Slow SATA performance

[Dan Walker]

Hi

This issue has been discussed over at http://ubuntuforums.org/showthread.php?t=447474, and seems to affect a number of us.

File copy speed is very slow (roughly 5-10MBps) on SATA hard drives. Copying within the same physical drive is just as slow as copying to another physical drive. The issue occurs with GUI tools (Nautilus, Krusader) as well as at the terminal using the CP command. This has occured since upgrading to Feisty; Edgy was fine.

[Sitsofe Wheeler (sitsofe)]

Thank you for your bug report.

Dan:
Can you check to see whether you are running by posting the output of
uname -a
dmesg | head
?

[Dan Walker (dwalker109)]

Here's the output of uname -a:
Linux Panoramix 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

The output of dmesg | head is attached to this post.

Thanks!

[Dan Walker (dwalker109)]

This doesn't seem to be limited to Intel chipsets - it also seems to affect nForce based systems, as per the discussion at the previously quoted thread.

[montag (montag-fire)]

Same problem here, but my motherbord is ALi based.

My Sata controller (lspci)
SATA controller: ALi Corporation ULi M5288 SATA

uname -a:
Linux kubuvic 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Many people on the forum are experiencing slow sata...

An other problem with mi Sata disk (I don't know if it's related to this one or not):
sudo smartctl -i /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA ST3320620AS Version: 3.AA
Serial number: 3QF0M1ZP
Device type: disk
Local Time is: Sun Jun 24 20:28:22 2007 CEST
Device does not support SMART

And it sounds strange...

[Dan Walker (dwalker109)]

Users of Intel, nForce, ALi, ATI and Silicon Image SATA controllers have all reported this issue - it does not seem limited to any one manufacturer.

[joyolee (joyolee15)]

some problem~~~~
any solutions?

[Sitsofe Wheeler (sitsofe)]

Dan:
Do you know if the problem has persisted into Gutsy (is it possible to test a LiveCD)?

[Dan Walker (dwalker109)]

I have heard anecdotal evidence that this is resolved in Gutsy. I will try and give it a test and report back.

[Reptile (adam-reptilianshapeshifter)]

This seemed to be resolved in Tribe 3 beta at least (cant remember the kernel version) but since the last few kernel updates I am back to the old transfer speeds again so I am going to find the old kernel that worked and test it. I am very disappointed that this appeared to be fixed and now it is a problem again.

Using Tribe 3 is getting up to 50mb/s (it took less than 15 seconds to transfer a 700mb file from one physical disk to another) and now it is taking 2 minutes to transfer!

I have an AG8 motherboard for Pentium 4 and the chipset is an intel ICH6-R 915P.

[Reptile (adam-reptilianshapeshifter)]

Ok this gets weirder. I installed the Gutsy RC from scratch and now file transfers are back to normal. What the hell could it be?

[lefty.crupps (eljefedelito)]

I am not sure if it is related or not, but my SATA2 DVD-r drive jumps around in speed but settles on burning at 4x after about 30-50% od a DVD, and then stays at that 4x for the remainder of the burning time. The DVD-R drive itself is *supposed* to burn at 18x...

Let me know if I can provide more info, or if I am on the wrong bug report...

[lefty.crupps (eljefedelito)]

sorry, that is with a fresh install of Gutsy final.

[mrmiranda (marcio-inf)]

I have same problem (slow transfers). I installed the gutsy RC and and the transfer continue slow.

I have an Laptop v6000 series compaq, semprom 3500+ and the chipset is an nvidia.

Any solutions?

[Dan Walker (dwalker109)]

Having upgraded to Gutsy, transfer speed is a lot faster for me, but I'm not certain the issue is fully resolved yet - I got between 20 and 40 MBps when copying this evening, so I will test further and report back. It is a definite improvement though, no question.

[Fungyo (sites07)]

Clean install of Gutsy final. copy a 350mb avi file at times is slow but can also start transferring at 120+mbs, then within seconds it drops to around 50mbs which by this time it has finished copying. I have noted it going as slow as 14mbs from 122mbs.
Transferring a large avi file of 900mb always starts at about 11mbs, drops as low as 6mbs but increases to 20mbs as the copying nears 100% complete.

copying from an ext usb hdd stays at about 25mbs from start to finish, i believe this would be about max due to the usb limited bandwidth.

> sudo hdparm -tT /dev/sda
Timing cached reads: 856 MB in 2.00 seconds = 427.16 MB/sec
Timing buffered disk reads: 190 MB in 3.00 seconds = 63.25 MB/sec

wd 320gb 7200 16mb

asus p5p800-mx
865G PE/P
ICH5/ICH5R

[pinepain (pinepain)]

Hi. i have or actually had the same problem, average speed from IDE to SATA was 5mbps. Then i tries to tune with hdparm and sdparm - nothing. But i noticed that I coudn't set to use UDMA mode (yeah, hdd support it), so i tried to set it in BIOS. BIOS saz that all settings is auto and it use the fastest mode, udma5 on segate(5yrs old) an udma6 on hitachi (a few month ago). But after switchin from auto to udma5 and udma6 i get min 20mbps from ide to sata =) Dunno why, but it helps. Actually I have average speed from ide to sata ~30mbps, but I just mv 2gb, I should make some serius tests in it... later =) BTW, self-copy, move from one partition to another (on sata hdd) goes with the similar speed.

Yeah, one more thing, speed is very various, starts from 60-80 and goes down to 50 - 40 still there and goes ~17-25. Dunno why. Maybe my IDE is to slow for SATA.

Here is some data about my
#sda = IDE, sdb-sata.
#motherboard ASROCK P4DUAL 915GL (nop, it is old 1-cpu mb =)), 1024 + 256 DDR1(tuned to 2.5-3-3-4, IIRC=)),

#CELERON D 2.4 (works on 2.7, I've overclock bus from 133 to 150)

root@lhome:~# lspci |grep IDE
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 05)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 05)

root@lhome:~# uname -a
Linux lhome 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

root@lhome:~# hdparm -i /dev/sda

/dev/sda:

 Model=ST340810A , FwRev=3.99 , SerialNo=5FBBPX4Y
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 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=yes: unknown setting 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@lhome:~# hdparm -i /dev/sdb

/dev/sdb:

 Model=Hitachi HDT725050VLA360 , FwRev=V56OA7EA, SerialNo= VFK401R41K57XK
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
 BuffType=DualPortCache, BuffSize=15315kB, MaxMultSect=16, MultSect=?16?
 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=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

root@lhome:~# hdparm -tT /dev/sda

/dev/sda: #yeah. it really slow
 Timing cached reads: 1624 MB in 2.00 seconds = 811.40 MB/sec
 Timing buffered disk reads: 82 MB in 3.06 seconds = 26.79 M...

[Fungyo (sites07)]

gave pinepain suggestions a try and set dma settings manually in bios. I have increased speed from 3 mb/s to 20-25mb/s. still not optimal but an improvement.

[Alexey Borzenkov (snaury)]

I've just measured my drive reading time and found out that it's 3.5-4.9MB/s (measured in Midnight Commander by copying a not yet cached file to /dev/null). Then I plugged a USB drive (an HDD box) and tried checking, it's 15-20MB/s, this isn't funny! I have ASUS F3Jp laptop (I have no settings in my BIOS) and now I see this was the reason of of bug #126274 and bug #131094 at least in my case.

dragonfox@kitsuden:~$ sudo hdparm -i /dev/sda

/dev/sda:

 Model=Hitachi HTS541612J9SA00 , FwRev=SBDOC70P, SerialNo= SB3D00E5G0D07A
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7516kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 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=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

I don't understand this, since I see udma5 marked as active in hdparm's output. (?)

[Alexey Borzenkov (snaury)]

Update. I've just tried copying files from my ntfs-3g partition and got 35MB/s. Then I started trying other files on my ext3 partition and found that some big files actually get read at 15-20MB/s. Most of big files are 5MB/s though. Seems like very heavy fragmentation. :(

[pinepain (pinepain)]

rtfm. copying a lot of small files takes more time than copying large with the same size. ntfs? its a stone age, use ext or raiser. also notice that copyng to /dev/null is different than copying to hdd or other media. btw, it's very interesting you don't have hdd options in bios. do u have the latest BIOS version? if no try to update it.

oh, one more fun thing. IIRC, there are pure SATA and emulation SATA via IDE on old MB =). also there are primary and secondary SATA connectors, try both of them, it may helps, i hope,

ps: maybe there are some jumpers to set io mode or sata1-sata2 ? but i'm not pro in such thing as hdd so it just IMHO

[lefty.crupps (eljefedelito)]

I could be wrong on this, but I thought the point (or, a part of it at
least) of DMA was to bypass the CPU when moving files; last night I copied
200GB of files and it totally ate the CPU during the processes. ext3 to
ext3, both SATA (from SATA2 to SATA1)...

[pinepain (pinepain)]

yupp, dma mustn't make heavy cpu load, for sure, but r u sure your hdd
use dma?

[Alexey Borzenkov (snaury)]

Pinepain, it's very kind of you to rtfm me without actually reading my comment, thank you very much. First of all there were no 'a lot of small files' not in any single of my tests. I always used large files, 250-350MB in size. And ntfs is not stone age, it is currently used by my windows partition, and the big file for testing was pagefile.sys (surprising, no? it's also not heavily fragment there). Also never in my tests I actually used to copy to hdd, because then it would be read+write speed (minus a delta because some data would stay in cache), writing data to /dev/null can have a small delta (dependent on buffer size though), but still, difference between 5MB/s and 20MB/s [on the same system with different files, one was downloaded with ktorrent (heavily fragmented and slow), another downloaded with wget (shows excellent throughput, supposedly it's not fragmented)] is not imaginary, don't you think? And I doubt I have a spare connector in my laptop's hard drive bay.

My experience with gutsy (after dist-upgrading from feisty) was extremely crawling and painful under even slightest disk load for past two months (and not just mine I assume, reading relevant bug reports), heavy fragmentation can also explain why people stop experiencing performance problems after they do clean reinstall.

P.S. Yes, I upgraded my bios and found that I do have those options in there, but I don't know if that would help at all, because I wiped my ubuntu installation, sorry. But seeing hdparm -i that I attached above I doubt it, because it shows udma5 is already currently selected mode.

[pinepain (pinepain)]

=) yeah, rtfm i thought u have not read man hdparm (sdparm), sry. about file size it was just in case, you know it's better to say it one more time than somebody will try to get 50mbps with 4gb of 4kb pics =)

ntfs in gnu is stone age. its a proprietary standard ant its support is limited so it's better to test your speed on full supported fs.

yeah, u r right with delay while copying to native hdd partition, but i think with copying to /dev/null you'll not get right results =) try to bkup / to /dev/null =) yeah, it takes more than io operations =)

5 and 20?? man, i have here 5 and 60 !!! it starts with 60 than drop down than up to 27-32 and stay there, but the average is ~27
i think hdd caching makes such differences. anyway, only hdparm -tT give you real result. other vudu is still vudu, nothing more.
experience of GNU/Linux saz that you _must_ experiment! who saz "heavy fragmentation"? there is fsck =) it will helps you to prevent fragmentation, i hope =)

about bios, i dunno, but it helps me (and Fungyo, thx for feedback) and i write here to help other ppl. btw, my hdd sad he use udma6 but speed was under 5 mbps before tune hdd mode in bios from auto to udma6. but u can try and see results.

truly you, pinepain

[pinepain (pinepain)]

[sorry] yeah, i was totally wrong. copying to /dev/null is much faster than to fs. dunno why did i sad that sh*t =).

i just tried to switch my hdd from primary sata connector to secondary and it is a little slower than on primary. so read your MB manual to know where is primary sata connector and where is secondary =). sorry one more time for /dev/null

[NiklasW (falken)]

I think my drives also act very slow. I do not know what preformance I could expect, here is some infor:

SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA

sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1746 MB in 2.00 seconds = 873.15 MB/sec
 Timing buffered disk reads: 232 MB in 3.03 seconds = 76.61 MB/sec
nwaren@amanda:~$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 1248 MB in 2.00 seconds = 624.23 MB/sec
 Timing buffered disk reads: 162 MB in 3.03 seconds = 53.55 MB/sec

uname -r
2.6.22-14-generic

Processor: AMD X2 +4400
Moderboard: MSI K9AG NEO-F, AMD 690V+SB600, ATX, Socket-AM2, DDR2, GbLAN, VGA

[NiklasW (falken)]

My drives:

/dev/sda:

 Model=SAMSUNG HD501LJ , FwRev=CR100-10, SerialNo=XXXXXXXXXXXXXX
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 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: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

/dev/sdb:

 Model=ST3160812AS , FwRev=3.AAE , SerialNo= XXXXXXXXX
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, 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
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

[Dan Walker (dwalker109)]

Just checking in the keep the thread "alive" - problem still exists for me in Gutsy. I average 5 - 10MBps during file copies.

[pinepain (pinepain)]

Hi,

Maybe the problem is in motherboard (chipset, etc.)? I've notice that
ASUS motherboards (as well as it subsidiary, ASRock) doesn't work
clearly under linux (problems with ACPI, slow hdd performance). So I
think it would be nice to get statistic on MB models (also notice BIOS
version) and vendors we got problem with.

[slinger (slinger-to)]

Same Problem here on Gutsy 2.6.22-14-generic.

Got a Thinkpad X60 with:

PCI bridge : Intel Corporation 82801 Mobile PCI Bridge
ISA bridge : Intel Corporation 82801GBM
IDE interface : Intel Corporation 82801G
SATA controller : Intel Corporation 82801GBM/GHM
SMBus : Intel Corporation 82801G

Slow performance with SATA HDD, i am just getting 34,04MB/sec and copying a 700MB file on same HDD takes just 5 MINUTES...no background tasks that can slower performance.

Tried Hardy Alpha 6 Live CD - same poor performance here. Why isn't there a fix since one year?

[Pelle van der Scheer (pellesimon)]

Same problem here on Hardy 2.6.24-12-generic,

Speeds vary between 5-10MB/s on a sata hard drive and Asus A8N-E motherboard copying large files (700mb) with nautilus

Speed reported by hdparm:

/dev/sda:
 Timing cached reads: 1418 MB in 2.00 seconds = 708.60 MB/sec
 Timing buffered disk reads: 204 MB in 3.02 seconds = 67.56 MB/sec

[pltxtra (pltxtra)]

I have the same problems, but I have two machines, both running 7.10, the first is AMD the other is Intel.

The problem for me seems to be the hard-drive itself. I have three SAMSUNG HD161HJ disks and one Maxtor.
No UDMA mode is enabled for any of the samsung disks, independently of which machine it is connected to.
The AMD has a VIA-SATA RAID controller, the Intel board has a controller from Intel.

The Maxtor disk has UDMA 5 enabled.

Conclusion: The differences on the disks have impact.

I also have a question: can it be that the samsung disks themselves do not support any UDMA/DMA mode?

[Dan Walker (dwalker109)]

Since my last comment, I have done some more testing. While performance is generally much better than it was a year ago, it still isn't quite as fast as it should be on two of my drives, and these drives don't appear to be running in any UDMA mode. The other one seems to perform a bit better, and has udma5 enabled. Here's the relevant output of hdparm -i and hdparm -tT on each of my three drives (the full output is attached):

# Maxtor 80GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 Timing buffered disk reads: 170 MB in 3.01 seconds = 56.39 MB/sec

# Seagate 80GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 Timing buffered disk reads: 224 MB in 3.01 seconds = 74.42 MB/sec

# Western Digital 500GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec

Copying a 700MB ISO image between each of these drives takes between 11 and 20 seconds, with the mean average being about 15 seconds; the faster the transfer, the higher the CPU usage (up to 30% in some cases, much higher than I would expect considering DMA is supposed to be in use). I have attached details of this test as well (9 copy operations in all), in case this is of any use.

Of course, I don't really know what speeds I'm supposed to get on these drives - I have never paid much attention to copy speed until this problem occured. It's possible that these speeds are normal (they're certainly quick enough that this isn't as big an issue as it was), though the fact that UDMA still seems to be disabled on two drives makes me think something is still not working as it should.

[joosters (x-launchpad-slimyhorror-com)]

I hit (what I think was) this problem with a fresh install of Hardy AMD64. My SATA controller is:

00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) (prog-if 85 [Master SecO PriO])
        Subsystem: Hewlett-Packard Company Unknown device 1714

I found that only my *second* hard drive (sdb) was slow, and only for writes. It turned out that the sata_nv driver, for whatever reason, did not enable the write cache on the second hard disk. 'hdparm -W 1 /dev/sdb' fixed the slow speed problems for me. Maybe that will help others on here?

It's not clear why the write cache doesn't get enabled on the second drive...

[NiklasW (falken)]

I have write cashe on all my drives (3 drives, diffrent brand):

/dev/sdc:

 Model=ST3160812AS , FwRev=3.AAE , SerialNo= 4LS1VZ17
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, 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
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
/dev/sdb:

 Model=SAMSUNG HD501LJ , FwRev=CR100-10, SerialNo=S0MUJ1NP502182
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 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: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

/dev/sda:

 Model=ST380817AS , FwRev=3.42 , SerialNo= 4MR07TJJ
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 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
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

Output of lspci:
 lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Co...

[NiklasW (falken)]

I did a copy between 2 diffrent disk

FileSize: 680M

Time:
real 0m54.372s
user 0m0.036s
sys 0m3.752s

[SirLancelot (lukaszgraczyk)]

Hi

I have exactly the same problem on my MSI VR610 new laptop with:

ATI Technologies Inc SB600 Non-Raid-5 SATA

100% same situation as it was descripted above!

Everything on my Ubuntu 7.10 32bit looks OK but the speed of copy and system performance is definitely not OK!

Coping 700MB of data between same disc prtitions gets too much time! Burning DVDs with higher speed than x2 is theoretic possible but jumping buffers and time of burning tells that disc works too slow to make a copy in less than 20 minutes!

I strongly suggest to change this bug priority to High! Many of new laptops will work slowest than the old ones on Ubuntu and that's sucks!

[SirLancelot (lukaszgraczyk)]

PS.:

Exactly same situation with Ubuntu 7.10 amd64!

[Léa GRIS (lea-gris)]

Same here with Ubuntu 7.10 in a Shuttle SN25P Nforce4 chiipset and Seagate ST3160023AS 160GB,
CPU AMD Athlon(tm) 64 X2 Dual Core Processor 4200+:

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1954 MB in 2.00 seconds = 977.58 MB/sec
 Timing buffered disk reads: 36 MB in 3.51 seconds = 10.27 MB/sec

uname -a
Linux meumeu 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

lspci | grep ATA
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)

lsmod | grep sata
sata_nv 20612 3
libata 125168 2 sata_nv,ata_generic

hdparm -i /dev/sda

/dev/sda:

 Model=ST3160023AS , FwRev=3.18 , SerialNo=3JS2LVQH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, 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
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number: ST3160023AS
        Serial Number: 3JS2LVQH
        Firmware Revision: 3.18
Standards:
        Used: ATA/ATAPI-6 T13 1410D revision 2
        Supported: 6 5 4
Configuration:
        Logical max current
        cylinders 16383 16383
        heads 16 16
        sectors/track 63 63
        --
        CHS current addressable sectors: 16514064
        LBA user addressable sectors: 268435455
        LBA48 user addressable sectors: 312581808
        device size with M = 1024*1024: 152627 MBytes
        device size with M = 1000*1000: 160041 MBytes (160 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Standby timer values: spec'd by Standard
        R/W multiple sector transfer: Max = 16 Current = 16
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           * SMART feature set
                Security Mode feature set
           * Power Management feature set
           * Write cache
           * Look-ahead
           * Host Protected Area feature set
           * WRITE_BUFFER command
           * READ_BUFFER command
           * DOWNLOAD_MICROCODE
                SET_MAX security extension
           * 48-bit Address feature set
           * Device Configuration Overlay feature set
           * Mandatory FLUSH_CACH...

[pltxtra (pltxtra)]

After an upgrade to Ubuntu 8.04 the UDMA mode 6 has been activated, previously hdparm -i only showed
up to UDMA 5 if I recall correctly, but now it shows UDMA 6 and it is checked. The system feels more responsive
now too..

[Adam Caldwell (adam-caldwell-deactivatedaccount)]

I have this same problem, though it definitely seems to be complicated. Copying large files (>2GB) from one SATA drive to another, or to another location on the same drive pretty much seems to always cause slow speeds (and i mean like 3Mb/sec, it can take 20-30 mins to copy a 4gig file, its seriously faster to burn the same file). Copying a say, 700MB file between the same two drives is reasonably fast (~30mb/sec).

I have a mix of NTFS and reiserfs drives, but it doesnt seem to matter which are the source and target drives. For what its worth, I had the same problem in gentoo, and 32 vs 64-bit doesnt seem to matter either. I'm fairly sure this is a kernel bug, possibly related to specific motherboards or chipset (i'm using the onboard SATA of my nforce4 board). I dont have any of the obvious problems mentioned earlier like disabled write cache or no DMA modes enabled, hdparm gives me a 72MB/s reads (is there a way to test writes?).

It's frustrating to know that I have drives capable of 50+MB/sec, and dont seem to have a problem getting those speeds in windows, and can only get half that in linux at best. Anyone with any insight would be much appreciated.

[victorglt (victorglt)]

Same problem here, Ubuntu 7.10, with an ASUS A7N8X-XE, NForce2 chipset.

My harddisk is a Samsung HD250HJ SATA.

HDPARM results:

/dev/sda:
 Timing cached reads: 728 MB in 2.00 seconds = 364.02 MB/sec
 Timing buffered disk reads: 40 MB in 3.16 seconds = 12.67 MB/sec

I compiled the 2.6.25.4 enabling de old SATA drivers, but the results are still the same.

[Sam Stern (samstern)]

Hi,

I'm apparently impacted this bug as well:

uname:
Linux mail 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

root@mail:~# hdparm -tT /dev/sdd

/dev/sdd:
 Timing cached reads: 534 MB in 2.00 seconds = 266.84 MB/sec
 Timing buffered disk reads: 306 MB in 3.01 seconds = 101.70 MB/sec
root@mail:~# hdparm -tT --direct /dev/sdd

/dev/sdd:
 Timing O_DIRECT cached reads: 160 MB in 2.01 seconds = 79.63 MB/sec
 Timing O_DIRECT disk reads: 328 MB in 3.01 seconds = 109.11 MB/sec

dd, cp and rsync top out at write of 33mbs

General system description (see attached tarball for detailed files):

Motherboard: ASUS a7m266-D
CPU: Dual AMD Althon 2.8 (Barton core)
Memory: 3gb
Disk controller 1: Promise tx2 SATA 150+ (holds individual data disks: 400gb PATA UDMA 133, 400GB SATA 150. Sits on 64bit 66mhz bus, runs at 66mhz, 32 bits
Disk controller 2: Promise tx4310 (holds four Segate 500 gb sata 3gb es.2 class drives). Sits on 64bit 66 mhz bus, runs at 66mhz, 32bit
Disk controller 3: AMD motherboard PATA channel 0 disabled, Channel 1 holds a pata udma/66 cd rom

NB: the dmesg shows allot of mdadm software raid activity -- I discoved the problem while benchmarking a new software raid array. The problem occurs regardless of where I copy the file to -- individual drive, part of the array, two drives ont eh same card or one drive on a sata card and one drive on the amd pata (not shown in dmesg).

So yes, the problem seems to exist on ubuntu 8.04.

Sam S.

[victorglt (victorglt)]

Just upgraded to Hardy.

uname -a
Linux 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

Performance seems to be better, however it's not ideal.

/dev/sda:
 Timing cached reads: 794 MB in 2.00 seconds = 396.58 MB/sec
 Timing buffered disk reads: 266 MB in 3.03 seconds = 87.85 MB/sec

Buffered disk reads increased dramatically from 10 to 87, but cached reads continues the same,

[Jacob D (brokendwarf)]

I seem to have the problem on Hardy ( updated from feisty ). The speeds of 12MiB/s while copying 400MiB files between two SATA drives are curious to say the least. However, these seem to be higher when copying from the drives over the network using samba (around 20MiB/s). I will try a clean install of Hardy on a different machine with these drives to see if it occurs there too. Did anybody with this issue try a different distro/kernel?

[Sam Stern (samstern)]

yes. I had a worse problem with Centos 4.4 copy speed < 1 mps. I'm downloading OpenSuse 10.3 and Centos 5.1 now. Also, I've heard of two possible avenues to explore:

1) add the boot time option of ide_combined=libata
note: this did not help me
2) edit /etc/initramfs-tools files to include your modules and libata and sata_$whatever (for me sata_promise) then add pata_$wahtever (pata_amd) to your module blacklist.
Note: if you're not really comfortable with this option you can make your system unable to boot. It's the next thing I'm going to try. The idea is that libata superceeds the kernel ata modules with might be conflicting with the sata modules.

