I upgarded my kernel from 2.6.17-r8 to 2.6.18-r2 (and later 2.6.18-r3) and my hard drive went much slower. I use gentoo-sources I recompiled my kernel using "make oldconfig" and chosen the default for every question, but still same problem. here is the output of diff between the two files http://achrome.photos.free.fr/tmp/diff.txt I am on AMD64 (Core 2 Duo E6300 not -yet- overclocked). My motherboard is a Gigabyte 965P-DS4. The hard drive is a western digital raptor 36Go SATA pluged on the ICH8R port (set as AHCI in the bios) No other drive except a IDE CDRW on the Jmicron port. I performed the following test. I did an emerge -f vanilla-sources and then for each kernel : 1/ time emerge -v vanilla-sources 2/ time emerge -C vanilla sources The results were the following : 2.6.18-r3 1/ Real 10m52s User 37s Sys 44s 2/ Real 14m52s User 13s Sys 49s 2.6.17-r2 1/ Real 02m35s User 37s Sys 1m34s 2/ Real 02m07s User 15s Sys 1m48s
Please attach dmesg from both kernels
Created attachment 103567 [details] dmesg output in diff form for 2.6.17-r8 and 2.6.18-r2 dmesg issued just after login.
Please actually attach the two logs, your strange diff is hard to read and truncates lines
Created attachment 104241 [details] Dmesg for 2.6.17-r8
Created attachment 104242 [details] Dmesg for 2.6.18-r2
Nothing stands out. Is this still reproducible on the latest development kernel, currently 2.6.20-rc6?
No, It seems that the problem has been solved in 2.6.20-rc6 time emerge -v vanilla-sources gives me 2m39s | 37s | 1m35s However, as I use stable gentoo-sources I am still stuck to 2.6.17 on a "normal speed computer" or 2.6.18 with my IDE CD-RW and Thermal sensors working on a sluggish computer... This is not totally satisfying although I understand why this will probably not be fixed.
Thanks for testing. If you are keen, there are a couple of things you can try: Here is a list of changes to ahci.c : http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/ata/ahci.c;h=e3c7b312287af7c810357937bbd5a0738ecfd00f;hb=HEAD For each change, click 'commitdiff' then 'raw' to get a patch. You could locate the first patch which is NOT present in 2.6.18, and then incrementally apply that one and the ones above it on top of 2.6.18 until you find the one which makes your disks go fast again. (the above assumes that the slowdown was fixed by a patch modifying ahci.c which although likely is not necessarily true) The other approach is an 'inverted bisection' which is a more reliable bet at finding the fix but is very time consuming. http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ Mark 2.6.18 as bad and 2.6.19 as good. Then, for every kernel it gives you, if it slow then mark it as GOOD and if it is fast then mark it as BAD. Eventually it will give you the 'first bad commit' which is actually the patch which solved the issue.
> Mark 2.6.18 as bad and 2.6.19 as good should have been: Mark 2.6.18 as good and 2.6.20-rc6 as bad
It would also be good to test 2.6.19, as that version will be going stable soon and may well not suffer the issue described here.
gentoo-sources-2.6.20 is now in portage
