Red Hat Bugzilla – Bug 92213
(USB STORAGE)Transfer using highspeed usb mass storage causes i/o error
Last modified: 2007-04-18 12:54:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
When trying to do a transfer either to or from a Maxtor usb drive using the
highspeed usb ports on my Dell 8250 the transfer will hang and eventually time
out. Once this happens the only way to bring the device back on line is to
reboot Linux (shutting down and restarting the device does not clear the
problem, the o/s reports "/dev/sda1 not a valid block device" until the system
is rebooted). The device WAS WORKING fairly reliably with 2.4.20-13.9 but that
could have been because the files being transferred where smaller. The files
that cause the problems are several hundred MB in size. I appears as though the
i/o system gets overwhelmed, confused and then locks up. This is most anoying. I
am running RH9 and it is proving to be buggy as all getout.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Mount file system
2.start transfer of file >200MB
3.observe transfer stall and eventualy report an input/output error.
Expected Results: The file sould be copied.
Jun 3 16:51:55 mycinae kernel: Initializing USB Mass Storage driver...
Jun 3 16:51:55 mycinae kernel: usb.c: registered new driver usb-storage
Jun 3 16:51:55 mycinae kernel: scsi1 : SCSI emulation for USB Mass Storage devices
Jun 3 16:51:55 mycinae kernel: Vendor: Maxtor Model: 3000LE v01.00.00
Jun 3 16:51:55 mycinae kernel: Type: Direct-Access
ANSI SCSI revision: 02
Jun 3 16:51:55 mycinae kernel: Attached scsi disk sda at scsi1, channel 0, id
0, lun 0
Jun 3 16:51:55 mycinae kernel: SCSI device sda: 240119808 512-byte hdwr sectors
Jun 3 16:51:55 mycinae kernel: sda: sda1
Jun 3 16:51:55 mycinae kernel: USB Mass Storage support registered.
Jun 3 16:51:55 mycinae devlabel: devlabel service started/restarted
Jun 3 16:52:26 mycinae su(pam_unix): session opened for user root by
Jun 3 16:52:34 mycinae kernel: kjournald starting. Commit interval 5 seconds
Jun 3 16:52:34 mycinae kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jun 3 16:53:22 mycinae su(pam_unix): session closed for user root
Jun 3 16:55:36 mycinae kernel: hub.c: USB device not accepting new address
Jun 3 16:55:36 mycinae kernel: usb.c: USB disconnect on device 02:01.2-1 address 4
Jun 3 16:55:36 mycinae kernel: hub.c: new USB device 02:01.2-1, assigned address 5
Jun 3 16:55:39 mycinae /etc/hotplug/usb.agent: Setup usb-storage for USB
Jun 3 16:55:41 mycinae kernel: usb-storage: host_reset() requested but not
Jun 3 16:55:51 mycinae kernel: scsi: device set offline - command error recover
failed: host 1 channel 0 id 0 lun 0
Jun 3 16:55:51 mycinae kernel: SCSI disk error : host 1 channel 0 id 0 lun 0
return code = 6070000
Jun 3 16:55:51 mycinae kernel: I/O error: dev 08:01, sector 116230488
Jun 3 16:55:51 mycinae kernel: I/O error: dev 08:01, sector 116230496
Jun 3 16:55:51 mycinae kernel: I/O error: dev 08:01, sector 116230736
Jun 3 16:55:51 mycinae kernel: I/O error: dev 08:01, sector 116230488
Jun 3 16:55:51 mycinae devlabel: devlabel service started/restarted
Please attach a dmesg output taken _after_ the problem occured.
Do not drop it intot the comments box, but attach using the
"Create a New Attachement" link.
I'm seeing similar sorts of problems talking to a Neuros (www.neurosaudio.com)
over USB 1 mass storage using the current (2.4.20-18.9) smp kernel.
Unfortunately I don't have any other USB mass storage device to experiment on,
but other owners of this product report that upgrading to the stock 2.4.21
kernel improves the situation dramatically. Attempting to replicate the
problems under the up kernel is unsucessful - the device is never recognized.
The initial connect and mount work correctly - though occasionally a write will
fail, and the device will be set to read-only with the following kernel messages:
Jun 19 19:21:10 rage kernel: I/O error: dev 08:01, sector 227582
Jun 19 19:22:14 rage kernel: Filesystem panic (dev 08:01).
Jun 19 19:22:14 rage kernel: FAT error
Jun 19 19:22:14 rage kernel: File system has been set read-only
Jun 19 19:22:14 rage kernel: Directory 107: bad FAT
Note that this corruption is not present before performing writes from linux -
an fsck.vfat runs clean before those messages, and finds and fixes errors after
Subsequent disconnect/reconnect cycles usually fail - requriring a linux reboot
to regain access to the device. Occasionally the connect works, but the device
is assigned a different device id (sdb, rather than sda). In these cases, the
device can't be mounted on the original mount point, (it reports that /dev/sdb1
is already mounted or /mnt/neuros is busy) but can be mounted on a different
Additionally, while performing writes the system is very unresponsive.
I'm attaching the output of dmesg and a bit of /var/log/messages corresponding
to the following steps:
1. boot the linux machine
2. attach the USB device - the initial connection works, the device is mounted,
unmounted, and detached
3. the device is re-attached - the connection assigns the device to sdb rather
than sda, the device can be mounted (as /dev/sdb1) on a secondary mount point -
it is mounted, unmounted, and detached for the second time
4. the device is again re-attached - the connection fails completely and the
external device hangs and must be reset
Created attachment 92605 [details]
annotated (using logger(1)) with the attach/detach events
Created attachment 92606 [details]
I installed the latest kernel-smp (2.4.20-20.9) and this seems to improve the
situation somewhat, though not fix it. I can not copy from the drive but writing
large files to or deleting a bunch of files from the drive will cause an
evenual hang as before. After a hang the i/o operations eventually time out and
the fs can be umounted. Any attempt to remount the device results in:
mount: /dev/sda1 is not a valid block device
Physically removing the usb device and reattaching it does not fix the problem.
Sorry, that last comment should have read "I can copy from the device".
Seeing the same behavior and dmesg content on a 8.0 box wth 2.4.20-20.8smp and
either a 120GB AcomData RocketPod or 40GB BUSLink Disk-on-the-go. Writes trip
at > 520MB, intermittently greater or smaller, mk***fs also fails with similar
dmesg content. One additional oddity: on a stock 8.0 install, writes appear to
buffer at the device and flushes as expected, but with the current system all
ops appear to occur in real time, no buffering (ie., no flush-block-flush cycle
as seen from the kernel side of the bus).
Seeing similar issues on RH 7.3 with 2.4.20-20.7 kernel.
Hardware is Dell C600 laptop, with a 160 GB
maxtor disk in an external USB 2.0 enclosure.
I have identical problems under RH 8.0 with the same kernel, this time on
a brand-new IBM T40 thinkpad.
Summary of problems:
mkfs is VERY slow. First 100 entries out of 1222 go fast, then it slows to
a crawl. Finally the system simply hangs.
I was eventually able to use fsck to complete a file system. At that point,
if I mount it, I can copy files - but it extremely slow - typically 0.5 MB/sec.
Seeing similar behavior on RH 9 with kernel 2.4.20-28.9. Maxtor 5000DV 2000 GB
external usb mounted as /dev/sdb1 on /mnt/extHD.
Specified mount options include: vfat -rw, user, exec, noauto, hard, intr, umask=0 0 0
Hardware is Dell Precision 420.
Summary of problems:
Copying large files (> 1 Gb) locks system and reboot required.
Also noticed when copying in verbose mode that copying process attempts to change
file permissions on smaller copied files to those of orginal file and this fails. Probably
I eventually found out the solution (in my case at least!). The
problem was that my laptop's internal USB port is USB 1 not USB 2. I
was able to confirm this by using usbview -- the line that says Speed:
12Mb/s (full) proves that it's not USB 2. From reading various web
reports, it appears that USB 1 has a practical speed limit
substantially slower than one might expect -- around 100 kB/s. This
explains why things like large file copies hang.
For $35 (USD) I purchased an Edimax EU-PC2P USB 2.0 CardBus (PCMCIA)
card. This card was recognized by and worked out-of-the-box with the
stock redhat 2.4.20-2.7 kernel. Using usbview shows Speed:
480Mb/s (full) which is a factor of forty faster than the USB 1
internal port. Plugging the external USB hard disk into this new USB
2 port made a DRAMATIC difference. It took a few minutes to build an
ext3 file system on a 160 MB disk. A 1 GB file write test:
dd if=/dev/zero of=/mnt/usbdisk/testfile bs=1M count=1k
took 79 seconds (a write speed of about 12 MB/s). Read speeds were
A full cpio copy (backup) of 20 GB of data from my laptop drive took
51 minutes, which is an average write speed of about 7 MB/s.
So people having problems like this:
(1) use usbview to see if your USB port is USB 1 (12 Mb/s)
(2) if so, try adding a true USB 2 port (480 Mb/s)
Please try FC2 or RHEL's kernel over FC1 (it is compatible)
Bruce, stay away from this bug. It's all about a lockup, not
I suspect it's the PF_MEMALLOC missing.
Needinfoing until Dan replies
I'm no longer running FC 1 with a RH kernel on any machines (my
notebook is running FC1, but with a custom 2.6 kernel). My FC2
machine doesn't demonstrate these symptoms, but that's as much help as
I can offer at this point.
This is a help, because I had a report which hints at the need
for PF_MEMALLOC just a few days ago in FC3T1.
Can I close this now?
Sure - works for me.