Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

2016-04-17 Thread Alan Stern 
On Sat, 16 Apr 2016, Rafał Miłecki wrote:

> >> Now, this is pretty interesting. So first of all I'm not using
> >> CONFIG_USB_OHCI_HCD_PLATFORM.
> >
> > Is that because you simply haven't enabled it, or because you don't
> > have any OHCI hardware on your platform?
> 
> I just didn't have it enabled. There is OHCI hardware available. Since
> you mentioned it ofc I decided to give it a try. As I expected I got 2
> root hubs visible this time:
> 1d6b:0002 Linux Foundation 2.0 root hub
> 1d6b:0001 Linux Foundation 1.1 root hub
> 
> First of all, with ohci-platform I can plug in USB 1.1 device, see it,
> unplug it and continue using port. It's a great difference compared to
> the previous report of USB port not being usable anymore (after
> plugging USB 1.1 device).

That's because your system was intended to have both controllers
working.  If only the EHCI controller is operational, it doesn't work
right for USB-1.1 devices.

> Now, there is more interesting stuff. With ohci-platform enabled
> triggering "port 1 full speed --> companion" (by plugging device very
> slowly) doesn't mean USB becoming unusable anymore. I can see may more
> ohci and ehci messages until (as it seems to me) both controllers give
> up. Please take a look at attached ehci-ohci-success-1.txt.

Yes, that's pretty much what it looks like.

By plugging in the connector very slowly, you are causing the signal
pins to make and break their connections several times.  This messes 
up the hardware and the drivers, although they do recover eventually.

> So there is my theory:
> 1) Connecting USB 1.1 device without ohci-platform installed causes
> some port lockup.

Yep.  When the EHCI controller sees that the device only supports
USB-1.1, it hands the port over to the OHCI controller.  Without the
OHCI driver, the OHCI controller never hands the port back -- even
after the device has been unplugged.

> 2) Connecting USB 2.0 very slowly seems to trigger some transmission
> error and makes OHCI hardware trying to handle this device.
> What I was experiencing so far was a mix of both above. I was
> connecting USB 2.0 device slowly (triggering some error) and I got
> OHCI hardware trying to handle it. I didn't have ohci-platform
> installed and it resulted in port lockup.
> 
> Does it make any sense?

Yes, that's what you should expect.  There's a simple lesson to learn: 
Don't insert the connectors very slowly!  :-)

> I'm also wondering if there is any way to avoid port lockups caused by
> connecting USB 1.1 device without ohci-platform installed?

No.  Or rather, the only way to avoid it is if you don't install 
ehci-platform either.  But that's not much use, because then you 
wouldn't have any USB support at all!

> > I get the impression that this behavior is intended, and your board was
> > never meant to be used without an external hub.  Or possibly with some
> > other permanently attached USB-2 device.  Either way, none of these
> > problems would occur, right?
> 
> This sounds pretty unexpected. I can't imagine vendor telling users to
> don't hot-plug USB device in the user manual.

My initial impression was wrong.  I didn't realize that you had simply 
left out the OHCI driver.

> I also tried installing original firmware on my Netgear R6250 (it's
> based on 2.6.36.4) and after few tries I managed to get some errors,
> but after all I never got port lockup. Sounds like a similar case to
> what I'm seeing with OpenWrt (some recent kernel) and both:
> ehci-platform and ohci-platform.

Yes.  With the same combination of drivers, you get the same behavior.

Alan Stern

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

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

2016-04-16 Thread Rafał Miłecki 
On 16 April 2016 at 17:13, Alan Stern  wrote:
> On Fri, 15 Apr 2016, Rafał Miłecki wrote:
>
>> > What happens if you plug a USB-1.1 device (such as a mouse or keyboard)
>> > into your single-port system?
>>
>> Now, this is pretty interesting. So first of all I'm not using
>> CONFIG_USB_OHCI_HCD_PLATFORM.
>
> Is that because you simply haven't enabled it, or because you don't
> have any OHCI hardware on your platform?

I just didn't have it enabled. There is OHCI hardware available. Since
you mentioned it ofc I decided to give it a try. As I expected I got 2
root hubs visible this time:
1d6b:0002 Linux Foundation 2.0 root hub
1d6b:0001 Linux Foundation 1.1 root hub

First of all, with ohci-platform I can plug in USB 1.1 device, see it,
unplug it and continue using port. It's a great difference compared to
the previous report of USB port not being usable anymore (after
plugging USB 1.1 device).

