Bug 28931
Summary: | 3c90x & Dell PWS330 cause kernel panic. | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Dan Taylor <daniel_a_taylor> |
Component: | kernel | Assignee: | Michael K. Johnson <johnsonm> |
Status: | CLOSED DEFERRED | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | fred_treasure, john_hull, mick_tantasirikorn, shane_painter |
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: | 2001-02-27 19:18:52 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
Dan Taylor
2001-02-22 22:07:15 UTC
The kernel panic (run through ksymoops) could be useful. 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------------
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---------------
Giving 3com the ability to view this report... We (Red Hat) should really try to resolve this before next release. 3c90x driver not currently in our kernel build |