USB - the Elephant in our Room

[RoGeorge]

My A4Tech Wireless Desktop Padless 8200F (keyboard + mouse kit) works erratically.

Tested with both images:

• 2012-08-16-wheezy-raspbian.zip
  2012-08-08-wheezy-armel.zip

with 3 different power supply (4.5V, 5V, 5.25V) and 2 different SD cards (2GB SD and 8GB class 6 SDHC).

The results are the same:

• 1. Before starting X, the keyboard woks almost normally.
  2. If I overclock to 800 or 900 MHz, the keyboard works great before starting X.
  3. After starting X, no meter what, the keyboard works erratically:
  • - missing at least 1 out of 3-5 letters
    - very often the last pressed key autorepeats with no reason, until any key is pressed again.
  4. If I logout from X (at standard speed), the keyboard is still erratically, but less then before. Even so, is erratically enough so I can't type the username/password after a restart. With overclock, it's almost usable after leaving X, but far from normal.

I suppose there is something wrong with the USB.
The chipset is "SMSC LAN 9512 JZX" and the processor is
"SAMSUNG 222 K4P2G324ED-AGCI"

Do I have a defective unit or it's a known bug? Should I try to send back the board and ask for a replacement? Should I buy another keyboard? Please help me with any advice or directions, I already waisted a whole day testing all these.

I am very new to Raspberry Pi, just bought one yesterday, and for me it's unusable...

[MattOwnby]

gsh is looking into the FTDI issue. It seems the device generates a continuous stream of NAKs which causes a very high interrupt rate (about 44k/s). He's investigating if we can delay dealing with the NAKs to throttle the rate so there may be a solution.

I think using the dedicated UART pins will definitely resolve the performance issue.

Welp, I successfully got the GPIO UART working (using a 330ohm and 680ohm resistor because that's all I had lying around) and it _seems_ to be working. It does lock up randomly but I haven't found where the lockup is occurring yet.

[kyelo]

I am trying to set up a Logitech USB H530 headset as my audio device on my R_pi , hoping to do VOIP using Ekiga or Twinkle or Puppy's Psip softphone.

I have found several reports of this headset working out-of-the-box on Debian and Ubuntu on x86 devices, so I thought the headset might work with R_pi.

I plug the Logitech H530 into a D-Link 7-port powered USB 2.0 hub, which is plugged into the R_pi. lsusb and lsmod both see the Logitech H530.

I have made the Logitech H530 my primary device, and my aplay -l is:

Code: Select all

Card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
		(ALSA subdevices list) 
Card 1: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
		Subdevices: 1/1
		Subdevice #0: subdevice #0

and my /etc/asound.conf is

Code: Select all

pcm.! default{
		type hw
		card1
	}
	ctl! default {
		type hw
		card 1
	}

I can use something like "arecord -f S16_LE test.wave" to record, and "aplay test.wav" to play my recording. and can use gnome-mplayer to play commercially prepared wma music files.

I really would like to use VOIP on my R_pi. I have Twinkle version 1.4.2 running on my R_pi system (I have the same version of Twinkle running "normally" on an x86 netbook for comparison).

On my R_pi, when I dial a number, it will fail to connect, or often connect but then I receive a disconnect after 2-3 seconds. For example, SIP providers often provide an "echo chamber" to test one's send and receive capability. When I try this with R_pi/Twinkle, I get a voice explaing how to use the service but typically after 1 sentence the voice disappears. Twinkle is still there and apparently stable and responsive (there is a timer to record the duration of the call, and it is still ticking away). I manually have to terminate the call. The active twinkle window says "far end answered call", but the Twinkle log says "SIP/2.0 404 not found".

R_pi's dmesg says "usb 1-1.2.2 reset full-speed usb device number 6 using dwc-otg", and of course device number 6 is the Logitech USB headset. Often dmesg also contains a line such as "retire_capture_urb: 45 callbacks supressed".

I am using Raspbian 3.2.27+ #96 PREEMPT with sdhci-bcm2708.enable_llm=1 and dwc_otg.microframe_schedule=1 added.

Twinkle (with the same configuration as on the R_pi) works as expected on the x86 netbook under Puppy Linux.

How can I improve on this situation?

[pluggy]

I am trying to set up a Logitech USB H530 headset as my audio device on my R_pi , hoping to do VOIP using Ekiga or Twinkle or Puppy's Psip softphone.

I have found several reports of this headset working out-of-the-box on Debian and Ubuntu on x86 devices, so I thought the headset might work with R_pi.

....
How can I improve on this situation?

Use something other than a Pi ?

I have lots of stuff that works out of the box on Ubuntu (I use it full time on my main computer) that the Pi won't entertain. This thread is here in response to the poor USB implementation on the Pi, lots of stuff that should work doesn't. Its getting better, but its a long way off yet.

[thradtke]

Its getting better, but its a long way off yet.

Why? If the bug is known and the hardware is ok, it can be fixed. What are the various 'fixes' good for? What are they doing? I also suffer from USB problems and fail to understand what's currently going on. Can anyone explain? Maybe we could have a sticky read only thread where advances are reported in a way the noob can understand.

[jamesh]

The various fixes have improved the situation but there are still problems. This is a pretty complex piece of code (not written by the foundation but by the suppliers of the USB hardware in the chip), and even if you know what the problem is, there are real difficulties in finding a solution.

I'm not sure myself what the fixes have and haven't done. I know they have improved reliability a lot, but it's still not perfect.

[pygmy_giant]

I've yet to encounter a problem with the USB with the peripherals that I use, but don't disbelieve those who do report problems.

I know it's certainly beyond me, but how difficult would it be for 'someone' to re-write the driver from scratch...?

At lease a community grown driver would be easily understood and easy to maintain.

[techpaul]

Its getting better, but its a long way off yet.

Why? If the bug is known and the hardware is ok, it can be fixed. What are the various 'fixes' good for? What are they doing? I also suffer from USB problems and fail to understand what's currently going on. Can anyone explain? Maybe we could have a sticky read only thread where advances are reported in a way the noob can understand.

A typical USB stack and its supporting functions for classes of devices, then interfacing to hardware and operating system is usually around 10,000 lines of software in high level language.
I would not want to estimate how long any bug fixing of someone elses code of that sort of size will take.

[pygmy_giant]

could it be quicker and easier to re-write it?

[techpaul]

could it be quicker and easier to re-write it?

Doubt it most USB stacks are about 6 months of FULL time development and 6 months of testing.

Do a google search for USB stacks for embedded systems and see how much they cost and how few there are

[pygmy_giant]

What about re-writing a portion of it?

I imagine that 99% of the driver is ok

If the problem is identified and the code is modular and if the source code is available and if the module where the problem originates can be identified could not just that modular part be re-written?

Am I being naive?

[jamesh]

Yes!

In effect the guys looking at the code are rewriting bits of it. They have already got further than community efforts in the past (same HW, different devices), because they have access to the RTL of the HW (the high level design language).

Writing embedded code is pretty difficult when you are talking direct to the HW. It's especially difficult taking on someone else's thinly documented code and trying to fix it.

[pygmy_giant]

Thanks for explaining - do these improvements magically show up in the firmware updates for blissfully ignorant people like me to take for grated?

If so, are we due for any more improvements in the near future?

Think I'm one of the lucky ones who isn't experiencing any issues, but I do sympathise with people who are.

I'm happy to settle for adequate rather than perfect.

[dom]

Do these improvements magically show up in the firmware updates for blissfully ignorant people like me to take for grated?

Yes. If you have ran rpi-update or apt-get upgrade lately you should have the recent USB fixes.

[pygmy_giant]

Thanks - we all do appreciate your hard work even if we are not aware of it.

I notice that someone has put 'sudo rpi-update' in their /boot/cmdline.txt so that their system is always updated. I notice also that some other people have updated and then report experiencing new problems.

Is there a simple way to have the Pi automatically notify people if an update is available without updating so that they don't miss out and so that they can have the option of making a back-up image of their current system before updating?

[dom]

Is there a simple way to have the Pi automatically notify people if an update is available without updating so that they don't miss out and so that they can have the option of making a back-up image of their current system before updating?

You can check what you'll get from rpi-update here:
https://github.com/Hexxeh/rpi-firmware/commits/master

The "apt-get upgrade" updates for the kernel/firmware are much less frequent (once or twice a month) and should be more stable.
If you got no specific problems, then just use that channel.

The rpi-update channel is for users with specific problems, or for people who like to help with testing.

[pygmy_giant]

Thanks for explaining that - I had wondered what the difference was!

[ubergrog]

Sorry for driving this more off-topic with a quick question. I've always ran dist-upgrade before rpi-update. Is that necessary? TX

[thradtke]

A typical USB stack and its supporting functions for classes of devices, then interfacing to hardware and operating system is usually around 10,000 lines of software in high level language.

Considering

(1) packages are lost no matter the client hardware, i.e. drivers behind the lowest level of the stack apparently doesn't matter

(2) a few things *are* known, like packages are acknoleged but not registered, further supporting the conclusion from (1)

and

(3) There's obviously a connection between losing packages and mixed protocols on the hub

If I'm not mistaken with this list, I guess the number of lines in questions are melting down significantly.

No critics from my side, but I know I might sound different (english is not my first language and the british culture of communication is also not mine). I just wanted to know where we stand (thanks James) and if we get closer to a solution (currently not as it seems).

[techpaul]

A typical USB stack and its supporting functions for classes of devices, then interfacing to hardware and operating system is usually around 10,000 lines of software in high level language.

Considering

(1) packages are lost no matter the client hardware, i.e. drivers behind the lowest level of the stack apparently doesn't matter

(2) a few things *are* known, like packages are acknoleged but not registered, further supporting the conclusion from (1)

and

(3) There's obviously a connection between losing packages and mixed protocols on the hub

If I'm not mistaken with this list, I guess the number of lines in questions are melting down significantly.

Not really as if you can see the layers above and below you can follow through what the code/hardware is actually doing, compared to the thin or non-existant documentation. Sometimes it may be your level or an undocumented 'feature' you have to code around in a different layer.

[jamesh]

No critics from my side, but I know I might sound different (english is not my first language and the british culture of communication is also not mine). I just wanted to know where we stand (thanks James) and if we get closer to a solution (currently not as it seems).

If you read this thread beginning to end you will see a lot of progress has already been made to improve the driver - by definition we are now closer to a solution. Most fixes described above have improved the situation, to the point where its works for many more people than it used to.

[pygmy_giant]

This thread is proof of success: http://www.raspberrypi.org/phpBB3/viewt ... et#p166969

[thradtke]

Yes, I see the situation has improved for many users. Still, I cannot have mouse and keyboard on the hub at the same time, despite having enough juice from the PSU. It even got worser, as before recent updates, keyboard dropouts were only noticable under LXDE. Now I have them at the console, too. My solution is, of course, to have the keyboard on the internal Pi hub and the mouse on the external hub.

Guess I have to be patient and cross my fingers for those volunteers caring about the situation. Thanks to all of you. Hope you find a solution.

[ppuskari]

I wish I knew more about the design of a standard USB stack. I also wish someone else might be able to help usblog the USBIP virtual hub system to potentially see what layer it might be happening at.

I bring this up because no matter what I try I can not get the usb package loss symptoms to occur if I'm passing the data through this way to get remote usb devices appearing on the local Pi stack. Works solid and well. The caveat here is that I'm using the wired ethernet port, which by design is a node on the 3 port internal usb hub as well. Perhaps the tcp characteristics involved mask the missing package?

Does that mean it's hardware/power? Or does that mean USBIP just inserts above the usb stack layer that has the issue? hmmmm.

[gsh]

The USBIP sits above all the USB code, in fact it is a completely separate USB stack to the real one so tells you nothing, its nice that it works though!

Gordon