Now, there is more interesting stuff. With ohci-platform enabled
triggering "port 1 full speed --> companion" (by plugging device very
slowly) doesn't mean USB becoming unusable anymore. I can see may more
ohci and ehci messages until (as it seems to me) both controllers give
up. Please take a look at attached ehci-ohci-success-1.txt.

So there is my theory:
1) Connecting USB 1.1 device without ohci-platform installed causes
some port lockup.
2) Connecting USB 2.0 very slowly seems to trigger some transmission
error and makes OHCI hardware trying to handle this device.
What I was experiencing so far was a mix of both above. I was
connecting USB 2.0 device slowly (triggering some error) and I got
OHCI hardware trying to handle it. I didn't have ohci-platform
installed and it resulted in port lockup.

Does it make any sense?

I'm also wondering if there is any way to avoid port lockups caused by
connecting USB 1.1 device without ohci-platform installed?


>>  After the first time I connect USB 1.1
>> device I see the same problem. This device doesn't get detected (due
>> to the missing "ohci-platform" driver I guess) and afterwards I can't
>> use my USB port anymore. Even connecting back some USB 2.0 device
>> won't get me any kernel event/message.
>>
>> It looks using USB 1.1 device is another (easier?) way of triggering
>> the same problem. At least from the early check it looks similar.
>>
>> You may take a look at attached mix-fail-1.txt.
>>
>>
>> > Does your platform data have the has_tt flag set or the
>> > "has-transaction-translator" OF property?
>>
>> I just checked bcma-hcd.c and it doesn't:
>> static const struct usb_ehci_pdata ehci_pdata = {
>> };
>>
>> However since you already asked, I decided to give it a try. I enabled
>> it but it resulted in USB port not being usable at all. Connecting any
>> USB 2.0 device give me 6 seconds of XactErr-s. If you take a look at
>> my previous e-mail, you'll see I already mentioned such error when
>> "plugging and unplugging USB device quickly (over and over)". Not sure
>> if it's related, just errors look the same.
>
> I get the impression that this behavior is intended, and your board was
> never meant to be used without an external hub.  Or possibly with some
> other permanently attached USB-2 device.  Either way, none of these
> problems would occur, right?

This sounds pretty unexpected. I can't imagine vendor telling users to
don't hot-plug USB device in the user manual.

I also tried installing original firmware on my Netgear R6250 (it's
based on 2.6.36.4) and after few tries I managed to get some errors,
but after all I never got port lockup. Sounds like a similar case to
what I'm seeing with OpenWrt (some recent kernel) and both:
ehci-platform and ohci-platform.

usb 1-1: new high speed USB device using ehci_hcd and address 28
usb 1-1: USB disconnect, address 28
usb 1-1: new high speed USB device using ehci_hcd and address 29
usb 1-1: USB disconnect, address 29
usb 2-1: new full speed USB device using ohci_hcd and address 6
usb 2-1: not running at top speed; connect to a high speed hub
usb 2-1: USB disconnect, address 6
usb 1-1: new high speed USB device using ehci_hcd and address 32
usb 1-1: USB disconnect, address 32
usb 2-1: new full speed USB device using ohci_hcd and address 7
usb 2-1: device descriptor read/64, error -62
usb 2-1: device descriptor read/64, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 8
usb 2-1: device descriptor read/64, error -62
usb 2-1: device descriptor read/64, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 9
usb 2-1: device not accepting address 9, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 10
usb 2-1: device not accepting address 10, error -62
hub 2-0:1.0: unable to enumerate USB device on port 1
usb 1-1: new high speed USB device using ehci_hcd and address 34
usb 1-1: USB disconnect, address 34
usb 1-1: new high speed USB device using ehci_hcd and address 35
usb 1-1: USB disconnect, address 35

-- 
Rafał
[ 1241.301553] hub

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

2016-04-16 Thread Alan Stern 
On Fri, 15 Apr 2016, Rafał Miłecki wrote:

> > What happens if you plug a USB-1.1 device (such as a mouse or keyboard)
> > into your single-port system?
> 
> Now, this is pretty interesting. So first of all I'm not using
> CONFIG_USB_OHCI_HCD_PLATFORM.

Is that because you simply haven't enabled it, or because you don't 
have any OHCI hardware on your platform?

