This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11664 - Workaround for usb random failures on amsv2.
Attached to Project:
Rockbox
Opened by amaury pouly (pamaury) - Sunday, 10 October 2010, 18:51 GMT+2
Last edited by Rafaël Carré (funman) - Tuesday, 13 December 2011, 21:45 GMT+2
Opened by amaury pouly (pamaury) - Sunday, 10 October 2010, 18:51 GMT+2
Last edited by Rafaël Carré (funman) - Tuesday, 13 December 2011, 21:45 GMT+2
|
DetailsThis patch is a possible workaround the usb random failures on amsv2 (mainly clip+).
The test procedure is as follow: 1) Apply the first patch [as3525v2-enable-usb] (to svn head) 2) Try to plug/unplug the player several times (10 or 20 times or even more if you want) and note how many times it fails to work (no mass storage device detected, doesn't mount) 3) Apply the second patch [as3525v2-usb] (to svn head) 4) Repeat step 2) The expected result is >0 failures in 2) and 0 failures in 4). All amsv2 devices are interesting: - fuzev2 to check regression - clip+ to check improvement Comments on the patch are welcome. 
as3525v2-enable-usb.diff
(0.5 KiB)
b/firmware/export/config/sansaclipplus.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
as3525v2-usb.diff
(2.3 KiB)
b/firmware/export/config/sansaclipplus.h | 4 ++-- b/firmware/target/arm/as3525/usb-drv-as3525v2.c | 19 ++++++++++++++++++- b/firmware/usbstack/usb_storage.c | 2 +- 3 files changed, 21 insertions(+), 4 deletions(-) |
This task depends upon
Closed by Rafaël Carré (funman)
Tuesday, 13 December 2011, 21:45 GMT+2
Reason for closing: Out of Date
Additional comments about closing: USB is now enabled.
If there are still bugs they should probably discussed somewhere else.
Tuesday, 13 December 2011, 21:45 GMT+2
Reason for closing: Out of Date
Additional comments about closing: USB is now enabled.
If there are still bugs they should probably discussed somewhere else.
With the first patch it fails sometimes (as expected).
With the second, doesn't fail as much but three times it "froze", as in it's stuck in main menu (which is weird) or the "usb cable screen". The menu cannot be navigated. Kernel says "device not accepting address 19, error -32". The player (and its USB, too) is then unusable until I power off the player forcefully (holding power button for a while). Rockbox wasn't fully dead though. The display shuts down after a while and a button click lights it again (when unplugged).
[256687.316571] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 19
[256687.391694] usb 2-1.3.1: device descriptor read/64, error -32
[256687.556558] usb 2-1.3.1: device descriptor read/64, error -32
[256687.730427] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 20
[256687.805363] usb 2-1.3.1: device descriptor read/64, error -32
[256687.981411] usb 2-1.3.1: device descriptor read/64, error -32
[256688.155370] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 21
[256688.557108] usb 2-1.3.1: device not accepting address 21, error -32
[256688.630555] usb 2-1.3.1: new low speed USB device using ehci_hcd and address 22
[256689.033079] usb 2-1.3.1: device not accepting address 22, error -32
[256689.033460] hub 2-1.3:1.0: unable to enumerate USB device on port 1
On some plug-in attempts it says "low speed", on some "high speed", I'm confused.
Can't reproduce it reliably. It doesn't happen very often.
Without patch: fails most of the times.
With patch: 100% working :-D Plugged in/out at least ten times, I didn't experience any lockup and the player always got recognized. Had a glitch where it said that the device connected in 1.1 mode, but OF does that too sometimes, I suspect a dodgy cable.
but it doesn't work for me, at the moment of plugin in the USB cable in the Computer (Host: Win7) I get:
*PANIC*
usb-drv: wrong architecture (0)
Would it be possible to post a diff file were the needed changes in config/SansaFuzeV2.h are also included?
Cheers
I attached a modified version of the diff for fuzev2 but I can't test it myself. Hope it helps.
Great patch! Under normal circumstances USB works perfectly. However, if I use 'charge mode' (ie hold select while plugging in) the host (Ubuntu 10.10) then gives a kernel error every time I plug the player in until I reboot the PC. The bootloader also fails to build for me, with the same errors as above.
[22791.125982] ehci_hcd 0000:00:1a.7: port 4 reset error -110
[22791.141985] ehci_hcd 0000:00:1a.7: port 4 reset error -110
[22791.141992] hub 1-0:1.0: hub_port_status failed (err = -32)
The point of the patch is not to eliminate all kernel errors because it's impossible to do it this way. The point of this patch is to achieve a working state every time you plug the device, even if the device goes through an unstable state and kernel emits errors. In your case, my question is: after these errors, is the device eventually working or not as a mass storage ?
Second patch works consistently, however my WinXP SP3 box sometimes gives a message saying I should connect to a High-Speed USB port. I get no such message using the OF.
I did get a panic, something about the USB driver waiting for an ACK when something else happened. I haven't reproduced it.
I have an old box running Ubuntu 10.04, I'll try to test on it tomorrow.
I can reproduce the USB 1.1 issue most of the times with the following procedure:
1. turn the fuze2 on, connect to the host (win7) -> USB 2.0
2. disconnect
3. connect again to the host -> USB 1.1
4. disconnecting and connecting without shutting down the fuze gives me after the first time always USB 1.1
5. shutdown and turn the fuze on (reboot)
6. connect to the host -> USB 2.0
It also happend a very few times (aprox. 1 in 15 reboots) that I can connect and disconnect without rebooting the fuze and still getting USB 2.0 everytime.
On Linux I get consistent USB 2.0 High Speed connections.
Note that my Linux box has a USB PCI card inserted with USB 2.0 ports. The build-in controller is only 1.1.
On Linux I also get consistent high speed connections. I didn't check with window (nor XP nor Seven) but apparently Windows is screwing up with usb one more time.
What about USB HID mode?
but we did that already.
help
im new and im deprate to get this fixed
I have no idea if HID is working but I think during my last try it didn't work.
FS#11774for a possible fix.FS#11774was committed can this in-turn be committed (USB enabled in AMSv2) or does more testing need to be done? I have a FuzeV2 which I will use to test if neededNot ideal test conditions: I tested 2) on a machine properly, 20 insertion attempts, one failure. A handful (~25%?) of USB 1 negotiations.
Unfortunately after that the machine I was using died.
Since then I've used d) for a few weeks, no problems whatsoever across several computers. At least 20 attempts.
The patch appeared to build successfully, but when I plugged in my Clip+, it failed to mount (Ubuntu 10.10 is the host OS) and the disk access light stayed on. Eventually I took a chance and disconnected the Clip+, but the disk icon remained on, and it was stuck on the USB screen. I had to force a power off, and am now scanning with fsck.vfat for filesystem damage. (There was no microSD inserted.)
Also attached is my kernel log from the time of the testing.
With USB enabled by this patch on my ClipV2, I still have recurring apparent filesystem corruption that goes away when I replug or reboot the player without fixing the detected corruption.
The pattern of corruption exposed over USB (single-byte corruption with the values 0x7d, 0x7e, 0xfd, or 0xfe, always appearing after pairs of valid 0x7d,0x7e or 0xfd,0xfe bytes) seems to point into USB's general direction: My googling indicates that at least 0x7d,0x7e are used as escape bytes in some low-level part of USB signaling.
ETA: before
Just out of curiosity you could add:
if (usb_state == USB_EXTRACTED)
break;
to the beginning of the USB_TRANSFER_COMPLETION case in usb_thread() in usb.c, with 29154 in place of course.
just checking i put it in the right place??
#ifdef HAVE_USBSTACK
case USB_TRANSFER_COMPLETION:
if (usb_state == USB_EXTRACTED)
break;
usb_core_handle_transfer_completion(
(struct usb_transfer_completion_event_data*)ev.data);
break;
#endif /* HAVE_USBSTACK */
one thing i forgot to mention previously and it's just happened again after re-applying 29154 and that is it's resetting USB mode in the OF back to "auto detect" when it was on MSC previously.
I tried to check if the driver exit function is called from an improper place for sleeping calls and didn't find anything so far. :\
Doing the disconnect is required but a couple other things might be needed as far as powering off the OTG. One thing you didn't mention is, besides 29154, has anything changed as far as connect reliablilty because for me on the fuze it never fails anymore except when XP starts leaking resources after lots of connect cycles, which happens with everything.
@anyone who knows: From where does knowledge of the other bits come in PCGCCTL? Bit 0 is all I find in the 6400 docs.
One check: replace the sleep with udelay(1000000/20) which also works on fuze (sort of a klude fix if it works, but perhaps informative).
ETA: oh, and maybe post a copy of your setting config?
ETA: Something with using the wait-for-interrupt instruction at that particular time maybe. ???
Instead of sleep() or udelay() try:
long tick = current_tick + HZ/20;
while (TIME_BEFORE(current_tick, tick))
yield();
If that works still works well, it strongly indicates an issue with sleeping the CPU core at that particular moment (which indicates a problem in general). If it doesn't work, something else is going on.
*PANIC*
usb-drv: disconnect
i also saw this on another attempt
Undefined instruction at 3008D594
Where is 3008D594 in your build? Could you attach the .map for that one?
ETA: try r29205 as is - there was a serious problem of double init
i just tried r29205 and i got the little sound as if a usb device had been connected and an "installing drivers" notification. but then i got a windows dialog to say it had failed.
Feb 4 09:24:36 machine kernel: [97521.845204] sd 17:0:0:0: [sdb] Unhandled sense code
Feb 4 09:24:36 machine kernel: [97521.845209] sd 17:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 4 09:24:36 machine kernel: [97521.845213] sd 17:0:0:0: [sdb] Sense Key : Medium Error [current]
Feb 4 09:24:36 machine kernel: [97521.845218] sd 17:0:0:0: [sdb] Add. Sense: Unrecovered read error
Feb 4 09:24:36 machine kernel: [97521.845222] sd 17:0:0:0: [sdb] CDB: Read(10): 28 00 00 eb ef f8 00 00 01 00
Feb 4 09:24:36 machine kernel: [97521.845230] end_request: I/O error, dev sdb, sector 15462392
Feb 4 09:24:36 machine kernel: [97521.845234] Buffer I/O error on device sdb, logical block 1932799
And fsck.vfat says:
# fsck.vfat /dev/sdb
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Read 32 bytes at 7901134848:Input/output error
When I tried reenabling the USB hard-reset code in the workaround patch posted above (I've been successfully running without the hard-reset code for some time now), I also saw crashes similar Marc's.
All this does not occur with r29146 (or with the OF). I don't have time for a proper bisect at this moment, but will post my results when I do find the time.
I've noticed some weird depenedency between the FM and the USB. The FM register screen shows strange values while USB is connected even though radio is not enabled. The i2c code in tuner_init locks at boot as well if the cable is inserted.
BTW, wasn't that commit quite awhile ago in RB time? You hadn't updated?
It's made with the build in the build directory with the main binary, called rockbox.map.
However, not crashing might have brought it to sanity and is actually a step in the right direction.
I'm up for getting a v2 clip but I can't just buy it since I don't know what I'm getting and I already have v1. I could explore ideas in minutes or hours that otherwise take days or weeks of interrogation and testing.
Data abort
at 30049FD8
FSR 0x8
(domain 0, fault 8)
address 0xE59F38D4
i've attached the .map (hopefully). if you want the .map from any other build just give me a shout. (i'm assuming it changes on every update/modification???)
I doubt that V1 clips are still being sold. But if you want to increase the likelihood of getting a V2 Clip, you could go for the 4GB version. AFAIK there never was a 4GB ClipV1, and the 4GB version is only marginally more expensive than the 2GB one. Cheers!
example:
1) Fresh turn on in rockbox, connect usb cable to windows 7 machine -> usb 2.0 connection
2) disconnect usb cable
3) Reconnect usb cable -> usb 1.1 connection ('this device could perform faster' message from windows)
I have a fuze v2 running r29143 with this patch along with the
FS#11304(it has the 4 with a circle, denoting the speed i believe)
C08G Japan
0829p20519Y
SDC4/8GB 03
sorry for the two posts, I couldnt edit...
1)
FS#11304- as3514-audio-hq.diff2) http://www.rockbox.org/tracker/task/11870#comment39128 - test_sd.patch
3) http://www.rockbox.org/tracker/task/12001 - 0001-Enable-Rockbox-USB-for-ClipV2.patch
my device: fuzev2 AMSv2 Varient 0
I am on windows 7 x64, usb 2.0 works after unplugging/replugging (no usb 1.1 issues)
8gb microsd card (works at 'boot' of rockbox)
as far as i can tell everything works! hope this helps someone
r29644 with just the as3525v2-enable-usb.diff patch (changed properly to enable USB on fuze2) works like a charm.
I can plug and unplug and replug as much as I want without rebooting rockbox and no USB 1.1 issues.
Booting rockbox with a 8GB microsd card inserted and inserting, removing, reinserting it during USB mode also works without any issues as well.
As host I am running a 32bit Windows 7.
Also dfkt over at ABI states, that it doesn't work at all for him with r28830 for clip+.
I did the same compile for my Fuze V2 and there it works perfectly!
Out of interest, I also compiled it with the second patch (as3525v2-usb.diff), which caused the device to freeze whenever USB was plugged in.
Running latest SVN with no additional patches.
The Fuze still boots into the OF, however, when plugged in after poweroff (though I suspect this is a simple bootloader setting and unrelated to the issue).
To confirm, USB2.0 mounting and file transfers works 100% of the time on SVN head Sansa Fuze v2 on both Linux and Windows 7 (unpatched, besides the patch to enable the USB stack in the first place).
with as3525v2-enable-usb
- On Linux everything was fine
- On Win7the device was not recognized the very first time in Windows and the Fuze froze on the USB connected screen. All other times were OK. The only weird thing is that the SD card always shows up before internal memory (respectively drives E: and F:)
with as3525v2-usb
on both Linux and Win7 the Sansa crashes as soon as the USB cable is pugged in:
Data abort at 300051F24 FSR 0x8 (domain 0, fault 8) address 0x8B000034
1) plugging the Fuze will briefly show the USB plug on the screen then go back to what it was displaying before. At that point you cannot read/write from the device but it will charge over the USB. You need to restart the Fuze to be able to read/write files.
2) the Fuze freezes
Is there anything that can be done when those happens to give some feedback to fix it?
in the hope that it will fix all the problems, I tried to rewrite the driver use the slave (aka PIO) mode of the controller. Since this driver doesn't use DMA at all, all the suspicious corruption bugs should be fixed. I provide here a patch against the trunk which also enables HID because it works with my Clip+. All comments are welcome especially since this is more or less a complete rewrite.
Thanks for contributing the PIO-mode driver! This has great potential to get AMSv2 USB going. :)
I've been trying your patch on my Clip+ with two Linux hosts (with different kernel version), with mixed results. I get various read errors and resets. Sometimes, the host is unable to enumerate the USB devices. In three successive attempts to connect the Clip+ to the host (without rebooting in between), the HID worked two times, and the storage only one time. In each case, it took quite some time for the host to detect the USB devices.
(I've attached the Linux-kernel output from the three sessions.)
Another observation: On my Clip+'s display, Rockbox's USB-jack logo was shifted vertically into the yellow display area, presumably to make space for the USB-keypad mode line, which looked odd.
clip v2:
original "sansaclipv2.h" patch to enable usb on it's own does not work. adding the 2nd patch from the 1st post and this modification by MikeS works fine: http://www.rockbox.org/tracker/task/11664#comment38418
new pio patch does not work at all. device not recognised by windows 7.
clip+:
neither of the first 2 patches work. the 2nd patch corrupted some files and i had to run chkdsk to fix it.
new pio patch does not work at all. device not recognised by windows 7. tried multiple times with and without micro SDHC card.
(I took a shot at fixing it, but ultimately couldn't.)
Tested with a Fuze v2 with r29944, the only weird thing is that the MicroSD appears first instead of the internal memory
(Sorry for the english, it's not my native language)
http://www.head-fi.org/forum/thread/438447/sansa-fuze-and-rockbox/15#post_7639129
It works really well with the Fuze v2 and Windows 7 64bit. I can plug/unplug continuously without any problems.
The only issue I see is if the Fuze v2 is turned OFF when plugging into USB or into a charger, the Fuze turns on and goes into the official firmware. OH NO!
With the Fuze v1 turned off, when plugging into USB or a charging cord, the Fuze v1 turns on and goes into the Rockbox firmware correctly. If I forget to turn on the fuze before plugging it in, I get to sit through a very long database refresh and a bunch of files are made I don't want. Hopefully this last thing can eventually be fixed.
So, the PIO mode patch for USB is almost perfect - at least for Windows 7 64bit. Thank you for making this work amaury pouly and thanks to thegr8brain for the custom build. Is the PIO mode patch good enough yet to fold into the official builds?
Just not to see the [censored] OF and its [censored] auto folders ever again.
Pamaury, we all are extremely grateful for your countless efforts, you're the man, hats off.
My main machine is Ubuntu so I don't mind.
Seems to me the problem seems to be Windows host machines ?
earlier in the thread, MikeS posted this hack: http://www.rockbox.org/tracker/task/11664#comment38418 which i needed to get my clip v2 running. but now my clip+ won't run without this either which is making me think it's my pc that needs this fix and not the players. of course i'm speculating - i know nuffin. :D
I could have a try on fuzev2 but i am very lazy :)
If the fuzev2 OF init code is the same I can try on fuzev2 (I only have linux though)
@Marc: what? you still need that ridiculous hack on another device? very odd.
what surprised me most is how quick it is. my clip v2 always took anything between a few and 10 seconds or more to initialise but this is instantaneous. it works very well for me. i did have one failure after many successive connection attempts but using the "troubleshoot" option found under "devices and printers" on the windows 7 start menu resolved it by re-scanning for drivers.
which patches did you apply exacty? Which Patches are you referring to when talking about 1st and 2nd patch.. you meant the patches for pio and then pmu?
I ask because I'd like to see my clip+ running in USB mode too :)
when i get home later i can put up my complete diff if you want.
There was some talk on IRC that a bugfix was done in the USB driver that the AMSv2 USB driver is based on, let me check if this bugfix also applies to the AMSv2 USB driver.
- linux with and without sd inserted
- windows (xp and 7) with and without sd inserted
here's mine: all it consists of is the original patch from the opening post and this "kludge" as MikeS put it... http://www.rockbox.org/tracker/task/11664#comment38418
the patch also contains the code to enable the clip v2 as i own both.
However with Marcs diff on ubuntu all 3 are slow to connect and the clip zip has the most problems being the slowest to be read.
So it looks to me like the problem is in firmware/target/arm/as3525/usb-drv-as3525.c.
All tests conducted with Sansa Fuzev2, Clip+ 8gb and Clip Zip 8gb with 32gb Micro SD.
In Linux with Marcs patch, as soon as I connect the Clip+ to USB, the kernel starts spitting out this:
[1731019.646396] hub 2-1:1.0: unable to enumerate USB device on port 2
[1731019.885791] usb 2-1.2: new high speed USB device number 14 using ehci_hcd
continuously increasing the USB device number with or without 32gb sd card.
Added funmans 64byte buffer patch, but go the same result.
I seem like the USB stack is disconnection just to reconnect afterwards -
My Clip zip had some problems but after a few connects on a USB 1.1 port it seems to connect all the time now either on 1.1 or 2.0 usb ports. With or without SD Card.
The Clip+ is strange I can sometimes get it connected to XP, Everytime on Ubuntu. On XP tho when connection works it skips two drive letters i.e. Will Connect as H and M (J and K are taken) but it skips I and L to give the external sd card a letter. In this case L. Or sometimes External will get H and internal will get Maybe not related but thought I should mention it.
So I'm not sure which patches are in there. I even made svn-clean.
Hmmmm
(Fuze2 r31161 and just the as3525v2-enable-usb.diff patch changed properly to enable USB on fuze2)
As for the Clip+ and Clip Zip the hunt goes on.
On my laptop, my Fuze V2 is recognized successfully by Win7 x64, and drivers install fine (I tried this several times). However, neither the SD card nor the internal memory of the Fuze mount...at least, not for a few minutes. The old build of rockbox I was using (now 8 months old) worked fine. But I think there is something screwy with my machine, because my e280 v1, which has never had any problems connecting to USB, runs into the same 'wait a few minutes' situation. Accessing diskmgmt.msc or My Computer during time causes both of them to hang, both with the e280 and the Fuze.
Interestingly, when I hand-off the device to Lubuntu running in a VirtualBox VM, both the Fuze and the e280 are recognized instantly. I'm not really sure what to make of this or how to fix this very odd volume management issue, considering...
I don't get it though - I have clearly experienced a regression here, from 29xxx builds (at least on this one host, my laptop). Has that much really changed in the usb stack?