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

Bug #500069 reported by sbec67 on 2009-12-24
644
This bug affects 141 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
High
linux (Fedora)
Won't Fix
High
linux (Ubuntu)
High
Unassigned
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
sbec@Diamant:~$

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 ;-(

Regards

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.

Thanks!

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
Simon

AplayDevices:
 **** 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
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC272 Analog [ALC272 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: pablo 1645 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 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
MachineType: SAMSUNG ELECTRONICS CO., LTD. NC10
Package: linux (not installed)
ProcCmdLine: root=UUID=5f964d43-b8cd-4886-a6e5-80376a5eb7b5 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=es_ES.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-17-generic N/A
 linux-firmware 1.25
RfKill:
 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:

dmi.bios.date: 09/08/2009
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: 11CA.M015.20090908.RHU
dmi.board.name: 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:
dmi.product.name: NC10
dmi.product.version: Not Applicable
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

tags: added: apport-collected

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.
Regards
Sbec

Simon Holm (odie-cs) wrote :

sbec67:
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 https://help.ubuntu.com/community/DiskPerformance 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:
http://ubuntuforums.org/showthread.php?t=1306333

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
Regards

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

Hello,

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

Description of problem:
I was trying to copy a very large file (3.3 Gb iso of Fedora x86_64) to a flash drive, and after copying a few hundred megabytes (e.g. 300MB) the copying speed slowed down to around 500KB/s and it was going even lower gradually. It was really unacceptable (the remaining time was climbing up to over 1 hour and 30 minutes using nautilus to copy the file). I've tried different flash drives and different USB ports of my laptop, and there was no significant difference. I encountered this slow copying in past, but usually I've ignored it as the files was not that big. But this time it was really disappointing and I've decided to see why it is so slow.

iotop showed slow disk writes (it was often 0, jumping to some low values (usually less than 500KB/s) and lowering to 0 again) and lots of IO waiting time for pdflush. After searching a little in the Internet, I found that playing with dirty_ratio and dirty_background_ratio kernel parameters in /proc/sys/vm/ might help.

First, I lowered the dirty_background_ratio to 1 (default value is 10), and the disk write speed jumped to around 2.5 MB/s for awhile (around 1 or a few minutes) and then the speed dropped again to around 0.

Finally, I lowered the dirty_ratio parameter to 10 (default value is 20), and it resulted in a constant 2.5MB/s to 3MB/s disk read (from hard disk) and write (to usb disk) speed to the end of the copy operation (which took a few minutes rather than more than an hour!).

The problem is so weird and unacceptable.

As it might help, I have 1.5GBs of RAM and at the time of copy around 44% of it was used by running programs.

Version-Release number of selected component (if applicable):
kernel-2.6.31.12-174.2.3.fc12.x86_64
but the problem was observed in previous F12 kernels too.

How reproducible:
100% in my few tests.

Steps to Reproduce:
1. Start copying a large file (e.g. over 2GB) to a regular USB flash drive. Use a single big file rather than many small files.
2. Observe the copying speed

Actual results:
Very slow copying operation (around 450KB/s in my case)

Expected results:
Regular copy speed (2.5MB/s seems to be possible with my hardware and the mentioned settings)

Additional info:
I don't know if it helps but: the source file was on an NTFS mounted partition, and both of the partitions were mounted by Gnome.
The problem might be related to the mount options used by gnome, but doesn't seem to be related to nautilus. Since I get slow speeds even using dd to copy the file.

sbec67 (sbec) wrote :

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

Rgerads
Sbec

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 http://ubuntuforums.org/showthread.php?t=1306333&page=12

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

Go to http://kernel.ubuntu.com/~kernel-ppa/mainline 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.

@blahde

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

Regards.

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.
Regards.

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.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in linux (Ubuntu):
assignee: Colin King (colin-king) → nobody

This bug is still present (in version F14):
2.6.35.6-48.fc14.x86_64

Copying big files is at beginning fast but gradually becoming slower and then stops at the end of the file, after a few moments (minutes or so) it continue and finally finish.

What should I do to gather more details?

fgr (f-gritsch) wrote :

uo, this bug has a very long history....
are you shure that this is the same problem that I hvae reported? because with 10.10 I did not have the problem, the read performance was as good as it is now in windows 7 on the same pc. It slowed down just after the update to 11.04!

What information do you need, to can investigate the problem? Can anybody give a hint?

Badcam (kiwicameron+launchpad) wrote :

I haven't had this issue since 10.10
Mint 10 is awesome.

I am Nastya, 22 y.o,
I am looking for man to have a strong family.
Please let me know if you are ready :)))
I am on-line now,
my profile is here:

http://sonya201010.com.ua/?message_from=Nastya

Note!
New free services! check info at the site!
( to unsubscribe - please, click link and enter e-mail address .)

OT: Is there a way to report spam as in the message above?

nomnex (nomnex) wrote :

Yes, send a message to Nastya... Joke aside, tell Maxime to change is password!

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix

Ubuntu team won't fix this bug as it affects all distributions.

Take a look at this, probably might help:

http://mailman.archlinux.org/pipermail/arch-general/2010-June/014470.html

This problem still persists in Fedora 16. Again, lowering dirty_ratio and dirty_background_ratio to 2 and 1 respectively (instead of 20 and 10) resulted in constant 4.5 MB/s speed while copying with the default settings the speed was going down... (I stopped it when it was around 1.5MB/s).

This is probably going to get fixed for real in 3.3, but there's a hack that might make things at least slightly better until then. I'll throw into the next 16 build.

oh, actually we have that hack in f16 since 3.1.2-0.rc1.1

IIRC, I experienced the problem on kernel-3.1.2-1.fc16.x86_64 :(
I hope that it'll be at least really fixed in 3.3.

Adam Porter (alphapapa) wrote :

This article explains that the problem is the Transparent Huge Pages feature of the kernel: http://lwn.net/Articles/467328/

According to this, some of the fixes are in 3.2, and some in 3.3: https://bugzilla.kernel.org/show_bug.cgi?id=12309#c563

This is a horrible bug for desktop use, and for some server use as well. This should be a top priority bug. Ubuntu needs to backport the fixes or consider disabling Transparent Huge Pages in desktop kernels.

Having the entire system freeze for minutes at a time and file copy operations take hours instead of minutes is entirely unacceptable behavior. As Corbet said, it's enough to make users consider the benefits of proprietary operating systems (i.e. Bug #1).

P.S. Automated scripts marking critically important bugs as WONTFIX is also unacceptable behavior.

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

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-12.20
Adam Porter (alphapapa) wrote :

As I noted, the kernel bugzilla says that some of the fixes for this bug will be in 3.3. Since the request was to test 3.2, I think it's reasonable to assume that 3.2 will not solve the bug, and that fixes will need to be backported to 3.2. And even if 3.2 were to completely address it, the fixes would still need to be backported to earlier, supported kernels, because this is a very serious bug.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: bot-stop-nagging.
Brad Figg (brad-figg) wrote :

The upstream patcheset has been applied to a version of the Precise kernel. For those wishing to give it a spin to see if it addresses the issue for them you will find built versions at:

http://people.canonical.com/~bradf/lp500069/

Changed in linux:
importance: Unknown → High
status: Unknown → Confirmed
Rui Barreiros (rbarreiros) wrote :

I'm having this problem for more than a year, and it's terribly annoying.

Only of late I managed to focus on trying to get rid of this since my backup ammount of data done weekly is getting huge and I have to put the desktop doing his backups at night only to arrive sometimes at the morning with it still running, and forced to cancel to be able to work.

Indeed as Adam said, this is unacceptable, and this is comming from a 12+ years of using linux only as my OS and being a huge linux advocate.

I'm going to try today this 3.2 kernel and see how it goes, more news later.

Best regards,

P.S.
My disappointment is not towards ubuntu as I believe ubuntu actually brought linux to a wider range of users and inovated more in linux than any other distro, but mainly towards kernel development (which I gave up contributing at all due to most of their elitist behaviour).

Rui Barreiros (rbarreiros) wrote :

Hi there,

As promised, I'm right now using 3.2 but on Ocelot, and, it apparently the bug is fixed, as I'm writing this, I'm copying/deleting about 5gb on an external usb2.0 HDD and had no system lock ups yet and speed is acceptable.

I couldn't install due to dependency issues obviously linux-tools and linux-headers (although I think linux-headers-3.2.0-13-generic_3.2.0-13.21~lp500069_amd64.deb has a circular dependency, maybe it's a bug ?)

I'll try to build all this packages here in ocelot and start using them to better test it.

Best regards,

bth73 (bth1969) wrote :

Wow, this sucks. I too am having the same problem with mint 9x64. How is it that such basic, basic functions can be handled so badly? Ubuntu now sucks and it seems that Mint is no better. Taking over 2 hours to transfer 7.3gigs to a 8gig stick (fat32). USB2 not USB1. What is up? Will we ever have a OS that just works? Sh%^ I'm about to go buy Win 7 or start beta testing Win8 to find a system that can do BASIC FUNCTIONS, IE: open files, manipulate them and move and transfer to different hard drives.
TRANSFERRING AT THE BLAZING SPEED OF 930 KB/SEC.
1TB TRANSFER TO NEW WD 1TB 2.5" USB DRIVE TOOK OVER 19HRS!
WAY TO GO PROGRAMMERS! REALLY YOU SHOULD BE PROUD.

bth73 (bth1969) wrote :

It is like designing a car that the wheels and tires fall off every 2 miles. The radio works and the motor runs fine, BUT don't try to go anywhere cause there is no tires or wheels - just axles. Or better yet an airplane with no wings.

bth73 (bth1969) wrote :

740 KB/sec.
 sudo apt-get upgrade only hangs with no progress. Probably would only BORK the system anyway.

FriedChicken (domlyons) wrote :

Linux 3.2 contains some fixes and Linux 3.3 is said to finaly fix it.

@bth73:
Spamming is no solution.

There were further fixes for this issue in 3.2. Is this problem still there on 3.2.7 or newer?

If anyone is willing to test 3.3-rc5, this build should also contain the fixes Dave mentioned:

http://koji.fedoraproject.org/koji/buildinfo?buildID=301620

Janusz (yorashtan2) wrote :

I discovered that using the noop scheduler helps. However, they seem to have finally fixed this bug.

I'm on Ubuntu 11.10 with 3.3.0-rc5 and these are my results (copying from an external usb drive):

