Bug 179191

Summary: USB Flash disk not assigned a device name
Product: Red Hat Enterprise Linux 4 Reporter: Scott Purcell <scott_purcell>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: jbaron
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 2.6.9-34.EL Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-12 00:14:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lsusb output using -vv and -s parameters on the affected device none

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):
usbutils-0.11-6.1

How reproducible:
Always

Steps to Reproduce:
1. Insert the USB device.
2.
3.
  

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
devices
Jan 27 17:07:26 localhost hal.hotplug[4430]: timout(10000 ms) waiting for
/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0
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.