8 ms·

Linux may have been causing USB disconnects

331 points by chalst 13y ago

bryanlarsen 13y ago
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.
- miga 13y ago
  It is always reason to celebrate when one engineer successfully communicates with another of different specialty. Big kudos to Intel for actually encouraging them to do so!
- raverbashing 13y ago
  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 something specific in software (in the HDMI standard - or better, things from the standard inherited from things like VESA) The Software Engineer see ports/memory to be written to and doesn't know what happens behind that The Hardware engineer sees the "chip" and its connections but doesn't realise the rabbit hole goes deeper "ah this is a simple USB device, only 8 pins" now try communicating with it
  - dubcanada 13y ago
    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.
    - raverbashing 13y ago
      True, but those examples you cited are the minority. Some software engineer working with drivers are distant from the hardware developers (especially in Linux) and even inside corporations there's a wall somewhere. And of course, sometimes there's an abstraction between hardware and driver (usually through a firmware). Commonly relating to a standard, like USB storage, ATAPI, etc " You can't make a piece of hardware without thinking about how the driver will work." Unfortunately I've had to work with some devices that had very hard requirements on the software (basically, response time) (or you would add extra hardware to deal with it). In the second revision this problem was "fixed" by increasing a certain buffer size. So yeah, sometimes hardware engineers don't think about that comprehensively enough.
    - stinos 13y ago
      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.
      - tytso 13y ago
        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".) Maybe there's so much complexity in the software stack that we can't start CS majors starting from the hardware level any more, but I can't help thinking we've lost something as a result. These days, there are Java programmers who get that "deer in headlights" look when confronted with terms such as "cache line miss".
        uhno 13y ago
- fixedd 13y ago
  Sarah's pretty sharp. IIRC, she single handedly built Linux's USB 3 support.
  - SimHacker 13y ago
    She must use VI instead of Emacs. Emacs requires more hands for all the modifier keys.
    - shabble 13y ago
      http://www.emacswiki.org/emacs/FootSwitches http://www.emacswiki.org/emacs/FootSwitches
      - sliverstorm 13y ago
        I can't tell. Is this a joke? Is this for real?
        laichzeit0 13y ago
        It's real. I think jwz uses foot pedals. People should just remap annoying keys, e.g. CAPS -> CTRL
annnnd 13y ago
Congrats! But how nobody analysed this bug for 8+ years is a bit of a mystery to me...
- JoeAltmaier 13y ago
  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/specs all the time. There are probably 100s of folks who knew about this and dealt with it (bumped the timeout in their embedded kernel to match the devices they support) and never said anything to anybody.
  - masklinn 13y ago
    In this case, the pain point was apparently a ChromeOS device: http://marc.info/?l=linux-usb&m=137714769606183&w=2 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.
  - nutate 13y ago
    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)
- RyanZAG 13y ago
  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 suddenly the test will fail the day after. When the test case mysteriously fails randomly like that on only a subset of devices, the assumption is that the hardware is faulty. These kind of failures would likely be higher on lower quality, less optimized hardware as well, furthering the perception. As far as I can tell, the reason this is fixed now is because known good hardware from Intel started exhibiting the same error which got people at Intel to track it down directly, as they knew it wasn't their hardware at fault.
oakwhiz 13y ago
This is a very interesting type of bug that I have often seen cropping up around hardware interfaces in microcontrollers.
makomk 13y ago
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.
- nknighthb 13y ago
  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.
  - acchow 13y ago
    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.
    - Zikes 13y ago
      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?
      - sliverstorm 13y ago
        I could simply be budgeting room for the USB core itself to wake.
      - davidp 13y ago
        I imagine it's something along the lines of "ok device, you have 10ms to play with the link before anyone's watching, do what you need to do." For example, electrically detecting the wattage of the power supplied over the link by examining its responses to various inputs. (I have no idea whether that's at all relevant here or if it's even the right part of the stack, I'm just offering an idea of why the device might like the controller to say "I'm not watching right now".)
deleted 13y ago
[deleted]
Jugurtha 13y ago
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.
- alexchamberlain 13y ago
  That's not entirely fair; standards are full of hard coded values.
  - adestefan 13y ago
    Especially timer values.
  - masklinn 13y ago
    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)
- JoeAltmaier 13y ago
  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.
  - barrkel 13y ago
    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.
- zwdr 13y ago
  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.
