[PATCH] work on usb_submit_urb returning -22 and "bad: scheduling while atomic!"

[PATCH] work on usb_submit_urb returning -22 and "bad: scheduling while atomic!"

[Stephane Alnet]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1715 bytes --]

Hi,

I couldn't get my UA-5 to work even in standard mode for playback
(recording is fine in either standard or advanced mode based on the quirk
I submitted recently and Clemens helped put in CVS) so I spent some time
working on this problem tonight.

I hit two different problems; the first one has already been mentioned on
the list a couple days ago and shows up as:

ALSA sound/usb/usbaudio.c:685: cannot submit datapipe for urb 0, err = -22
(-22 is -EINVAL)

After some parsing of usb_submit_urb, I added some debugs in usbaudio.c
and found out that urb->interval was set to 0, an invalid value. So I
forced it to 1 and things started to work. (Obviously the proper fix may
be to find why it's not properly initialized in the first place.)

However I still had the "bad: scheduling while atomic!" problem I reported
earlier on the list; sometimes I'd also get "Debug: sleeping function
called from illegal context at kernel/sched.c:1489". Looking at the output
from my debugs I saw that in some cases we were calling usb_submit_urb
with a non-NULL urb->hcpriv, which isn't valid either.

So, I'm not sure what the root cause for this last problem is (besides the
fact that schedule() is called within schedule()), but I kind of worked
around it by guarding all the usb_submit_urb calls with a check for a NULL
urb->hcpriv. I still get the same oopses when opening the device, and
sound quality gets down under load (lost packets), but otherwise things
seem to be working much better.

Attached are the diffs I made; it's getting late here so I'll check back
on it tomorrow, but hopefully that'll give somebody some ideas of what I
did. :-]

Tested with Kernel 2.5.75 + alsa-kernel CVS as of tonight.

Stephane

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 792 bytes --]

Re: [PATCH] work on usb_submit_urb returning -22 and "bad: scheduling while atomic!"

[Takashi Iwai]

At Sat, 12 Jul 2003 23:45:08 -0500 (CDT),
Stephane Alnet wrote:
> 
> I hit two different problems; the first one has already been mentioned on
> the list a couple days ago and shows up as:
> 
> ALSA sound/usb/usbaudio.c:685: cannot submit datapipe for urb 0, err = -22
> (-22 is -EINVAL)
> 
> After some parsing of usb_submit_urb, I added some debugs in usbaudio.c
> and found out that urb->interval was set to 0, an invalid value. So I
> forced it to 1 and things started to work. (Obviously the proper fix may
> be to find why it's not properly initialized in the first place.)
 
yeah, that's a known problem of usb-audio driver on the recent 2.5/2.6
kernel...

> However I still had the "bad: scheduling while atomic!" problem I reported
> earlier on the list; sometimes I'd also get "Debug: sleeping function
> called from illegal context at kernel/sched.c:1489".

these errors should have been fixed on 0.9.5.
usb_submit_urb() was called in prepare callback of ALSA, which is
supposed to be atomic.

> Looking at the output
> from my debugs I saw that in some cases we were calling usb_submit_urb
> with a non-NULL urb->hcpriv, which isn't valid either.

hmm, this looks bad.

> So, I'm not sure what the root cause for this last problem is (besides the
> fact that schedule() is called within schedule()), but I kind of worked
> around it by guarding all the usb_submit_urb calls with a check for a NULL
> urb->hcpriv. I still get the same oopses when opening the device, and
> sound quality gets down under load (lost packets), but otherwise things
> seem to be working much better.
> 
> Attached are the diffs I made; it's getting late here so I'll check back
> on it tomorrow, but hopefully that'll give somebody some ideas of what I
> did. :-]

thanks for the patch.

i was working on this yesterday, 2.6.0-test1 was succesfully built,
and...  this morning i found my harddisk crashed completely :-<

too bad.


i still have only a 2.4 environment, so fixing this problem might take
a bit longer time.  please be patient.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0