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

21–30 of 123 posts

Re: Linux may have been causing USB disconnects

#21

Post by username42 »

rustynails wrote: post #9

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 occu…

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.

Re: Linux may have been causing USB disconnects

#22

Post by miga »

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

Re: Linux may have been causing USB disconnects

#23

Post by masklinn »

RyanZAG wrote: post #19
annnnd wrote: post #3

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

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.

Re: Linux may have been causing USB disconnects

#24

Post by miga »

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.

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!

Re: Linux may have been causing USB disconnects

#25

Post by valisystem »

alexchamberlain wrote: post #11

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

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.

Re: Linux may have been causing USB disconnects

#26

Post by miga »

masklinn wrote: post #23
RyanZAG wrote: 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.

I add it to my list of hard-to-replicate-and-locate bugs then.

Re: Linux may have been causing USB disconnects

#27

Post by viraptor »

rustynails wrote: post #9

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 occu…

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

Re: Linux may have been causing USB disconnects

#29

Post by bluesign »

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.

Re: Linux may have been causing USB disconnects

#30

Post by raverbashing »

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.

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

Post reply on HN