Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux may have been causing USB disconnects

plus.google.com

Post reply on HN
Print view View original

31–40 of 123 posts

Re: Linux may have been causing USB disconnects

#31

Post by delinka »

bluesign wrote: post #29

this is wrong interpretation actually. There is no "maximum" for a reason. Because it should be evaluated as "hey hardware developer, you will have guaranteed 10 ms from System Software to resume". If you don't wake up in 10ms, you are clearly violating the spec. 9.2.6.2 states: After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached t…

Nothing there says that the hardware must be ready at or after 10ms. It simply says that software can't ask for anything before 10ms is up. Software has to wait 10ms, and then might have to wait longer.

Re: Linux may have been causing USB disconnects

#32

Post by [deleted] »

bluesign wrote: post #29

this is wrong interpretation actually. There is no "maximum" for a reason. Because it should be evaluated as "hey hardware developer, you will have guaranteed 10 ms from System Software to resume". If you don't wake up in 10ms, you are clearly violating the spec. 9.2.6.2 states: After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached t…

[deleted]

Re: Linux may have been causing USB disconnects

#33

Post by davidw »

ape4 wrote: post #28

Its a good thing that Linux is open and transparent. Good to admit a bug (and exactly what it is) rather than silently deny then possibly fix. Also, somebody uses Google+ ?

For whatever reason, there seems to be a number of Linux people on Google Plus, including Linus Torvalds.

Re: Linux may have been causing USB disconnects

#34

Post by zwdr »

Jugurtha wrote: post #7

Well, that's why you don't hardcode a magic value, nor do you continuously poll the state of a device and rely instead on interrupts: That's what they're made for.

USB 3.0 uses interrupts, but if you're trying that with 2.0 you're gonna have to wait for those interrupts a _long_ time.

Re: Linux may have been causing USB disconnects

#35

Post by masklinn »

JoeAltmaier wrote: post #18
annnnd wrote: post #3

Congrats! But how nobody analysed this bug for 8+ years is a bit of a mystery to me...

Because nobody cares about suspend-resume power mgmt. If it doesn't work, curse it, pull it out and put it back in again, voila it works. The people who really care about and study the spec, are those who have to support fixed devices i.e. USB devices internal to an appliance. They physically cannot be removed by the user. So suspend/resume has to work. Embedded programmers have to deal with totally-broken drivers/sp…

In this case, the pain point was apparently a ChromeOS device: http://marc.info/?l=linux-usb&m=137714769606183&w=2

> This bug has been reproduced under ChromeOS, which is very aggressive about USB power management. It enables auto-suspend for all internal USB devices (wifi and bluetooth), and the disconnects wreck havoc on those devices, causing the ChromeOS GUIs to repeatedly flash the USB wifi setup screen on user login.

Re: Linux may have been causing USB disconnects

#36

Post by masklinn »

delinka wrote: post #31
bluesign wrote: post #29

this is wrong interpretation actually. There is no "maximum" for a reason. Because it should be evaluated as "hey hardware developer, you will have guaranteed 10 ms from System Software to resume". If you don't wake up in 10ms, you are clearly violating the spec. 9.2.6.2 states: After a port is reset or resumed, the USB System Software is expected to provide a “recovery” interval of 10 ms before the device attached t…

Nothing there says that the hardware must be ready at or after 10ms. It simply says that software can't ask for anything before 10ms is up. Software has to wait 10ms, and then might have to wait longer.

Yep, the mentioned 7-14 table makes this very clear: it's a big-ass table of timing names with a column for minimum and a column for maximum (and a bunch of other columns for e.g. timing unit), where either column may be empty (and for many timings only one of them is filled).

In that table, TRSMRCY has a minimum value (of 10ms) but no maximum.

Re: Linux may have been causing USB disconnects

#37

Post by Fuxy »

miga wrote: post #22

Good we have a fix for a bug, that has been pestering me for quite a long time. As for maximum timeout, I believe that setting a maximum timeout in sysfs with default of 1s should make satisfy most people (unless anyone wants per-device max wait time?)

50ms should be quite enough i think. That's 5X the minimum, more than any proper device should ask for. If you want to be extreme you can make it 100ms but any more than that is way to extreme.

Re: Linux may have been causing USB disconnects

#38

Post by masklinn »

alexchamberlain wrote: post #10
Jugurtha wrote: post #7

Well, that's why you don't hardcode a magic value, nor do you continuously poll the state of a device and rely instead on interrupts: That's what they're made for.

That's not entirely fair; standards are full of hard coded values.

In fact the 7-14 table mentioned in TFAA is literally a table of magic values to hard-code: it's a big table listing all the timings of section 7 and their minimum and maximum values (either one of which may be absent)

Re: Linux may have been causing USB disconnects

#39

Post by exDM69 »

Jugurtha wrote: post #7

Well, that's why you don't hardcode a magic value, nor do you continuously poll the state of a device and rely instead on interrupts: That's what they're made for.

> Well, that's why you don't hardcode a magic value, nor do you continuously poll the state of a device and rely instead on interrupts: That's what they're made for.

There was a mention about this in the OP. There were no interrupts for this state transition in USB prior to USB3. "The Intel xHCI host, unlike the EHCI host, actually gives an interrupt when the port fully transitions to the active state."

In addition, a lot of hardware initialization is based on delays and polling by design.

Re: Linux may have been causing USB disconnects

#40

Post by barrkel »

JoeAltmaier wrote: post #20
Jugurtha wrote: post #7

Well, that's why you don't hardcode a magic value, nor do you continuously poll the state of a device and rely instead on interrupts: That's what they're made for.

Agreed. There's no reason to slavishly imitate a spec, when you can be more generous or better yet just test and wait. Embedded programmers know this; you can't ship working appliances without dealing with these issues.

There's no reason to slavishly imitate a spec

You're forgetting the feeling of smug virtuousness you get when you end up being incompatible because you're more technically correct (the best kind) than the other components you're interacting with.

You get to say the other guys are all wrong, wage wars against them, blacklists, all the usual religious crap etc.

Post reply on HN