User avatar
piglet
Posts: 913
Joined: Sat Aug 27, 2011 1:16 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 8:56 am

Just back from two weeks holiday and catching up on progress. There's been some really good reporting, diagnosis and fix progress information in this thread. Great news.

Unfortunately there's also been a lot of whining and trolling.

Please can we have more of the former and less of the latter? It doesn't help. I'd definitely support some more active pruning of this kind of thread to remove the moaning and carping or to move it to its own thread "Winging and whining about USB issues" which we can then just ignore if we choose....

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 12:33 pm

Why not move the success stories to another Threat? After all, this is the Troubleshooting section and there are problems with USB. Remove those and you can clean up half of the troubleshooting section.
It's the people saying "It works fine for me" that are actually trolling.
This isn't really helpfull information if you happen to have problems.

So ok, the Pi isn't to slow for it's usb. It are the usb host drivers.

If it would be a fault in silicium, than the chip makers are responsable.
But, both "usb host" silicium implementation and the otg driver come from the same firm...
So, I think everybody agrees that the problem it's origin should come from the synopsis, either "usb host" implementation or driver? Leaving it as an open question to the readers why nobody from the foundation or Broadcom seems to contact them?

What is more enoying to me is the fact that there is no decent knowledge of what is supposed to work and what is supposed to give issues. The information about possible fixes is spread all over the forum, and there is enough to keep you busy for a couple of weeks trying things out, but nothing really seems to help reliable.
So it's not about whining and trolling.. It's about warning people that in it's current state, the Pi is nothing more than a gadget for educational purposes, due to it's usb problems. If the foundation chooses to ignore this issues (which I doubt, but who am I), than they should inform us about it and stop telling that the Pi can do what any other desktop pc can do. Farnell and RS components are not exactly chinese web firms selling "el cheapo" gadget electronics. If something from such a firm has issues, nobody is suprised. This is different.

lostintime
Posts: 29
Joined: Sun Jul 22, 2012 7:30 am

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 12:44 pm

jamesh wrote:
pluggy wrote:I went as far as soldering bypass shunts on the polyfuses and powering the Pi through the GPIO pins to try and get one of my 4 webcams to work reliably. Powered hubs tend to cause as many problems as they solve. They all work for a short period before croaking with segmentation faults and dmesg full of error messages. I'd rather they did the USB and Ethernet properly with some extra silicon (and mainstream drivers) and charge a bit more for it. They sold out to get the price down in my opinion.

I fear people might judge Linux by the Pi, and having used Linux for 10+ years and now use it exclusively on all my computers, I know Linux works, its the Pi that doesn't.
Not true at all. This almost certainly isn't a silicon problem, it's a driver problem.
It doesn't matter. Whether or not it's a software or hardware problem it is most likely going to go unresolved. There are other devices which utilize the same USB controller as the Raspberry Pi and in the past there have been efforts made to fix the bugs in the vendor-supplied driver for this controller and also to replace it with a new driver written from scratch. So far nobody has achieved very much and it stands to reason that this situation will not change.
But the contract As far as the Raspi foundation are concerned, when the board was designed and tested, it all worked, so there was no reason to believe any more money needed to be spend on different components.
I encountered major USB/Ethernet problems within an hour or so of first booting my Raspberry Pi with just an Ethernet cable and a keyboard and mouse attached via a USB hub to it. This is hardly an esoteric setup and it makes me question the competence of the testers and the thoroughness of their testing if they never experienced the issues that I and many others have.
And for most people the Pi does work. Stop being overly dramatic. Your particular use case might not work yet, but a lot of others do.
The Raspberry Pi certainly works for some, including me, but it doesn't work as well as it should do. Workarounds involving additional expense are often necessary with the Pi that seemingly aren't necessary with anything else.

hippy
Posts: 6853
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 12:45 pm

jamesh wrote:And for most people the Pi does work. Stop being overly dramatic. Your particular use case might not work yet, but a lot of others do.
I have to agree, but from the other side of the fence it likely does sound a bit like, "We are sorry the wheels fell off your car. Other people's wheels don't fall off and we will fix the cases where they do some time in the future". It's their case they are concerned with, not others'.