kalleboo 13y ago
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 http://marc.info/?l=linux-usb&m=137714769606183&w=2
- milliams 13y ago
  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.
  - veeti 13y ago
    GNU/Design.
  - demiol 13y ago
    Optimized for "white on black" color scheme. http://marc.info/?q=configure http://marc.info/?q=configure
    - kalleboo 13y ago
      That still looks terrible, hehe
      - k1chy 13y ago
        Use this http://marc.info/?l=linux-usb&m=137714769606183&q=raw http://marc.info/?l=linux-usb&m=137714769606183&q=raw
  - 1337hax0ll 13y ago
    I can read the website perfectly fine. It may not be shiny like all the iCrap, but it doesn't need to attract "average" users (e.g. spoiled, rich 12-year olds). I would rather prefer kernel hackers to do something useful, instead of wasting time and money to make every LKML archive look aesthetically beautiful. hackers != designers
rustynails 13y ago
Now can someone fix the embarrassing network bug in Linux. You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. It still begs belief that such a fundamental aspect of Linux is broken ... When I show Linux to newbies and this fault occurs (ie. 100% of the time), I simply say "Linux isn't perfect ..." But inside, I cringe... It occurs under all distros I've tried and it's been there for years. Even on different computers with different hardware...
- vidarh 13y ago
  I have TCP connections that have stayed open for months so this is highly unlikely to be a kernel issue. I have no idea what you might be running into as I've never seen anything like that occurring.
- octo_t 13y ago
  backing the previous poster here, I've never experienced anything like this at all. "Network error" makes it sound like you're using KDE or GNOME or something, or Samba isn't liking your configuration...
- eksith 13y ago
  That's an odd. Have you eliminated all other variables E.G. Common utility/setting, cabling, switch/router etc..? I've had paths open for much longer than that without access issues.
- username42 13y ago
  Never had such error. Even in Linux 0.99pl10 (in 1992), network was working fine. I have always used a lot remote access to X servers. If network was broken, Linux would have been unusable.
- viraptor 13y ago
  > You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. I don't even know what this means. What's the actual, reproducible scenario?
alexchamberlain 13y ago
We should applaud them for standing up and saying "Hey, we cocked up, sorry!"
- valisystem 13y ago
  Definitely yes. Them or others, whatever. And Not for every issues. But I want to ear about issues that have been worrying for a long time and/or annoyed a lot of people, or that are very complex and shady. And the only way to encourage communication about bugs is to congratulate people for their fixes/problem isolation.
- scrrr 13y ago
  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? :)
  - jaredmcateer 13y ago
    Maybe if we did more people would be willing to do it.
  - sghill 13y ago
    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.
miga 13y ago
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?)
- Fuxy 13y ago
  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.
  - Someone 13y ago
    "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.
    - Fuxy 13y ago
      Well given that 90% of hardware out there is supported just file with the current setting i suspect 50ms would qualify as quite paranoid.
ape4 13y ago
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+ ?
- davidw 13y ago
  For whatever reason, there seems to be a number of Linux people on Google Plus, including Linus Torvalds.
  - archivator 13y ago
    And Android people, and various YouTube people, and Internet celebrities and ... That said, G+ is not half bad. The app beats Facebook hands down. Live Hangouts are also a neat way to engage with your audience.
bluesign 13y ago
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 to the port is expected to respond to data transfers. The device may ignore any data transfers during the recovery interval. After the end of the recovery interval (measured from the end of the reset or the end of the EOP at the end of the resume signaling), the device must accept data transfers at any time.
- delinka 13y ago
  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.
  - masklinn 13y ago
    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.
    - makomk 13y ago
      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.
  - bluesign 13y ago
    "After the end of the recovery interval the device must accept data transfers at any time." simply says that "hardware must be ready (in order to accept data transfer)"
deleted 13y ago
[deleted]
foobarqux 13y ago
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?
- baq 13y ago
  it happens after a resume from sleep?
  - foobarqux 13y ago
    No. I'm typing or trying to type and it becomes unresponsive. Can't even toggle the caps and num lock LEDs on the keyboard.
- blaenk 13y ago
  For what it's worth, I too have a Das Keyboard (Ultimate) and I don't experience this problem (Arch 64-bit). Hopefully that helps narrow down your issue.
  - foobarqux 13y ago
    Thanks. I'm on 32-bit Ubuntu 13.04 but problem has presented itself for at least last several releases.
T3RMINATED 13y ago
you are probably going to get the middle finger from Linus Torvald and he will say it was built like this by design and your wrong.
codex 13y ago
This is alarming. If the issue really was that simple, it strongly indicates that Linux kernel developers don't put a lot of effort into investigating problems whenever a convenient scapegoat--faulty hardware--is available. For shame.

