On Mon, 10 Dec 2012, Piergiorgio Sartor wrote: > It might be useful. > I tried quickly to put 5 instead of 20, but still > the issue was difficult to reproduce (3.7.0-rc4+). > It happened (again) only after I increased the CPU > (or I/O) load by "make -j5" in "/usr/src/linux". > And even not immediately. > > Of course, it was just a quick test, it could have > been I made some mistakes. Or not. Yeah, it's hard to know how to interpret your result. > > Here's an idea. This just occurred to me. Maybe when the driver is > > waiting for the async schedule to turn off, new QH's should not be > > added to the schedule. The driver could wait and add them after the > > schedule was off. I didn't do it that way because it would slow things > > down and add complexity, but maybe that's what the nVidia hardware > > needs. > > How difficult is it? > Would it be possible to have as a patch I could try? I'm kind of busy these days. Maybe I can do it later this week. The thing is, on the face of it there's no reason why the amount of traffic should have any effect on the time required to turn off the schedule. I once tried looking for errata documents from nVidia about their USB controllers, but I couldn't find anything. > > > More of that, is it "sane" to just increase a timeout > > > in order to workaround the issue? > > > > I don't know. If a small increase in the timeout fixes the problem > > then maybe it is. The problem is that I don't understand exactly what > > causes the bug, so I can't tell the right way to work around it. > > Maybe more verbosity is needed somewhere? The bug is in the hardware. You can't add verbosity to the hardware, unfortunately. > > > Would it be better, after the timeout, to re-try to turn > > > on the async schedule for a couple of times? With some > > > wait inbetween, of course. > > > > I doubt that would work. It would be better to make the timeout > > longer. > > What I mean is that instead of waiting for 500ms > at once, it could be better to wait 50 times 10ms. In fact, right now the driver waits 1 ms 20 times. If you changed the 20 to 500 then it would wait 1 ms 500 times. > As soon as the switch occurs, the system can just > continue. In other words to have a flexible timeout, > instead of a fixed one. > Assuming it is realiably possible to verify the > status of the EHCI hardware. Yes, I think the status value is reliable. 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
