Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159269 - usb memory stick data transfer is too slow
Summary: usb memory stick data transfer is too slow
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-01 09:17 UTC by Caner Baydemir
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-28 17:38:25 UTC

Attachments (Terms of Use)
dmesg output (deleted)
2005-06-01 11:53 UTC, Caner Baydemir
no flags Details
/var/log/messages file (deleted)
2005-06-01 11:55 UTC, Caner Baydemir
no flags Details

Description Caner Baydemir 2005-06-01 09:17:25 UTC
I'm using several USB memory stick's in FC4-test3. I attach the device and
system automatically mount it. I copy a file in USB memory stick to hard drive
is very fast. Well, it's ok. But i try copy a file in my hard drive to USB
memory stick is  VERY SLOW.

Example: file size is 790KB and transfer time is 45 minutes! I try copy the
kernel RPM (~14MB), system say, it will be finished in 13 Hours 50 Minutes. (at
last, i try the kernel-2.6.11-1.1366, but nothing changed...) it's too much
time, isn't it? I think something wrong in this kernel for usb. Any comment?

Comment 1 Dave Jones 2005-06-01 10:40:40 UTC
please attach the output of dmesg.

Comment 2 Caner Baydemir 2005-06-01 11:53:04 UTC
Created attachment 115023 [details]
dmesg output

i don't see any error messages...

Comment 3 Caner Baydemir 2005-06-01 11:55:49 UTC
Created attachment 115024 [details]
/var/log/messages file

and last 20 lines of /var/log/messages file

Comment 4 Alex Farkas 2005-06-10 11:09:40 UTC
At the risk of being a useless by-stander, I would like to add an observation
that may help:

I have noticed this behaviour since at least the vanilla 2.6.11.x kernel, but
not once the redhat patch set has been applied. i.e. If I build kernel
(say) and try my USB stick than the write speed is incredibly slow (a 40Mb file
takes 15-20 minutes).  However, once the redhat patches are applied to produce
the 2.6.11-1.27_FC3 kernel, then this problem disappears.

I have tried manually removing/replacing ehci/uhci etc. but it does not make a

Comment 5 Alex Farkas 2005-06-11 15:14:26 UTC
Addendum to my previous comment: Today I tested this issue with the development
kernels from redhat (2.6.11-1.1369 and 2.6.11-1.1381) rebuilt for my FC3 

These development kernels also exhibit the 'slow USB write' problem, so the 
proverbial "something" has changed between 2.6.11-1.27 and the later 
development kernels.  I have not had the time to collect logs just yet but if 
this bug is being pursued I will endeavour to log them here.

Comment 6 Pete Zaitcev 2005-06-11 21:05:38 UTC
I'd like to see /proc/partitions and /proc/mounts with the stick mounted.

I guess we can exclude iommu bouncing since it's a 32 bit kernel...
BTW, Is there a particular reason to run a 32 bit distribution on Opteron?

Comment 7 Alex Farkas 2005-06-13 05:45:31 UTC

Under both the working 2.6.11-1.27_FC3 and the not-working 2.6.11-1.1381_FC3 the
output is identical as shown below (hence I have only included the data once). 
I ran both tests on P3 and P4 (32 bit) platforms which are otherwise configured
identically in terms of installed software.

To run the tests, I booted to run level 3, inserted the USB stick and examined
the console output and the /proc/* files indicated above.

When the stick is inserted, the info displayed is:

SCSI subsystem initialized
  Vendor: USB 2.0   Model: Flash Disk        Rev: 0.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 2048000 512-byte hdwr sectors (1049 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
SCSI device sda: 2048000 512-byte hdwr sectors (1049 MB)
sda: Write Protect is off
sda: assuming drive cache: write through
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

Contents of /proc/partitions:

major minor  #blocks  name

   3     0  117220824 hda
   3     1  117218241 hda1
   3    64  156290904 hdb
   3    65   82381288 hdb1
   3    67          1 hdb3
   3    69    2040223 hdb5
   3    70   71866746 hdb6
   8     0    1024000 sda
   8     1    1022960 sda1

Contents of /proc/mounts:

rootfs / rootfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
none /dev tmpfs rw 0 0
/dev/root / ext3 rw 0 0
none /dev tmpfs rw 0 0
/proc /proc proc rw,nodiratime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
/sys /sys sysfs rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0

I can confirm again that it is only *writing* to the USB stick which is
extremely slow, and not reading.

Are there any source modules I could examine to help identify the cause of this

Comment 8 Pete Zaitcev 2005-06-13 07:34:23 UTC
I do not see /dev/sda1 mounted in that /proc/mounts.

Comment 9 Alex Farkas 2005-06-14 03:17:55 UTC
Apologies for my poor cut and paste (missed the last line).  I have transcribed 
this from my printout, hopefully without error... 

Please consider the following appended to /proc/mounts:

/dev/sda1 /media/ONEG vfat 
harset=utf8 0 0

[Note that ONEG is the label I applied to my USB stick]

Comment 10 Alex Farkas 2005-06-20 02:34:33 UTC
After seeking some additional help on the bugzilla (See BUGID 4747 
on if you are interested) I discovered that there was 
radically different behaviour between the usb-storage drivers of the two 
different kernels on the same FC3 platform.

Long story short: I tried the same experiments on *FC4* with the redhat 2.6.11-
1.1369 and the vanilla 2.6.12 kernel.... err... to my surprise the problem does 
not recur with the 2.6.12 version!

This would seem to indicate that on FC3, there may be some other interaction 
going on which causes this anomoly - e.g. some application, daemon, service 
etc. that has an allergic reaction to an unpatched kernel.

Some long nights ahead ;-)

Comment 11 Pete Zaitcev 2005-06-20 04:03:02 UTC
This is a valuable data point, actually. Unfortunately, the diff is
still too big between the two. Trying it with the stock base of 1.1369
would be helpful (it's something like 2.6.12-rc2 or about that, I'm
going to unpack the src.rpm and check).

Comment 12 Alex Farkas 2005-06-21 00:37:31 UTC
I've checked my trash can of built kernels and 
summarised below the results of my tests with respect
to the 2 distributions FC3 and FC4:

2.6.11-1.27	 -      working
2.6.11-1.35      -      working
2.6.11-1.1369    !      fails
2.6.11-1.1381    !      fails        *      fails        *      fails        *      fails
2.6.12-rc5       *      fails
2.6.12-rc6-git6  *      fails
2.6.12           *      fails

2.6.11-1.1369    -      working
2.6.11-1.1381    -      working
2.6.11-1.1385    -      working
2.6.12           *      working

-  = prebuilt fedora project rpm
!  = Rebuilt from redhat source
*  = 'vanilla' kernel

I am guessing the suggestion is to try the vanilla base of
2.6.11-1.1369 under *both* FC3 and FC4 to see what happens...

Makes good horse sense.  I will post back when I get a chance
to do the builds a bit later in the week.

Comment 13 Alex Farkas 2005-06-22 15:24:05 UTC
Kernel 2.6.11-1.1369's base is a tricky, cut down 2.6.12-rc5; after chopping
kernel-2.6.spec down to a bare minimum I built this on FC3 and FC4 - the
results above still hold:

    the USB stick works under FC4 but not under FC3.

I built the kernels seprately i.e. I built the FC3 variant on FC3 and the FC4 
variant on FC4 - I was not going to risk suffering Interesting Times by swapping 
binaries between distributions unless I hear from this forum that it is 
considered safe to do so!

What I mean is that the compilation environment is obviously different between 
the distributions - I don't know (yet) if there are any compiler related 
problems that may arise.

I'm kind of stuck here - I've built a tonne of kernels and don't seem to have 
made huge progress.  I will broaden the investigation to the surrounding 
software (e.g. try different shells, try different file system format on the 
stick, etc.) but I am open to suggestions!

Comment 14 Dave Jones 2005-06-27 23:31:34 UTC
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done


Comment 15 Alex Farkas 2005-06-28 00:25:47 UTC
Put simply, I have tried to replicate this problem under FC4 and have failed
(which is probably a good thing!)

I don't have the time to chase this up further - the solution seems to be
"upgrade to FC4".

Comment 16 Dave Jones 2005-06-28 17:38:25 UTC
Ok, that kernel is going to get backported to FC3 soon too, so it'll get fixed
there too. Thanks for testing.

I'll close this bug. If the original reporter can still reproduce it with the
latest FC4 kernel, please feel free to reopen this bug.

Thanks again.

Comment 17 Caner Baydemir 2005-06-30 11:58:21 UTC
ok, i tried fc4 and it seems everything is fine. But i don't see any progress
bar while writing. Writing is doing when umounting. so, it's writing in async
mode. right?

Comment 18 Pete Zaitcev 2005-06-30 16:42:08 UTC
That is correct, in fact kernels always did flush on unmount.
This is especially essintial for floppies.

However, changes in caching disciplines caused let you observe it
now with faster media.

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