rsync:
   733507584 100% 30.89MB/s 0:00:22 (xfer#1, to-check=0/1)

Somebody should verify with 3.2 as I guess this will be the kernel that will ship with Precise.

Janusz (yorashtan2) wrote :

I did that test with cfq.

Damir Butmir (d4m1r2) wrote :

This is still an issue in Ubuntu 11.10 (32 bit) with the most up to date kernel provided through update manager:

Linux Damir-Ubuntu 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 athlon i386 GNU/Linux

I do not get transfer speeds faster than 7-8mb/s to a 8GB external USB stick....I cannot believe this issue is so old and it hasn't been addressed yet, this is a critical bug!!!

tags: added: kernel-fixed-upstream

I filled several bugs almost 1 year ago and, today I still have the same
problem.
Even with the latest 3.2.5 kernel
Therefore, it seems that reporting problems is useless. That's my point of
view.
I think that slow usb transfer must be a highly critical bug, and most of
the effort should be put on it.
I have another bug pending to be solved (not critical), and there is no
solution yet.

Sorry for my English.
Bye!
 El 09/03/2012 18:12, "Joseph Salisbury" <email address hidden>
escribió:

> ** Tags added: kernel-fixed-upstream
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (477843).
> https://bugs.launchpad.net/bugs/500069
>
> Title:
> USB file transfer causes system freezes; ops take hours instead of
> minutes
>
> Status in The Linux Kernel:
> Confirmed
> Status in “linux” package in Ubuntu:
> Confirmed
> Status in “linux” package in Fedora:
> Unknown
>
> 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
> sbec@Diamant:~$
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/500069/+subscriptions
>

Changed in linux (Ubuntu):
status: Confirmed → Triaged

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Ming Lei (tom-leiming) wrote :

Anyway, if you still have this kind of slow usb problem, please
post the usbmon trace(see guide in below link), otherwise it is
difficult to say where is wrong.

[1], http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt

Thanks,

On Sat, Mar 10, 2012 at 3:08 AM, adri58 <email address hidden> wrote:
> I filled several bugs almost 1 year ago and, today I still have the same
> problem.
> Even with the latest 3.2.5 kernel
> Therefore, it seems that reporting problems is useless. That's my point of
> view.
> I think that slow usb transfer must be a highly critical bug, and most of
> the effort should be put on it.
> I have another bug pending to be solved (not critical), and there is no
> solution yet.
>
> Sorry for my English.

adri58 (adri58) wrote :
Download full text (6.9 KiB)

USBMON trace:

T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.02
S: Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.02
S: Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.02
S: Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 41/900 us ( 5%), #Int= 3, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.02
S: Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1a.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c050 Rev=27.20
S: Manufacturer=Logitech
S: Product=USB-PS/2 Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 5 Ivl=10ms

T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=045e ProdID=00dd Rev= 1.73
S: Manufacturer=Microsoft
S: Product=Comfort Curve Keyboard 2000
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms

T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 3.02
S: Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=0000:00:1a.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00...

Read more...

Ming Lei (tom-leiming) wrote :
Download full text (5.1 KiB)

On Sat, Mar 31, 2012 at 9:32 PM, adri58 <email address hidden> wrote:
> USBMON trace:

The below is not usbmon trace at all, please read the doc in the link below

        http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt

then post out your usbmon trace.

Also you can refer to LP624510 about how to do it.

       https://bugs.launchpad.net/bugs/624510

Thanks,

>
> T:  Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 2
> B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1d6b ProdID=0001 Rev= 3.02
> S:  Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
> S:  Product=UHCI Host Controller
> S:  SerialNumber=0000:00:1d.2
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>
> T:  Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 2
> B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1d6b ProdID=0001 Rev= 3.02
> S:  Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
> S:  Product=UHCI Host Controller
> S:  SerialNumber=0000:00:1d.1
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>
> T:  Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 2
> B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1d6b ProdID=0001 Rev= 3.02
> S:  Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
> S:  Product=UHCI Host Controller
> S:  SerialNumber=0000:00:1d.0
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>
> T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 2
> B:  Alloc= 41/900 us ( 5%), #Int=  3, #Iso=  0
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1d6b ProdID=0001 Rev= 3.02
> S:  Manufacturer=Linux 3.2.0-2-amd64 uhci_hcd
> S:  Product=UHCI Host Controller
> S:  SerialNumber=0000:00:1a.2
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
>
> T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=1.5  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=046d ProdID=c050 Rev=27.20
> S:  Manufacturer=Logitech
> S:  Product=USB-PS/2 Optical Mouse
> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
> E:  Ad=81(I) Atr=03(Int.) MxPS=   5 Ivl=10ms
>
> T:  Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=1.5  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=045e ProdID=00dd Rev= 1.73
> S:  Manufacturer=Microsoft
> S:  Product=Comfort Curve Keyboard 2000
> C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
> E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID...

Read more...

elatllat (elatllat) wrote :

maybe Ming is trying to say, do this:

1) started a capture using this command:
 cat /sys/kernel/debug/usb/usbmon/1u > /tmp/1u.mon.out

2) connect the external drive

3) copy a file to the external drive

4) kill the capture with CTRL-C

5) zip and add attach 1u.mon.out.zip here.

Ming Lei (tom-leiming) wrote :

On Sat, Mar 31, 2012 at 11:55 PM, Dmole <email address hidden> wrote:
> maybe Ming is trying to say, do this:
>
> 1) started a capture using this command:
>  cat /sys/kernel/debug/usb/usbmon/1u > /tmp/1u.mon.out
>
> 2) connect the external drive
>
> 3) copy a file to the external drive
>
> 4) kill the capture with CTRL-C
>
> 5) zip and add attach 1u.mon.out.zip here.

