USB packet loss.


254 posts   Page 2 of 11   1, 2, 3, 4, 5 ... 11
by gsh » Sat Jun 30, 2012 11:22 am
Yes,

I am looking at it now, taking some time but I've got the Yoctopuce board reproducing the problem and have started to understand the problem... It seems to be something to do with the hub and split transactions, I don't think the NYET is being handled properly. So it'll only effect 1.0 and 1.1 devices (which is why we don't seem to see this packet loss with mass storage etc)

Cheers

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 780
Joined: Sat Sep 10, 2011 11:43 am
by thexman » Sat Jun 30, 2012 4:46 pm
thanks for the update hopefully its a simple enough fix and if you could let us. me know that would be great
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by Burngate » Tue Jul 03, 2012 5:23 pm
While gsh is busy in one corner sorting this out, and the rest of us are in another keeping out of his hair ...
... is it possible that this could explain some of the keyboard problems? After all KBs are slow devices ...
Wyszkowski's Second Law: Anything can be made to work if you fiddle with it long enough.
Brain surgery is easier than psychoanalysis
User avatar
Posts: 2749
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by thexman » Tue Jul 03, 2012 8:11 pm
if there having issues with USB 1.0 and USB1.1 Version hardware i would assume most if not all keyboards never got passed 1.0/1.1 versions i don't remember seeing a 2.0 USB keyboard as 2.0 is backward compatible did you mean the repeated key and missing key stokes issue. mentioned elsewhere on forum if so yes this might fix that issue. lets hope its not a Board killer.
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by Burngate » Wed Jul 04, 2012 9:52 am
That was my thought.
On the brand new wonderful wireless keyboard / mouse I bought for the Pi I get the stutters. The mouse works with no problems.
I've checked all voltages, everything ok. Also works perfectly when plugged into laptop, no stutters.

It would seem to me that key-down events get through reliably - I've never yet seen a missed keystroke - but key-up events are sometimes missed, leading to repetition. The next key-down will then terminate that.


On another setup (different wireless keyboard/mouse, PS2 only, through PS2-only KVM, to wiindows-PC / RiscPC / A9home /laptop) I was getting stutters when I connected the KB through a PS2 - USB translatory dongle thingy. Since USB packets couldn't (?) get through the KVM, it's got to be the translation. And the laptop it was connected to was XP, so it probably not wasn't windows USB stack. I'll have to try that situation with one of the other machines - maybe the A9home - to see what happens.
And also with a USB 1 hub to get rid of USB 2 packets - I don't think they make USB 2 devices that aren't backward compatible with USB 1, to get rid of USB 1 packets.
Wyszkowski's Second Law: Anything can be made to work if you fiddle with it long enough.
Brain surgery is easier than psychoanalysis
User avatar
Posts: 2749
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by Burngate » Wed Jul 04, 2012 10:08 am
As far as board-killer is concerned, I don't expect that.
My understanding is that there's a pile of electronics between the USB port of the Pi and the Arm.
First off is the 9512 chip. There may be a problem with that, which would be difficult to get round. But it would have been found before now since it's a standard chip.
Then there's the SoC. Most of that is under Broadcom control, and is set up by the blob. They seem to have designed in enough flexibility to allow this sort of problem to be tackled in the blob.
After it hits the Arm, everything's in the kernal, which is just a re-compile away.
Wyszkowski's Second Law: Anything can be made to work if you fiddle with it long enough.
Brain surgery is easier than psychoanalysis
User avatar
Posts: 2749
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by thexman » Wed Jul 04, 2012 10:59 am
yup i fully expect it to be a blob issue or a blob fix for the issue to go away no one else using the 9512 chip reports such problems

the Film the Blob is a horror film every mention of the Blob makes me think Nighmare / horror. they should rename Blob to broadcom code or sumthing makes it less worrying

:lol: :lol:

anyways Hopefully the man at Broadcom i assume is looking at it fixes it with a reasonable time scale i know most of them work for free or do the stuff of an evening after a hard day at work sipping coffee sitting on bouncy balls..(google) maybe not Broadcom, but still i spend most days coding and Fault finding on Proprierty control systems and posting here it seams but should it be that hard to fix quickly.?
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by ledow » Wed Jul 04, 2012 11:10 am
Burngate wrote:As far as board-killer is concerned, I don't expect that.
My understanding is that there's a pile of electronics between the USB port of the Pi and the Arm.
First off is the 9512 chip. There may be a problem with that, which would be difficult to get round. But it would have been found before now since it's a standard chip.
Then there's the SoC. Most of that is under Broadcom control, and is set up by the blob. They seem to have designed in enough flexibility to allow this sort of problem to be tackled in the blob.
After it hits the Arm, everything's in the kernal, which is just a re-compile away.


Yes, but it only needs a tiny little passive component in between those chips to be the wrong value (or even be improperly traced with too large a track on the PCB) and it could also easily end up dropping packets under load - i.e. power load / frequency of nearby tracks affects the capacitance / resistance of some of those chip interconnects. And that WOULDN'T be an easy problem to fix without board changes. The OpenPandora had something similar with their wireless - all the designs were in compliance with the manufacturer's instructions but the PCB printer put too thin a trace on the final boards, which lowered the capacitance at a critical point, and effectively killed the wireless chips on all those boards or at least crippled their speed.

That said, I think it'll probably be some firmware-y sort of issue, but given that it's taken over a month to start looking at it, I don't expect a quick fix any time soon.
User avatar
Posts: 36
Joined: Thu Feb 02, 2012 12:55 pm
by thexman » Mon Jul 09, 2012 6:38 pm
gsh wrote:Yes,

I am looking at it now, taking some time but I've got the Yoctopuce board reproducing the problem and have started to understand the problem... It seems to be something to do with the hub and split transactions, I don't think the NYET is being handled properly. So it'll only effect 1.0 and 1.1 devices (which is why we don't seem to see this packet loss with mass storage etc)

Cheers

Gordon



ANY NEWS Gordon would really really like to get on with the Project i had designed before the Raspberry pi fell flat on its face . thanks in advance of a good answer
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by thexman » Wed Jul 11, 2012 2:58 pm
Gordon hows the fixing going or anyone from the Foundation im sitting here patiently waiting for an answer :)
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by yoctopuce » Thu Jul 12, 2012 12:26 pm
Bad news for Raspberry Pi users today:
- Gordon informed us by mail that he was "stuck on other work", so it is unlikely that we will get a fix for the issue in the near future.
- Although we have proved that the problem is on Raspberry side, and Gordon has hinted it may affect any USB 1.x device (eg. keyboard, mouse, modem), the Raspberry team still considers this as a problem specific to our devices.

So until more device vendors spend time to provide the same proofs to Raspberry as we did (dedicated test device, kernel trace and USB analyzer logs), the USB 1.x packet loss issue will not be considered as a high priority for Raspberry team.

We are sorry about this, but we understand that, when people have to fix bugs on their free time, it cannot be different. These are the limits of the "free development" model.
We produce USB controllers, USB sensors as well as embedded USB hubs for DIY projects
User avatar
Posts: 19
Joined: Sat Mar 03, 2012 11:27 pm
by JPI » Thu Jul 12, 2012 2:03 pm
Well I might have seen this issue when I have tried connecting an UPS to RPi. It is a Powerware model ("new low speed USB device" says dmesg). I have tried it with Debian Squeeze and the UPS works ok with the same driver version and Debian running on x86_64.

I have no USB debugging skills so I have only checked the hex debug output provided by the driver and it seems that the first 128 bytes are equal on RPi and x86_64 machines and then something strange happens and the driver outputs some error.

This might be some totally different issue but I decided to write here in case the foundation wants to hear about other similar issues. However I am not able to provide much more information with my skills, sorry.
Posts: 2
Joined: Tue Jul 03, 2012 6:10 am
by ledow » Fri Jul 13, 2012 7:53 am
yoctopuce wrote:Bad news for Raspberry Pi users today:


That's okay. My RPi is still sitting in the box waiting for something practical to work on it. Given the single (not unreasonable) project I bought it for has been stymied on several levels, it can just stay in the box. A lesson to myself in why I don't preorder things. I've also advised my employer's that it's completely unsuitable for deployment in school for the things we were hoping to trial.

Pretty poor show, to be honest. If it affects any USB 1.x device, then how can it be a problem specific to a particular device? It's basically NOT a USB-compatible port, that's what I have taken away from the silence over the past month.

Because, you know, everyone has a USB analyzer, can provide kernel traces, supply example test devices, etc. don't they? And that big company that's producing the RPi, they obviously have no hardware of that kind at all, clearly... :roll:

Back to plan B for me. It's going to get shoved into the loft somewhere and sold when I find it again in 20 years.

Note to self: RPi does NOT have a USB-compliant port. And may not work on your SD card.
User avatar
Posts: 36
Joined: Thu Feb 02, 2012 12:55 pm
by zefiris » Mon Jul 16, 2012 10:10 pm
Hi

I think I've hit this issue too. It happens when I record audio from a USB audio device or capture samples from a USB radio tuner. I presume both devices use isochronous mode.

Interestingly, I see a pattern in the received stream. It looks like every second byte is being corrupted. Here's an excerpt of a stream:

Code: Select all
$ hexdump -s 1000000 -n 1000 -C /dev/shm/test
000f4240  00 85 00 7f 00 68 00 4d  00 2d 00 09 00 00 09 00  |.....h.M.-......|
000f4250  38 00 5d 00 7a 00 92 00  94 00 8c 00 86 00 8a 00  |8.].z...........|
000f4260  97 00 ad 00 cb 00 e6 00  ff 29 ff 5a ff 7c ff 9b  |.........).Z.|..|
000f4270  ff ba ff d5 ff dd ff d8  fd db f8 e8 f3 f5 dd ff  |................|
000f4280  b5 ff 7d ff 3a ff 00 ff  00 ff 00 e9 00 cd 00 c5  |..}.:...........|


It looks like the corrupted bytes are reported as 00 or ff.

I see the same pattern from both devices. For the USB audio device, I see it in the stream produced by arecord via ALSA. For the USB radio tuner, I see it from the stream from a custom libusb-based program.

Anyway, this issue is currently blocking my application so I'm interested in getting it fixed. I may even attempt some fiddling with the dwg_otg driver, but I'm not sure where to start. Does anyone have any hints or suspicions about what might be going on?

By the way, I noticed this change to the dwg_otg driver in the R-Pi kernel source tree recently:
https://github.com/raspberrypi/linux/co ... bed74679a3
It seems like it may be related to this problem but it didn't help when I tried switching it on.
Posts: 2
Joined: Mon Jul 16, 2012 9:59 pm
by jbeale » Mon Jul 16, 2012 11:26 pm
This is a somewhat random thought, I'm writing because it MAY possibly be relevant.

I have an old HHB MDP-500 MiniDisc deck with a USB audio output. This is not a Sony HiMD device with a proprietary driver, it is a "professional" deck which appears as a standard USB 1.1 audio device. When I got it, quite a few years ago, I found it would not talk to my PC, either direct or through a USB 2.0 hub but it did work correctly through a USB 1.1 hub. Apparently there is something about the USB audio in particular, or isochronous USB streams generally, that was not correctly handled by the USB interface chipset on my PC motherboard, unless first put through a USB 1.1 hub. I vaguely recall something at the time about how this type of USB audio device was seldom used and that's why the chipset vendor went to production without noticing the problem, but no idea if that's true.

