Summary: | Since upgrade to gentoo-sources 2.6.17-r4 CD-ROM/DVD-ROM copying slow | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ryan Newberry <brnewber> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | VERIFIED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=7027 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
lspci output on my system
2.6.16-r13 dmesg output 2.6.17-r4 dmesg output |
Description
Ryan Newberry
2006-07-29 14:38:58 UTC
Created attachment 93024 [details]
lspci output on my system
Created attachment 93025 [details]
2.6.16-r13 dmesg output
Created attachment 93026 [details]
2.6.17-r4 dmesg output
Can you reproduce the bug using vanilla-sources-2.6.17? I was in fact able to reproduce the same problem in vanilla-sources-2.6.17.7. Is this reproducible on the latest development kernel, currently 2.6.18-rc4? Bug is verfied to occur in vanilla-sources-2.16.18_rc4 Would you be able to take some measurements so that we have numbers to work with? Time how long it takes to copy a file on 2.6.16, and then time how long it takes to copy the same file on 2.6.17 At that point, you need to file a bug upstream at http://bugzilla.kernel.org clearly stating that 2.6.16 worked ok *and* 2.6.18-rc4 is still affected. If you have a lot of time and patience, you could find the exact patch which introduces this bug by testing approximately 13 kernels. See http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ Use 2.6.16 as good and 2.6.17 as bad. Given that this is really time consuming it might be worth simply reporting the bug upstream first, and saving this as a last resort method if no solutions are immediately obvious after say 1 week. *sigh* After trying to get some hard numbers on this, it seems that every application except the cd ripper I use isn't suffering from a slow down. And the great thing about the cd ripper I'm using is that I wrote it. Sound Juicer has no change in performance. As this is obviously an application level bug, does anyone know what might cause this behavior in the ripper? I'm sort of at a loss as to how to fix it... git bisect says this patch is what is causing the changed behavior 9430d58e34ec3861e1ca72f8e49105b227aad327 is first bad commit commit 9430d58e34ec3861e1ca72f8e49105b227aad327 Author: Mike Galbraith <efault@gmx.de> Date: Wed Mar 22 00:07:33 2006 -0800 [PATCH] sched: remove sleep_avg multiplier Remove the sleep_avg multiplier. This multiplier was necessary back when we had 10 seconds of dynamic range in sleep_avg, but now that we only have one second, it causes that one second to be compressed down to 100ms in some cases. This is particularly noticeable when compiling a kernel in a slow NFS mount, and I believe it to be a very likely candidate for other recently reported network related interactivity problems. In testing, I can detect no negative impact of this removal. Signed-off-by: Mike Galbraith <efault@gmx.de> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> :040000 040000 28d2d8f53ab7b5dd89e846f2dcc107ce88cb695f 780a13c0f8ba5465db79c668 This has been filed upstream here http://bugzilla.kernel.org/show_bug.cgi?id=7027 will track upstream bug Not a kernel bug |