See attached file for details.
Description: Kernel oops when unplugging the usb cable of an active usb device.
It has some explanations of the "uhci.c-oops" attachment, together with extract from the source code identifying the oops position, together with the ksymoops output from the oops.


Can anyone help?
The reason I need this fixed is that there are certain audio devices out there that disconnect themselves from the usb bus without the user knowing, so it is up to the kernel to remove the device from it's tables gracefully without oops.


Cheers
James
This is produced by using an audio usb device, with alsa driving it.
One starts playing some music to the usb device, and while it it playing one 
disconnects the usb cable. It does not happen every time, but enough times to make it 
annoying.
The "Tainted: P" is due to nvidia video card driver nvidia.o.
The mh2 is standard 2.4.21 kernel from kernel.org with bluetooth patches from 
http://bluez.sf.net.
Extract from uhci.c for where oops takes place with location of OOPS identified :-
static void uhci_interrupt(int irq, void *__uhci, struct pt_regs *regs)
{
        struct uhci *uhci = __uhci;
        unsigned int io_addr = uhci->io_addr;
        unsigned short status;
        struct list_head *tmp, *head;

        /*
         * Read the interrupt status, and write it back to clear the
         * interrupt cause
         */
        status = inw(io_addr + USBSTS);
        if (!status)    /* shared interrupt, not mine */
                return;
        outw(status, io_addr + USBSTS);         /* Clear it */

        if (status & ~(USBSTS_USBINT | USBSTS_ERROR | USBSTS_RD)) {
                if (status & USBSTS_HSE)
                        err("%x: host system error, PCI problems?", io_addr);
                if (status & USBSTS_HCPE)
                        err("%x: host controller process error. something bad 
happened", io_addr);
                if ((status & USBSTS_HCH) && !uhci->is_suspended) {
                        err("%x: host controller halted. very bad", io_addr);
                        /* FIXME: Reset the controller, fix the offending TD */
                }
        }

        if (status & USBSTS_RD)
                wakeup_hc(uhci);

        uhci_free_pending_qhs(uhci);

        uhci_remove_pending_qhs(uhci);

        uhci_clear_next_interrupt(uhci);

        /* Walk the list of pending URB's to see which ones completed */
        spin_lock(&uhci->urb_list_lock);
        head = &uhci->urb_list;
        tmp = head->next;
        while (tmp != head) {
                struct urb *urb = list_entry(tmp, struct urb, urb_list);

/* THIS IS WHERE THE OOPS HAPPENS!!! */
                tmp = tmp->next;  /* THIS IS WHERE THE OOPS HAPPENS!!! */

                /* Checks the status and does all of the magic necessary */
                uhci_transfer_result(uhci, urb);
        }
        spin_unlock(&uhci->urb_list_lock);

        uhci_finish_completion(uhci);
}

Last kernel message before oops: -
usb.c: USB disconnect on device 00:07.2-1.2 address 11

ksymoops 2.4.8 on i686 2.4.21-mh2.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.21-mh2/ (default)
     -m /boot/System.map-2.4.21-mh2 (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.

status: (1E) 0x48, (1F) 0xc0
cpu: 0, clocks: 100216, slice: 50108
Unable to handle kernel paging request at virtual address 5a5a5a5a
c890a0f3
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c890a0f3>]    Tainted: P 
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010a87
eax: 5a5a5a56   ebx: 5a5a5a5a   ecx: c6ac4000   edx: c6ac5f7c
esi: c7f829ac   edi: c7f82a18   ebp: c0dede80   esp: c0dede6c
ds: 0018   es: 0018   ss: 0018
Process artsd (pid: 1485, stackpage=c0ded000)
Stack: c7f829ac c05f3dcc c77d16a4 04000001 c0dedecc c0dedea0 c0108968 0000000a 
       c7f829ac c0dedecc c02b5a40 0000000a c77d16a4 c0dedec4 c0108b23 0000000a 
       c0dedecc c77d16a4 00000140 c1cb2008 c1cb2008 00000000 c0dedf14 c010b0a8 
Call Trace:    [<c0108968>] [<c0108b23>] [<c010b0a8>] [<c9d10018>] [<c0133591>]
  [<c01482e4>] [<c01485b7>] [<c01489ed>] [<c010740f>]
Code: 8b 1b 89 44 24 04 89 34 24 e8 2f ef ff ff 39 fb 75 eb 89 75 


>>EIP; c890a0f3 <[uhci]uhci_interrupt+83/100>   <=====

>>ecx; c6ac4000 <_end+67e1240/85f42a0>
>>edx; c6ac5f7c <_end+67e31bc/85f42a0>
>>esi; c7f829ac <_end+7c9fbec/85f42a0>
>>edi; c7f82a18 <_end+7c9fc58/85f42a0>
>>ebp; c0dede80 <_end+b0b0c0/85f42a0>
>>esp; c0dede6c <_end+b0b0ac/85f42a0>

Trace; c0108968 <handle_IRQ_event+48/80>
Trace; c0108b23 <do_IRQ+83/e0>
Trace; c010b0a8 <call_do_IRQ+5/d>
Trace; c9d10018 <[snd-pcm]snd_pcm_free_stream+28/70>
Trace; c0133591 <free_pages+1/30>
Trace; c01482e4 <poll_freewait+44/50>
Trace; c01485b7 <do_select+107/200>
Trace; c01489ed <sys_select+2fd/4a0>
Trace; c010740f <system_call+33/38>

Code;  c890a0f3 <[uhci]uhci_interrupt+83/100>
00000000 <_EIP>:
Code;  c890a0f3 <[uhci]uhci_interrupt+83/100>   <=====
   0:   8b 1b                     mov    (%ebx),%ebx   <=====
Code;  c890a0f5 <[uhci]uhci_interrupt+85/100>
   2:   89 44 24 04               mov    %eax,0x4(%esp,1)
Code;  c890a0f9 <[uhci]uhci_interrupt+89/100>
   6:   89 34 24                  mov    %esi,(%esp,1)
Code;  c890a0fc <[uhci]uhci_interrupt+8c/100>
   9:   e8 2f ef ff ff            call   ffffef3d <_EIP+0xffffef3d>
Code;  c890a101 <[uhci]uhci_interrupt+91/100>
   e:   39 fb                     cmp    %edi,%ebx
Code;  c890a103 <[uhci]uhci_interrupt+93/100>
  10:   75 eb                     jne    fffffffd <_EIP+0xfffffffd>
Code;  c890a105 <[uhci]uhci_interrupt+95/100>
  12:   89 75 00                  mov    %esi,0x0(%ebp)

 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.

Reply via email to