[Home]

Summary:ASTERISK-01600: Bringing hdlc0 interface down and back up causes kernel panic
Reporter:zchamber (zchamber)Labels:
Date Opened:2004-05-12 14:37:41Date Closed:2004-09-25 02:45:09
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:after compiling the zaptel drivers with:

#define CONFIG_ZAPATA_NET
#define CONFIG_ZAPATA_PPP

in zconfig.h, I was able to load the modules and configure hdlc0.  Regardless of whether or not there's a T1 line plugged in, if you execute the following commands:

/sbin/ifup hdlc0
/sbin/ifdown hdlc0
/sbin/ifup hdlc0

(as if you were reconfiguring an interface) the kernel will panic within 30 seconds.

****** ADDITIONAL INFORMATION ******

Distribution: Fedora Core 1
Kernel: Fedora Standard 2.4.22-2188-nptl, or stock 2.4.26 kernel compiled from scratch.
Hardare:  I've tried two: VIA motherboard, VIA chipset, with Athlon XP 1800, and A-bit with PII-400, Intel chipset.  Neither machine uses shared video memory.
Zaptel driver: 0.9.1, or cvs
Comments:By: Mark Spencer (markster) 2004-05-12 15:11:04

Please be sure to use CVS.  Can you provide a ksymoops of the resulting panic?
By: zchamber (zchamber) 2004-05-12 15:28:09

I'm using the CVS version current to a couple of hours ago.  Is there an easy way to pull the kysmoops?  Does it dump that info somewhere where is can be recovered after the next boot?
By: Mark Spencer (markster) 2004-05-12 15:38:22

serial console probably.
By: James Golovich (jamesgolovich) 2004-05-12 16:06:35

Which zaptel interface do you have.  I've not had a problem with this before.  I'm not using that specific kernel though
By: zchamber (zchamber) 2004-05-12 16:12:02

working on the ksymoops, but in the mean time the card is the T100P. I knew I was forgetting to include something ;)
By: James Golovich (jamesgolovich) 2004-05-12 16:14:27

Ok, I've only done nethdlc on T400P and TE410P.  I think I have a T100P at home I can try this on, but I'll also see if I can upgrade to that specific kernel and try it on my other cards
By: zchamber (zchamber) 2004-05-12 16:32:24

For what it's worth, I've already tried removing all APM stuff from the kernel, it had no effect except that I don't think I got any koops data when that was done.

Raw koops data:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c012043c
*pde = 00000000
Oops: 0000
apm via-rhine mii wcusb wct1xxp zaptel ppp_generic slhc hdlc syncppp keybdev mousedev input hid ehci-hcd usb-uhci usbcore ext3 jbd  
CPU:    0
EIP:    0060:[<c012043c>]    Not tainted
EFLAGS: 00010086

EIP is at timer_bh [kernel] 0xc8 (2.4.22-1.2188.nptlcustom)
eax: 00000000   ebx: c114dc14   ecx: c0339204   edx: c1156614
esi: c1156514   edi: c0339034   ebp: c0338fe0   esp: c0315f28
ds: 0068   es: 0068   ss: 0068
Process swapper (pid: 0, stackpage=c0315000)
Stack: 00000001 c0315f2c c0315f2c 00000000 c0330370 fffffffe 00000046 c011ccfe
      c011cc33 00000000 00000001 c011caab c0330370 c032f900 00000000 c0315f84
      c02d0b7c c010a544 000089ff c0314000 00000010 00000001 c010cbb8 000089ff
Call Trace:   [<c011ccfe>] bh_action [kernel] 0x1e (0xc0315f44)
[<c011cc33>] tasklet_hi_action [kernel] 0x3b (0xc0315f48)
[<c011caab>] do_softirq [kernel] 0x8b (0xc0315f54)
[<c010a544>] do_IRQ [kernel] 0x90 (0xc0315f6c)
[<c010cbb8>] call_do_IRQ [kernel] 0x5 (0xc0315f80)
[<c0106c33>] default_idle [kernel] 0x23 (0xc0315fac)
[<c68b83c1>] apm_cpu_idle [apm] 0xa1 (0xc0315fb8)
[<c68b8320>] apm_cpu_idle [apm] 0x0 (0xc0315fbc)
[<c0106c8e>] cpu_idle [kernel] 0x2a (0xc0315fcc)
[<c0105000>] stext [kernel] 0x0 (0xc0315fd8)


Code: 8b 10 39 fe 89 4a 04 89 11 89 41 04 89 08 89 f1 75 aa 89 3f
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

ksymoops output:

ksymoops 2.4.9 on i686 2.4.22-1.2188.nptl.  Options used
    -V (default)
    -k /proc/ksyms (default)
    -l /proc/modules (default)
    -o /lib/modules/2.4.22-1.2188.nptl/ (default)
    -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object.  Trace may not be reliable.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
