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

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 2:16 pm

DAFlippers wrote:
jamesh wrote: If you have more details I would suggest updating the github entry with them. Or posting them here.
Hi James,

I have posted what I think is relevant on github but I assumed that if someone was picking up ownership of the issue then I would be contacted for any further details I could give. Note that I can add debug to my program and I have an external USB analyser (ellisys USB explorer) to capture the USB traffic.

As things stand I haven't a clue if anyone has picked up ownership of the issue.

When I first posted about the issue I found I was pointed at github to report the issue. I did that and I have had no acknowledgement of the report. You are now suggesting I post further information here which defeats the whole point of a centralised logging of issues and their handling doesn't it?

David
No, I suggested you post on github, where entries are read, even if they don't appear to have any ownership. Or posting them here was if you could'nt be bothered to go back to github - just trying to save you time! This thread is basically where lots of stuff is happening at the moment, so is a good place for garnering USB information.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

DAFlippers
Posts: 26
Joined: Fri Aug 10, 2012 8:39 am
Location: Berkshire

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 2:50 pm

jamesh wrote:
No, I suggested you post on github, where entries are read, even if they don't appear to have any ownership. Or posting them here was if you could'nt be bothered to go back to github - just trying to save you time! This thread is basically where lots of stuff is happening at the moment, so is a good place for garnering USB information.
Hi James,

I wasn't getting at you just expressing my frustration at not knowing what my expectations should be when I report an issue.

I have posted an update on github and hopefully someone might drop me a mail to tell me I am talking out of my backside or get me to test a patch.

My frustration is that I reported an issue in what I believe is the correct place in the right manner and have not had any response in over a week. I really would have expected something from someone by now. If issues aren't handled in a manner that keeps the original poster and interested parties informed of status then the process will lose credibility and cease to be of any use.

David

PS You will note I erroneously closed the issue - never give me the opportunity to click the wrong button :o)

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 3:22 pm

DAFlippers wrote:
jamesh wrote:
No, I suggested you post on github, where entries are read, even if they don't appear to have any ownership. Or posting them here was if you could'nt be bothered to go back to github - just trying to save you time! This thread is basically where lots of stuff is happening at the moment, so is a good place for garnering USB information.
Hi James,

I wasn't getting at you just expressing my frustration at not knowing what my expectations should be when I report an issue.

I have posted an update on github and hopefully someone might drop me a mail to tell me I am talking out of my backside or get me to test a patch.

My frustration is that I reported an issue in what I believe is the correct place in the right manner and have not had any response in over a week. I really would have expected something from someone by now. If issues aren't handled in a manner that keeps the original poster and interested parties informed of status then the process will lose credibility and cease to be of any use.

David

PS You will note I erroneously closed the issue - never give me the opportunity to click the wrong button :o)
First github *is* the right place, the suggestion is just to post here as well ;-)

As for the frustration caused by the wait... welcome to linux :lol: There isn't a division of highly paid computer programmers working on the bugs that we're discovering. The RPi is at its heart a community and volunteer based project which places responsibility of upkeep not on the individual fixing the problem but on the individual reporting the problem. When you have an issue that you report then it's up to you to see check in and see if it's been fixed yet ;-). Now this might be a deal breaker for you, but I hope not. I hope that you continue to provide additional details as you think of them and check in to see how its going. The linux mindset can be a bit of a cultural shock, but it pays off surprisingly well over other OS alternatives :-)
Dear forum: Play nice ;-)

DAFlippers
Posts: 26
Joined: Fri Aug 10, 2012 8:39 am
Location: Berkshire

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 3:50 pm

abishur wrote:
First github *is* the right place, the suggestion is just to post here as well ;-)
which is what I was doing....;-)
abishur wrote:
As for the frustration caused by the wait... welcome to linux :lol: There isn't a division of highly paid computer programmers working on the bugs that we're discovering.
I totally understand that but my point was that if something is in place and it isn't being used correctly then it can actually be worse then not being there.

github #79 I have now had a comment from Popcornmix and I have responded to that.

The thing is that what I have seen should be pretty simple to reproduce and being able to reproduce is always the key to fixing an issue. I can see the calls being made and the data on the bus but the data being returned by the call does not reflect the data on the bus - see the github linux issue #79.

I have just installed the software on a pico ITX Atom based board running Fedora and it runs without issue. The *only* platform so far to have an issue is RPi.

David

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 4:22 pm

