Re: CVS commit: src/sys/arch/sandpoint/stand/altboot
On Sun, Oct 30, 2011 at 09:08:33PM +, Frank Wille wrote: Module Name: src Committed By: phx Date: Sun Oct 30 21:08:33 UTC 2011 Modified Files: src/sys/arch/sandpoint/stand/altboot: brdsetup.c dsk.c entry.S fxp.c globals.h nvt.c rge.c skg.c stg.c vge.c Log Message: Added in8() and out8() to access a byte with reorder-protection. Use it in all drivers instead of (volatile uint8_t *). This isn't really an ideal solution, I've have to fight membar instructions embedded into byteswapping accesses on ppc linux. Drivers may want to do several accesses that can be reordered before/after one that matters - so need greater control than enforcing specific membars. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/sandpoint/stand/altboot
David Laight wrote: This isn't really an ideal solution, I've have to fight membar instructions embedded into byteswapping accesses on ppc linux. Drivers may want to do several accesses that can be reordered before/after one that matters - so need greater control than enforcing specific membars. Hm. What would you suggest? Is it better to revert this change? If it is only a matter of performance, I would prefer a slower driver with increased stability. This is just the boot loader, which reads from disks with PIO0. -- Frank Wille
Re: CVS commit: src/sys/arch/m68k
is a nointr pool safe for this pmap? I could be stupid in this area. iirc x86 pmap allocates pv entries from kmem_map to avoid this kind of recursion. I see, but x86 pmap has been changed to use pool_cache(9) with pool_allocator_meta during vmlocking merge. http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/arch/x86/x86/pmap.c.diff?r1=1.2r2=1.3 Is it enough to use pool(9) with pool_allocator_meta (which uses kmem_map), or should I revert that pool change and just make uvm_km_alloc() in old pmap_alloc_pv() use kmem_map instead of kernel_map? --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/m68k
hi, is a nointr pool safe for this pmap? I could be stupid in this area. iirc x86 pmap allocates pv entries from kmem_map to avoid this kind of recursion. I see, but x86 pmap has been changed to use pool_cache(9) with pool_allocator_meta during vmlocking merge. http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/arch/x86/x86/pmap.c.diff?r1=1.2r2=1.3 Is it enough to use pool(9) with pool_allocator_meta (which uses kmem_map), or should I revert that pool change and just make uvm_km_alloc() in old pmap_alloc_pv() use kmem_map instead of kernel_map? although i'm not familiar with this pmap, i think pool_allocator_meta is ok. YAMAMOTO Takashi --- Izumi Tsutsui
Re: CVS commit: src/distrib/utils/sysinst
If TNF can provide a open resolver on a stable IPv6 address for use by sysinst, that'd be great. Do we need only a resolver that answers for things in netbsd.org, to find mirrors, or really a full resolver? pgpkxsOKL8CZH.pgp Description: PGP signature
Re: CVS commit: src/distrib/utils/sysinst
On Mon, Oct 31, 2011 at 11:40:25AM -0400, Greg Troxel wrote: If TNF can provide a open resolver on a stable IPv6 address for use by sysinst, that'd be great. Do we need only a resolver that answers for things in netbsd.org, to find mirrors, or really a full resolver? Depends, I often will install sets I've built myself from a random server. But adding a server (preferably further down the list) that only answers for netbsd.org might be a option some people would prefer to use. Jonathan Kollasch
Re: CVS commit: src/distrib/utils/sysinst
On Mon, Oct 31, 2011 at 03:45:05PM +, Jonathan A. Kollasch wrote: Depends, I often will install sets I've built myself from a random server. But adding a server (preferably further down the list) that only answers for netbsd.org might be a option some people would prefer to use. I wonder if we should add another option to use the ipv6 default gateway as nameserver and otherwise declare this a convenience option for a real world corner case most users won't run into (and not realy care about the actual resolvers used in that case). Martin (but hey, I'm living in a mostly v6 free world still, despite realy hard trying to change that)
