Messages in this thread Patch in this message | | | Subject | Re: [PATCH 2/2] Futex non-page-pinning fix | From | Dave Hansen <> | Date | 02 Sep 2003 18:54:51 -0700 |
| |
On Tue, 2003-09-02 at 18:16, Andrew Morton wrote: > Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > I don't know of a rule which says "thou shalt not wake a random thread > > in the kernel": for all I know wierd things like CPU hotplug or > > software suspend may do this in the future. > > pdflush is sensitive to that. It emits angry squeaks if unexpectedly woken. > > And up until a couple of months ago there were sporadic squeaking reports, > but they seem to have gone away.
I still run into the pdflush problem once a month or so, but only with boxes that are up for a week or more. It usually takes the box down if for no other reason than it's too busy prink()ing to do anything else. I haven't been able to sysrq it and the particular box that it happens on doesn't like NMIs so kgdb and the NMI oopser are out.
Are there any good reasons not to do something like the attached patch? It would at least keep pdflush from evicting everthing interesting that may have preceded it in dmesg. -- Dave Hansen haveblue@us.ibm.com --- mm/pdflush.c.orig Tue Sep 2 18:50:39 2003 +++ mm/pdflush.c Tue Sep 2 18:52:11 2003 @@ -112,7 +112,11 @@ spin_lock_irq(&pdflush_lock); if (!list_empty(&my_work->list)) { - printk("pdflush: bogus wakeup!\n"); + static int wakeup_count = 100; + if (wakeup_count > 0) { + wakeup_count--; + printk("pdflush: bogus wakeup!\n"); + } my_work->fn = NULL; continue; } | |