.titleBar { margin-bottom: 5px!important; }

PRI: Whooopsie...general protection fault in module TEI mana

Dieses Thema im Forum "Asterisk ISDN mit Bristuff (hfc, zaptel)" wurde erstellt von rolandm, 4 März 2005.

  1. rolandm

    rolandm Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    nach vielleicht 10 tagen betrieb bekomme ich den "general protection fault in module TEI manager" fehler.
    bei meiner 2. und 3. asterisk installation ist dieser fehler noch noch aufgefallen.

    kann es sein, dass es daran liegt, dass wir hier häufig GIGASET interne gespräche führen?
    dabei wird wohl zuerst ein ZAP channel im ASTERISK belegt, man hört das freizeichen, dann aber GIGASET-intern zu einer anderen nebenstelle verbunden.
    kann es sein, dass da der LIBPRI TEI manager durcheinanderkommt? sprich sich verzählt?

    nur so eine vermutung.
     
  2. revki

    revki Neuer User

    Registriert seit:
    12 Okt. 2004
    Beiträge:
    30
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    ich habe auch das Gigaset (bzw. hier das T-Sinus 721 MMS) in Verdacht. Der Protection Fault kommt bei mir z.B. dann, wenn ich die Option "Verzögertes Klingeln" nutze und das Gespräch dann heranhole, wenn ein anderes angemeldetes Mobilteil klingelt. Sehr ärgerlich das Ganze, weil danach hilft nur noch der * Neustart :-(.

    Grüße
    FP.
     
  3. rolandm

    rolandm Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    auch mit bristuff-0.2.0-RC7k und ohne florzs patch kommt der
    Protection Fault nach 8 tagen dauerbetrieb :cry:
     
  4. Specki

    Specki Neuer User

    Registriert seit:
    12 Okt. 2004
    Beiträge:
    42
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi,

    ich nutze ebenfalls die bristuff-0.2.0-RC7k (Florz Patch und 3 x HFC-S Karte) und eine Gigaset 1000 ISDN. Wenn ich über die INT Funktion verbinden möchte, rauscht mir Asterisk so richtig ab, dass sich in der Asterisk-Kommandozeile nichts mehr bewegt und nur noch ein Neustart des ganzen Servers hilft. Die normale Rückfrage scheint zu funktionieren. Zudem mache ich jede Nacht um 4:00 Uhr einen Neustart des Asterisk Daemons. Seitdem habe ich kaum noch Hänger (natürlich nur, wenn ich die INT Funktion schön beiseite lasse).
    Schön ist das mit den Gigasets nicht, habe auch schon eine Gigaset SX205 dran gehabt, mit denselben Problemen.

    Gruß,

    Specki
     
  5. papaya74

    papaya74 Neuer User

    Registriert seit:
    5 Jan. 2005
    Beiträge:
    24
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Moin zusammen,

    das ist ja interessant...

    Ich habe auch ein Gigaset SX353 und S1 und bekomme in regelmässigen Abständen (ca. Alle 2 Wochen) die "Whoopsie..."-Meldung, so dass nur ein '/etc/init.d/asterisk restart' hilft.

    Jedoch starte ich den Asterisk auch jeden Tag mittels cron um 4.00 Uhr morgens neu, so dass er eigentlich immer frisch an den Start gehen sollte.

    Interne Gespräche sind bei mir KEIN Problem, läuft super, * sagt gar nix dazu.

    Habe nun mal die Zeiten in eine Tabelle gepackt, um eine Regelmäßigkeit zu finden, aber bisher leider negativ.

    Warum kommt denn Whooopsie-Goldberg immer wieder vorbei ?! Was will die denn von uns ?? ;-)

    Gruss,

    Harry
     
  6. rolandm

    rolandm Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    ich restarte asterisk 1x pro woche und habe seit dem keine whoopsies mehr.

    nur kackt mir asterisk Nr.1 so alle 4-6 wochen einmal komplett ab.
    da steht alles. kompletter freeze.
    bei asterisk Nr.2 (in der nachbarschaft) passiert das zum teil täglich.
    unterschied: dort sehr viele und lange gespräche zur t-com.

    hab mal lkcd (Linux Kernel Crash Dump) installiert um einen dump
    des crashes zu bekommen. funktioniert aber leider nicht.

    also wenn mir da jemand mal einen tipp geben könnte.
     
  7. svenux

    svenux Neuer User

    Registriert seit:
    19 Feb. 2005
    Beiträge:
    10
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi,

    damit es nicht in Vergessenheit gerät. Ich hatte heute die selbe Meldung und beitze wie ihr auch ein Siemens Gigaset Telefon (SX100 mit S1).

    Code:
    Aug 11 16:12:54 WARNING[4057]: chan_zap.c:7534 zt_pri_error: PRI: Whooopsie...general protection fault in module TEI manager.
    Das System (Asterisk 1.0.9 mit florzs Patch) lief 2 Wochen, 1 Tag, 8 Stunden, 43 Minuten und 20 Sekunden 8).
    Über die Asteriskkonsole konnte ich den Daemon restarten.
     
  8. wwg2000

    wwg2000 Neuer User

    Registriert seit:
    28 Juli 2005
    Beiträge:
    14
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi,
    ist ja wirklich sehr komisch. Ich hab das gleich Problem.
    Mein Telefon ist ein T-Sinus 720P, ich glaub die sind baugleich zu den Gigaset dingern .... sehr komisch.

    Hat jemand schon eine Lösung gefunden?
     
  9. wwg2000

    wwg2000 Neuer User

    Registriert seit:
    28 Juli 2005
    Beiträge:
    14
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hat schon irgendjemand eine Lösung des ganzen?? ich hab den Fehler immernoch und der ist ganz schön ärgerlich.
     
  10. rolandm

    rolandm Neuer User

    Registriert seit:
    23 Nov. 2004
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hallo,

    schön ist es sicher nicht, aber mit dem einmal pro woche asterisk restart kann ich problemlos leben.
     
  11. chronoton

    chronoton Neuer User

    Registriert seit:
    27 Juli 2005
    Beiträge:
    18
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Die Sache mit dem Whoopsie

    Gut - Ihr seid nicht allein und ich Gott sei Dank auch nicht. Das Whoopsie Problem tritt bei mir auch auf, ebenfalls Gigaset ISDN Telefon als DECT Basis und ein Gigaset Micro dazu. Ich habe das Gefühl, daß nicht die internen Gespräche schuld sind sondern asterisk durcheinander kommt, da beide Telefone klingeln, obwohl * nur das eine anwählt ( aber das Gigaset so eingestellt ist, daß das andere mitklingelt ).

    Lustig ist, wir sind alle auf den selbigen fix gekommen, spooky ist schon eher, daß ich auch unabhängig von diesem thread meinen asterisk restart per cron ebenfalls auf 0400 gelegt habe ;).

    Das Problem verschlimmert sich noch, sobald ich ein T-Com ISDN Fax mit an den gleichen S0 Bus hinter der HFC hänge ( parallel zu den Telefonen ).

    Teilweise hilft * neustart, teilweise muss ich die hfc module unloaden / loaden / neu initialisieren / S0 komplett ausstecken.

    Das ist wirklich nicht angenehm.

    Wenn jemand eine Lösung dazu weiss, wären wir alle hier sicher dankbar.
     
  12. RcRaCk2k

    RcRaCk2k Mitglied

    Registriert seit:
    4 Aug. 2005
    Beiträge:
    230
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Mag den Thread gerne mal wieder on the top bringen...

    Gleiches Problem. Muss sogar die kompletten Module unloaden und neu loaden, und nen ZAP-Reset machen.

    Blöde Sache. Ebenfalls Siemens GigaSet am Gerät laufen.
    Muss ja ein interner Fehler irgendwo sein - an der Fritz 7050 WLAN ging die Siemens DECT-Anlage ja auch korrekt.

    Hoffentlich wird dafür bald Abhilfe geschaffen.

    Grüße
    Michi.
     
  13. *-tuxi

    *-tuxi Neuer User

    Registriert seit:
    28 Sep. 2005
    Beiträge:
    126
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Hehe, guten Morgen allerseits...
    Arbeite hier mit verschiedenen Telekom-Geräten am internen ISDN-Bus (T-Sinus 720P, T-Europa 11a (2x), T-Sinus 700K (3x) ) und habe das gleiche Problem - nach 8 oder ein paar mehr Tagen schmiert Asterisk sozusagen ab. Im Display der Telefone steht dann nach einigen Sekunden "Störung". Asterisk gibt Whoopsie auf dem CLI aus, sobald an einem Telefon abgenommen wird.
    Seltsam ist nur, dass teilweise nicht alle Telefone gleichermaßen von dem Problem betroffen sind.
    Ich kann also, wenn es beispielsweise am 720P nicht mehr geht manchmal noch vom Europa telefonieren.

    Alles zusammen sehr merkwürdig. Hat sich hier denn insgesamt schon etwas wegen diesem Problem getan?

    Michael
     
  14. Sharum

    Sharum Neuer User

    Registriert seit:
    13 Feb. 2005
    Beiträge:
    30
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Habe mit einer Siemens Gigaset ISDN Basis Station bei einem das gleiche Problem. Ein Analoges Telefon über nen 2A/B Wandler läuft meist einwandfrei weiter.

    Workaround ist wirklich per "cron" Aufruf und Script Nachts die Kiste neu zu starten.

    zB
    asterisk -x -r "stop now"
    bristuff entladen
    bristuff laden
    asterisk starten

    Hat jemand Erfahrung die /var/log/asterisk/messages auszuwerten?
    Dann könnte man doch per cron alle 5 min checken ob in den messages ein Whoopsie erscheint und dann sofort asterisk neu starten. Dann wäre die Totzeit im schlimmsten Fall 5 min. Man müsste nur aufpassen, dass in dem Moment keiner telefoniert.
    Gibt es dafür schon eine Lösung oder macht Ihr das alle Nachts per cron?
     
  15. TheOe

    TheOe Neuer User

    Registriert seit:
    31 Dez. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Das mit der automatischen Auswertung der logs würde mich auch interessieren, Habe das selbe Problem, obwohl der Rechner täglich rebootet wird.
     
  16. papaya74

    papaya74 Neuer User

    Registriert seit:
    5 Jan. 2005
    Beiträge:
    24
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ich mache per cron JEDEN morgen um 8.00 Uhr ein:
    Code:
    /etc/init.d/asterisk stop
    /etc/init.d/asterisk start
    ABER: Es hilft nichts, denn die "Wooopsie..." - Meldung kommt spontan erst beim wählen, bzw abheben des Telefons...

    Wenn ich dann NACH der "Wooopsie..."-Meldung ein:
    Code:
     /etc/init.d/asterisk stop
    /etc/init.d/asterisk start
    mache, dann läuft es wieder ca. eine Woche....SEHR, SEHR seltsam

    Habe auch noch diesen Link gefunden:
    =================================
    http://www.ip-phone-forum.de/showthread.php?t=64205

    Vielleicht sollten wir das mal überprüfen, ich glaube in der Tat es ist ein HARDWARE-Problem !!

    Gruß,
    /harry
     
  17. TheOe

    TheOe Neuer User

    Registriert seit:
    31 Dez. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also ein Interrupt-Proplem schliesse ich aus, ich hab extra drauf geachtet, dass zaphfc je auf einem eigen Interrupts liegen.
    Code:
    cat /proc/interrupts
               CPU0       
      0:    3265732          XT-PIC  timer
      1:          2          XT-PIC  keyboard
      2:          0          XT-PIC  cascade
      5:  260934062          XT-PIC  zaphfc
      7:  260930457          XT-PIC  zaphfc
      8:        196          XT-PIC  rtc
      9:          0          XT-PIC  usb-uhci
     11:      12990          XT-PIC  eth0
     12:      18683          XT-PIC  usb-uhci, eth1
     14:     274514          XT-PIC  ide0
     15:          8          XT-PIC  ide1
    NMI:          0 
    LOC:          0 
    ERR:          0
    MIS:          0
    
    lspci
    0000:00:00.0 Host bridge: Intel Corp. 82850 850 (Tehama) Chipset Host Bridge (MCH) (rev 04)
    0000:00:01.0 PCI bridge: Intel Corp. 82850 850 (Tehama) Chipset AGP Bridge (rev 04)
    0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 04)
    0000:00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 04)
    0000:00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 04)
    0000:00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 04)
    0000:00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 04)
    0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 04)
    0000:01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro] (rev 11)
    0000:02:09.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 43)
    0000:02:0a.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
    0000:02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
    0000:02:0c.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
    
    Trotzdem kommt es nach 5-7 Stunden zu " Whooopsie...general protection fault in module TEI manager." Ich glaub ich klemme das Gigaset mal ab.

    MfG Marcel
     
  18. glotzi

    glotzi Neuer User

    Registriert seit:
    26 Nov. 2004
    Beiträge:
    72
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    In den ReleaseNotes des neuesten BRI-Stuff 0.3.0-PRE-1e gibts einen interessanten Hinweis:

    0.3.0-PRE-1e
    [...]
    - added TEI recovery to libpri
    - modified libpri to request a TEI on startup of a BRI_CPE_PTMP span

    Recovery Evtl. löst das das Whooopsie-Problem.
     
  19. TheOe

    TheOe Neuer User

    Registriert seit:
    31 Dez. 2005
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ob ein neuer bristuff das Problem in den Griff bekommt kann ich bis jetzt nicht entgültig bestätigen, zwar hatte ich keine Whooopsie-Meldung mehr seit bristuff-0.3.0-PRE-1f bei mir läuft, dafür hat sich ein anderes Problem eingestellt -> http://www.ip-phone-forum.de/showthread.php?t=91660
     
  20. Moo2Mee

    Moo2Mee Neuer User

    Registriert seit:
    16 Nov. 2005
    Beiträge:
    10
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Habe das beschriebene Problem so "gelöst":

    (System: Asterisk 1.0.7 auf/von debian Sarge, HFC im NT-Mode, Telekom Sinus 720PA und Europa 30i da dran)

    Eine Logdatei, in der nur Warnmeldungen, unter anderem auch die Whooopsie-Meldungen, geloggt werden, wird überwacht.
    das Programm lorgprn gibt alle neuen Logmeldungen an ein Script, welches bei Auftauchen der Whoooopsie-Meldungen den Asterisk neu startet.

    Und so hab ich das angestellt...
    Paket logtools installieren, dieses beinhaltet logprn, das brauchen wir:

    Code:
    apt-get install logtools
    
    Ein Logfile, was nicht rotiert wird, für die zu überwachenden Whoopsie-Meldungen:

    Code:
    echo "whooopsie => warning" >> /etc/asterisk/logger.conf
    
    Asterisk neu starten (/var/log/asterisk/whooopsie sollte nun existieren):

    Code:
    /etc/init.d/asterisk restart
    
    Ein Shell-Script, was das Logfile auswertet und asterisk neu startet unter zB. /usr/local/sbin anlegen und ausführbar machen. Ich habs mal asterooopsie genannt :)

    Code:
    #!/bin/sh
    
    #
    # Logfile auf Whooopsie pruefen und Asterisk neu starten
    #
    
    grep -q Whooopsie...general
    
    if [ $? = "0" ] ; then
            /etc/init.d/asterisk restart
    fi
    
    Jetzt noch logprn starten, der das vorherige Script immer mit den Änderungen des Logfiles füttert. Das Ganze kann man natürlich sich auch als Init-Script basteln, daß nach einem Neustart logprn automatsuch gestartet wird.

    Code:
    logprn /var/log/asterisk/whooopsie 10:60 /usr/local/sbin/asterooopsi
    
    So sollte das nun klappen... Hier tuts ;-) Ausfallzeit bei einem Whooopsie ca 70 Sekunden.

    Denne, Didi