RoGeorge
Posts: 3
Joined: Wed Sep 05, 2012 1:04 pm

Re: USB - the Elephant in our Room

Wed Sep 05, 2012 2:11 pm

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... :cry:

MattOwnby
Posts: 58
Joined: Thu Aug 16, 2012 7:22 pm

Re: USB - the Elephant in our Room

Wed Sep 05, 2012 2:25 pm

dom wrote: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.
Image

kyelo
Posts: 64
Joined: Sun Oct 23, 2011 6:31 pm

USB Headset Involuntary Reset

Thu Sep 06, 2012 6:23 pm

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?

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB Headset Involuntary Reset

Thu Sep 06, 2012 7:22 pm

kyelo wrote: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.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB Headset Involuntary Reset

Fri Sep 07, 2012 1:37 pm

pluggy wrote: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.
Rocket Scientist.

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

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 1:59 pm

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.
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

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:04 pm

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.
Last edited by pygmy_giant on Fri Sep 07, 2012 4:08 pm, edited 1 time in total.
Ostendo ignarus addo scientia.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: USB Headset Involuntary Reset

Fri Sep 07, 2012 4:07 pm

thradtke wrote:
pluggy wrote: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.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:09 pm

could it be quicker and easier to re-write it?
Ostendo ignarus addo scientia.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:12 pm

pygmy_giant wrote: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
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:24 pm

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?
Ostendo ignarus addo scientia.

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

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:28 pm

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.
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

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:34 pm

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.
Last edited by pygmy_giant on Fri Sep 07, 2012 4:38 pm, edited 1 time in total.
Ostendo ignarus addo scientia.

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

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:35 pm

pygmy_giant wrote: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
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:49 pm

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?
Ostendo ignarus addo scientia.

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

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:54 pm

pygmy_giant wrote: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
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 4:57 pm

Thanks for explaining that - I had wondered what the difference was!
Ostendo ignarus addo scientia.

ubergrog
Posts: 6
Joined: Sun Aug 12, 2012 9:00 pm

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 5:06 pm

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
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB Headset Involuntary Reset

Fri Sep 07, 2012 5:54 pm

techpaul wrote: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).
Rocket Scientist.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: USB Headset Involuntary Reset

Fri Sep 07, 2012 7:32 pm

thradtke wrote:
techpaul wrote: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.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

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

Re: USB Headset Involuntary Reset

Fri Sep 07, 2012 9:21 pm

thradtke wrote:
techpaul wrote: 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.
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

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Sep 07, 2012 11:37 pm

Ostendo ignarus addo scientia.

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Sun Sep 09, 2012 9:36 am

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.
Rocket Scientist.

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

Re: USB - the Elephant in our Room

Tue Sep 11, 2012 4:39 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1445
Joined: Sat Sep 10, 2011 11:43 am

Re: USB - the Elephant in our Room

Tue Sep 11, 2012 6:04 am

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
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

Return to “Troubleshooting”