On Friday 10 July 2009, Ian Lynagh wrote: > [582730.178212] kernel BUG at .../drivers/usb/host/ehci-mem.c:74! Note that this is a *SECONDARY* failure ... the endpoint hardware is still in use, but it should have been shut down already. So the interesting question is: what was the *PRIMARY* failure? So I'd suggest that the WLAN device driver has at least three bugs: 1 The error logging should use dev_err() etc so that it shows which USB device it came from; "phy0 -> rt2x00usb_vendor_request" etc just leaves us guessing. 2 The first one, which prevented it from working and caused all the syslog spam that wasn't triggered by seeming bugs in userspace code (those "derefnull" and "divbyzero" utils, also "ghc"); presumably the PHY code is at least one issue. Maybe it's just mis-handling something at high speed... 3 The driver's likely doing *something wrong* in disconnect(). Maybe returning while a control message is outstanding; that might cause the above BUG(), ISTR there was a hole of that shape in the USB stack a few years ago. I'm skeptical that the BUG() above would trigger without a driver first misbehaving. This is not a common BUG(); something else made it happen. My guess is #3 above. The first two seem very apparent just from looking at the syslog data provided. - Dave -- 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