Exactly, that is just what I wanted.

Thanks,

adri58 (adri58) wrote :
  • 1u.mon.out Edit (4.2 MiB, application/octet-stream; name="1u.mon.out")

Here's the file

2012/4/1 Ming Lei <email address hidden>

> cat /sys/kernel/debug/usb/usbmon/1u > /tmp/1u.mon.out
>

Ming Lei (tom-leiming) wrote :

On Sun, Apr 1, 2012 at 1:15 PM, adri58 <email address hidden> wrote:
https://bugs.launchpad.net/bugs/500069/+attachment/2980204/+files/1u.mon.out

adri58, thanks for your post.

From your usbmon trace, I found that it may take about ~22ms averagely
to complete writing 120KB[1] into your usb mass storage, so the max write
performance is about 5.3MB/sec, for example:

/*send WRITE cmd from host to usb mass storage device*/
ffff880037674d40 905709519 S Bo:2:007:2 -115 31 = 55534243 9f080000
00e00100 00000a2a 00000457 c60000f0 00000000 000000
ffff880037674d40 905709611 C Bo:2:007:2 0 31 >

/*write 120KB data to usb mass storage device*/
ffff8801139ac080 905709619 S Bo:2:007:2 -115 122880 = 831683e5
c00e55d7 83e9c00e 95c1f2bf fb0300c6 81908c93 c98144a9 5980441a
ffff8801139ac080 905731863 C Bo:2:007:2 0 122880 >

/*read the status of writing operation*/
ffff880037674d40 905731871 S Bi:2:007:1 -115 13 <
ffff880037674d40 905733112 C Bi:2:007:1 0 13 = 55534253 9f080000 00000000 00

The above 3 steps are an intact procedures to write 120KB into usb
mass storage device.

Also looks no any error information is found in your trace, so your problem
should be that the usb mass storage is slow device, especially wrt. writing
performance.

I suggest you to do some tests on windows to see if you can get same
performance with ubuntu.

[1], 120KB is the max transfer unit per scsi command, also it is the most
frequent transfer unit in linux usb mass storage read/write.

Thanks
--
Ming Lei

adri58 (adri58) wrote :
Download full text (3.1 KiB)

In Windows I have no problem at all. So, there must be something wrong with
the Linux kernel

2012/4/2 Ming Lei <email address hidden>

> On Sun, Apr 1, 2012 at 1:15 PM, adri58 <email address hidden> wrote:
>
> https://bugs.launchpad.net/bugs/500069/+attachment/2980204/+files/1u.mon.out
>
> adri58, thanks for your post.
>
> >From your usbmon trace, I found that it may take about ~22ms averagely
> to complete writing 120KB[1] into your usb mass storage, so the max write
> performance is about 5.3MB/sec, for example:
>
> /*send WRITE cmd from host to usb mass storage device*/
> ffff880037674d40 905709519 S Bo:2:007:2 -115 31 = 55534243 9f080000
> 00e00100 00000a2a 00000457 c60000f0 00000000 000000
> ffff880037674d40 905709611 C Bo:2:007:2 0 31 >
>
> /*write 120KB data to usb mass storage device*/
> ffff8801139ac080 905709619 S Bo:2:007:2 -115 122880 = 831683e5
> c00e55d7 83e9c00e 95c1f2bf fb0300c6 81908c93 c98144a9 5980441a
> ffff8801139ac080 905731863 C Bo:2:007:2 0 122880 >
>
> /*read the status of writing operation*/
> ffff880037674d40 905731871 S Bi:2:007:1 -115 13 <
> ffff880037674d40 905733112 C Bi:2:007:1 0 13 = 55534253 9f080000 00000000
> 00
>
> The above 3 steps are an intact procedures to write 120KB into usb
> mass storage device.
>
> Also looks no any error information is found in your trace, so your problem
> should be that the usb mass storage is slow device, especially wrt. writing
> performance.
>
> I suggest you to do some tests on windows to see if you can get same
> performance with ubuntu.
>
> [1], 120KB is the max transfer unit per scsi command, also it is the most
> frequent transfer unit in linux usb mass storage read/write.
>
> Thanks
> --
> Ming Lei
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (477843).
> https://bugs.launchpad.net/bugs/500069
>
> Title:
> USB file transfer causes system freezes; ops take hours instead of
> minutes
>
> Status in The Linux Kernel:
> Confirmed
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> 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
> sbec@Diamant:~$
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/500069/+subscri...

Read more...

Ming Lei (tom-leiming) wrote :

On Mon, Apr 2, 2012 at 10:28 PM, adri58 <email address hidden> wrote:
> In Windows I have no problem at all.

OK, so what is your problem in linux? just you fell that the writing
is very slow?
or USB file transfer may cause system freezes?

> So, there must be something wrong with
> the Linux kernel

Could you post output of the below commands on your effected machine?

        uname -a
        lsusb -vv #plug your usb mass storage into machine
        lcpci -vv -n

Thanks
--
Ming Lei

elatllat (elatllat) wrote :
Download full text (3.2 KiB)

USB 1 is 001.5 MB/s
USB 2 is 060.0 MB/s
USB 3 is 625.0 MB/s

adri58 is getting 5.3 MB/s, I would bet that is the max speed of his device.
But if not please post the output of a disk speed testing tool from some other OS.

