Re: Audio I/O parameters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> 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.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux