Bug 734516 - When copying more than a few files from disk to usb flash drive, gnome environment freezes
Summary: When copying more than a few files from disk to usb flash drive, gnome enviro...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
: 755140 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-30 16:33 UTC by Brian G. Anderson
Modified: 2012-07-11 17:53 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-07-11 17:53:28 UTC

Attachments (Terms of Use)

Description Brian G. Anderson 2011-08-30 16:33:46 UTC
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):

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
Actual results:
System freezes

Expected results:
Responsive system

Additional info:

Comment 1 Tomáš Bžatek 2011-08-31 13:09:26 UTC
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.

Comment 2 Brian G. Anderson 2011-09-07 15:37:21 UTC
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

Comment 3 Tomáš Bžatek 2011-09-07 16:17:00 UTC
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.

Comment 4 Peter C 2011-10-01 23:09:48 UTC
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?

Comment 5 Tommy He 2011-10-05 14:49:33 UTC
Something very similar to https://bugzilla.redhat.com/show_bug.cgi?id=721127

Comment 6 Chuck Ebbert 2011-11-23 13:24:11 UTC
*** Bug 755140 has been marked as a duplicate of this bug. ***

Comment 7 Chuck Ebbert 2011-11-23 13:26:14 UTC
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:
then log in and leave karma (feedback).

Comment 8 Jaroslav Sykora 2012-02-21 22:49:52 UTC
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.

Comment 9 Brian G. Anderson 2012-02-21 23:02:25 UTC
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.

Comment 10 Josh Boyer 2012-06-06 19:08:31 UTC
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.

Comment 11 Josh Boyer 2012-07-11 17:53:28 UTC
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.

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