Re: Help with USB issues at boot-up on i.MX25 (linux 3.5.4)

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

 



On 27 March 2013 20:00, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 27 Mar 2013, David Linares wrote:
>
>> Please correct me if I am wrong.
>> On my iMX25 board, I have got a 1-port root_hub which will provide
>> 500mA max to its unique child.
>
> You should check that against the iMX25's specs.  It's possible that
> the root hub has a current limit lower than 500 mA.
>
>>  Now that's where I am getting confused.
>> Its child, a 2-port hub, will then be bus-powered. But if it is, it
>> won't provide these 500mA shared between the 2 ports. It will only
>> provide 100mA per port, right?
>
> Actually, I don't know.  What I said earlier was under the assumption
> that the 2-port hub receives all its power from the USB bus.  But in
> theory, it's possible for the hub to receive power directly from the
> iMX25 board's power supply.  So the answer depends on how the hardware
> is wired up.
>
> If the 2-port hub doesn't have an additional power source then you are
> right -- it is bus powered and should provide only 100 mA to each port.
> But if it does have an external (to the USB bus) supply then it could
> very well try to provide 500 mA to each port.  Even if the external
> supply isn't strong enough to permit this.
>
>> But for me to be able to plug my wireless dongle, in the code, I guess
>> I will need to have "hub->mA_per_port = 500;" and therefore have the
>> USB_DEVICE_SELF_POWERED bit set in the hubstatus. Is that correct?
>> Because otherwise, my dongle will always pass the test "if
>> (c->desc.bMaxPower * 2 > udev->bus_mA)" if this udev->bus_mA is set to
>> 100mA and always end up in insufficient power.
>
> Sort of.  Your emphasis is backward; this is a hardware issue, and
> whether or not a software test is passed won't affect the underlying
> problem.  That test is there so that the system will avoid trying to
> use a device when there isn't enough power for it.  Unfortunately the
> test doesn't always work, because many devices lie about their power
> sources.
>
> Also, hubs don't always limit the amount of current to their downstream
> ports the way they should.  A bus-powered hub is supposed to get an
> over-current condition and turn off port power if the device attached
> to the port tries to draw more than 100 mA.  But not all of them do
> this.
>
> In any case, you said there were occasional problems even without the
> dongle attached.  In that situation, power should not be an issue.
>
>> > You never posted any usbmon results.  If you could see the actual data
>> > sent by the hub when it's not working, you might get a better idea of
>> > where the problem is.
>>
>> True. Didn't get a chance to do this experiment yet. As you can read,
>> I am still having some difficulties understanding how it should work
>> in practice and who gives which power :-)
>> Will do that tomorrow too.
>
> Okay.

Ok so here is what I did:
- compiled all USB stuff as modules
- boot up the device with nothing plugged in
- Checked that "lsmod | grep usb" didn't return anything
- modprobe usbmon (this will also load usbcore)
- start the capture : cat /sys/kernel/debug/usb/usbmon/0u > mon.out &
- modprobe ehci-hcd
- kill the cat ;p

I managed to get the capture for the failing case (NOK) and the OK
case. Here are the results:
OK case, dmesg output:     http://pastebin.com/8DRP9L4E
OK case, lsusb -v output:   http://pastebin.com/HcFKhVeW
OK case, usbmon output:   http://pastebin.com/LrFuJ2cd

NOK case, dmesg output:   http://pastebin.com/7kXDCDmr
NOK case, lsusb -v output: http://pastebin.com/zachs6FX
NOK case, usbmon output: http://pastebin.com/RtyLjKt9

I still haven't analysed the results, but there are definitely some
differences between the two usbmon results.
Just wanted to post them as soon as possible, just in case I did
something wrong.
Cheers.
David

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux