On Monday 13 August 2007, Midhun Agnihotram wrote:
> Hi All,
> 
>     We are have a development kit on which we are trying to run USB
> host port. The drivers are from the vendor. The kernel recognizes the
> USB host controller. But as soon as we insert a USB flash drive, the
> kernel hangs with the following error:
> 
> usb 1-2: device descriptor read/64, error -110

Just a flash drive?  Or -- *any* USB device?  This happens
very early.  I've seen similar problems if the transciever
is set up wrong ... e.g. it uses 4-wire signaling but you've
set it up for 6-wire, and so on.


>    I am attaching the source code that I got from the vendor.

Looks like they sent you a broken development snapshot.  What's
that huge block of "#if 0/.../#endif code at the top, before the
copyright and normal #includes?

Does the vendor have any help to offer you?  How well do they
say it should work?  Can they report that it runs for a week
with all the tests listed in

   http://www.linux-usb.org/usbtest/

which apply to host side drivers?  With lockdep and memory
poisoning enabled?

- Dave

p.s. With code like the following, I can easily see how this
driver could have all kinds of bugs:

> static int imx21_alloc_dmem(struct imx21 *imx21, int size)
> {
>     int offset = 0;
>     imx21_dmem_area_t *area;
>     imx21_dmem_area_t **p;
>     imx21_dmem_area_t *tmp;
>
>     spin_lock(imx21->lock);
>
>     /* Round the size up */
>     size += (~size + 1) & 0x3;

How about the traditional "size = (size + 3) & 3" ?
That "-size" looks needlessly fishy ...


>     if (size > DMEM_SIZE) {
>         return -ENOMEM;

Didn't release the lock.  Of course, it *GOT* the lock
too early ... one should defer getting locks for as long
as practical.  In this case there's no point in getting
it until the dmem_list needs to be scanned, since it
doesn't need to protect local variables ("size", "area")
from anything.

>     }
>
>     area = kmalloc(sizeof(imx21_dmem_area_t), GFP_ATOMIC);
>     if ( area == NULL) {
>         return -ENOMEM;

A second locking bug, and the routine hasn't really even
begun to do work yet!

Plus of course the style bugs:  indents aren't purely TAB
characters, extra brackets in "if (...) return...", extra
space right above "if ( ", and so on.

Style bugs aren't necessarily a worry, although they do
hurt when asking for help from the the general community.
But in conjunction with obvious locking bugs they certainly
suggest that the driver hasn't yet had the *minimum* of
attention it needs before it's expected to work properly.

HCDs are, unfortunately, fairly complex animals.  Being
able to notice serious locking bugs without even trying
makes me suspect this driver needs a *LOT* more work than
anyone without iMX21 hardware can provide.

>     }

... more omitted.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to