The root problem IMO continues to be people not understanding what a "Development Board" is and having far greater expectations than they should. As I've said before; it really would help if Licensee Manufacturers made it clear that it is a "Development Board" and explained what that means. The more they sell, the more people who don't fully understand what it is they are buying, the more people will complain about things which they expect to work but don't.

I really don't understand the reluctance of Licensee Manufacturers selling boards to make it clear it is a "Development Board". I'll admit it took me a long time to fully understand what that meant for the Pi and it seems a lot of people still don't.

lostintime
Posts: 29
Joined: Sun Jul 22, 2012 7:30 am

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:02 pm

obcd wrote:What is more enoying to me is the fact that there is no decent knowledge of what is supposed to work and what is supposed to give issues. The information about possible fixes is spread all over the forum, and there is enough to keep you busy for a couple of weeks trying things out, but nothing really seems to help reliable.
So it's not about whining and trolling.. It's about warning people that in it's current state, the Pi is nothing more than a gadget for educational purposes, due to it's usb problems.
I agree with you that the Raspberry Pi is "a gadget for educational purposes", but only for geeks and/or enthusiasts. In its current state it isn't suitable for students who just wish to develop their programming skills and have no time or interest in troubleshooting an unreliable system. This is a big problem for the Raspberry Pi Foundation since they are clearly wanting the Pi to have an impact in schools.

lostintime
Posts: 29
Joined: Sun Jul 22, 2012 7:30 am

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:10 pm

hippy wrote:The root problem IMO continues to be people not understanding what a "Development Board" is and having far greater expectations than they should.
That's just it though, the Raspberry Pi is supposed to be a finished product, albeit one without a case. It's not supposed to be a prototype.

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:12 pm

Development boards are mostly used to promote a processor. The manufacturer made a reference design with it so that people can experement with all the features of that processor. (Can be an fpga as well). It usually comes with software demonstrating all the features and options of the chip. If one of those doesn't work, the manufacturer will listen to the user as it's not good advertising for his chip if a feature doesn't work like it should. A Development board makes it possible to start to use a chip, without the need to design a board for it.
If a development board has usb host connectors and is told to be usb compliant, than I expect those usb host ports to work with usb compliant devices. At least with a 4 port hub, a mouse and a keyboard, it should work. Isn't that the setup they are promoting for educational purpose in the classroom? I can understand that connecting 16 usb serial ports or 5 usb wifi sticks gives issues, but usually a development board comes with detailed information about what is possible and what isn't.
If the Pi would need to be seen as a Development board, than why are the graphic core drivers a closed binary blob? I see it more as an OEM module here. It's up to you to provide the needed power and the case...It still is no excuse for not functionning properly.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25439
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:18 pm

lostintime wrote:
jamesh wrote:
pluggy wrote:I went as far as soldering bypass shunts on the polyfuses and powering the Pi through the GPIO pins to try and get one of my 4 webcams to work reliably. Powered hubs tend to cause as many problems as they solve. They all work for a short period before croaking with segmentation faults and dmesg full of error messages. I'd rather they did the USB and Ethernet properly with some extra silicon (and mainstream drivers) and charge a bit more for it. They sold out to get the price down in my opinion.

I fear people might judge Linux by the Pi, and having used Linux for 10+ years and now use it exclusively on all my computers, I know Linux works, its the Pi that doesn't.
Not true at all. This almost certainly isn't a silicon problem, it's a driver problem.
It doesn't matter. Whether or not it's a software or hardware problem it is most likely going to go unresolved. There are other devices which utilize the same USB controller as the Raspberry Pi and in the past there have been efforts made to fix the bugs in the vendor-supplied driver for this controller and also to replace it with a new driver written from scratch. So far nobody has achieved very much and it stands to reason that this situation will not change.
But the contract As far as the Raspi foundation are concerned, when the board was designed and tested, it all worked, so there was no reason to believe any more money needed to be spend on different components.
I encountered major USB/Ethernet problems within an hour or so of first booting my Raspberry Pi with just an Ethernet cable and a keyboard and mouse attached via a USB hub to it. This is hardly an esoteric setup and it makes me question the competence of the testers and the thoroughness of their testing if they never experienced the issues that I and many others have.
And for most people the Pi does work. Stop being overly dramatic. Your particular use case might not work yet, but a lot of others do.
The Raspberry Pi certainly works for some, including me, but it doesn't work as well as it should do. Workarounds involving additional expense are often necessary with the Pi that seemingly aren't necessary with anything else.
What makes you think that this will go unresolved? There are very clever people working on it right now. Please keep your unfounded allegations to yourself.