>  After the first time I connect USB 1.1
> device I see the same problem. This device doesn't get detected (due
> to the missing "ohci-platform" driver I guess) and afterwards I can't
> use my USB port anymore. Even connecting back some USB 2.0 device
> won't get me any kernel event/message.
> 
> It looks using USB 1.1 device is another (easier?) way of triggering
> the same problem. At least from the early check it looks similar.
> 
> You may take a look at attached mix-fail-1.txt.
> 
> 
> > Does your platform data have the has_tt flag set or the
> > "has-transaction-translator" OF property?
> 
> I just checked bcma-hcd.c and it doesn't:
> static const struct usb_ehci_pdata ehci_pdata = {
> };
> 
> However since you already asked, I decided to give it a try. I enabled
> it but it resulted in USB port not being usable at all. Connecting any
> USB 2.0 device give me 6 seconds of XactErr-s. If you take a look at
> my previous e-mail, you'll see I already mentioned such error when
> "plugging and unplugging USB device quickly (over and over)". Not sure
> if it's related, just errors look the same.

I get the impression that this behavior is intended, and your board was
never meant to be used without an external hub.  Or possibly with some
other permanently attached USB-2 device.  Either way, none of these
problems would occur, right?

Alan Stern

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

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

2016-04-15 Thread Rafał Miłecki 
On 15 April 2016 at 17:33, Alan Stern  wrote:
> On Fri, 15 Apr 2016, Rafał Miłecki wrote:
>
>> Hello
>>
>>
>> I'm seeing some problems with EHCI stability on two families of
>> Broadcom devices:
>> 1) CONFIG_MIPS=y, CONFIG_BCM47XX=y
>> 2) CONFIG_ARM=y, CONFIG_ARCH_BCM_5301X=y
>> both of them use bcma-hcd driver which registers "ehci-platform" device.
>>
>> An interesting note is that this stability problem occurs only on
>> devices with a single USB port. These devices have simply a root hub:
>> 1d6b:0002 Linux Foundation 2.0 root hub
>> I can't reproduce this issue on devices with 2 USB ports that come with:
>> 1d6b:0002 Linux Foundation 2.0 root hub
>> 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
>>
>> Moreover attaching an external USB hub I own:
>> 058f:6254 Alcor Micro Corp. USB Hub
>> to device with a single USB port (and using this hub instead) also
>> make the problem unreproducible.
>>
>>
>> OK, let me finally describe the problem.
>> Sometimes when (un)plugging USB device when I expect to see:
>> > ehci-platform ehci-platform.0: port 1 reset complete, port enabled
>> I'm getting
>> > ehci-platform ehci-platform.0: port 1 full speed --> companion
>> > hub 1-0:1.0: port_wait_reset: err = -16
>> > not enabled, trying reset again...
>> instead. After that happens I can't use my USB port anymore.
>> Connecting/disconnecting USB device(s) doesn't trigger any kernel
>> reaction. To use USB port again I need to reload bcma-hcd module.
>> For the more complete log please see attached fail-1.txt.
>>
>> I'm not sure how sane it sounds, but I believe the easiest way to
>> trigger this problem is to plug in USB device very slowly.
>> On the other hand plugging and unplugging USB device quickly (over and
>> over) can trigger "detected XactErr len 0/8 retry %d" at some point,
>> but I'm trying to focus on one thing at a time. Let me know if you
>> think it's important though.
>>
>>
>> As I mentioned earlier, when using a USB hub (internal or external
>> one) I can't reproduce this problem. First of all, there is never a
>> standard "port 1 reset complete, port enabled" message, instead I can
>> see e.g. "not reset yet, waiting 10ms". I'm also never getting "port 1
>> full speed --> companion" or "port_wait_reset: err = -16" with USB
>> hub. I can see errors like "device descriptor read/64, error -32" but
>> finally I'm always able to see my USB device and I never need to
>> reload the module.
>>
>> To see a bigger log (with some tries triggering "device descriptor
>> read/64, error -32" but always recovering fine) see attached
>> success-1.txt.
>>
>>
>> Do you have any idea what this problem may be related to? Can I debug
>> it any further to help solving it? Any extra info I can provide?
>>
>> There are more logs available at:
>> http://files.zajec.net/openwrt/ehci/
>> if you need some. If you check fail-5.txt you'll see that "port 1 full
>> speed --> companion" can also occur when unplugging USB device.
>
> Do you always use the same device for testing, or do you test with
> multiple devices?

All logs were coming from the same router (Netgear R6250) and the same
USB device:
0846:9020 NetGear, Inc. WNA3100(v1) Wireless-N 300 [Broadcom BCM43231]

I just tried different USB device, a simple pendrive:
0781:5406 SanDisk Corp. Cruzer Micro U3
and got the same results. You may take a look at attached pendrive-fail-*.txt

To my surprise Linux managed to recover from reset problem once (see
the first log). However after few extra tries I hit the problem
anyway. Same after a reboot.

To sum this up problem doesn't seem to be device specific.


> What happens if you plug a USB-1.1 device (such as a mouse or keyboard)
> into your single-port system?

Now, this is pretty interesting. So first of all I'm not using
CONFIG_USB_OHCI_HCD_PLATFORM. After the first time I connect USB 1.1
device I see the same problem. This device doesn't get detected (due
to the missing "ohci-platform" driver I guess) and afterwards I can't
use my USB port anymore. Even connecting back some USB 2.0 device
won't get me any kernel event/message.

It looks using USB 1.1 device is another (easier?) way of triggering
the same problem. At least from the early check it looks similar.

You may take a look at attached mix-fail-1.txt.


> Does your platform data have the has_tt flag set or the
> "has-transaction-translator" OF property?

I just checked bcma-hcd.c and it doesn't:
static const struct usb_ehci_pdata ehci_pdata = {
};

However since you already asked, I decided to give it a try. I enabled
it but it resulted in USB port not being usable at all. Connecting any
USB 2.0 device give me 6 seconds of XactErr-s. If you take a look at
my previous e-mail, you'll see I already mentioned such error when
"plugging and unplugging USB device quickly (over and over)". Not sure
if it's related, just errors look the same.

-- 
Rafał
[  481.256923] hub 1-0:1.0: state 7 ports 2 chg  evt 0002
[  481.262444] ehci-platform

Re: Unstable ehci(-platform) when using root hub (hw lockup after port reset problem?)

2016-04-15 Thread Alan Stern 
On Fri, 15 Apr 2016, Rafał Miłecki wrote:

> Hello
> 
> 
> I'm seeing some problems with EHCI stability on two families of
> Broadcom devices:
> 1) CONFIG_MIPS=y, CONFIG_BCM47XX=y
> 2) CONFIG_ARM=y, CONFIG_ARCH_BCM_5301X=y
> both of them use bcma-hcd driver which registers "ehci-platform" device.
> 
> An interesting note is that this stability problem occurs only on
> devices with a single USB port. These devices have simply a root hub:
> 1d6b:0002 Linux Foundation 2.0 root hub
> I can't reproduce this issue on devices with 2 USB ports that come with:
> 1d6b:0002 Linux Foundation 2.0 root hub
> 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
> 
> Moreover attaching an external USB hub I own:
> 058f:6254 Alcor Micro Corp. USB Hub
> to device with a single USB port (and using this hub instead) also
> make the problem unreproducible.
> 
> 
> OK, let me finally describe the problem.
> Sometimes when (un)plugging USB device when I expect to see:
> > ehci-platform ehci-platform.0: port 1 reset complete, port enabled
> I'm getting
> > ehci-platform ehci-platform.0: port 1 full speed --> companion
> > hub 1-0:1.0: port_wait_reset: err = -16
> > not enabled, trying reset again...
> instead. After that happens I can't use my USB port anymore.
> Connecting/disconnecting USB device(s) doesn't trigger any kernel
> reaction. To use USB port again I need to reload bcma-hcd module.
> For the more complete log please see attached fail-1.txt.
> 
> I'm not sure how sane it sounds, but I believe the easiest way to
> trigger this problem is to plug in USB device very slowly.
> On the other hand plugging and unplugging USB device quickly (over and
> over) can trigger "detected XactErr len 0/8 retry %d" at some point,
> but I'm trying to focus on one thing at a time. Let me know if you
> think it's important though.
> 
> 
> As I mentioned earlier, when using a USB hub (internal or external
> one) I can't reproduce this problem. First of all, there is never a
> standard "port 1 reset complete, port enabled" message, instead I can
> see e.g. "not reset yet, waiting 10ms". I'm also never getting "port 1
> full speed --> companion" or "port_wait_reset: err = -16" with USB
> hub. I can see errors like "device descriptor read/64, error -32" but
> finally I'm always able to see my USB device and I never need to
> reload the module.
> 
> To see a bigger log (with some tries triggering "device descriptor
> read/64, error -32" but always recovering fine) see attached
> success-1.txt.
> 
> 
> Do you have any idea what this problem may be related to? Can I debug
> it any further to help solving it? Any extra info I can provide?
> 
> There are more logs available at:
> http://files.zajec.net/openwrt/ehci/
> if you need some. If you check fail-5.txt you'll see that "port 1 full
> speed --> companion" can also occur when unplugging USB device.

Do you always use the same device for testing, or do you test with 
multiple devices?

What happens if you plug a USB-1.1 device (such as a mouse or keyboard)  
into your single-port system?

Does your platform data have the has_tt flag set or the 
"has-transaction-translator" OF property?

Alan Stern

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