usb_fill_bulk_urb() broken for USB1.1?

usb_fill_bulk_urb() broken for USB1.1?

[Keith Chew]

Hi

We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
with great success. Recently, when we upgraded to 2.6.20.1 (also
tested on 2.6.21.5), we found that during initialisation, these calls
works with USB2.0 but stopped working on USB1.1:

usb_fill_bulk_urb();
usb_submit_urb();

The error code returned is -22 (-EINVAL). In 2.6.16.18, it works for
both USB2.0 and 1.1.

When we change to use usb_fill_int_urb(), it then works for USB1.1,
but takes up to 15 seconds (usually less than 5 seconds) for the
driver to initialise. Also, usb_fill_int_urb() does not work for
USB2.0 (kernel panic).

Can anyone point us to the right direction on how to get
usb_fill_bulk_urb() working on USB1.1? We need this as not all of the
deployed machines have USB2.0 enabled.

Regards
Keith

Re: usb_fill_bulk_urb() broken for USB1.1?

[Chuck Ebbert]

On 06/26/2007 10:20 AM, Keith Chew wrote:

[cc: linux-usb-devel]

> We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
> with great success. Recently, when we upgraded to 2.6.20.1 (also
> tested on 2.6.21.5), we found that during initialisation, these calls
> works with USB2.0 but stopped working on USB1.1:
> 
> usb_fill_bulk_urb();
> usb_submit_urb();
> 
> The error code returned is -22 (-EINVAL). In 2.6.16.18, it works for
> both USB2.0 and 1.1.
> 
> When we change to use usb_fill_int_urb(), it then works for USB1.1,
> but takes up to 15 seconds (usually less than 5 seconds) for the
> driver to initialise. Also, usb_fill_int_urb() does not work for
> USB2.0 (kernel panic).
> 
> Can anyone point us to the right direction on how to get
> usb_fill_bulk_urb() working on USB1.1? We need this as not all of the
> deployed machines have USB2.0 enabled.
> 

Re: usb_fill_bulk_urb() broken for USB1.1?

[Pete Zaitcev]

On Tue, 26 Jun 2007 13:52:41 -0400, Chuck Ebbert <cebbert@redhat.com> wrote:
> On 06/26/2007 10:20 AM, Keith Chew wrote:

> [cc: linux-usb-devel]
> 
> > We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
> > with great success. Recently, when we upgraded to 2.6.20.1 (also
> > tested on 2.6.21.5), we found that during initialisation, these calls
> > works with USB2.0 but stopped working on USB1.1:
> > 
> > usb_fill_bulk_urb();
> > usb_submit_urb();
> > 
> > The error code returned is -22 (-EINVAL). In 2.6.16.18, it works for
> > both USB2.0 and 1.1.

This looks like an attempt to submit a bulk URB to an interrupt endpoint,
with garbage interval or something of that nature.

I think it would be the best to talk to the driver author directly.

-- Pete

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Oliver Neukum]

Am Dienstag, 26. Juni 2007 schrieb Chuck Ebbert:
> On 06/26/2007 10:20 AM, Keith Chew wrote:
> 
> [cc: linux-usb-devel]
> 
> > We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
> > with great success. Recently, when we upgraded to 2.6.20.1 (also
> > tested on 2.6.21.5), we found that during initialisation, these calls
> > works with USB2.0 but stopped working on USB1.1:
> > 
> > usb_fill_bulk_urb();
> > usb_submit_urb();

What do you use as arguments for usb_fill_bulk_urb() ? One of the sanity tests
in usb_submit_urb() is triggered.

	Regards
		Oliver

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Greg KH]

On Tue, Jun 26, 2007 at 01:52:41PM -0400, Chuck Ebbert wrote:
> On 06/26/2007 10:20 AM, Keith Chew wrote:
> 
> [cc: linux-usb-devel]
> 
> > We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
> > with great success. Recently, when we upgraded to 2.6.20.1 (also
> > tested on 2.6.21.5), we found that during initialisation, these calls
> > works with USB2.0 but stopped working on USB1.1:
> > 
> > usb_fill_bulk_urb();
> > usb_submit_urb();
> > 
> > The error code returned is -22 (-EINVAL). In 2.6.16.18, it works for
> > both USB2.0 and 1.1.
> > 
> > When we change to use usb_fill_int_urb(), it then works for USB1.1,
> > but takes up to 15 seconds (usually less than 5 seconds) for the
> > driver to initialise. Also, usb_fill_int_urb() does not work for
> > USB2.0 (kernel panic).
> > 
> > Can anyone point us to the right direction on how to get
> > usb_fill_bulk_urb() working on USB1.1? We need this as not all of the
> > deployed machines have USB2.0 enabled.

Do you have a pointer to where this code is so that we can see if the
driver is doing something "odd"?

thanks,

greg k-h

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Keith Chew]

Hi Oliver

>
> What do you use as arguments for usb_fill_bulk_urb() ? One of the sanity tests
> in usb_submit_urb() is triggered.
>

Usage:

	usb_fill_bulk_urb(macp->intr_urb, macp->usb,
		usb_rcvbulkpipe(macp->usb, EP_INT_IN),
		macp->IntEPBuffer, MAX_EPINT_BUFFER,
		zd1211_intr_cb, macp);

where

#define EP_INT_IN			0x03
#define MAX_EPINT_BUFFER	64

Here are the relevant structure definitions:

	struct usb_device	*usb;
	struct urb		*intr_urb;
	u8			*IntEPBuffer;

I can post the full structure if required.

Regards
Keith

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Oliver Neukum]

Am Mittwoch, 27. Juni 2007 schrieb Keith Chew:
> Hi Oliver
> 
> >
> > What do you use as arguments for usb_fill_bulk_urb() ? One of the sanity tests
> > in usb_submit_urb() is triggered.
> >
> 
> Usage:
> 
> 	usb_fill_bulk_urb(macp->intr_urb, macp->usb,
> 		usb_rcvbulkpipe(macp->usb, EP_INT_IN),
> 		macp->IntEPBuffer, MAX_EPINT_BUFFER,
> 		zd1211_intr_cb, macp);

See Pete's post.

You are initialising an interrupt urb with an initializer for
a bulk urb. The behavior is undefined. In older kernels
by random chance a sensible interval was set.

You need to use the correct initializer and the correct interval,
which usually can be read from the device's descriptors.

	Regards
		Oliver

Re: [linux-usb-devel] usb_fill_bulk_urb() broken for USB1.1?

[Keith Chew]

Hi Oliver

> You are initialising an interrupt urb with an initializer for
> a bulk urb. The behavior is undefined. In older kernels
> by random chance a sensible interval was set.
>
> You need to use the correct initializer and the correct interval,
> which usually can be read from the device's descriptors.
>

Thank you very much for all your help. Will correct the code and
report back very soon.

Regards
Keith