Fw: [Bugme-new] [Bug 13366] New: About 80% of shutdowns fail (blocking)

Fw: [Bugme-new] [Bug 13366] New: About 80% of shutdowns fail (blocking)

[Andrew Morton]

Guys, I'm still in Australia and won't be much use until next week.  We
have a post-2.6.29 regression here, something to do with mlockall() and its
cross-CPU LRU draining.  Could someone please take a look?

Thanks.


Begin forwarded message:

Date: Sat, 23 May 2009 00:58:25 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 13366] New: About 80% of shutdowns fail (blocking)


http://bugzilla.kernel.org/show_bug.cgi?id=13366

           Summary: About 80% of shutdowns fail (blocking)
           Product: Process Management
           Version: 2.5
    Kernel Version: 2.6.30-rc6+latest git patches
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: blocking
          Priority: P1
         Component: Other
        AssignedTo: process_other@kernel-bugs.osdl.org
        ReportedBy: mrb74@gmx.at
        Regression: Yes


Created an attachment (id=21499)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=21499)
Screenshot of kernel crash output.

When the system shuts down/reboots nearly every shutdown stops when trying to
kill all processes with killall5. Pressing the power button has no effect in
most cases. Only the magic key sequences work.
This problem occures since 2.6.30-rc6. 2.6.30-rc5 had no problems with shutting
down/rebooting.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Fw: [Bugme-new] [Bug 13366] New: About 80% of shutdowns fail (blocking)

[Hugh Dickins]

A git-bisect would indeed be worthwhile; but looking through the diff
between 2.6.30-rc5 and 2.6.30-rc7 didn't show any likely candidates -
I wonder if this will turn out to be something more elusive.

Is this an Acer Aspire One?  Looks rather like it: I tried building
your kernel (on openSUSE rather than Ubuntu) on mine, and running it:
no luck reproducing your issue here.

I doubt this has got much to do with mlockall() or lru_add_drain_all()
themselves: it looks rather as if an events thread has "gone away".

Would you mind applying the hacky patch below, and posting the
screenshot from shutdown?  I assume from the fact that you posted
a photo, that nothing useful gets out to the logs: so here I'm trying
to leave just the "events/0" and "events/1" stacktraces onscreen.

--- 2.6.30-rc7/kernel/hung_task.c	2009-04-08 14:59:26.000000000 +0100
+++ linux/kernel/hung_task.c	2009-05-25 18:45:11.000000000 +0100
@@ -98,7 +98,7 @@ static void check_hung_task(struct task_
 	printk(KERN_ERR "\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
 			" disables this message.\n");
 	sched_show_task(t);
-	__debug_show_held_locks(t);
+	show_state_filter(512);
 
 	touch_nmi_watchdog();
 
--- 2.6.30-rc7/kernel/sched.c	2009-05-09 09:24:35.000000000 +0100
+++ linux/kernel/sched.c	2009-05-25 19:08:05.000000000 +0100
@@ -6514,13 +6514,14 @@ void show_state_filter(unsigned long sta
 		 * console might take alot of time:
 		 */
 		touch_nmi_watchdog();
-		if (!state_filter || (p->state & state_filter))
+		if ((state_filter == 512 && !strncmp(p->comm, "events/", 7)) ||
+		    !state_filter || (p->state & state_filter))
 			sched_show_task(p);
 	} while_each_thread(g, p);
 
 	touch_all_softlockup_watchdogs();
 
-#ifdef CONFIG_SCHED_DEBUG
+#ifdef CONFIG_SCHED_DEBUG_NOT
 	sysrq_sched_debug_show();
 #endif
 	read_unlock(&tasklist_lock);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>