Speed tests showing how slow flash drives are:

---------------------------------------------------------------------------------------------------------------------------
--flash fat32 drive

Darwin imac 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64

writing:
1024+0 records in
1024+0 records out
102400000 bytes transferred in 32.315127 secs (3168795 bytes/sec)

reading:
1024+0 records in
1024+0 records out
102400000 bytes transferred in 3.597781 secs (28461989 bytes/sec)

---------------------------------------------------------------------------------------------------------------------------
--flash fat32 drive

Linux ubuntu 3.2.0-20-generic-pae #33-Ubuntu SMP Tue Mar 27 17:05:18 UTC 2012 i686 i686 i386 GNU/Linux

writing:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 47.9621 s, 2.1 MB/s

reading:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 3.9149 s, 26.2 MB/s

---------------------------------------------------------------------------------------------------------------------------
--sata ext4 drive

Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC 2012 i686 GNU/Linux

writing:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 0.759231 s, 135 MB/s

reading:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 1.74171 s, 58.8 MB/s

---------------------------------------------------------------------------------------------------------------------------
--usb ntfs drive

Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC 2012 i686 GNU/Linux

writing:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 3.08867 s, 33.2 MB/s

reading:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 3.27496 s, 31.3 MB/s

---------------------------------------------------------------------------------------------------------------------------
--3 usb lvm dm_crypt ext4 drives (dm_crypt is messing with the write speed here)

Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC 2012 i686 GNU/Linux

writing:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 0.463585 s, 221 MB/s

reading:
1024+0 records in
1024+0 records out
102400000 bytes (102 MB) copied, 3.04551 s, 33.6 MB/s

---------------------------------------------------------------------------------------------------------------------------
--the test used:

#!/bin/bash

#
# test_drive_speed.sh
#

OUT=./file1G.tmp
uname -a
echo "spin you right round" >$OUT;
sleep 1
echo -e "\nwriting:"
if [ "$1" == "-u" ]; then
 dd if=/dev/urandom of=/dev/shm/$OUT bs=100000 count=1024 >/dev/null 2>&1
 dd if=/dev/shm/$OUT of=$OUT bs=100000 count=1024
 rm /dev/shm/$OUT;
else
 dd if=/dev/zero of=$OUT bs=100000 count=1024
fi
sync
W=$(which purge);
if [ "$W" == "" ] ; then
 sudo echo 3 > /proc/sys/vm/drop_caches;
else
 purge;
fi
sleep 1
echo...

Read more...

adri58 (adri58) wrote :
  • lspci Edit (13.1 KiB, application/octet-stream; name=lspci)
  • lsusb Edit (19.3 KiB, application/octet-stream; name=lsusb)

First of all, thanks everybody for helping me with this problem.
When trying to transfer big files (>1GB) the system freezes until it
finishes. Anyway, speed is really slow comparing to windows:

uname -a

Linux adrian-PC 3.2.0-2-amd64 #1 SMP Tue Mar 20 18:36:37 UTC 2012 x86_64
GNU/Linux

I also attach the two outputs you asked for.

2012/4/2 Ming Lei <email address hidden>

> On Mon, Apr 2, 2012 at 10:28 PM, adri58 <email address hidden> wrote:
> > In Windows I have no problem at all.
>
> OK, so what is your problem in linux? just you fell that the writing
> is very slow?
> or USB file transfer may cause system freezes?
>
> > So, there must be something wrong with
> > the Linux kernel
>
> Could you post output of the below commands on your effected machine?
>
> uname -a
> lsusb -vv #plug your usb mass storage into machine
> lcpci -vv -n
>
> Thanks
> --
> Ming Lei
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (477843).
> https://bugs.launchpad.net/bugs/500069
>
> Title:
> USB file transfer causes system freezes; ops take hours instead of
> minutes
>
> Status in The Linux Kernel:
> Confirmed
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> 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
> sbec@Diamant:~$
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/500069/+subscriptions
>

adri58 (adri58) wrote :
Download full text (5.4 KiB)

And the output of the speed test

Linux adrian-PC 3.2.0-2-amd64 #1 SMP Tue Mar 20 18:36:37 UTC 2012 x86_64
GNU/Linux

writing:
1024+0 registros leídos
1024+0 registros escritos
102400000 bytes (102 MB) copiados, 0,315309 s, 325 MB/s
./script: línea 22: /proc/sys/vm/drop_caches: Permiso denegado

reading:
1024+0 registros leídos
1024+0 registros escritos
102400000 bytes (102 MB) copiados, 0,0303001 s, 3,4 GB/s

Anyway, I'll test it under Windows

2012/4/2 Dmole <email address hidden>

> USB 1 is 001.5 MB/s
> USB 2 is 060.0 MB/s
> USB 3 is 625.0 MB/s
>
> adri58 is getting 5.3 MB/s, I would bet that is the max speed of his
> device.
> But if not please post the output of a disk speed testing tool from some
> other OS.
>
> Speed tests showing how slow flash drives are:
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------
> --flash fat32 drive
>
> Darwin imac 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST
> 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
>
> writing:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes transferred in 32.315127 secs (3168795 bytes/sec)
>
> reading:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes transferred in 3.597781 secs (28461989 bytes/sec)
>
>
> ---------------------------------------------------------------------------------------------------------------------------
> --flash fat32 drive
>
> Linux ubuntu 3.2.0-20-generic-pae #33-Ubuntu SMP Tue Mar 27 17:05:18 UTC
> 2012 i686 i686 i386 GNU/Linux
>
> writing:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 47.9621 s, 2.1 MB/s
>
> reading:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 3.9149 s, 26.2 MB/s
>
>
> ---------------------------------------------------------------------------------------------------------------------------
> --sata ext4 drive
>
> Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC
> 2012 i686 GNU/Linux
>
> writing:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 0.759231 s, 135 MB/s
>
> reading:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 1.74171 s, 58.8 MB/s
>
>
>
> ---------------------------------------------------------------------------------------------------------------------------
> --usb ntfs drive
>
> Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC
> 2012 i686 GNU/Linux
>
> writing:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 3.08867 s, 33.2 MB/s
>
> reading:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 3.27496 s, 31.3 MB/s
>
>
> ---------------------------------------------------------------------------------------------------------------------------
> --3 usb lvm dm_crypt ext4 drives (dm_crypt is messing with the write speed
> here)
>
> Linux ubuntu 2.6.32-39-generic #86-Ubuntu SMP Mon Feb 13 21:47:32 UTC
> 2012 i686 GNU/Linux
>
> writing:
> 1024+0 records in
> 1024+0 records out
> 102400000 bytes (102 MB) copied, 0.463585 s, 221 MB/s
>
> reading:
> 1024+0 records in
> 1024+0 records out
> 102400000 ...

Read more...

elatllat (elatllat) wrote :

Hi Adrian,

You need to run that script as root for it to work
(3,4 GB/s is your RAM speed not your disk speed)
also cd to your USB drive before running it.

Marius B. Kotsbak (mariusko) wrote :

Are you sure that this is not caused by the USB media mounted with "sync" option? (check with the "mount" command). I had the problem that Ubuntu mounted with sync and experienced this behavior.

adri58 (adri58) wrote :

No no, I checked that several times

2012/4/2 Marius Kotsbak <email address hidden>

> Are you sure that this is not caused by the USB media mounted with
> "sync" option? (check with the "mount" command). I had the problem that
> Ubuntu mounted with sync and experienced this behavior.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (477843).
> https://bugs.launchpad.net/bugs/500069
>
> Title:
> USB file transfer causes system freezes; ops take hours instead of
> minutes
>
> Status in The Linux Kernel:
> Confirmed
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> 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
> sbec@Diamant:~$
>
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/500069/+subscriptions
>

adri58 (adri58) wrote :

Script run as root from the USB drive

Linux adrian-PC 3.2.0-2-amd64 #1 SMP Tue Mar 20 18:36:37 UTC 2012 x86_64
GNU/Linux
-e
writing:
/home/adrian/script: 12: [: unexpected operator
1024+0 registros leídos
1024+0 registros escritos
102400000 bytes (102 MB) copiados, 14,9117 s, 6,9 MB/s
/home/adrian/script: 21: [: unexpected operator
/home/adrian/script: 24: /home/adrian/script: purge: not found
-e
reading:
1024+0 registros leídos
1024+0 registros escritos
102400000 bytes (102 MB) copiados, 0,0297004 s, 3,4 GB/s

2012/4/2 Adrián Arévalo Tirado <email address hidden>

> No no, I checked that several times
>
> 2012/4/2 Marius Kotsbak <email address hidden>
>
>> Are you sure that this is not caused by the USB media mounted with
>> "sync" option? (check with the "mount" command). I had the problem that
>> Ubuntu mounted with sync and experienced this behavior.
>>
>> --
>> You received this bug notification because you are subscribed to a
>> duplicate bug report (477843).
>> https://bugs.launchpad.net/bugs/500069
>>
>> Title:
>> USB file transfer causes system freezes; ops take hours instead of
>> minutes
>>
>> Status in The Linux Kernel:
>> Confirmed
>> Status in “linux” package in Ubuntu:
>> Triaged
>> Status in “linux” package in Fedora:
>> Unknown
>>
>> 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
>> sbec@Diamant:~$
>>
>> 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
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/linux/+bug/500069/+subscriptions
>>
>
>

Ming Lei (tom-leiming) wrote :

On Tue, Apr 3, 2012 at 2:47 AM, adri58 <email address hidden> wrote:
> First of all, thanks everybody for helping me with this problem.
> When trying to transfer big files (>1GB) the system freezes until it
> finishes. Anyway, speed is really slow comparing to windows:

From the usbmon trace you posted, we can find the writing is slowly:
complete writing more than 700MB into usb mass storage device in
about 260sec.

So firstly, it is just very slow, and nothing to do with system freezes
(you can do other things when the transfer is ongoing)

Also could you make sure if you can get better writing performance
on windows in the same machine with the same usb mass storage
device?

Thanks
--
Ming Lei

philinux (philcb) wrote :

I've just tested this in Precise. Copy and pasting a 734MB iso from internal drive to second internal drive took less than ten seconds.

Copying same iso to 4gig usb stick started of well at about 15mb/sec and has now slowed to 2.8mb/sec

The copy is still not finished as I write this. I'ts taken about 3 mins to copy the iso to usb.

System does not freeze though.

elatllat (elatllat) wrote :

philinux and adri58, this bug will never get fixed if you guys don't do a proper test.

You can't compare the speed of a disk drive to a usb flash stick.

1) You have to use the same disk internaly then over USB, or the same external on 2 OSes.
2) You have to provide quantitative numbers using a standard method.

