mISDN - Kernel Opps

[maestro]

Hallo

Ich komme nicht mehr weiter. Ich möchte Asterisk mit 2 HFCPII Karten betreiben, bekomme mISDN / mISDNuser / chan_mISDN und Asterisk auch ohne Problem compiliert, aber sobald ich mISDN laden möchte bekomme ich einen Kernel Opps:

Modular ISDN Stack core $Revision: 1.25.2.8 $
mISDNd: kernel daemon started
mISDNd: test event done
ISDN L1 driver version 1.11.2.9
ISDN L2 driver version 1.20.2.12
mISDN: DSS1 Rev. 1.29.2.12
DTMF modul version 1.11.2.6
CAPI Subsystem Rev 1.1.2.8
mISDN Capi 2.0 driver file version 1.14.2.6
HFC card c9c2f040 dch c9c2f0a0 bch1 c9c2f1fc bch2 c9c2f358
mISDN: HFC-PCI driver Rev. 1.39.2.18
ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 10 (level, low) -> IRQ 10
mISDN: HFC-PCI card manufacturer: CCD/Billion/Asuscom card name: 2BD0
HFC-PCI: defined at mem 0xd8a10000 fifo 0xc9e60000(0x9e60000) IRQ 10 HZ 1000
reset_hfcpci: entered
HFC_PCI: resetting HFC ChipId(30)
HFC-PCI status(4) before reset
HFC-PCI status(2) after reset
HFC-PCI status(4) after 5us
mISDNStackd started for id(00000100)
init_card: entered
inithfcpci: entered
kcapi: Controller 1: mISDN1 attached
contr->addr(01) cnr(01) st(00000100)
l1_manager prim f1482 not handled
HFC PCI: IRQ 10 count 131
HFC card cc3a5040 dch cc3a50a0 bch1 cc3a51fc bch2 cc3a5358
mISDN: HFC-PCI driver Rev. 1.39.2.18
ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 10 (level, low) -> IRQ 10
mISDN: HFC-PCI card manufacturer: CCD/Billion/Asuscom card name: 2BD0
HFC-PCI: defined at mem 0xd8aae000 fifo 0xc9a28000(0x9a28000) IRQ 10 HZ 1000
reset_hfcpci: entered
HFC_PCI: resetting HFC ChipId(30)
HFC-PCI status(4) before reset
HFC-PCI status(2) after reset
HFC-PCI status(4) after 5us
init_card: entered
inithfcpci: entered
mISDNStackd started for id(00000200)
mISDNStackd started for id(10010200)
mISDNStackd started for id(10020200)
mISDNStackd started for id(10010100)
Unable to handle kernel NULL pointer dereference at virtual address 00000070
printing eip:
c018588a
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: hfcpci mISDN_capi kernelcapi mISDN_dtmf l3udss1 mISDN_l2 mISD
N_l1 mISDN_core af_packet usbserial lp speedstep_lib freq_table thermal processo
r fan button battery ac snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd
_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_devic
e snd soundcore ipv6 edd usblp 8139too mii joydev sg st sd_mod sr_mod scsi_mod i
de_cd cdrom uhci_hcd parport_pc parport via_agp agpgart ext3 jbd evdev dm_mod us
bcore reiserfs
CPU: 0
EIP: 0060:[<c018588a>] Tainted: G U VLI
EFLAGS: 00010286 (2.6.8-24.20-mISDN )
EIP is at sysfs_hash_and_remove+0xa/0x9f
eax: 00000000 ebx: d8bf93b8 ecx: 00000070 edx: d8bf0ab0
esi: c9b9cc98 edi: c037d040 ebp: d8bf93f4 esp: c9e15ef0
ds: 007b es: 007b ss: 0068
Process mISDNStackd (pid: 4610, threadinfo=c9e14000 task=d6ea0550)
Stack: d8bf93b8 c9b9cc98 c0186a6c c9b9cc98 d8bf93cc c0186ba6 c9c2f290 c9c2f298
d8beee98 c9c2f298 c037d01c c0241a46 c9c2f298 c01d05f9 c9c2f2b0 c01d0600
00000000 000007d7 c01d0904 c9e15f48 c9c2f1fc d8beefff 6579616c 00302e72
Call Trace:
[<c0186a6c>] remove_files+0x1c/0x30
[<c0186ba6>] sysfs_remove_group+0x46/0x70
[<d8beee98>] release_mISDN_inst+0x48/0x60 [mISDN_core]
[<c0241a46>] class_dev_release+0x46/0x50
[<c01d05f9>] kobject_cleanup+0x69/0x70
[<c01d0600>] kobject_release+0x0/0x10
[<c01d0904>] kref_put+0x24/0x70
[<d8beefff>] mISDN_unregister_sysfs_inst+0x1f/0x80 [mISDN_core]
[<d8be9c25>] unregister_instance+0x25/0x210 [mISDN_core]
[<d8c1b461>] HFC_manager+0x351/0x460 [hfcpci]
[<d8be8a1d>] release_layers+0x1d/0x80 [mISDN_core]
[<d8be8e52>] mISDNStackd+0x372/0x680 [mISDN_core]
[<c011e83d>] do_exit+0x1ed/0x310
[<c011aab0>] autoremove_wake_function+0x0/0x30
[<c0105bb6>] ret_from_fork+0x6/0x20
[<c011aab0>] autoremove_wake_function+0x0/0x30
[<d8be8ae0>] mISDNStackd+0x0/0x680 [mISDN_core]
[<c0104255>] kernel_thread_helper+0x5/0x10
Code: 8d 1c 42 75 e2 89 e0 89 f2 89 1c 24 e8 c0 7f fd ff 83 c4 10 5b 5e 5f c3 89
f6 8d bc 27 00 00 00 00 56 53 89 c6 8b 40 08 8d 48 70 <ff> 48 70 0f 88 8c 00 00
00 89 f0 e8 86 ff ff ff 89 c3 3d 18 fc
<6>HFC PCI: IRQ 10 count 22
HFC card c9a1c840 dch c9a1c8a0 bch1 c9a1c9fc bch2 c9a1cb58
mISDN: HFC-PCI driver Rev. 1.39.2.18
HFC-PCI: No more PCI cards found
HFC 2 cards installed
mISDNStackd started for id(10020100)

Ich verzweifle langsam

 

[lo4dro]

Versuch mal die Version von chan_misdn.
http://www.beronet.com/downloads/chan_misdn/stable/candidates/chan_misdn-0.3.0-rc27.tar.gz
Das ist auch die letzte Version die bei mir funktioniert.
Alle weitere Version führen zu einem Kernel oooops

 

[sterkel]

Hallo

Ich verzweifle langsam

Die Karten scheinen auf dem gleichen IRQ zu liegen, versuch mal Dein System so zu konfigurieren dass sie kein IRQ-sharing machen müssen, vielleicht lindert das die Sache schon.

 

[crich]

Das liegt am 2.6.8. Ich kenne nur einen der mISDN-mqueue erfolgreich mit dem 2.6.8 Kernel am laufen hat und das ist Hobbystern.. Ich empfehle definitiv mindestens einen 2.6.12 Kernel zu nehmen.

PS. chan_misdn Version ist bei Kernel Oopsen unerheblich, da ist nur das mISDN von bedeutung.

 

[lo4dro]

...
PS. chan_misdn Version ist bei Kernel Oopsen unerheblich, da ist nur das mISDN von bedeutung.

Aber es muss doch einen Zusammenhang zwischen chan_misdn und mISDN bestehen.
Wie du weist, bekomme ich auch ab einer speziellen Version bei jedem Dian-In ein Kernel-Ooops.
Daher würde ich die Schuld nicht nur auf mISDN abwälzen.

 

[maestro]

Hallo

chan_misdn ist doch nur der Treiber für Asterisk ( mISDN <-> chan_misdn <-> aterisk )

mit dem Kernelmodul mISDN hat chan_misdn nichts zu tun.

Markus

 

[crich]

Naja.. also natürlich ruft chan_misdn mISDN Funktionen auf. Wenns aber einen Kernel Oops gibt, dann entsteht der in mISDN. Da mISDN noch nicht alle Fehlerfälle abfängt und es leider kaum Doku dazu gibt, kann es sein das chan_misdn nicht immer optimal mit mISDN 'umgeht' ..

 

[mrenner]

Hallo.

lo4dro scheint mit seiner Vermutung, dass chan_misdn am Kernel-Oops beteiligt ist, nicht unrecht zu haben.

Auch wir hatten das Problem, dass mit dem "install-misdn-queue" von Freitag, 05.05., ein Kernel-Oops bei eingehenden Anrufen auftrat. "chan_misdn" lag in der Version 0.3.1-rc3 vor.

Nun habe ich nur chan_misdn durch die genannte Version .../stable/candidates/chan_misdn-0.3.0-rc27.tar.gz ersetzt und der Server läuft seit 6 Stunden ohne Oops.

 

[HobbyStern]

Ich habe heute die Erfahrung gemacht das die aktuellsten Versionen nicht immer die besten sind, chan_misdn teilt sich eine "lib" mit misdn, ich hoffe ich habe mir das vorhin so richtig selber beigebracht - die lib hat bei mir für jede Menge furore mit der aktuellen misdn version vom cvs gesorgt, ein downgrade auf die genannte 27iger und die Installation steht...

:noidea:

Gut´Nacht, Tag war lang!

 

[lo4dro]

Nun bin ich aber froh, das ich nicht der einzige User mit diesen Problemen bin.

 

[HobbyStern]

Ich möchte mich gerne so ausdrücken :

Bisher (klopfaufholz) habe ich mit der neuen Konstellation :

Kernel 2.6.15 (wie crich ihn empfohlen hat via backports)
Asterisk 1.2.6,Zaptel 1.2.4,Libpri 1.2.4
und mISDN 0.3.0 RC27

heute morgen *sehr* gute Erfahrungen gemacht.

Mal abwarten ! Aber im Endeffekt ist uns doch allen daran gelegen das mISDN zu der Komponente schlechthin für Asterisk wird, oder ?!

Grüsse,

Stefan

 

[crich]

Kann mir mal jemand der mit 0.3.0-rc3 einen Kernel Oops bekommt seine Kernel Version, und die Kernel Config zusenden. Ich würde auch gern diesen Oops haben

 

[mrenner]

Kann mir mal jemand der mit 0.3.0-rc3 einen Kernel Oops bekommt seine Kernel Version, und die Kernel Config zusenden. Ich würde auch gern diesen Oops haben

Gerne. Wohin?

 

[crich]

einfach mal an [email protected]

 

[lo4dro]

Hallo.

Wie sieht es aus? Schon den Bug gefunden?

 

[crich]

für den oben beschriebenen oops hab ich einen Workaround gemacht, ist bereits im CVS von mISDN, also einfach das mISDN updaten und nochmal probieren.

Bezüglich der backports kernel ist mir aufgefallen, dass Profiling dort leider eingeschaltet ist. Profiling führt in verschiedenen Kombinationen zum Oops.

Ich versuche morgen mal rauszufinden ob man das per kernelparameter deaktivieren oder harmlos machen kann, andernfalls muss man den Kernel ohne Profiling support kompilieren.