Re: Audio I/O parameters

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

 



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




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

  Powered by Linux