With regard to testing - there is no possible way everything could have been tested with every USB gadget. I don't encounter problems with exactly the same setup you describe. Neither did anyone else. Was my testing inadequate? Also please do NOT comment on the competence of the testing as you are commenting on the competency of yourself! Remember that this stage of the project, it was fully expected to find issues, that was required as the Foundation was not able to test every combination - we are in the testing stage after all, as was fully explained prior to launch. So I would go as far to say the testing was going well as its finding some quite interesting issues, which go forward to be fixed.
What you also really need to consider, is how many boards are out there vs how many people are seeing problems. That figure is an unknown, but probably less than 1%. Difficult to pick up in pre-release testing when you have no employees and limited funds.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25439
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:19 pm

obcd wrote:Development boards are mostly used to promote a processor.
Not true. Which means the rest of your post is based on a false premise.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Aydan
Posts: 710
Joined: Fri Apr 13, 2012 11:48 am
Location: Germany, near Lake Constance

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:45 pm

Aydan wrote:Hi,

I have a few findings concerning staggered hubs.
Have a look here http://www.raspberrypi.org/phpBB3/viewt ... 71#p151571

Regards
Aydan
I'm gonna bump this again. I think it got overlooked a bit. Only three downloads and no comments so far.
I had hoped this might shed some more light onto the USB and hub situation.
If it is irrelevant then say so. I just don't want something potentially useful get drowned out by all the moaning going on here.

Regards
Aydan

lostintime
Posts: 29
Joined: Sun Jul 22, 2012 7:30 am

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:46 pm

jamesh wrote:What makes you think that this will go unresolved? There are very clever people working on it right now. Please keep your unfounded allegations to yourself.
Did you read the last two sentences in the first paragraph of my response to you? Here it is again:
lostintime wrote:There are other devices which utilize the same USB controller as the Raspberry Pi and in the past there have been efforts made to fix the bugs in the vendor-supplied driver for this controller and also to replace it with a new driver written from scratch. So far nobody has achieved very much and it stands to reason that this situation will not change.
It isn't an allegation, it's a prediction and I stand by it. Prove me wrong, please.
With regard to testing - there is no possible way everything could have been tested with every USB gadget.
I wasn't suggesting this, nor would a reasonable person expect it.
I don't encounter problems with exactly the same setup you describe. Neither did anyone else. Was my testing inadequate?
Would you like to take a poll to find out how many others have?
Also please do NOT comment on the competence of the testing as you are commenting on the competency of yourself!
I don't understand what you're getting at here.

hippy
Posts: 6853
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 1:54 pm

lostintime wrote:
Also please do NOT comment on the competence of the testing as you are commenting on the competency of yourself!
I don't understand what you're getting at here.
That's the nature of the "Development Board"; whether it does what it is expected to or not is revealed in the using of it. The users ( you, me, everyone else ) are in effect the testers of it. It's what others would call a public beta and similar.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25439
Joined: Sat Jul 30, 2011 7:41 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 2:08 pm

lostintime wrote:
jamesh wrote:What makes you think that this will go unresolved? There are very clever people working on it right now. Please keep your unfounded allegations to yourself.
Did you read the last two sentences in the first paragraph of my response to you? Here it is again:
lostintime wrote:There are other devices which utilize the same USB controller as the Raspberry Pi and in the past there have been efforts made to fix the bugs in the vendor-supplied driver for this controller and also to replace it with a new driver written from scratch. So far nobody has achieved very much and it stands to reason that this situation will not change.
It isn't an allegation, it's a prediction and I stand by it. Prove me wrong, please.
Did those people have access to the RTL of the silicon? I don't believe so.
That's the extent to which this stuff is being investigated.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