Sam S.

[Sam Stern (samstern)]

um forget that second option it's not the root of my problem at least -- libata is already preffered on my system and it's modules are what is linked against per lsmod ;>

[Amr Hassan (amr-hassan)]

having the same problem, plus, i can't get DMA to work on my IDE DVD-RW, but that's another story.

sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1684 MB in 2.00 seconds = 841.96 MB/sec
 Timing buffered disk reads: 204 MB in 3.02 seconds = 67.65 MB/sec

using one sata HDD on ntfs, copying/moving files takes place at 4-6 MB/sec..

i'm surprised nobody has solved this yet..

[Prakash J Kokkatt (pjkonweb)]

Here with Ubuntu Hardy ,I can confirm the same bug.
although hdparm shows for both my sata hdds are udma6 enabled ,it took 35minutes for me to copy a 10GB dir from one location to another!.

I can compile a kernel myself.just tell me -should I disable newer libata and enable old set of drivers?they seemed to have worked perfect for my hardware :)

Thank you!

[Prakash J Kokkatt (pjkonweb)]

forgot to tell that I have a 915GV based mobo with 2 seagate barracuda SATA drives.

[erikkll (erik-kleinlangenhorst)]

I can confirm this bug. It's really annoying, even vista copies files faster than this.
Copying from within the same harddisk is at around 8MB/sec.

As with everybody else, i'm getting good speeds at hdparm.

[Léa GRIS (lea-gris)]

erikkll a écrit :
> I can confirm this bug. It's really annoying, even vista copies files faster than this.
> Copying from within the same harddisk is at around 8MB/sec.
>
> As with everybody else, i'm getting good speeds at hdparm.

Did one of you benchmarked on a "noatime" mounted volume, to test if
this slowness may be related to the atime update having to write the
metadata for each file access?

--
Léa Gris

[lefty.crupps (eljefedelito)]

> Did one of you benchmarked on a "noatime" mounted volume, to test if
> this slowness may be related to the atime update having to write the
> metadata for each file access?

All of my volumes are mounted this way (why isn't this the *buntu default??) and it doesn't solve the issue.

[maik (maik-0x2a)]

Same here on Hardy:

/dev/sda:
 Timing cached reads: 1482 MB in 2.00 seconds = 741.13 MB/sec
 Timing buffered disk reads: 28 MB in 3.07 seconds = 9.12 MB/sec

I have a ASUS A8N-SLI Deluxe Board and Seagate Baracuda Drive.

Tried to disable IDE in Bios, unplugging all IDE devices, but this does not help.

Greping in dmesg i found the following line. Has this any meaning?

[ 23.641701] ata6.00: ATA-7: ST3300831AS, 3.02, max UDMA/133
[ 23.641704] ata6.00: 586072368 sectors, multi 1: LBA48 NCQ (depth 0/32)
[ 23.641712] ata6.00: configured for PIO <-----

[D!ego (diegoasanza)]

Same problem. Some data:

:~$ cat /etc/issue
Ubuntu 8.04.1 \n \l

:~$ uname -a
Linux netstar 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 GNU/Linux

:~$ sudo hdparm -i /dev/sda
/dev/sda:

 Model=ST9160821AS , FwRev=3.BHE , SerialNo=5MA5P0FB
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312581808
 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=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1192 MB in 2.00 seconds = 595.79 MB/sec
 Timing buffered disk reads: 128 MB in 3.04 seconds = 42.13 MB/sec

[armbrust (armbrust-cern)]

I have had this problem for a while now and just fixed it by adding "noatime,nodiratime" to the mount options in fstab, as suggested at http://kerneltrap.org/node/14148 .

The problem was on a SATA drive I use for storage. Copying a 676mb file from an IDE to the SATA drive before the fix:

> time cp test.tar /storage/.

real 1m38.573s
user 0m0.032s
sys 0m4.132s

And after:

> time cp test.tar /storage/.

real 0m7.128s
user 0m0.004s
sys 0m2.892s

The cpu usage during transfer was about 3%, now it ranges from 15-50%. I don't notice it, but I just thought I should say.

[erikkll (erik-kleinlangenhorst)]

Hmm, i'm now reading there, but there seems to be some side-effects in doing that? Can anybody explain that for a bit? I don't quite understand what they're saying..

[John Thomson (john-thomson-nz)]

I had this problem. My motherboard does not support sata nor recognize
my via 6421 controller. Even though it did'nt boot I was able to boot via
usb hard disk (memory stick) and no matter what always got about 4 m/bytes
on the hdparm test. My IDE disk was making about 50+.
Just now I re-installed my st3320613as onto the external connector
of the controller, now it tests at 60+ m/bytes. Of course the two ports are
supposed to be the same ! Hope that helps (or maybe confuses ??).
I am using the "combined_mode=libata", but no idea now whether it is actually needed.

[Chip Schweiss (chip-innovates)]

This is a serious problem. I just installed 8.04 on an ASUS M3A78-EMH HDMI with three WR Raptor SATA drives.

# hdparm -tT /dev/sda# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD740ADFD-00NLR5 , FwRev=21.07QR5, SerialNo= WD-WMANS2252557
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=48
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=145226112
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 published, ANSI INCITS 397-2005: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

/dev/sda:
 Timing cached reads: 2054 MB in 2.00 seconds = 1026.74 MB/sec
 Timing buffered disk reads: 68 MB in 3.09 seconds = 22.03 MB/sec

I'm getting better performance out of 7200 rpm drives on a machine with 7.10 on it.

None of the above suggestions improve performance any. I should be seeing over 3 times the throughput.

Is anyone looking into this problem?

[Leann Ogasawara (leannogasawara)]

Beginning with the Hardy Heron 8.04 development cycle the kernel source package naming convention changed from "linux-source-2.6.xx" to just "linux". Going forward, kernel bugs should now be reported against the "linux" package. I'm going to automatically retarget this bug against the "linux" package so that the appropriate developers are notified.

[Leann Ogasawara (leannogasawara)]

Hi Guys,

The upcoming Intrepid Ibex 8.10 release is actively being developed. Would anyone care to confirm if this is still an issue with the latest Alpha for the upcoming Intrepid Ibex 8.10 which contains a 2.6.26 based kernel. You can find more information regarding the latest Alpha at http://www.ubuntu.com/testing. If the issue still exists just curious if booting with "all_generic_ide" makes any different. Please let us know your results.

Also, report will remain open against the actively developed kernel but since a patch/fix has not been isolated to backport to 2.6.20 and 2.6.22, those tasks will be closed for the time being. Once a fix can be determined it will be reviewed for consideration as a Stable Release Update - http://wiki.ubuntu.com/StableReleaseUpdates. Thanks.

[Lars Steinke (lss)]

Just to add some more input on the problem, that nobody seems to have been able to resolve yet:

On my system (Linux sigma 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux), the only harddrive affected by the SATA performance bug (5MB/sec max.) is the one on the second port (even though it is identical to the one on the first port of my 00:12.1 IDE interface: ALi Corporation ULi 5289 SATA (rev 10), see below):

steinke@sigma:~$ sudo hdparm -tT /dev/sdb
/dev/sda:
 Timing cached reads: 1702 MB in 2.00 seconds = 851.45 MB/sec
 Timing buffered disk reads: 228 MB in 3.01 seconds = 75.62 MB/sec

steinke@sigma:~$ sudo hdparm -tT /dev/sdb
/dev/sdb:
 Timing cached reads: 1100 MB in 2.00 seconds = 550.14 MB/sec
 Timing buffered disk reads: 10 MB in 3.61 seconds = 2.77 MB/sec

This is also reflected by the SATA initialisation ("configured for PIO" instead of "configured for UDMA/133"), forcing UDMA with hdparm has no effect either...

dmesg:
...
[ 18.319314] scsi2 : ata_generic
[ 18.319369] scsi3 : ata_generic
[ 18.319481] ata3: PATA max UDMA/100 cmd 0xec00 ctl 0xe080 bmdma 0xd880 irq 19
[ 18.319482] ata4: PATA max UDMA/100 cmd 0xe000 ctl 0xdc00 bmdma 0xd888 irq 19
[ 18.522204] ata3.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 18.522206] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 18.522216] ata3.00: configured for UDMA/133
[ 18.727409] ata4.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 18.727411] ata4.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 18.727419] ata4.00: configured for PIO
[ 18.727456] scsi 2:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
[ 18.727561] scsi 3:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
...
[ 21.453463] ahci 0000:03:00.0: version 3.0
[ 21.453493] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 35 (level, low) -> IRQ
 35
[ 21.456918] Driver 'sd' needs updating - please use bus_type methods
[ 21.456990] sd 2:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
[ 21.457000] sd 2:0:0:0: [sda] Write Protect is off
[ 21.457002] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 21.457014] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 21.457049] sd 2:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB)
[ 21.457056] sd 2:0:0:0: [sda] Write Protect is off
[ 21.457057] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 21.457068] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 21.457070] sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
[ 21.518700] sd 2:0:0:0: [sda] Attached SCSI disk
[ 21.518759] sd 3:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
[ 21.518768] sd 3:0:0:0: [sdb] Write Protect is off
[ 21.518770] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 21.518782] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 21.518816] sd 3:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
[ 21.518822] sd 3:0:0:0: [sdb] Write Protect is off
[ 21.518824] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 21.518835] sd 3:0:0:0: ...

[Lars Steinke (lss)]

Oh,

I forgot to mention that I had to add "all_generic_ide" to grub, as Hardy would not boot otherwise...

Thanks,
Lars

[Cubytus (dupa45)]

Hi to all,

same problems here:

Relevant hardware:
Asus A8N SLi Deluxe;
2x 250GB 7200 rpm Western Digital Hard drives, SATA-3
1x DVD-RW, NEC 3500 A
1x Compaq DVD-ROM (slave on ATA cable)

Symptoms:
copying a large file (700MB) to the same hard drive reads around 8 to 13 MBps at most; very occasionally jumps to 20MBps.
Same sort of speed copying to the other hard drive, formatted in NTFS (yes, for the Win XP install that I would like to dump, if only Ubuntu was more reliable.)

uname -a:
Linux Le-Grand-bleu 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux

cubytus@Le-Grand-bleu:~$ dmesg | grep ata
[ 0.000000] BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
[ 71.301111] Memory: 1027360k/1048512k available (2177k kernel code, 20460k reserved, 1006k data, 368k init, 131008k highmem)
[ 71.301125] .data : 0xc0320474 - 0xc041bdc4 (1006 kB)
[ 75.481984] libata version 3.00 loaded.
[ 76.261838] pata_amd 0000:00:06.0: version 0.3.10
[ 76.262715] scsi0 : pata_amd
[ 76.262906] scsi1 : pata_amd
[ 76.263445] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
[ 76.263447] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
[ 76.909093] ata2.00: ATAPI: _NEC DVD_RW ND-3500AG, 2.1B, max UDMA/33
[ 76.909112] ata2.01: ATAPI: COMPAQ DVD-ROM GD-8000, 0011, max UDMA/66
[ 76.909123] ata2.01: limited to UDMA/33 due to 40-wire cable
[ 77.072902] ata2.00: configured for UDMA/33
[ 77.244770] ata2.01: configured for UDMA/33
[ 77.251491] sata_nv 0000:00:07.0: version 3.5
[ 77.251868] sata_nv 0000:00:07.0: Using ADMA mode
[ 77.253359] scsi2 : sata_nv
[ 77.253545] scsi3 : sata_nv
[ 77.253695] ata3: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xd800 irq 19
[ 77.253698] ata4: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xd808 irq 19
[ 77.564337] ata3: SATA link down (SStatus 0 SControl 300)
[ 77.876091] ata4: SATA link down (SStatus 0 SControl 300)
[ 77.876499] sata_nv 0000:00:08.0: Using ADMA mode
[ 77.876618] scsi5 : sata_nv
[ 77.876842] scsi6 : sata_nv
[ 77.876968] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400 irq 16
[ 77.876970] ata6: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xc408 irq 16
[ 78.343727] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 78.351865] ata5.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 78.351868] ata5.00: 488397168 sectors, multi 1: LBA48
[ 78.359842] ata5.00: configured for UDMA/133
[ 78.827344] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 78.835466] ata6.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 78.835468] ata6.00: 488397168 sectors, multi 1: LBA48
[ 78.843471] ata6.00: configured for UDMA/133
[ 78.843566] ata5: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61
[ 78.843911] ata6: bounce limit 0xFFFFFFFFFFFFFFFF, segment boundary 0xFFFFFFFF, hw segs 61
[ 78.844643] sata_sil 0000:05:0a.0: version 2.3
[ 78.844876] sata_sil 0000:05:0a.0: Applying R_ERR on DMA activate FIS errata fix
[ 78.845861] scsi7 : sata_sil
[ 78.845997] scsi8 : sata_sil
[ 78.846135] scsi9 : sata_sil
[ 78.846269] scsi10 : sata_sil
[ 78.84629...

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Jeffery MacEachern (jaem)]

