Bug 246340

Created attachment 158296 [details]
lspci

/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

*** Bug 246337 has been marked as a duplicate of this bug. ***

*** Bug 246338 has been marked as a duplicate of this bug. ***

*** Bug 246339 has been marked as a duplicate of this bug. ***

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.

I used the echo method and changed both sda and sdb. No significant change in cp
times. hdparm -tT got slightly (probably insignificant) worse.

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?

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

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

Alan

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

Thanks

Related to 242123?

Kernel 2.6.22.1 seems to make this problem worse. Add about 30 seconds onto a
4.4gig transfer.

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

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.

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. 

The problem still exists in 2.6.22.4-65.fc7.

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.

  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.

  Still broken for me with kernel-2.6.22.7-85.fc7.

  Still broken with kernel-2.6.23.1-10.fc7.

Not likely to change in the near future. Depends on extracting information from
nvidia I suspect so don't hold your breath 8)

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

Okay, changing to MODIFIED. Please could reporters test using rawhide kernels if
they are able with:

# yum update kernel --enablerepo=development

Still broken with kernel-2.6.24.3-50.fc8.

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

This bug is still around in F8 and F9. Anybody home?

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.

Still broken for me in F9 with kernel-2.6.26.3-29.fc9.i686.

changing to assigned and moving version to "9" based on last comment

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

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.