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.
Linux may have been causing USB disconnects
61–70 of 123 posts
Re: Linux may have been causing USB disconnects
#62Re: Linux may have been causing USB disconnects
#63We 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? :)
Re: Linux may have been causing USB disconnects
#64Wait, 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.
Re: Linux may have been causing USB disconnects
#65Good 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.
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
#66Be 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
Re: Linux may have been causing USB disconnects
#67Congrats! 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…
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
#68Earlier 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.
Re: Linux may have been causing USB disconnects
#69Earlier 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.
Re: Linux may have been causing USB disconnects
#70Congrats! 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...