Summary: | misc/dahdi-kmod: FreeBSD crashes periodically with RedFone FB2 and dahdi_dynamic_ethmf driver | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | bsd |
Component: | Individual Port(s) | Assignee: | Max Khon <fjoe> |
Status: | Closed Feedback Timeout | ||
Severity: | Affects Only Me | CC: | cs, ktrace, w.schwarzenfeld |
Priority: | Normal | ||
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
bsd
2013-03-15 08:00:00 UTC
Responsible Changed From-To: freebsd-ports-bugs->fjoe Over to maintainer (via the GNATS Auto Assign Tool) It's highly probably that problem is due to loss of TDMoE packets. I found workaround: Crashes goes away when connecting FB2 directly to server without Ethernet switches. Is this PR still relevant? Hello. I don't sure is this problem still exists in latest FreeBSD. I using 9.1-RELEASE. Without ethernet switches it's working much better, but I got kernel panic twice (19 Aug 2014 and 7 Feb 2014) with following stack trace: spin lock 0xffffffff816443c0 (dahdi_timer_lock) held by 0xfffffe0098129000 (tid 125869) too long panic: spin lock held too long cpuid = 1 KDB: stack backtrace: #0 0xffffffff809208a6 at kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 0xffffffff808d8a9c at _mtx_lock_spin_failed+0x3c #3 0xffffffff808d8c66 at _mtx_lock_spin+0x1c6 #4 0xffffffff808d9184 at _mtx_lock_spin_flags+0x94 #5 0xffffffff8162323a at _process_masterspan+0x63a #6 0xffffffff816233c1 at _dahdi_receive+0x111 #7 0xffffffff8164f290 at dahdi_dynamic_receive+0x210 #8 0xffffffff816512d5 at ztdethmf_rcv+0x2d5 #9 0xffffffff81653137 at ng_dahdi_netdev_rcvdata+0xa7 #10 0xffffffff81647ca0 at ng_apply_item+0x220 #11 0xffffffff81646efe at ng_snd_item+0x2ce #12 0xffffffff809a35a7 at ether_demux+0x127 #13 0xffffffff809a38a4 at ether_nh_input+0x1f4 #14 0xffffffff809adafb at netisr_dispatch_src+0x20b #15 0xffffffff80c0e1e3 at nfe_int_task+0x9e3 #16 0xffffffff8092cf55 at taskqueue_run_locked+0x85 #17 0xffffffff8092ded6 at taskqueue_thread_loop+0x46 Uptime: 128d23h47m25s I have two kernel core dumps for this problem. Thanks for your update. Confirm same in 9.3-STABLE spin lock 0xc5d52bb0 (dahdi_timer_lock) held by 0xc5s5d000 (tid 100146) too long panic: spin lock held too long cpuid = 0 KDB: stack backtrace; #0 0xc0b1ef6f at kdb_backtrace+0x4f #1 0xc0ae5b8f at panic+0x16f #2 0xc0ad048f at _mtx_lock_spin_failed+0x3f #3 0xc0ad0f05 at _mtx_lock_spin+0x165 #4 0xc0ad1721 at _mtx_lock_spin_flags+0x71 #5 0xc5d3165a at _process_masterspan+0x62a #6 0xc5d317c2 at _dahdi_receive+0x112 #7 0xc5d4e97c at dahdi_dynamic_receive+0x21c #8 0xc5c69190 at zldeth_rcv+0x60 #9 0xc5c6cf43 at ng_dahdi_netdev_rcvdata+0xb3 #10 0xc174c911 at ng_apply_item+0x1f1 #11 0xc174bb4f at ng_snd_item+0x28f #12 0xc0babc4f at ether_demux+0x20f #13 0xc0bac88f at ether_nb_input+0x38f #14 0xc0bb51af at netisr_dispatch_src+0x0f #15 0xc0bb5450 at netisr_dispatch+0x20 #16 0xc0bab6f9 at ether_input+0x19 #17 0xc0cdf8e2 at rl_rxeof+0x252 dahdi-2.4.0rc5_6 DAHDI userland utilities and libraries dahdi-kmod26-2.6.1.r10747_1 Digium/Asterisk Hardware Device Interface FreeBSD 9.3-STABLE #15 r275474 Once more traps. dahdi_netdev(dahdi@rl0): new netgraph node Fatal trap 12: page fault while in kernel mode dahdi_netdev(dahdi@rl0): ether 00:04:61:9f cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc5ef1bea stack pointer = 0x28:0xe82bf6b8 frame pointer = 0x28:0xe82bf910 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7586 (dahdi_cfg) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc0b209ef at kdb_backtrace+0x4f #1 0xc0ae771f at panic+0x16f #2 0xc0fb0df3 at trap_fatal+0x323 #3 0xc0fb0ef8 at trap_pfault+0xf8 #4 0xc0fb22bb at trap+0x59b #5 0xc0f9adbc at calltrap+0x6 #6 0xc5e9223b at dahdi_dynamic_ioctl+0x4eb #7 0xc60da222 at dahdi_unlocked_ioctl+0x162 #8 0xc60cfabb at dahdi_device_ioctl+0x3b #9 0xc09bd53a at devfs_ioctl_f+0x10a #10 0xc0b33630 at kern_ioctl+0x2a0 #11 0xc0b337e8 at sys_ioctl+0x178 #12 0xc0fb16e3 at syscall+0x443 #13 0xc0f9ae51 at Xint0x80_syscall+0x21 9.1-RELEASE is EOL. Is this still relevant? I think it is as it is not specific to the FreeBSD release. ^Triage: close as OBE. To submitter: please let us know if we have closed this in error. |