zagumennikov wrote:There is so much discussion about usb here. Can anyone make a summary of all of that (for example in the first post of this topic or in wiki)? How are things with the problem for now? What is already fixed, what will be fixed in near future, what will not be fixed, is anyone working on usb problems now? What means cmdline.txt options discussed here, what are default values? What is optimal cmdline.txt configuration for usb performance? It's hard to read whole this thread, collect and combine useful information. Someone who understands the whole situation, please make an exlaining post.
The optimal command line options are all defaults now (assuming you have ran rpi-update). These will be pushed to "apt-get upgrade" in the next few days.
The USB problems have been significantly improved during the lifetime of this thread to the extent that most users shouldn't have problems.
One of the issues remaining is where packets can be lost from USB 1 devices when there are also USB 2 devices present.
This can be avoided by forcing everything to use USB 1 speeds (dwc_otg.speed=1). Gordon is still investigating this.
There are a number of other bug reports that are being investigated by Gordon. We think some of these problems are due to the "dumb" nature of the USB hardware.
This requires the ARM core to service interrupts in a timely manner. However linux is not a real-time OS, and if interrupt latency is poor, things can be missed.
Normally that is not critical, as USB is designed to handle loss and retransmit, but there are exceptions (isochronous transfers from webcams and audio devices for example).
We've typically found that poor interrupt latency is caused by other badly behaved drivers in the system. For example a fix to the sdcard driver caused a lot of positive reports for USB audio devices.
So, if you are not specifically hitting problems with USB, then just run "apt-get upgrade" from time to time, and you will get the recommended fixes.
If you are suffering a specific problem and like to help with testing, then rpi-udpate may get you a fix earlier, and the various command line options may help diagnose what is good and what is bad.