Re: Still getting errors in vfs_vnops.c after updating

On Fri, Nov 30, 2007 at 03:33:27PM -0800, Paul Goyette wrote:
> 
> But then I get the following error:
> 
> #   install  /usr/obj/destdir/amd64/dev/MAKEDEV
> cd /usr/obj/objdir/amd64/etc && 
> /usr/obj/tooldir/x86_64/amd64/bin/x86_64--netbsd-install  -N /usr/src/etc 
> -c -p -r -T etc_pkg -o root -g wheel -m 555  MAKEDEV 
> /usr/obj/destdir/amd64/dev
> x86_64--netbsd-install: MAKEDEV: stat: No such file or directory

Check that you haven't got some generated files polluting your source tree.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Re: Still getting errors in vfs_vnops.c after updating

Weird!

It seems my src/etc directory was totally corrupted.  CVS had listed a

 	? etc/MAKEDEV

line from the update, yet there was no such file.  And when I tried to
`ls /usr/src/etc' it just stopped after the various MAKEDEV.* files and 
failed to list the etc.${arch} and everything else!

I just nuked the entire /usr/src/etc directory (with `rm -R') and reran 
my CVS update.  It got past the previous error.

However, now I get something even more strange:

--- kern-XEN3_DOM0 ---
/usr/obj/tooldir/x86_64/amd64/bin/nbconfig: panic: memory device is not 
configured
*** [kern-XEN3_DOM0] Error code 2

It didn't seem to have any problems running nbconfig against the other
kernels...

Have I once again gotten a partial update from CVS?

On Sat, 1 Dec 2007, David Laight wrote:

>> #   install  /usr/obj/destdir/amd64/dev/MAKEDEV
>> cd /usr/obj/objdir/amd64/etc &&
>> /usr/obj/tooldir/x86_64/amd64/bin/x86_64--netbsd-install  -N /usr/src/etc

order important in x86/pmap.c ?

