Bug 246340 - [cable detect[: File transfers between disks or partition slower on F7 (8-40%) when compared to FC5 orFC6.
[cable detect[: File transfers between disks or partition slower on F7 (8-40%...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity high
: ---
: ---
Assigned To: Peter Martuccelli
Fedora Extras Quality Assurance
:
: 246337 246338 246339 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-30 14:15 EDT by Brad
Modified: 2009-07-14 14:15 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:15:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci (1.54 KB, text/plain)
2007-06-30 14:15 EDT, Brad
no flags Details

  None (edit)
Description Brad 2007-06-30 14:15:54 EDT
Description of problem:File transfers between disks or partition slower on F7
(8-40%) when compared to FC5 orFC6.


Version-Release number of selected component (if applicable):2.6.21-1.3228.fc7



How reproducible: Time transfer speeds of large (4.4gig+) files and compare to
legacy data.


Steps to Reproduce:
1.
2.
3.
  
Actual results: Slower Transfers


Expected results: Equivalent or faster transfers


Additional info:Rahula said to point this at you.
http://forums.fedoraforum.org/forum/showthread.php?t=159525&page=2&pp=15
Is the same on gnome, cli, and KDE. Applies to pata and sata devices. No known
errors spat out(checked tail -f /var/log/messages started prior to cp).
Available memory not a factor. Drive speeds check out fine via hardparm -tT.
Only checked on EXT3 file systems.
Comment 1 Brad 2007-06-30 14:15:54 EDT
Created attachment 158296 [details]
lspci
Comment 2 Darwin H. Webb 2007-06-30 15:25:39 EDT
/me/too - much slower

See page one of above
linkhttp://forums.fedoraforum.org/forum/showthread.php?t=159525&page=1&pp=15

# rpm -qa fedora-release
fedora-release-7-3
$ uname -a
Linux Ruthie-07 2.6.21-1.3240.fc8 #1 SMP Mon Jun 25 20:19:12 EDT 2007 i686 i686
i386 GNU/Linux
[darwinhwebb@Ruthie-07 ~]$ df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup71-LogVol71root
                      71069000   3187076  64213548   5% /
/dev/sda3               497861     30145    442012   7% /boot
tmpfs                   505340         0    505340   0% /dev/shm
/dev/mapper/VolGroup72-LogVol72home
                     468984864  11186532 433590972   3% /home
[darwinhwebb@Ruthie-07 ~]$ fdisk -L
bash: fdisk: command not found
[darwinhwebb@Ruthie-07 ~]$ su -
Password: 
[root@Ruthie-07 ~]# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        4865    39078081    7  HPFS/NTFS
/dev/sda2            4866        9730    39078112+   7  HPFS/NTFS
/dev/sda3            9731        9794      514080   83  Linux
/dev/sda4            9795       19457    77618047+   5  Extended
/dev/sda5            9795       19457    77618016   8e  Linux LVM

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Darwin
Comment 3 Chuck Ebbert 2007-07-06 14:22:40 EDT
*** Bug 246337 has been marked as a duplicate of this bug. ***
Comment 4 Chuck Ebbert 2007-07-06 14:23:11 EDT
*** Bug 246338 has been marked as a duplicate of this bug. ***
Comment 5 Chuck Ebbert 2007-07-06 14:23:49 EDT
*** Bug 246339 has been marked as a duplicate of this bug. ***
Comment 6 Chuck Ebbert 2007-07-06 14:30:38 EDT
Try a different IO scheduler. Either boot with kernel parameter:

   elevator=anticipatory

or try: 

   # echo "anticipatory" >/sys/block/<DEVICE>/queue/scheduler

where <DEVICE> is, e.g. sda.
Comment 7 Brad 2007-07-06 15:26:44 EDT
I used the echo method and changed both sda and sdb. No significant change in cp
times. hdparm -tT got slightly (probably insignificant) worse.
Comment 8 Micke 2007-07-11 15:19:24 EDT
FWIW, I just noted that the disks on my ATA100 controller were just as slow as
the one connected to the motherboard's ATA33. There is something strange/new in
the detection...
Jul  9 00:31:17 xyzzy kernel: ata3: PATA max UDMA/100 cmd 0x00012070 ctl 0x
000120a2 bmdma 0x000120c0 irq 11
Jul  9 00:31:17 xyzzy kernel: ata4: PATA max UDMA/100 cmd 0x00012078 ctl 0x
000120a6 bmdma 0x000120c8 irq 11
Jul  9 00:31:17 xyzzy kernel: scsi2 : pata_pdc202xx_old
Jul  9 00:31:17 xyzzy kernel: ata3.00: ata_hpa_resize 1: sectors = 32167296
0, hpa_sectors = 321672960
Jul  9 00:31:17 xyzzy kernel: ata3.00: ATA-6: HDS722516VLAT80, V34OA63A, ma
x UDMA/100
Jul  9 00:31:17 xyzzy kernel: ata3.00: 321672960 sectors, multi 16: LBA48
Jul  9 00:31:17 xyzzy kernel: ata3.01: ata_hpa_resize 1: sectors = 78142276
8, hpa_sectors = 781422768
Jul  9 00:31:17 xyzzy kernel: ata3.01: ATA-7: SAMSUNG HD400LD, WQ100-14, ma
x UDMA/100
Jul  9 00:31:17 xyzzy kernel: ata3.01: 781422768 sectors, multi 16: LBA48
Jul  9 00:31:17 xyzzy kernel: ata3.00: ata_hpa_resize 1: sectors = 32167296
0, hpa_sectors = 321672960
Jul  9 00:31:17 xyzzy kernel: ata3.00: configured for UDMA/33
Jul  9 00:31:17 xyzzy kernel: ata3.01: ata_hpa_resize 1: sectors = 78142276
8, hpa_sectors = 781422768
Jul  9 00:31:17 xyzzy kernel: ata3.01: configured for UDMA/33

I.e. it detects the UDMA/100 controller and the UDMA/100 disk, and then ditches
everything as UDMA/33. I'm pretty sure it ran faster under FC 6.

# hdparm -i /dev/sdc

/dev/sdc:

 Model=SAMSUNG HD400LD                         , FwRev=WQ100-14,
SerialNo=S0AXJ1MP306955
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 udma3 udma4 udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4
ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

What does your hdparm -i /dev/sda show?
Comment 9 Brad 2007-07-11 15:26:31 EDT
[root@localhost ~]# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD2500JB-00GVC0                     , FwRev=08.02D08, SerialNo=    
WD-WMAL73690148
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?1?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode

[root@localhost ~]# hdparm -i /dev/sdb 

/dev/sdb:

 Model=ST3320620AS                             , FwRev=3.AAC   , SerialNo=     
      3QF01Y5W
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?1?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

Interesting that sdb does not show a active mode.
Comment 10 Alan Cox 2007-07-13 13:15:54 EDT
Cable detection pdc202xx_old cable detect was wrong in some cases so 80wire
cables were handled as 40 wire and limited to UDMA33, already fixed upstream
Comment 11 Brad 2007-07-13 13:33:20 EDT
Alan

That (post #10) would just apply to Micke's post (#8) right?

Thanks
Comment 12 Brad 2007-07-15 16:39:22 EDT
Related to 242123?
Comment 13 Brad 2007-07-21 13:57:56 EDT
Kernel 2.6.22.1 seems to make this problem worse. Add about 30 seconds onto a
4.4gig transfer.
Comment 14 Brad 2007-07-22 15:40:03 EDT
When yum installed the 2.6.22.1 kernel it decided to install the 586 version.
Once this was corrected, the speed transfer time for a 4.4 gig file decreased by
5 seconds. Still not as good as FC5 but moving in the right direction.

Sorry about the mistake(just on this last kernel).
Comment 15 Alan Cox 2007-09-10 11:16:21 EDT
For the VIA and for some pdc202xx there are some fixes in the latest rc tree for
cable detection handling problems which might limit the drive to UDMA33 and
would precisely match your performance reporting.

The via one seems to have cured the remaining known problem cases the
pdc202xx_old one is probably there but may not be all that is needed.
Comment 16 Brad 2007-09-10 13:54:09 EDT
I would guess that this would not apply to me as I (and several of the others
that I know of) are running nvidia chipsets. In my case it is an Asus a8n5x and
in another it is the asus A8n-sli. 
Comment 17 Brad 2007-09-10 13:59:08 EDT
The problem still exists in 2.6.22.4-65.fc7.
Comment 18 Alan Cox 2007-09-10 14:02:52 EDT
The Nvidia chips we have some problems with (the usual Nvidia approach to
documentation requests - ie "NO") but there is some work going on there with
using ACPI to get hints which may help.

Once 2.6.23 final is out then it would be useful to test - before that I
wouldn't expect any change in the FC kernels.
Comment 19 Andre Robatino 2007-09-14 13:47:59 EDT
  For what it's worth, the bug still exists in a Dell Dimension B110 with F8t2
(2.6.23-0.164.rc5.fc8 kernel).  At kernel.org it looks like 2.6.23 should be out
soon.
Comment 20 Andre Robatino 2007-09-26 22:20:53 EDT
  Still broken for me with kernel-2.6.22.7-85.fc7.
Comment 21 Andre Robatino 2007-10-29 19:36:14 EDT
  Still broken with kernel-2.6.23.1-10.fc7.
Comment 22 Alan Cox 2007-10-29 20:53:03 EDT
Not likely to change in the near future. Depends on extracting information from
nvidia I suspect so don't hold your breath 8)
Comment 23 Alan Cox 2007-12-03 12:21:48 EST
Nvidia patches going upstream, some fixes hopefully for 2.6.24, rework for
hardware where drive side detect is broken aimed at 2.6.25 for Nvidia and
probably VIA cases

Comment 24 Christopher Brown 2008-01-09 10:35:21 EST
Okay, changing to MODIFIED. Please could reporters test using rawhide kernels if
they are able with:

# yum update kernel --enablerepo=development
Comment 25 Andre Robatino 2008-03-28 15:23:46 EDT
Still broken with kernel-2.6.24.3-50.fc8.
Comment 26 Bug Zapper 2008-05-14 09:21:39 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 27 Brad 2008-06-23 17:06:12 EDT
This bug is still around in F8 and F9. Anybody home?
Comment 28 Alan Cox 2008-06-24 18:11:55 EDT
Cases we find are being gradually eliminated. Some stuff in 2.6.25, some queued
for .26 and also the libata.force option to ignore cable detection.

It isn't simple because it has hundreds of causes from laptop quirks which need
specific handling on the laptop, through plain buggy drive firmware to boards
where they saved a cent by missing off the capacitors for cable
detect and interactions between devices.
Comment 29 Andre Robatino 2008-09-22 04:02:17 EDT
Still broken for me in F9 with kernel-2.6.26.3-29.fc9.i686.
Comment 30 John Poelstra 2008-09-22 23:29:23 EDT
changing to assigned and moving version to "9" based on last comment
Comment 32 Bug Zapper 2009-06-09 18:41:00 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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
Comment 33 Bug Zapper 2009-07-14 14:15:10 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.

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