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): kernel-2.4.20-18.9 How reproducible: Always 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:
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 hoffman(uid=500) 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 (error=-71) 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 implemented 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 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
Created attachment 92605 [details] /var/log/messages excerpt annotated (using logger(1)) with the attach/detach events
Created attachment 92606 [details] dmesg output
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 unrelated though.
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: sync date dd if=/dev/zero of=/mnt/usbdisk/testfile bs=1M count=1k sync date took 79 seconds (a write speed of about 12 MB/s). Read speeds were comparable. 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) ftp://people.redhat.com/zaitcev/120341/ 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
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.