dpws
Posts: 9
Joined: Sat Aug 18, 2012 2:11 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 2:18 pm

Just a bit of input on the USB issues I have found.

I've only had problems when transferring large amounts of data over USB. After a little while I get all kinds of errors, and my hard drive disappears from /dev/. The errors are along these lines:

Code: Select all

Aug 14 19:01:24 alarmpi kernel: [  594.106004] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.295998] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:24 alarmpi kernel: [  594.375984] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.645997] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.836005] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:25 alarmpi kernel: [  595.313523] usb 1-1.2.1: device not accepting address 6, error -71
Aug 14 19:01:25 alarmpi kernel: [  595.386009] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:25 alarmpi kernel: [  595.847761] Buffer I/O error on device sdb2, logical block 2844871
Aug 14 19:01:25 alarmpi kernel: [  595.847781] Buffer I/O error on device sdb2, logical block 2844872
Aug 14 19:01:25 alarmpi kernel: [  595.847800] Buffer I/O error on device sdb2, logical block 2844873

Code: Select all

Aug 14 18:47:19 alarmpi kernel: [ 1876.439851] scsi2 : usb-storage 1-1.2.1:1.0
Aug 14 18:47:51 alarmpi kernel: [ 1908.670686] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:56 alarmpi kernel: [ 1913.750698] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:57 alarmpi kernel: [ 1913.940698] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.130705] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1914.210688] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.401578] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.590702] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.043604] usb 1-1.2.1: device not accepting address 12, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1915.120698] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.679675] usb 1-1.2.1: device not accepting address 12, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1915.681818] scsi 2:0:0:0: Device offlined - not ready after error recovery
Aug 14 18:47:59 alarmpi kernel: [ 1915.683343] usb 1-1.2.1: USB disconnect, device number 12
Aug 14 18:47:59 alarmpi kernel: [ 1915.770710] usb 1-1.2.1: new high speed USB device number 13 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.850700] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.040752] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.230702] usb 1-1.2.1: new high speed USB device number 14 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1916.310694] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.500703] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.690701] usb 1-1.2.1: new high speed USB device number 15 using dwc_otg
Aug 14 18:48:00 alarmpi kernel: [ 1917.110361] usb 1-1.2.1: device not accepting address 15, error -71
Aug 14 18:48:00 alarmpi kernel: [ 1917.190713] usb 1-1.2.1: new high speed USB device number 16 using dwc_otg
Aug 14 18:48:00 alarmpi kernel: [ 1917.610359] usb 1-1.2.1: device not accepting address 16, error -71
Aug 14 18:48:00 alarmpi kernel: [ 1917.610716] hub 1-1.2:1.0: unable to enumerate USB device on port 1
These errors never occur, though, when transferring over the network, even wen transferring, in one case, around 100GB of data - presumably because the bottleneck becomes wifi throughput and usb transfer isn't maxed out. For my problem, a temporary fix would be some way to limit usb transfer speed to, say, 5 or 6 mb/s (this is my wifi throughput) and so avoid 'overloading' the usb. I have no idea how to do this though :P

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12664
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 2:41 pm

Just to rule out an overheating LAN chip (there has been a recent discovery that on some PI's the LAN chip uses 20% more energy than normal) when you get errors like these do they go away when you forcibly cool the LAN9512 chip down with "freezer spray" (AKA KALTE spray). If you don't have that take a bit of cottonwool or toilet paper and use some kind of alcohol (spirit) that can quickly evaporate to cool down the chip . Also a hones assessment of the relative temperatures of RG1 (near the pinheader), the SoC, and the LAN9512 chip would be welcome. I am almost embarrassed to ask this, as I am of the opinion that a finger is a poor thermometer, but how long you can but your finger on it before it starts to hurt would give us at least some feedback. (unless you happen to have a thermal camera handy that is LOL)

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 2:51 pm

I appreciate it's being examined up to the RTL of the silico, but I would like to know where I can find information upon it's progress.
Don't tell me to look in the github at issue 29, as that seems mostly fix attempts by independant individuals with linux kernel and driver design knowledge.

If the problem is interrupt latency, how can it be fixed in a non real time operating system?
It can be improved, that's sure, but the OS is not giving any guarantee that an interrupt can be handled within some time.
I hope I am wrong with previous assumption. As long as it's unknown, the engineer in me simply says to stop wasting time. That's why I would like to know if there is progress. lostintime seems to think in the same direction. People saying their usb speakers crackle less with the latest progress implemented, that's not progress for me. That's simply improvement of the latency.
Seeing the Pi as a 'development board' or a 'public beta' is an interesting theory.
I am trying to think of other public beta hardware designs, but can only see the term used in software? It again makes the Pi an innovative product as it opens a whole new market.

User avatar
Lob0426
Posts: 2198
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 3:12 pm

dpws wrote:Just a bit of input on the USB issues I have found.

I've only had problems when transferring large amounts of data over USB. After a little while I get all kinds of errors, and my hard drive disappears from /dev/. The errors are along these lines:

Code: Select all

Aug 14 19:01:24 alarmpi kernel: [  594.106004] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.295998] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:24 alarmpi kernel: [  594.375984] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.645997] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 19:01:24 alarmpi kernel: [  594.836005] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:25 alarmpi kernel: [  595.313523] usb 1-1.2.1: device not accepting address 6, error -71
Aug 14 19:01:25 alarmpi kernel: [  595.386009] usb 1-1.2.1: reset high speed USB device number 6 using dwc_otg
Aug 14 19:01:25 alarmpi kernel: [  595.847761] Buffer I/O error on device sdb2, logical block 2844871
Aug 14 19:01:25 alarmpi kernel: [  595.847781] Buffer I/O error on device sdb2, logical block 2844872
Aug 14 19:01:25 alarmpi kernel: [  595.847800] Buffer I/O error on device sdb2, logical block 2844873

Code: Select all

Aug 14 18:47:19 alarmpi kernel: [ 1876.439851] scsi2 : usb-storage 1-1.2.1:1.0
Aug 14 18:47:51 alarmpi kernel: [ 1908.670686] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:56 alarmpi kernel: [ 1913.750698] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:57 alarmpi kernel: [ 1913.940698] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.130705] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1914.210688] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.401578] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1914.590702] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.043604] usb 1-1.2.1: device not accepting address 12, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1915.120698] usb 1-1.2.1: reset high speed USB device number 12 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.679675] usb 1-1.2.1: device not accepting address 12, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1915.681818] scsi 2:0:0:0: Device offlined - not ready after error recovery
Aug 14 18:47:59 alarmpi kernel: [ 1915.683343] usb 1-1.2.1: USB disconnect, device number 12
Aug 14 18:47:59 alarmpi kernel: [ 1915.770710] usb 1-1.2.1: new high speed USB device number 13 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1915.850700] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.040752] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.230702] usb 1-1.2.1: new high speed USB device number 14 using dwc_otg
Aug 14 18:47:59 alarmpi kernel: [ 1916.310694] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.500703] usb 1-1.2.1: device descriptor read/64, error -71
Aug 14 18:47:59 alarmpi kernel: [ 1916.690701] usb 1-1.2.1: new high speed USB device number 15 using dwc_otg
Aug 14 18:48:00 alarmpi kernel: [ 1917.110361] usb 1-1.2.1: device not accepting address 15, error -71
Aug 14 18:48:00 alarmpi kernel: [ 1917.190713] usb 1-1.2.1: new high speed USB device number 16 using dwc_otg
Aug 14 18:48:00 alarmpi kernel: [ 1917.610359] usb 1-1.2.1: device not accepting address 16, error -71
Aug 14 18:48:00 alarmpi kernel: [ 1917.610716] hub 1-1.2:1.0: unable to enumerate USB device on port 1
These errors never occur, though, when transferring over the network, even wen transferring, in one case, around 100GB of data - presumably because the bottleneck becomes wifi throughput and usb transfer isn't maxed out. For my problem, a temporary fix would be some way to limit usb transfer speed to, say, 5 or 6 mb/s (this is my wifi throughput) and so avoid 'overloading' the usb. I have no idea how to do this though :P
A couple of questions:
Are you using WiFi exclusively for your network connection?
Are you using a hub? Most likely you are.
If you unplug your WiFi adapter does your HDD stay connected?

