Re: uvm locking inconsistency

2011-06-16 Thread David Laight
On Thu, Jun 16, 2011 at 02:40:06PM +1000, matthew green wrote: LOCKDEBUG is too expensive for a normal kernel. eg, build.sh isn't just a little slower, it's 3-10x slower. Maybe there could be a cheaper lockdebug - that would keep enough info to let you work out deadlocks (etc). (Not having

Re: uvm locking inconsistency

2011-06-16 Thread Manuel Bouyer
On Thu, Jun 16, 2011 at 02:40:06PM +1000, matthew green wrote: On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote: I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC kernels on HEAD (this can be switched off in release branches) Contrary, I think every

Re: uvm locking inconsistency

2011-06-16 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at least) should be enabled in HEAD, but disabled in release kernels. An easy way to catch obvious regression that should never enter a release kernel. The so-called HEAD is

uvm locking inconsistency

2011-06-15 Thread Matthias Drochner
A fresh kernel panics for me with a KASSERT about a lock not held - see attachment. uvm_pgalloc() was called from amap_cow_now() -- the anon is freshly allocated, so the reason for the panic is obvious. (and it seems better to relax the check than to acquire the lock for no good reason) Am I the

Re: uvm locking inconsistency

2011-06-15 Thread Matthias Drochner
m.droch...@fz-juelich.de said: see attachment here is it Forschungszentrum Juelich GmbH 52425

Re: uvm locking inconsistency

2011-06-15 Thread Manuel Bouyer
On Wed, Jun 15, 2011 at 08:02:12PM +0200, Matthias Drochner wrote: A fresh kernel panics for me with a KASSERT about a lock not held - see attachment. uvm_pgalloc() was called from amap_cow_now() -- the anon is freshly allocated, so the reason for the panic is obvious. (and it seems better

Re: uvm locking inconsistency

2011-06-15 Thread Mindaugas Rasiukevicius
Matthias Drochner m.droch...@fz-juelich.de wrote: A fresh kernel panics for me with a KASSERT about a lock not held - see attachment. uvm_pgalloc() was called from amap_cow_now() -- the anon is freshly allocated, so the reason for the panic is obvious. (and it seems better to relax the

Re: uvm locking inconsistency

2011-06-15 Thread Jukka Ruohonen
On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote: I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC kernels on HEAD (this can be switched off in release branches) Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at least) should be enabled in

re: uvm locking inconsistency

2011-06-15 Thread matthew green
On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote: I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC kernels on HEAD (this can be switched off in release branches) Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at least) should be enabled

Re: uvm locking inconsistency

2011-06-15 Thread Masao Uebayashi
On Thu, Jun 16, 2011 at 1:34 PM, Jukka Ruohonen jruoho...@iki.fi wrote: On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote: I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC kernels on HEAD (this can be switched off in release branches) Contrary, I think every