Messages in this thread | | | Date | Sat, 20 Feb 2010 15:42:56 +0800 | Subject | Re: [2.6.33-rc5] Weird deadlock when shutting down | From | Dave Young <> |
| |
On Fri, Feb 19, 2010 at 2:45 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Thu, 2010-02-18 at 08:31 -0800, Linus Torvalds wrote: > >> > > halt/4071 is trying to acquire lock: >> > > (s_active){++++.+}, at: [<c0000000001ef868>] >> > > .sysfs_addrm_finish+0x58/0xc0 >> > > >> > > but task is already holding lock: >> > > (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: >> [<c0000000004cd6ac>] >> > > .lock_policy_rwsem_write+0x84/0xf4 >> > > >> > > which lock already depends on the new lock. >> >> You don't have a full backtrace for these things? > > No, it deadlocks right there, unfortunately. > >> We've had lots of trouble with the cpu governors, and I suspect the >> problem isn't new, but the lockdep warning is likely new (see commit >> 846f99749ab68bbc7f75c74fec305de675b1a1bf: "sysfs: Add lockdep >> annotations >> for the sysfs active reference"). >> >> So it is likely to be an old issue that (a) now gets warned about and >> (b) might have had timing changes enough to trigger it. > > Well, it used to not deadlock and actually shut down the machine :) So > in that sense it's definitely new. It might have printed a lockdep > warning before, which you wouldn't normally see since the machine turns > off right after this.
before shutdown, you can: echo N > /proc/sys/kernel/printk_delay to see the printk messages, N is 0-10000 in milliseconds
> >> I suspect it is G5-specific (or specific to whatever CPU frequency >> code >> that gets used there), since I think we'd have had lots of reports if >> this >> happened on x86. > > Yeah, that's puzzling me as well. > > johannes >
-- Regards dave -- 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/
| |