|
I just upgraded to pcmcia-cs 3.1.9 (precompiled Debian "woody" version), which has fixed earlier problems I had with pcmcia, but which Oopses whenever the card is ejected, cardctl eject is called, or the system shuts down/reboots.
I'm not sure if I had this problem before, since I was pretty much happy to have the card _not_ lock the system solid (which it frequently did with pcmcia-cs 3.1.8), and didn't bother to check the kernel logs much once things were up and running :) The system is a Dell Latitude CPtV466GT running Debian "potato" (aka "frozen") with kernel 2.2.14 plus the ext3 patch, the international kernel patch, and the 2.3.39 USB backport. The output of ksymoops is as follows:
ksymoops 2.3.3 on i686 2.2.14ext3. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.14ext3/ (default)
-m /boot/System.map-2.2.14ext3 (specified)
Unable to handle kernel paging request at virtual address 5a5a5ab6
current->tss.cr3 = 06f90000, %cr3 = 06f90000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c80575f2>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 5a5a5a5a ebx: c0233800 ecx: 5a5a5a5a edx: c80599fc
esi: c80599fc edi: c8052000 ebp: c6f8ff3c esp: c6f8ff2c
ds: 0018 es: 0018 ss: 0018
Process rmmod (pid: 584, process nr: 36, stackpage=c6f8f000)
Stack: 00004000 c7e11ee0 0000000c c011ba98 c6f8ff6c c805790e c8059be8 00000000
c6fbb150 c0116d73 c8052000 fffffff0 c7144180 08054006 00000000 c6f8e000
bfffecac c0117130 c8052000 fffffff0 c6f8ffb0 bfffecac c4b77000 fffffffe
Call Trace: [<c011ba98>] [<c805790e>] [<c8059be8>] [<c0116d73>] [<c8052000>] [<c0117130>] [<c8052000>]
[<c0116775>] [<c8052000>] [<c0116737>] [<c010a041>] [<c0109f3c>]
Code: 8b 59 5c 8d 53 0c 8a 83 72 05 00 00 24 03 3c 02 75 29 83 c4
>>EIP; c80575f2 <[tulip_cb]tulip_reap+2e/78> <===== Trace; c011ba98 <handle_mm_fault+c8/13c> Trace; c805790e <[tulip_cb]cleanup_module+1a/84> Trace; c8059be8 <[tulip_cb]tulip_ops+0/13> Trace; c0116d73 <qm_info+9f/b8> Trace; c8052000 <[tulip_cb]__module_kernel_version+0/1a> Trace; c0117130 <free_module+20/a8> Trace; c8052000 <[tulip_cb]__module_kernel_version+0/1a> Trace; c0116775 <sys_delete_module+13d/1ec> Trace; c8052000 <[tulip_cb]__module_kernel_version+0/1a> Trace; c0116737 <sys_delete_module+ff/1ec> Trace; c010a041 <error_code+2d/34> Trace; c0109f3c <system_call+34/38> Code; c80575f2 <[tulip_cb]tulip_reap+2e/78> 00000000 <_EIP>: Code; c80575f2 <[tulip_cb]tulip_reap+2e/78> <===== 0: 8b 59 5c mov 0x5c(%ecx),%ebx <===== Code; c80575f5 <[tulip_cb]tulip_reap+31/78> 3: 8d 53 0c lea 0xc(%ebx),%edx Code; c80575f8 <[tulip_cb]tulip_reap+34/78> 6: 8a 83 72 05 00 00 mov 0x572(%ebx),%al Code; c80575fe <[tulip_cb]tulip_reap+3a/78> c: 24 03 and $0x3,%al Code; c8057600 <[tulip_cb]tulip_reap+3c/78> e: 3c 02 cmp $0x2,%al Code; c8057602 <[tulip_cb]tulip_reap+3e/78> 10: 75 29 jne 3b <_EIP+0x3b> c805762d <[tulip_cb]tulip_reap+69/78> Code; c8057604 <[tulip_cb]tulip_reap+40/78> 12: 83 c4 00 add $0x0,%esp I've managed to parse the disassembled output enough to figure out that the kernel oopses in tulip_reap() while trying to dereference (*devp)->priv on line 3459 of tulip_cb.c, which might mean that root_tulip_dev is invalid, but I don't know how to debug the kernel so I can't find out :) What I _do_ know is that tulip_reap is called twice; once while loading the module, and once while cleaning up after it (I get the "tulip_reap()" message twice in my kernel log). The first invocation works fine, obviously. Since I don't usually eject the network card once I've inserted it this isn't really a big deal for me, but I'd be happy to provide my configuration, log messages etc. if anyone wants to take a harder look at it.
|
Messages