Red Hat Bugzilla – Bug 160308
USB Key stops working after upgrade to U1
Last modified: 2007-11-30 17:07:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4
Description of problem:
I've got a KINGSTON USB memory stick which I just plug into my machine and automatically an entry is created in /etc/fstab. This worked fine with RHEL 3 (with different updates) and also worked properly with RHEL 4. However after having upgraded to U1 this weekend, the kernel no longer configures the USB memory stick any more. When I boot with the previous kernel (i.e. kernel-2.6.9-5.0.5.EL) the stick gets configured properly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. But kernel-2.6.9-11.EL
2. Plug in memory stick
Actual Results: Kernel sees stick but fails to configure it.
Expected Results: Kernel detects memory stick and configures it as previously.
The machine is a Dell Dimension 4550.
Created attachment 115396 [details]
Output in /var/log/messages with kernel-2.6.9-11
Created attachment 115397 [details]
Output of /var/log/messages with kernel 2.6.9-5.0.5
Created attachment 115398 [details]
Output of lsusb -v with kernel-2.6.9-5.0.5
Created attachment 115399 [details]
Output of lspci -v
This is a regression, clearly. Thanks for letting me know.
I would like to see complete dmesg outputs for the two kernels involved,
taken with the key attached.
BTW, I cannot call this device a "memory stick", because Memory Stick(r)
is a trademark of Sony, and in any case it means entirely different technology
that has nothing to do with USB. "USB key" is a common term.
Also, I need /proc/bus/usb/devices, but one would be enough - they should
be the same on both kernels.
Created attachment 115417 [details]
dmesg output of kernel -11.
I've waited for the machine to boot up completely (i.e. enter runlevel 5) then
inserted the USB key. Waited for about 20 seconds than ran dmesg.
Created attachment 115418 [details]
dmesg output of kernel -5.0.5
Same procedure as with -11 kernel.
Created attachment 115419 [details]
/proc/bus/usb/devices of -11 kernel
exactly the same problem for me (ok with the old kernel, notok for the new, same
logs than Dirk)
Me too, for my Kingston DataTraveler2.0, but the TwinMOS MOBILE Disk seems to
It appears that Kingston offers no less than 4 generations of USB keys.
Here's the list of 512MB units (Dirk has 512MB):
#1: http://www.cdw.com/shop/products/default.aspx?EDC=675052 KUSBDTI/512
#2: http://www.cdw.com/shop/products/default.aspx?EDC=765338 KUSBDTII/512
#3: http://www.cdw.com/shop/products/default.aspx?EDC=704095 KUSBDTII+/512
The 4th gen either has no 512MB, or CDW doesn't carry it, so the 1GB unit:
#4: http://www.cdw.com/shop/products/default.aspx?EDC=702843 KUSBDTE/1GB
I had a case when Warren sent me a key which failed for him but worked
just fine here, so I don't want any risks.
Guys, please read the signage off the bottom of your keys and post it here.
A readable digital picture would work too.
Created attachment 116459 [details]
Picture1 of USB Key
Created attachment 116460 [details]
Picture 2 of USB Key
None of the four links showed the USB key I'm using. The key is not a current
model. It was purchased on 2004-07-12. There's a barely readable signage at the
side of the key which reads: 4083G9008014R233A1.
I plugged the key in the meantime in three other machines which are running RHEL
4 (two with an USB 1.1 bus, one with an USB 2.0 capable bus). It worked in none
I've also tested with a KINGSTON DataTraveler II+ and this key worked fine.
Surely you mean "plugged into ... running RHEL 4 U1", because you wrote that
RHEL 4 GA worked in the original report?
Yes, sorry. All machines were running RHEL 4 U1.
Ok, so mine (I have two) look like the one on the right at this url:
ie they look just like the ones in picture 1 and picture 2 of the attachment to
They are both 256MB and have this id on the side:
and they both fail in the same way.
usb 1-2: new full speed USB device using address 2
SCSI subsystem initialized
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
but no device sda1 appears with the -11 kernel.
Thanks for the info. Since we have a failing case of 256MB, I'll go with this:
Fujifilm 256Mb, same issue with U1:
I dont know how related this is but I have a Transcend JetFlash 128MB MP3 player
which used to work fine as a USB memory stick. Now, when I try to mount it I get
the message "special device /dev/sda1 does not exist". The "dmesg" command shows
usb 7-2: new full speed USB device using address 14
usb-storage: probe of 7-2:1.0 failed with error -1
(the address increments by 1 with each plugging in of the device). I have the
following running when I do an "lsmod":
I am running kernel 2.6.9-11.ELsmp
a bit of a shot in the dark, but the U2 beta has *a lot* of fixes, and might be
worth trying: http://people.redhat.com/~jbaron/rhel4/. .thanks.
Thanks for the info. However the new kernel does not seem to fix this problem -
at least for me. The USB key is still not being recognized properly. The
messages in /var/log/messages seem to be the old ones (i.e. USB device detected,
mass storage driver loaded, reset after some time).
No surprise here, sorry to say. I aimed for U2 with the fix, but the key
I acquired from CDW does NOT reproduce the problem. While I thought what
to do about this, development window for U2 closed.
We rebuilt an FC 4 kernel (2.6.12-1.1398) and my Kingston Data Travellers work
fine with that whereas they fail with the EL4 -11 kernel. This is actually on
Scientific Linux 4.1.
Pete: If it would help I could loan you one of my Data Travellers thats shows
Created attachment 120592 [details]
Candidate #1 - only clear halt after an error
It seems that no matter what we do, there's no way to make sure a device
won't fail if we clear toggles unconditionally. Exclusion lists get
unmanageable very quickly. So, the only soluion appears to be reactive,
not proactive, and clear halts upon an error only.
This fix causes a regression for TEAC CD-224 (NOT the infamous CD-210).
See bug 175188. We may need to bump this into U4.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.