c012043c
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<c012043c>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 00000000   ebx: c114dc14   ecx: c0339204   edx: c1156614
esi: c1156514   edi: c0339034   ebp: c0338fe0   esp: c0315f28
ds: 0068   es: 0068   ss: 0068
Process swapper (pid: 0, stackpage=c0315000)
Stack: 00000001 c0315f2c c0315f2c 00000000 c0330370 fffffffe 00000046 c011ccfe
      c011cc33 00000000 00000001 c011caab c0330370 c032f900 00000000 c0315f84
      c02d0b7c c010a544 000089ff c0314000 00000010 00000001 c010cbb8 000089ff
Call Trace:   [<c011ccfe>] bh_action [kernel] 0x1e (0xc0315f44)
[<c011cc33>] tasklet_hi_action [kernel] 0x3b (0xc0315f48)
[<c011caab>] do_softirq [kernel] 0x8b (0xc0315f54)
[<c010a544>] do_IRQ [kernel] 0x90 (0xc0315f6c)
[<c010cbb8>] call_do_IRQ [kernel] 0x5 (0xc0315f80)
[<c0106c33>] default_idle [kernel] 0x23 (0xc0315fac)
[<c68b83c1>] apm_cpu_idle [apm] 0xa1 (0xc0315fb8)
[<c68b8320>] apm_cpu_idle [apm] 0x0 (0xc0315fbc)
[<c0106c8e>] cpu_idle [kernel] 0x2a (0xc0315fcc)
[<c0105000>] stext [kernel] 0x0 (0xc0315fd8)
Code: 8b 10 39 fe 89 4a 04 89 11 89 41 04 89 08 89 f1 75 aa 89 3f


>>EIP; c012043c <exit_mm+7dc/a70>   <=====

>>ebx; c114dc14 <_end+d3919c/103f85e8>
>>ecx; c0339204 <__start___kallsyms+8b944/8ef3f>
>>edx; c1156614 <_end+d41b9c/103f85e8>
>>esi; c1156514 <_end+d41a9c/103f85e8>
>>edi; c0339034 <__start___kallsyms+8b774/8ef3f>
>>ebp; c0338fe0 <__start___kallsyms+8b720/8ef3f>
>>esp; c0315f28 <__start___kallsyms+68668/8ef3f>

Trace; c011ccfe <__out_of_line_bug+49e/630>
Trace; c011cc33 <__out_of_line_bug+3d3/630>
Trace; c011caab <__out_of_line_bug+24b/630>
Trace; c010a544 <dump_stack+a24/f80>
Trace; c010cbb8 <disable_irq_nosync+11e8/30b0>
Trace; c0106c33 <empty_zero_page+2c33/2f70>
Trace; c68b83c1 <_end+64a3949/103f85e8>
Trace; c68b8320 <_end+64a38a8/103f85e8>
Trace; c0106c8e <empty_zero_page+2c8e/2f70>
Trace; c0105000 <empty_zero_page+1000/2f70>

Code;  c012043c <exit_mm+7dc/a70>
00000000 <_EIP>:
Code;  c012043c <exit_mm+7dc/a70>   <=====
  0:   8b 10                     mov    (%eax),%edx   <=====
Code;  c012043e <exit_mm+7de/a70>
  2:   39 fe                     cmp    %edi,%esi
Code;  c0120440 <exit_mm+7e0/a70>
  4:   89 4a 04                  mov    %ecx,0x4(%edx)
Code;  c0120443 <exit_mm+7e3/a70>
  7:   89 11                     mov    %edx,(%ecx)
Code;  c0120445 <exit_mm+7e5/a70>
  9:   89 41 04                  mov    %eax,0x4(%ecx)
Code;  c0120448 <exit_mm+7e8/a70>
  c:   89 08                     mov    %ecx,(%eax)
Code;  c012044a <exit_mm+7ea/a70>
  e:   89 f1                     mov    %esi,%ecx
Code;  c012044c <exit_mm+7ec/a70>
 10:   75 aa                     jne    ffffffbc <_EIP+0xffffffbc>
Code;  c012044e <exit_mm+7ee/a70>
 12:   89 3f                     mov    %edi,(%edi)

<0>Kernel panic: Aiee, killing interrupt handler!

2 warnings and 3 errors issued.  Results may not be reliable.
By: zchamber (zchamber) 2004-05-17 12:37:22

Haven't heard anything after the initial flurry of activity ;)  Anything else I do to help with this process?  One interesting note is that if i drop back to a 2.4.20 kernel and compile the zaptel drivers with the "OLD HDLC" code, the problem goes away.  I can bounce the interface all I want without trouble thus far.  The problem seems to be limited to the "new" HDLC code.
By: James Golovich (jamesgolovich) 2004-05-17 13:05:44

I tried to work on this over the weekend but didn't have enough time to discover the cause.  I am able to reproduce this on my box with a T400P.  Hopefully I'll have some free time tonight or tommorow to test this
By: James Golovich (jamesgolovich) 2004-05-18 02:51:58

Fixed in CVS.  Please re-open if this isn't the case, but I'm pretty sure on this one.  I've tried a few different kernels and now it works great