Date: Mon, 01 Oct 2012 10:38:49 -0500 From: Alan Cox <alc@rice.edu> To: Aleksandr Rybalko <ray@freebsd.org> Cc: "arm@freebsd.org" <arm@freebsd.org> Subject: Re: armv6 pmap patch Message-ID: <5069B909.4040300@rice.edu> In-Reply-To: <20121001000619.12f2b230.ray@freebsd.org> 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> <20121001000619.12f2b230.ray@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/30/2012 16:06, Aleksandr Rybalko wrote: > 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. Thanks! This tells me what I needed to know. Alan > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5069B909.4040300>