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?
please attach the output of dmesg.
Created attachment 115023 [details] dmesg output i don't see any error messages...
Created attachment 115024 [details] /var/log/messages file and last 20 lines of /var/log/messages file
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 2.6.11.10 (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 difference.
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 platforms. 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.
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?
Pete, 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 phenomenon?
I do not see /dev/sda1 mounted in that /proc/mounts.
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 rw,sync,noatime,nodiratime,nosuid,nodev,fmask=0022,dmask=0022,codepage=cp437,ioc harset=utf8 0 0 [Note that ONEG is the label I applied to my USB stick]
After seeking some additional help on the kernel.org bugzilla (See BUGID 4747 on bugzilla.kernel.org 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 ;-)
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).
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: FC3 2.6.11-1.27 - working 2.6.11-1.35 - working 2.6.11-1.1369 ! fails 2.6.11-1.1381 ! fails 2.6.11.10 * fails 2.6.11.11 * fails 2.6.11.12 * fails 2.6.12-rc5 * fails 2.6.12-rc6-git6 * fails 2.6.12 * fails FC4 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.org 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.
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!
Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks.
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".
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.
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?
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.