Anyway, just wanted to throw that out there, in case it has any bearing on the issue. If you can still buy a USB 1.1 only (NOT USB 2.0 compliant) hub, it might be something to try.
User avatar
Posts: 2011
Joined: Tue Nov 22, 2011 11:51 pm
by jbeale » Mon Jul 16, 2012 11:35 pm
zefiris wrote: It looks like every second byte is being corrupted. Here's an excerpt of a stream:

Code: Select all
$ hexdump -s 1000000 -n 1000 -C /dev/shm/test
000f4240  00 85 00 7f 00 68 00 4d  00 2d 00 09 00 00 09 00  |.....h.M.-......|
000f4250  38 00 5d 00 7a 00 92 00  94 00 8c 00 86 00 8a 00  |8.].z...........|
000f4260  97 00 ad 00 cb 00 e6 00  ff 29 ff 5a ff 7c ff 9b  |.........).Z.|..|
000f4270  ff ba ff d5 ff dd ff d8  fd db f8 e8 f3 f5 dd ff  |................|
000f4280  b5 ff 7d ff 3a ff 00 ff  00 ff 00 e9 00 cd 00 c5  |..}.:...........|


It looks like the corrupted bytes are reported as 00 or ff.

Are these 16-bit integers in 2's complement format? If so, for small signals, you'd normally expect the high-order byte to be either 0x00 (for a small positive number) or 0xff (small negative number). For slightly larger signals you'd see 0x00 become 0x01, 0x02 etc. and 0xff move to 0xfe, 0xfd etc.
User avatar
Posts: 2011
Joined: Tue Nov 22, 2011 11:51 pm
by zefiris » Tue Jul 17, 2012 12:18 am
jbeale wrote:Are these 16-bit integers in 2's complement format? If so, for small signals, you'd normally expect the high-order byte to be either 0x00 (for a small positive number) or 0xff (small negative number). For slightly larger signals you'd see 0x00 become 0x01, 0x02 etc. and 0xff move to 0xfe, 0xfd etc.


Ah, good point!

In the case above (from my USB radio tuner), they are supposed to be unsigned 8-bit integers. However, there are two interleaved channels so it's possible that one channel has a problem.

My other device (the USB audio device) does use 16-bit signed integers. So that may indeed be the cause of the pattern there.
Posts: 2
Joined: Mon Jul 16, 2012 9:59 pm
by thexman » Tue Jul 17, 2012 2:18 pm
the reported Bug will happen to some effect on all V1.0 and v1.1 USB device's HiD Device drivers

so if more people reports the model of equipment not currently working it might push this up into the Things to do list rather than the thing to ignore list its currently on

this wont be a commiunity Fix its a Blob issue they coded something wrong it what i understand and untill its coded correctly it will never work. end off.
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by abishur » Tue Jul 17, 2012 2:49 pm
thexman wrote:this wont be a commiunity Fix its a Blob issue they coded something wrong it what i understand and untill its coded correctly it will never work. end off.


Actually the blob is for handling the GPU, so it might yet be community fix ;-)
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4261
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by thexman » Tue Jul 17, 2012 4:35 pm
abishur wrote:
thexman wrote:this wont be a commiunity Fix its a Blob issue they coded something wrong it what i understand and untill its coded correctly it will never work. end off.


Actually the blob is for handling the GPU, so it might yet be community fix ;-)



Well if thats the Truth why doesnt anyone seam to know how to fix the issue as Debian devices other than the Rasperry pi are working correctly with my devices but the Raspberry pi doesnt so what changed oh yeah RPI is the only differance , so as the device's dont work with Wheezzy also, what are we supposed to think, the RPI foundation are Volenteers from whats been written so after selling 500,000 units isnt it about time to fix all the issues (employ some one for a month )and continue from a Firm footing rather than people continualy reporting faults with no or little help or responce from the makers.
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by abishur » Tue Jul 17, 2012 6:41 pm
thexman wrote:
abishur wrote:
thexman wrote:this wont be a commiunity Fix its a Blob issue they coded something wrong it what i understand and untill its coded correctly it will never work. end off.


