Bug 53849 - oops when using 3com 3c996-T gigabit (bcm5700 module) with Tyan Thunder (amd760mp) motherboard S2462NG; rawhide kernel 2.4.9-0.5
oops when using 3com 3c996-T gigabit (bcm5700 module) with Tyan Thunder (amd7...
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-19 16:31 EDT by Matt Ryan
Modified: 2015-01-04 17:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-29 23:42:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Ryan 2001-09-19 16:31:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.7-2 i686)

Description of problem:
I have two Tyan Thunder dual-Athlon machines, each with a 3com gigabit (ie
broadcom) card, connected by a 5e crossover cable.  Running ttcp between
them leads to a kernel oops by either the sender or receiver (which seems
to depend on setup); transferring files with something like scp lead to all
sorts of errror messages.

- behavior is the same for at least the last two rawhide kernels (2.4.7-2.9
and 2.4.9-0.5).  With the 2.4.9 kernel, I tried for reference three
different binary rpms, smp-athlon, smp-i686, and plain old i386 (one cpu).
- the same gigabit cards (and even the same cable) appear to work fine in a
similar setup, two Intel Stl2 dual-pIII machines, on both recent rawhide
kernels.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
steps seem to vary a bit, depending on which exact kernel I run.  here are
steps, results, and oops for with kernel-2.4.9-0.5.i386.rpm:
1. ifup ethx on each machine
2. ttcp -r -s on receiving end; ttcp -t -s -n 50000 on transmitting end
(default -n of 2048 doesn't trigger it).

	

Actual Results:  receiver oopses (with different kernels, I think it was
the transmitter that was oopsing)


Expected Results:  blazing speed

Additional info:

I captured the oops from a serial port. 
'ksymoops -m /boot/System.map-2.4.9-0.5 oops.txt' output:
(I'm not very familiar with using this, let me know if there's something
else I should have done. )

ksymoops 2.4.1 on i686 2.4.9-0.5.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.9-0.5/ (default)
     -m /boot/System.map-2.4.9-0.5 (specified)

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
ksymoops: No such file or directory
/usr/bin/find: /lib/modules/2.4.9-0.5/build: No such file or directory
Error (pclose_local): find_objects pclose failed 0x100
Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base
says c01ae950, System.map says c014fe30.  Ignoring ksyms_base entry
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique
module object.  Trace may not be reliable.
invalid operand: 0000
CPU:    0
EIP:    0010:[<f88d3659>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000005d   ebx: f55f7ab0   ecx: 00000001   edx: 00001916
esi: 000005ea   edi: c1f78140   ebp: f56192e0   esp: c025df20
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c025d000)
Stack: f88dc340 00000313 c1f78e04 c1f78140 c1f78140 f5612ccc c1f7a458
c025dfac
       f88d8f4b c1f78140 c1f78140 04000001 c1f78000 f88d2435 c1f78140
f5b78640
       04000001 0000000a c0107f85 0000000a c1f78000 c025dfac c025dfac
0000000a
Call Trace: [<f88dc340>] [<f88d8f4b>] [<f88d2435>] [<c0107f85>]
[<c01080d4>]
   [<c0105344>] [<c0214e2c>] [<c0105344>] [<c0105367>] [<c01053ce>]
[<c0105000>]
Code: 0f 0b 5a 59 89 f0 03 83 84 00 00 00 01 73 5c 3b 83 88 00 00
 
>>EIP; f88d3659 <[bcm5700]MM_IndicateRxPackets+8d/1b4>   <=====
Trace; f88dc340 <[bcm5700].LC22+0/3>
Trace; f88d8f4b <[bcm5700]LM_ServiceInterrupts+293/2b0>
Trace; f88d2435 <[bcm5700]bcm5700_interrupt+dd/1c0>
Trace; c0107f85 <handle_IRQ_event+35/5c>
Trace; c01080d4 <do_IRQ+60/9c>
Trace; c0105344 <default_idle+0/28>
Trace; c0214e2c <call_do_IRQ+5/d>
Trace; c0105344 <default_idle+0/28>
Trace; c0105367 <default_idle+23/28>
Trace; c01053ce <cpu_idle+42/58>
Trace; c0105000 <_stext+0/0>
Code;  f88d3659 <[bcm5700]MM_IndicateRxPackets+8d/1b4>
00000000 <_EIP>:
Code;  f88d3659 <[bcm5700]MM_IndicateRxPackets+8d/1b4>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  f88d365b <[bcm5700]MM_IndicateRxPackets+8f/1b4>
   2:   5a                        pop    %edx
Code;  f88d365c <[bcm5700]MM_IndicateRxPackets+90/1b4>
   3:   59                        pop    %ecx
Code;  f88d365d <[bcm5700]MM_IndicateRxPackets+91/1b4>
   4:   89 f0                     mov    %esi,%eax
Code;  f88d365f <[bcm5700]MM_IndicateRxPackets+93/1b4>
   6:   03 83 84 00 00 00         add    0x84(%ebx),%eax
Code;  f88d3665 <[bcm5700]MM_IndicateRxPackets+99/1b4>
   c:   01 73 5c                  add    %esi,0x5c(%ebx)
Code;  f88d3668 <[bcm5700]MM_IndicateRxPackets+9c/1b4>
   f:   3b 83 88 00 00 00         cmp    0x88(%ebx),%eax
 
 <0>Kernel panic: Aiee, killing interrupt handler!
 
2 warnings and 3 errors issued.  Results may not be reliable.

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