I’m having problems with low transfer rates (maximum 1 MB/sec) to my FUZE unit under Linux, mass-storage mode. Looking at the output from /var/log/messages it seems that the unit is unable to use the USB 2.0 hub and uses a USB 1.1 hub instead:
[log]
Jan 20 09:50:41 barbara kernel: usb 5-4: new high speed USB device using ehci_hcd and address 4
Jan 20 09:50:44 barbara kernel: ehci_hcd 0000:00:1d.7: port 4 reset error -110
Jan 20 09:50:44 barbara kernel: hub 5-0:1.0: hub_port_status failed (err = -32)
Jan 20 09:50:44 barbara kernel: hub 5-0:1.0: unable to enumerate USB device on port 4
Jan 20 09:50:44 barbara kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2
Jan 20 09:50:44 barbara kernel: usb 2-2: not running at top speed; connect to a high speed hub
Jan 20 09:50:44 barbara kernel: usb 2-2: configuration #1 chosen from 1 choice
Jan 20 09:50:44 barbara kernel: usb 2-2: New USB device found, idVendor=0781, idProduct=74c1
Jan 20 09:50:44 barbara kernel: usb 2-2: New USB device strings: Mfr=6, Product=7, SerialNumber=8
Jan 20 09:50:44 barbara kernel: usb 2-2: Product: SanDisk Sansa Fuze
Jan 20 09:50:44 barbara kernel: usb 2-2: Manufacturer: SanDisk
Jan 20 09:50:44 barbara kernel: usb 2-2: SerialNumber: D010D2171226B5940000000000000000
Jan 20 09:50:45 barbara kernel: Initializing USB Mass Storage driver…
Jan 20 09:50:45 barbara kernel: scsi6 : SCSI emulation for USB Mass Storage devices
Jan 20 09:50:45 barbara kernel: usbcore: registered new interface driver usb-storage
Jan 20 09:50:45 barbara kernel: USB Mass Storage support registered.
Jan 20 09:50:45 barbara kernel: usb-storage: device found at 2
Jan 20 09:50:45 barbara kernel: usb-storage: waiting for device to settle before scanning
Jan 20 09:50:46 barbara kernel: scsi 6:0:0:0: Direct-Access SanDisk Sansa Fuze 2GB v01. PQ: 0 ANSI: 0
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] 3951616 512-byte hardware sectors: (2.02GB/1.88GiB)
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Write Protect is off
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Mode Sense: 04 00 00 00
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] 3951616 512-byte hardware sectors: (2.02GB/1.88GiB)
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Write Protect is off
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Mode Sense: 04 00 00 00
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Assuming drive cache: write through
Jan 20 09:50:46 barbara kernel: sdb:
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: [sdb] Attached SCSI removable disk
Jan 20 09:50:46 barbara kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
Jan 20 09:50:46 barbara kernel: scsi 6:0:0:1: Direct-Access SanDisk Sansa Fuze 2GB v01. PQ: 0 ANSI: 0
Jan 20 09:50:46 barbara kernel: sd 6:0:0:1: [sdc] Attached SCSI removable disk
Jan 20 09:50:46 barbara kernel: sd 6:0:0:1: Attached scsi generic sg3 type 0
Jan 20 09:50:46 barbara kernel: usb-storage: device scan complete
[/log]
The output from the lsusb command confirms that the unit ended up on a 1.1 hub:
[lsusb]
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0781:74c1 SanDisk Corp.
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 046d:c019 Logitech, Inc. Optical Tilt Wheel Mouse
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[/lsusb]
This happens both on my laptop and my stationary computer, running different flavors of Linux (OpenSUSE, Ubuntu and Fedora). I have other USB devices that do use the 2.0 bus without problems.
I have found out that I can get my Fuze to connect to the 2.0 hub following these steps:
Connect the Fuze to a USB port.
Unload the ehci_hcd module: “modprobe -r ehci_hcd”
Reload the ehci_hcd module: "modprobe ehci_hcd
The Fuze will now connect to the 2.0 hub. Of course, this is not a viable solution since it is complex and will disconnect and reconnect all other physically connected USB units.
Sorry - meant to see what mine did last night, but I forgot & played x3tc instead.
I wanted to try beacuse I seem to remember something similar happening when I plugged directly into the back of my PC via a long cheap & nasty extender cable. I put it down to the long cable run and plugged into a powered 2.0 hub on my desk, and as everthing worked, I left my Sansa cable there and never went back and investigated. Maybe it wasn’t due to the cable…
Is the Fuze in MTP, MSC or Auto mode, and does changing it make any difference? The Sansa players do a bit of Windoze-style probing protocol before deciding how to connect in both Auto & MTP modes (don’t know about MSC). Maybe it’s worth trying different modes? Or a hub?
Message Edited by daytona955 on 01-21-2009 04:24 AM
Is the Fuze in MTP, MSC or Auto mode, and does changing it make any difference? The Sansa players do a bit of Windoze-style probing protocol before deciding how to connect in both Auto & MTP modes (don’t know about MSC). Maybe it’s worth trying different modes? Or a hub?
The mode doesn’t matter. As for connecting via a hub, it works when I connect to my desktop machine via the hub in the monitor. But I’m not very keen on buying a hub for my laptop.
My Ubuntu 8.10 box does indeed show the same symptoms - connects as a USB 1.1 device with consequently slow throughput - when the Fuze is directly connected.
I happened to be out recording some stuff at church last night, and the recording PC has 8.04 installed - and guess what - my Fuze connects fine on it.
So later, I booted my 8.10 box from an 8.04 ‘live’ CD, and the Fuze connects as USB 2.0 - on the same physical port that connects it as 1.1 with 8.10.
So this is an OS problem, not a Fuze problem as such.
I guess it maybe a libusb problem since you are seeing the same issue with several distros. The libusb versions reported by apt are:
8.04 - 2:0.1.12-8
8.10 - 2:0.1.12-12
According to the libusb SF site v1.12 is now a legacy version. I guess if you want it fixing, it needs raising with either Ubuntu or libusb.
Maybye I’ll get a Jaunty 9.04alpha live boot CD and see what libusb version they are using on that, and whether it has the problem.
Thanks, daytona955, for your reasearch! I have filed a bug with OpenSUSE (which is the distro I use most). I just wish some developer at SanDisk would take a look at this, too.
I’m not sure it’s the same bug. That bug seems to be that USB 2.0 doesn’t work at all, which they can work around by unloading the ehci_hcd module. As far as I can tell, this problem affects the Fuze only while all other USB 2.0 devices function correctly, and I don’t have to unload any modules to get it working at all.
I found another work-around: With the device connected, hibernate and restart the computer. After hibernation, the device will be reassigned to the 2.0 bus.
Not very convenient, but it indicates that the problem lies in the hand-shake on device plugin.
I don’t get the same good result in Kubuntu live CD 9.04alpha3: the uhci_hcd and the ehci_hcd modules seem to compete over the device, and uhci_hcd (the lower-speed handler) wins:
[log output]
Jan 25 09:56:18 ubuntu kernel: [ 274.840014] usb 4-2: new high speed USB device using ehci_hcd and address 6
Jan 25 09:56:21 ubuntu kernel: [ 278.184011] usb 5-2: new full speed USB device using uhci_hcd and address 2
Jan 25 09:56:21 ubuntu kernel: [ 278.330000] usb 5-2: not running at top speed; connect to a high speed hub
[/log output]
This is confirmed by lsusb:
[lsusb]
Bus 004 Device 005: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse
Bus 004 Device 004: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 004 Device 002: ID 15a9:0004
Bus 004 Device 003: ID 0bda:0111 Realtek Semiconductor Corp. Card Reader
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 003: ID 0781:74c1 SanDisk Corp.
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[/lsusb]
I actually got an openSUSE developer to work on it for a while, but we didn’t get anywhere. Since he didn’t have a FUZE to test on I had to do the debugging, which was very awkward. And then I think he got more pressing things to do.
I finally bought a USB switch to work around the problem.
I never had this problem on my Debian Lenny system. But this is not as new as other Linux systems with respect to kernel, hal, udev, libmtp libraries. I might step into the same mud on future upgrades so I tried to fiddle around a bit using the Ubuntu 9.04 “Jaunty” live CD.
And to my surprise everything I tried so far did work: my Fuze got USB 2.0 high speed connection
using front USB
using back USB
using a powered USB hub
Obviousely the newer software components are more susceptible to certain hardware constellations. For what I read so far it seems pretty tough to narrow things down. Nevertheless I’ll keep an eye on the issue …
In troubleshooting an unrelated issue with ext4, I discovered that using the most recent 2.6.29 generic kernel from the ubuntu mainstream kernel repo, this issue is fixed. So, the issue lies either in some of the Ubuntu patches (somehow I doubt, considering that other distros have this issue), or in the 2.6.28 and earlier kernels across the board.
If you don’t need any of the ubuntu proprietary driver patches on your computer, then this might be a good option to upgrade to 2.6.29. Presumably (and hopefully) this will remain fixed when/if jaunty puts out its own flavor of the 2.6.29 kernel in the repos.
Others encountering this error – can you confirm this fix?
Message Edited by sdrawkcab on 05-21-2009 01:30 PM