Actually the blob is for handling the GPU, so it might yet be community fix ;-)



Well if thats the Truth why doesnt anyone seam to know how to fix the issue as Debian devices other than the Rasperry pi are working correctly with my devices but the Raspberry pi doesnt so what changed oh yeah RPI is the only differance , so as the device's dont work with Wheezzy also, what are we supposed to think,


Easy, easy! I never even began to claim that the R-pi isn't the issue here. All I said is that it's not the blob as that's just for dealing with the GPU. There is undeniably a driver issue or a compatibility issue (a driver with the way the ARM based pi interacts with the LAN9512 chip or perhaps the chip itself is incompatible with the devices).

The RPI foundation are Volenteers from whats been written so after selling 500,000 units isnt it about time to fix all the issues (employ some one for a month )and continue from a Firm footing rather than people continualy reporting faults with no or little help or responce from the makers.


To be fair, there's been a great deal of support from the makers (do a search on the posts from Gert or Jamesh) the issue is that no matter how many people you add to the payroll to deal with this, it will always be a triage situation where the most pressing/desired issue goes to the top, and the least desire/pressing issue remains at the bottom. This issue (in my opinion anyway, so please take that with a grain of salt! :-)) is less pressing than than getting the gui to a working point and based off the number of threads/activity in said threads, less desired than an mpeg-2 codec. Neither of those things are said to be offensive or callous, all I'm saying is that it's unfair to say "since this issue isn't getting an immediate response, that means they're not helping anyone"
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4261
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by thexman » Fri Jul 20, 2012 8:55 pm
Abushur

Your last line I think you say immediate response I've been reporting the fault since 7th April
it's taken till now to get one post reply from the foundation I'm looking then, that person contacted the manufacturer and told them they were to busy to continue looking into it

And still no confirmation of where the fault lies so someone else could take up the challenge to fix it.
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm
by dom » Fri Jul 20, 2012 10:59 pm
@theaxman
I can confirm that the USB driver code runs exclusively on the ARM through the linux driver, and the GPU blob (start.elf) has no USB related code.
All the USB bugs present are in the publically visible github code.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by abishur » Sat Jul 21, 2012 12:48 am
thexman wrote:Abushur

Your last line I think you say immediate response I've been reporting the fault since 7th April



yes I say immediate, but the point of the sentence was to point out the fallacy of the argument in "they're not helping my issue = they're not involved in helping anyone period"

it's taken till now to get one post reply from the foundation I'm looking then, that person contacted the manufacturer and told them they were to busy to continue looking into it


See the fore mentioned triage issue I mentioned in my last post ;-)
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4261
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by thexman » Sun Jul 22, 2012 1:03 pm
dom wrote:@thexman
I can confirm that the USB driver code runs exclusively on the ARM through the linux driver, and the GPU blob (start.elf) has no USB related code.
All the USB bugs present are in the publically visible github code.



well if thats the case and the git-hub code is the same code used in debian Linux then why does it work fine on a Qnap Server Linux box but not on a PI i again Point you to the PI. as the libusb file is the same one used for all users of Linux unless of course the RPI foundation decided it new better and changed something fundamental to operation unlikely as they don't do software apparently thats the responsibility of the community so ok

who in the community made the software change that now prevents USB-lib code to fail and loose some packets.. ill wait for ever for an answer as the community haven't made changes.

if Dom is able to Point me in a more meaning full direction to where the Problem lies then i might be able to solve the issue by simply comparing a working Linux Soc system with the Pi system and files, to work out where the problem is. code - hardware or both.
one armed controls engineer, my grammar is bad but lets face it most keyboards don't suit a one armed man
Posts: 259
Joined: Sat Apr 07, 2012 2:18 pm