Messages in this thread | | | Date | Mon, 5 Jun 2006 11:01:19 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH] request_irq(...,SA_BOOTMEM); |
| |
* Andrew Morton <akpm@osdl.org> wrote:
> And yes, the mutex code will (with debug enabled) unconditionally > enable interrupts. ppc64 tends to oops when this happens, in the > timer handler (so it'll be intermittent...)
hm, i sent a patch to fix that, long time ago.
> But looking at > work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch > I realise I don't understand it. We only go into the irq-enabling > code in the case of contention, and there cannot be contention in this > case?
in the debug case we go into the 'slowpath' all the time - so that we can do the debug checks under the mutex lock.
if we get real contention then we have a might_sleep() check that will catch that.
i'd suggest to push work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch upstream - i thought we agreed that while it's a bit hacky and slows the mutex code down a bit, it's not practical right now to forbid uncontended mutex_lock() in early init code?
Ingo - 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/
| |