Messages in this thread | | | Date | Mon, 6 Feb 2012 09:25:01 +0800 | Subject | Re: [BUG 3.3-rc2] spinlock trylock failure on UP on CPU#0 | From | Shaohua Li <> |
| |
2012/2/6 Linus Torvalds <torvalds@linux-foundation.org>: > Ok, interesting. You're triggering the issue because you have a UP > build with the spinlock debugging code enabled. > > On Sun, Feb 5, 2012 at 12:57 PM, Knut Petersen > <Knut_Petersen@t-online.de> wrote: >> Booting 23783f817bceedd6d4e549385e3f400ea64059e5 I get the following trace >> an AOpen i915GMm-hfs with Pentium-M Dothan: > > This is probably the same "technically legal" code that LOCKDEP also > is unhappy about - the nested fast path release. We do a trylock on > the queue lock while we already are holding the queue lock > recursively. > > Jens, Tejun - the crazy-ass games that this code is playing is clearly > messing not just with lockdep, it's messing with some very reasonable > spinlock sanity checks on UP (which just boil down to "a spinlock > should never have contention on UP") > > Any chance of sanitizing this all? I just sent out a debug patch, please try: http://marc.info/?l=linux-kernel&m=132849146702770&w=2 -- 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/
| |