Bug 179191 - USB Flash disk not assigned a device name
Summary: USB Flash disk not assigned a device name
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-27 23:09 UTC by Scott Purcell
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-09-12 00:14:49 UTC

Attachments (Terms of Use)
lsusb output using -vv and -s parameters on the affected device (1.95 KB, text/plain)
2006-01-27 23:14 UTC, Scott Purcell
no flags Details

Description Scott Purcell 2006-01-27 23:09:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
When a specific USB key is inserted, it is seen but not fully initialized and not given a /dev/sdxx device name.

If I boot with the device inserted, I can run lsusb and get device information from the key, but fdisk -l does not show any /dev/sdx devices.

If I insert the device after boot, it loads the "SCSI emulation for USB Mass Storage Devices, but then I get a timeout messages from hal.hotplug and 
the entire USB subsystem has become non-responsive until reboot.

This device worked on FC2, RHEL4 (gold), and currently works on Linspire 5.0 and Windows XP.  I had previously seen the same behaviour on RHEL4 U1. This report deals with RHEL4 U2.

The specific key  is a Kingston DataTraveler2.0 that seems to be identifying itself to the USB bus as from Vendor 0x08ec "M-Systems Flash Disk Pioneers" with a Product ID of 0x0012.  It is a 512 MB device.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Insert the USB device.

Actual Results:  Described above more fully...
1) If inserted prior to boot, device is seen but not given a /dev/sdx device name and cannot be mounted, but does not interrupt operation fo other usb devices
2) if inserted after boot, causes a hal.hotplug timeout and causes the system to be non-responsive to other usb events.

Expected Results:  Device should have been given a device name of /dev/sda and /dev/sda1 should have been automatically mounted at /media/usb or some similar mountpoint.

Additional info:

I believe I remember seeing information about this in a previously reported bug for U1, but have been unable to find it.  My system is fully up to date.

Comment 1 Scott Purcell 2006-01-27 23:14:55 UTC
Created attachment 123811 [details]
lsusb output using -vv and -s parameters on the affected device

This is my output from 

lsusb -vv -s 001:004

Comment 2 Scott Purcell 2006-01-27 23:18:58 UTC
/var/log/messages output when the device (having been inserted before boot) was
removed and then reinserted:

Jan 27 17:06:32 localhost kernel: usb 1-6: USB disconnect, address 4
Jan 27 17:07:11 localhost kernel: usb 1-6: new high speed USB device using address 5
Jan 27 17:07:11 localhost kernel: scsi1 : SCSI emulation for USB Mass Storage
Jan 27 17:07:26 localhost hal.hotplug[4430]: timout(10000 ms) waiting for

Comment 3 Scott Purcell 2006-01-27 23:30:51 UTC
If I install and boot to the 2.6.9-5.EL kernel from RHEL4 Gold, the device works
as expected.

Comment 4 Scott Purcell 2006-01-30 19:42:06 UTC
I should note that I have seen the same behaviour with other Kingston Data
Travelers.  I suspect it is a problem with the identification of the vendor ID
or the device ID.

Comment 5 Scott Purcell 2006-02-03 17:05:11 UTC
Updating priority and severity because I'm uncomfortable being forced to run 
an out-of-date kernel just to have functionality with my USB device and 
because I can't see that this bug report has even been noticed in the past 
week.  If it needs to be downgraded again, I'm fine with that -- I'm just 
looking for some confirmation that it has been seen.

Comment 6 Pete Zaitcev 2006-03-29 19:47:17 UTC
Does the U3 work? Please verify that it fixes the problem and close the bug.
I have fixed regressions with 08ec/0012 devices, by bug 161613 and bug 160308.

Comment 7 Scott Purcell 2006-04-03 17:07:19 UTC
Yes, the 2.6.9-34.EL kernel does resolve the problem.  Thank you!

I've attempted to mark the bug as resolved by the current kernel version, but
apparently I do not have the appropriate Bugzilla privileges to do that.  It can
be closed as far as I am concerned, but I'm unable to do it myself.

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