You may see an improvement by using the disable-ethernet script.
http://www.raspberrypi.org/phpBB3/viewt ... 51#p127151
Some hubs and the onboard hub (LAN9512) decide to fight with each other. The problem seems to be with the Ethernet adapter. Turning off the Ethernet usually solves the problem, but not always. Of course you need to be using the WiFi for your connection if this is going to work. There are instructions how to enable, disable the Ethernet adapter as you need it.
512MB version 2.0 as WordPress Server
Motorola Lapdock with Pi2B
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!

Max

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 3:28 pm

jamesh wrote: What you also really need to consider, is how many boards are out there vs how many people are seeing problems. That figure is an unknown, but probably less than 1%.
Or it may be 99%, but not many bothered to report it.
Especially if it happens infrequently and is not easy to reproduce (say a key repeat once every hour), let alone write a useful bug report about. It is not like a kernel panic with a backtrace you can make a photo of.
Or they may assume it might be their power supply (that is often blamed here), their hardware or Linux's general hardware support that is the problem, while it may not be.

Perhaps send out a questionaire to random people that purchased a Pi?

hippy
Posts: 6853
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 5:44 pm

obcd wrote:Seeing the Pi as a 'development board' or a 'public beta' is an interesting theory.
I am trying to think of other public beta hardware designs, but can only see the term used in software? It again makes the Pi an innovative product as it opens a whole new market.
Most "Finished Product" has the potential for undiscovered bugs and hardware issues, and having paid for the product we expect those bugs not to be there and to be fixed pronto when found. When some ability isn't there but promised for the future we expect it to be delivered in some timely fashion. We expect a finished product to genuinely be finished with only a little leeway.

As I see it: The Foundation took a principled stand in knowing the current iteration of the R-Pi may not be perfect in terms of either software or hardware and used "Development Board" to identify its status as such. It was simply acknowledging that, 'no, it's not a finished product yet, and some people may encounter problems but shouldn't expect issues to be resolved as if it were a finished product'. It's a 'we think it should work, know it works to a certain extent and can meets its primary goals. We know it will work beyond that but expect there may be some issues we haven't foreseen. If it works for you, great, if it doesn't we will do our best to resolve that, but there are no promises'. This is what I now interpret as meant by "no warranty"; no guarantee of a particular or specific fitness for purpose.

Once one understands the nature of the R-Pi as it currently is it puts a different light on things. We shouldn't expect perfection and that was never promised, some things might not work and we have to accept that, they'll do their best but there are no promises. There are not the obligations there might be if it were a finished product. This is a stepping stone towards a finished product.

So for USB and other issues; "it should work!", and I am sure the Foundation will readily agree, will try to ensure that it does, but they never promised that it would. They never promised anything would even be fixable though undoubtedly hope it is and have confidence it will be.

When one puts aside what one may personally expect of the R-Pi and looks at what was promised - and importantly not promised - consider what we chose to buy into at this time, it becomes easier to see it from the Foundation's perspective. That's not being an apologist for the Foundation; they simply never promised more than they have delivered.

Where I feel a disconnect lays though is two-fold; the lack of explanation as to its "Development Board" status at the point of sale, and the R-Pi being promoted and advertised in terms of *is* when arguably more correctly that should be *will be*. Perhaps *is hoped to be* but I have every confidence the Foundation will strive to deliver. Alternatively one could agree with *is* to some certain extent, but not for all cases.

Unless already understanding the nature of the current iteration of the R-Pi it can leave the impression it's a finished product when it's not. It will be, but it's not there yet.

If Mods or the Foundation feel I've misrepresented anything here please do correct me. It's how I've come to see things and my interpretation of that.

User avatar
Burngate
Posts: 6225
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 5:56 pm

