elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: USB - the Elephant in our Room

Mon Aug 13, 2012 4:05 am

Befriending the Elephant:
http://elinux.org/Rpi_USB_check-list
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

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

Re: USB - the Elephant in our Room

Mon Aug 13, 2012 9:28 am

gsh wrote:Also note that there is a deficiency in the driver which means we're limited currently to a maximum of 8 periodic endpoints, this is because the driver reserves a channel (of which there are eight) for each periodic endpoint. Now I believe that for each hub port you have at least one interrupt endpoint so once you get to seven hub ports then you run out of channels!

If you want to have a look at what endpoints you have just do:

lsusb -v

This will output quite a bit of information about each of the devices on the usb host and what endpoints each one has. Once you add up one interrupt endpoint for mouse, keyboard, hub, ethernet you've already used five of the eight channels (we may even reserve a channel for the root hub)... I'd be interested in seeing how many periodic endpoints (interrupt or isochronous) people have working before they find problems...

Given the Kinect has four endpoints this could be an issue for the guys trying to get that going.

Also some posts have referred to passive PS2-USB adaptors. This are simply hard wired connectors as the device (mouse) has both PS/2 and USB interfaces built in and both are presented on the 6 pin mini DIN connector used for PS/2 connection with the USB data on the unsed pins 2 and 6. Note these adaptors ONLY work with specific devices that have this functionality built in.

The crux of the issue seems to me to be the fact the BCM2835 SoC is normally used as an USB device and in the RPi it is being used as an USB host. Getting a device to work as a host is significantly more difficult than configuring it to be a device and far less people have experience of doing this simply because there are far more devices than hosts. Think how many different types and makes of device you (try to) connect to your PC or RPi. It is almost impossible to consider every combination of devices, endpoints and load that users (us) attempt to put on the USB implementation provided and ulitmately early adopters are helping debug the product.

If bugs are found, reported and handled in a manner that users can see that something is being done then that is great. My worry is that having reported a problem on Github I have not received any acknowledgement or response (I know it was reported over the weekend ) and looking at open issues (some are months old) most have no one assigned and no milestones so what is being done? If they are resolved then they should be closed; if they are incorrect they should be flagged as such. Am I missing something?

The danger is that people will lose enthusiasm and there is a whole bunch of that here at the moment.

David

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 13, 2012 5:35 pm

gsh wrote:...we're limited currently to a maximum of 8 periodic endpoints...
gsh wrote:...So the important thing is the periodic endpoints, that is those that are Interrupt or Isochronous, so do

Code: Select all

sudo lsusb -v | grep "Transfer Type"
If you've got more than six then I think you'll end up running into trouble. There is a patch for this but currently I believe it is running into trouble.
Hi all,

In the post quoted above Gordon implies that issues will be seen if there are more than 6 periodic endpoints in use. However in a following post elatllat implies that the issue is caused by anything more than 7 periodic endpoints
elatllat wrote:Thanks for the clarification gsh.

I have 8 ( and the last one is not working).

Code: Select all

lsusb -v | grep -iP "Transfer Type.*(Interrupt|Isochronous)" | wc -l
8
lsusb -v | grep "Transfer Type"
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Interrupt
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Bulk
All the hard drives are "Transfer Type Bulk".
From my calculations even having a very basic keyboard and mouse plugged into a hub would use 7 periodic endpoints which would break the limit of 6 quoted by Gordon above.

Pi with no USB devices plugged in = 4 endpoints
Pi with 4 port hub plugged in = 5 endpoints
Pi with 4 port hub with keyboard in hub using one endpoint = 6 endpoints
Pi with 4 port hub with keyboard and mouse in hub, each one using one endpoint = 7 endpoints

The periodic endpoint limitation would certainly explain why I see the "No host channel available for periodic transfer" message when attempting to use a DeNovo Edge keyboard that uses periodic 3 endpoints or any keyboard and mouse with a Belkin KVM that uses 2 periodic endpoints

