On Thu, 12 Apr 2007, Chris Gilbert wrote:
>
> can you try a non-lockdebug kernel with:
> option ARM_LOCK_CAS_DEBUG

For what it's worth, this didn't change anything. Event counters look 
like:

db> show event
evcnt type 1: vic2 irq 35 = 467
evcnt type 1: vic2 irq 39 = 723
evcnt type 1: vic2 irq 52 = 3
evcnt type 0: uvmmap ukh_alloc = 5
evcnt type 0: uvmmap uke_free = 13
evcnt type 0: uvmmap uke_alloc = 210
evcnt type 0: uvmmap mlk_hint = 830
evcnt type 0: uvmmap mlk_call = 1461
evcnt type 0: uvmmap map_call = 415
evcnt type 0: uvmmap knomerge = 141
evcnt type 0: uvmmap kbimerge = 2
evcnt type 0: uvmmap kbackmerge = 174
evcnt type 0: uvmmap unomerge = 82
evcnt type 0: uvmmap ubackmerge = 16
evcnt type 0: vmcmd kills = 8
evcnt type 0: vmcmd extends = 1
evcnt type 0: vmcmd calls = 35
evcnt type 0: _lock_cas success = 2452
evcnt type 1: soft clock = 467
evcnt type 1: soft net = 508
evcnt type 1: soft serial = 3

..which doesn't mean a lot to me. :-)

I couldn't just add LOCKDEBUG to pmap.c only -- it fails to compile with 
undefined references to _simple_lock etc -- a quick grep suggests the 
reason is that kern/subr_lockdebug.c and kern/kern_lock.c are missing the 
options. Adding them there too lead to new undefined references, so I 
didn't chase further down that lane.

If yamt-idlelwp is about to be merged RSN anyway, I suppose the most 
useful thing now would be to see if that branch exhibits the same problem, 
before chasing further?

/ali:)