From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Pump is taking a kernel panic at bootup on my TokenRing interface (worked
fine in previous versions).
Steps to Reproduce:
2.Select DHCP for token ring adapter
Actual Results: kernel panic aieeee
Expected Results: System should boot up and get a dhcp address.
I'm testing on a Dell 2400, with Dual 866 SMP configuration. The adapters
installed are AMI Megaraid (perc2/dc),IBM PCI token ring adapter
(olympic), 3com 3c905c-tx, adaptec a7xxx (for tape and cd). The system is
configured with 512mb memory. The problem is easily reproduceable.
I'm beginning to suspect either the olympic driver, or the way the kernel
handles PCI on this box. I'm not sure which at this point. Here is some of
the register information, hopefully that'll help someone figure out what's
*pde = 0728d001
*pte = 00000000
eax: 00000000 ebx: c5f15900 ecx:0000000 edx:c494f750
esi: c494f6e0 edi:c42d2a00 ebp:c5f15900 esp: c728fc40
Process pump (pid838, stackpage=c728f000)
Stack and call trace stuff........
Code: Bad EIP value
Kernel panic: Aiee, killing interrupt handler
In interrupt handler - not syncing
If you need the stack or call trace, let me know, and I'll add that. I'm
running the 2.4.0 kernel from rawhide, and it doesn't seem to have helped a
great deal. Will you be upgrading to Linus' 2.4.2 kernel on rawhide?
The stack and call trace would be useful, yes, but only after being
run through the ksymoops program to decode them into symbolic names.
We don't have a position relative to 2.4.2 yet.
Alan Cox reports this as a known bug in the 2.4.x stream at this time.
Makes ksymoops output even more potentially useful now that I know it
hasn't been fixed yet in a more recent kernel...
This is kinda embarrassing, but I've never done a ksymoops before. Can you
walk me through what I need to do? Recreating the problem isn't an issue, it
happens everytime the module is loaded and pump tries to start using it.
if your kernel has survived, "dmesg | ksymoops" will do the right thing usually.
if your system completely locks up, this gets a lot harder.
Looks like this'll be a hard one. The system locks up hard. No capslock,
scroll lock no nothing.
*** Bug 30406 has been marked as a duplicate of this bug. ***
Resolved in later tr drivers in 2.4