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

rolandm · 4 Mrz 2005

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.

revki · 8 Mrz 2005

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.

rolandm · 26 Mrz 2005

auch mit bristuff-0.2.0-RC7k und ohne florzs patch kommt der
Protection Fault nach 8 tagen dauerbetrieb :cry:

Specki · 28 Mrz 2005

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

papaya74 · 21 Jun 2005

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

rolandm · 21 Jun 2005

papaya74 schrieb:
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.

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.

svenux · 11 Aug 2005

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.

wwg2000 · 3 Sep 2005

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?

wwg2000 · 13 Sep 2005

hat schon irgendjemand eine Lösung des ganzen?? ich hab den Fehler immernoch und der ist ganz schön ärgerlich.

rolandm · 13 Sep 2005

wwg2000 schrieb:
hat schon irgendjemand eine Lösung des ganzen?? ich hab den Fehler immernoch und der ist ganz schön ärgerlich.

hallo,

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

chronoton · 11 Okt 2005

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.

RcRaCk2k · 22 Okt 2005

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.

*-tuxi · 29 Nov 2005

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

Sharum · 27 Dez 2005

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?

TheOe · 2 Jan 2006

Das mit der automatischen Auswertung der logs würde mich auch interessieren, Habe das selbe Problem, obwohl der Rechner täglich rebootet wird.

papaya74 · 3 Jan 2006

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

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

TheOe · 4 Jan 2006

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

glotzi · 5 Jan 2006

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.

TheOe · 9 Jan 2006

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

Moo2Mee · 8 Apr 2006

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

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

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Statistik des Forums