Bug 249136 - Deep Directory structure on USB Hard Drive Causes device descriptor error messages
Deep Directory structure on USB Hard Drive Causes device descriptor error mes...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
7
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-21 07:19 EDT by Greg Morgan
Modified: 2008-06-16 21:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:55:57 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 Greg Morgan 2007-07-21 07:19:14 EDT
Description of problem:

Here's a for what it's worth informational bug report.  I have a seagate 160 gig
drive in an external usb enclosure.  I realized that I had borked the formating
of the drive when Solaris 10 would not mount the drive but MS Windows
Professional 2000, Fedora 5 and Fedora 7 would mount the drive with no problem.
(Sadly I can only use Solaris 10 at work, if I want a stable development
platform.  We bought AMD boxes in the hopes of someday using Linux but I
digress. :-( )

fdisk -l reports
...
Disk /dev/sde: 160.0 GB, 160041885184 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1   *           1       19457   156288321    6  FAT16

I was coping the files of the drive so that I could reformat it with a FAT32 ID.

The copy worked find but would fail part way through.  I thought heat would was
a factor and tried again.  The copied failed again.  This time I tried coping
files from the failed point onward.  However, I started at the very last
directory and worked backward.  These worked ok.  So I got brave and launched
the rest of directory copies.  I then went of the the Harry Potter book release
thing with the kids.  Sure enough the copy failed again.  Well two hours waiting
in line allowed heat to be factored out of the equation.  I copied individual
directories again until I got to the last directory where the copy failed.  The
other directories where light copies and the USB enclosure has a fan blowing
over the drive.  The room air is cool.

The copy command was in the form of 
yes | cp -pR  ISDocs20060525/AppDevlTools/OracleODBC /160bk/AppDevlTools

When the copy command came to an exe file and I believe finished the copy an
error message for the next file say: 
cp: overwrite `/160bk/AppDevlTools/OracleODBC/odbcIntoOracle.doc'?
cp: overwrite `/160bk/AppDevlTools/OracleODBC/omwb_92012.exe'? 
cp: cannot stat `ISDocs20060525/AppDevlTools/OracleODBC/Oracle Migration Kit
User\'s Guide -- Contents.htm': No such file or directory

The 'cannont stat' and 'No such file or directory error messages' are from the
/media/disk-1/ source directory being unmounted.

/var/log/messages shows
Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd
and address 26
Jul 21 02:13:03 mowgli kernel: usb 5-4: device descriptor read/64, error -71
Jul 21 02:13:03 mowgli kernel: usb 5-4: device descriptor read/64, error -71
Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd
and address 27
Jul 21 02:13:03 mowgli kernel: usb 5-4: device not accepting address 27, error -71
Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd
and address 28
Jul 21 02:13:04 mowgli kernel: usb 5-4: device not accepting address 28, error -71
Jul 21 02:13:34 mowgli kernel: scsi 8:0:0:0: rejecting I/O to dead device
Jul 21 02:13:34 mowgli kernel: FAT: unable to read inode block for updating
(i_pos 792171667)
Jul 21 02:40:24 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd
and address 29
Jul 21 02:40:24 mowgli kernel: usb 5-4: configuration #1 chosen from 1 choice
Jul 21 02:40:24 mowgli kernel: scsi9 : SCSI emulation for USB Mass Storage devices
Jul 21 02:40:24 mowgli kernel: scsi 4:0:0:0: rejecting I/O to dead device
Jul 21 02:40:24 mowgli kernel: scsi 4:0:0:0: rejecting I/O to dead device
...
Jul 21 03:00:30 mowgli kernel: FAT: Directory bread(block 152615) failed
Jul 21 03:02:48 mowgli kernel: usb 5-4: USB disconnect, address 29

A power off and a power on of the Ultra USB enclosure automounts the disk to
/media/disk-1

After the drive is automounted I the following in /var/log/messages

Jul 21 03:02:48 mowgli kernel: usb 5-4: USB disconnect, address 29
Jul 21 03:02:48 mowgli hald[2443]: forcibly attempting to lazy unmount /dev/sde1
as enclosing drive was disconnected
Jul 21 03:02:48 mowgli hald: unmounted /dev/sde1 from '/media/disk-1' on behalf
of uid 0
Jul 21 03:02:53 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd
and address 30
Jul 21 03:02:54 mowgli kernel: usb 5-4: configuration #1 chosen from 1 choice
Jul 21 03:02:54 mowgli kernel: scsi10 : SCSI emulation for USB Mass Storage devices

An individual file copy succeeds

[root@mowgli disk-1]# pwd
/media/disk-1
[root@mowgli disk-1]# cp -Rp ISDocs20060525/AppDevlTools/OracleODBC/Oracle\
Migration\ Kit\ User\'s\ Guide\ --\ Contents.htm
/160bk/ISDocs20060525/AppDevlTools/OracleODBC/Oracle\ Migration\ Kit\ User\'s\
Guide\ --\ Contents.htm

The tree command walks the "28872 directories, 341679 files" ok.



lsusb 
Bus 005 Device 030: ID 067b:2507 Prolific Technology, Inc. 
Bus 005 Device 001: ID 0000:0000  
...
Bus 001 Device 001: ID 0000:0000  



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

Linux version 2.6.20-2925.11.fc7xen (kojibuilder@hammer2.fedora.redhat.com) (gcc
version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Mon Jun 11 16:21:08 EDT 2007


How reproducible:

It appears to be reproducible.  The failure occurs at the same point in the
directory.

Steps to Reproduce:
Details are in the post above.
  
Actual results:
A complete -Rp copy fails of the USB drive.

Expected results:
cd /media/disk-1
cp -Rp . /160_bk
should copy the entire 160gig disk to an internal IDE drive.

Additional info:
dosfsck -nv /dev/sde1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     16384 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
  39053312 bytes per FAT (= 76276 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 78123008 (sector 152584)
   9763251 data clusters (159961104384 bytes)
63 sectors/track, 255 heads
         0 hidden sectors
 312576642 sectors total
Checking for unused clusters.
Checking free cluster summary.
/dev/sde1: 374313 files, 8188069/9763251 clusters

I will try Bug 242359 as the screen saver kicks in during the copy.
Comment 1 Greg Morgan 2007-07-21 19:20:44 EDT
I blindly followed
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359#c16 and added
'"usbcore.autosuspend=0" (without the quotes) to the kernel command line in
grub.conf'  However, a more of /proc/cmdline shows 
more /proc/cmdline
ro root=/dev/VolGroup00/LogVol00 rhgb quiet

and

Grub has

more /etc/grub.conf 
# grub.conf generated by anaconda
#
...
default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.22.1-27.fc7)
        root (hd0,0)
        kernel /vmlinuz-2.6.22.1-27.fc7 ro root=/dev/VolGroup00/LogVol00 rhgb qu
iet usbcore.autosuspend=0
        initrd /initrd-2.6.22.1-27.fc7.img
title Fedora (2.6.20-2925.11.fc7xen)
        root (hd0,0)
        kernel /xen.gz-2.6.20-2925.11.fc7 usbcore.autosuspend=0
        module /vmlinuz-2.6.20-2925.11.fc7xen ro root=/dev/VolGroup00/LogVol00 r
hgb quiet


The copy still failed.  Notice that the Xen kernel is not at 2.6.22 version and
yum reports
No Packages marked for Update/Obsoletion
[root@mowgli ~]# date
Sat Jul 21 16:18:34 MST 2007

Hence, I reassigned to Xen kernel thinking it is related to the other usb bug.

I will look up grub configuration and try again.
Comment 2 Bug Zapper 2008-05-14 09:37:20 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Bug Zapper 2008-06-16 21:55:55 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this 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.