Bug 28931 - 3c90x & Dell PWS330 cause kernel panic.
3c90x & Dell PWS330 cause kernel panic.
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-22 17:07 EST by Dan Taylor
Modified: 2007-04-18 12:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-27 14:18:52 EST
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 Dan Taylor 2001-02-22 17:07:15 EST
When testing 3c90x module on Dell PWS330, it has kernel panic.  3c59x was 
originally loaded.  Removed from /etc/modules.conf. ifdown. rmmod 3c59x. 
modprobe 3c90x. Module gives this error:
----------
[root@localhost /root]# modprobe 3c90x
Note: /etc/modules.conf is more recent than /lib/modules/2.4.1-
0.1.9/modules.depWarning: /lib/modules/2.4.1-
0.1.9/kernel/drivers/net/3c90x.o parameter switchdelay has max < min!
3Com 3c90x Version 1.0.0i 1999 <linux_drivers@3com.com>
----------
module does load though.  At this point ifup returns ok.  No eth0 in 
ifconfig.  ifup again & kernel panic (/var/log/messages right before)
----------
Feb 22 14:18:42 localhost pumpd[558]: disabling interface eth0
Feb 22 14:18:42 localhost pumpd[558]: terminating as there are no more 
devices under management
Feb 22 14:18:51 localhost /etc/hotplug/net.agent: unregister event not 
supported
Feb 22 14:19:03 localhost kernel: 3Com 3c90x Version 1.0.0i 1999 
<linux_drivers@3com.com>
Feb 22 14:19:03 localhost /etc/hotplug/net.agent: register event not 
handled
Feb 22 14:19:03 localhost pumpd[3476]: starting at (uptime 0 days, 
3:54:17) Thu Feb 22 14:19:03 2001  
Feb 22 14:19:08 localhost pumpd[3476]: configured interface eth0
Feb 22 14:19:16 localhost pumpd[3476]: configured interface eth0
Feb 22 14:19:16 localhost pumpd[3476]: failed to set default route: 
Network is unreachable
Feb 22 14:25:19 localhost syslogd 1.4-0: restart.
-----------

The current default driver 3c59x works without problems.  Just want to 
make sure this stays the default for this pci id (per t.nix).

vendorId: 10b7
deviceId: 9200
subVendorId: 1028
subDeviceId: 00d2
Comment 1 Bill Nottingham 2001-02-22 17:14:29 EST
The kernel panic (run through ksymoops) could be useful.
Comment 2 Dan Taylor 2001-02-23 09:53:17 EST
I had to manually copy this... I believe it to be correct:
----------------------------------------------------------
printing eip:
c01c0202
*pde = 00000000
Oops: 0002
CPU:	0
EIP:	0010:[<c01c0202>]
EFLAGS:	00010046
eax:  00000000   ebx:  f7261760   ecx:  00000293   edx:  00000000
esi:  00000000   edi:  ecc89800   ebc:  ecc89c00   esp:  c0261f18
ds:  0018   es:  0018   ss:  0018
Process swapper (pid:0, stackpage=c0261000)
Stack:  c01bde87 f7261440 f72501e0 ec2e8810 f7261440 f72501e0 fd9a1da0 f7261760
	ec2e8812 ecc89800 00000400 ecc89c00 0000000b c0261fa8 fd9a2c59 ecc89c00
	01000000 ece37bc0 24000001 c010a2ea 0000000b ecc89800 c0261fa8 c0261fa8
Call Trace: [<c01bde87>] [<fd9a1da0>] [<fd9a2c59>] [<c010a2ea>] [<c010a468>] 
[<c0107240>]  [<c01090b0>] 
	    [<c0107240>] [<c0107263>] [<c01072e2>] [<c0105000>] [<c0100191>]

Code: ff 80 d4 00 00 00 b8 e0 f6 29 c0 83 c0 0c 89 43 08 8b 50 04
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

--------------End-----------------

Here are the results of 'ksymoops oops.file'

--------------Begin---------------
ksymoops 2.4.0 on i686 2.4.1-0.1.9.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.1-0.1.9/ (default)
     -m /boot/System.map-2.4.1-0.1.9 (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/aic7xxx.o) for aic7xxx
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says 
c01b0600, System.map says c01524a0.  Ignoring ksyms_base entry
Warning (map_ksym_to_module): cannot match loaded module aic7xxx to a unique 
module object.  Trace may not be reliable.
c01c0202
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c01c0202>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax:  00000000   ebx:  f7261760   ecx:  00000293   edx:  00000000
esi:  00000000   edi:  ecc89800   ebc:  ecc89c00   esp:  c0261f18
ds:  0018   es:  0018   ss:  0018
Process swapper (pid:0, stackpage=c0261000)
Stack:  c01bde87 f7261440 f72501e0 ec2e8810 f7261440 f72501e0 fd9a1da0 f7261760
        ec2e8812 ecc89800 00000400 ecc89c00 0000000b c0261fa8 fd9a2c59 ecc89c00
        01000000 ece37bc0 24000001 c010a2ea 0000000b ecc89800 c0261fa8 c0261fa8
