USB file transfer causes system freezes; ops take hours instead of minutes

Bug #500069 reported by sbec67 on 2009-12-24
This bug affects 131 people
Affects Status Importance Assigned to Milestone
Fix Released
linux (Fedora)
linux (Ubuntu)
Nominated for Lucid by Mudstone

Bug Description

USB Drive is a MP3 Player 2GB

sbec@Diamant:~$ lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 046d:c50e Logitech, Inc. MX-1000 Cordless Mouse Receiver
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 0402:5661 ALi Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Linux Diamant 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux
Ubuntu 2.6.31-15.50-generic

to test, i issued dd command:
dd if=/dev/zero of=/media/usb-disk/test-file bs=32

while dd is running i run dstat.... this is in the log file attached.

other logs are also in the tar.gz file...

there is a huge USB performance Bug report #1972262. this Report is something simular

sbec67 (sbec) wrote :
Dexter (pogany-tamas+bug) wrote :

I have this problem too, check my logs. My USB 2.0 pendrive's speed is about 3-5 MB/s. Soooo slow.

sbec67 (sbec) wrote :

did someone took a look on this ?
This Bug is really annoying, as it takes ages to bring some Data on a USB Device ;-(


Changed in linux (Ubuntu):
status: New → In Progress
assignee: nobody → Colin King (colin-king)
Colin Ian King (colin-king) wrote :

@sbec67, can you run the following command to collect all the system specific information about your computer to help us diagnose this bug:

apport-collect 500069

please can you supply the model number of the pendrive and if you are using it via a USB hub or not.


Changed in linux (Ubuntu):
importance: Undecided → Medium
importance: Medium → High
Andy Whitcroft (apw) on 2010-01-13
tags: added: kernel-series-unknown
sbec67 (sbec) wrote :

@Colin: I entered "sudo apport-collect 500069"
the Device i facing the Problem is a Tech Line DFS-1002 MP3 Player.
But it seems the Problem happens with almost any Flash Memory USB Device.

@Andy: GRUB uses ( out of /boot/gruub/menu.lsi ) this Kernel Parm to boot:

kernel /boot/vmlinuz-2.6.31-17-generic root=UUID=96f8feb3-e65b-4696-b8f
5-c32638cde861 ro quiet splash

Kind regards

 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: pablo 1645 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
 Card hw:0 'Intel'/'HDA Intel at 0xf0340000 irq 22'
   Mixer name : 'Realtek ALC272'
   Components : 'HDA:10ec0272,144dca00,00100001'
   Controls : 19
   Simple ctrls : 12
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=c1938014-8689-4db3-add3-99b0c514b946
Package: linux (not installed)
ProcCmdLine: root=UUID=5f964d43-b8cd-4886-a6e5-80376a5eb7b5 ro quiet splash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
 linux-backports-modules-2.6.31-17-generic N/A
 linux-firmware 1.25
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
Tags: ubuntu-unr
Uname: Linux 2.6.31-17-generic i686
UserGroups: adm admin cdrom dialout fuse lpadmin plugdev sambashare
WpaSupplicantLog: 09/08/2009
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: 11CA.M015.20090908.RHU NC10
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvr11CA.M015.20090908.RHU:bd09/08/2009:svnSAMSUNGELECTRONICSCO.,LTD.:pnNC10:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNC10:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A: NC10
dmi.product.version: Not Applicable

tags: added: apport-collected
16 comments hidden view all 135 comments

I've also experienced very slow USB transfers, with CPU waiters piling up. The odd thing is that USB-to-USB transfers go at about four times the speed of HDD-to-USB transfers. On average I get 2MB/s from hard drive to USB, and about 8MB/s copying between flash drives.

sbec67 (sbec) wrote :

its correct.. this Report is a duplicate of #197762
But #197762 has Status "incomplete", and is Medium. & almost 1 1/2 Years old !

I think this Bug should be High.. its realy a Pain in the A..... for many Users.

Simon Holm (odie-cs) wrote :

Have you tried your device with another OS with different performance results?

From your lsusb output is does not look like your device is listed? Was it plugged in when you ran lsusb?

If that doesn't turn up anything obvious you should probably see and test whether the raw device performance is better than when formatted. Backup your data on the device first.

dd numbers with bs=1M in addition to the bs=32 would also be interesting.

MMS-Prodeia (mms-prodeia) wrote :

I do second this report!

sbec67 (sbec) wrote :

Simon Holm Thøgersen:
it was connected, and it also shows on lsusb
Bus 001 Device 004: ID 0402:5661 ALi Corp

its a Bug, witch hit many Users.
Do a google...... just one Talk:

i passed all Data with the apport-collect command.. Unit was connected while doing this command.

i did a other Test with a Sony 4GB USB stick.. there i dont see this Problem...
so it seems that that Problem happens only with certain Flash Drives

Mudstone (agovernali) on 2010-01-29
description: updated
Mathias Zubek (mathias-zubek) wrote :


I have this problem too....
2 Installations: My PC is an Intel MoBo DG965WH; my Laptop is an ThinkpadT60.
Both with Karmnic 9.10 and patches are up to date. Maximum Write speed after transferring more than 150MB slows down to 3,5MB/s.
Adding ehci_hcd to /etc/initramfs-tools/modules as recommended in some posts was not helpful.

Thanks in advance

sbec67 (sbec) wrote :

@colin Mins: any new on this, as its assigned to U ?


Badcam (kiwicameron+launchpad) wrote :

I believe that I have this very same issue on my Mint 8.0 distro. I have two 5 port USB 2.0 hubs and only 1 USB port in either device is showing as a USB 2.0, with all the rest showing 1.1 I've checked the hardware and every port is supposed to be 2.0

Running a "sudo dmesg | grep usb" swwms to show that all the devices are recognised as 2.0 but somehow being limited to 1.1:

[156037.796028] usb 10-2: new full speed USB device using uhci_hcd and address 5
[156037.941105] usb 10-2: not running at top speed; connect to a high speed hub
[156037.979263] usb 10-2: configuration #1 chosen from 1 choice

I have not attached a patch, just my Terminal info.

aleth (aleth) wrote :

I also have this issue when writing to a 4Gb USB stick. Transfer rates start high, then slow to a crawl or even stall completely. As they slow down, the whole computer becomes unresponsive for seconds at a time.
On the same machine, the same USB stick is working fine under Windows XP; read access is also no problem.

aleth (aleth) wrote :

Just in case, it might be worth pointing out there are many more reports of this problem at

This is one workaround until it's got fixed: update the kernel.

Go to and choose a recent linux-image file. Download and install.

Changed in linux (Ubuntu):
status: In Progress → Confirmed
blahde (daisy-ice) wrote :

@André Desgualdo Pereira:

which kernel exactly do you recommend? Linux 2.6.35-020635rc1-generic does not bring any changes - for me.


The 2.6.33 kernel has worked with Karmic Koala, but I haven 't tested with Lucid Lynx.


blahde (daisy-ice) wrote :

@André Desgualdo Pereira:

Thank you. Unfortunately 2.6.33 doesn't make any difference for me either - on Lucid Lynx. Whereas I can confirm that the transfer rate from USB to USB seems to be not affected by this.

Sorry I can't help any further.
If I found something I will post here.

Adam Kulagowski (fidor-fidor) wrote :

I have Sandisk Backup U3. (32G). I've tested it on 4 different computers. I had always writing speed around 3MB/s, which is slow, because this pendrive is capable of doing 16-17MB/s writing speed. The only way I'm able to put files faster is to use dd with bs=64 AND oflag=direct. Using these options I have full writing speed.

dd if=ubuntu-10.04-server-amd64.iso of=/media/FE35-228F/file.bin bs=64k oflag=direct
10840+1 records in
10840+1 records out
710412288 bytes (710 MB) copied, 43,8788 s, 16,2 MB/s

What is also important I can break the copying proccess any time. Without oflag=direct dd ignores Ctrl-C or even kill -9.

This was tested on 10.04 and with similar result on "Recovery is Possible" distro (kernel 2.6.34-git16)

uname -a
Linux fidor 2.6.32-24-generic #38-Ubuntu SMP Mon Jul 5 09:20:59 UTC 2010 x86_64 GNU/Linux

Maybe it will help.

Adam Kulagowski (fidor-fidor) wrote :

I've made a typo in my previous comment: you have to specify (at least in my case) bs=64k , not bs=64. Command line example was correct. Any other value, bigger or smaller (32k, 128k, 256k) brings speed down back to 3MB/s.

One more thing. I've found second pen drive which is working correctly (full 5MB/s writing speed). There are some small differences in lsusb between those two. I'm attaching lsusb -v output.

On the working pen drive (Adata) bs doesn't really matter. Of course with bigger block size, you get bigger writing speed up to 128k. Bigger bs than 128k doesnt change anything. I've tested from 256k up to 2048k, still achieving full writing speed.

I'll try to test more USB sticks.

Changed in linux (Ubuntu):
assignee: Colin King (colin-king) → nobody
Brad Figg (brad-figg) on 2011-07-14
Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Adam Porter (alphapapa) on 2012-01-30
summary: - since Ubuntu karmic Filetransfer to some USB Drives got realy slow
+ USB file transfer causes system freezes; ops take hours instead of
+ minutes
Brad Figg (brad-figg) on 2012-01-31
tags: added: precise
Changed in linux (Ubuntu):
status: Won't Fix → Confirmed
Brad Figg (brad-figg) on 2012-01-31
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-12.20
Adam Porter (alphapapa) on 2012-01-31
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: bot-stop-nagging.
Changed in linux:
importance: Unknown → High
status: Unknown → Confirmed
tags: added: kernel-fixed-upstream
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Changed in linux:
status: Confirmed → Fix Released
55 comments hidden view all 135 comments
elatllat (elatllat) wrote :

I appreciate your frustration but try to understand the people who can fix this problem are unable to reproduce it, and the people who have the problem are unable to so much as report on it properly.

If you truly want this fixed please take the time to learn how to report a bug properly.
At 95 comments clearly there is A problem but without a stack trace, log, or conclusive benchmarking it's unlikely to be addressed.

lowsky (jpc1208) wrote :


The Developers don't have a 600MB of files and a common USB drive on hand to test transfer speed? The issue causes programs like Banshee and Rythmbox to force close because the system believes their is an issue if you try to transfer an entire library of music or video to a media device. So it isn't just messing with USB drives acting as part of the file sytem but also effecting devices using MTP.

Its easily reproduced but impossible to test and log for the normal user. FAT32 suffers the most significantly, but the results are reproducible with EXT2 and NTFS. It's hard to benchmark for many users. They don't have the time to sit and watch 1GB of data not do anything for 6 hours. They need their PC to be usable.

Even when this bug was first reported it was pretty common for people to have large files.
The issue is clearly there, and has been ignored up til recently, and is only now being looked at because of Ubuntu's move from using 700MB CDs to using USB drives as a installation medium.

I see this problem since precise, and it clearly is not fixed in the latest quantal.
Please note that whatever caused this problem, it appeared in precise. I never had USB speed issues in oneiric.

Today, I created USB installation media, using Ubuntu's "Startup disk creator", from (a) the latest quantal release, (b) precise release, (c) oneiric release.
(a) and (b): Live image takes up to 10 minutes just to boot up, then system is so slow it is unusable.
(c): Live image boots up in approx. 2 minutes and is usable.

Can anyone confirm that this problem was not present in oneiric, but appeared in precise?

Andrey Dj (djdron) wrote :

Seen this problem for years.
Ubuntu/Linux FAIL.

Antony Jones (wrh) wrote :

This is the single most infuriating bug that I have ever seen in Ubuntu and I've been struggling with it for about 3 years now (before that there was no problem, so anybody saying large files weren't invented back then, is talking crap).