Hi,
The attached diff does some performances improvement for xen, and also fix
error recovery from xpq_update_foreign() in pmap_update_ma(). For the later,
it makes things easier to move updating pm_stats or calling pmap_enter_pv()
after updating the PTE. Is it a problem for SMP systems ?

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Index: pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/pmap.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 pmap.c
--- pmap.c	28 Nov 2007 16:28:44 -0000	1.10
+++ pmap.c	2 Dec 2007 18:41:48 -0000
 <at>  <at>  -668,6 +668,9  <at>  <at>  pmap_map_ptes(struct pmap *pmap, struct 
 	struct lwp *l;
 	bool iscurrent;
 	uint64_t ncsw;
+#ifdef XEN
+	int s;
+#endif

 	/* the kernel's pmap is always accessible */
 	if (pmap == pmap_kernel()) {
 <at>  <at>  -729,7 +732,6  <at>  <at>  pmap_map_ptes(struct pmap *pmap, struct 

CLI and STI for XEN

sys/arch/amd64/include/frameasm.h defines macros for STI and CLI
for XEN that use 2 temp registers.
I think the patch below is equivalent - but only uses 1.

--- frameasm.h  22 Nov 2007 16:16:45 -0000      1.8
+++ frameasm.h  2 Dec 2007 22:00:04 -0000
 <at>  <at>  -140,15 +140,13  <at>  <at> 
 #define CLI(reg1,reg2) \
        movl CPUVAR(CPUID),%e/**/reg1 ;                 \
        shlq $6,%r/**/reg1 ;                                    \
-       movq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg2 ;      \
-       addq %r/**/reg1,%r/**/reg2 ;                            \
-       movb $1,EVTCHN_UPCALL_MASK(%r/**/reg2)
+       addq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg1 ;      \
+       movb $1,EVTCHN_UPCALL_MASK(%r/**/reg1)
 #define STI(reg1,reg2) \
        movl CPUVAR(CPUID),%e/**/reg1 ;                 \
        shlq $6,%r/**/reg1 ;                                    \
-       movq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg2 ;      \
-       addq %r/**/reg1,%r/**/reg2 ;                            \
-       movb $0,EVTCHN_UPCALL_MASK(%r/**/reg2)
+       addq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg1 ;      \
+       movb $0,EVTCHN_UPCALL_MASK(%r/**/reg1)
 #else /* XEN */
 #define CLI(reg1,reg2) cli
 #define STI(reg1,reg2) sti

However I don't have a XEN install so can't test it.

	David

Re: order important in x86/pmap.c ?

> For the later,
> it makes things easier to move updating pm_stats or calling pmap_enter_pv()
> after updating the PTE. Is it a problem for SMP systems ?

no, afaik.

YAMAMOTO Takashi

jmcneill-pm kernel does not compile on amd64

		Hello,

compiling a kernel from the jmcneill-pm branch currently does not
compile. It fails like this:

> $ sh build.sh -O /usr/obj -T /usr/tools -U -u kernel=GENERIC.MP
> ===> build.sh command: build.sh -O /usr/obj -T /usr/tools -U -u kernel=GENERIC.MP
> ===> build.sh started: Mon Dec  3 17:15:09 CET 2007
> ===> NetBSD version:   4.99.38
> ===> MACHINE:          amd64
> ===> MACHINE_ARCH:     x86_64
> ===> Build platform:   NetBSD 4.99.37 amd64
> ===> HOST_SH:          /bin/sh
> ===> TOOLDIR path:     /usr/tools
> ===> DESTDIR path:     /usr/obj/destdir.amd64
> ===> RELEASEDIR path:  /usr/obj/releasedir
> ===> makewrapper:      /usr/tools/bin/nbmake-amd64
> ===> Updated /usr/tools/bin/nbmake-amd64
> ===> Building kernel without building new tools
> ===> Building kernel:  GENERIC.MP
> ===> Build directory:  /usr/obj/sys/arch/amd64/compile/GENERIC.MP
> Build directory is /usr/obj/sys/arch/amd64/compile/GENERIC.MP
> Don't forget to run "make depend"
> depending the kern library objects
> depending the compat library objects
> making sure the compat library is up to date...
> `libcompat.a' is up to date.
> making sure the kern library is up to date...
> `libkern.o' is up to date.
> #      link  GENERIC.MP/netbsd

Re: jmcneill-pm kernel does not compile on amd64

On Mon, Dec 03, 2007 at 05:19:21PM +0100, Pierre Pronchery wrote:
> compiling a kernel from the jmcneill-pm branch currently does not
> compile. It fails like this:

Either use an old src/common or update to the last merges.

Joerg

Re: jmcneill-pm kernel does not compile on amd64

Joerg Sonnenberger wrote:
> On Mon, Dec 03, 2007 at 05:19:21PM +0100, Pierre Pronchery wrote:
>> compiling a kernel from the jmcneill-pm branch currently does not
>> compile. It fails like this:
> 
> Either use an old src/common or update to the last merges.

I updated and it works. Thanks!

--

-- 
khorben

Re: CLI and STI for XEN

On Mon, Dec 03, 2007 at 11:05:49PM +0100, Manuel Bouyer wrote:
> 
> It works. But please keep the 2 registers as macro arguments, even if only
> one is used for now: I may need a STIC() in the future, and this one would
> need 2 arguments.

But why would a STIC() having 2 args force STI() and CLI() to have 2 args?

The only thing I can think of is something like:

#define action(sti_stic, reg1, reg2) \
	... \
	sti_stic(reg1, reg2) \
	...

which could be called:
	action(STI, si, di)
or
	action(STIC, ax, 10)

But that is rather silly since STIC() would be followed by some
conditional jump.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Re: CLI and STI for XEN

On Sun, Dec 02, 2007 at 10:34:28PM +0000, David Laight wrote:
> sys/arch/amd64/include/frameasm.h defines macros for STI and CLI
> for XEN that use 2 temp registers.
> I think the patch below is equivalent - but only uses 1.
> 
> --- frameasm.h  22 Nov 2007 16:16:45 -0000      1.8
> +++ frameasm.h  2 Dec 2007 22:00:04 -0000
>  <at>  <at>  -140,15 +140,13  <at>  <at> 
>  #define CLI(reg1,reg2) \
>         movl CPUVAR(CPUID),%e/**/reg1 ;                 \
>         shlq $6,%r/**/reg1 ;                                    \
> -       movq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg2 ;      \
> -       addq %r/**/reg1,%r/**/reg2 ;                            \
> -       movb $1,EVTCHN_UPCALL_MASK(%r/**/reg2)
> +       addq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg1 ;      \
> +       movb $1,EVTCHN_UPCALL_MASK(%r/**/reg1)
>  #define STI(reg1,reg2) \
>         movl CPUVAR(CPUID),%e/**/reg1 ;                 \
>         shlq $6,%r/**/reg1 ;                                    \
> -       movq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg2 ;      \
> -       addq %r/**/reg1,%r/**/reg2 ;                            \
> -       movb $0,EVTCHN_UPCALL_MASK(%r/**/reg2)
> +       addq _C_LABEL(HYPERVISOR_shared_info),%r/**/reg1 ;      \
> +       movb $0,EVTCHN_UPCALL_MASK(%r/**/reg1)
>  #else /* XEN */
>  #define CLI(reg1,reg2) cli
>  #define STI(reg1,reg2) sti
> 
> However I don't have a XEN install so can't test it.