331 points by chalst 13y ago

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.

miga 13y ago
It is always reason to celebrate when one engineer successfully communicates with another of different specialty. Big kudos to Intel for actually encouraging them to do so!
raverbashing 13y ago
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 something specific in software (in the HDMI standard - or better, things from the standard inherited from things like VESA) The Software Engineer see ports/memory to be written to and doesn't know what happens behind that The Hardware engineer sees the "chip" and its connections but doesn't realise the rabbit hole goes deeper "ah this is a simple USB device, only 8 pins" now try communicating with it
- dubcanada 13y ago
  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.
  - raverbashing 13y ago
    True, but those examples you cited are the minority. Some software engineer working with drivers are distant from the hardware developers (especially in Linux) and even inside corporations there's a wall somewhere. And of course, sometimes there's an abstraction between hardware and driver (usually through a firmware). Commonly relating to a standard, like USB storage, ATAPI, etc " You can't make a piece of hardware without thinking about how the driver will work." Unfortunately I've had to work with some devices that had very hard requirements on the software (basically, response time) (or you would add extra hardware to deal with it). In the second revision this problem was "fixed" by increasing a certain buffer size. So yeah, sometimes hardware engineers don't think about that comprehensively enough.
  - stinos 13y ago
    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.
    - tytso 13y ago
      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".) Maybe there's so much complexity in the software stack that we can't start CS majors starting from the hardware level any more, but I can't help thinking we've lost something as a result. These days, there are Java programmers who get that "deer in headlights" look when confronted with terms such as "cache line miss".
      - uhno 13y ago
fixedd 13y ago
Sarah's pretty sharp. IIRC, she single handedly built Linux's USB 3 support.
- SimHacker 13y ago
  She must use VI instead of Emacs. Emacs requires more hands for all the modifier keys.
  - shabble 13y ago
    http://www.emacswiki.org/emacs/FootSwitches http://www.emacswiki.org/emacs/FootSwitches
    - sliverstorm 13y ago
      I can't tell. Is this a joke? Is this for real?
      - laichzeit0 13y ago
        It's real. I think jwz uses foot pedals. People should just remap annoying keys, e.g. CAPS -> CTRL

annnnd 13y ago

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

JoeAltmaier 13y ago
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/specs all the time. There are probably 100s of folks who knew about this and dealt with it (bumped the timeout in their embedded kernel to match the devices they support) and never said anything to anybody.
- masklinn 13y ago
  In this case, the pain point was apparently a ChromeOS device: http://marc.info/?l=linux-usb&m=137714769606183&w=2 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.
- nutate 13y ago
  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)
RyanZAG 13y ago
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 suddenly the test will fail the day after. When the test case mysteriously fails randomly like that on only a subset of devices, the assumption is that the hardware is faulty. These kind of failures would likely be higher on lower quality, less optimized hardware as well, furthering the perception. As far as I can tell, the reason this is fixed now is because known good hardware from Intel started exhibiting the same error which got people at Intel to track it down directly, as they knew it wasn't their hardware at fault.

oakwhiz 13y ago

This is a very interesting type of bug that I have often seen cropping up around hardware interfaces in microcontrollers.

makomk 13y ago

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.

nknighthb 13y ago
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.
- acchow 13y ago
  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.
  - Zikes 13y ago
    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?
    - sliverstorm 13y ago
      I could simply be budgeting room for the USB core itself to wake.
    - davidp 13y ago
      I imagine it's something along the lines of "ok device, you have 10ms to play with the link before anyone's watching, do what you need to do." For example, electrically detecting the wattage of the power supplied over the link by examining its responses to various inputs. (I have no idea whether that's at all relevant here or if it's even the right part of the stack, I'm just offering an idea of why the device might like the controller to say "I'm not watching right now".)

deleted 13y ago

[deleted]

Jugurtha 13y ago

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.

alexchamberlain 13y ago
That's not entirely fair; standards are full of hard coded values.
- adestefan 13y ago
  Especially timer values.
- masklinn 13y ago
  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)
JoeAltmaier 13y ago
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.
- barrkel 13y ago
  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.
zwdr 13y ago
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.

kalleboo 13y ago

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 http://marc.info/?l=linux-usb&m=137714769606183&w=2

milliams 13y ago
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.
- veeti 13y ago
  GNU/Design.
