Date: Mon, 1 Oct 2012 00:06:19 +0300 From: Aleksandr Rybalko <ray@freebsd.org> To: Alan Cox <alc@rice.edu> Cc: "arm@freebsd.org" <arm@freebsd.org> Subject: Re: armv6 pmap patch Message-ID: <20121001000619.12f2b230.ray@freebsd.org> In-Reply-To: <506882FB.9060507@rice.edu> References: <504BDC56.3060607@rice.edu> <20120910211817.2d8a340d@fubar.geek.nz> <504E1A1B.90101@rice.edu> <20120928160227.99d2b126.ray@dlink.ua> <5066AB0D.6000901@rice.edu> <20120930014939.9d277f0d.ray@freebsd.org> <506882FB.9060507@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Sep 2012 12:35:55 -0500
Alan Cox <alc@rice.edu> wrote:
> On 09/29/2012 17:49, Aleksandr Rybalko wrote:
> > On Sat, 29 Sep 2012 03:02:21 -0500
> > Alan Cox<alc@rice.edu> wrote:
> >
> >> On 09/28/2012 08:02, Aleksandr Rybalko wrote:
> >>> On Mon, 10 Sep 2012 11:49:31 -0500
> >>> Alan Cox<alc@rice.edu> wrote:
> >>>
> >>>>> On 09/10/2012 04:18, Andrew Turner wrote:
> >>>>>> On Sat, 08 Sep 2012 19:01:26 -0500
> >>>>>> Alan Cox<alc@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@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121001000619.12f2b230.ray>