I have this problem in Intrepid/2.6.27-1 and -2, but it worked fine in 2.6.26

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/262845

[Dan Walker (dwalker109)]

This seems to be resolved for me in 2.6.24. I shall test Alpha5 when the LiveCD is available.

[Lars Steinke (lss)]

Just to add some more anaylsis results to narrow this issue down:

Removing "all_generic_ide" from grub, and enforcing use of sata_uli (over ahci) by explicitly adding sata_uli to /etc/modules (and calling "update-initramfs") did the trick for me:

$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1790 MB in 2.00 seconds = 895.06 MB/sec
 Timing buffered disk reads: 228 MB in 3.02 seconds = 75.39 MB/sec

$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 1892 MB in 2.00 seconds = 946.23 MB/sec
 Timing buffered disk reads: 226 MB in 3.01 seconds = 74.98 MB/sec

dmesg extract:
...
[ 16.715632] libata version 3.00 loaded.
[ 16.716662] sata_uli 0000:00:12.1: version 1.3
[ 16.716674] ACPI: PCI Interrupt 0000:00:12.1[A] -> GSI 19 (level, low) -> IRQ 19
[ 16.716788] scsi0 : sata_uli
[ 16.716841] scsi1 : sata_uli
[ 16.716968] ata1: SATA max UDMA/133 cmd 0xec00 ctl 0xe080 bmdma 0xd880 irq 19
[ 16.716971] ata2: SATA max UDMA/133 cmd 0xe000 ctl 0xdc00 bmdma 0xd888 irq 19
[ 17.180710] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 17.230594] ata1.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 17.230598] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 17.297117] ata1.00: configured for UDMA/133
[ 17.762934] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 17.813154] ata2.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 17.813157] ata2.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 17.879691] ata2.00: configured for UDMA/133
[ 17.879868] scsi 0:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
[ 17.879991] scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
...
[ 19.703935] ahci 0000:03:00.0: AHCI 0001.0000 32 slots 1 ports 3 Gbps 0x1 imp
l SATA mode
[ 19.703940] ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
[ 19.703945] PCI: Setting latency timer of device 0000:03:00.0 to 64
[ 19.704033] scsi2 : ahci
[ 19.704090] ata3: SATA max UDMA/133 abar m8192@0xfd800000 port 0xfd800100 irq 35
[ 20.342837] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 20.385098] ata3.00: ATA-7: ST3500630AS, 3.AAK, max UDMA/133
[ 20.385100] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 20.443318] ata3.00: configured for UDMA/133
[ 20.443513] scsi 2:0:0:0: Direct-Access ATA ST3500630AS 3.AA PQ: 0 ANSI: 5
...

So there still seems to be a bug in the libata ahci driver 2.6.24-19.41 with the second port of SATA chipsets, as both the ULi and JMicron (JMicron 20360/20363 AHCI Controller [197b:2360] (rev 02)) chipsets on my ASRock 939Dual show no trouble at all with the disk (sda and sdc, respectively) connected to the first port:

$ sudo hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads: 1674 MB in 2.00 seconds = 837.13 MB/sec
 Timing buffered disk reads: 188 MB in 3.01 seconds = 62.44 MB/sec

Cheers,
Lars

[Lars Steinke (lss)]

Just to add some more anaylsis results to narrow this issue down:

Removing "all_generic_ide" from grub, and enforcing use of sata_uli (over ahci) by explicitly adding sata_uli to /etc/modules (and calling "update-initramfs") did the trick for me:

$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1790 MB in 2.00 seconds = 895.06 MB/sec
 Timing buffered disk reads: 228 MB in 3.02 seconds = 75.39 MB/sec

$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 1892 MB in 2.00 seconds = 946.23 MB/sec
 Timing buffered disk reads: 226 MB in 3.01 seconds = 74.98 MB/sec

dmesg extract:
...
[ 16.715632] libata version 3.00 loaded.
[ 16.716662] sata_uli 0000:00:12.1: version 1.3
[ 16.716674] ACPI: PCI Interrupt 0000:00:12.1[A] -> GSI 19 (level, low) -> IRQ 19
[ 16.716788] scsi0 : sata_uli
[ 16.716841] scsi1 : sata_uli
[ 16.716968] ata1: SATA max UDMA/133 cmd 0xec00 ctl 0xe080 bmdma 0xd880 irq 19
[ 16.716971] ata2: SATA max UDMA/133 cmd 0xe000 ctl 0xdc00 bmdma 0xd888 irq 19
[ 17.180710] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 17.230594] ata1.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 17.230598] ata1.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 17.297117] ata1.00: configured for UDMA/133
[ 17.762934] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 17.813154] ata2.00: ATA-7: ST3320620AS, 3.AAE, max UDMA/133
[ 17.813157] ata2.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 17.879691] ata2.00: configured for UDMA/133
[ 17.879868] scsi 0:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
[ 17.879991] scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
...
[ 19.703935] ahci 0000:03:00.0: AHCI 0001.0000 32 slots 1 ports 3 Gbps 0x1 imp
l SATA mode
[ 19.703940] ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
[ 19.703945] PCI: Setting latency timer of device 0000:03:00.0 to 64
[ 19.704033] scsi2 : ahci
[ 19.704090] ata3: SATA max UDMA/133 abar m8192@0xfd800000 port 0xfd800100 irq 35
[ 20.342837] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 20.385098] ata3.00: ATA-7: ST3500630AS, 3.AAK, max UDMA/133
[ 20.385100] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 20.443318] ata3.00: configured for UDMA/133
[ 20.443513] scsi 2:0:0:0: Direct-Access ATA ST3500630AS 3.AA PQ: 0 ANSI: 5
...

So there still seems to be a bug in the libata ahci driver 2.6.24-19.41 with the second port of SATA chipsets, as both the ULi and JMicron (JMicron 20360/20363 AHCI Controller [197b:2360] (rev 02)) chipsets on my ASRock 939Dual show no trouble at all with the disk (sda and sdc, respectively) connected to the first port:

$ sudo hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads: 1674 MB in 2.00 seconds = 837.13 MB/sec
 Timing buffered disk reads: 188 MB in 3.01 seconds = 62.44 MB/sec

Cheers,
Lars

[Leann Ogasawara (leannogasawara)]

Hrm, since Dan is the original bug reporter and has commented this is resolved with 2.6.24 I'm going to mark this bug "Fix Released". For those of you still experiencing issues after having tested the 2.6.27 kernel, please open a new report as it's likely you have a slightly different bug.

Jeffrey - I believe I've already followed up with you at your other report.

Thanks.

[Dan Walker (dwalker109)]

Unfortunately, this doesn't seem to be fixed. It is still intermittent, and while I sometimes get high speeds (50MBps), I sometimes get the expected low (10MBps) speeds. As others have pointed out, it does seem to be related to which SATA port the drive is connected to. I do need to properly test this to provide some meaningful info, which I will do ASAP.

Therefore, I will reopen the bug.

[Dan Walker (dwalker109)]

Status was changed as a result of a comment I made, which turned out to be premature. Reopening the bug...

[John Kuang (xiphosurus)]

I have similar problems.

$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 3510 MB in 2.00 seconds = 1754.82 MB/sec
 Timing buffered disk reads: 264 MB in 3.02 seconds = 87.49 MB/sec

hdparm -i shows it in udma6 mode. BUT, copy large files shows a transfer rate of ~5MB/s. Occasionallly, it ranges from 2MB/s to 10MB/s.

I tried some other copying tests and found interesting results. My WD 750gb SATA drive has both ext3 and NTFS partions on it. Since I wasn't sure what was the limiting factor that is make the transfer so slow, I copied a 500MB file in/out for both NTFS and exts into/out of /dev/shm, as it can be assumed the RAM disk has the ultimate read/write speeds. Here are the rough results:

NTFS to NTFS: full speed (~70-80MB/s)
NTFS to /dev/shm: full speed
/dev/shm to NTFS: full speed
ext3 to ext3: SLOW (~5MB/s)
ext3 to /dev/shm: SLOW
/dev/shm to ext3: FULL SPEED

That was the surprising part. Copying from RAM disk to ext3 gave me full speed! So I conclude that the problem is in the read speed. Write speed is perfectly fine. FYI, my ext3 is already mounted with the noatime option. Any comments?

[John Kuang (xiphosurus)]

Oh and of course the other interesting thing was that the NTFS partition was at full speed both read and write even though they are on the same physical drive as the slow ext3 partition.

[darkwalter (darkwalter)]

Hello. I just upgraded to Ibex 64 bit and still have this problem. Transfer speeds are typically 7-8 MB/s between drives. Really annoying. Both drives are ext3, mounted with noatime,nodiratime. I did NOT have this problem with Ibex 32 bit. Write caches are both enabled, and the problem is only when moving files sda => sdb, not the other way around.

IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)

andy@nothing:~$ uname -a
Linux nothing 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux

andy@nothing:~$ sudo hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads: 2250 MB in 2.00 seconds = 1125.59 MB/sec
 Timing buffered disk reads: 230 MB in 3.01 seconds = 76.37 MB/sec

hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
 Model Number: ST3300620AS
 Serial Number: 9QF2K3FA
 Firmware Revision: 3.AAE
Standards:
 Supported: 7 6 5 4
 Likely used: 7
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: 16514064
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 586072368
 device size with M = 1024*1024: 286168 MBytes
 device size with M = 1000*1000: 300069 MBytes (300 GB)
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 16
 Recommended acoustic management value: 254, current value: 0
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * DOWNLOAD_MICROCODE
      SET_MAX security extension
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * SATA-I signaling speed (1.5Gb/s)
    * Native Command Queueing (NCQ)
    * Phy event counters
      Device-initiated interface power management
    * Software settings preservation
Security:
 Master password revision code = 65534
  supported
 not enabled
 not locked
 not frozen
 not expired: security count
 not supported: enhanced erase
Checksum: correct

hdparm -Tt /dev/sdb
/dev/sdb:
 Timing cached reads: 2074 MB in 2.00 seconds = 1036.93 MB/sec
 Timing buffered disk reads: 224 MB in 3.02 seconds = 74.12 MB/sec

hdparm -I /dev/sdb
/dev/sdb:
ATA device, with non-removable media
 Model Number: ST3500630A
 Serial Number: 9QG6Z3F0
 Firmware Revision: 3.AAF
Standards:
 Supported: 7 6 5 4
 Likely used: 7
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: ...

[darkwalter (darkwalter)]

Oh, and it's apparently an intermittent problem. Sometimes I transfer a whole ~800 meg. file at 8 MB/s, and sometimes it skips around between 20-50 MB/s.

[Cubytus (dupa45)]

I have Ibex 32 bits on an Athlon 64 3200+ for the sake of compatibility, and still have the same slow transfer problem *sigh*

cubytus@Le-Grand-Bleu:~$ uname -a
Linux Le-Grand-Bleu 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux
cubytus@Le-Grand-Bleu:~$ sudo hdparm -Tt /dev/sda1
[sudo] password for cubytus:

/dev/sda1:
^C
cubytus@Le-Grand-Bleu:~$ sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads: 1336 MB in 2.00 seconds = 668.18 MB/sec
 Timing buffered disk reads: 176 MB in 3.01 seconds = 58.52 MB/sec