My tests show that there is no problem on the current or the next LTS,
you guys have not run any "scientific" tests,
and AFAIK this bug report should be closed.

philinux (philcb) wrote :

@Dmole.

In my case the device is a little 4 gig USB stick. You cannot test that internally.

This bug has been a bain for years. The copy starts good then progressively slows down to a crawl as has been reported many times.

In windows this does not happen. Therefore kernel maybe reason

If you have a test for me to do on my USB stick I'm more than willing to participate.

I even tried the mainlone kernel once. As suggested a while back in this bug.

elatllat (elatllat) wrote :

@philinux,

You can't buy a 15mb/sec usb stick.
For all we know the slowness you are experiencing could be due to it being formatted as NTFS or just a slow flash drive.
3MB/s is the expected speed of a flash drive, anything more then that can likely be attributed to compression / caching / delayed write settings.
(That's why the SDHC classes were introduced http://www.sakoman.com/OMAP/microsd-card-perfomance-test-results.html)

You said that windows was "about" 7MB/s and Linux was "about" 3MB/s
You need to post the results of a disk benchmarking tool on the same drive from both OSes.
(I have no recommendations for what windows benchmarking tool to use.)

elatllat (elatllat) wrote :

@philinux, this might work for you though: http://www.iozone.org/src/current/IozoneSetup.zip

elatllat (elatllat) wrote :

At this time:

There are UHS-1 "SDHC compatible" cards that claim read speeds of 90MB/s but you need custom hardware to get speeds above normal SDHC.

25MB/s is the max write speed for SDHC.

Class 4 is the max for micro/mini SDHC.

There are some 15MB/s usb sticks http://usbspeed.nirsoft.net/usb_drive_speed_summary.html?o=11

Torsten Bronger (bronger) wrote :

I observe a drop to 1/10th in writing speed if I switch from NTFS to FAT32 on an external USB disk. Is this related to this issue?

Adam Porter (alphapapa) wrote :

I think a proper test methodology on both Windows and Linux should basically be:

1. Start copy operation and start stopwatch.
2. As soon as the copy is finished on the screen, umount/"Safely
Remove" the drive.
3. Wait for activity light on USB drive to go out and stop stopwatch.

I'm not sure if this bug is truly fixed on Linux, either, but because
of write caching and buffering at different levels and differences in
OSes, any benchmark must take into account unmounting/removing the
drive, otherwise it's apples and oranges. The progress bars, they
lie!

On Fri, May 18, 2012 at 4:21 PM, Torsten Bronger
<email address hidden> wrote:
> I observe a drop to 1/10th in writing speed if I switch from NTFS to
> FAT32 on an external USB disk.  Is this related to this issue?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/500069
>
> Title:
>  USB file transfer causes system freezes; ops take hours instead of
>  minutes
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/500069/+subscriptions

Torsten Bronger (bronger) wrote :

I copied very large files with rsync. rsync prints the transfer rate on the screen, and in case of NTFS, it was the expected 10 MByte/s (I copied though 100MBit Ethernet on the USB disk), and in case of FAT32 it was 900 kByte/s. So, it was even more that a factor of 10 because for NTFS, the transfer was limited by the Ethernet.

Thus, FAT32 is definitely responsible for ridiculously slow writing on the USB disk on my Lubuntu 12.04. This surely is a bug. My question is whether this is covered by this bug report here.

Ming Lei (tom-leiming) wrote :

On Sun, May 20, 2012 at 2:07 AM, Torsten Bronger
<email address hidden> wrote:
> I copied very large files with rsync.  rsync prints the transfer rate on
> the screen, and in case of NTFS, it was the expected 10 MByte/s (I
> copied though 100MBit Ethernet on the USB disk), and in case of FAT32 it
> was 900 kByte/s.  So, it was even more that a factor of 10 because for
> NTFS, the transfer was limited by the Ethernet.
>
> Thus, FAT32 is definitely responsible for ridiculously slow writing on
> the USB disk on my Lubuntu 12.04.  This surely is a bug.  My question is
> whether this is covered by this bug report here.

Of course, the fat32 bug is not covered by this bug report because the bug
title is 'USB file transfer causes system freezes; ops take hours
instead of minutes'.

So suggest to submit a new bug entry for the fat32 bug.

Thanks,

Hallöchen!

Ming Lei writes:

> [...]
>
> Of course, the fat32 bug is not covered by this bug report because
> the bug title is 'USB file transfer causes system freezes; ops
> take hours instead of minutes'.

Well, bug #392089 "Slow USB transfer for FAT32" has been marked as a
duplicate of this one. However, the intriguing NTFS/FAT32
difference doesn't seem to play any role in this discussion.

Has anybody affected by this bug tried with a different filesystem
(if possible)?

Tschö,
Torsten.

--
Torsten Bronger Jabber ID: <email address hidden>
                                  or http://bronger-jmp.appspot.com

Changed in linux:
status: Confirmed → Fix Released

I have experienced very slow copying with 3.4.4-5.fc17.x86_64 when the number of files/the volume of the files to copy become large. Unfortunately, it didn't improve with the trick I mentioned in the report.

AO (aofrl10n) wrote :

I'm afraid this is not fixed in Ubuntu Quantal AMD64 with latest kernel 3.5.0-6. I'm transferring data to a Sansa Clip+,S internal storage, over 2Gb in this case, starting at over 20 Mo/s to end up below 1Mo/s. So whatever fixe was released did not get ride of the problem at all.

elatllat (elatllat) wrote :

Alain-OIivier Breysse: read the previous posts; provide proof.

Torsten Bronger (bronger) wrote :

What kind of proof?

Simplexion (simplexion) wrote :

I have now tried to duplicate this bug with ext2 on a usb drive. It occurs when transferring over about 1GB of data. It slows down pretty rapidly. Let me know what information is required.

elatllat (elatllat) wrote :

simplexion (simplexion)
Torsten Bronger (bronger)

If you'r not going to read the history and figure out how to
provide the results of a disk benchmarking tool on the exact same hardware from both an effected and unaffected, fully upgraded OS, then
please don't post.

# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change 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.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem.
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).

