Bug 141275 - Writing to FAT32 file system on USB hard drive locks up computer
Summary: Writing to FAT32 file system on USB hard drive locks up computer
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dosfstools   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Ondrej Dvoracek
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-29 23:54 UTC by J. Lewis Muir
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:12:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Scripts used for generating test files (995 bytes, application/octet-stream)
2004-11-29 23:56 UTC, J. Lewis Muir
no flags Details

Description J. Lewis Muir 2004-11-29 23:54:43 UTC
Description of problem:
When I generate test files on a local file system and then use rsync to
copy those files to a FAT32 file system on a high-speed USB hard drive,
the computer locks up after transferring around 3-7GB worth of data
(sometimes less, sometimes more).

I can ping the computer but I can't log in at the console nor remotely
via SSH.

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

How reproducible:

Steps to Reproduce:
1. Partition and format high-speed USB connected 250 GB hard drive
   (these steps assume the USB hard drive is mapped to the /dev/sdb
   device file) (perhaps a smaller hard drive will exhibit the same
   # dd if=/dev/zero of=/dev/sdb bs=1024 count=1024
   # sfdisk /dev/sdb <<EOF
   # dd if=/dev/zero of=/dev/sdb1 bs=512 count=1
   # mkfs.vfat -F 32 -n EXTHD -v /dev/sdb1
2. # mkdir -p /mnt/exthd1
3. The UID and GID are that of the user 'jlmuir' that is used for
   non-root commands indicated with a dollar sign prompt below. Of
   course you will want to change the UID and GID to match your own.
   # mount -t vfat -o 'noatime,nodev,uid=502,gid=502,umask=007' \
     /dev/sdb1 /mnt/exthd1
4. Make large scratch file system at /data (must be large enough to hold
   generated data until writing to the USB hard drive causes the
   computer to lock up - 10GB might be enough...or you might need more)
   # mkdir /data/jlmuir
5. The punish-disk.tgz archive is included as an attachment to this bug
   report. Extract punish-disk.tgz archive and edit bin/punish variables
   PUNISH_DISK_HOME and EXT_HD_DEST to point to the correct location for
   where you have extracted the archive and where you have mounted the
   external USB hard drive. If you have used the paths shown in these
   steps, no changes need to be made.
   $ mkdir /mnt/exthd1/jlmuir
   $ cd /data/jlmuir
   $ tar -xpzvf ~/punish-disk.tgz
   $ vi punish-disk/bin/punish
6. $ ./punish-disk/bin/punish

Actual Results:  The punish script will stop printing progress output. It will not be
possible to log into the computer at the console nor remotely via SSH.

Expected Results:  The punish script should run until either the local scratch file system
fills up or the external USB hard drive file system fills up. The script
should stop, and the computer should remain functional the entire time.

Additional info:

For all I know, this could be a problem with the kernel vfat driver
rather than the dosfstools.

The external hard drive is a LaCie d2 250 GB hard drive (model #
300718). It is connected via its USB interface and should be operating
in high-speed mode.

Here's model information about the USB controller I think is being used:
# lspci | grep -i usb
00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 \
EHCI Controller (rev 02)

Comment 1 J. Lewis Muir 2004-11-29 23:56:52 UTC
Created attachment 107588 [details]
Scripts used for generating test files

Comment 2 J. Lewis Muir 2004-11-30 00:04:23 UTC
I should also note that using this exact same hardware connected in
exactly the same way with an ext3 file system on the external hard drive
works fine. This made me think it was a problem solely with FAT32, but
then I tested this exact same hardware with a FAT32 file system on the
external hard drive connected via FireWire 400 instead of USB and it
worked fine. So it seems to be a problem with the pairing of USB and

Comment 3 RHEL Product and Program Management 2007-10-19 19:12:52 UTC
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.

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