Call Trace: [<c01bde87>] [<fd9a1da0>] [<fd9a2c59>] [<c010a2ea>] [<c010a468>] 
[<c0107240>]  [<c01090b0>] 
            [<c0107240>] [<c0107263>] [<c01072e2>] [<c0105000>] [<c0100191>]
Code: ff 80 d4 00 00 00 b8 e0 f6 29 c0 83 c0 0c 89 43 08 8b 50 04

>>EIP; c01c0202 <netif_rx+42/e0>   <=====
Trace; c01bde87 <alloc_skb+e7/190>
Trace; fd9a1da0 <[3c59x]boomerang_rx+160/410>
Trace; fd9a2c59 <[3c59x]mtu+2d5/650>
Trace; c010a2ea <handle_IRQ_event+3a/70>
Trace; c010a468 <do_IRQ+68/b0>
Trace; c0107240 <default_idle+0/30>
Trace; c01090b0 <ret_from_intr+0/20>
Trace; c0107240 <default_idle+0/30>
Trace; c0107263 <default_idle+23/30>
Trace; c01072e2 <cpu_idle+52/70>
Trace; c0105000 <empty_bad_page+0/1000>
Trace; c0100191 <L6+0/2>
Code;  c01c0202 <netif_rx+42/e0>
00000000 <_EIP>:
Code;  c01c0202 <netif_rx+42/e0>   <=====
   0:   ff 80 d4 00 00 00         incl   0xd4(%eax)   <=====
Code;  c01c0208 <netif_rx+48/e0>
   6:   b8 e0 f6 29 c0            mov    $0xc029f6e0,%eax
Code;  c01c020d <netif_rx+4d/e0>
   b:   83 c0 0c                  add    $0xc,%eax
Code;  c01c0210 <netif_rx+50/e0>
   e:   89 43 08                  mov    %eax,0x8(%ebx)
Code;  c01c0213 <netif_rx+53/e0>
  11:   8b 50 04                  mov    0x4(%eax),%edx

Kernel panic: Aiee, killing interrupt handler!

4 warnings and 3 errors issued.  Results may not be reliable.
------------End------------
Comment 3 Dan Taylor 2001-02-23 09:59:43 EST
Perhaps it would be better if I had the failing module loaded?
-----------Begin-------------
>>EIP; c01c0202 <netif_rx+42/e0>   <=====
Trace; c01bde87 <alloc_skb+e7/190>
Trace; fd9a1da0 <[3c90x]tc90x_UpCompleteEvent+170/1e0>
Trace; fd9a2c59 <[3c90x]NICInterrupt+99/120>
Trace; c010a2ea <handle_IRQ_event+3a/70>
Trace; c010a468 <do_IRQ+68/b0>
Trace; c0107240 <default_idle+0/30>
Trace; c01090b0 <ret_from_intr+0/20>
Trace; c0107240 <default_idle+0/30>
Trace; c0107263 <default_idle+23/30>
Trace; c01072e2 <cpu_idle+52/70>
Trace; c0105000 <empty_bad_page+0/1000>
Trace; c0100191 <L6+0/2>
Code;  c01c0202 <netif_rx+42/e0>
00000000 <_EIP>:
Code;  c01c0202 <netif_rx+42/e0>   <=====
   0:   ff 80 d4 00 00 00         incl   0xd4(%eax)   <=====
Code;  c01c0208 <netif_rx+48/e0>
   6:   b8 e0 f6 29 c0            mov    $0xc029f6e0,%eax
Code;  c01c020d <netif_rx+4d/e0>
   b:   83 c0 0c                  add    $0xc,%eax
Code;  c01c0210 <netif_rx+50/e0>
   e:   89 43 08                  mov    %eax,0x8(%ebx)
Code;  c01c0213 <netif_rx+53/e0>
  11:   8b 50 04                  mov    0x4(%eax),%edx

Kernel panic: Aiee, killing interrupt handler!

4 warnings and 3 errors issued.  Results may not be reliable.
-------------End---------------
Comment 4 Michael K. Johnson 2001-02-23 12:42:51 EST
Giving 3com the ability to view this report...
Comment 5 Glen Foster 2001-02-23 16:55:25 EST
We (Red Hat) should really try to resolve this before next release.
Comment 6 Michael K. Johnson 2001-02-28 23:31:12 EST
3c90x driver not currently in our kernel build

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