Bug 28139 - Pump taking kernel panic on TR interface at bootup
Summary: Pump taking kernel panic on TR interface at bootup
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: David Lawrence
URL:
Whiteboard:
: 30406 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-17 14:40 UTC by Bill Stephens
Modified: 2007-04-18 16:31 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-06-09 15:01:07 UTC
Embargoed:


Attachments (Terms of Use)

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




Note You need to log in before you can comment on or make changes to this bug.