On Sat, 26 Apr 2014, Dennis New wrote: > On Fri, 25 Apr 2014 16:54:29 -0400 (EDT), Alan Stern wrote: > > All right, here's a slightly different version of the patch. This one > > should shut down the controller entirely when the problem occurs and > > the frame pointer stops. > > > > After another week or so, I'll expect to see your next report... > > So, it happened again, barely a day since I applied the patch. This > time I got an interesting irq kernel call trace, involving > "__report_bad_irq.isra": > > http://dennisn.linuxd.org/guest/pubstuff/debug-usbaudio/crash7.log Ah. Evidently the controller didn't get reset as fully as it should have. Not surprising that this didn't work; I can't remember anybody ever encountering a situation like this, so that "controller died" code has probably never been tested. I'll try to simulate your situation on my own machine to carry out more thorough testing. > Not sure if it's relevant, but from the "registers" debugging file, I > also noticed that this time the "fmremaining" and "FR" values were not > changing over time, and the "FRT" tag is not there. Those are unimportant values; you can ignore them. The main reason for the difference is that before the controller was still partially running, but the new patch resets it, causing it to stop. > Also not sure if it's relevant, but the devices are still able to get > power when they're in this crashed/unresponsive state. And also, I > haven't (yet) been able to reproduce this bug with a 4-port hub that I > started to use. But we'll see how long that claim lasts. The USB hardware found in most desktop and laptop computers is not capable of turning off power to the ports. 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
