|
»
[ARM+NFS] panic while copying across NFS
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
[ARM+NFS] panic while copying across NFS
by Marcel Moolenaar-4
::
Rate this Message:
I just ran into the following panic:
panic: vm_page_insert: offset already allocated I was copying a kernel across NFS at the time: orion% cd /nfs/netboot/arm orion% ls kernel-save.bin kernel.bin ubldr orion% sudo cp kernel.bin kernel-save.bin orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin kernel.bin (/usr/obj is on a local disk) With this backtrace: db> bt Tracing pid 26585 tid 100073 td 0xc22bd6f0 db_trace_thread() at db_trace_thread+0x10 scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) rsp=0xc8492878 rfp=0xc8492898 r10=0x00000001 r9=0xc0bb3e94 r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 r4=0xc22bd6f0 db_command_init() at db_command_init+0x404 scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) rsp=0xc849289c rfp=0xc8492940 r6=0x00000002 r5=0x00000000 r4=0xc0b8bb80 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) rsp=0xc8492944 rfp=0xc8492954 r10=0x00000001 r8=0x00000000 r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 db_command_loop() at db_command_loop+0x18 scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) rsp=0xc8492958 rfp=0xc8492a74 r4=0xc849295c X_db_sym_numargs() at X_db_sym_numargs+0x18 scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) rsp=0xc8492a78 rfp=0xc8492aa0 r4=0x000000c0 kdb_trap() at kdb_trap+0x10 scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) rsp=0xc8492aa4 rfp=0xc8492b18 r10=0xc22bd6f0 r9=0x00000000 r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 r4=0x00000000 undefinedinstruction() at undefinedinstruction+0x10 scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) rsp=0xc8492b1c rfp=0xc8492b7c r10=0xc0d147c8 r8=0x00000000 r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 kdb_enter() at kdb_enter+0x14 scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) rsp=0xc8492b80 rfp=0xc8492b94 r5=0xc0b4c994 r4=0x00000100 panic() at panic+0x1c scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) rsp=0xc8492ba8 rfp=0xc8492bc8 vm_page_insert() at vm_page_insert+0x10 scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) rsp=0xc8492bcc rfp=0xc8492bf4 r8=0x00001e03 r7=0x00000061 r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 vm_page_alloc() at vm_page_alloc+0x10 scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) rsp=0xc8492bf8 rfp=0xc8492c48 r10=0x00000000 r9=0x00001000 r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 r4=0xc1e03000 kmem_malloc() at kmem_malloc+0x14 scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) rsp=0xc8492c4c rfp=0xc8492c88 r10=0xc0ac5efc r9=0xc0e36640 r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 r4=0xc0e2d280 uma_zcreate() at uma_zcreate+0x70 scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) rsp=0xc8492c8c rfp=0xc8492cac r10=0xc0e319d8 r9=0x00000020 r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 r4=0xc0e2d280 uma_prealloc() at uma_prealloc+0xd4 scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) rsp=0xc8492cb0 rfp=0xc8492cc8 r7=0x00000002 r6=0xc0e36640 r5=0x00000003 r4=0xc0e2d280 uma_prealloc() at uma_prealloc+0x42c scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) rsp=0xc8492ccc rfp=0xc8492d10 r6=0xc1a5dcc0 r5=0x00000013 r4=0x00000013 uma_zalloc_arg() at uma_zalloc_arg+0x10 scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) rsp=0xc8492d14 rfp=0xc8492d5c r10=0xc4bc0fcc r9=0x00008000 r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 r4=0x00000000 nfsm_uiotombuf() at nfsm_uiotombuf+0x10 scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) rsp=0xc8492d60 rfp=0xc8492ddc r10=0xc3884910 r9=0x00008000 r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 r4=0x00000000 nfs_writerpc() at nfs_writerpc+0x10 scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) rsp=0xc8492de0 rfp=0xc8492e4c r10=0xc3884910 r9=0xc235cca8 r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 r4=0x00000000 nfs_doio() at nfs_doio+0x10 scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) rsp=0xc8492e50 rfp=0xc8492e80 r10=0x00000000 r9=0xc0d13ab4 r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 r4=0xc3884910 nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) rsp=0xc8492e84 rfp=0xc8492ea8 r10=0xc0a870b0 r9=0xc0d1f6c0 r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 r4=0xc22bd6f0 fork_exit() at fork_exit+0x10 scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) rsp=0xc8492eac rfp=0x00000000 r10=0xc0d1f6c0 r8=0x00000104 r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 FYI, -- Marcel Moolenaar xcllnt@... _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
|
|
Re: [ARM+NFS] panic while copying across NFS
by Alexandr Rybalko
::
Rate this Message:
Hi All!
Testing on Orion like board (D-Link DNS-323) I get same result, panic on copy file across NFS. panic: vm_page_insert: offset already allocated backtrace - same. On Fri, 12 Jun 2009 13:19:22 -0700 Marcel Moolenaar <xcllnt@...> wrote: >> I just ran into the following panic: >> >> panic: vm_page_insert: offset already allocated >> >> I was copying a kernel across NFS at the time: >> >> orion% cd /nfs/netboot/arm >> orion% ls >> kernel-save.bin kernel.bin ubldr >> orion% sudo cp kernel.bin kernel-save.bin >> orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin >> kernel.bin >> >> (/usr/obj is on a local disk) >> >> With this backtrace: >> >> db> bt >> Tracing pid 26585 tid 100073 td 0xc22bd6f0 >> db_trace_thread() at db_trace_thread+0x10 >> scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) >> rsp=0xc8492878 rfp=0xc8492898 >> r10=0x00000001 r9=0xc0bb3e94 >> r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 >> r4=0xc22bd6f0 >> db_command_init() at db_command_init+0x404 >> scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) >> rsp=0xc849289c rfp=0xc8492940 >> r6=0x00000002 r5=0x00000000 >> r4=0xc0b8bb80 >> db_skip_to_eol() at db_skip_to_eol+0x1d0 >> scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) >> rsp=0xc8492944 rfp=0xc8492954 >> r10=0x00000001 r8=0x00000000 >> r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 >> db_command_loop() at db_command_loop+0x18 >> scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) >> rsp=0xc8492958 rfp=0xc8492a74 >> r4=0xc849295c >> X_db_sym_numargs() at X_db_sym_numargs+0x18 >> scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) >> rsp=0xc8492a78 rfp=0xc8492aa0 >> r4=0x000000c0 >> kdb_trap() at kdb_trap+0x10 >> scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) >> rsp=0xc8492aa4 rfp=0xc8492b18 >> r10=0xc22bd6f0 r9=0x00000000 >> r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 >> r4=0x00000000 >> undefinedinstruction() at undefinedinstruction+0x10 >> scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) >> rsp=0xc8492b1c rfp=0xc8492b7c >> r10=0xc0d147c8 r8=0x00000000 >> r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 >> kdb_enter() at kdb_enter+0x14 >> scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) >> rsp=0xc8492b80 rfp=0xc8492b94 >> r5=0xc0b4c994 r4=0x00000100 >> panic() at panic+0x1c >> scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) >> rsp=0xc8492ba8 rfp=0xc8492bc8 >> vm_page_insert() at vm_page_insert+0x10 >> scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) >> rsp=0xc8492bcc rfp=0xc8492bf4 >> r8=0x00001e03 r7=0x00000061 >> r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 >> vm_page_alloc() at vm_page_alloc+0x10 >> scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) >> rsp=0xc8492bf8 rfp=0xc8492c48 >> r10=0x00000000 r9=0x00001000 >> r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 >> r4=0xc1e03000 >> kmem_malloc() at kmem_malloc+0x14 >> scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) >> rsp=0xc8492c4c rfp=0xc8492c88 >> r10=0xc0ac5efc r9=0xc0e36640 >> r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 >> r4=0xc0e2d280 >> uma_zcreate() at uma_zcreate+0x70 >> scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) >> rsp=0xc8492c8c rfp=0xc8492cac >> r10=0xc0e319d8 r9=0x00000020 >> r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 >> r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0xd4 >> scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) >> rsp=0xc8492cb0 rfp=0xc8492cc8 >> r7=0x00000002 r6=0xc0e36640 >> r5=0x00000003 r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0x42c >> scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) >> rsp=0xc8492ccc rfp=0xc8492d10 >> r6=0xc1a5dcc0 r5=0x00000013 >> r4=0x00000013 >> uma_zalloc_arg() at uma_zalloc_arg+0x10 >> scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) >> rsp=0xc8492d14 rfp=0xc8492d5c >> r10=0xc4bc0fcc r9=0x00008000 >> r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 >> r4=0x00000000 >> nfsm_uiotombuf() at nfsm_uiotombuf+0x10 >> scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) >> rsp=0xc8492d60 rfp=0xc8492ddc >> r10=0xc3884910 r9=0x00008000 >> r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 >> r4=0x00000000 >> nfs_writerpc() at nfs_writerpc+0x10 >> scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) >> rsp=0xc8492de0 rfp=0xc8492e4c >> r10=0xc3884910 r9=0xc235cca8 >> r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 >> r4=0x00000000 >> nfs_doio() at nfs_doio+0x10 >> scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) >> rsp=0xc8492e50 rfp=0xc8492e80 >> r10=0x00000000 r9=0xc0d13ab4 >> r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 >> r4=0xc3884910 >> nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac >> scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) >> rsp=0xc8492e84 rfp=0xc8492ea8 >> r10=0xc0a870b0 r9=0xc0d1f6c0 >> r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 >> r4=0xc22bd6f0 >> fork_exit() at fork_exit+0x10 >> scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) >> rsp=0xc8492eac rfp=0x00000000 >> r10=0xc0d1f6c0 r8=0x00000104 >> r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 >> >> >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@... >> >> >> >> _______________________________________________ >> freebsd-arm@... mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." -- Alexandr Rybalko <ray@...> _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
|
|
|
|
|
Re: [ARM+NFS] panic while copying across NFS
by Mark Tinguely
::
Rate this Message:
> Hi Mark! > With your patch works fine. > > # dd if=/swap.file of=/mnt/swap.file bs=1M > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 231.294150 secs (4642322 bytes/sec) > > But still slow. Maybe someone know why slow? (Marvell 88F5182 rev A2) Here is what I think is the complete update to the revisions 181296 and 195779 cache fixes. 1) vm_machdep.c: remove the dangling allocations so they do not un-necessarily turn off the cache in the future. (this is the patch that worked for you. 2-3 are two more) 2) busdma_machdep.c: remove the same amount than shadow mapped. 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF is set by a trap when the page is really use. kernel pages should assume it is immediately used. In ARMv5 pmap, we should manage every RAM physical page. Without a profiling the kernel, it would be tough to say were performance issues are orginating. (device driver, in the fs code, or machine level). Ideas about the machine level code: I think freeing the memory from the level page table descriptors for general use should improve things. More usuable RAM is always a good thing. There is some code in trap and other places that looks to see if the level 1 pde is for this memory space or shared memory space. we can keep a few level pde around for forks. downside a fork could fail the 16K contig buffer; which it can in other archs too. This is a pretty big change. There are tests/fixes (switch/pmap) for low vector page that can be removed with define statement for high vector kernels. In fact if we are not sharing the level 1 pd, this set only in pmap initialization. Simple change "#ifdef LOW_VECTOR", minor savings. Are we cleaning caches too much? ARMv6/7 will be a big game changer. Should put a ton of effort into ARMv5, put the effort into optimizing, or do both? Index: arm/arm/vm_machdep.c =================================================================== --- arm/arm/vm_machdep.c (revision 198246) +++ arm/arm/vm_machdep.c (working copy) @@ -169,6 +169,9 @@ sf_buf_free(struct sf_buf *sf) if (sf->ref_count == 0) { TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); nsfbufsused--; + pmap_kremove(sf->kva); + sf->m = NULL; + LIST_REMOVE(sf, list_entry); if (sf_buf_alloc_want > 0) wakeup_one(&sf_buf_freelist); } @@ -449,9 +452,12 @@ arm_unmap_nocache(void *addr, vm_size_t size) size = round_page(size); i = (raddr - arm_nocache_startaddr) / (PAGE_SIZE); - for (; size > 0; size -= PAGE_SIZE, i++) + for (; size > 0; size -= PAGE_SIZE, i++) { arm_nocache_allocated[i / BITS_PER_INT] &= ~(1 << (i % BITS_PER_INT)); + pmap_kremove(raddr); + raddr += PAGE_SIZE; + } } #ifdef ARM_USE_SMALL_ALLOC Index: arm/arm/busdma_machdep.c =================================================================== --- arm/arm/busdma_machdep.c (revision 198246) +++ arm/arm/busdma_machdep.c (working copy) @@ -649,7 +649,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, b KASSERT(map->allocbuffer == vaddr, ("Trying to freeing the wrong DMA buffer")); vaddr = map->origbuffer; - arm_unmap_nocache(map->allocbuffer, dmat->maxsize); + arm_unmap_nocache(map->allocbuffer, + dmat->maxsize + ((vm_offset_t)vaddr & PAGE_MASK)); } if (dmat->maxsize <= PAGE_SIZE && dmat->alignment < dmat->maxsize && Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 198246) +++ arm/arm/pmap.c (working copy) @@ -1643,7 +1643,7 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ pve->pv_pmap = pmap_kernel(); pve->pv_va = pg->md.pv_kva; - pve->pv_flags = PVF_WRITE | PVF_UNMAN; + pve->pv_flags = PVF_WRITE | PVF_UNMAN | PVF_REF; pg->md.pv_kva = 0; TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); @@ -2870,7 +2870,7 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p vm_page_lock_queues(); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, - PVF_WRITE | PVF_UNMAN); + PVF_WRITE | PVF_UNMAN | PVF_REF); pmap_fix_cache(m, pmap_kernel(), va); PMAP_UNLOCK(pmap_kernel()); } else { @@ -3538,7 +3538,7 @@ do_l2b_alloc: if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { KASSERT(pve != NULL, ("No pv")); - nflags |= PVF_UNMAN; + nflags |= PVF_UNMAN | PVF_REF; pmap_enter_pv(m, pve, pmap, va, nflags); } else m->md.pv_kva = va; _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
|
|
Re: [ARM+NFS] panic while copying across NFS
by Marcel Moolenaar-4
::
Rate this Message:
On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > is set by a trap when the page is really use. kernel pages should > assume it is immediately used. This causes problems for me, so I don't think this is quite right. FYI, -- Marcel Moolenaar xcllnt@... _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
|
|
Re: [ARM+NFS] panic while copying across NFS
by Mark Tinguely
::
Rate this Message:
> > On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: > > > 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. PVF_REF > > is set by a trap when the page is really use. kernel pages should > > assume it is immediately used. > > This causes problems for me, so I don't think this is quite right. > FYI, > > -- > Marcel Moolenaar > xcllnt@... Thank-you for the information. Hmmm, how odd. I will give that some thought. To everyone else, I read my last post and a big sorry for incomplete sentences. It was just a quick list of things that could be changed to streamline the machine dependant portion of the code. --Mark Tinguely. _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
|
|
Re: [ARM+NFS] panic while copying across NFS
by Marcel Moolenaar-4
::
Rate this Message:
On Oct 23, 2009, at 9:41 AM, Mark Tinguely wrote: > >> >> On Oct 23, 2009, at 8:22 AM, Mark Tinguely wrote: >> >>> 3) pmap.c: PVF_REF is used to invalidate cache and flush tlb. >>> PVF_REF >>> is set by a trap when the page is really use. kernel pages should >>> assume it is immediately used. >> >> This causes problems for me, so I don't think this is quite right. >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@... > > Thank-you for the information. Hmmm, how odd. I will give that some > thought. > > To everyone else, I read my last post and a big sorry for incomplete > sentences. > It was just a quick list of things that could be changed to > streamline the > machine dependant portion of the code. Also to everyone: There's a huge amount of instability in the ARM VM/PMAP code. Things are slightly better when the L2 cache is configured for write-through, but there's at least 2 issues left: 1. Clustered I/O causes incoherency and pretty much makes the box useless when you want to run what you just built. 2. PMAP panics in one or two places, typically after a few minutes/hours of uptime when doing builds. With a L2 cache the problems are a bit more severe as it adds I-cache incoherency to the mix, which even prevents running init(8). I think w e need to rethink the PMAP layer, because if we keep trying to patch it, performance will probably worse from what it is now. Plus, we'll have to deal with physically indexed and physically tagged caches ASAP, so better modularization helps. FYI, -- Marcel Moolenaar xcllnt@... _______________________________________________ freebsd-arm@... mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@..." |
| Free embeddable forum powered by Nabble | Forum Help |