cubytus@Le-Grand-Bleu:~$ sudo hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads: 1392 MB in 2.00 seconds = 695.86 MB/sec
 Timing buffered disk reads: 186 MB in 3.02 seconds = 61.52 MB/sec
cubytus@Le-Grand-Bleu:~$ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
 Model Number: WDC WD2500KS-00MJB0
 Serial Number: WD-WCANK9271428
 Firmware Revision: 02.01C03
Standards:
 Supported: 7 6 5 4
 Likely used: 8
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: 16514064
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 488397168
 device size with M = 1024*1024: 238475 MBytes
 device size with M = 1000*1000: 250059 MBytes (250 GB)
Capabilities:
 LBA, IORDY(can be disabled)
 Standby timer values: spec'd by Standard, with device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 1
 Recommended acoustic management value: 128, current value: 254
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * NOP cmd
    * DOWNLOAD_MICROCODE
      Power-Up In Standby feature set
    * SET_FEATURES required to spinup after power up
      SET_MAX security extension
    * Automatic Acoustic Management feature set
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * SATA-I signaling speed (1.5Gb/s)
    * SATA-II signaling speed (3.0Gb/s)
    * Host-initiated interface power management
    * Phy event counters
    * Software settings preservation
    * SMART Command Transport (SCT) feature set
    * SCT Long Sector Access (AC1)
    * SCT LBA Segment Access (AC2)
    * SCT Error Recovery Control (AC3)
    * SCT Features Control (AC4)
    * SCT Data Tables (AC5)
      unknown 206[12] (vendor specific)
Security:
 Master password revision code = 65534
  supported
 not enabled
 not locked
 not frozen
 not expired: security count
 not supported: enhanced erase
Checksum: correct
cubytus@Le-Grand-Bleu:~$ dmesg | grep ata
[ 0.000000] BIOS-e820: 000000003fff3000 - ...

[CarloBecchi (carlo-becchi-web)]

Hi everyone,
I'm so happy to find this bug report, because it perfectly match my situation, even if I don't have SATA drives on my laptop, but I have indeed a SATA controller, and maybe this could be the key of the issue, and that's why I'm submitting my story.

Almost an year ago a friend gave me a (quite) old Acer Aspire 5510 laptop, 2 Ghz Pentium M, Intel chipset and wireless, and Radeon X700. A perfect machine for Ubuntu, I thought.

The controller is an Intel ICH6, and as far as I know it sports a SATA controller and a PATA one. (dmesg after the boot attached). The disk is a 100 GB Seagate PATA, and also the DVD burner is a PATA one but never worked well, it just (slowly) burn CD, and it does not burn nor mount DVD + or – R and RW.

I use only linux at home, so I wiped out Windows, installing Ubuntu 8.04 Hardy (32 bits).

The disk access was unbelievably slow starting from the boot, the light was always on with almost no flickering, and opening an application was a pain. The computer freezes a lot even if this slowness was not matched by hi cpu usage as it happens when no dma mode is set for the drive. The disk were just slow, no other symptoms.

Having a SATA/PATA controller I've thought I've got a Libata/”combined mode” problem. I cannot set the bios because it's so locked down, but I've tried all kernel options related to this issues and many others, with no luck.

Copying a file from and to the internal disk gave me a transfert rate of 2-4 MEGAbytes/s

As other noticed in this thread, sometime (let's say once a month) I feel the computer faster at boot time, and eventually I get a decent trasfer 16-24 Mb/s but just for few minutes, then the situation reverts back to hell.

Then came the Ibex. And the Ibex was better.

Now I get trasfer stable at 8 Mb/s but it's still very slow (an old Athlon XP at 1400 Mhz I've here it's overall ways faster!)
Actually stable is not the right word: it starts fast, then hangs, then gave me another burst, then another stop and so on during file copy.

I've tried other distros, but them all suffer from the same issue.

Again sometimes after the boot ( but less frequently then in Hardy) I get normal speed.

If I copy from the internal disk to a USB drive the speed is a little faster (13 Mb/s) just because the disk is less stressed (it just read), but the system freezes anyway, and the internal disk light is stuck on.

Comping from external usb disk to the same external disk gave me normal speed, greater then 20 Mb/S.

This computer is almost unusable, I keep it just because I really want this issue solved, so I'm ready and willing to try everything you propose and give back any information you need.

Thank you all, very much.

Other infos on my current setup:
uname -a
Linux carlo-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

sudo hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads: 1688 MB in 2.00 seconds = 843.63 MB/sec

 Timing buffered disk reads: 86 MB in 3.02 seconds = 28.51 MB/sec

/dev/sda:

 Model=ST9100822A , FwRev=3.01 , SerialNo= 3LG1CH85

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% ...

[imercado (im91367)]

Not sure who to thank here, but a combination of implementing this suggestion...

"I have had this problem for a while now and just fixed it by adding "noatime,nodiratime" to the mount options in fstab, as suggested at http://kerneltrap.org/node/14148 ."

...and another suggestion which said (roughly)...

'disable the "Performance" HDD option in your BIOS settings and set it to "Bypass"'

...has solved my poor HDD performance woes on my Dell Latitude D610 running Intrepid!

Poor performance was previously measured with VMWare Workstation suspend/resume feature previously taking several minutes to complete (either storing or loading state from a 1GB virtual machine). Now it always takes less than a minute for suspends, and less than 30 seconds for resumes. Hurrah!

[Kristleifur Daðason (kristleifur)]

Hi,

I had terribly fluctuating speeds on the SATA drives in my machine, and it sometimes the entire OS would stall and sometimes not. I'm not 100% sure this Ubuntu bug report applies to my situation. I'd just like to state, however, that I just updated my BIOS to the latest version, which the manufacturer claims has 'updated super i/o code'. Now all SATA disks perform as expected.

I've got a Gigabyte P35-DS4R, and I installed BIOS version F14C.

[LimCore (limcore)]

Similar for me, BUT - it is slow to at all write to device (even not to file system!)

/dev/sda13:
 Timing cached reads: 1518 MB in 2.00 seconds = 759.03 MB/sec
 Timing buffered disk reads: 186 MB in 3.02 seconds = 61.64 MB/sec

root@limcore:/mnt# dd if=/dev/zero of=/dev/sda13
297645+0 records in
297645+0 records out
152394240 bytes (152 MB) copied, 23.5958 s, 6.5 MB/s

So x10 slower when actually writting data (even to raw device)

uname -a
Linux limcore 2.6.24-22-generic #1 SMP Mon Nov 24 19:35:06 UTC 2008 x86_64 GNU/Linux

 hdparm /dev/sda

/dev/sda:
 IO_support = 0 (default)
16-bit)
 HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
 readonly = 0 (off)
 readahead = 256 (on)
 geometry = 60801/255/63, sectors = 976773168, start = 0

[Petter (pettno)]

Same problem here, with both Asus P5B and P5QL SE mainboards.

Details from the P5QL SE mainboard:

petter@asus:~$ lspci |grep IDE
03:00.0 IDE interface: JMicron Technologies, Inc. JMB368 IDE controller
petter@asus:~$ uname -a
Linux asus 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux
petter@asus:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 4850 MB in 2.00 seconds = 2425.98 MB/sec
 Timing buffered disk reads: 172 MB in 3.56 seconds = 48.30 MB/sec
petter@asus:~$ sudo hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD2500KS-00MJB0, FwRev=02.01C03, SerialNo=WD-WCANK5820205
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

[LimCore (limcore)]

Why this is Medium not High? It affects number of people, and x5 slower hdd makes entire ubuntu work slooow.

[The GuiGuy (linux-finalfiler)]

Can I just add my cry for help on this issue; my wife's tired old PC running ATA/IDE drives is a gazzillion time faster than my gee whizz 3 X 1T SATA drive machine running dual core. A bit of delving after stumpbling across this thread seems to have revealed all. HDD throughput as appalling and CPU usage off the scale. As the prev. poster says, why isn't this escalated to "High"

ASUS M2N-VM DV MOBO.

Ubuntu Intrepid.

[The GuiGuy (linux-finalfiler)]

Re my prev. comments.

I decided to explore this through a process of elimination. The PC had 3 X 1T SATA HDDs (WD, Seagate, Samsung). There is 1 Seagate 320G ATA/IDE, 1 X DVD writer (IDE) and 1 X DVD Writer (SATA).

I took all drives out, leaving only the boot drive (1T Seagate SATA). Progressively I re-introduced all the HDDs/DVDs starting with the SATA drives. Large file transfers realises in excess of 32mbps. This is much better than I was getting and therefore I assume it to be OK.

Then, when I plugged the ATA/IDE DVD in the problems started again. I tried a couple of other IDE HDDs and DVDs with the same result. I changed the ribbon cable, checked settings for optimum. The problem remained.

If I disconnect the IDE device/s SATA performance is OK.

ASUS M2N-VM DV MOBO, nForce 430 chipset, I think.

Not using RAID.

BTW, even my external eSATA docking station works great now.

Hope this helps someone.

Cheers

[Petter (pettno)]

My typical use of a computer is writing code, compilation and test/debugging.

A small test performed with the Asus P5QL SE mainboard:
1) Start "make clean && make" in a terminal (uses >30 minutes, which is slooow compared to other older computers)
2) Run "top" in another terminal

Output from "top":
-------- 8< --------
top - 09:16:34 up 14 min, 3 users, load average: 4.10, 3.40, 1.81
Tasks: 155 total, 2 running, 153 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 0.0%id, 99.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2072260k total, 1245388k used, 826872k free, 25856k buffers
Swap: 0k total, 0k used, 0k free, 637636k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5496 root 20 0 418m 46m 11m R 1 2.3 0:34.00 Xorg
 6100 petter 20 0 21216 3104 1780 S 1 0.1 0:00.52 gnome-screensav
 8956 petter 20 0 2416 1172 876 R 1 0.1 0:00.44 top
    1 root 20 0 2120 1076 640 S 0 0.1 0:01.18 init
-------- 8< --------

"us" was typically <10% and rarely ~30% for a long time (a lot of >90%wa as above) periodically during the half hour or so. When the >90%wa occurs (which can be frequently), far more than a minute (!) can be used on a tiny cpp-file. To my knowledge no other HDD-time-consuming processes are running. Periodically the system seems to be OK, with typically ~50% of the time in "us" and ~50% in "id" (due to usage of only one CPU in the dual core?).

IMHO: a lot of time is spent waiting for I/O to complete. More CPU time should be spent on compiling the code (User CPU time). The Asus P5QL SE mainboard (and a lot of other mainboards?) is not compatible with the current Ubuntu 8.10 (kernel 2.6.27-11).

The trick from the GuiGuy did not work for me. The only units connected to SATA during this test was the HDD (WDC WD2500KS-00MJB0). No IDE devices.

I hope this is relevant for the slow SATA bug. Let me know if I can perform other tests to help solve this issue.

[andre (andre-compufu)]

Hello guys,

I really don't know what to do. I can't even install a native ubuntu in my machine. The overall sys performance is awful.
Now, the only way to use the system is using wubi, but with poor performance and so much noise from the hard drive.
I have a Asus P5K-Premium WI-FI, with a Q6600, 4GB ram and the SAMSUNG HD501LJ .
So, I think I can expect a good performance from my machine :)
I'm using the Jaunty 64bits beta. I tried to use gutsy and intrepid too, with no good news.
What makes me really confuse and sad is that windows vista/xp runs with awesome performance, and no noise.

Here is some info:

uname -a output:

Linux ubuntu 2.6.28-11-generic #38-Ubuntu SMP Fri Mar 27 10:01:17 UTC 2009 x86_64 GNU/Linux

hdparm -tT /dev/sda output:

/dev/sda:
 Timing cached reads: 8346 MB in 2.00 seconds = 4176.84 MB/sec
 Timing buffered disk reads: 238 MB in 3.01 seconds = 78.99 MB/sec

hdparm -i /dev/sda output:

/dev/sda:

 Model=SAMSUNG HD501LJ , FwRev=CR100-12, SerialNo=S0MUJDWQ146326
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

I also tried to recompile my kernel several times, but with no success too.
If I can help, or run some tests, please let me know.
This problem is really annoying, and based on the above info, it's bothering many people.