I should try to find a new problematic device and test (Under Fedora 17).

Experienced similar issue as comment #12. However I witnessed the following:
1. a normal copy by nautilus was going. The speed was around 2.9M/s and in iotop I saw this: in one update, a write operation around 3M/s happened, in the next 2 updates no read/write operation happened. This pattern was repeatedly happen in iotop.

2. I did the trick I mentioned above to force Linux to flush its caches. I saw a constant write operation in iotop from 3 to 6 M/s. nautilus stalled for a while until buffers were flushing. Unfortunately, I didn't see the final speed shown by nautilus. But considering iotop results, the speed should be better than normal case (2.9M/s)

3. I did another copy of another directory, but it was even slower than 2.9M/s. I undone my changes to kernel parameters and nautilus suddenly finished the copying (which actually copied into memory). I don't know if the actual write was faster or slower.

Unfortunately, I forgot to test with one big file rather than a number of small files. But considering what happened in number 2 above, I'd assume that Linux still needs to better manage its in-RAM buffer for slow USB devices.

Matthew (ruinairas1992) wrote :

@The People stating this is a falsely reported bug.

I really don't understand how someone can "not" notice the slowness of USB transfers....I wonder if anyone making these type of comments have used Windows in the last decade... I'm not trying to sound mean, but this is like talking to people with no common sense.

to reproduce this bug

*slap in a USB flash drive/SD card
*transfer a 600mb (or larger file) (maybe the Ubuntu image?)
*Take note of how long it took to transfer that
*Do this over and over with every type of format until you are blue in the face, it wont make a difference

repeat this on a Mac or a Windows machine...notice the drastic difference in speed....But yet it's the USB flash drives fault it's so slow *facepalm*

I don't know why this happens or how to fix this issue, but this is indeed a bug somewhere...

elatllat (elatllat) wrote :

@Matthew
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 :

@elatllat

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.
Results:
(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?

Well, I just discovered something about the new behavior. I found that sometimes, when I insert a flash disk, it is registered in a USB 1 bus rather than a USB 2 bus, and this is why it is slow. If I re-insert the disk (even in the same port), it might be recognized as a USB 2 device and so it'll be much faster.

Therefore, I think the original bug is already solved. I just wonder why sometimes the disks are registered as USB 1?!

Thanks

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.

Thanks,
--
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!

alexmex90 (alexmex90) wrote :

@garzie2000

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: http://askubuntu.com/questions/11277/usb-drive-speed-testing-app-with-test-options

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?

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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 https://www.kernel.org/doc/Documentation/vm/transhuge.txt 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 http://cdimage.ubuntu.com/daily-live/current/ .

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 https://wiki.ubuntu.com/KernelMainlineBuilds ? 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:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

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

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:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

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
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /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
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
RfKill:
 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
dmi.bios.date: 08/09/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1501
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 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:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

tags: added: trusty
AO (aofrl10n) wrote : AlsaInfo.txt

apport information

AO (aofrl10n) wrote : BootDmesg.txt

apport information

AO (aofrl10n) wrote : CRDA.txt

apport information

apport information

AO (aofrl10n) wrote : IwConfig.txt

apport information

AO (aofrl10n) wrote : Lspci.txt

apport information

AO (aofrl10n) wrote : Lsusb.txt

apport information

apport information

apport information

apport information

apport information

AO (aofrl10n) wrote : PulseList.txt

apport information

AO (aofrl10n) wrote : UdevDb.txt

apport information

AO (aofrl10n) wrote : UdevLog.txt

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: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

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

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

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: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

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

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

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.

This bug still exits in latest version. It's not only file of USB to HDD or vice versa. This bug occurs for any kind of large file copy.

System:
Ubuntu 15.10 64bit
Corei7
8GB RAM

shantanu saha, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

Dimitrenko (paviliong6) on 2017-07-04
Changed in linux (Ubuntu):
status: Incomplete → Fix Released
Changed in linux (Fedora):
importance: Unknown → High
status: Unknown → Won't Fix
Chris (chriswy27) wrote :

Was this bug actually fixed? The status shows Fix Released for Ubuntu with a last modified date of July 4 2017 by Dimitrenko (paviliong6). I don't see any updates as to what was corrected, and what version the fix will be put into?

Jeremy (son9ne-junk) wrote :

This bug still exists in 18.04.02. Over 20 minutes to transfer 2 GB is insane.USB and Network transfers are killing productivity. Hopefully this will be fixed this decade...

Brad Figg (brad-figg) on 2019-07-24
tags: added: cscc
To post a comment you must log in.
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.