Rockbox

Tasklist

FS#10666 - Rockbox software USB doesn't connect with OS X 10.4

Attached to Project: Rockbox
Opened by Dave Chapman (linuxstb) - Friday, 09 October 2009, 17:38 GMT
Last edited by Tomer Shalev (tomers) - Friday, 23 October 2009, 13:48 GMT
Task Type Bugs
Category Drivers
Status Closed
Assigned To No-one
Operating System PortalPlayer-based
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

[NOTE: I haven't experienced this bug myself, I'm just adding a task to collect info about it]

It has been confirmed that HID mode (fully enabled in 3.4, but also present in 3.3, so this affects both of those releases) causes OS X 10.4 to fail to mount a PP Sansa when in Rockbox USB mode.

Building a version of Rockbox without HID support is known to fix the problem.

Some examples from a OS X 10.4 syslog experiencing this problem:

USBF: 6214.718 AppleUSBEHCI[0x2724800]::Found a transaction past the completion deadline on bus 75, timing out!
USBF: 6225.728 AppleUSBEHCI[0x2724800]::DoIOTransfer - error 0xe000404f queueing request
Closed by  Tomer Shalev (tomers)
Friday, 23 October 2009, 13:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  FS #10704 adds an option to disable USB HID. Doing so will enumerate the DAP as a regular (non composite) USB device, therefore avoid this OS bug. A documentation note advising to disable USB HID if this bug occurs has been added to the manual (would appreciate if someone review it).
Comment by Frank Gevaerts (fg) - Friday, 09 October 2009, 17:50 GMT
The attached patch makes it possible to easily build a version without HID during MSC connections, while keeping HID during charge-only connections.

Apply, and build with -DNO_MSC_HID

This shouls also provide hints on where to add a setting for this :)
Comment by Frank Gevaerts (fg) - Friday, 09 October 2009, 18:05 GMT
A more correct patch
Comment by Tomer Shalev (tomers) - Tuesday, 13 October 2009, 06:22 GMT
I compared two logs given by developers, and got to some conclusions.

Source: http://www.rockbox.org/irc/log-20091010#13:42:24, and I can't find the origin of the other one).

USB Product ID 0x7421 belongs to e200
USB Product ID 0x7451 belongs to c200

And reading the reference at:
www.usb.org/developers/devclass_docs/HID1_11.pdf
HID1_11.pdf, E.2 Configuration Descriptor, page 77

I can see that the Configuration Descriptor is different. The e200 (0x7421) has the wTotalLength swapped, i.e. 0x3900 instead of 0x0039, although actually 0x0039 bytes are sent, which is the actual descriptor length.
I think this is the problem. The question is why does the DAP sends this wrong value? Maybe it's an issue in the host itself?

Comment by Tomer Shalev (tomers) - Tuesday, 13 October 2009, 19:51 GMT
OS X 10.4 users - please try whether r23157 fix this issue
Comment by Kaspar Rothenfusser (k-man666) - Saturday, 17 October 2009, 00:36 GMT
I have the same problem using Ubuntu Linux 9.04 (Jaunty) fully patched. Sansa is reognized and works as HID device, but not as mass storage.
Comment by Frank Gevaerts (fg) - Sunday, 18 October 2009, 12:13 GMT
Kaspar: different issue, that's an ubuntu bug. See http://www.rockbox.org/wiki/LibGphoto2Bug
Comment by Rob Frohne (frohro) - Tuesday, 20 October 2009, 01:19 GMT
Hi,
I am an OS X 10.4 user who is affected by this bug, and I tried the latest build (r23284-091020) and it didn't fix this problem.

I get some error messages in the syslog. I'll post them here in a minute.

Rob
Comment by Rob Frohne (frohro) - Tuesday, 20 October 2009, 01:21 GMT
Here are the syslog messages:

Oct 19 18:19:25 frohro-g5 kernel[0]: USBF: 1050980.406 AppleUSBEHCI[0x257e800]::DoIOTransfer - error 0xe000404f queueing request
Oct 19 18:19:36 frohro-g5 kernel[0]: USBF: 1050991.396 AppleUSBEHCI[0x257e800]::Found a transaction past the completion deadline on bus 75, timing out!
Oct 19 18:19:48 frohro-g5 kernel[0]: USBF: 1051003.397 AppleUSBEHCI[0x257e800]::Found a transaction past the completion deadline on bus 75, timing out!

with a bunch more timeouts.

Thanks for working on this.

Rob

Loading...