Thanks,

Andre

[The GuiGuy (linux-finalfiler)]

OK, I'm starting to think this is a serious, serious problem.

Same basic hardware, using SATA devices

SATA
Boot into Windows XP ~25 seconds to get a cursor
Boot into Kubuntu 8.10 (KDE4), ~150 seconds to get a cursor in KDE, Yes kiddies, 150 seconds. Consistently

Ripped the SATA drives out. Replaced with IDE, configured on same hardware.
SATA
Boot into Windows XP ~30 seconds to get a cursor
Boot into Kubuntu 8.10 (KDE4), ~35 seconds

[The GuiGuy (linux-finalfiler)]

Sorry, the heading SATA above the last two lines should have been ATA/IDE. But you knew that, right?

[The GuiGuy (linux-finalfiler)]

It just gets worse; I installed a Pioneer SATA DVD- read/ write device.

Burn speed using Nero or K3B, 1.4X !!??

[Mindaugas (mindedie)]

Same in Jaunty. Sata performance slow. Coping/moving data form root disk sda to others two sdb,sdc only 4-10MB. Moving data between sdb and sdc normal (50-70MB).

mindedie@mindedie-desktop:~$ uname -a
Linux mindedie-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux
mindedie@mindedie-desktop:~$ dmesg | head
[ 0.000000] BIOS EBDA/lowmem at: 0009f000/0009f000
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 (Ubuntu 2.6.28-11.42-generic)
[ 0.000000] Command line: root=UUID=82658bd4-0c50-4815-a528-9223cc582264 ro quiet splash
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] BIOS-provided physical RAM map:

 sudo hdparm -i /dev/sd#

/dev/sda:

 Model=ST3250820AS , FwRev=3.AAE , SerialNo= 9QE150Y2
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?1?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
 * signifies the current active mode

/dev/sdb:

 Model=SAMSUNG HD321KJ , FwRev=CP100-10, SerialNo=S0MQJ1SP200375
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?1?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7
 * signifies the current active mode

/dev/sdc:

 Model=ST3500320AS , FwRev=SD15 , SerialNo= 9QM3Q44T
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?1?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
 * signifies the current active mode

sudo hdparm -tT /dev/sd# on idle system:
/dev/sda:
 Timing cached reads: 2808 MB in 2.00 seconds = 1405.84 MB/sec
 Timing buffered disk reads: 236 MB in 3.03 seconds = 77.81 MB/sec
/dev/sdb:
 Timing c...

[Petter (pettno)]

I guess this is the related kernel bug:
http://bugzilla.kernel.org/show_bug.cgi?id=12309

IMHO: A patch for the current Ubuntu version should be of high priority when this is fixed.

[teo (mbeghini)]

Hi everyone,
                  i have the same problem with the symptoms described by CarloBecchi, also with ubuntu 9.04 with the kernel 2.6.28
My laptop is a Sony Vaio VGN A517B, with a controller

00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)

and a Hitachi SATA disk HTS541080G9SA00

During the use, copying moving files, the disk often freezes, and becomes more slow passing from UDMA5 to UDMA2.

At the beginning these are the conditions:

teo@vaioteo:~$ sudo hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads: 1718 MB in 2.00 seconds = 859.50 MB/sec
 Timing buffered disk reads: 104 MB in 3.03 seconds = 34.30 MB/sec

teo@vaioteo:~$ sudo hdparm -v -i /dev/sda

/dev/sda:
 IO_support = 0 (default)
 readonly = 0 (off)
 readahead = 256 (on)
 geometry = 9729/255/63, sectors = 156301488, start = 0

 Model=HTS541080G9SA00 , FwRev=MB4OC60D, SerialNo= MPBDL0X6GXHU8M
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7538kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 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
 AdvancedPM=yes: mode=0xFE (254) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

After some use and getting worst:

teo@vaioteo:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1566 MB in 2.00 seconds = 783.28 MB/sec
 Timing buffered disk reads: 88 MB in 3.03 seconds = 29.01 MB/sec

teo@vaioteo:~$ sudo hdparm -v -i /dev/sda

/dev/sda:
 IO_support = 0 (default)
 readonly = 0 (off)
 readahead = 256 (on)
 geometry = 9729/255/63, sectors = 156301488, start = 0

 Model=HTS541080G9SA00 , FwRev=MB4OC60D, SerialNo= MPBDL0X6GXHU8M
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7538kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 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
 AdvancedPM=yes: mode=0xFE (254) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

The messages in the log folder show this very quickly degradation:

Apr 27 11:05:57 vaioteo kernel: [ 357.882808] ata1.00: configured for UDMA/100
Apr 27 11:07:33 vaioteo kernel: [ 453.770810] ata1.00: configured for UDMA/100
Apr 27 11:15:28 vaioteo kernel: [ 928.770809] ata1.00: configured for UDMA/100
Apr 27 11:16:28 vaioteo kernel: [ 989.770818] ata1.00: configured for UDMA/100
Apr 27 11:17:00 vaioteo kernel: [ 1021.000054] ata1.00: limiting speed to UDMA/66:PIO4
Apr 27 11:17:00 vaioteo kerne...

[CarloBecchi (carlo-becchi-web)]

Sadly I confirm the problem also on Jaunty, with the same configuration described above.

/dev/sda:
 Timing cached reads: 1744 MB in 2.00 seconds = 872.40 MB/sec
 Timing buffered disk reads: 88 MB in 3.03 seconds = 29.05 MB/sec

/dev/sda:
 IO_support = 0 (default)
 readonly = 0 (off)
 readahead = 256 (on)
 geometry = 12161/255/63, sectors = 195371568, start = 0

 Model=ST9100822A , FwRev=3.01 , SerialNo= 3LG1CH85
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=195371568
 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
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

[The GuiGuy (linux-finalfiler)]

I just want to confirm that after a clean install of jaunty, the problem is severe. My SATA DVD-R burns at < 3x. SATA HDD performance is equally dismal.

[Adam Kessel (ajkessel)]

Same problem here; very slow on internal hard drive with up-to-date Jaunty on Thinkpad x40. hdparm -Tt gives a fraction of throughput that it used to get.

[remi_2 (remi-delmas-3000)]

Hello,

Just to inform you that I'm also hitting this bug with the Jaunty stock kernel 2.6.28 on an Asus M50sv laptop (intel core2duo T9300, 3gb RAM@667, ICH8 chipset, WesternDigital Caviar Blue 500Go SATAII hard drive) (which by the way is really fast under XP/Vista)

hdparm reports figures around 11000Mb/s for cached reads and 78Mb/s for buffered disk reads,

but actually transferring large amount of data from one partition to another on the same disk, or to an external USB or eSATA external drive is limited to 2.5/3Mb/s.

I've tried various bootparams as found in different posts, blacklisting libata, etc. no sucess so far.

[remi_2 (remi-delmas-3000)]

Hi again,

I tried ubuntu 8.10, 8.04, 7.10, opensuse 11.1 and fedora 10 on the same machine and they all reproduce the problem.

[Petter (pettno)]

remi_2: If you are able: try Ubuntu 6.10. It includes the 2.6.17 kernel where some SATA problems (...or... actually... problems related to usage of large i/o buffers) are not present. Something was introduced in 2.6.18 (released in September 2006), and the kernel developers have still not been able to fix this.

[remi_2 (remi-delmas-3000)]

Thanks for the tip, I tried the 6.10 yesterday night but unfortunately it boots straight to busybox, meaning that some other errors occur during the boot process.

Do you think it is possible to downgrade the linux kernel to 2.6.17 via apt while keeping all other 9.04 packages?

Or could I grab the 2.6.17 sources from kernel.org and build a custom kernel to integrate it in my current 9.04?

Anyhow, thanks for you input !

[Petter (pettno)]

remi_2: I managed (a while ago) to install Ubuntu 6.06 with instlux (old historic stuff) on a PC with Asus P5B deluxe mainboard and only SATA HD/CD/DVD devices:
http://sourceforge.net/project/showfiles.php?group_id=151507&package_id=192787

The upgrade instructions from 6.06 to 6.10 has now unfortunately been removed from the version history:
https://help.ubuntu.com/community/UpgradeNotes
(click "Page history" at the bottom of the page and check an older version of the page to find link which does not work anymore)

If I remember correctly I entered a lot of "old-releases" similar to stuff on this page:
https://help.ubuntu.com/community/DapperUpgrades
...but with URL's to somewhere else in the archives.

If you are unsuccessful in upgrading to 6.10 -you should at least be able to test SATA with Ubuntu 6.06.

[Petter (pettno)]

Uh... I almost forgot: you will need to start instlux from windows (e.g. on a small partition).

[remi_2 (remi-delmas-3000)]

Hi, I've compiled and installed the latest stable kernel 2.6.29.3 from kernel.org, and the bug is still present (even worse, transfer rates won't go over 1.5Mb/s).

How can I report this problem to the actual kernel/libata developers? I feel like posting here is not going to make any difference?

The only positive thing is that I've changed the preemption model to preemptible kernel and the timer frequency to 1000Hz and the desktop now feels really snappy.

[dabergman (dabergman)]

Hey.

I had the same problem with my setup. 8 sata disks for storage (single disk, 4x320 and 4x500) and ide (2x200gb raid 1) for the system.
The slow speed on my sata disks just appeared one day like a month ago and I have googled like a maniac in search for a fix. Been checking these comments now and then, but still no fix.

Today my raid1 array "crashed". When I booted, ubuntu said that one of my disks is fubar. Since it's a raid1 array, the other disk is fully functional. I booted like normal from the other disk and I did a fsck on the "crashed" partition. Then I re-added the partition to the array by typing "mdadm --add /dev/md0 /dev/sdi1", where md0 is the raid1 array and sdi1 is the "crashed" ide-drive-partition.

The recreation of the array was successful and I didn't think much of it after that. A few hours later I was unpacking stuff from one of the 500GB drives to my regular windows computer (via samba) and I realized that the speed was back at normal. Just like it was a month ago. Normally when I had the sata speed problem, the unpacking was at around 8-10MB/s. Now I'm at around 30MB/s (through a crappy switch, this is my max throughput).

I have no understanding of how the problem started or how it was fixed, but my problem with the sata speed is gone.

[Kristleifur Daðason (kristleifur)]

Two points
1) This is a serious bug serious, not medium
2) Installing a vanilla Linux kernel from here: https://wiki.ubuntu.com/KernelMainlineBuilds has fixed ALL problems like this on two machines, one 8.10 and one 9.04

!

[Kristleifur Daðason (kristleifur)]

Two points
1) This is a serious bug, not medium
2) Installing a vanilla Linux kernel from here: https://wiki.ubuntu.com/KernelMainlineBuilds has fixed ALL problems like this on two machines, one 8.10 and one 9.04

!

[ngsupb (ngsupb)]

Kristleifur Daðason,

I tried to install 2.6.30, but the problem still exists :(
Only 1.6MB/s copy speed.

Could you detail please which one kernel you installed?

[Kristleifur Daðason (kristleifur)]

@ngsupb,
We used the vanilla versions corresponding to whatever was the stable Ubuntu kernel at the time, for that release. (We didn't go to 2.6.30.)

Here's the Ubuntu-to-vanilla lookup table: http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html

Good luck!

[ngsupb (ngsupb)]

Kristleifur Daðason,

Unfortunately it doesn't fix for me :(

Still the same poor speed while coping large files

[ngsupb (ngsupb)]

I have allocated the problem:

1. Slow transfer file speed happens only when to read from ext3 partition.
2. If I write from some other (I have a fat32 part) to ext3 on the same hdd, the speed is normal.
3. I applies only for large files.

Could someone confirm who has the problem, that coping big files from some other partition to ext3 file system works faster?

[ngsupb (ngsupb)]

sorry for posting. Please delete my comments :)

I found that the problem in my case was because of defragmentation files after downloading them through torrent.

[Shane Rice (shane2peru)]

I also have this problem. Three things to note about transferring files to USB flash drive. 1. When I transfer with Nautilus it is very slow! 2. When I transfer files with GnomeCommander, it is very fast. 3. When I transfer files with command line it is very fast. = I think this could be a problem with Nautilus? If some others could verify the experiments as well, we may be able to help nail this down.

Shane

[The GuiGuy (linux-finalfiler)]

So in the last couple of days kernel 2.6.28-13 arrived. I'd hope it would make a difference.

I suppose it did. Now my mythbuntu box comes to standstill when copying files. Transferring a 1G file between two SATA drives took a blistering 8, read it and weep, 8 minutes!!!

Sorry, I'm loosing it here. Linux is no longer an option.

[Daniel Harvey (daniel.harvey)]

I can confirm that this is a very frustrating bug, and still seems to be affecting lots of us :-) Don't forget to check the upstream bug (linux-kernel-bugs #12309 - http://bugzilla.kernel.org/show_bug.cgi?id=12309). Also, I suggest keeping an eye on what sounds like promising comments on bug #131094 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094) regarding kernel 2.6.31.

