This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 125711 - sandisk cruzer 128mb usb key has problems with kernel-smp-2.4.21-15.EL
sandisk cruzer 128mb usb key has problems with kernel-smp-2.4.21-15.EL
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-10 10:08 EDT by Bret McMillan
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:24:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bret McMillan 2004-06-10 10:08:59 EDT
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
Storage devices
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)[25314]: session opened for user
root by bretm(uid=5216)
Jun  9 16:38:05 mrfurious kernel: hub.c: USB device not accepting new
address (error=-71)
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):
kernel-smp-2.4.21-15.EL

How reproducible:
Perfectly

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.
Comment 1 Pete Zaitcev 2004-07-29 15:09:13 EDT
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
level timeout.

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.
Comment 2 Pete Zaitcev 2004-07-29 15:15:37 EDT
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!
Comment 3 Bret McMillan 2004-07-29 15:53:14 EDT
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.
Comment 5 RHEL Product and Program Management 2007-10-19 15:24:19 EDT
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:
http://www.redhat.com/security/updates/errata/
 
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.

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