- demiol 13y ago
  Optimized for "white on black" color scheme. http://marc.info/?q=configure http://marc.info/?q=configure
  - kalleboo 13y ago
    That still looks terrible, hehe
    - k1chy 13y ago
      Use this http://marc.info/?l=linux-usb&m=137714769606183&q=raw http://marc.info/?l=linux-usb&m=137714769606183&q=raw
- 1337hax0ll 13y ago
  I can read the website perfectly fine. It may not be shiny like all the iCrap, but it doesn't need to attract "average" users (e.g. spoiled, rich 12-year olds). I would rather prefer kernel hackers to do something useful, instead of wasting time and money to make every LKML archive look aesthetically beautiful. hackers != designers

rustynails 13y ago

Now can someone fix the embarrassing network bug in Linux. You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. It still begs belief that such a fundamental aspect of Linux is broken ... When I show Linux to newbies and this fault occurs (ie. 100% of the time), I simply say "Linux isn't perfect ..." But inside, I cringe... It occurs under all distros I've tried and it's been there for years. Even on different computers with different hardware...

vidarh 13y ago
I have TCP connections that have stayed open for months so this is highly unlikely to be a kernel issue. I have no idea what you might be running into as I've never seen anything like that occurring.
octo_t 13y ago
backing the previous poster here, I've never experienced anything like this at all. "Network error" makes it sound like you're using KDE or GNOME or something, or Samba isn't liking your configuration...
eksith 13y ago
That's an odd. Have you eliminated all other variables E.G. Common utility/setting, cabling, switch/router etc..? I've had paths open for much longer than that without access issues.
username42 13y ago
Never had such error. Even in Linux 0.99pl10 (in 1992), network was working fine. I have always used a lot remote access to X servers. If network was broken, Linux would have been unusable.
viraptor 13y ago
> You know, where if you access a link to a network, or access an open networked path after 255 seconds or so ... You receive a network error. I don't even know what this means. What's the actual, reproducible scenario?

alexchamberlain 13y ago

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

valisystem 13y ago
Definitely yes. Them or others, whatever. And Not for every issues. But I want to ear about issues that have been worrying for a long time and/or annoyed a lot of people, or that are very complex and shady. And the only way to encourage communication about bugs is to congratulate people for their fixes/problem isolation.
scrrr 13y ago
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? :)
- jaredmcateer 13y ago
  Maybe if we did more people would be willing to do it.
- sghill 13y ago
  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.

miga 13y ago

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?)

Fuxy 13y ago
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.
- Someone 13y ago
  "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.
  - Fuxy 13y ago
    Well given that 90% of hardware out there is supported just file with the current setting i suspect 50ms would qualify as quite paranoid.

ape4 13y ago

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+ ?

davidw 13y ago
For whatever reason, there seems to be a number of Linux people on Google Plus, including Linus Torvalds.
- archivator 13y ago
  And Android people, and various YouTube people, and Internet celebrities and ... That said, G+ is not half bad. The app beats Facebook hands down. Live Hangouts are also a neat way to engage with your audience.

bluesign 13y ago

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 to the port is expected to respond to data transfers. The device may ignore any data transfers during the recovery interval. After the end of the recovery interval (measured from the end of the reset or the end of the EOP at the end of the resume signaling), the device must accept data transfers at any time.

delinka 13y ago
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.
- masklinn 13y ago
  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.
  - makomk 13y ago
    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.
- bluesign 13y ago
  "After the end of the recovery interval the device must accept data transfers at any time." simply says that "hardware must be ready (in order to accept data transfer)"

deleted 13y ago

[deleted]

foobarqux 13y ago

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?

baq 13y ago
it happens after a resume from sleep?
- foobarqux 13y ago
  No. I'm typing or trying to type and it becomes unresponsive. Can't even toggle the caps and num lock LEDs on the keyboard.
blaenk 13y ago
For what it's worth, I too have a Das Keyboard (Ultimate) and I don't experience this problem (Arch 64-bit). Hopefully that helps narrow down your issue.
- foobarqux 13y ago
  Thanks. I'm on 32-bit Ubuntu 13.04 but problem has presented itself for at least last several releases.

T3RMINATED 13y ago

you are probably going to get the middle finger from Linus Torvald and he will say it was built like this by design and your wrong.

codex 13y ago

This is alarming. If the issue really was that simple, it strongly indicates that Linux kernel developers don't put a lot of effort into investigating problems whenever a convenient scapegoat--faulty hardware--is available. For shame.