[Mindaugas (mindedie)]

2.6.28-13 have no effect (for me).
This bug don't effect live-cd (disks read/write 50-70 MB ).Tested hdd performance on Ubuntu 9.04 8.10 8.04 (both 64bit and 32bit) LIVE-CDs.

[lefty.crupps (eljefedelito)]

> Sorry, I'm loosing it here. Linux is no longer an option.
This bug only affects Ubuntu, don't blame all of Linux and the various distros for this.

[The GuiGuy (linux-finalfiler)]

>This bug only affects Ubuntu, don't blame all of Linux and the various distros for this.

Can we be sure about that? The Ubuntu forums would have me believe that it is a kernel issue..
http://ubuntuforums.org/showthread.php?t=1150108&page=4

If it is Ubuntu specific, I'll make the change. In fact, I have already downloaded Fedora.

Thanks,

[Kristleifur Daðason (kristleifur)]

> Can we be sure about that? The Ubuntu forums would have me believe that it is a kernel issue..
> http://ubuntuforums.org/showthread.php?t=1150108&page=4

> If it is Ubuntu specific, I'll make the change. In fact, I have already downloaded Fedora.

Well, installing a kernel without the Ubuntu patchset fixed things for me. So I'd hazard a guess that it was an Ubuntu issue.

[Kristleifur Daðason (kristleifur)]

Hi,

Bump.

I've now installed the mainline kernel on at least four machines: One Core 2 Duo, one Core 2 Quad and an i7 machine. 64-bit Ubuntu versions 8.10 and 9.04. In all cases, the broken I/O has been fixed by the mainline kernel install.

[andre (andre-compufu)]

which version?
2.6.30 doesn't work for me =(

On Mon, Jul 6, 2009 at 1:04 PM, Kristleifur
Daðason<email address hidden> wrote:
> Hi,
>
> Bump.
>
> I've now installed the mainline kernel on at least four machines: One
> Core 2 Duo, one Core 2 Quad and an i7 machine. 64-bit Ubuntu versions
> 8.10 and 9.04. In all cases, the broken I/O has been fixed by the
> mainline kernel install.
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Kristleifur Daðason (kristleifur)]

> which version?
> 2.6.30 doesn't work for me =(

2.6.27.x works for me on on Ubuntu 8.10,
also 2.6.28 and 2.6.29 and 2.6.30 all work on 9.04.

[Mante (mante)]

I'm using jaunty 64 bit.
Unfortunately I've install a mainline kernel
Linux xxx-desktop 2.6.29-02062906-generic #02062906 SMP Fri Jul 3 10:17:03 UTC 2009 x86_64 GNU/Linux
but speed problem persists. Speed transfer between hard disks below 5Mb/sec.

Below hard disks info.

/dev/sda:

 Model=SAMSUNG SP2504C , FwRev=VT100-50, SerialNo=S09QJ1PP321450
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
--------------------------------------------------------------------------------------------------
/dev/sdb:

 Model=SAMSUNG HD753LJ , FwRev=1AA01113, SerialNo=S13UJDWQ801281
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=32767kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1465149168
 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 *udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

Singular Hard disk performance is standard/
sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 3872 MB in 2.00 seconds = 1936.29 MB/sec
 Timing buffered disk reads: 194 MB in 3.01 seconds = 64.54 MB/sec

/dev/sdb:
 Timing cached reads: 5664 MB in 2.00 seconds = 2833.85 MB/sec
 Timing buffered disk reads: 286 MB in 3.02 seconds = 94.67 MB/sec

[germulvey (gerardmulvey)]

I am noticing that the problem is directional also.
Copying from sdb to sda was about 37.5 MB/s and the other direction sda to sdb was 11.8 MB/s for the same 1.6 GB file.

[germulvey (gerardmulvey)]

additional info for #127
nForce 560 - gigabyte motherboard
amd athlon 64 x2 4400+
ubuntu 9.04 64 bit - update status ~ current

/dev/sda:

 Model=SAMSUNG SP2504C , FwRev=VT100-41, SerialNo=S09QJ1WL915408
 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=488397168
 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 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

root@linger-ger:/home/ger# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
 Model Number: SAMSUNG SP2504C
 Serial Number: S09QJ1WL915408
 Firmware Revision: VT100-41
Standards:
 Used: ATA/ATAPI-7 T13 1532D revision 4a
 Supported: 7 6 5 4 & some of 8
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: 16514064
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 488397168
 device size with M = 1024*1024: 238475 MBytes
 device size with M = 1000*1000: 250059 MBytes (250 GB)
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 16
 Recommended acoustic management value: 254, current value: 128
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * NOP cmd
    * DOWNLOAD_MICROCODE
      SET_MAX security extension
    * Automatic Acoustic Management feature set
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * Segmented DOWNLOAD_MICROCODE
    * SATA-I signaling speed (1.5Gb/s)
    * SATA-II signaling speed (3.0Gb/s)
    * Native Command Queueing (NCQ)
    * Host-initiated interface power management
    * Phy event counters
      DMA Setup Auto-Activate optimization
      Device-initiated interface power management
    * Software settings preservation
    * SMART Command Transport (SCT) feature set
    * SCT Long Sector Access (AC1)
    * SCT LBA Segment Access (AC2)
    * SCT Error Recovery Control (AC3)
    * SCT Features Control (AC4)
    * SCT Data Tables (AC5)
Security:
 Master password revision code = 65534
  supported
 not enabled
 not locked
 not frozen
 not expired: security count
  sup...

[Kristleifur Daðason (kristleifur)]

Hi all,

I was moving disks around on my motherboard because the SATA cables blocked a video card. Two disks were placed on a secondary SATA controller on the motherboard which I hadn't used before. This has caused the slowness to resurface, with the mainline kernel.

Previously, all the disks were on an "82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller", using driver "ahci", capabilities "storage msi pm bus_master cap_list emulated", configuration "driver=ahci latency=0 module=ahci". According to lshw.

In the rearrangement, two disks were placed on a "JMicron 20360/20363 AHCI Controller", also using driver "ahci", capabilities "storage pm pciexpress bus_master cap_list emulated", configuration "driver=ahci latency=0 module=ahci".

Before installing mainline, there was both IO and overall system lag with the Intel controller. With mainline, the Intel behaves fine, but the JMicron turns out to be slow. (To the point where I personally consider it broken.)

I hope this info helps!

[andre (andre-compufu)]

Hello guys,

some news? performance is still awfull, I don't know what to do. This way,
linux's no more an option.

On Fri, Aug 28, 2009 at 8:25 AM, Kristleifur Daðason
<email address hidden>wrote:

> Hi all,
>
> I was moving disks around on my motherboard because the SATA cables
> blocked a video card. Two disks were placed on a secondary SATA
> controller on the motherboard which I hadn't used before. This has
> caused the slowness to resurface, with the mainline kernel.
>
> Previously, all the disks were on an "82801IR/IO/IH (ICH9R/DO/DH) 6 port
> SATA AHCI Controller", using driver "ahci", capabilities "storage msi pm
> bus_master cap_list emulated", configuration "driver=ahci latency=0
> module=ahci". According to lshw.
>
> In the rearrangement, two disks were placed on a "JMicron 20360/20363
> AHCI Controller", also using driver "ahci", capabilities "storage pm
> pciexpress bus_master cap_list emulated", configuration "driver=ahci
> latency=0 module=ahci".
>
> Before installing mainline, there was both IO and overall system lag
> with the Intel controller. With mainline, the Intel behaves fine, but
> the JMicron turns out to be slow. (To the point where I personally
> consider it broken.)
>
> I hope this info helps!
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Petter (pettno)]

This bug with proposals for fix seems very interesting:
https://bugs.launchpad.net/bugs/427210

[Gremlyn1 (gremlyn1)]

Might as well chime in as one more affected. Running an AMD Phenom with a 1TB SATA and have AWFUL speeds for data transfer like everyone else. :(

[Petter (pettno)]

Using the deadline scheduler had no significant effect on my problems (ref the 427210 bug). I give up. AFAIK the Asus P5B and P5QL SE mainboards are not compatible with Ubuntu (and/or the kernel or some I/O stuff used by Ubuntu). I will install Ubuntu on another hopefully compatible box, as I really need to use a linux distro.

BTW: My most recent working Ubuntu version was 6.10. The scheduler stuff seems to help some.

[lefty.crupps (eljefedelito)]

> This way, linux's no more an option.

This bug only seems to affect Ubuntu; there are other Linux options out there.

[andre (andre-compufu)]

Hi,

not so sure...
the same behavior happened when I installed slack 13, fedora and macosx.

On Mon, Sep 14, 2009 at 10:43 AM, lefty.crupps <email address hidden>wrote:

> > This way, linux's no more an option.
>
> This bug only seems to affect Ubuntu; there are other Linux options out
> there.
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[lefty.crupps (eljefedelito)]

> > This bug only seems to affect Ubuntu; there are other Linux options out
> > there.

> the same behavior happened when I installed slack 13, fedora and macosx.

Then it may possibly be a larger issue, as I've not come across this on any other distro, and Mac OSX has completely different technology for kernel and drive access.

[Mindaugas (mindedie)]

https://bugs.launchpad.net/bugs/427210 didn't helped nor others proposals (some just made more problems :D). Live-cd not effected, anyone tested it?

[andre (andre-compufu)]

I tested here too, with no sucess.
Live cd and pen drive performace are ok.

On Mon, Sep 14, 2009 at 12:30 PM, mindedie <email address hidden> wrote:

> https://bugs.launchpad.net/bugs/427210 didn't helped nor others
> proposals (some just made more problems :D). Live-cd not effected,
> anyone tested it?
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Tom (tna5000)]

I guess I'm just adding my two cents here, trying to get this bug noticed. I'm having the same issue, and so is a co-worker who runs pretty much the same setup. If I run windows on my current setup, no problem. Jaunty just seems to be very slow when copying large files between the internal SATA drives and another USB drive.

[The GuiGuy (linux-finalfiler)]

Some good news. In part, at least.

ASUS M2N-VN-DH mobo, Ubuntu Jaunty (9.04) AMD64.

This syste, had been unusable. If I enabled AHCI the system would lock up on the grub loading message. This meant I had to tune down to IDE mode. SATA transfers were awful and general file transfers to USB where even worse.

I'm pleased to report that after the latest kernel updates - 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux" the system now boots with AHCI enabled and xfer speeds are right up there where we'd expect them to be. Importantly high xfer rates are maintained on extended large file transfers. All in all, it's a relief.

Unfortunately the problem persists on another system with an ASUS M3A mobo when running Ubuntu Jaunty (9.04) AMD64m kernel 2.6.28-15. No problem with Fedora, however.

[hessmo (hessmo)]

I am having the exact same issue. It has gone away, and then come back several times since I installed jaunty. I am running the amd64 kernel on a MSI motherboard with ATI graphics. The primary hard disk works great, all the secondary ones I can read from at full speeds, but writes max out the cpu (quad phenom II) and top out at about 6 Mb/s. Very very frustrating. Problem isn't there in windows, and doesn't change if I force the drives into udma 6.

[[e-mail] (jlelusz)]

