> > On Sun, Jul 15, 2012 at 11:41:33PM +0100, Ben Hutchings wrote: > > Hi, > > > I assume you mean this patch: > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=65;filename=0001- > usb-Fix-deadlock-in-hid_reset-when-Dell-iDRAC.patch;att=1;bug=670398> > > so I'll apply that. > > Exactly, that would be great. > > > > It won't be accepted into a 2.6.32.y release unless someone can > explain > > how it was fixed upstream (ideally, which commit(s) fixed it). > > I think it was somewhere mentioned that it got fixed with some USB-HID > rewrite > in 2.6.36 or 2.6.37. We could not reproduce it with Linux 3.2 from > backports > and internal builds of 2.6.37. But I can see that this isn't a proper > explanation or reason for an inclusion upstream. > > Sven >
I believe this was fixed with changes to the kernel workqueue code (in 2.6.36, I believe). In older kernels, the kernel workqueue would run one queued item at a time, and wait for it to finish before running the next one. The function hid_reset() is running on keventd (the workqueue). When a transaction run by hid_reset() gets a timeout trying to talk to the iDRAC, it puts hub_tt_work() on the workqueue to be run by keventd (by calling schedule_work(&tt->clear_work)) and waits for it to finish. But keventd is waiting for hid_reset() to finish before it will run hub_tt_work(). So deadlock. Later kernels don't wait for each item on the workqueue to finish before starting the next, as I recall. Stuart -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/959d45574d89af41a9dadf6f446a2e9a2aef6f1...@ausx7mcps310.amer.dell.com
