armv6 pmap patch

Aleksandr Rybalko ray at freebsd.org
Sun Sep 30 21:06:31 UTC 2012 

On Sun, 30 Sep 2012 12:35:55 -0500
Alan Cox <alc at rice.edu> wrote:

> On 09/29/2012 17:49, Aleksandr Rybalko wrote:
> > On Sat, 29 Sep 2012 03:02:21 -0500
> > Alan Cox<alc at rice.edu>  wrote:
> >
> >> On 09/28/2012 08:02, Aleksandr Rybalko wrote:
> >>> On Mon, 10 Sep 2012 11:49:31 -0500
> >>> Alan Cox<alc at rice.edu>   wrote:
> >>>
> >>>>> On 09/10/2012 04:18, Andrew Turner wrote:
> >>>>>> On Sat, 08 Sep 2012 19:01:26 -0500
> >>>>>> Alan Cox<alc at rice.edu>    wrote:
> >>>>>>
> >>>>>>> Can someone here please test this patch to the new armv6 pmap?
> >>>>>>> It eliminates the use of the page queues lock and updates some
> >>>>>>> comments. Similar changes were recently made to the original
> >>>>>>> arm pmap.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Alan
> >>>>>>>
> >>>>>> I have booted FreeBSD with the patch on a Pandaboard and it
> >>>>>> appears to work. Are there any tests you would like me to run?
> >>>>>>
> >>>>> Nothing in particular, since almost anything that you do on the
> >>>>> machine will exercise the changed code.
> >>>>>
> >>>>> There appears to be a lot of unnecessary dropping and
> >>>>> reacquiring of locks around UMA calls in both pmap.c and
> >>>>> pmap-v6.c.  I will try to generate a patch to eliminate this
> >>>>> later in the week.
> >>>>>
> >>>>> Alan
> >>>>>
> >>> Hi Alan and ARM hackers,
> >>>
> >>> Don't know exact, but think it is related to current pmap work.
> >>> So here is two panics observed on R-Pi recently (HEAD @r240985),
> >>> both on attempt to untar ports.tar.gz :)
> >>>
> >> *snip*
> >>
> >> The attached patch should eliminate the panic.  Please let me know
> >> when you've had a chance to test it.
> > I don't know when it done (extracting ports.tar.gz :) ) but it still
> > works w/o panic :)
> >
> > Thanks a lot Alan!
> >
> >
> 
> Great.  I've committed the change.
> 
> Can someone here please test the attached arm v6 pmap patch?  I'd
> like to verify that my earlier efforts to eliminate the lock order
> reversals allows for eliminating all of the unlocking and relocking
> in pmap_alloc_l2_bucket().  If there's a problem, it should be
> apparent immediately.
> 
> Alan
> 

Hi Alan,

Here is result for your attached patch: 
---------------------------------------------------------
Updating motd: /etc/motd is not writable, update failed.
panic: _rw_wlock_hard: recursing but non-recursive rw pmap pv global
@ /usr/1/MIPS_FreeBSD/HEAD/head/sys/arm/arm/pmap-v6.c:2497

KDB: enter: panic
[ thread pid 430 tid 100048 ]
Stopped at      kdb_enter+0x48: ldrb    r15, [r15, r15, ror r15]!
db> bt
Tracing pid 430 tid 100048 td 0xc10a9900
db_trace_self() at db_trace_self+0xc
scp=0xc03348e4 rlv=0xc0334930 (db_trace_thread+0x38)
        rsp=0xc79746c0 rfp=0xc79746cc
db_trace_thread() at db_trace_thread+0xc
scp=0xc0334904 rlv=0xc01293b8 (db_command_init+0x648)
        rsp=0xc79746d0 rfp=0xc79746ec
db_command_init() at db_command_init+0x570
scp=0xc01292e0 rlv=0xc0128a60 (db_skip_to_eol+0x4a0)
        rsp=0xc79746f0 rfp=0xc7974794
        r5=0x00000000 r4=0xc03e101c