How are we supposed to send log files and output for something which doesn't create either? This bug is simple to reproduce. Copy a 3gb file to a USB stick which uses FAT32 - any HD movie is a good candidate.

If there is a developer who is able or willing to fix this I will happily send them a USB stick and a file for them to reproduce the problem to their hearts content, if only this stupid problem would be fixed.

On Fri, Mar 29, 2013 at 5:06 AM, Andrey Dj <email address hidden> wrote:
> to test, i issued dd command:
> dd if=/dev/zero of=/media/usb-disk/test-file bs=32

The above dd test is very stupid, since setting bs as 32 will make usb
storage transfer very very slowly, and the typical value(also max value)
in kernel is 120K.

Ming Lei

garzie2000 (garzie2000) wrote :

I can't believe this bug still exists in Ubuntu 12.10. It's annoying as hell. Please developers work your magic and fix this once and for all!


Do you really expect people to do magic and fix a bug without proper logging?
This seems to work different for all people, in my case USB transfers are fine, but seems like the people affected cannot submit a bug properly for the people who can fix it, and the people who can fix it, cannot reproduce the bug because their USB transfers are fine. Everybody claims that only copying data from the hard drive to the USB is sufficient to reproduce the bug, but that's not the case, a benchmarking from an affected system is necessary to do a fair comparison and try to find the cause of the issue. Maybe this link can be useful for that goal:

gonssal (gonssal) wrote :

This 'bug' is fixed running "modprobe ehci_hcd" (as root) in my 13.04. Been having the issue since 08.04 maybe, only now I _needed_ to fix it.

So maybe load that module by default and mark this as fixed?

1 comments hidden view all 135 comments
Tsu Jan (tsujan2000) wrote :

Has anyone tried to disable THP (transparent huge-pages) with the following command (as root) before using USB stick?

echo "never" > "/sys/kernel/mm/transparent_hugepage/enabled"

This can be easily undone with:

echo "always" > "/sys/kernel/mm/transparent_hugepage/enabled"

Or just with a reboot.

Daniel Barrett (dbarrett-m) wrote :

gonssal (#104): On 13.04 (live CD), I ran "sudo modprobe ehci_hcd" and copied files from an internal SSD to an external USB3 drive. I get super-slow 1 MB/second transfer rates. I boot the same computer into Windows 7 (it's dual boot) and I get 150MB/sec.

I get the same problem if I use eSATA or Firewire (the external drive has all three connections): slow on 13.04, fast on Windows 7.

If I boot on a Knoppix 7.2 CD, however... FAST FAST FAST transfer speed. Knoppix is 3.9 kernel, while 13.04 is 3.8.

I also tried the Ubuntu nightly build of 13.10 today (kernel 3.11), and it had the same slowness problem as 13.04.

I also tried #106 (echo "never" > "/sys/kernel/mm/transparent_hugepage/enabled") and it made no difference.

My vendor blames the ASmedia Chipset on my motherboard, which he says Linux has "rudimentary at best" support for.

Tsu Jan (tsujan2000) wrote :

@Daniel Barrett

I have Debian with Liquorix kernel 3.10.X and this always works for me before inserting usb stick:

sudo bash -c 'echo "never" > /sys/kernel/mm/transparent_hugepage/enabled'

I just came to this page and was surprised that there was no trace of "THP" or "hugepages", so I added a comment.

See for explanation.

Daniel Barrett (dbarrett-m) wrote :

Referencing my previous post (#107): never mind. Something else is wrong with my machine. ALL disk writes are 1MB/second, even on my internal SSD RAID. So it's not just external drives.

sbec67, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:

where VERSION-NUMBER is the version number of the kernel you tested. For example:

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:

If the mainline kernel does not fix this bug, please add the following tags:

As well, please remove the tag:

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Henry Mata (matahr) wrote :

still persists in trusty tahr
Linux 3.12.0-4-generic x86_64 GNU/Linux

Henry Mata, so your hardware may be tracked, could you please file a new report via a terminal:
ubuntu-bug linux

ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
 /dev/snd/controlC1: ao 2970 F.... pulseaudio
 /dev/snd/controlC0: ao 2970 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-06 (10 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140404)
MachineType: System manufacturer System Product Name
Package: linux (not installed)
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=b49aac97-cebf-48a0-b5b2-db2b0c148a81 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
Tags: trusty
Uname: Linux 3.13.0-24-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True 08/09/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1501
dmi.board.asset.tag: To Be Filled By O.E.M. M4A88TD-M/USB3
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1501:bd08/09/2012:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM4A88TD-M/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

tags: added: trusty

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Ubuntu-QC-1, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad:
Ubuntu Kernel Team:
Ubuntu Community:

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:

tags: added: bot-stop-nagging
removed: apport-collected bot-stop-nagging. slow trusty usb
Simplexion (simplexion) wrote :

I have a brand new motherboard and the issue still remains. I guess I will have to reinstall Ubuntu. I haven't had to reinstall it in about 5 years. So annoying.

SImplexion, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad:
Ubuntu Kernel Team:
Ubuntu Community:

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:

Ken Sharp (kennybobs) wrote :

Is this not fixed now? It was fixed upstream a while ago.

Damir Butmir (d4m1r2) wrote :

Still not fixed under Ubuntu 12.04 LTS x64 at least, even with the latest kernel....

Linux damir-macbook 3.13.0-45-generic #74~precise1-Ubuntu SMP Thu Jan 15 20:21:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Writing to a 16GB USB 2.0 stick (NTFS) goes at ~17MB/s while under Windows (same amount, machine, stick, everything) goes at 30+MB/s....

Damir Butmir, it would help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

Displaying first 40 and last 40 comments. View all 135 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.