Live data from Hacker News

Linux may have been causing USB disconnects

plus.google.com

81–90 of 123 posts

Re: Linux may have been causing USB disconnects

#81
post #71
post #61

Earlier quoted context omitted.

though I agree that it's probably too general of a statement, I'm more with raverbashing on this one: while now mainly doing software I have a strong hardware background and it's more often than not just baffling to see the approach of software-only engineers when having to code over the software/hardware border. Then again, maybe I only met some exceptions. I also have no idea if/how these topics are covered in a ty…

Well, back when I was an MIT undergraduate, one of the core CS classes handed us a breadboard and a bunch of 74XX TTL chips, and we needed to construct a general register and stack computer from that. (We did get some PC boards that gave us a ALU and a UART that plugged into the breadboard, as well as the ability to program an EPROM to implement the firmware, but none of this "here's an Arduino or Rasberry Pi".) Mayb…

"deer in headlights"

lol, I see what you mean there. Now as long as the person you're talking to has a true engineering mind he/she will be happy to learn about the subject. But there's unfortunately also those that start looking you with eyes begging you to go stop the hardware mumbojumbo talk and go back to oftware only. I don't really consider them true engineers.

Re: Linux may have been causing USB disconnects

#82

Earlier quoted context omitted.

> No I don't know who you think you're disagreeing with, but it clearly isn't me.

acchow is disagreeing with your database query likeness. Your comment was effectively saying that it's just waiting until it's ready. And this is clearly something that can be disagreed with. Based on the way this article is worded, it seems like there is no way to check when TRSMRCY is over. Imagine if you were waiting for a database query and if the database wasn't done thinking yet, simply accessing the socket wou…

Your understanding of the problem is in error, and will be corrected by reading the linux-usb thread linked to by the article.

Re: Linux may have been causing USB disconnects

#83

Earlier quoted context omitted.

acchow is disagreeing with your database query likeness. Your comment was effectively saying that it's just waiting until it's ready. And this is clearly something that can be disagreed with. Based on the way this article is worded, it seems like there is no way to check when TRSMRCY is over. Imagine if you were waiting for a database query and if the database wasn't done thinking yet, simply accessing the socket wou…

Your understanding of the problem is in error, and will be corrected by reading the linux-usb thread linked to by the article.

Good! But that doesn't mean your original comment was infallible, since it didn't actually clarify such a thing.

Re: Linux may have been causing USB disconnects

#84
post #19

Earlier quoted context omitted.

Well the Linux USB maintainer has spent the last month or so trying to get Linus to be more polite, so I guess those kind of things have a higher priority! I kid, I kid... The reason is that it is incredibly difficult to link the disconnect to the cause as the 10ms is likely sufficient in 99% of cases - until it suddenly isn't. This means that you could be running test cases on a certain device for a year, and sudden…

> the 10ms is likely sufficient in 99% of cases from TFA: > the time is above 10 ms in about 8% of the remote wakeup events I've tested. So 10ms is sufficient in about 92% of cases, barely more than 9 in 10.

This figure is just for two specific devices [1]:

>Out of 227 remote wakeup events from a USB mouse and keyboard: > - 163 transitions from RExit to U0 were immediate ( - 47 transitions from RExit to U0 took under 10 ms > - 17 transitions were over 10ms

So, 10 ms might indeed be sufficient for 99% of devices. But some devices (i.e. this mouse/kb combo) needs between 10 ms and 12 ms in 8% of all wakeups.

[1] http://marc.info/?l=linux-usb&m=137714769606183&w=2

Re: Linux may have been causing USB disconnects

#85
post #3

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

When cheap hardware acts like it doesn't follow the spec, no one digs too deep, because it's always going to be quite frequent, and there's nothing you can do about it. It's very rare that it turns out to actually have been following the spec, and you had the spec wrong. That's the practical reason.

Re: Linux may have been causing USB disconnects

#86
post #71
post #61

Earlier quoted context omitted.

though I agree that it's probably too general of a statement, I'm more with raverbashing on this one: while now mainly doing software I have a strong hardware background and it's more often than not just baffling to see the approach of software-only engineers when having to code over the software/hardware border. Then again, maybe I only met some exceptions. I also have no idea if/how these topics are covered in a ty…

Well, back when I was an MIT undergraduate, one of the core CS classes handed us a breadboard and a bunch of 74XX TTL chips, and we needed to construct a general register and stack computer from that. (We did get some PC boards that gave us a ALU and a UART that plugged into the breadboard, as well as the ability to program an EPROM to implement the firmware, but none of this "here's an Arduino or Rasberry Pi".) Mayb…

> These days, there are Java programmers who get that "deer in headlights" look when confronted with terms such as "cache line miss".

Forget that, most of these folks can't reason about a program that doesn't have automatic garbage collection. Even if they have direct experience with C or similar, I have asked recent grads how they imagine reference counting or malloc/free works, and they very often start pulling out GC-influenced magical thinking about "the system" reclaiming things under the covers.

Re: Linux may have been causing USB disconnects

#87

What are the conditions where this problem manifests? I have a Das Keyboard that sporadically become unresponsive until I unplug and plug it back in. How do I know if my problem is caused by the issue described in the article?

it happens after a resume from sleep?

Re: Linux may have been causing USB disconnects

#88
post #64

Earlier quoted context omitted.

If you issue a database query, you have no particular guarantee that it's going to complete in any finite amount of time. At some point, you simply throw up your hands and say it would be unreasonable to wait any longer, and accept the resulting error condition.

No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.

[deleted]

Re: Linux may have been causing USB disconnects

#89
post #58

Earlier quoted context omitted.

Or just use a decent router and put the Virgin supplied thing in modem mode.

My fix involved spending no money and required supporting no more devices :)

But instead required a bunch of moderately obscure changes to system config which you are bound to forget after a few years when you reinstall / image a new machine. The Virgin Superhub is a crappy barely-consumer grade box from Netgear with firmware written by Virgin. Modem mode is all it's good for. Sometimes the right answer is to spend the money on a decent router - Draytek are passable.

Re: Linux may have been causing USB disconnects

#90
post #31

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.

[deleted]
Post reply on HN