lkml.org 
[lkml]   [2006]   [Jun]   [5]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 5 Jun 2006 11:01:19 +0200
FromIngo Molnar <>
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-06-05 11:04    [from the cache]
©2003-2008