I'm having the same problem. Jaunty server (32bits version) with Zotac IONITX-A and one sata hdd. During large file copy CPU load goes to the roof and transfer rate drops down. Tested with cp, mc and samba. With samba (and gigabit ethernet) it starts from 65MB/s and drops down to 8-10MB/s within 2-3 seconds (at the same time cpu load goes up). It would be nice to have it sorted, otherwise I'm going to end up with Windows Home Server, because file transfer speed is unacceptable with this bug - and the machine was built to be a file server ;-(
I'm willing to try different things - if someone is willing to point me in the right direction.

[meuns (sylvainmeunier26)]

I have the same problem using Karmic Koala. The first disk works finely but my second hard drive is very slow (~3MB/s).

The uname result :
Linux Void 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

My computer :
Intel Core i7 920
Gigabyte GA-EX58-UD4 (Intel X58 Express)
Seagate Barracuda 7200.12 SATA 3Gb/s - 500 Go 7200 RPM 16 Mo Serial ATA II (1st disk)
Seagate Barracuda 7200.11 SATA 3Gb/s - 1 To 7200 RPM 32 Mo Serial ATA II (2nd disk)

I hope this issue will be solved.

[franck (franck-fleurey)]

Same problem here also with Karmic Koala.
uname : Linux AMD64 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
My sata disks show ok performances if tested with hdparm:

/dev/sdb:
 Timing cached reads: 1912 MB in 2.00 seconds = 956.43 MB/sec
 Timing buffered disk reads: 224 MB in 3.01 seconds = 74.47 MB/sec

/dev/sdc:
 Timing cached reads: 1892 MB in 2.00 seconds = 945.87 MB/sec
 Timing buffered disk reads: 332 MB in 3.00 seconds = 110.64 MB/sec

But if I try to copy a file from one place to another (same disk, same or different partition or different disk) I get steady really poor performances of between 2 and 4 MB/sec.
In addition, the whole system becomes really slow while copying.
This is both using cp in a console or using Gnome and has been for a while.
All my disks/partitions are formated ext3.

My SATA controller is :
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

I hope this problem will get a solution, it is quite difficult to work with big file in the current situation. I would be glad to provide any additional info if it can help.

Franck

[The GuiGuy (linux-finalfiler)]

franck and others, some of us have seen improvement by enabling the proposed ubuntu repositories, especially kernel version 2.6.31-15-generic.

The downside of this approach would be, of course, that something else will break.

[Charles Whittle (napau)]

Howdy! I tried enabling the proposed ubuntu repositories, downloaded and installed all updates; no joy.
Even rebooted computer and did clean remount of external drives. Currently getting a transfer speed
of 70.5 kbs. Have observed that if I cut and paste just a few folders the speed will rise to about 1.2 Mbs.
I am trying to move a large folder that contains around 9,000 folders with about 1.5 million files; total size
is approximately 40 gigabytes. Takes over an hour just to start moving files and the speed is at first
only 100 bytes per second and gradually increases as the number of files left to be moved decreases.
If I move around 1,000 files the move also begins slowly and then speeds up, but never faster than 1.2 Mbs.
I am running Karmic Koala, but have had this problem since Hearty Heron. If someone would be kind
enough to give me the commands I will send additional system information. My computer is a Dell
Optiplex 280 . Thanks!

[Gus (wallace-angus)]

I have what I think is the same problem, and I think I've solved it by installing the mainline kernel:

System:
AMD X2 3800+, 1GB RAM,
/dev/sda 1 TB
/dev/sdb 500 GB
/dev/sdc 500 GB

Symptoms:
Very slow reads (in particular) and writes to/from /dev/sda
hdparm -Tt reported /dev/sda as buffered reads at 50 - 60 MB/sec, however a cp from /dev/sda to /dev/sdb occured at about 6 MB/sec, and a cp to USB occured at 1-2 MB/sec - during which the system was almost non-responsive - top showed iowait at about 60%. Paging in/out of RAM is glacial.
I also tried adding various params to fstab (noatime, etc) and changing the scheduler, to little effect.

Solution (please note, I'm running Ubuntu AMD64 with the nvidia driver blob!! - your mileage may vary):
As recommended by guiguy (thanks!), I downloaded the mainline kernel. I also needed nvidia drivers, so I followed the procedure here (post by Zeroth Eksaz on 2009-06-12):
https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/384639

In a nutshell, I went here
http://archive.ubuntu.com/ubuntu/pool/restricted/n/nvidia-graphics-drivers-180/
and downloaded
nvidia-180-kernel-source_185.18.36-0ubuntu9_amd64.deb
nvidia-180-libvdpau-dev_185.18.36-0ubuntu9_amd64.deb
nvidia-glx-180-dev_185.18.36-0ubuntu9_amd64.deb
nvidia-glx-180_185.18.36-0ubuntu9_amd64.deb
and installed them all with
sudo dpkg -i nvidia*185.18.36*

then I went here
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/
and downloaded
linux-headers-2.6.32-02063202-generic_2.6.32-02063202_amd64.deb
linux-headers-2.6.32-02063202_2.6.32-02063202_all.deb
linux-image-2.6.32-02063202-generic_2.6.32-02063202_amd64.deb
linux-source-2.6.32_2.6.32-02063202_all.deb
and installed them with
sudo dpkg -i linux*2.6.32*

I watched this process via iotop, and had disk reads and writes generally less than 1-2 Mb/sec, with iowaits around 60% and the system almost non-responsive. Booting into the new kernel (with nvidia still working), I can now cp from /dev/sda to /dev/sdb at about 40 MB/sec (though I've yet to extensively test it - it feels a lot more responsive)

Now, I realise I'm running a newer kernel to that from before, so it's not a like-for-like comparison, but I still think it's likely that guiguy's theory (about the problem being with an Ubuntu kernel patch) is likely to be correct. If people can suggest some tests for me to do that might help, I'll try and be of assistance, but this is the main PC in my house, and is needed!
I'm certainly going to be wary about applying future ubuntu kernel upgrades! (might try and stick with the mainline kernel - what a pain!)

Hope this is helpful, and Merry Christmas :-)

[Andy Whitcroft (apw)]

On Wed, Dec 23, 2009 at 10:48:22AM -0000, Gus wrote:

> Now, I realise I'm running a newer kernel to that from before, so it's not a like-for-like comparison, but I still think it's likely that guiguy's theory (about the problem being with an Ubuntu kernel patch) is likely to be correct. If people can suggest some tests for me to do that might help, I'll try and be of assistance, but this is the main PC in my house, and is needed!
> I'm certainly going to be wary about applying future ubuntu kernel upgrades! (might try and stick with the mainline kernel - what a pain!)

You could trivially confirm whether this is an Ubuntu patch by picking the
mainline kernel which the Ubuntu kernel you have is based on. Your full
Ubuntu kernel version can be found with 'cat /proc/version_signature',
and you can map that to a mainline kernel version via the table at the
URL below:

    http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html

So if you have 2.6.31-16.51 then you would want to test with mainline
2.6.31.4. As before the mainline kernel can be found at the URL below:

    https://wiki.ubuntu.com/KernelTeam/MainlineBuilds

Please do report any testing you do back here, please include full version
numbers for both kernels and indicate how you did your testing.

-apw

[Matt (mattjubb)]

I have the same problem as reported many times here - Slow file transfers on one harddisk and the other works fine. hdparm -Tt gives me reasonable speeds. So I tried updating to a newer kernel - linux-image-2.6.32-02063202-generic_2.6.32-02063202_i386.deb

And the result is absolutely no change. This is such an annoying problem

Any other suggestions? Id be very grateful

Matt

[The GuiGuy (linux-finalfiler)]

Matt,
This bug, which has been around since 2007 (it is now 2010!!) was enough for to remove Linux from my desktop computers. My suggestion would be to eat humble pie and buy a copy of Windows 7.

Comparison, same hardware, SATA drives, 1G file; Linux > 5 minutes. Win7 < seconds!!

[lefty.crupps (eljefedelito)]

> This bug, which has been around since 2007 (it is now 2010!!)
> was enough for to remove Linux from my desktop computers

This bug only seems to afect the *buntu distributions; its not present in the upstream Debian distro FYI. Try other Linux distros before jumping ship completely, would be my suggestion.

€l ]€f€

[andre (andre-compufu)]

This bug is really serious.
It doesn't affect only *buntu distributions. I had the same problem
with fedora, debian, slackware.
Unfortunately, the only feasible system was windows 7, witch works very well.

On Mon, Jan 4, 2010 at 12:58 PM, lefty.crupps <email address hidden> wrote:
>> This bug, which has been around since 2007 (it is now 2010!!)
>> was enough for to remove Linux from my desktop computers
>
> This bug only seems to afect the *buntu distributions; its not present
> in the upstream Debian distro FYI.  Try other Linux distros before
> jumping ship completely, would be my suggestion.
>
> €l ]€f€
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[ivanxx (ivan-monodosis)]

I'm on an AMD64 2.6.31-19-generic #56-Ubuntu SMP and experiencing the same problem...

Copying speed for some large files (2-12 Gb per file) from SATA to a USB drive drops to 1,4Mb/s after the first hundreds of Mb are copied. I have to copy around 1Tb, and I'm expecting it to take 8 days!!! It should take around 14 hrs at a decent 20Mb/s speed...

Also the CPU wait states are around 50% all the time, thus the CPU use is 100% and load average 7.5... I suppose there's something wrong down in the kernel, perhaps the buffer for the first hundred Mbs not getting emptied/reused and everything slowing down after that.

Ivan.

[Shane Rice (shane2peru)]

On Wed, 2010-02-17 at 19:17 +0000, ivanxx wrote:

> I'm on an AMD64 2.6.31-19-generic #56-Ubuntu SMP and experiencing the
> same problem...
>
> Copying speed for some large files (2-12 Gb per file) from SATA to a USB
> drive drops to 1,4Mb/s after the first hundreds of Mb are copied. I have
> to copy around 1Tb, and I'm expecting it to take 8 days!!! It should
> take around 14 hrs at a decent 20Mb/s speed...
>
> Also the CPU wait states are around 50% all the time, thus the CPU use
> is 100% and load average 7.5... I suppose there's something wrong down
> in the kernel, perhaps the buffer for the first hundred Mbs not getting
> emptied/reused and everything slowing down after that.
>
> Ivan.
>

Please see post #12 and #14 of this thread
http://ubuntuforums.org/showthread.php?p=8769095#post8769095 if you are
copying to NTFS. This was amazing the difference it made. I don't know
much about how the ext3 fs works, but to sum up those posts, it depends
on how fragmented or non-fragmented the fs is when copying to NTFS. If
you are not copying to NTFS, then just ignore this solution, or read it
if you understand the workings of ext3 or others and perhaps it can put
you on a track that may be the problem with those fs.

Shane

[Jonatan Magnusson (jonatan-cmteknik)]

I have the same problem:

My setup:

 * Gigabyte P35 motherboard
 * 1 WD 500G IDE drive
 * 1 Seagate 500G SATA drive

hdparm ("hdparm -tT") gives 2966/109 MB/sec (cached and buffered reads) for the SATA-drive and 3026/74 MB/sec for the IDE-drive. No problem there.

In Windows XP there is no problem with either drive. Both are fast (~30-40 MB/sec).

Here are the tests I've done:

 * Reading from the IDE-drive is fast (+30 MB/sec)
 * Writing to the IDE-drive is fast (+30 MB/sec)
 * Reading from the SATA drive is SLOW (~3.5 MB/sec)
 * Writing to the SATA drive is fast (+30 MB/sec)

I've done these tests on two partitions of the SATA-drive, and using both FAT32 and ext4.

[Thomas Herve (therve)]

FWIW, I thought I had the same problem. But using mainstream kernel didn't change anything. My real problem is that most of my big files are downloaded via bittorrent, which ends up fragmenting files *a lot*. See http://trac.transmissionbt.com/ticket/849 in transmission bug tracker for example. I used shake (http://vleu.net/shake/) to defragment my disk, and now everything is fast again. I plan to switch to ext4 to see if the problem goes away for future downloads.

[penalvch (penalvch)]

Dan Walker, 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 (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. 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.13-rc4

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.

[Ilya Murav'jov (muravjov-il)]

Hi,

I found this bug is similar to mine (it hurts i386 only). Here is my workaround:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1264707/comments/18 .

Please try it and comment if it works for you.

[Rafael García (rgo)]

It also happens with kernel 3.13.2-031302-generic #201402061638 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.2-trusty/)

Based on previous comment of Ilya Murav'jov I "solved" it temporally with powertop.

I disabled powersaving modes of these devices:

PM ejecutable para dispositivo PCI Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1
PM ejecutable para dispositivo PCI Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller

[penalvch (penalvch)]

Rafael García, 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

[dino99 (9d9)]

closing that old report, as it has not got recent comment.