Bug 241510 - lsusb causes USB "jump drive" (RAM disk) to lose connection / become inaccessible
lsusb causes USB "jump drive" (RAM disk) to lose connection / become inaccess...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pciutils (Show other bugs)
6
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
Ben Levenson
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-26 23:43 EDT by Larry Morley
Modified: 2008-05-06 15:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 15:37:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Larry Morley 2007-05-26 23:43:36 EDT
Description of problem:

lsusb (or lsusb -v, etc.) causes USB "jump drive" (aka "pen drive", "thumb
drive" etc.) to become inaccessible: contents of volume can no longer be
obtained via "ls", nautilus, or other means; individual files can no longer be
read from or written to; etc.

The drive will usually show up in subsequent "lsusb" invocations, but not in
subsequent invocations of "lsusb -v".  Either way, the device and its contents
are inaccessible.

The mtab entry for the device + mount point combination remains in mtab even
after connectivity to the device is lost; umount does not report an error, and
umount does remove the mtab entry for the device / mount point combination.

Version-Release number of selected component (if applicable):

O/S version is Fedora Core 6; pciutils version is as shown:

$ rpm -q --whatprovides /sbin/lspci
pciutils-2.1.99.test8-10

How reproducible:

Mount jump drive from command line; then, invoke lsusb from command line.

Steps to Reproduce:
1. mount /dev/sdc4 /media/thumbdrive
2. if ( { ls /media/thumbdrive/* ; } ; ) ; then
      # everything is working correctly at this point
      ...
   fi
3. lsusb (or lsusb -v)

4. if ( { ls /media/thumbdrive/* ; } ; ) ; then ...

   "ls: /media/thumbdrive/*: No such file or directory"

Actual results:
(see above)

Expected results:
(see above)

Additional info:

lsusb shows device as:

Bus 002 Device 007: ID 0d7d:1600 Phison Electronics Corp.

From /var/log/messages:

kernel: usb 2-5: new high speed USB device using ehci_hcd and address 7
kernel: usb 2-5: configuration #1 chosen from 1 choice
kernel: scsi6 : SCSI emulation for USB Mass Storage devices
kernel: scsi 6:0:0:0: Direct-Access              USB DISK 2.0     PMAP PQ: 0
ANSI: 0 CCS
kernel: SCSI device sdd: 246272 512-byte hdwr sectors (126 MB)
kernel: sdd: Write Protect is off
kernel: sdd: assuming drive cache: write through
kernel: SCSI device sdd: 246272 512-byte hdwr sectors (126 MB)
kernel: sdd: Write Protect is off
kernel: sdd: assuming drive cache: write through
kernel: sdd: sdd4
kernel: sd 6:0:0:0: Attached scsi removable disk sdd
kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

Note that, according to /sys/bus/usb/devices/... and /sys/bus/scsi/devices/
(etc), the device is still present and running.  The transition from working to
non-working appears in /varlog/mesages as follows:

kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
kernel: scsi 5:0:0:0: rejecting I/O to dead device
kernel: FAT: Directory bread(block 241) failed
kernel: scsi 5:0:0:0: rejecting I/O to dead device
zeus kernel: FAT: Directory bread(block 242) failed

No specific error message(s) or indication that drive went offline appears in
/var/log/messages or in dmesg; the drive simply becomes inaccessible:

sd 6:0:0:0: Attached scsi removable disk sdd
sd 6:0:0:0: Attached scsi generic sg2 type 0
usb-storage: device scan complete
scsi 5:0:0:0: rejecting I/O to dead device
Comment 1 Bug Zapper 2008-04-04 03:18:02 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 2 Bug Zapper 2008-05-06 15:37:51 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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