[deleted]
Linux may have been causing USB disconnects
41–50 of 123 posts
Re: Linux may have been causing USB disconnects
#42Earlier 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.
Which depends on the cases tested by Sharp – as the GP, depending on the hardware you use, you can probably get 100% or 0% (if you try really hard).
Re: Linux may have been causing USB disconnects
#43Now 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…
If you are connecting to a remote system, it could be NAT configured badly on your router.
The router provided by my ISP (Virgin Media) is ruthless at closing idle TCP connections after only a few minutes. I'd see this with idle SSH logins being closed all the time.
The solution (for me at least) was to ensure connections used TCP keepalives, and vastly decrease the keepalive times (various sysctl calls, I don't have the details to hand).
Re: Linux may have been causing USB disconnects
#44this 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 t…
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.
"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)"
Re: Linux may have been causing USB disconnects
#45Now 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…
not sure what you mean exactly, but one thing that has caused tons of trouble here, with sometimes the sole solution being a restart (ok our IT maintainer might be doing something worng, yet..) is the opposite: take a bunch of workstations and a bunch of servers, put home directories and data on servers then put everything together using NFS shares. Run analysis and whatnot on the data. Then make the server go down somehow and watch all workstation getting completely locked up without seemingly ever generating some kind of timeout error instead waiting endlessly on a dead connection.
Re: Linux may have been causing USB disconnects
#46Note 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 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.
Re: Linux may have been causing USB disconnects
#47Its 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+ ?
For whatever reason, there seems to be a number of Linux people on Google Plus, including Linus Torvalds.
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.
Re: Linux may have been causing USB disconnects
#48this 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 t…
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.
Re: Linux may have been causing USB disconnects
#49Earlier 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.
"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)"
But the "recovery interval" is not defined, leaving the device to decide what its "recovery interval" is and guaranteeing that software will not expect it to be less than 10ms.
Re: Linux may have been causing USB disconnects
#50Earlier 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.
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.