Live data from Hacker News

Linux may have been causing USB disconnects

plus.google.com

61–70 of 123 posts

Re: Linux may have been causing USB disconnects

#61

Earlier quoted context omitted.

Really As an EE turned "software engineer" this bothers me, a lot. I like the EE part of it, but I prefer thing that change more easily and are more "playful" (not to mention today hardware is at the mercy of software, so you take the reference design and go with it) But I've come into situations where I uncovered a HW bug (in the chip reference board implementation, no less) that only manifested itself because of so…

That is a VERY general statement, most software engineers who do hardware stuff also know what takes to make it. You can't design a driver for a card without knowing everything about the card. And I'd say the same with hardware engineers. If you don't know how the software is going to run, how are you suppose to architect it. You can't make a piece of hardware without thinking about how the driver will work.

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 typical software engineering's education.

Re: Linux may have been causing USB disconnects

#62
post #60

We should applaud them for standing up and saying "Hey, we cocked up, sorry!"

Nothing wrong with that statement, except I think it should be a given.. Do we need a pat on the back for doing the right thing? :)

Maybe if we did more people would be willing to do it.

Re: Linux may have been causing USB disconnects

#63
post #60

We should applaud them for standing up and saying "Hey, we cocked up, sorry!"

Nothing wrong with that statement, except I think it should be a given.. Do we need a pat on the back for doing the right thing? :)

Yes. As an industry, we're not very good at recognizing the great things people do. We tend to focus solely on mistakes. It's not easy to admit failure, and if we want it to continue we should recognize the effort it takes.

Re: Linux may have been causing USB disconnects

#64
post #5

Wait, if I'm reading this correctly there's no safe resume recovery time which can be guaranteed not to cause devices to drop off the bus. The kernel could wait 10 minutes and devices could still require more than that. That seems like a pretty major issue with the USB specification.

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.

Re: Linux may have been causing USB disconnects

#65
post #37
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.

"50ms should be quite enough i think"

If you are going to make a statement like that, make it "64ms ought to be enough for anyone". Either way, it won't help. If you write kernel code or interface with unknown hardware, you must be paranoid to the bone to get robust code. Double so if your kernel code talks with hardware you do not control.

"more than any proper device should ask for."

If devices asked for time, things would be easy; you either reply 'no', or you give them the time they ask for. The problem is that they take time without telling you.

Re: Linux may have been causing USB disconnects

#66
post #8

Be sure to check out the mailing list post linked from the G+ post which contains more technical details and proposed fixes http://marc.info/?l=linux-usb&m=137714769606183&w=2

Why on earth is all the text on that website set to font-weight:600 and using Courier New of all fonts? Incredibly hard to read.

Re: Linux may have been causing USB disconnects

#67
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…

Also with sound devices it is more than a tad annoying to unplug a USB external audio interface (powering down your monitors, etc) because it magically disappeared for some reason.

This is an amazing fix if it is the root of the sorts of problems I've seen on Linux (which've kept me crawling back to Mac for hardware support)

Re: Linux may have been causing USB disconnects

#68
post #31

Earlier quoted context omitted.

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.

Bear in mind that here, something which is a minimum from the point of view of the OS is a maximum from the device's point of view. If the OS is allowed to use any value above 10ms for TRSMRCY then the device can take at most 10ms to prepare itself because the OS can send a request at any point after that.

Re: Linux may have been causing USB disconnects

#69
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.

I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly impossible to ready a device within 10ms, so the spec is saying it would be pointless to issue a request before that time?

Re: Linux may have been causing USB disconnects

#70
post #3

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

I can't speak for kernel developers, but when you have complex and large codebase running on a huge variety of hardware, you will have some edge cases that are rare or difficult to debug. And I don't envy the folks that have to interface directly with hardware, I have enough fun in database land...

I'm an embedded software developer now doing some things with databases.... Give me hardware any day :-)
Post reply on HN