There are people out there complaining that it is or isn't beta hardware, and that you wouldn't get that with proper commercial stuff.
So just my penny-worth.
So a company I worked for bought a whole set of bits,from a well-known company (well-known in the TV-world anyway) that was sold as capable of recording, editing, and playing out multiple streams via an automation system. For months afterward the well-known company's engineers spent eight-hour days seven days a week trying to get it to work. Eventually it was thrown out. And that was a good fraction of a million quid.

drgeoff
Posts: 10333
Joined: Wed Jan 25, 2012 6:39 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 6:10 pm

The cognescenti who were avidly following the RPi in the months prior to its 29 Feb launch may have implicitly understood the risks that it was not a finished product but can the same be said for the vast majority of the hundreds of thousands of purchasers who saw only the TV and press publicity on and just after that day?

That said, I'm not making a value judgement either way.

drgeoff
Posts: 10333
Joined: Wed Jan 25, 2012 6:39 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 6:14 pm

Burngate wrote:There are people out there complaining that it is or isn't beta hardware, and that you wouldn't get that with proper commercial stuff.
So just my penny-worth.
So a company I worked for bought a whole set of bits,from a well-known company (well-known in the TV-world anyway) that was sold as capable of recording, editing, and playing out multiple streams via an automation system. For months afterward the well-known company's engineers spent eight-hour days seven days a week trying to get it to work. Eventually it was thrown out. And that was a good fraction of a million quid.
So what happened to the money? Or are the lawyers still arguing about it?

User avatar
Burngate
Posts: 6225
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 6:26 pm

drgeoff wrote: So what happened to the money? Or are the lawyers still arguing about it?
No idea. Fortunately it wasn't my money. :)
Another similar one ended with the well-known company saying "You've had it for six months so we can't sell it as new, and it's now out of date so no-one will want it, so we don't want the equipment and you can't have your money back"
I think the lawyers managed to get us the money and we kept the equipment. So lawyers are some use after all.

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 8:35 pm

Maybe people who try to advertise the Pi as an unfinished development board should read the FAQ here and show me the Paragraph that explains why the Pi's usb problems should not give us a reason to complain. I can understand and live with the power supply issues. If the Pi needs a stable voltage between 4.85 and 5.25, it can be aranged. If an usb client can only draw 100mA, that's something fixable as well.
If however the usb stack is giving issues which are still undefined 4 months after release date, that's something I am serious worried about. At home, I can look in my drawer for working usb devices, but I can't promote to use the device at work, telling them that every usb client will be a hit or miss. I considered it one of the great advantages that io expansion could be done using usb. It would make the io boards compatible with all devices using usb. Doing so, you could simply test it on your pc and use it on the Pi afterwards.
So, in my opinion, if the problem is the fact that peoples expectations are 2 high, than it's the duty of this Forum to warn them about the non accurate press information. This is an engineering point of view, and I know there are others involved as well.

User avatar
jbeale
Posts: 3581
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 18, 2012 8:36 pm

obcd wrote:Seeing the Pi as a 'development board' or a 'public beta' is an interesting theory.
I am trying to think of other public beta hardware designs, but can only see the term used in software?
On the topic of uncased ARM-based Linux boards: If you think the R-Pi software is not at a satisfactory level for what it is, what would you say about the Olimex Olinuxino-Micro board? They don't have a forum but feel free to peruse its Yahoo user group for the current state of play: http://tech.groups.yahoo.com/group/olinuxino/
The product page does label it "development board": https://www.olimex.com/dev/index.html
https://www.olimex.com/dev/imx233-olinuxino-micro.html

Briefly, the Olinuxino-Micro has an iMX233 Arm v5 CPU and one USB 2.0 port. Using the 'official' kernel, that USB port works with a USB memory stick and little else- not even a keyboard, unless you use a separate hub. If you compile your own kernel you may do better, but AFAIK no USB-LAN or Wifi adaptors are proven to work reliably on that platform yet (progress is being made, though, and I am hoping it will be useful in a month or two.) My Olinuxino is on the shelf while I wait for more software progress.

Meanwhile my R-Pi has been solid, gathering data via USB from Arduinos and uploading to a remote site 24/7 for 7 weeks now without trouble and is by comparison- well, there is no comparison really.

Return to “Troubleshooting”