Pi + 4 port hub + DeNovo Edge keyboard + mouse = 9 endpoints minimum
or
Pi + Belkin KVM + keyboard and mouse with one endpoint each = 8 endpoints minimum
or
Pi + Belkin KVM + DeNovo keyboard + mouse = 10 endpoints minimum
or
Pi + Belkin KVM + DeNovo keyboard + mouse + hub + any other USB peripheral with 1 endpoint = 12 endpoints

Can anyone provide clarity on the current maximum number of periodic endpoints which can be in use before encountering issues.
Is it 6, 7, something else, or have I completely misread these posts?

Thankfully I'm running both my Pi's in headless configurations right now so I'm able to avoid the issue. However I'd like to try using some of the configurations outlined above and until there is a fix it's just impossible.

I'd like to thank Gordon and the others for their work on this so far, it really is appreciated.

I'm keeping my fingers crossed that a fix for the periodic endpoint, and other USB issues, will be found, and fully released, in the near future.

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: USB - the Elephant in our Room

Mon Aug 13, 2012 5:44 pm

fbutler wrote:...
Periodic endpoints are hubs (for the most part), mice, keyboards, hard drives etc don't count.
so you are limited to 2 7-port-hubs for a total of 14 devices.
(I have only tested 2 hubs and 8 devices at once, but 14 should work)
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

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

Re: USB - the Elephant in our Room

Mon Aug 13, 2012 6:11 pm

elatllat wrote:
fbutler wrote:...
Periodic endpoints are hubs (for the most part), mice, keyboards, hard drives etc don't count.
so you are limited to 2 7-port-hubs for a total of 14 devices.
(I have only tested 2 hubs and 8 devices at once, but 14 should work)
Aren't Video and Audio periodic? If so Kinect has at least 3 so more likely to hit the limit.

David

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 13, 2012 6:12 pm

elatllat wrote:
fbutler wrote:...
Periodic endpoints are hubs (for the most part), mice, keyboards, hard drives etc don't count.
so you are limited to 2 7-port-hubs for a total of 14 devices.
(I have only tested 2 hubs and 8 devices at once, but 14 should work)
So how do you actually count the number of periodic endpoints in use?

For instance with a 4 port hub, with a keyboard and mouse plugged in, using the two commands you've quoted above I see

Code: Select all

[email protected]:~# lsusb -v | grep -iP "Transfer Type.*(Interrupt|Isochronous)" | wc -l
8
[email protected]:~# lsusb -v | grep "Transfer Type"
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Bulk
          Transfer Type            Bulk
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
          Transfer Type            Interrupt
What commands can be used to determine which of these are periodic endpoints?

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 13, 2012 7:18 pm

elatllat wrote: Periodic endpoints are hubs (for the most part), mice, keyboards, hard drives etc don't count.
so you are limited to 2 7-port-hubs for a total of 14 devices.
(I have only tested 2 hubs and 8 devices at once, but 14 should work)
Thanks for the response elatllat. I'm clearly not interpreting what Gordon wrote correctly:
gsh wrote:...So the important thing is the periodic endpoints, that is those that are Interrupt or Isochronous, so do

Code: Select all

sudo lsusb -v | grep "Transfer Type"
If you've got more than six then I think you'll end up running into trouble. There is a patch for this but currently I believe it is running into trouble.
I read this to mean that any endpoint that is showing up in a lsusb -v with a Transfer Type of Interrupt or Isochronous is a periodic endpoint. Is this not correct?
If I do:

Code: Select all

 lsusb -v | grep -iP "Bus.*Device| Transfer Type.*(Interrupt|Isochronous)" &&  lsusb -v | grep -iPc "Transfer Type.*(Interrupt|Isochronous)"
I see:

