On Wed, 31 Jul 2013, James Stone wrote: > > 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. > > Yep - that makes sense. But has there been a change in SMI timings > with the new kernel? SMIs are controlled by the BIOS, not by the kernel. I don't think changing the kernel would affect their timings. > I don't think this bug happened with earlier > kernels. It depends on what you mean. The underruns almost certainly did occur with earlier kernels. But they didn't cause failures, so you weren't aware of them. > Oh, by the way, should I be adding anything to #1191603 > seeing as this (non-realtime) bug seems to be the same one everyone > else is complaining about? It's up to you. Bear in mind that your problems have involved three or four other bugs in addition. > > By the way, can you post the contents of /proc/interrupts? I'd like to > > see if the IRQ line in question is shared. > > > CPU0 CPU1 CPU2 CPU3 > 17: 5261388 0 1 104 IO-APIC-fasteoi > ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3 > 18: 0 52 26049 408 IO-APIC-fasteoi > ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 Okay, so the USB controllers do share IRQ lines. Were you using the other USB buses when the errors occurred? > >> 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. > > > > I don't think that's necessary - it seems to update the file without this. All right. > > 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. > > Yes - there was something - from recollection it was some firefox > process with a latency of 2000us, but what I meant is that nothing new > seemed to be written at the time the bug happened. That's to be expected. The tracer records the _longest_ time that interrupts were disabled. When the bug happened, interrupts were disabled for a long time, but it may not have been the longest up to that point. > The file now has: > cc1-21060 2d.h. 0us!: local_clock <-perf_event_update_userpage > cc1-21060 2dN.. 3803us+: trace_hardirqs_on_thunk <-retint_careful > cc1-21060 2dN.. 3806us+: trace_hardirqs_on_caller <-retint_careful > cc1-21060 2dN.. 3812us : <stack trace> > => trace_hardirqs_on_thunk > > but this is with kernel build going on.. The load shouldn't matter much, as far as I know. Steven Rostedt said that perf_event_update_userpage shouldn't take 2 ms; therefore we can be pretty sure that it shouldn't take 3.8 ms. :-) Try running the tracer with "echo 1 > options/function-trace". That ought to provide additional useful information. 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
