USB redux

[obcd]

Jamesh made a point.
If the way usb works now doesn't work for you, don't complain but sell the board and move on to something else. After all, it's just 35 US$
This leads me to believe it won't get much better anymore than it is at the moment.
I don't blame the people working on it about that. If the hardware isn't up to the job, even clever programming can't totally fix it. They are doing a great job, lot has improved since the beginning.
I wouldn't be pi**ed about this if they had told me six months ago.
But then they said, it will be fixed, we just don't know when as we are a charity foundation etc. etc.
If you doubt questionning that you were a concern troll and freightend off with the banhammer.
And when I read the latest discussion here, I get a "déjà vu" feeling when suddendly the claim comes back that the Pi is a low cost computer for educational purpose...So don't expect....

[tvjon]

"That looks like it crashed inside the USBVision driver not the USB stack..."

Agreed, as the PC & LR are pointing to its code

I did actually buy an OS X driver for it a few years ago. If I get a chance, I'll try it on Linux on a x86 box.

"which does mean it could be an effect of the split transaction stuff...
....
Can't help any further until I've release the FIQ implementation... Soon..."

That's fine, I only posted it in case you find the feedback useful.
Incidentally, there is definite improvement in recent firmware releases, as the PCTV 290e "nanostick" HD freeview USB tuner now has quite a few less errors than a couple of weeks ago The only variable is the firmware as I haven't changed anything else.

[M_P]

Hmm... been a little while since I was on here, just wanted to stop in and say thanks again for all the hard work that's been done on the drivers - the following USB cameras are now working just fine now:
- Microsoft LifeCam Cinema
- Logitech C270
- Logitech C600

All run at 1280x720 and the Pis with the LifeCam Cinema and the C600 have both been running for over ten days straight.

Huge improvements - many thanks!!!

[jamesh]

Jamesh made a point.
If the way usb works now doesn't work for you, don't complain but sell the board and move on to something else. After all, it's just 35 US$
This leads me to believe it won't get much better anymore than it is at the moment.
I don't blame the people working on it about that. If the hardware isn't up to the job, even clever programming can't totally fix it. They are doing a great job, lot has improved since the beginning.
I wouldn't be pi**ed about this if they had told me six months ago.
But then they said, it will be fixed, we just don't know when as we are a charity foundation etc. etc.
If you doubt questionning that you were a concern troll and freightend off with the banhammer.
And when I read the latest discussion here, I get a "déjà vu" feeling when suddendly the claim comes back that the Pi is a low cost computer for educational purpose...So don't expect....

Actually, I think it will get better than it is now. Once the FIQ stuff is released, Gordon's going to be working on the Isynchronous transfer stuff (I think that's what it's called, I'm no USB expert). But, as I said above, the timescales on all this stuff is pretty fluid. Note that M33P gave a very comprehensive summary (and very good) of the issues encountered above, so IMO there will always be some things that won't work as well as they do on a desktop USB controller (the one on the Raspi is designed for mobile devices, and has limitations). So although it will get better, there will always be some esoteric devices that probably won't work very well. I think they will be in the minority however, as even now the vast majority of devices work OK (once you have all the fixes). It's a shame there may well be these corner cases, but as the development has continued on this, the limitations of the device have become clearer, and expectations change with greater knowledge. The biggest issue I think will be the limit to the number of devices that can be successfully attached, rather than specific devices not working, but most people won't get near that limit anyway.

As I also said above, I've got a USB device that doesn't work on my Ubuntu desktop box, so USB problems are not limited to the Raspi.

[ausserirdischegesund]

I think a lot of the frustration around USB could be removed if there was more detailed and reliable documentation what works, and what not.

It really makes a difference if you have to buy three webcams or USB hubs to get a working one, or if you can look up known good setups in a table (with exact model designation, USB id and description of use scenario) and go shopping for that. The wiki is only half there. Too many "it works" where it does not (or only in some scenarios), not enough detail (e.g. do devices need extra power).

Most of this will work out eventually. I've got stuff that works exceptionally well (my USB hard disk works for months without a problem, and back-powers the pi too, the webcam I bought, well that is another story .

[jamesh]

I think a lot of the frustration around USB could be removed if there was more detailed and reliable documentation what works, and what not.

It really makes a difference if you have to buy three webcams or USB hubs to get a working one, or if you can look up known good setups in a table (with exact model designation, USB id and description of use scenario) and go shopping for that. The wiki is only half there. Too many "it works" where it does not (or only in some scenarios), not enough detail (e.g. do devices need extra power).

Most of this will work out eventually. I've got stuff that works exceptionally well (my USB hard disk works for months without a problem, and back-powers the pi too, the webcam I bought, well that is another story .

The problem is how to make such a list, and equally importantly, keep it accurate. There is the Wiki which would seem to be the best if not only approach. There's no way the Foundation can test every item in existence (millions of them), so it's necessary for the people using those devices to update the list. Then a software release might fix a whole bunch of them and the list will then be out of date. It's a difficult problem.

As gsh has said in the past, all the devices he has work fine, so from his point of view of testing every device he has, USB works fine (as do all of mine). And he has some interesting devices!

[obcd]

As it's known what causes the problems, it should be possible to give a clue of when problems can be expected. It's perfectly possible to figure out what type of endpoints an usb device is using. Even if a wiki list isn't complete, it should be possible to create a list of known "good" working device. Which such a list, I can go shopping for devices on that list. Further on, usb devices can be divided in classes like the HID class, the Storage class, Serial device class, etc.
Maybe the accurate information isn't there because it's simply unknown. Maybe keyboard X will work perfectly on my Pi, and will loose keystrokes on yours. First of all, we will both need the same kernel and firmware to test in equal conditions. Next we will both need the same power supply as that also is a source of fustration, And finally, I shouldn't be typing slower than you do as obviously you will loose more keys/minute if you type faster. Finally, it might turn out that altough both our keyboards carry the same type number, mine might have another firmware rev. than yours. So I posted mine as working fine, and you are fustrated because it's inaccurate. Keeping track of the number of success/failure cases can help, but most people won't care posting that information unless there is a bonus for doing this.
If we look at it more technical, it seems that the needed real time response within a microframe can't be guaranteed. Such a response is needed to avoid the loose of split transactions. Pretty much every interrupt source going on can increase the real time response time (as one interrupt can't interrupt another ongoing interrupt handler) which makes predicting and fixing it very difficult.

[jamesh]

As it's known what causes the problems, it should be possible to give a clue of when problems can be expected. It's perfectly possible to figure out what type of endpoints an usb device is using. Even if a wiki list isn't complete, it should be possible to create a list of known "good" working device. Which such a list, I can go shopping for devices on that list. Further on, usb devices can be divided in classes like the HID class, the Storage class, Serial device class, etc.
Maybe the accurate information isn't there because it's simply unknown. Maybe keyboard X will work perfectly on my Pi, and will loose keystrokes on yours. First of all, we will both need the same kernel and firmware to test in equal conditions. Next we will both need the same power supply as that also is a source of fustration, And finally, I shouldn't be typing slower than you do as obviously you will loose more keys/minute if you type faster. Finally, it might turn out that altough both our keyboards carry the same type number, mine might have another firmware rev. than yours. So I posted mine as working fine, and you are fustrated because it's inaccurate. Keeping track of the number of success/failure cases can help, but most people won't care posting that information unless there is a bonus for doing this.
If we look at it more technical, it seems that the needed real time response within a microframe can't be guaranteed. Such a response is needed to avoid the loose of split transactions. Pretty much every interrupt source going on can increase the real time response time (as one interrupt can't interrupt another ongoing interrupt handler) which makes predicting and fixing it very difficult.

Look up ARM FIQ's for how gsh latest code fixes the interrupt speed issue.

[Burngate]

... Even if a wiki list isn't complete, it should be possible to create a list of known "good" working device...

The trouble with that is that the manufacturers change their devices without changing the part numbers, so what worked last time you bought one may not work this time.

[cyrano]

The trouble with that is that the manufacturers change their devices without changing the part numbers, so what worked last time you bought one may not work this time.

That is one of the biggest problems in USB country. Especially wireless USB keys can have different chipsets, but the same type numbers. Belkin and Dlink, for instance do this quite frequently. And some of these are on the "working" list.

[obcd]

Look up ARM FIQ's for how gsh latest code fixes the interrupt speed issue.

Ok, so the FIQ is comparable to the NMI that was present on some early day microcontrollers.
Using it should fix the split transaction issues, so no more missing keystrokes and strange mouse behavour.
I am still confused about the fix M33P implemented for the usb2serial devices. Wasn't the problem there a case of missing packets as well? Did those also come from split transactions? Please don't tell me to look it up in the 25000 lines of usb driver code. I seem to remember it was a case that normally shouldn't occur, since the code to handle it properly wasn't even written in the driver.

[gsh]

That was my fix!

Honestly!

Actually the USB -> serial devices were really bad devices because they're USB 1.1 devices (and therefore need split transactions) and they operate in a poor way...

Basically rather than using an interrupt endpoint to identify whether there is any data to be read they just set up an IN endpoint which it polls continuously. This then means we get huge numbers of interrupts per transaction which can happen multiple times per uframe (at one time as many as 70000 interrupts per second!)

But I implemented a NAK holdoff which means if it sees a NAK it will no resend the IN until the start of the next frame (i.e. it will poll the endpoint at a maximum speed of once per frame)

Gordon

[obcd]

Thanks for explaining that Gordon.
Didn't M33P made a Patch as well that improved the reliability of some older ftdi devices?
Before the Patch, they sometimes made the Kernel hang when you tried to access the device.
Reducing the speed to usb 1.1 also fixed it before his patch.

[gsh]

Ah yes you're right the channel halted thing which would lock up the kernel, I don't think it's been fixed yet though, I think we've worked around the lockup at the moment

Gordon

[rspitz]

I'm using a "Sundtek MediaTV Home" USB DVB-T/C Receiver to monitor the bandwidth usage of my cable internet. It is attached to a powered 7-port hub and operated in "bulk" mode (as opposed to isochronous), which is recommended by Sundtek for the RPi. There is a script which polls the 8 frequencies used for cable Internet every minute and writes the results into a RRD database.

Up to now, the device would lock up within minutes or hours, making the monitoring script useless. Since upgrading to "3.6.11+ #416 PREEMPT" with rpi-update, the script has been running for a week without a crash, so it seems that whatever fix was introduced up to that version of the firmware fixed my USB problem.

I must admit that I had gotten increasingly pessimistic about a possible solution, but I'm happy to be proven wrong. Thank you gsh and M33P for the good work.

[rspitz]

I should have known better

Within minutes after my "success!" posting, my Pi started acting up as before. The USB device is not accessible any more, nothing in dmesg. The command in the script setting the DVB-C frequency gives "/dev/dvb/adapter0/dvr0: No such device or address", even though it is there.

Ok, goodbye optimism, hello USB depression.

[gsh]

Sounds possible that it could be a dequeing issue.

There should be a fix for that soon...

Gordon

[scrishton]

Hi Gordon,

Sorry to pester, and no pressure, but any idea how soon? I'm starting to think that my USB / keyboard / rs422 problem is actually related to the 'curses' getch command being upset by the microframe scheduler enable. I was trying to find time to try reading key presses a different way, but it seems far more difficult than expected to implement an 'INKEY$' type command in python. And I'm probably barking up the wrong tree anyway.

And jamesh, before you advise me to sell my wonderful Raspberry Pies and use something more powerful, I used to design quite sophisticated hardware and software around PIC processors running at 4MHz, less than 2k of program memory and 36 BYTES of RAM, so the Raspberry Pi is orders of magnitude more powerful than I'm used to.

Simon R.

[jamesh]

