Re: rfc: OMAP2: micro benchmarks

[Chris Gilbert <chris%dokein.co.uk@localhost>]

Andy Shevchenko wrote:
> On Mon, Jul 21, 2008 at 1:17 PM, Andy Shevchenko
> <andy.shevchenko%gmail.com@localhost> wrote:
>>> P.S. More detailed description about bugs is coming soon...
> 
>> 2. 'connection' and 'close_tcp' produce lock collision when LOCKDEBUG
>> is set (moreover 'close_tcp' produces this issue every time)
>> Reproducibility: 100% (always)
>> 3. Action is required to update kern.maxproc from 532 (16*32+20) at
>> least to 1020 (1000+20)
>> But after this we have got the another lock collision when LOCKDEBUG is set.
>> Reproducibility: 100% (always)
> 
> Rafal  turned my eyes to FAST_SOFTINTS flag.
> However the bug 3) is still reproduced without __HAVE_FAST_SOFTINTS at
> least for me.
> 

bug 3 looks like pmap is accessing something that's not in memory, hence:
netbsd:data_abort_handler+0xc
        scp=0x804784e4 rlv=0x8047808c (netbsd:address_exception_entry+0x50)
        rsp=0x82b4bd98 rfp=0x82b4be00
        r10=0x82b2ea40 r9=0x00000000
        r8=0x81cbd640 r7=0x00000000 r6=0x83d96b68 r5=0x00000001
        r4=0x8051f2c0
netbsd:pmap_create+0x10
        scp=0x8047e3e0 rlv=0x803affac (netbsd:uvmspace_init+0x5c)
        rsp=0x82b4be04 rfp=0x82b4be20
        r6=0x83d95f00 r5=0x80000000
        r4=0x00001000

My best guess is that some memory needs to be wired that isn't, as
paging while accessing pmap structures is probably not the best thing to
do, as it looks like it's causing uvm to relock to hanle the page fault.

I suspect someone needs to repro and investigate further (or turn on
some of the pmap debugging options)

Thanks,
Chris