DAFlippers wrote: I totally understand that but my point was that if something is in place and it isn't being used correctly then it can actually be worse then not being there.
And my point is that that *is* the correct use of github, that having to wait a week for volunteers to be able to look at your specific issue is not (lamentably) weird. It is unfortunate and understandably frustrating when you have something you want to accomplish, but it is the nature of the beast :-)
I have just installed the software on a pico ITX Atom based board running Fedora and it runs without issue. The *only* platform so far to have an issue is RPi.David
Well now, Atom != ARM does it? It's somewhat unjust to hold up an orange and then judge an apple poorly because it's not orange, has the wrong texture, and is sweet or tart instead of tangy ;-)
Dear forum: Play nice ;-)

DAFlippers
Posts: 26
Joined: Fri Aug 10, 2012 8:39 am
Location: Berkshire

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 4:42 pm

abishur wrote:And my point is that that *is* the correct use of github, that having to wait a week for volunteers to be able to look at your specific issue is not (lamentably) weird.
Would it be too much to ask for the message "it might take up to 14 days before you see a response...." to be sent to the poster of an issue on github?
abishur wrote:It's somewhat unjust to hold up an orange and then judge an apple poorly because it's not orange, has the wrong texture, and is sweet or tart instead of tangy ;-)
Come on that's so lame. Surely on this forum it should be Strawberries and ......

David

MarcinM
Posts: 6
Joined: Sun Aug 19, 2012 7:27 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 4:49 pm

abishur wrote:Have you noticed your ethernet chip get's unusually hot? It's been discovered recently that on certain Pis there's a design mistake which uses the LAN9512 chip as the 3v3 regulator. It's possible that you have one such pi (which might explain why the 3v3 rail goes janky when you plug in USB devices).
I've checked the LAN chip and it is hot, but it seems that not unusually (touchable). The 3.3V regulator is also warm, which suggests it's doing some work. Do you know how to check if the board is affected? According to http://elinux.org/RaspberryPi_Boards I have BH1219 board from RS. A sticker on the bottom side says E2612RSV1.0B1.1
abishur wrote:On the Hub issue, one thing I've noticed is that if I try and mix high speed (Hard drives mainly in my case) and low speed (keyboards/mice) USB devices on the same hub it really causes issues, but if I split off the high speed devices onto their own hub it tends to calm things down.
I've noticed that too. When separated they are usable, but they don't work 100% ok. There are errors with both the camera and the keyboard.

Thanks for all the info!
Marcin.

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

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:00 pm

It's the 1.8V regulator, not the 3.3V....

User avatar
PeterO
Posts: 5075
Joined: Sun Jul 22, 2012 4:14 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:11 pm

Can someone post a link to the latest set of recommended kernel command line options to use/test latest USB code please.

Ta, PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:22 pm

obcd wrote:It's the 1.8V regulator, not the 3.3V....
Doh! :oops:
MarcinM wrote: Do you know how to check if the board is affected? According to http://elinux.org/RaspberryPi_Boards I have BH1219 board from RS. A sticker on the bottom side says E2612RSV1.0B1.1
I do not, as you can see I apparently couldn't even keep straight what was being affected :roll: I have seen 2 threads on the forum discussing this, I'd do a site search and find the specific thread discussing it and seeing if they know.
DAFlippers wrote: Would it be too much to ask for the message "it might take up to 14 days before you see a response...." to be sent to the poster of an issue on github?


But then people would be upset if it took longer than that.
Come on that's so lame. Surely on this forum it should be Strawberries and ......
:lol:
Dear forum: Play nice ;-)

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5341
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:26 pm

PeterO wrote:Can someone post a link to the latest set of recommended kernel command line options to use/test latest USB code please.

Ta, PeterO
dwc_otg.microframe_schedule=1

is the main one, if you have problems with too many endpoints.
Even if you don't have these problems, it's also useful to determine it doesn't break anything new. We would like to enable that by default soon.

If you are suffering from lost USB packets:
sdhci-bcm2708.sync_after_dma=0 sdhci-bcm2708.missing_status=0

will help with interrupt latency. We believe the sync_after_dma is safe, and will be enabled by default soon.
The missing_status is the one that gives the most benefit, but unfortunately doesn't work with all sdcards.
We're still looking into a better solution.

Always wise to backup your sdcard before trying something like this, just in case.

We believe there is an additional reason for packet loss due to mixed high/low speed devices and split transactions.
No fix for that yet, gsh is still investigating.

User avatar
PeterO
Posts: 5075
Joined: Sun Jul 22, 2012 4:14 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:30 pm

Thanks dom.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

pwinwood
Posts: 76
Joined: Mon Jul 02, 2012 2:21 am
Location: Oxford, England

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:31 pm

I never had any success using my Toshiba/Creative Labs 7 port hub which has Ethernet and Audio until I updated to the new kernel and added

dwc_otg.microframe_schedule=1 sdhci-bcm2708.sync_after_dma=0 sdhci-bcm2708.missing_status=0

to cmdline.txt.
Now after an initial test, everything is working fine.
No errors in /var/log/messages.

Very good so far. Thanks for your hard work.
:D

kermitas
Posts: 108
Joined: Thu Jan 26, 2012 11:49 am

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:47 pm

pwinwood wrote:I never had any success using my Toshiba/Creative Labs 7 port hub which has Ethernet and Audio until I updated to the new kernel and added

dwc_otg.microframe_schedule=1 sdhci-bcm2708.sync_after_dma=0 sdhci-bcm2708.missing_status=0

to cmdline.txt.
Now after an initial test, everything is working fine.
No errors in /var/log/messages.

Very good so far. Thanks for your hard work.
:D
For those who use sdhci-bcm2708.missing_status=0 I suggest to move rootfs to pendrive to reduce SD card operations (and possible IO errors and turning system in to read-olny mode). It is very easy, just change 'root' in cmdline.txt to root=/dev/sda2.
How to get second partition on pendrive? It is also easy, flash Debian/Fedora (or whatever you use) image on pendrive just like you did that with SD card.

When your rootfs is on pendrive you can have small problems with update (via rpi-update) because it will update /boot what is mounted to first partition of pendrive - not on SD card.
To change that do before update: umount /boot and mount /dev/mmcblk0p1 /boot. Now in /boot there is first partition from SD card, not from pendrive.

pwinwood
Posts: 76
Joined: Mon Jul 02, 2012 2:21 am
Location: Oxford, England

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 5:50 pm

umount /boot and mount /dev/mmcblk0p1 /boot. Now in /boot there is first partition from SD card, not from pendrive.
What is the advantage of moving /boot? It is never accessed once the system is loaded. I would leave it on the sdcard and just move the one partition.

kermitas
Posts: 108
Joined: Thu Jan 26, 2012 11:49 am

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 6:23 pm

pwinwood wrote:
umount /boot and mount /dev/mmcblk0p1 /boot. Now in /boot there is first partition from SD card, not from pendrive.
What is the advantage of moving /boot? It is never accessed once the system is loaded. I would leave it on the sdcard and just move the one partition.
Base boot partition must be on SD card - that is how rpi works. Then in cmdline.txt you can 'redirect' second partition - not use this from SD card but use this from pendrive.

When I did like this I didn't know that entering to /boot I see first partition form pendrive. So very hapy I did many times rpi-upate and from time to time ask myself why I always have 3.1.9+ #272.

That was until yesterday evening when I realized that other rpi users have 3.2.27+ #12. On this thread we did investigation and using received help I realized that I see first partiotn form pendrive.

Doing umount /boot and mount /dev/mmcblk0p1 /boot you will see first partition form SD card so rpi-update can do update and you will boot with latest firmware.

(Without moving rootfs to pendrive option sdhci-bcm2708.missing_status=0 causes me a lot of IO errors ant troubles.)

pwinwood
Posts: 76
Joined: Mon Jul 02, 2012 2:21 am
Location: Oxford, England

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 6:38 pm

I run with '/' on a usb hard disk drive and leave /boot on the sdcard.
I encounter no problems with this and I do not have to unmount and mount anything to do an rpi-update.

kermitas
Posts: 108
Joined: Thu Jan 26, 2012 11:49 am

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 6:43 pm

pwinwood wrote:I run with '/' on a usb hard disk drive and leave /boot on the sdcard.
I encounter no problems with this and I do not have to unmount and mount anything to do an rpi-update.
Ok, that's great.

You all other readers: if you are not sure what you have in /boot (after change 'root' in cmdline.txt to use external pendrive) please see this my post http://www.raspberrypi.org/phpBB3/viewt ... 56#p153956.

bfromcolo
Posts: 26
Joined: Sat Aug 11, 2012 11:20 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 6:52 pm

I updated to 3.2.27+ this morning. The wired ethernet seems to work better with the hub attached now.

But if I plug my wifi adapter into the hub after the mouse and keyboard, the system slows to a crawl, the CPU usage monitor freezes or barely updates. Removing the adapter restores the system to normal functioning.

It does the same thing if I plug the adapter into one of the ports on the PI, with the mouse and keyboard attached to the hub.

If I unplug the mouse and keyboard, then plug in the wifi adapter, it looks like the system recognizes the adapter, at least the LED on the adapter lights up. But when I then plug in the mouse and keyboard, the first one I plug in works and the second one doesn't.

