On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern <[email protected]> wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern <[email protected]>
>> 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.
Yep - that makes sense. But has there been a change in SMI timings
with the new kernel? I don't think this bug happened with earlier
kernels. 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?
>
> 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
0: 43 0 0 0 IO-APIC-edge timer
1: 0 6 125 8193 IO-APIC-edge i8042
4: 1 0 0 3 IO-APIC-edge
7: 1 0 0 0 IO-APIC-edge
8: 0 0 0 1 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 6 41 1399 132585 IO-APIC-edge i8042
14: 0 0 0 0 IO-APIC-edge pata_atiixp
15: 0 0 0 0 IO-APIC-edge pata_atiixp
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
19: 285 1 2468 115973 IO-APIC-fasteoi ahci
20: 0 179690 3 625 IO-APIC-fasteoi
0000:01:05.0
40: 0 0 0 0 PCI-MSI-edge PCIe PME
41: 0 0 0 0 PCI-MSI-edge PCIe PME
42: 1 5 136 13765 PCI-MSI-edge radeon
43: 0 0 0 0 PCI-MSI-edge eth0
NMI: 249 250 250 251 Non-maskable interrupts
LOC: 1429195 1559233 1373952 1109102 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 249 250 250 251 Performance
monitoring interrupts
IWI: 10666 9404 10633 11032 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 1101840 1115189 1141309 1180596 Rescheduling interrupts
CAL: 652 919 780 959 Function call interrupts
TLB: 33102 20339 28625 26571 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 19 19 19 19 Machine check polls
ERR: 1
MIS: 0
>> 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.
> 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.
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..
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