Hi Gordon,

Sorry to pester, and no pressure, but any idea how soon? I'm starting to think that my USB / keyboard / rs422 problem is actually related to the 'curses' getch command being upset by the microframe scheduler enable. I was trying to find time to try reading key presses a different way, but it seems far more difficult than expected to implement an 'INKEY$' type command in python. And I'm probably barking up the wrong tree anyway.

And jamesh, before you advise me to sell my wonderful Raspberry Pies and use something more powerful, I used to design quite sophisticated hardware and software around PIC processors running at 4MHz, less than 2k of program memory and 36 BYTES of RAM, so the Raspberry Pi is orders of magnitude more powerful than I'm used to.

Simon R.

No worries, not going to advise sale - just patience. These sorts of things take a while to diagnose, determine a fix, and implement as you well know. That 'while' is quite often indeterminate. So patience is required.

[gsh]

You could try disabling microframe scheduling to see if it makes a difference at least

[M33P]

I should have known better

Within minutes after my "success!" posting, my Pi started acting up as before. The USB device is not accessible any more, nothing in dmesg. The command in the script setting the DVB-C frequency gives "/dev/dvb/adapter0/dvr0: No such device or address", even though it is there.

Ok, goodbye optimism, hello USB depression.

See - this is why these bugs are immensely annoying to even replicate, let alone troubleshoot. Something that works "for a week now" but then randomly goes silent without a bang or even a whimper under normal usage conditions is a major headache - was it a power glitch? Nearby lightning strike upset it? Software (or even device firmware) bug unrelated to the driver?

We also end up with some very obscure use case causing an issue with a device, yet other people using the same device don't have it (yours is a bit obscure - changing "channel" 8 times per minute) which makes hunting for a common theme much harder to do.

What we CAN do is simply find new ways of breaking the driver through telling it to do silly stuff - like queue a transaction then immediately cancel it. Patches for broken behaviour caused by stress tests will typically also fix things experienced under normal usage.

[scrishton]

Hi Gordon,

Disabling microframe scheduling works fine, but then I run out of interrupts when I add another HID device (Contour ShuttleXpress wheel). And on updates from 24th March and later (Rebuild with: dwc_otg: implement tasklet for returning URBs to usbcore HCD layer) it stops working again, even after fixing the reboot issue with memory split.

With earlier updates, microframe schedule disabled, and no ShuttleXpress it works brilliantly well, with twelve FTDI rs422 ports (three FTDI USB-COM422-PLUS4 http://uk.farnell.com/ftdi/usb-com422-p ... dp/1817175 cards) reliably controlling and monitoring a bank of video recorders at least 25 times per second for hours on end.

Simon R.

[gsh]

People who are having trouble with keyboards etc should try with the new fiq_split branch

http://www.raspberrypi.org/phpBB3/viewt ... 05#p345905

Gordon

[M33P]

People who are having trouble with keyboards etc should try with the new fiq_split branch

http://www.raspberrypi.org/phpBB3/viewt ... 05#p345905

Gordon

Oh snap

My Sidewinder X4 now works, for the first time ever[1]. The thing that killed it on the Pi was definitely 2 periodic interrupt endpoints because it has "macro" keys as well as being a normal keyboard. All we need now is confirmation that keyboards with crappy hubs in work...

I've yet to try it with all of my ebay-spectacular USB devices plugged in, but this is definitely a step in the right direction...

[1] for a given value of ever

[mikelangeloz]

People who are having trouble with keyboards etc should try with the new fiq_split branch

http://www.raspberrypi.org/phpBB3/viewt ... 05#p345905

Gordon

Thank you gsh!!!! This finally solved usb audio problems! I'm the dev behind RaspyFi, which uses usb as audio pathway for hi-fi music reproducion...
Before this fix, the pi used to loose lots of packets while streaming >44/16 audio via usb. Now this made the trick!!!
Thank you so much:
You can find reports of working peripherals here:
http://www.raspyfi.com/raspberry-pi-usb-audio-fix/