Code: Select all

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
          Transfer Type            Interrupt
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
          Transfer Type            Interrupt
          Transfer Type            Interrupt
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
          Transfer Type            Interrupt
Bus 001 Device 031: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
          Transfer Type            Interrupt
Bus 001 Device 032: ID 0a81:0101 Chesen Electronics Corp. Keyboard
          Transfer Type            Interrupt
          Transfer Type            Interrupt
Bus 001 Device 033: ID 045e:0737 Microsoft Corp. Compact Optical Mouse 500
          Transfer Type            Interrupt
8
showing the endpoints with Transfer Types of either Interrupt or Isochronous associated with each connected USB device and the total of such endpoints which in this case is 8. So how can I determine which of these endpoints are periodic endpoints?

elatllat
Posts: 1337
Joined: Sat Dec 17, 2011 5:05 pm

Re: USB - the Elephant in our Room

Mon Aug 13, 2012 9:31 pm

Maybe I'm wrong about the mouse and keyboard thing, I was only testing with hard drives~
Try adding a 9th and see if it works.


Getting back to the elephant, Paraphrased OP:
blavery wrote:...the biggest Pi issue. The USB system is broken....
The problems stem from 3 things:
* power - use a powered hub
* crash under load - fix: http://www.raspberrypi.org/phpBB3/viewt ... 84#p148684
* crash on missing driver - fix: don't plug in anything with a missing driver. (I have not been able to reproduce, maybe someone who has can comment.)
* only supports some devices - legacy list: http://elinux.org/RPi_VerifiedPeripherals

Was there an issue brought up in the 10 pages (tl;dr) after that is worthy being labeled Elephant?
SBC with 32GB RAM: https://hardkernel.com

FAQ : https://raspberrypi.stackexchange.com

Unanswered: https://www.raspberrypi.org/forums/search.php?search_id=unanswered

reggie
Posts: 151
Joined: Fri Aug 26, 2011 11:51 am

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 12:29 am

I've just tested with my webcam and a usb hub, no keyboard or mouse, connected via ssh, this is the result, http://pastebin.com/M8hJ05tq I'm shocked, 31? If I take out the webcam, I get 5 but I still get 4 'couldn't open device' messages (resolved those messages by using sudo on the lsusb commands), so that's 26 just plugging my webcam in, is that a pi thing or my webcam? Would be interested to hear what you guys think :)

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

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 7:21 am

elatllat wrote:Maybe I'm wrong about the mouse and keyboard thing, I was only testing with hard drives~
Try adding a 9th and see if it works.

Code: Select all

[email protected]:~#  lsusb -v | grep -iP "Bus.*Device| Transfer Type.*(Interrupt|Isochronous)" &&  lsusb -v | grep -iPc "Transfer Type.*(Interrupt|Isochronous)"
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
          Transfer Type            Interrupt
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
          Transfer Type            Interrupt
          Transfer Type            Interrupt
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
          Transfer Type            Interrupt
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
          Transfer Type            Interrupt
Bus 001 Device 005: ID 046d:0b04 Logitech, Inc.
          Transfer Type            Interrupt
Bus 001 Device 006: ID 045e:0737 Microsoft Corp. Compact Optical Mouse 500
          Transfer Type            Interrupt
Bus 001 Device 007: ID 046d:c713 Logitech, Inc.
          Transfer Type            Interrupt
Bus 001 Device 008: ID 046d:c714 Logitech, Inc. diNovo Edge Keyboard
          Transfer Type            Interrupt
9
Replacing the Chesen keyboard with a DeNovo Edge keyboard after a halt and a fresh boot replaces 2 of the endpoints with 3 other endpoints. There are no "No host channel available for periodic transfer" error messages, however the keyboard appears to very occasionally exhibit a sticky key.

Adding a Trust bluetooth adapter with the Chesen keyboard configuration gives the following:

Code: Select all

