Description of problem:
USB key gives error in var log messages when I try to run:
devlabel add -d /dev/sda1 -s /dev/usbkey --automount
Here's the relevant log from /var/log/messages:
Jun 9 16:37:01 mrfurious kernel: hub.c: new USB device 00:1d.7-5,
assigned address 9
Jun 9 16:37:01 mrfurious kernel: usb.c: USB device 9 (vend/prod
0x781/0x8181) is not claimed by any active driver.
Jun 9 16:37:04 mrfurious /etc/hotplug/usb.agent: Setup usb-storage
for USB product 781/8181/122
Jun 9 16:37:04 mrfurious kernel: Initializing USB Mass Storage driver...
Jun 9 16:37:04 mrfurious kernel: usb.c: registered new driver usb-storage
Jun 9 16:37:04 mrfurious kernel: scsi1 : SCSI emulation for USB Mass
Jun 9 16:37:04 mrfurious kernel: Vendor: Generic Model: STORAGE
DEVICE Rev: 1.22
Jun 9 16:37:04 mrfurious kernel: Type: Direct-Access
ANSI SCSI revision: 02
Jun 9 16:37:04 mrfurious kernel: Attached scsi removable disk sda at
scsi1, channel 0, id 0, lun 0
Jun 9 16:37:04 mrfurious kernel: SCSI device sda: 256000 512-byte
hdwr sectors (131 MB)
Jun 9 16:37:04 mrfurious kernel: sda: Write Protect is off
Jun 9 16:37:04 mrfurious kernel: sda: sda1
Jun 9 16:37:04 mrfurious kernel: USB Mass Storage support registered.
Jun 9 16:37:15 mrfurious su(pam_unix): session opened for user
root by bretm(uid=5216)
Jun 9 16:38:05 mrfurious kernel: hub.c: USB device not accepting new
Jun 9 16:38:10 mrfurious kernel: scsi: device set offline - not ready
or command retry failed after bus reset: host 1 channel 0 id 0 lun 0
Jun 9 16:38:10 mrfurious kernel: sda: I/O error: dev 08:00, sector 0
Jun 9 16:38:10 mrfurious kernel: I/O error: dev 08:00, sector 0
Jun 9 16:38:10 mrfurious kernel: unable to read partition table
Jun 9 16:38:10 mrfurious devlabel: devlabel service started/restarted
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make sure usb-storage is not loaded
2. Plug in usb key, watch message log as it gets linked to sda1
3. Try to use the devlabel command above while watching the message log
Once usb-storage is loaded, if you remove and reattach the usb key,
you get the following lines in the message log:
Jun 10 10:05:53 mrfurious kernel: hub.c: new USB device 00:1d.7-5,
assigned address 10
Jun 10 10:05:56 mrfurious /etc/hotplug/usb.agent: Setup usb-storage
for USB product 781/8181/122
Jun 10 10:05:57 mrfurious devlabel: devlabel service started/restarted
The only thing strange w/ this box is that it's running nvidia binary
xfree drivers. Not sure if that's relevant though. The machine is
just a Dell Precision 450, dual 2.6 p4 box.
Let me know if there is any more info I can provide.
Investigation note - no action required -
The message "not accepting new address" is produced by
usb_reset_device, which is called by scsiglue.c:bus_reset().
The error -71 is -EPROTO, which means a timeout for a
control command as detected by HC hardware, not a higher
The error processing in SCSI proceeds by doing task management
abort, device reset, bus reset. If bus reset fails, there is
nothing that can be done and the SCSI device is taken offline
(in case of USB it is. Some HBAs implement full hardware resets).
So, the device encounters an error of some kind (maybe bad
flash block), but attempts to reset it fail.
Brent, I have 3 requests.
Please try 2.4.21-17.EL with this thing. It implements
Dell's ->exclusive_access semaphore to interlock devlabel
and block access. I'm curious if that helps.
Please attach /proc/bus/usb/devices.
Please try the device on an RHEL box with the same kernel
but without nVidia stuff.
I saw some very wild things happening to USB when nVidia drivers
were loaded, strangely enough... So there's a reason to disqualify
you from the support, but I wish to investigate this anyway.
Maybe the HC cannot get PCI access fast enough and chokes when
nVidia hardware does a DMA somewhere? Getting -EPROTO is really
a unique achievement!
I'll toss -17.EL on if you can tell me the appropriate place to find
it, and I'll remove the nvidia stuff to eliminate it as a variable.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.