Subject: my vaxstation4k/90 is alive

Hy List,

after a long Period of inactivity my vaxstation runs now under
NetBSD2.0. But there are some questions. 
First: I connected an old extern Apple SCSI CD-rom to my diva (my
VAXstation 4000.90 ) switch on the diva and after a >>>show dev command
the vax gives me the following screen back.

VMS/VMB ADDR Devtype Numbytes RM/FX WP   DEVNAM    REV
EZA0 08-00-2B-3F-8F-D9  
DKA0    A/0/0 RODISK 682.19MB   RM WP CD_ROM   1.8g
DKA100  A/1/0 RODISK 682.19MB   RM WP CD_ROM   1.8g
DKA200    2 "    "    "    "   "        "
DKA300  A/3/0 DISK     1.05GB    FX    RZ26B   0B04
DKA400  A/4/0 RODISK 682.19MB   RM WP CD_ROM   1.8g
DKA500  A/5/0 RODISK 682.19MB   RM WP CD_ROM   1.8g
..HostID.. A/6  INITRD
DKA600  A/5/0 RODISK 682.19MB   RM WP CD_ROM   1.8g

I inserted a multiboot cd-rom (Lehmanns Online Bookshop Edition NetBSD
2.0 from 12/2004 ) to the drive. At bootprompt i type >>> b DKA0. Yes,
the diva begins to boot.!!! But why i get so confusing information ??
Can anyone explain me that SCSImysterium ?

Second question : you see the Harddisk of my Vax isn't really big. How i
can connect a second HD ( intern ) to the system such as IBM DDRS-34560
or SEAGATE ST34520. I've tested it with both Harddisks and >>> show dev
show's me nothing, only the screen above. A RZ28-E is being idenified. 
But you know how noisy these Harddisk is  

Subject: Re: my vaxstation4k/90 is alive

On Sat, 3 Mar 2007, Wilfried Weiß wrote:
> I inserted a multiboot cd-rom (Lehmanns Online Bookshop Edition NetBSD
> 2.0 from 12/2004 ) to the drive. At bootprompt i type >>> b DKA0. Yes,
> the diva begins to boot.!!! But why i get so confusing information ??
> Can anyone explain me that SCSImysterium ?

It looks to me like your CD-ROM is jumpered for SCSI address 6, the
same address being used by the VAXstation. Since the VAXstation
asserts both its address and the address of the target when it
selects a device, the CD-ROM always thinks the VAXstation is talking
to it.
--

-- 
roger ivie
rivie <at> ridgenet.net

Re: cannot build DEBUG kernel on -current

Should be fixed now.

-- Ragge

> Adding "options DEBUG" to a GENERIC kernel produces the following on 
> vax.  Things were OK on amd64; I did not test other platforms.  This is 
> -current from yesterday.
> 
> --- subr_debug.o ---
> /usr/src/src-current/sys/kern/subr_debug.c: In function 'freecheck_out':
> /usr/src/src-current/sys/kern/subr_debug.c:108: error: 'struct cpu_info' 
> has no member named 'ci_ipimsgs'
> /usr/src/src-current/sys/kern/subr_debug.c:108: error: 'IPI_SEND_CNCHAR' 
> undeclared (first use in this function)
> /usr/src/src-current/sys/kern/subr_debug.c:108: error: (Each undeclared 
> identifier is reported only once
> /usr/src/src-current/sys/kern/subr_debug.c:108: error: for each function 
> it appears in.)
> /usr/src/src-current/sys/kern/subr_debug.c:108: error: 'IPI_DDB' 
> undeclared (first use in this function)
> cc1: warnings being treated as errors
> /usr/src/src-current/sys/kern/subr_debug.c:108: warning: implicit 
> declaration of function 'cpu_handle_ipi'
> /usr/src/src-current/sys/kern/subr_debug.c: In function 'freecheck_in':
> /usr/src/src-current/sys/kern/subr_debug.c:135: error: 'struct cpu_info' 
> has no member named 'ci_ipimsgs'
> /usr/src/src-current/sys/kern/subr_debug.c:135: error: 'IPI_SEND_CNCHAR' 
> undeclared (first use in this function)
> /usr/src/src-current/sys/kern/subr_debug.c:135: error: 'IPI_DDB' 
> undeclared (first use in this function)

Re: UPDATE: various changes on INSTALL and iso generation

[ relevant port lists in Cc; please reply to one port list or
tech-install as appropriate]

On Mon, Mar 05, 2007 at 05:49:00PM +0100, Manuel Bouyer wrote:
> Hi,
> here's an updated patch for my changes on iso generation. Changes since
[...]

so I just commited this (with some minor changes thanks to Alan Barrett's
comments). The iso should be bootable on:
alpha, amd64, cats, i386, pmax, sgimips, sparc, sparc64, sun3, vax.
You can find an iso for these ports (exept cats which doesn't build at all
right now), built using build.sh iso-image with the new infrastructure.
It would be great if each of these could be tested at last once.
I tested amd64, i386, alpha and sparc64 myself.

--

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

4.0_BETA2 install, panic: lockmgr: no context

I just tried to install 4.0_BETA2 on my 4k90, it panics as soon as it tries
to fetch distribution sets:

Trying 192.168.1.37...
panic: lockmgr: no context
syncing disks... Trap: type 2, code 0, pc 80000395, psl 4080000
panic: trap

dumping to dev 23,1 offset 8
dump succeeded

Sometimes it wouldn't panic but just reboot.

