Takashi Iwai wrote:
no, it has nothing to do with the latency but oopsen / lock-up.
the problem exists only at stopping the streams. if the everything is
ok, it's not a big issue. but, when the device runs with small
latency, which may result in xrun often, has the higher probability to
hit thi
At Thu, 20 Nov 2003 23:33:52 +0900,
Patrick Shirkey wrote:
>
> Takashi Iwai wrote:
> >
> > the current code is surely buggy, because it issues sync unlink
> > inside the spinlocked context. it's problematic on 2.6 kernel or SMP
> > system, and may result in kernel oops. i added async_unlink mod
Hello list,
I'm new here so hi, and sorry if I missed out on things discussed earlier.
I subscribed to this list because I've been having lost of problems with
the USB driver over the past half year (similar to the stuff mentioned in
this thread). So much so, that I am prepared to dive into the co
At Thu, 20 Nov 2003 15:28:25 -0500,
Karim Yaghmour wrote:
>
>
> Takashi Iwai wrote:
> > it'd be better to clean unlink_mask in the complete callback for the
> > case you use async unlink mode (see below).
> > and, the check of active_mask should be done in prepare callback, not
> > in the trigger
Takashi Iwai wrote:
it'd be better to clean unlink_mask in the complete callback for the
case you use async unlink mode (see below).
and, the check of active_mask should be done in prepare callback, not
in the trigger callback. the trigger callback must be as short as
possible. we can put deactiv
Niklas Werner wrote:
hmmm, the submit_urb-error is gone, but random lockups and
usb-device-disconnect until reboot have come... (bitkeeper-2.6 from just
one hour ago...) with your function.
Interesting. I haven't seen any of these.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded
Takashi Iwai wrote:
the current code is surely buggy, because it issues sync unlink
inside the spinlocked context. it's problematic on 2.6 kernel or SMP
system, and may result in kernel oops. i added async_unlink module
option to change the behavior in the new version.
but it's still disabled as
At Thu, 20 Nov 2003 00:50:03 -0500,
Karim Yaghmour wrote:
>
>
> Well, it seems that I'm going to have to answer my own self ... :)
>
> The following is what I've been able to find using additional tracing
> info. Also there's a fix for usbaudio.c.
>
> Basically, it's as I said before: the usbau
At Thu, 20 Nov 2003 11:04:52 +0100,
Niklas Werner wrote:
>
> Karim Yaghmour wrote:
>
> >
> > Well, it seems that I'm going to have to answer my own self ... :)
>
> Yes, usb-audio seems to be a bit forgotten... (Takashi, those
> mplayer-plughw-segfaults still persist, even on x86 and even with k
Karim Yaghmour wrote:
Well, it seems that I'm going to have to answer my own self ... :)
Yes, usb-audio seems to be a bit forgotten... (Takashi, those
mplayer-plughw-segfaults still persist, even on x86 and even with kernel
2.4 (current cvs of drivers/lib, of course)
The following is what I've
Well, it seems that I'm going to have to answer my own self ... :)
The following is what I've been able to find using additional tracing
info. Also there's a fix for usbaudio.c.
Basically, it's as I said before: the usbaudio driver uses URBs
without even checking if they're in use or not. Surprisi
11 matches
Mail list logo
