On Wed, Jul 27, 2011 at 09:18:20AM +0800, Xu, Andiry wrote: > > -----Original Message----- > > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > > Sent: Wednesday, July 27, 2011 2:47 AM > > To: Xu, Andiry > > Cc: linux-usb@xxxxxxxxxxxxxxx; gregkh@xxxxxxx > > Subject: Re: [PATCH] xHCI: refine td allocation > > > > On Tue, Jul 26, 2011 at 08:34:11AM +0800, Andiry Xu wrote: > > > In xhci_urb_enqueue(), allocate a block of memory for all the TDs > > instead > > > of allocating memory for each of them separately. This reduces the > > number > > > of kzalloc calling when an isochronous usb is submitted. > > > > Hi Andiry, > > > > I've actually been finding a lot of memory leaks and race conditions > in > > the isochronous transfer queueing. I have a box that consistently > > hard-hangs with a certain setup of HS webcams and audio devices when > > xHCI driver debugging is enabled. I'd like to root out those problems > > before we do any optimizations. I'm at a conference this week, so I > > won't be able to finish that bug fix until end of next week. Then we > > can look and see if this patch is useful. Makes sense? > > > > Yeah, please do so. It sounds like a time-related race issue. I have to > admit that I've disabled xHCI driver dubugging for a quite long time. Yes, it is a race condition. It only happens when the driver is enabled to print isoc rings during the cancellation process. > Do you mean xHCI hangs when webcam and audio devices are both plugged? The setup is this: I have a 7 port MTT HS hub, a 4 port MTT HS hub, and a single TT hub. There's two USB-to serial adapters that are plugged into each other, about three mice, and a keyboard, all plugged into the MTT hub. I have a USB audio device (I'm not sure if it's FS or HS) that has music playing out the wireless headphones, and a 720p webcam capturing video at 1600x1200. This basically almost maxes out the USB 2.0 bus bandwidth. When I plug in a 1080p camera, the music stops and the system hard hangs. As far as I can tell, the watchdog timer has fired for the Stop Endpoint command, and the driver assumes the host is dead (probably because it took too long to print the isoc endpoint rings? Or maybe just a bug in this prototype). When the watchdog goes to remove TDs from either the td_list or the cancelled_list, it oopses when it deferences td->urb->hcpriv, several TDs into the list. Now the only places I see hcpriv can be set to NULL and the TD was placed on either TD list is if the isochronous URB was partially enqueued (at least the first TD), and then something went wrong on the Nth TD, which would leave the TD on the td_list. The error handling in the URB enqueueing functions is just a mess (just look at how TDs are leaked if the bulk endpoint is getting streams), so I'm trying to untangle it. > Does it hang when isoc transfer is on-going? Can you give me the device > names and I'll check if I can reproduce it locally. I don't have the lsusb for the setup with me. I can get it to you next week, but it's entirely possible the race condition will only show up on this prototype. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