Is there a point in trying to fix this in 4.0_BETA2, or should I just
try to get -current working instead?

--

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

some fixes for caddr_t removal errors

compiling -current GENERIC fails because of some errors introduced by
the caddr_t removal. the attached patch fixes these.

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

Index: sys/dev/bi/if_ni.c
===================================================================
RCS file: /cvsroot/src/sys/dev/bi/if_ni.c,v
retrieving revision 1.29
diff -u -r1.29 if_ni.c
--- sys/dev/bi/if_ni.c	4 Mar 2007 06:01:45 -0000	1.29
+++ sys/dev/bi/if_ni.c	8 Mar 2007 22:04:38 -0000
 <at>  <at>  -242,7 +242,7  <at>  <at> 
 	struct ifnet *ifp = (struct ifnet *)&sc->sc_if;
 	struct ni_msg *msg;
 	struct ni_ptdb *ptdb;
-	void *va;
+	uintptr_t va;
 	int i, j, s, res;
 	u_short type;

 <at>  <at>  -351,7 +351,7  <at>  <at> 
 #endif
 	s = splvm();
 	/* Set up message free queue */
-	ni_getpgs(sc, NMSGBUF * 512, &va, 0);
+	ni_getpgs(sc, NMSGBUF * 512, (void **) &va, 0);
 	for (i = 0; i < NMSGBUF; i++) {

LOCKDEBUG and TRAPDEBUG errors

When building a kernel with LOCKDEBUG enabled, the mutex stub code in
sys/arch/vax/vax/lock_stubs.S collides with the aliases set in
sys/kern/kern_mutex.c, the first attached patch disables them in the
LOCKDEBUG case.

The syscallnames array is used in sys/arch/vax/vax/syscall.c if
TRAPDEBUG is set, but the declaration is missing. The second attached
patch adds this declaration.

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

Index: sys/arch/vax/vax/lock_stubs.S
===================================================================
RCS file: /cvsroot/src/sys/arch/vax/vax/lock_stubs.S,v
retrieving revision 1.2
diff -u -r1.2 lock_stubs.S
--- sys/arch/vax/vax/lock_stubs.S	17 Feb 2007 05:34:07 -0000	1.2
+++ sys/arch/vax/vax/lock_stubs.S	8 Mar 2007 22:12:56 -0000
 <at>  <at>  -37,9 +37,12  <at>  <at> 
  */

 #include "opt_multiprocessor.h"
+#include "opt_lockdebug.h"
 #include <machine/asm.h>
 #include "assym.h"

+#ifndef LOCKDEBUG
+

MUTEX_ACQUIRE bug

There seems to be a bug in the MUTEX_ACQUIRE macro in
sys/arch/vax/include/mutex.h, the "position" of the bit field in the
INSV instruction should probably be $0 instead of %0 (mtx->mtx_owner).

This caused a PTELEN trap on my 4k90, which itself caused a PTELEN trap
in uvm_fault_internal, which caused another PTELEN trap in
uvm_fault_internal, ..., which finally caused a kernel stack invalid
panic. I think there might be another bug somewhere there.

Anyway, the attached patch fixes MUTEX_ACQUIRE.

--

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

Index: sys/arch/vax/include/mutex.h
===================================================================
RCS file: /cvsroot/src/sys/arch/vax/include/mutex.h,v
retrieving revision 1.5
diff -u -r1.5 mutex.h
--- sys/arch/vax/include/mutex.h	19 Feb 2007 03:06:46 -0000	1.5
+++ sys/arch/vax/include/mutex.h	8 Mar 2007 21:58:31 -0000
 <at>  <at>  -188,7 +188,7  <at>  <at> 
 		"clrl %1;"
 		"bbssi $31,%0,1f;"
 		"incl %1;"
-		"insv %2,%0,$31,%0;"
+		"insv %2,$0,$31,%0;"
 		"1:"
 	    : "=m"(mtx->mtx_owner), "=r"(rv)

Another crash...

Well, now that the kernel is semi-working again, I decided to update my 
system, and start testing around.
Installed the relevant sets, and started running etcupdate, but after a 
while the kernel crash.

Anyone have an idea? I have the system at the ddb prompt now, so I can 
muck around more if anyone have any ideas. Or I can recreate the 
crash... 

This with a current kernel as of today. 4.99.14.

	Johnny

-----------------------
Gnat:/home/bqt# etcupdate
*** Creating /tmp/temproot
*** Populating /tmp/temproot from /usr/src
panic: Segv in kernel mode: pc 8017e898 addr 81fc0800
Stopped in pid 2463.1 (cat) at  netbsd:trap+0x4fb:      movl    $1, -64(fp)
db> bt
panic: Segv in kernel mode: pc %x addr %x
Stack traceback :
0x85204c64: trap+0x4fb(0x85204d2c)
0x85204d2c: trap type=0xc code=0x81fc0800 pc=0x8017e898 psl=0xc00000
0x85204cf8: pmap_page_protect_long+0x244(0x8030fce0,0x1)
0x85204d7c: uvm_loan+0x377(0x805ec628,0x3c000,0x4000,0x827dc760,0x2)
0x85204dec: 
pipe_write+0x38c(0x8175283c,0x81752868,0x85204e9c,0x80d5e548,0x1)
0x85204e58: 
dofilewrite+0x6f(0x81689ba0,0x1,0x8175283c,0x3c000,0x4000,0x81752868

Re: Another crash...

Johnny Billquist wrote:
> panic: Segv in kernel mode: pc %x addr %x

Probably not crash related, but why are those %x'es printed?