Description of problem: I have a three of AVI files ranging from 700k to 1.5G in size which I want to copy to a USB flash drive. I plug in the drive and use nautilus to view the contents of the drive and another nautilus to view the contents of the source directory on my hard disk with the three files. I then drag one of the files from the view showing the hard drive to the the view with the flash drive and a progress pop-up appears showing the coping. This starts of progressing fairly quickly but will slow down about 75% (~500m). So I drag over two more of the files from the HD view to the USB Drive view and the progress pop-up is updated with two more progress bars which again start to move quickly and then stop at some partial way. Meanwhile the USB write lite is flashing quickly showing write activity. Then after about two minutes, the entire desktop stops responding. No updates no keyboard response. The mouse pointer moves, but I can't focus on anything. I even try switching to a console window using CTL-ALT-F2, but no response. The USB drive write LED is still going strong. I'm tempted to kill X, but I know that if I wait about 10 minutes, responsiveness will return. The file copies will be finished according to nautilus since the progress pop-ups are gone, but the USB drive light is still going. I checked .xsession-errors and dmesg, but there are no obvious errors relating to the copy or indicating why the system froze; perhaps a dead-lock? The USB drive mount was reported as: [985445.333216] usb 2-1.4.3: new high speed USB device number 112 using ehci_hcd [985445.998824] usb 2-1.4.3: New USB device found, idVendor=05dc, idProduct=a813 [985445.998830] usb 2-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [985445.998835] usb 2-1.4.3: Product: USB Flash Drive [985445.998839] usb 2-1.4.3: Manufacturer: Lexar [985445.998843] usb 2-1.4.3: SerialNumber: AAHKE2MVP60TNDEO [985446.005643] scsi7 : usb-storage 2-1.4.3:1.0 [985448.594779] scsi 7:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 0 CCS [985448.599732] sd 7:0:0:0: Attached scsi generic sg3 type 0 [985450.134833] sd 7:0:0:0: [sdc] 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB) [985450.135929] sd 7:0:0:0: [sdc] Write Protect is off [985450.135935] sd 7:0:0:0: [sdc] Mode Sense: 43 00 00 00 [985450.137049] sd 7:0:0:0: [sdc] No Caching mode page present [985450.137056] sd 7:0:0:0: [sdc] Assuming drive cache: write through [985451.889619] sd 7:0:0:0: [sdc] No Caching mode page present [985451.889625] sd 7:0:0:0: [sdc] Assuming drive cache: write through [985451.890594] sdc: sdc1 [985451.893993] sd 7:0:0:0: [sdc] No Caching mode page present [985451.893999] sd 7:0:0:0: [sdc] Assuming drive cache: write through [985451.894004] sd 7:0:0:0: [sdc] Attached SCSI removable disk [985452.558930] SELinux: initialized (dev sdc1, type vfat), uses genfs_contexts [986411.374402] SELinux: initialized (dev proc, type proc), uses genfs_contexts [986458.188756] usb 2-1.4.3: USB disconnect, device number 112 Version-Release number of selected component (if applicable): nautilus-3.0.2-1.fc15.x86_64 How reproducible: Fairly reliable as long as one has a lot of large files to copy. Steps to Reproduce: 1. Mount a USB drive 2. Use nautilus to copy three or more large (> 800M) files simultaneous from the HD to the USB drive 3. Actual results: System freezes Expected results: Responsive system Additional info:
This doesn't look like a nautilus or gnome bug, more like a kernel/driver issue. This would be difficult to debug as long as there are no suspicious lines in dmesg.
Well, it's a big problem. My whole machine becomes unresponsive. You're right about it being most probably a kernel bug since when I ssh in an try and copy something large it will lock up the shell too. Should it be reassigned? If you go on fedoraproject forums you will see that I'm not the only one with this problem
That looks horrible. Sounds like your disk controller runs in PIO mode. You can try booting with "elevator=cfq" or "elevator=as" to see the difference, but it's a lame advice after all. Reassigning to kernel.
Having identical problem here. And a quick google suggests we are not the only ones. What information can I provide to get this looked into?
Something very similar to https://bugzilla.redhat.com/show_bug.cgi?id=721127
*** Bug 755140 has been marked as a duplicate of this bug. ***
Package kernel-3.1.2-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.1.2-1.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16237/kernel-3.1.2-1.fc16 then log in and leave karma (feedback).
Hi! Let me provide a new datapoint to this matter as I think I have the same problem: Situation: source disk: internal SATA HDD, reading at approx 90MB/s Destination: external magnetic HDD over USB 2.0, writing at approx 30MB/s Kernel: 3.2.6-3.fc16.x86_64 When the external drive is formatted as BTRFS the system (X, KDE) stalls after a few hundreds of MB are "copied". I say "copied" because in midnight commander (mc) it reports progress according to the read-rate, i.e. cca 90MB/s, then once the kernel buffers are full the whole system is stalled (while the data are pushed over usb at cca 30MB/s), or slowed down to a point of being unusable. Once the copying is over everything returns to normal. No info in dmesg. Interestingly when the external HDD is formatted EXT4 the stall does not happen... almost. I think there still were one or two short (<0.5sec) intermittent stalls, but this may be subjective. In EXT4 the reported speed in mc starts at the read-rate (90MB/s), then progressively degrades to the real write-speed (30MB/s), and the system stays responsive. I switched the external HDD to deadline scheduler, with no avail. I tried changing the scheduling class to 'idle' on mc. It helped a little: as long as I play around in KDE (e.g. switching desktop there and back) while copying it runs pretty fine. However, when I leave it for a few seconds it chokes and stalls.
Update. My machine is up to kernel 3.2.6-3.fc16.x86_64 and the problem is most definitely still around. I had three avi files each at or above 1G and I used nautilus to move each over to my USB disk in quick succession. Everything was fine for about 5 minutes with all three transfers showing progress, but then the progress meter speed level starts dropping steadily until when it reaches zero, the entire UI freezes. No keyboard response, no switching to the console or killing X; the mouse shows movement but doesn't respond to input. I let it sit for 20 minutes and while the drive write light was flashing there was still no user response. When I pull the USB drive then the UI returns. I'd say that while the time to freeze has improved it still occurs with the same disastrous results.
The 3.4 kernel has additional fixes in this area. It is already in F17 updates now and F16 should get it soon. If anyone is willing to try that, please let us know.
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.