On Wed, 16 Jul 2003, Charles Lepple wrote:
> Alan Stern said:
> > This is a problem in uhci-hcd. A struct urbp (private data structure) is
> > being accessed after it has been freed. More specifically, the list of
> > unlinked URBs (uhci->urb_remove_list) has been corrupted: it points to a
> > deallocated urbp. It would be nice to know how this could happen.
>
> CONFIG_DEBUG_SLAB=y
>
> Should I set CONFIG_DEBUG_PAGEALLOC as well? (Sorry, I'm not completely up
> to speed on the new memory debugging options.)
No, I don't think that would help. The problem isn't with the allocation
and freeing, it's the order in which the uhci driver does them and the
lists that it uses.
> > The function uhci_destroy_urb_priv() -- which is the only place these
> > things are deallocated -- should print out a warning message if an urbp is
> > still on that list. But that only happens if you have configured USB
> > debugging in your kernel.
>
> This is what I see on the console after a number of tests with firmware
> loaded:
>
> drivers/usb/misc/usbtest.c: control queue 81.0a, err -121, 31997 left
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706ff1c still on
> uhci->urb_list or uhci->remove_list
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706f3b8 still on
> uhci->urb_list or uhci->remove_list
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706f34c still on
> uhci->urb_list or uhci->remove_list
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706f2e0 still on
> uhci->urb_list or uhci->remove_list
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706fd6c still on
> uhci->urb_list or uhci->remove_list
> drivers/usb/host/uhci-hcd.c: uhci_destroy_urb_priv: urb c706fc28 still on
> uhci->urb_list or uhci->remove_list
>
> Without firmware, the list is similar, but about half as long. I'll try
> and turn on USB debugging and see what I come up with.
Those messages are what I meant. They clearly show that the driver has
detected an invalid internal state.
> > If you haven't done that, try running the test again with USB debugging
> > on. Or if you already have, look through the system log for messages from
> > the uhci driver.
>
> Will do. Isn't there a sysfs node that correlates the URB addresses with
> how they were submitted? Or any other sort of UHCI debugging info? Maybe
> I'm imagining things.
There ought to be /proc/driver/uhci/...
> I was going to try and eliminate my board construction as one of the
> variables, but I can't seem to locate my Keyspan serial adapters at the
> moment. Can anyone with a recent 2.5.x/2.6test kernel, a Keyspan adapter
> and UHCI try to reproduce this as well?
>
> When I remembered to load the firmware, the worst that happened was that
> the usbtest process went out for a long lunch break (but it responded to
> signals). The kernel panics happened when I didn't load firmware.
It might be that the problem is triggered by a particular pattern of URBs
being unlinked and completed. The exact timing may matter as well.
Anyway, this bug shouldn't occur no matter what hardware or firmware you
use.
The patch below will log some additional debugging information. It might
help pinpoint where things go wrong during your test. Unfortunately, it
will generate a good deal of output even when things go right. Try to
run just the test that produced the error messages above and post the
corresponding part of the kernel log.
Alan Stern
===== uhci-hcd.c 1.53 vs edited =====
--- 1.53/drivers/usb/host/uhci-hcd.c Wed Jul 2 12:28:41 2003
+++ edited/drivers/usb/host/uhci-hcd.c Wed Jul 16 14:26:26 2003
@@ -135,6 +135,7 @@
spin_lock_irqsave(&uhci->complete_list_lock, flags);
list_add_tail(&urbp->complete_list, &uhci->complete_list);
+ printk(KERN_INFO "uhci: added urbp %p to complete_list\n", urbp);
spin_unlock_irqrestore(&uhci->complete_list_lock, flags);
}
@@ -727,6 +728,7 @@
urb->hcpriv = NULL;
kmem_cache_free(uhci_up_cachep, urbp);
+ printk(KERN_INFO "uhci: freed urbp %p\n", urbp);
}
static void uhci_inc_fsbr(struct uhci_hcd *uhci, struct urb *urb)
@@ -1658,6 +1660,7 @@
if (list_empty(&uhci->urb_remove_list))
uhci_set_next_interrupt(uhci);
list_add(&urbp->urb_list, &uhci->urb_remove_list);
+ printk(KERN_INFO "uhci: added urbp %p to remove_list\n", urbp);
spin_unlock(&uhci->urb_remove_list_lock);
spin_unlock_irqrestore(&uhci->urb_list_lock, flags);
@@ -1833,6 +1836,7 @@
struct urb *urb = urbp->urb;
list_del_init(&urbp->complete_list);
+ printk(KERN_INFO "uhci: took urbp %p off complete_list\n", urbp);
spin_unlock_irqrestore(&uhci->complete_list_lock, flags);
uhci_finish_urb(hcd, urb, regs);
@@ -1859,6 +1863,7 @@
tmp = tmp->next;
list_del_init(&urbp->urb_list);
+ printk(KERN_INFO "uhci: took urbp %p off remove_list\n", urbp);
urbp->status = urb->status = -ECONNRESET;
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