I have a Rosewill 4 port powered hub, and the wifi adapter is an Encore ENUWI-G2.

If there is any info I can provide let me know, and tell me the commands to collect it.

Thanks

edit - I tried a USB flash drive, I was able to read the contents of the drive with it attached to the hub, but my keyboard stopped working until I removed the flash drive, and then unplugged and reinserted my keyboard cable.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5341
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 7:11 pm

@bfromcolo
When system slows to a crawl, what does top report as the busy processes?
Are you in X or does it fail from initial console?
Does dmesg produce lots of errors?

If you set:
dwc_otg.microframe_schedule=0
does it behave better, or is it still broken?

samsamsam
Posts: 36
Joined: Fri Aug 17, 2012 11:36 am

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 7:13 pm

Please try add dwc_otg.speed=1 to cmdline.txt

bfromcolo
Posts: 26
Joined: Sat Aug 11, 2012 11:20 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 7:19 pm

dom wrote:@bfromcolo
When system slows to a crawl, what does top report as the busy processes?
Are you in X or does it fail from initial console?
Does dmesg produce lots of errors?

If you set:
dwc_otg.microframe_schedule=0
does it behave better, or is it still broken?
The CPU usage meter is the one displayed at the bottom by default in Raspian, I'll have to redo the test and run something that lists the running processes.

I was in the GUI.

I will try again after work and let you know.

User avatar
fbutler
Posts: 302
Joined: Thu Mar 15, 2012 4:09 pm
Location: Surrey, England

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 7:52 pm

dom wrote:I've ported to microframe scheduler to 2.94 and added a cmdline switch to turn it on/off. By default it is disabled. Add this to cmdline.txt to enable:
dwc_otg.microframe_schedule=1
I can confirm that this has solved the periodic channel error messages for me. No error messages in /var/log/syslog and for the first time I'm successfully able to use a KVM.

An lsusb from the console shows all the devices correctly with no error messages:

Code: Select all

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0424:2524 Standard Microsystems Corp. USB MultiSwitch Hub
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 006: ID 050d:3201 Belkin Components F1DF102U/F1DG102U Flip KVM
Bus 001 Device 007: ID 046d:c062 Logitech, Inc. LS1 Laser Mouse, corded
Bus 001 Device 008: ID 046d:0b04 Logitech, Inc.
Bus 001 Device 009: ID 0a81:0101 Chesen Electronics Corp. Keyboard
Bus 001 Device 010: ID eb1a:2861 eMPIA Technology, Inc.
Bus 001 Device 011: ID 20a0:0001 Clay Logic
Bus 001 Device 012: ID 045e:0737 Microsoft Corp. Compact Optical Mouse 500
Bus 001 Device 015: ID 046d:c713 Logitech, Inc.
Bus 001 Device 016: ID 046d:c714 Logitech, Inc. diNovo Edge Keyboard
I'll test it further tomorow night with a 10 port hub and some more devices, but so far it's looking good. :D

Thanks to all for their work on this issue.

MarcinM
Posts: 6
Joined: Sun Aug 19, 2012 7:27 pm

Re: USB - the Elephant in our Room

Mon Aug 20, 2012 9:07 pm

MarcinM wrote:Yes, I have USB problems. With USB cameras, storage, WiFi. Even keyboard and mouse reset from time to time. Everything gets worse when connected to a HUB. I've measured the mythical 5V and it turned out to be about 4.9V. Then I decided to check if there is a distortion on 5V. Connected a scope and it turned out to be flat. Really flat. But then I've checked 3.3V... This one IS distorted. Voltage drops to as low as 2.85V. It's relatively quiet when there are no USB devices and no network traffic. It gets worse with USB devices connected.
I've put pictures here: http://marcin.homedns.org/~marcin/pic.html. The page is hosted on the Pi that's being measured so it may not be accessible from time to time...

Can somebody with more experience check if that may be the problem?

I've tried few caps in different places without any noticeable change. (few hundreds uF, nF and pF).
Probes were connected to P1. 3.3V looks the same measured directly on RG2.
I've made a basic mistake taking measurements. 3.3V is fine. I hope I didn't make too much confusion.

ppuskari
Posts: 38
Joined: Sat Jul 07, 2012 4:04 am

Re: USB - the Elephant in our Room

Tue Aug 21, 2012 4:44 am

I'll have to try and see if I can reproduce the failure but I was able to coax a traceback listing after plugging in my bluetooth usb dongle.

The main stack trace basically was REALLY unhappy about dma inside the usb stack it looked like... Once I get done building the USBIP modules I'll try and kill the raspi again and post the exact trace info. Maybe it'll help us?

Return to “Troubleshooting”