db_skip_to_eol() at db_skip_to_eol+0x1d4
scp=0xc0128794 rlv=0xc0128bcc (db_command_loop+0x60)
        rsp=0xc7974798 rfp=0xc79747a4
        r10=0x600001d3 r8=0x00000001
        r7=0x00000000 r6=0x00000000 r5=0xc03e12e4 r4=0xc79747b0
db_command_loop() at db_command_loop+0xc
scp=0xc0128b78 rlv=0xc012b06c (X_db_sym_numargs+0xf4)
        rsp=0xc79747a8 rfp=0xc79748c4
X_db_sym_numargs() at X_db_sym_numargs+0x14
scp=0xc012af8c rlv=0xc0207288 (kdb_trap+0xa4)
        rsp=0xc79748c8 rfp=0xc79748ec
        r4=0xc7974970
kdb_trap() at kdb_trap+0xc
scp=0xc02071f0 rlv=0xc034376c (undefinedinstruction+0x2d0)
        rsp=0xc79748f0 rfp=0xc797496c
        r10=0xe7ffffff r8=0xe7ffffff
        r7=0xc7974970 r6=0x00000000 r5=0x00000000 r4=0x00000000
undefinedinstruction() at undefinedinstruction+0xc
scp=0xc03434a8 rlv=0xc03360e8 (address_exception_entry+0x50)
        rsp=0xc7974970 rfp=0xc79749cc
        r10=0x00000007 r9=0x00000061
        r8=0xc05eed80 r7=0xc10a9900 r6=0xc037bda4 r5=0xc040cd94
        r4=0xc037c5c0
kdb_enter() at kdb_enter+0xc
scp=0xc0206d6c rlv=0xc01d4614 (panic+0xe8)
        rsp=0xc79749d0 rfp=0xc79749e4
        r4=0x00000100
panic() at panic+0x10
scp=0xc01d453c rlv=0xc01d2de0 (_rw_wlock_hard+0x84)
        rsp=0xc79749f8 rfp=0xc7974a1c
_rw_wlock_hard() at _rw_wlock_hard+0xc
scp=0xc01d2d68 rlv=0xc01d2fe4 (_rw_wlock+0xcc)
        rsp=0xc7974a20 rfp=0xc7974a3c
        r8=0xc05eed80 r7=0xc1131000
        r6=0x00000000 r5=0xc03a0a04 r4=0x000009c1
_rw_wlock() at _rw_wlock+0xc
scp=0xc01d2f24 rlv=0xc033df14 (pmap_enter+0x38)
        rsp=0xc7974a40 rfp=0xc7974a6c
        r6=0xc0429d40 r5=0xc0428b70
        r4=0xc03a0a04
pmap_enter() at pmap_enter+0xc
scp=0xc033dee8 rlv=0xc0315600 (kmem_back+0x334)
        rsp=0xc7974a70 rfp=0xc7974ac4
        r10=0x00000101 r8=0x00001000
        r7=0xc051d08c r6=0x00000000 r5=0x00000000 r4=0xc05eed80
kmem_back() at kmem_back+0xc
scp=0xc03152d8 rlv=0xc0315d78 (kmem_malloc+0x244)
        rsp=0xc7974ac8 rfp=0xc7974b00
        r10=0xc051d08c r9=0x00001000
        r8=0x00000101 r7=0xc051f680 r6=0x00001000 r5=0xc039bce0
        r4=0xc7974ad4
kmem_malloc() at kmem_malloc+0xc
scp=0xc0315b40 rlv=0xc030cd88 (uma_print_zone+0x260)
        rsp=0xc7974b04 rfp=0xc7974b10
        r10=0xc7974b4b r9=0xc051e780
        r8=0x00000101 r7=0xc051f680 r6=0x00001000 r5=0x00000001
        r4=0xc051e780
uma_print_zone() at uma_print_zone+0x248
scp=0xc030cd70 rlv=0xc030d044 (uma_print_zone+0x51c)
        rsp=0xc7974b14 rfp=0xc7974b38
uma_print_zone() at uma_print_zone+0x3bc
scp=0xc030cee4 rlv=0xc030eacc (uma_zcreate+0x134)
        rsp=0xc7974b3c rfp=0xc7974b74
        r10=0xc030ced8 r8=0x00000101
        r7=0x00000000 r6=0x00000101 r5=0xc051f680 r4=0xc039aeb8
uma_zcreate() at uma_zcreate+0x74
scp=0xc030ea0c rlv=0xc030f0b4 (uma_prealloc+0x2b0)
        rsp=0xc7974b78 rfp=0xc7974b98
        r10=0x00000016 r9=0x00000101
        r8=0xc051e780 r7=0xc051e780 r6=0x00000101 r5=0xc051f680
        r4=0xc051f680
uma_prealloc() at uma_prealloc+0x120
        rsp=0xc7974b9c rfp=0xc7974bb4
        r7=0xc0500f94 r6=0xc051e780
        r5=0x00000101 r4=0xc051f680
scp=0xc030f190 rlv=0xc0310900 (uma_zalloc_arg+0x540)
        r6=0xc0514348 r5=0x00000013
        r4=0x00000012
uma_zalloc_arg() at uma_zalloc_arg+0xc
scp=0xc03103cc rlv=0xc033d598 (pmap_growkernel+0x8e8)
        r10=0xc0f25594 r9=0xc0592840
        r8=0xc0f25614 r7=0x00000201 r6=0x00000000 r5=0x00000005
        r4=0xc03a0a04
pmap_growkernel() at pmap_growkernel+0x3fc
scp=0xc033d0ac rlv=0xc033df4c (pmap_enter+0x70)
        rsp=0xc7974c58 rfp=0xc7974c84
        r10=0x00000005 r9=0x00000000
        r8=0xc0592840 r7=0x20132000 r6=0xc0429d40 r5=0xc0f25594
pmap_enter() at pmap_enter+0xc
scp=0xc033dee8 rlv=0xc03131fc (vm_fault_hold+0x1638)
        rsp=0xc7974c88 rfp=0xc7974df8
        r10=0xc100c5c0 r8=0x00000000
        r7=0x00000005 r6=0xc0505940 r5=0xc0f254e4 r4=0x00000000
vm_fault_hold() at vm_fault_hold+0xc
scp=0xc0311bd0 rlv=0xc0313804 (vm_fault+0x8c)
        rsp=0xc7974dfc rfp=0xc7974e20
        r10=0xc100c5c0 r9=0xc0f254e4
        r8=0x00000000 r7=0x00000005 r6=0x20132000 r5=0xc0f254e4
        r4=0xc10a9900
vm_fault() at vm_fault+0xc
scp=0xc0313784 rlv=0xc0342320 (prefetch_abort_handler+0x17c)
        rsp=0xc7974e24 rfp=0xc7974ea8
        r8=0xc7974eac r7=0xc10a9900
        r6=0x20132000 r5=0xc03a10ec r4=0xc100c648
prefetch_abort_handler() at prefetch_abort_handler+0xc
scp=0xc03421b0 rlv=0xc03360e8 (address_exception_entry+0x50)
        rsp=0xc7974eac rfp=0xbfffd8fc
        r10=0x20283020 r9=0x202ded21
        r8=0x202deb70 r7=0x00000003 r6=0x00000000 r5=0x20283020
        r4=0x202deb70
panic: _rw_wlock_hard: recursing but non-recursive rw pmap pv global
@ /usr/1/MIPS_FreeBSD/HEAD/head/sys/arm/arm/pmap-v6.c:1163
---------------------------------------------------------

When print backtrace device going into reboot just after last line :)

Thanks Alan!

WBW
-- 
Aleksandr Rybalko <ray at freebsd.org>

More information about the freebsd-arm mailing list