Re: USB net device unexpectedly stops sending driver bulk in urbs

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

Hi Alan,
	see my comments below.

On Monday 03 December 2007 15:26:19 Alan Stern wrote:
> On Mon, 3 Dec 2007, Andrew Bird wrote:
> > > What do you mean by "instantaneously"?  How do you know the data isn't
> > > stuck in a network buffer rather than a USB buffer?
> >
> > Well I think it is the USB device, because if I lower the size of the
> > receive URB to less than the packet size, the device stops sending URBs
> > mid packet.
> This statement is confusing.  For one thing, devices don't send URBs --
> they send packets.  (Drivers don't send URBs either; they submit them.)
> For another, what does it mean to stop sending packets in mid packet?

OK, I have the terminology wrong here. But what I meant to say is that if I 
reduce the size of the URBs I submit as a test (noting your comment below), 
the USB packet flow from the device stops at some point. If I reassemble 
those USB packets together, I can see that they do not form a complete IP 
packet, it is truncated. Hence my supposition that the USB packet flow 
stopped from the device, not the IP packet flow into the device.

> Bear in mind that if your driver submits receive URBs with a smaller
> transfer length than the device expects, then your driver is ipso facto
> at fault.  Any further errors you observe can't be blamed on the
> device.
Checking out the device its Bulk in and out endpoints are advertised as 64 
bytes. Originally the URBs were set large enough to contain a full Ethernet 
packet at over 1500 bytes. Presumably the USB core was coalesing those USB 
packets either to fill my URB, or until an empty USB packet was sent 
indicating end of data. In my test I reduced the size down to 64 bytes, so is 
that OK?

> > My thought ATM is that it's the device that is at fault. Assuming it is
> > for the moment, and knowing that sending data along the bulk-out path
> > stimulates the receive path again, what would be a valid thing to send?
> > Ideally I want something that terminates on the USB device, and doesn't
> > get pushed out to the network.
> It's impossible to answer this question without knowing what data the
> device expects to receive on its bulk-out endpoint.
I was hoping there might be a generic USB level ping or get status command I 
could send to its bulk-out endpoint, just to tickle the other end.

> > Well I have tested variants of the driver on two platforms and see the
> > fault on both. Currently I'm trying to make it work on a Broadcom
> > embedded MIPSel device with 2.4.20 kernel. Previously I saw it on x86
> > with 2.6.22 kernel. The device is an Option UMTS card. It is a PCI
> > expressCard that comes with a cardbus caddy containing an ohci usb
> > controller. The device is not one of the usual usbserial type cards, but
> > one that does PPP on the card itself, and ships IP packets out to the
> > host. The 2.6 driver is available from
> >,com_forum/Itemid,68/page,viewto
> >pic/t,350/
> If you're trying to debug a difficult problem, you should make the rest
> of your environment as trouble-free as possible.  That means using a
> standard host architecture (like x86) with a standard USB host
> controller (not something built into a cardbus caddy), and using the
> most recent and most bug-free kernel you can find (like 2.6.23.x).
Yes I couldn't agree more. I'll try and setup something simple.

Thanks again


> Alan Stern

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
To unsubscribe, use the last form field at:

[Home]     [Video for Linux]     [Photo]     [Yosemite Forum]     [Yosemite Photos]    [Video Projectors]     [PDAs]     [Hacking TiVo]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Big List of Linux Books]     [Free Dating]

  Powered by Linux