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

91–100 of 123 posts

Re: Linux may have been causing USB disconnects

#91

Post by kps »

uhno wrote: post #73
tytso wrote: post #71

Earlier quoted context omitted.

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…

Which class was this, and are any of the notes or project assignments available online? That sounds like a fun project.

Sounds like http://www.nand2tetris.org/

Re: Linux may have been causing USB disconnects

#93

Post by delinka »

caf wrote: post #52
delinka wrote: post #51

Earlier quoted context omitted.

It does indeed put restrictions on the software author not to expect hardware to be ready in less than 10ms. Perhaps the specification is somewhat nonsensical. That does not permit the software author to create restrictive interpretations. IMHO, it informs the software author that flexibility should be allowed in their code.

But under your interpretation, the software can't expect the hardware to be ready in less than 100ms, 10s or 10 minutes either - so the value "10ms" is meaningless.

Indeed. And the software should continue to wait for readiness or decide when to give up. Giving up at the 10ms mark isn't against spec, it's just not prudent.

Re: Linux may have been causing USB disconnects

#94

Post by demiol »

milliams wrote: post #66
kalleboo wrote: 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.

Optimized for "white on black" color scheme. http://marc.info/?q=configure

Re: Linux may have been causing USB disconnects

#95

Post by kalleboo »

demiol wrote: post #94
milliams wrote: post #66

Earlier quoted context omitted.

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.

Optimized for "white on black" color scheme. http://marc.info/?q=configure

That still looks terrible, hehe

Re: Linux may have been causing USB disconnects

#96

Post by Sheepshow »

dubcanada wrote: post #46
raverbashing wrote: post #30

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.

> You can't design a driver for a card without knowing everything about the card

Strongly disagree with that statement, though I sincerely wish it were true. My company manufactures hardware and does not provide a reference driver for any OS. We provide binary blobs and textual "guidelines".

For our hardware, driver authors operate without knowing any details beyond the interface.

Re: Linux may have been causing USB disconnects

#97

Post by SimHacker »

fixedd wrote: post #72
bryanlarsen wrote: post #2

Note that this bug was found because the software engineer talked to a hardware engineer. Props to Intel for hiring leading Linux developers and turning them loose.

Sarah's pretty sharp. IIRC, she single handedly built Linux's USB 3 support.

She must use VI instead of Emacs. Emacs requires more hands for all the modifier keys.

Re: Linux may have been causing USB disconnects

#98

Post by shabble »

SimHacker wrote: post #97
fixedd wrote: post #72

Earlier quoted context omitted.

Sarah's pretty sharp. IIRC, she single handedly built Linux's USB 3 support.

She must use VI instead of Emacs. Emacs requires more hands for all the modifier keys.

http://www.emacswiki.org/emacs/FootSwitches

Re: Linux may have been causing USB disconnects

#99

Post by shabble »

caf wrote: post #48
delinka wrote: 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.

That interpretation doesn't seem to make much sense though, because there would be no point in specifying the 10ms at all - it means nothing, and doesn't put any restrictions on anyone.

An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be expedient) do all sorts of otherwise spec-violating things, safe in the knowledge that nobody will ever find out[2]. After that grace period, it has to go back to playing by the rules, but doesn't necessarily have to be operational. Whether or not it's operational yet can be queried[1] (after the first timeout), and a decision to use it, retry the query after a fixed or variable additional fallback, or mark it as failed.

A better spec might recommend or mandate values for fallback quanta and repetitions, or a maximum bound on the delay, rather than leaving it vendor-gets-to-choose.

I didn't look too hard, but a decently marked timing diagram would be nice, and might make it easier to spot the unbounded nature of it, rather than having to cross-reference the inline '10ms' value with the minmax table elsewhere.

[1] At least, if I understand it correctly. If accessing the status info uses the same mechanism as general traffic, it's obviously subject to the flaw described, and this interpretation is wrong.

[2] c.f. https://en.wikipedia.org/wiki/Don%27t-care_term and perhaps https://en.wikipedia.org/wiki/Virtual_particle

Re: Linux may have been causing USB disconnects

#100

Post by Jugurtha »

exDM69 wrote: post #39
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,…

I'm not familiar with the USB spec. It happened I did tear-downs of flashdrives to find-out which ucontroller there is and try to dump stuff, etc... (For anyone interested, look up VID:PID and Google some microcontroller chip. It's a fascinating world where Russians are very present).

Your second comment about a lot of hw initialization being based on polling gives place to an "a fortiori": Why cascade this necessary evil to software. It's true, in the beginning, writing code for microcontrollers, you avoid working with interrupts. You work with assembly language, and get a bit lazy and hard-code delays (and even then, I'd choose a longer delay than the one specified as "max" in the datasheet : it's not like a chip not performing as well as is written in a datasheet never happened, so I take my precautions).

But then battery life reminds you of bad code practice: This continuous polling is draining. (And you put the uc to sleep :) )

Even more, if the application's involving sensors there's no way around using interrupts. Unless the thing is powered by a wall-socket, but even then, you get your consciousness preventing you from sleeping at night thinking about that horrible, barbarian code you put in there.

But then again, I don't know the USB spec and this may change so it's cool. And they have come a long way.

Post reply on HN