[email protected]:~#lsusb -v | grep -iP "Bus.*Device| Transfer Type.*(Interrupt|Isochronous)" &&  lsusb -v | grep -iPc "Transfer Type.*(Interrupt|Isochronous)"
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
          Transfer Type            Interrupt
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
          Transfer Type            Interrupt
          Transfer Type            Interrupt
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
          Transfer Type            Interrupt
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
          Transfer Type            Interrupt
Bus 001 Device 005: ID 0a81:0101 Chesen Electronics Corp. Keyboard
          Transfer Type            Interrupt
          Transfer Type            Interrupt
Bus 001 Device 006: ID 045e:0737 Microsoft Corp. Compact Optical Mouse 500
          Transfer Type            Interrupt
Bus 001 Device 007: ID 0a5c:21e8 Broadcom Corp.
          Transfer Type            Interrupt
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
          Transfer Type            Isochronous
21
This shows the bluetooth adapter adding 1 Interrupt type endpoint and 12 Isochronous type endpoints making a total of 21 endpoints with Transfer Types of Interrupt or Isochronous. Again there are no error messages with this.

I think I'll wait for some further clarity on periodic endpoints and what exactly we should be looking for in relation to them before testing further.

Dexterp37
Posts: 21
Joined: Mon Jul 30, 2012 7:51 pm
Location: Italy
Contact: Website

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 7:58 am

