New: About 80% of shutdowns fail (blocking)

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: [email protected]
To: [email protected]
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: [email protected]
ReportedBy: [email protected]
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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

@@ -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();
 

@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>