Bug 28139

Summary: Pump taking kernel panic on TR interface at bootup
Product: [Retired] Red Hat Linux Reporter: Bill Stephens <bill.stephens>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.1CC: alan
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-09 15:01:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bill Stephens 2001-02-17 14:40:56 UTC
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).

Reproducible: Always
Steps to Reproduce:
1.Install beta
2.Select DHCP for token ring adapter
3.boot up.

	

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.

Comment 1 Bill Stephens 2001-02-22 18:48:15 UTC
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 
wrong:
*pde = 0728d001
*pte = 00000000
Ooops:0000
CPU: 1

EIP:0010:[<00000000>]
eflags: 000010246
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?


Comment 2 Michael K. Johnson 2001-02-22 19:18:09 UTC
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.

Comment 3 Michael K. Johnson 2001-02-22 19:36:47 UTC
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...

Comment 4 Bill Stephens 2001-02-22 19:43:11 UTC
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.

Comment 5 Arjan van de Ven 2001-02-23 12:41:17 UTC
if your kernel has survived, "dmesg | ksymoops" will do the right thing usually.
if your system completely locks up, this gets a lot harder.

Comment 6 Bill Stephens 2001-02-23 17:15:41 UTC
Looks like this'll be a hard one.  The system locks up hard.  No capslock, 
scroll lock no nothing.

Comment 7 Michael K. Johnson 2001-03-05 17:52:58 UTC
*** Bug 30406 has been marked as a duplicate of this bug. ***

Comment 8 Alan Cox 2003-06-09 15:01:07 UTC
Resolved in later tr drivers in 2.4