Without attaching anything (I'm using my RPi via SSH) the number of "periodic endpoints" (if that means the number of Interrupt or Isochronous trasfers) is 4. By plugging my USB powered hub + Kinect the number raises to 11 which explains the problem we are experiencing with the Kinect.

I have no idea how the device should correctly behave or how the periodic endpoints should sum up. I'll wait for some clarity over these things in order to further test as well :-) Meanwhile, I'm compiling the kernel with the patch cited some posts ago which should remove the periodic endpoints problem. We'll see!

james968
Posts: 29
Joined: Tue Jul 17, 2012 8:52 am

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 8:17 am

juggle wrote:
jamesh wrote:...
Can you supply information on the particular PS2 adapter you are using, might make it easier to see what the problem is. Also, do USB keyboards/mice work ok? Which should prove whether it's the adapter or not.
It is one of these.

I don't have any USB keyboards or mice, which is why I bought this adapter.
One thing that pops out right away, is that the adapter in the picture has only1 USB port, which means that BOTH the mouse and the keyboard will be limited to 140 mA. Maybe one of the electrical experts will come out and say it won't be an issue, though most adapters I've seen are 1 USB prort for each device, that way they each have access to all 140 mA. (With only 1 USB port they are fighting each other for it).

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

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 9:15 am

The way I see it, the Hardware is capable of servicing 8 channels simultanously. All interrupt In and Isochronous Transfers take a channel. I think One should remain available for the Periodic Endpoints.
Once you are having to much, you only run into problem when they are used. The mouse for instance is only used when startx or another graphical shell is started. I also noticed that the script I found on this Forum to disable the onboard ethernet adapter indeed makes eth0 dissapear from the ifconfig, but it doesn't decrease the number of used Transfers in the lsusb -v command. Still however people report they got some setups running when they disable the ethernet adapter.
So, it looks like lsusb -v is reporting the maximum number of endpoints needed when all devices are busy, but not the real number that are used. As long as that stays below 8, I assume the system should work stable.
But again, that's my personal view. I hope Gordon knows the details, as it would be helpfull, before we have a fix, to know exactly what works and what might give us issues. I also noticed some patches in the latest kernels that can be turned on by adding
sdhci-bcm2708.missing_status=0
sdhci-bcm2708.sync_after_dma=0
to cmdline.txt, but I am again missing some details about what it is suposed to fix. I know drivers don't grow on trees, but the lack of information is annoying.

secretagent
Posts: 36
Joined: Wed Mar 07, 2012 10:09 am

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 9:31 am

juggle wrote:
jamesh wrote:...
Can you supply information on the particular PS2 adapter you are using, might make it easier to see what the problem is. Also, do USB keyboards/mice work ok? Which should prove whether it's the adapter or not.
It is one of these.

I don't have any USB keyboards or mice, which is why I bought this adapter.
I have one of these too (or at least looks the same, it identifies itself as "0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter") and it works fine, at least with a keyboard (I don't have a PS/2 mouse at the moment to test with). Have you tried it with just the keyboard?

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

Tue Aug 14, 2012 11:25 am

obcd wrote: sdhci-bcm2708.missing_status=0
sdhci-bcm2708.sync_after_dma=0
to cmdline.txt, but I am again missing some details about what it is suposed to fix. I know drivers don't grow on trees, but the lack of information is annoying.
We believe the main cause for lost USB packets (although possibly not the only one) is bad interrupt latency for USB interrupts.
We have found two places in the sdcard driver where it busy waits with interrupts disabled.
We believe that that "sdhci-bcm2708.sync_after_dma=0" avoids one of these cases and is safe (no reports of it causing sdcard problems).
We believe that that "sdhci-bcm2708.missing_status=0" avoids the other case, but only works with some sdcards. (we've some reports of it causing sdcard problems, others that it is fine).

The "missing_status" code can disable interrupts for over 100ms, which is a huge problem for other drivers.

Another solution is to minimise sdcard accesses. E.g. run your rootfs from a USB drive, or NFS. This should help with this sort of packet loss.

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

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 4:47 pm

Dear topic readers,

I am fighting with webcams with USB issues for many weeks (http://www.raspberrypi.org/phpBB3/viewt ... 5&p=147129).

I know this two parameters:
- sdhci-bcm2708.sync_after_dma=0 - this does nothing for me, not better not worst so I leaved it in cmdline.txt
- sdhci-bcm2708.missing_status=0 - adding this one cause a lot of IO write errors and system/partition turns into read-only mode :cry:

I've read small info that people boots only from SD and rest of the system resides on pendrive.

To check how it works it will take me couple of hurs so I wanted to ask you:
- does anybody did that trick?
- did it help, does usb works better with missing_status=0?
- are there any other parameters / quirks / tricks that I should check?

Thank you,
Arthur.

Max

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 5:43 pm

dom wrote:Another solution is to minimise sdcard accesses. E.g. run your rootfs from a USB drive, or NFS. This should help with this sort of packet loss.
Have had occasional "enter" key repeats with root file system on USB hard disk and during a short test with rootfs on iSCSI as well.

Only with "enter" though, never another key.
Like the command that is being executed causes other USB traffic or something else that causes latency, and then it loses the "enter key has been released" packet or something like that.

(config: a simple normal Logitech classic 200 wired keyboard, powered 2A usb hub, WD passport 160 gb 2.5" usb drive)

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

Re: USB - the Elephant in our Room

Tue Aug 14, 2012 5:47 pm

It has been mentioned in this thread before, but how big is the chance that the LAN9512 running hot, (as according to recent discovery some samples may indeed run hotter than others) might be involved in USB problems, such as "repeating key errors". Perhaps someone with a few cans of freeze spray can do some basic tests?

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

Tue Aug 14, 2012 5:48 pm

kermitas wrote: To check how it works it will take me couple of hurs so I wanted to ask you:
- does anybody did that trick?
- did it help, does usb works better with missing_status=0?
- are there any other parameters / quirks / tricks that I should check?
Instructions here for how to boot from usb drive/stick:
http://www.raspberrypi.org/phpBB3/viewt ... 25#p129484

zardoz99
Posts: 175
Joined: Fri Jan 13, 2012 2:25 pm
Location: Somewhere in Canada.

Re: USB - the Elephant in our Room

Thu Aug 16, 2012 8:43 am

It's all very well saying "run from a pendrive" but if the USB system is broken, and it is, then the pendrive is also going to have problems.
Err, "Catch 22" anyone?

The last time I tried using a pendrive in anger, the Raspi probably killed it, as I have mentioned before in this thread.

So, we are looking at NFS as an alternative, now making our nice little standalone system dependent on many hundreds of pounds worth of external NFS server. OK, that's fine for some of us who are geared up and using the Raspi as a "toy" to experiment with, but that is not the solution for "Jimmy Smith down the road" who wants to be able to use it in his bedroom after school.

And now we are back to "fix the problem" and not "work around the symptoms".

bredman
Posts: 1415
Joined: Tue Jan 17, 2012 2:38 pm

Re: USB - the Elephant in our Room

Thu Aug 16, 2012 8:54 am

zardoz99 wrote:It's all very well saying "run from a pendrive" but if the USB system is broken, and it is, then the pendrive is also going to have problems.
Err, "Catch 22" anyone?
I think the proposed solution is to use the SD card only for the boot sequence and use the USB drive as the root filesystem and the user filesystem.

In this case, there will be no accesses to the SD card, there should be no need for the SD driver to lockout the interrupts, so there should be no more issues with the USB driver.

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

Thu Aug 16, 2012 9:27 am

We updated the synopsys driver to a newer version (2.94) last night.
Thanks to ddv2005 for tracking down a bug that had been breaking the newer version of the driver.

Whilst no specific bug we are aware of is fixed by this update (sorry, lost packets and limited number of periodic endpoints are still present), it does improve iperf performance by nearly 10% and seems to handle locking more cleanly, so it could help some miscellaneous issues.

We are still treating the lost packets as the most urgent issue, but it's proving tricky to find.
We're also tidying up the FIQ patch and the limited number of periodic endpoints patch, so they can be enabled with a command line parameter for wider testing.

p4trykx
Posts: 127
Joined: Wed Jan 11, 2012 2:55 pm

Re: USB - the Elephant in our Room

Thu Aug 16, 2012 11:47 am

mahjongg wrote: Perhaps someone with a few cans of freeze spray can do some basic tests?
I added a radiator to the chip but there was no difference. Perhaps it was too small.

james968
Posts: 29
Joined: Tue Jul 17, 2012 8:52 am

Re: USB - the Elephant in our Room

Thu Aug 16, 2012 12:37 pm

dom wrote:
obcd wrote:
The "missing_status" code can disable interrupts for over 100ms, which is a huge problem for other drivers.

Another solution is to minimise sdcard accesses. E.g. run your rootfs from a USB drive, or NFS. This should help with this sort of packet loss.
If you are not using Sound on the pie, how about removing the snd-bcm2835 module? Use:
#modprobe -r snd-bcm2835

(That will temporarily remove it from the kernel).

If you want to permanentally remove it you can edit /etc/modules and comment out the line (and reboot):
snd-bcm2835

This might help in troubleshooting issues where you think the sound driver is the cause.

James

lintweaker
Posts: 33
Joined: Mon Jul 09, 2012 6:26 pm

Re: USB - the Elephant in our Room

Thu Aug 16, 2012 3:44 pm

dom wrote:We updated the synopsys driver to a newer version (2.94) last night.
Thanks to ddv2005 for tracking down a bug that had been breaking the newer version of the driver.

Whilst no specific bug we are aware of is fixed by this update (sorry, lost packets and limited number of periodic endpoints are still present), it does improve iperf performance by nearly 10% and seems to handle locking more cleanly, so it could help some miscellaneous issues.

We are still treating the lost packets as the most urgent issue, but it's proving tricky to find.
We're also tidying up the FIQ patch and the limited number of periodic endpoints patch, so they can be enabled with a command line parameter for wider testing.
Congrats, the new USB OTG driver greatly improves USB2 audio performance/usability. Even 192K FLACs now play almost flawless (still regular crackles).

Keep it going!

Return to “Troubleshooting”