Bug 532394 - sansa clip usb un-recognized; fails to mount
Summary: sansa clip usb un-recognized; fails to mount
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-02 03:02 UTC by abrouwers
Modified: 2009-12-08 16:33 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-12-08 16:33:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description abrouwers 2009-11-02 03:02:04 UTC
Description of problem:

I have a small mp3 player (sansa clip) which has excellent linux compatibility.  It works as a mass usb-storage device typically, for exchanging files, and even charging.

Upon plugging it in to a fedora 12 (beta, rawhide) installation, the kernel fails to place the device.  I think this is probably due to a devicekit (-disks?) item, as I've used the device on systems with only hal with much success (up to, and including, 2.6.32-rc kernels).

Upon plugging the device in, the event is certainly shown in my system log; tail'ing dmesg:


usb 2-2.4: new high speed USB device using ehci_hcd and address 4
hub 2-2:1.0: unable to enumerate USB device on port 4
usb 2-2.4: new high speed USB device using ehci_hcd and address 5
usb 2-2.4: New USB device found, idVendor=0781, idProduct=7432
usb 2-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-2.4: Product: SanDisk Sansa Clip
usb 2-2.4: Manufacturer: SanDisk
usb 2-2.4: SerialNumber: FDFEE90A4004B59F0000000000000000
usb 2-2.4: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device scan complete
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: device descriptor read/64, error -110
usb 2-2.4: device descriptor read/64, error -110
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: device descriptor read/64, error -110
usb 2-2.4: device descriptor read/64, error -110
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: device descriptor read/8, error -110
usb 2-2.4: device descriptor read/8, error -110
usb 2-2.4: reset high speed USB device using ehci_hcd and address 5
usb 2-2.4: device descriptor read/8, error -110

The mp3 player simply says "writing" on its small display, and locks up completely.  I have tested this with a hal system, and it gets assigned a device node and is passed along very successfully.  The window manager will then mount the device

My external USB harddrive (ext3 and vfat partitions) works as expected on the same configuration (including the same usb port on my laptop).

Let me know if there is any other information that might be helpful.  I have experimented on both a fresh fedora 12 beta, and a completely up-to-date rawhide with the same results.

Comment 1 David Zeuthen 2009-11-02 17:39:54 UTC
Doesn't even get to binding the usb-storage driver -> kernel (or hardware) problem. Reassigning.

Comment 2 abrouwers 2009-11-06 22:39:40 UTC
Sorry - my mistake.  I suppose you are right - it doesn't even get a device node assigned properly.

I have booted a Fedora 11 liveCD, and plugged the same mp3 player, into the same USB port on the same laptop (with the same cable :) , and it indeed detects and mounts the device automatically:

[liveuser@localhost ~]$ dmesg | tail
sd 6:0:0:0: [sdb] Mode Sense: 04 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] 1986048 512-byte hardware sectors: (1.01 GB/969 MiB)
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 04 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb:
sd 6:0:0:0: [sdb] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg2 type 0
SELinux: initialized (dev sdb, type vfat), uses genfs_contexts

At this point, the device mounts itself, and the display on the mp3 player appears normal, with "Connected," instead of the dead "writing" state with F12.

Comment 3 abrouwers 2009-11-13 02:44:12 UTC
I thought I'd also attach my current config; I've re-installed using RC4, and still notice this unique behavior.  For reference:

[andrew@thinkpad ~]$ rpm -qa | egrep 'usb|kernel' | grep -v xorg | sort
kernel-2.6.31.5-127.fc12.x86_64
kernel-firmware-2.6.31.5-127.fc12.noarch
libusb-0.1.12-22.fc12.x86_64
libusb1-1.0.3-1.fc12.x86_64
usbutils-0.86-2.fc12.x86_64

Is it possible that libusb1 is at fault?  Again, I've confirmed that the hardware works in 2 other distros (both pre libusb1, come to think of it) on the same hardware, so I am confident the issue is software related.

Comment 4 Bug Zapper 2009-11-16 14:51:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 abrouwers 2009-11-19 13:08:04 UTC
I've attempted to update to udev from testing-updates, and the mp3 player is still unrecognized upon hotplugging.  I've grabbed live media from the newest ubuntu and openSUSE (as my suspicions were of libusb1), and my player was recognized and auto-mounted in each, so I still think that it's kernel, or a difference in udev rules.

Comment 6 abrouwers 2009-12-05 18:36:42 UTC
I've since updated to 2.6.31.6 in fedora, with no luck.

This laptop also has a slackware64 installation; on my custom 2.6.32 kernel, completely vanilla, the mp3 player mounts perfectly with the same exact hardware/cable etc.:

scsi 3:0:0:0: Direct-Access     SanDisk  Sansa Clip 1GB   v01. PQ: 0 ANSI: 0
usb-storage: device scan complete
sd 3:0:0:0: [sdb] 1986048 512-byte logical blocks: (1.01 GB/969 MiB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 04 00 00 00
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sd 3:0:0:0: [sdb] Assuming drive cache: write through
 sdb:
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sd 3:0:0:0: [sdb] Attached SCSI removable disk

This is completely specific to fedora's kernel, and not related at all to the hardware.

Comment 7 Pete Zaitcev 2009-12-08 04:53:00 UTC
Awesome, thanks for excluding the hardware with the help of the other kernel!
May I get the usbmon traces from both 2.6.32 and 2.6.31.6?
Comparing the two is bound to show us clearly what is afoot.

I think it would be easiest to rebuild usbmon userland from source,
available from my webpage. I am certain Slackware doesn't ship it.
This way you don't need to tinker with debugfs and other painful
stuff from ./Documentation/usb/usbmon.txt.
 http://people.redhat.com/zaitcev/linux/usbmon-5.4.tar.gz

Comment 8 abrouwers 2009-12-08 12:59:16 UTC
Hello Pete,

Thanks for your comment.  Unfortunately, after about a month and a half of waiting, I've removed my Fedora installation.  I grew tired of rebooting liveCD's just to charge the MP3 player.  This bug should be closed, as I won't be able to provide any more information.

Thanks anyway.


Note You need to log in before you can comment on or make changes to this bug.