Description of problem: I bought a USB 2.0 card (Adaptec AUA-2000 -- this is a PCI card w/ two USB ports) and media reader/writer (SanDisk 5-in-1 Imagemate) so I could fill my SD cards in a reasonable amount of time. I am copying files from my external USB hard drive (it's an IDE drive in a USB enclosure). About the fourth time I copied a directory of .oggs the write hung. Killing the process that is doing the copy has no effect -- kill -9 does not remove it, it is just completely hung. System can't even be rebooted to get rid of it, as drives will not umount; I have to power cycle (would appreciate any advice on avoiding this). The problem does not seem to manifest when copying data to an intermediary directory, nor if the write device is on a slower USB port; owing to the annoying nature of reproducing this (i.e. requiring reboot) I haven't had abundant opportunities to explore this, but it seems to manifest ONLY when both devices are on the fast USB ports. Version-Release number of selected component (if applicable): # uname -a Linux desktop.sosiouxme.net 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23 EST 2005 i686 athlon i386 GNU/Linux How reproducible: Perhaps 1 in 3 times I try to copy a directory of ~50 MB. Steps to Reproduce: 1. Hook up two high-speed USB 2.0 devices to card ports as described. 2. Copy ~50MB data from one to the other. Try a few times. Actual results: Write hangs, both devices "busy", write process(es) cannot be halted. Expected results: Data copied, devices free to unmount. Additional info: # usbtree /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/5p, 480M |__ Port 3: Dev 5, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 4: Dev 6, If 0, Class=stor., Driver=usb-storage, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 12M strace cp -R /media/usbdisk/music/stevie_ray_vaughan__double_trouble/greatest_hits/ /media/usbdisk1/audio/srv >& /tmp/cp.strace.log [...] read(3, "\275\207\245\327\212\331A\310\2$\30\353=\\\304p@ \1^\313"..., 16384) = 16384 write(4, "\275\207\245\327\212\331A\310\2$\30\353=\\\304p@ \1^\313"..., 16384) = 16384 read(3, "\366\35\263\353\366\333\213\220/\'/\205\327\346\367F\36"..., 16384) = 16384 write(4, "\366\35\263\353\366\333\213\220/\'/\205\327\346\367F\36"..., 16384) = 16384 read(3, "\20\216\324N\351\250L\231\4\360\332\362\316\204\371Y\327"..., 16384) = 16384 write(4, "\20\216\324N\351\250L\231\4\360\332\362\316\204\371Y\327"..., 16384 (looks like the relevant bit, if any, may have been buffered... doh) I'd be happy to perform any further diagnostics if someone can tell me which ones would be relevant!
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.