Bug 179191 - USB Flash disk not assigned a device name
USB Flash disk not assigned a device name
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-01-27 18:09 EST by Scott Purcell
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.9-34.EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-11 20:14:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Scott Purcell 2006-01-27 18:09:46 EST
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 18:14:55 EST
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 18:18:58 EST
/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 18:30:51 EST
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 14:42:06 EST
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 12:05:11 EST
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 14:47:17 EST
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 13:07:19 EDT
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.