[lkml]   [2009]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/12] Per-bdi writeback flusher threads v7
> > I have been playing with v7 since your sending and after a while
> > (short on laptop, longer on desktop, a few hours), writeback doesn't
> > seem to work anymore. Manual call to sync hangs (process in D state)
> > and Dirty value in meminfo gets growing. As previous versions had
> > been heavily tested, I guess there is some regression in v7.

> Not good, the prime suspect is the sync notification stuff. I'll take
> a look and get that fixed. You didn't happen to catch any sysrq-t back
> traces or anything like that? Would be interesting to see where
> bdi-default and the bdi-* threads are stuck.

No, as I was doing many things at the same time and not exclusively
debugging, I just rebooted hard and went back to an upatched kernel when
the problems occured. But I noticed only bdi-default was alive, the
other bdi-* threads had disappeared and the sync commands I had tried
were all in D state. Also I tried to reinstall a kernel .deb (these
systems are Debian) and this got stuck guring installation, when probing
grub config (do not know if there is some sync syscall inthere).

Can try to go further tomorrow but will not have a lot of time...

> Can you send me your .config and a dmesg from a booted system? Any
> kernel, doesn't have to be the writeback kernel.

Ok, I am attaching corresponding config and dmesg from the desktop
system (the laptop which reproduces the problem more easily is at the
office so not reachable until tomorrow).

Damien Wyart
[unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream]
 \ /
  Last update: 2009-05-26 19:13    [W:0.054 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site