On Wed, 31 Jul 2013, James Stone wrote: > On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 30 Jul 2013, Alan Stern wrote: > > > >> I can try to ameliorate the situation. Although the 7-ms delay will > >> inevitably cause an underrun, it doesn't have to cause errors the way > >> it does now. I'll write a patch to handle this. It may take a few > >> days. > > > > James, see what happens with this patch. It will print a warning > > message in the system log every time it detects an underrun, but it > > won't cause an URB submission failure any more. > > > > OK - I will try it, however, it seems a bit like papering over the > cracks without really understanding what's causing the error.. It seems likely that the error is caused by an SMI taking too much time. At least, we seem to have ruled out everything else. Besides, this change has to be made eventually in any case -- underruns can occur at any time, in principle, and they shouldn't cause the audio driver to fail. By the way, can you post the contents of /proc/interrupts? I'd like to see if the IRQ line in question is shared. > I just managed to induce another cannot submit URB bug, and there is > definitely nothing written to trace around the time of this bug, with > the settings: > > echo 0 > options/function-trace > echo irqsoff > current_tracer > echo 1 > tracing_on > echo 0 > tracing_max_latency You may need to do "echo 0 >tracing_on" before looking at the file. I'm not sure. But the tracer certainly should contain _something_, because interrupts are constantly being disabled and enabled during normal system operation. Even if nothing went wrong, there would still be a nonzero latency. 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
