I've been getting this since -rc1. It's still present in -rc2, so I thought I'd bug some people. Everything seems to be working fine. I'm not sure who's to blame here so I've added a few people to CC
Hmm. The problem is that blk_remove_plug() does a non-atomic queue_flag_clear(QUEUE_FLAG_PLUGGED, q); without holding the queue lock. Now, sometimes that's ok, because of higher-level locking on the
(Added LKML CC) (I could be perverting this report a bit by reporting something possibly not related, but I have a gut feeling about this..) So I applied Neil's patch which is now upstream to 2.6.26-
Do this on the console (and having a serial console or working netconsole is a wonderful thing to log it, because otherwise it will generally just scroll off the screen), and trigger SysRQ-w. That du
Another thing to try is to enable lock debugging, and have CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y CONFIG_DEBUG_LOCKDEP=y in y
I actually had the opposite problem, too little was showing. I guess this is because the log level the "SysRq : Show Blocked State" bit goes out on is higher than the level of the actual result, so i
Ahh, yeah, I hate how all the distro's hide the default messages. Bad, bad. Ok, looks like block device breakage, possibly MD-related. Looks like something is waiting for IO to complete, and it never
I did a git revert on this and manually fixed up the conflicts; I also reverted Neil's patch. Unfortunately (though the WARNING is still gone) it doesn't fix the hang. -- Cheers, Alistair. 137/1 Warr
Btw, just that function has a missing GFP_NOFS and a too large allocation which were fixed by Dave Chinner but aren't in mainline yet. Can you check whether it still happens with the patch below? Att