Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 92213 - (USB STORAGE)Transfer using highspeed usb mass storage causes i/o error
(USB STORAGE)Transfer using highspeed usb mass storage causes i/o error
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Depends On:
  Show dependency treegraph
Reported: 2003-06-03 17:24 EDT by Need Real Name
Modified: 2007-04-18 12:54 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-19 22:11:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages excerpt (11.12 KB, text/plain)
2003-06-24 20:32 EDT, Dan Berger
no flags Details
dmesg output (14.96 KB, text/plain)
2003-06-24 20:32 EDT, Dan Berger
no flags Details

  None (edit)
Description Need Real Name 2003-06-03 17:24:50 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):

How reproducible:

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.

Additional info:
Comment 1 Need Real Name 2003-06-03 17:55:46 EDT
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 
Rev: 0100
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
(122941 MB)
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)[8357]: 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)[8357]: 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
product d49/3010/100
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
Comment 2 Pete Zaitcev 2003-06-03 19:36:49 EDT
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.
Comment 3 Dan Berger 2003-06-24 20:31:25 EDT
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
those messages.

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
mount point.
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

Comment 4 Dan Berger 2003-06-24 20:32:24 EDT
Created attachment 92605 [details]
/var/log/messages excerpt

annotated (using logger(1)) with the attach/detach events
Comment 5 Dan Berger 2003-06-24 20:32:51 EDT
Created attachment 92606 [details]
dmesg output
Comment 6 Need Real Name 2003-08-23 10:24:19 EDT
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.
Comment 7 Need Real Name 2003-08-23 10:25:49 EDT
Sorry, that last comment should have read "I can copy from the device".
Comment 8 Owen LaGarde 2003-09-25 15:01:58 EDT
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).
Comment 9 Bruce Allen 2003-10-28 00:25:04 EST
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.
Comment 10 Steven Lohrenz 2004-01-08 11:25:46 EST
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 
unrelated though. 
Comment 11 Bruce Allen 2004-01-08 11:48:21 EST
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[78].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)
Comment 12 Pete Zaitcev 2004-08-19 19:23:15 EDT
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
performance problems.

I suspect it's the PF_MEMALLOC missing.

Needinfoing until Dan replies
Comment 13 Dan Berger 2004-08-19 19:51:22 EDT
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.
Comment 14 Pete Zaitcev 2004-08-19 20:30:58 EDT
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?
Comment 15 Dan Berger 2004-08-19 22:04:43 EDT
Sure - works for me.

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