On Sun, Jun 22, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote: > On Tuesday 10 June 2003 19:18, Alan Stern wrote: > > On Tue, 10 Jun 2003, Duncan Sands wrote: > > > I've tracked it down to the following: the first of two queued urbs > > > completes, and the HC detects a problem in the following stretch of code > > > in uhci_irq: > > I have tracked the problem down further. What happens is that the > host controller is still reading a TD when uhci_free_td is called on it. > uhci_free_td calls pci_pool_free, which (because slab debugging > is turned on) does > memset (vaddr, POOL_POISON_FREED, pool->size); > This causes the host controller to barf, doubtless because it was > reading that TD when it got poisoned. > > In summary: > (1) I get > e400: host controller process error. something bad happened > e400: host controller halted. very bad > when queuing multiple urbs to an endpoint (2.5 kernels). > (2) What happens is: > uhci_irq -> > uhci_finish_completion -> > uhci_finish_urb -> > uhci_destroy_urb_priv -> > uhci_free_td -> > pci_pool_free: > memset (vaddr, POOL_POISON_FREED, pool->size); > > Now to find out why that TD is still in use...
Interesting. That path should mean that the URB is finished and that the HC shouldn't be reading the TD anymore. Does this only happen with IN transfers? Perhaps only when the read is short? I'll need to look at the code, but maybe we don't wait the necessary frame after updating the qh before we start freeing the TDs for the URB we just completed. Hmm, off to read the sources. JE ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
