Messages in this thread | | | Date | Mon, 07 Jul 2003 12:37:47 +1000 | From | Nick Piggin <> | Subject | Re: anticipatory scheduler merged |
| |
Brandon Low wrote:
>On Sat, 07/05/03 at 13:33:34 -0700, Andrew Morton wrote: > >>- These changes have been well tested, but it is five months work and >> over 100 patches. There's probably a bug or two. If you suspect that >> something has gone wrong at the block layer (lots of tasks stuck in D >> state) then please retest with `elevator=deadline'. >> >>Thanks. >> > >I am seeing these D tasks when running 2.5.74-mm2 under a heavy seeking >load (compiling application, untarring kernel, and filesharing >simultaneously) on a slow (laptop 4200RPM) hdd. I find that after about >10 uptime when I start throwing on the seeking loads one or all of them >go to D state and any new disk IO is either blocked or very slow. > >I have tested with elevator=deadline and have been unable to reproduce. > >Any further testing or debugging you need me to do I can probably do >(but I'm not terribly knowledgable so I'll need step by step for said >testing). Thanks! > >
OK, so the disk is IDE, and you aren't using ide-scsi? Please compile the kernel with "Magic SysRq key" config option enabled. Its in the Kernel hacking submenu.
Then repeat the system freeze, and press alt+sys rq+t. Run dmesg | less to get the task trace. You'll get a lot of lines like this: bash S 00000001 627 625 626 (NOTLB) followed by their call traces. Copy the call trace of one or two tasks that have a D following their name. Then post it here.
Oh and you'll probably have to run dmesg and less to get them into cache before the system freezes!
Thanks, Nick
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |