On Thu, 9 Feb 2012, Dave Jones wrote: > > It's worth noting that all three stack traces show the bad clear_halt > > coming from a user program called "hp". Whatever that program is, it > > appears to be doing something stupid -- and changing the kernel won't > > help. > > https://bugzilla.redhat.com/show_bug.cgi?id=787533 now has a usbmon > log attached. For whatever reason, the usbmon log doesn't show any clear_halt requests. I have no idea why not. Did the problem reoccur while the log was being recorded? > It seems that 'hp' comes from the hplip package. > I'm completely unfamiliar with any of the printing code, but at least > we have the source for this, so if it does turn out to be dumb userspace, > we could feasibly get it fixed. I took a look at the source code for the hplip package. In io/hpmud/musb.c, the musb_raw_channel_close() routine always calls usb_clear_halt() for each bulk-in and bulk-out endpoint that it uses, whether the endpoint needs it or not. If one of those endpoints had a read or write going on in another thread at the same time, the usb_clear_halt() call would cause the WARN to trigger. It's hard to tell exactly what the program is doing. You'd think that all I/O to a printer would be serialized, and ongoing reads or writes would be completed before anything was closed. But the use of multiple threads and callback routines makes the code difficult to follow. Anyway, removing those usb_clear_halt() calls would most likely eliminate the problem. Of course, they might be needed for some printers. Still, it's best not to clear a halted endpoint until you know that it is halted, and then it is best to clear the halt condition right away instead of waiting until some I/O channel is closed. Alan Stern -- 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
