VS3100M76 - current

[Holm Tiffe]

I'll start a new thread since the previous one gets a little bit
complicated.

I've burned a CDROM and tried to install. It takes a very long time
to load the kernel from the CDROM...

In sysinst I've choosed to use the existing partition sizes, after that,
sysinst crashed in similar fashion as before:

We now have your BSD-disklabel partitions as:
This is your last chance to change them.

uid 0, pid 6, command sysinst, on /: file system full

/: write failed, file syspid 6 (sysinst): user write of ***@0x7f61f000
at 177448 failed: 28
tem is full
[1] Segmentation fault sysinst
# .profile etc mnt2 sysinstmsgs.de
targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
#

(I've typed 'ls' to show the core)

an stty sane repairs the terminal

# # ls
.profile etc mnt2 sysinstmsgs.de targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
# rm *.core
# ls
.profile etc mnt2 sysinstmsgs.es tmp
bin kern sbin sysinstmsgs.fr usr
boot libexec sysinst sysinstmsgs.pl var
dev mnt sysinstmsgs.de targetroot
# df
Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/md0a 1907 1634 273 85% /

The next sysinst isn't working as expected, isn't it?

NetBSD/vax 6.99.42

This menu-driven tool is designed to help you install NetBSD to a hard
disk,
or upgrade an existing NetBSD system, with a minimum of work.
In the following menus type the reference letter (a, b, c, ...) to select
an
item, or type CTRL+N/CTRL+P to select the next/previous item.
The arrow keys and Page-up/Page-down may also work.
Activate the current selection from the menu by typing the enter key.

uid 0, pid 13, command sysinst, on /: file system full

/: write failepid 13 (sysinst): user write of ***@0x7f643000 at 274252
failed: 28
d, file system is full
[1] Illegal instruction sysinst
#

# rm *.core
# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: FUJITSU_M2954S-5
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 122
total sectors: 8498506
rpm: 0
interleave: 0
trackskew: 0
cylinderskew: 0
headswitch: 16 # microseconds
track-to-track seek: 8498506 # microseconds
drivedata: 0

8 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 409600 16 4.2BSD 0 0 1 # (Cyl. 0*-
25*)
b: 262144 409616 swap # (Cyl. 25*-
41*)
c: 8498506 0 unused 0 0 # (Cyl. 0 -
529*)
d: 1024000 671760 4.2BSD 0 0 1 # (Cyl. 41*-
105*)
e: 6393146 1695760 4.2BSD 0 0 1 # (Cyl. 105*-
503*)
f: 409600 8088906 4.2BSD 0 0 1 # (Cyl. 503*-
529*)
disklabel: warning, revolutions/minute 0
# newfs /dev/rsd1a
/dev/rsd1a: 200.0MB (409600 sectors) block size 8192, fragment size 1024
using 5 cylinder groups of 40.00MB, 5120 blks, 9920 inodes.
super-block backups (for fsck_ffs -b #) at:
32,
81952,
163872,
245792,
327712,
#

... Huch??

# newfs /dev/rsd1d
/dev/rsd1d: 500.0MB (1024000 sectors) block size 8192, fragment size 1024
using 11 cylinder groups of 45.46MB, 5819 blks, 11328 inodes.
super-block backups (for fsck_ffs -b #) at:
32,
93136,
186240,
279344,
372448,
465552,
558656,
651760,
744864,
837968,
931072,
#
# newfs /dev/rsd1f
/dev/rsd1f: 200.0MB (409600 sectors) block size 8192, fragment size 1024
using 5 cylinder groups of 40.00MB, 5120 blks, 9920 inodes.
super-block backups (for fsck_ffs -b #) at:
[1] Segmentation fault (core dumped) newfs /dev/rsd1f
#

Hmm..... :-|

maybe later...

# ls /usr/mdec
hpboot raboot rdboot sdboot xxboot
# installboot /dev/rsd1c /usr/mdec/sdboot
# mount /dev/sd1a /targetroot
# mkdir /targetroot/usr
# mount /dev/sd1d /targetroot/usr
# mount
/dev/md0a on / type ffs (local)
/dev/sd1a on /targetroot type ffs (local)
/dev/sd1d on /targetroot/usr type ffs (local)
# ls usr
bin mdec sbin share
# mount -t cd9660 /dev/cd0c /mnt
# ls /mnt
boot netbsd vax
# ls /mnt/netbsd
/mnt/netbsd
# ls -l /mnt/netbsd
-rw-r--r-- 1 1003 1002 1646829 May 19 19:02 /mnt/netbsd
# cp /mnt/netbsd /targetroot
# cp /mnt/boot /targetroot
# ls /mnt/vax/binary
kernel sets
# ls /mnt/vax/binary/kernel
MD5 netbsd-GENERIC.MP.gz
SHA512 netbsd-GENERIC.gz
# rm /targetroot/netbsd
# cp /mnt/vax/binary/kernel/netbsd-GENERIC.gz /targetroot
# gunzip /targetroot/*.gz
# ls /targetroot
boot netbsd-GENERIC usr

.. ok here I'm removed the log accidentally..

copied boot, the generic kernel and currently untarring the sets..

Hopefully I can newfs the var partition later...

Its seems that the problems are still here, but different programs will
crash differently...

newfs and sysinst are still dumping cores.

I'm no going to drink a beer, I'll report more after untarring the sets and
reboot...

Regards,

Holm

[Holm Tiffe]

Post by Holm Tiffe
I'll start a new thread since the previous one gets a little bit
complicated.
I've burned a CDROM and tried to install. It takes a very long time
to load the kernel from the CDROM...
In sysinst I've choosed to use the existing partition sizes, after that,
This is your last chance to change them.
uid 0, pid 6, command sysinst, on /: file system full
at 177448 failed: 28
tem is full
[1] Segmentation fault sysinst
# .profile etc mnt2 sysinstmsgs.de
targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
#
(I've typed 'ls' to show the core)
an stty sane repairs the terminal
# # ls
.profile etc mnt2 sysinstmsgs.de targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
# rm *.core
# ls
.profile etc mnt2 sysinstmsgs.es tmp
bin kern sbin sysinstmsgs.fr usr
boot libexec sysinst sysinstmsgs.pl var
dev mnt sysinstmsgs.de targetroot
# df
Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/md0a 1907 1634 273 85% /
The next sysinst isn't working as expected, isn't it?
NetBSD/vax 6.99.42
This menu-driven tool is designed to help you install NetBSD to a hard
disk,
or upgrade an existing NetBSD system, with a minimum of work.
In the following menus type the reference letter (a, b, c, ...) to select
an
item, or type CTRL+N/CTRL+P to select the next/previous item.
The arrow keys and Page-up/Page-down may also work.
Activate the current selection from the menu by typing the enter key.
uid 0, pid 13, command sysinst, on /: file system full
failed: 28
d, file system is full
[1] Illegal instruction sysinst
#
# rm *.core
# disklabel sd1
type: SCSI
disk: SCSI disk
label: FUJITSU_M2954S-5
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 122
total sectors: 8498506
rpm: 0
interleave: 0
trackskew: 0
cylinderskew: 0
headswitch: 16 # microseconds
track-to-track seek: 8498506 # microseconds
drivedata: 0
# size offset fstype [fsize bsize cpg/sgs]
a: 409600 16 4.2BSD 0 0 1 # (Cyl. 0*-
25*)
b: 262144 409616 swap # (Cyl. 25*-
41*)
c: 8498506 0 unused 0 0 # (Cyl. 0 -
529*)
d: 1024000 671760 4.2BSD 0 0 1 # (Cyl. 41*-
105*)
e: 6393146 1695760 4.2BSD 0 0 1 # (Cyl. 105*-
503*)
f: 409600 8088906 4.2BSD 0 0 1 # (Cyl. 503*-
529*)
disklabel: warning, revolutions/minute 0
# newfs /dev/rsd1a
/dev/rsd1a: 200.0MB (409600 sectors) block size 8192, fragment size 1024
using 5 cylinder groups of 40.00MB, 5120 blks, 9920 inodes.
32,
81952,
163872,
245792,
327712,
#
... Huch??
# newfs /dev/rsd1d
/dev/rsd1d: 500.0MB (1024000 sectors) block size 8192, fragment size 1024
using 11 cylinder groups of 45.46MB, 5819 blks, 11328 inodes.
32,
93136,
186240,
279344,
372448,
465552,
558656,
651760,
744864,
837968,
931072,
#
# newfs /dev/rsd1f
/dev/rsd1f: 200.0MB (409600 sectors) block size 8192, fragment size 1024
using 5 cylinder groups of 40.00MB, 5120 blks, 9920 inodes.
[1] Segmentation fault (core dumped) newfs /dev/rsd1f
#
Hmm..... :-|
maybe later...
# ls /usr/mdec
hpboot raboot rdboot sdboot xxboot
# installboot /dev/rsd1c /usr/mdec/sdboot
# mount /dev/sd1a /targetroot
# mkdir /targetroot/usr
# mount /dev/sd1d /targetroot/usr
# mount
/dev/md0a on / type ffs (local)
/dev/sd1a on /targetroot type ffs (local)
/dev/sd1d on /targetroot/usr type ffs (local)
# ls usr
bin mdec sbin share
# mount -t cd9660 /dev/cd0c /mnt
# ls /mnt
boot netbsd vax
# ls /mnt/netbsd
/mnt/netbsd
# ls -l /mnt/netbsd
-rw-r--r-- 1 1003 1002 1646829 May 19 19:02 /mnt/netbsd
# cp /mnt/netbsd /targetroot
# cp /mnt/boot /targetroot
# ls /mnt/vax/binary
kernel sets
# ls /mnt/vax/binary/kernel
MD5 netbsd-GENERIC.MP.gz
SHA512 netbsd-GENERIC.gz
# rm /targetroot/netbsd
# cp /mnt/vax/binary/kernel/netbsd-GENERIC.gz /targetroot
# gunzip /targetroot/*.gz
# ls /targetroot
boot netbsd-GENERIC usr
.. ok here I'm removed the log accidentally..
copied boot, the generic kernel and currently untarring the sets..
Hopefully I can newfs the var partition later...
Its seems that the problems are still here, but different programs will
crash differently...
newfs and sysinst are still dumping cores.
I'm no going to drink a beer, I'll report more after untarring the sets and
reboot...
Regards,
Holm
--

After that beer:

./usr/libexec/postfix/tlsproxy
./usr/libexec/postfix/trivial-rewrite
./usr/libexec/postfix/verify
./usr/libexec/postfix/virtual
./usr/mdec
./usr/mdec/boot
./usr/mdec/hpboot
./usr/mdec/raboot
./usr/mdec/rdboot
./usr/mdec/sdboot
./usr/mdec/xxboot
start = 1, len = 5818, fs = /targetroot/usr
offset=1590 1590
cg 0
panic: ffs_alloccg: map corrupted

dump to dev 23,1 not possible

Regards,

Holm

[Holm Tiffe]

Holm Tiffe wrote:

[..]


Since booting thakes that long wfrom a CD, I've decided to try Netbooting
again, but this isn't possible without some work.

There are netboot files provided for mop.
If you look deeper on this, you will see that those files are ELF format,
and at least my FreeBSD mopd from the ports isn't able to boot them.
I had to use mopcopy to build a mopfile from them, but unfortunately
a look to the sources brings up this:

mopcopy.c:

#ifndef NOELF
# if defined(__NetBSD__)
# include <sys/exec_elf.h>
# else
# define NOELF
# endif
# if !defined(EM_VAX)
# define EM_VAX 75
# endif
#endif /* NOELF */

That means ELF is supported on NetBSD, on nothing other. I don't even try
to compile the needed support in.

I've hacked this a year before and I have a 32bit FreeBSD mopcopy that does
the job, but I don't have the sources anymore and my workstation is a 64bit
system now. (I've hacked in the netboot because I needed to add support
for the rtVAX SGEC)
So please guys, since I don't know how this would work out on other server
architectures, could you please provide an a.out mop file which will work
on NetBSD AND the other Architectures? The needed converter is build on
NetBSD anyways...

The next thing with that file is this:


netio.c from NetBSD VAX boot:

* Get info for NFS boot: our IP address, our hostname,
* server IP address, and our root path on the server.
* There are two ways to do this: The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)
*/

#ifdef SUPPORT_BOOTP

/* Get boot info using BOOTP way. (RFC951, RFC1048) */
printf("Trying BOOTP\n");
bootp(0);

if (myip.s_addr) {
printf("Using IP address: %s\n", inet_ntoa(myip));

printf("myip: %s (%s)\n", hostname, inet_ntoa(myip));
} else

#endif /* SUPPORT_BOOTP */
{
#ifdef SUPPORT_BOOTPARAMS
/* Get boot info using RARP and Sun bootparams. */

printf("Trying BOOTPARAMS\n");
/* Get our IP address. (rarp.c) */
if (rarp_getipaddress(0) == -1)
return (errno);

printf("boot: client IP address: %s\n", inet_ntoa(myip));

/* Get our hostname, server IP address. */
if (bp_whoami(0))
return (errno);

printf("boot: client name: %s\n", hostname);

/* Get the root pathname. */
if (bp_getfile(0, "root", &rootip, rootpath))
return (errno);
#endif
}
printf("root addr=%s path=%s\n", inet_ntoa(rootip), rootpath);
f->f_devdata = s;



someone decided that there is a modern way: "The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)"

BOOTP is providing a root-path, but nobody inide "boot" is interested in
that root-path:

Trying BOOTP
Using IP address: 192.168.50.22
myip: vs3176 (192.168.50.22)
root addr=192.168.50.49 path=
nfs_open: must mount first.
open netbsd.gz: Device not configured
netbsd.gz: boot failed: Device not configured

boot netbsd.old

wireshark says that my DNSMASQ from my Linksys Router is providing one:

"Boot file name: /tftpboot/netbsd-vax"

So why this is leaved unnused?
In libsa the bootfile is rad but the variable is unnused.

It is really not that easy to dig with an VAX and NetBSD if you not already
have a VAX with a running NetBSD. I've had setup a cross development tree 1
year before, but I have this todo again it seems...

Regards,

Holm

[Holm Tiffe]

It appears that Debian's Mopd has a patch to work with ELF. Perhaps it
could work on FreeBSD for you?
In any case, it works on things other than NetBSD. I'm not sure providing a
non-ELF kernel image makes sense. I'm sure it's not a trivial change.
Pat

...at first: Why you answering at top? Outlook?

2nd: not hte kerenl, the problem is simply the "boot" file that gets loaded
from mopd and the change as simple as mopcopy ELF-bootfile mop-bootfile on
a NetBSD system building the distribution.
The kernel gets loaded later over NFS from that already booted bootfile.

I'll look for the Debian stuff, thx.


Regards,

Holm

Post by Holm Tiffe
[..]
Since booting thakes that long wfrom a CD, I've decided to try Netbooting
again, but this isn't possible without some work.
There are netboot files provided for mop.
If you look deeper on this, you will see that those files are ELF format,
and at least my FreeBSD mopd from the ports isn't able to boot them.
I had to use mopcopy to build a mopfile from them, but unfortunately
#ifndef NOELF
# if defined(__NetBSD__)
# include <sys/exec_elf.h>
# else
# define NOELF
# endif
# if !defined(EM_VAX)
# define EM_VAX 75
# endif
#endif /* NOELF */
That means ELF is supported on NetBSD, on nothing other. I don't even try
to compile the needed support in.
I've hacked this a year before and I have a 32bit FreeBSD mopcopy that does
the job, but I don't have the sources anymore and my workstation is a 64bit
system now. (I've hacked in the netboot because I needed to add support
for the rtVAX SGEC)
So please guys, since I don't know how this would work out on other server
architectures, could you please provide an a.out mop file which will work
on NetBSD AND the other Architectures? The needed converter is build on
NetBSD anyways...
* Get info for NFS boot: our IP address, our hostname,
* server IP address, and our root path on the server.
* There are two ways to do this: The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)
*/
#ifdef SUPPORT_BOOTP
/* Get boot info using BOOTP way. (RFC951, RFC1048) */
printf("Trying BOOTP\n");
bootp(0);
if (myip.s_addr) {
printf("Using IP address: %s\n", inet_ntoa(myip));
printf("myip: %s (%s)\n", hostname, inet_ntoa(myip));
} else
#endif /* SUPPORT_BOOTP */
{
#ifdef SUPPORT_BOOTPARAMS
/* Get boot info using RARP and Sun bootparams. */
printf("Trying BOOTPARAMS\n");
/* Get our IP address. (rarp.c) */
if (rarp_getipaddress(0) == -1)
return (errno);
printf("boot: client IP address: %s\n", inet_ntoa(myip));
/* Get our hostname, server IP address. */
if (bp_whoami(0))
return (errno);
printf("boot: client name: %s\n", hostname);
/* Get the root pathname. */
if (bp_getfile(0, "root", &rootip, rootpath))
return (errno);
#endif
}
printf("root addr=%s path=%s\n", inet_ntoa(rootip), rootpath);
f->f_devdata = s;
someone decided that there is a modern way: "The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)"
BOOTP is providing a root-path, but nobody inide "boot" is interested in
Trying BOOTP
Using IP address: 192.168.50.22
myip: vs3176 (192.168.50.22)
root addr=192.168.50.49 path=
nfs_open: must mount first.
open netbsd.gz: Device not configured
netbsd.gz: boot failed: Device not configured

boot netbsd.old

"Boot file name: /tftpboot/netbsd-vax"
So why this is leaved unnused?
In libsa the bootfile is rad but the variable is unnused.
It is really not that easy to dig with an VAX and NetBSD if you not already
have a VAX with a running NetBSD. I've had setup a cross development tree 1
year before, but I have this todo again it seems...
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583

[Holm Tiffe]

Post by Holm Tiffe
Since booting thakes that long wfrom a CD, I've decided to try Netbooting
again, but this isn't possible without some work.
There are netboot files provided for mop.
If you look deeper on this, you will see that those files are ELF format,
and at least my FreeBSD mopd from the ports isn't able to boot them.
I had to use mopcopy to build a mopfile from them, but unfortunately
#ifndef NOELF
# if defined(__NetBSD__)
# include <sys/exec_elf.h>
# else
# define NOELF
# endif
# if !defined(EM_VAX)
# define EM_VAX 75
# endif
#endif /* NOELF */
That means ELF is supported on NetBSD, on nothing other. I don't even try
to compile the needed support in.
I've hacked this a year before and I have a 32bit FreeBSD mopcopy that does
the job, but I don't have the sources anymore and my workstation is a 64bit
system now. (I've hacked in the netboot because I needed to add support
for the rtVAX SGEC)

Its *possible* that NetBSD's mopcopy's ELF support might Just Work on
FreeBSD if it was enabled. It might certainly be work testing. If it does,
or it just needs a small patch then it would make sense to import it into
the NetBSD tree.

There is something todo, the Makefile Architecture is different and some
other differences are there too, but it isn't impossible, I've compile this
last year more or less per hand.

Another though might be to try building the NetBSD mopd on FreeBSD - again
patches could be imported and we could even make the source available for
separate packaging.

Thats what I've done. FreeBSDs mopd is derived and "scaled" down from
NetBSD anyway.

So please guys, since I don't know how this would work out on other server

Post by Holm Tiffe
architectures, could you please provide an a.out mop file which will work
on NetBSD AND the other Architectures? The needed converter is build on
NetBSD anyways...

The problem is that anything which is used in the NetBSD build must be
built as a tool and supported on all build platforms, so if mopcopy worked
on FreeBSD, Linux, etc, then it could be enabled in the build to generate
an a.out as well as an elf kernel image.

:-)

in the history that specific boot file hat the right format, don't ask me
now, NetBSD 4 or 5..

Just say no and NetBSD is the only OS that can boot NetBSD.
MOP is a VAX only protocol anyway and I don't think that the mop-able
NetBSD boot is build on every other architecture - since it isn't needed
there. You can't boot other things as VAXen with that, so if you build it
for VAXen you can build it in the right format.

Post by Holm Tiffe
* Get info for NFS boot: our IP address, our hostname,
* server IP address, and our root path on the server.
* There are two ways to do this: The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)
*/
#ifdef SUPPORT_BOOTP
/* Get boot info using BOOTP way. (RFC951, RFC1048) */
printf("Trying BOOTP\n");
bootp(0);
if (myip.s_addr) {
printf("Using IP address: %s\n", inet_ntoa(myip));
printf("myip: %s (%s)\n", hostname, inet_ntoa(myip));
} else
#endif /* SUPPORT_BOOTP */
{
#ifdef SUPPORT_BOOTPARAMS
/* Get boot info using RARP and Sun bootparams. */
printf("Trying BOOTPARAMS\n");
/* Get our IP address. (rarp.c) */
if (rarp_getipaddress(0) == -1)
return (errno);
printf("boot: client IP address: %s\n", inet_ntoa(myip));
/* Get our hostname, server IP address. */
if (bp_whoami(0))
return (errno);
printf("boot: client name: %s\n", hostname);
/* Get the root pathname. */
if (bp_getfile(0, "root", &rootip, rootpath))
return (errno);
#endif
}
printf("root addr=%s path=%s\n", inet_ntoa(rootip), rootpath);
f->f_devdata = s;
someone decided that there is a modern way: "The old, Sun way,
* and the more modern, BOOTP way. (RFC951, RFC1048)"
BOOTP is providing a root-path, but nobody inide "boot" is interested in
Trying BOOTP
Using IP address: 192.168.50.22
myip: vs3176 (192.168.50.22)
root addr=192.168.50.49 path=
nfs_open: must mount first.
open netbsd.gz: Device not configured
netbsd.gz: boot failed: Device not configured

boot netbsd.old

"Boot file name: /tftpboot/netbsd-vax"
So why this is leaved unnused?
In libsa the bootfile is rad but the variable is unnused.

You're definitely seeing an entry with TAG_ROOTPATH (17) in the packet?

To late. I've closed that windows. I had todo some work...

It is really not that easy to dig with an VAX and NetBSD if you not already

Post by Holm Tiffe
have a VAX with a running NetBSD. I've had setup a cross development tree 1
year before, but I have this todo again it seems..

Because the standard NetBSD cross development environment is supposed to be
so easy to setup on any posix platform, we tend to assume its present.
I think the issues here are in addition to the cross development
environment - let see what we can do to make it less painful to start
working with NetBSD/vax :)

Yes, it is relativley easy, but it needs time to setup.
I do even have a 32Bit FreeBSD in a VirtualBox just had to transfer the
entire stuff but then it is a 6.0 from last year..

Regards,

Holm

[Holm Tiffe]

Holm Tiffe wrote:

[..]

Post by Holm Tiffe
./usr/libexec/postfix/tlsproxy
./usr/libexec/postfix/trivial-rewrite
./usr/libexec/postfix/verify
./usr/libexec/postfix/virtual
./usr/mdec
./usr/mdec/boot
./usr/mdec/hpboot
./usr/mdec/raboot
./usr/mdec/rdboot
./usr/mdec/sdboot
./usr/mdec/xxboot
start = 1, len = 5818, fs = /targetroot/usr
offset=1590 1590
cg 0
panic: ffs_alloccg: map corrupted
dump to dev 23,1 not possible
Regards,
Holm
--

I've repeated this yesterday eavening one more time w/o any other things
than some fsck's before.
The -current crashes every time with this same panic, so it seems
something in the vm-system is going crazy here.
For my experiences the bug is the same on CVAX, Rigel and the NVAX,
since I had some ugly suprises too while installing the VS4000/90
but I have a somewhat running system (not used, last booted last year)
on this machine. At least the two VS3100's are running OpenBSD flawlessly
without any suprises.

What should I do?
I can put the M76 aside an get the M38 to verify Ragges question about the
behavior of the CVAX (IMHO the very same, but I'll try again).

I'm a good electronican and I rule my own business. Sometimes I'm
programming some embedded things, but debugging a VM System from a VAX is
beyound my possibilities, regardless of the needed time.
I would provide some fixes to the code, but for this it is neccessary that
the machines are at least able to compile some stuff.
That I don't know much from the internals of a VAX processor is another
thing..

If I can help I'll do this as good as I can, but "fix it yourself if you
need it" wouldn't work here. If no one from the VAX maintainers is jumping
in here, I'll put that stuff aside again, maybe trying next year..
From my Opinion is the state of the NetBSD VAX port at least to be called
"desolate".

So what now. Please no silence, I'll help but I don't want to be the only
one.

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe
If I can help I'll do this as good as I can, but "fix it yourself if you
need it" wouldn't work here. If no one from the VAX maintainers is jumping
in here, I'll put that stuff aside again, maybe trying next year..
From my Opinion is the state of the NetBSD VAX port at least to be called
"desolate".

Because there are bugs? I do not agree with that view.

Post by Holm Tiffe
So what now. Please no silence, I'll help but I don't want to be the only
one.

Unfortunately I have not seen your problem myself. newfs have worked
fine on several machines I have tested.
And right now I'm trying to get current setup under a simh VAX8600
instance, since I know there is some kind of bug if you have more than
64MB memory configured, where NetBSD will not boot.
And that is what I'm trying to get to at the moment.

But to recap - you basically get a signal and a memory dump every time
you run newfs?

Johnny

[Holm Tiffe]

Post by Holm Tiffe
I've repeated this yesterday eavening one more time w/o any other things
than some fsck's before.
The -current crashes every time with this same panic, so it seems
something in the vm-system is going crazy here.
For my experiences the bug is the same on CVAX, Rigel and the NVAX,
since I had some ugly suprises too while installing the VS4000/90
but I have a somewhat running system (not used, last booted last year)
on this machine. At least the two VS3100's are running OpenBSD flawlessly
without any suprises.
What should I do?
I can put the M76 aside an get the M38 to verify Ragges question about the
behavior of the CVAX (IMHO the very same, but I'll try again).
I'm a good electronican and I rule my own business. Sometimes I'm
programming some embedded things, but debugging a VM System from a VAX is
beyound my possibilities, regardless of the needed time.
I would provide some fixes to the code, but for this it is neccessary that
the machines are at least able to compile some stuff.
That I don't know much from the internals of a VAX processor is another
thing..
If I can help I'll do this as good as I can, but "fix it yourself if you
need it" wouldn't work here. If no one from the VAX maintainers is jumping
in here, I'll put that stuff aside again, maybe trying next year..
From my Opinion is the state of the NetBSD VAX port at least to be called
"desolate".

I think "desolate" would be overstating. I think we would agree on "could
be improved". It works fine on my 4000/90 and the various simh instances
I've used to test, and I believe that is the case for several other users.

Yes,Ok. I know that was LOUD.

Clearly it doesn't work for you - on multiple instances of hardware which
are able to run other software, so its likely there is something pervasive
or common to your environment which is not triggering here or elsewhere,
and it would be really good to find out.

Johnny asked above why I think it would be different to install on a 1GB
disk and on a 4GB disk. He is right, it makes no difference...theoretical.
In fact I could install the OS on the IBM0663 1Gb disk and I failed badly
to move it to the 4GB disk or install it there...

There is for sure a moving targt that spits in the soup, sometimes here and
sometimes there. Ragge may be right with the Pagemap/VM Problems, that
feels like bad memory, but bad memory on 4 different machines?

Look at this, that is from a thread last year, some infamous guy mailed

HI,
I've got some Vaxstations lately and today I've tried to install
NetBSD-6.1_RC2 on a VS3100M38 with 24Mbytes of RAM.
Disk is an IBM DCAS 34330, 4Gbyte.
I can do what I want, the install.ram is crashing while labeling the disk,
regardless if I have overwritten the disk with zeros before ot not.
Status: Command ended on signal
Command: disklabel -w -r -f /tmp/disktab sd0 'DCAS-34330 '
Hit enter to continue
--------------------------------------------------------------------------------
uid 0, pid 7, command disklabel, on /: file system full
/: write failed, file system is full

...yes, it was me, with the very same problem.

after new booting I had to edit the mount points of the labeled partitions
and finally this runs in the same problem.
| yes or no? |
| |
| a: No |
|uid 0, pid 6, command sysinst, on /: file
system full +---------------+
ite failed, file system is full
[1] Illegal instruction sysinst
# s: not found
# Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/md0a 1551 1549 2 99% /

Curses Bug in -current ehy?

drivedata: 0
# size offset fstype [fsize bsize cpg/sgs]
a: 1842384 16 4.2BSD 0 0 1 # (Cyl. 0*-
114*)
b: 524288 1842400 swap # (Cyl. 114*-
147*)
c: 8250001 0 unused 0 0 # (Cyl. 0 -
513*)
d: 5025728 2366688 4.2BSD 0 0 1 # (Cyl. 147*-
460*)
e: 857504 7392416 4.2BSD 0 0 1 # (Cyl. 460*-
513*)
partition> W
Label disk [n]? y
disklabel: warning, revolutions/minute 0
Label written
partition> Q
vs3138# newfs sd0a
/dev/rsd0a: 899.6MB (1842384 sectors) block size 8192, fragment size 1024
using 20 cylinder groups of 44.98MB, 5758 blks, 11200 inodes.
[1] Segmentation fault (core dumped) newfs sd0a
vs3138# newfs sd0d
[1] Illegal instruction (core dumped) newfs sd0d
vs3138# newfs rsd0d
[1] Illegal instruction (core dumped) newfs rsd0d
vs3138#

The newfs problem. Watch out the machine name: vs3138, that means at
Sat, 30 Mar 2013 22:17:34 +0100 the CVAX had the same Problem as the
Rigel (vs3176) one day before now.

Throwing out some random thoughts on what might be common (Note, I'm not
saying "wrong", just "that NetBSD does not currently handle")
- are you using the same serial terminal/cable/flow control settings?

Yes, that's seyon on FreeBSD with the same cable :-)

- are you using the same physical disk?

Yes, Tried the IBM DCAS 34330 and the Fujitsu M2954SYU. Currently is a
working OpenBSD on the DCAS. A somewhat working NetBSD is on the IBM0663,
at least I was able to install it there, not with sysinst but by hand.

- You're not using any odd arguments to newfs or similar - so thats out

newfs /dev/rsd1a as to be read in every terminal dump..

- Its reproduced with netboot and cdboot, so they are excluded...

netboot .. no, I've netbooted last year, this year I've used a CROM.
But the problems are the very same. The boot itself isn't the problem.
I'm in the process of setting up the netboot environment again since
the CDROM boot is dog slow..

For OpenBSD, does it report the same details on disk attachment, does a
read/write of a file report the same approximate speed? - eg
dd msgfmt=human if=/dev/zero of=TMPFILE bs=1m count=10
dd msgfmt=human if=TMPFILE of=/dev/null bs=1m

Never tried to measure some speed, I'm happe if I can pollute the
filesystems with the needed files, but the speed doesn't feel bad at all.
With NetBSD-current the extract of the base.tgz triggers the kernel to a panic.

Can you NFS export a filesystem to the vax and then boot the vax from the
CD and manually install into the NFS filesystem? - trying to exclude the
disk IO

Nice Idea, would try later.

Do you have any other disk controller - a VAX with an MFM/DSSI drive?

I do have some QBUS Backplane, a KA630 with 16MB ram and some UC07
Controller laying around. I'm building a enclosure for the Card Cage
currently.. will take some time, but I had that "running" on Quasjarus-0c
last year..

Searching for a KA65x, KA660 + Memory since the MVAXII is dog slow.

Does an early NetBSD/vax install (say 1.6) have the same issue?

Thell me where I can find an iso image..

So what now. Please no silence, I'll help but I don't want to be the only

Post by Holm Tiffe
one.

Not silence. Possibly something more of a scattergun of too many questions,
but not silence :)

Ahh.. no Problem. I've already sayd that I will do what I can.
Some of your Questions will take some time to answer.

I'll look for NetBSD 1.6 next.

Regards

Holm

[Holm Tiffe]

David Brownlee wrote:

[..]

Post by Holm Tiffe
Johnny asked above why I think it would be different to install on a 1GB
disk and on a 4GB disk. He is right, it makes no difference...theoretical.
In fact I could install the OS on the IBM0663 1Gb disk and I failed badly
to move it to the 4GB disk or install it there...

Just to confirm - are you using different disks & cables (both physical and
models in different machines?) I just want to eliminate an issue with a
specific disk and or/model

3 different disks tried. Cabling was the same.
I have more disks of that size, no problem, I'll take another.

[..]

Post by Holm Tiffe
[...]

ite failed, file system is full
[1] Illegal instruction sysinst
# s: not found
# Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/md0a 1551 1549 2 99% /

Curses Bug in -current ehy?

Looking at changes since netbsd-6 on the most likely curses file the logs

[..]

Post by Holm Tiffe

- are you using the same physical disk?

Yes, Tried the IBM DCAS 34330 and the Fujitsu M2954SYU. Currently is a
working OpenBSD on the DCAS. A somewhat working NetBSD is on the IBM0663,
at least I was able to install it there, not with sysinst but by hand.

- You're not using any odd arguments to newfs or similar - so thats out

newfs /dev/rsd1a as to be read in every terminal dump..

- Its reproduced with netboot and cdboot, so they are excluded...

netboot .. no, I've netbooted last year, this year I've used a CROM.
But the problems are the very same. The boot itself isn't the problem.
I'm in the process of setting up the netboot environment again since
the CDROM boot is dog slow..

Don't know if it counts that I used netboot last year.

Post by Holm Tiffe

For OpenBSD, does it report the same details on disk attachment, does a
read/write of a file report the same approximate speed? - eg
dd msgfmt=human if=/dev/zero of=TMPFILE bs=1m count=10
dd msgfmt=human if=TMPFILE of=/dev/null bs=1m

Never tried to measure some speed, I'm happe if I can pollute the
filesystems with the needed files, but the speed doesn't feel bad at all.
With NetBSD-current the extract of the base.tgz triggers the kernel to a panic.

Can you NFS export a filesystem to the vax and then boot the vax from the
CD and manually install into the NFS filesystem? - trying to exclude the
disk IO

Nice Idea, would try later.

[..]

Post by Holm Tiffe
I'll look for NetBSD 1.6 next.

Thanks. Would it be accurate to say that all of the remaining issues appear
to occur while accessing one of your two SCSI disks?
I think the most fruitful avenues for testing would be
- anything that avoids those disk/controller combinations - NFS, or your
other vax
- testing earlier NetBSD versions to see if the issue is present there
(will follow up on other thread :)
I understand your frustration at reporting these issues some time ago and
that thread running out to silence. I hope we can avoid that happening
again, and get you with a set of machines which can run NetBSD/vax for you
when you want them

NetBSD 1.6.2 stops every time on the cd-boot at this point.
6.x is displaying the date after this line in human readable format...

boot device: cd0
root on md0a dumps on md0b
Clock has lost 1726 day(s) - CHECK AND RESET THE DATE.
root file system type: ffs

then nothing more happens.
I've tried to set the time to 1999 with NetBSD, it changed the displayed
clock skew from 36xx to 1726 days, that's all.

I've tried to boot from the CDROM w/o the disks on the SCSI Bus but that
changed nothing. I could try netboot but I don't think that this changes
something at this point. The kernel should at this stage find the rootfs in
memory and mount it and the kernel was loaded properly already.

..and yes, all 3 machines have ncr SCSI controllers (I've mentioned this
more then one times), that is what is similar between them.

I'll try an other disk and another CDROM today, but I don't know if I can
boot from that other CDROM. So far as I know the DEC stuff is picky what
type is used. I could'nt boot VMS on the 4000/90 with other CD-drives..
I've got exactly the actual used Toshiba XM5701 from Ebay for this purpose.
So far as I remember it had something todo with disk sector sizes 2048 vs.
2324 bytes or something like that.

Regards,

Holm

[Holm Tiffe]

Holm Tiffe wrote:

Tried to label the Quantum 2,1G Disk with Davids -current:

6 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 262144 16 4.2BSD 0 0 0 # (Cyl. 0*-
434*)
b: 262144 262160 swap # (Cyl. 434*-
868*)
c: 4124736 0 unused 0 0 # (Cyl. 0 -
6829*)
d: 131072 524304 4.2BSD 0 0 0 # (Cyl. 868*-
1085*)
e: 1024000 655376 4.2BSD 0 0 0 # (Cyl. 1085*-
2780*)
f: 2445360 1679376 4.2BSD 0 0 0 # (Cyl. 2780*-
6829*)
partition>?
? print this menu
A adjust the label size to the max disk size
C make partitions contiguous
E print disk label and current partition table
I change label information
L list all known file system types
N name the label
P print current partition table
Q quit
R rounding (c)ylinders (s)ectors
W write the current partition table
[a-l] define named partition
partition>W
Label disk [n]?y
r0=00000000 r1=803c0544 r2=00000000 r3=80fbd360 r4=8046815c r5=00000000
r6=803c04d0 r7=80dec200
r8=803c0544 r9=00000000 r10=803c04d0 r11=00000000
ap=83742b84 fp=83742b60 sp=7fffd638 pc=800b9d5b
panic: SEGV in kernel mode: pc 0x800b9d5b addr 0

dump to dev 23,1 not possible


83 BOOT SYS

I'm now trying the same with the VS3100 M38.

Regards

Holm

[Holm Tiffe]

Post by Holm Tiffe
# size offset fstype [fsize bsize cpg/sgs]
a: 262144 16 4.2BSD 0 0 0 # (Cyl. 0*-
434*)
b: 262144 262160 swap # (Cyl. 434*-
868*)
c: 4124736 0 unused 0 0 # (Cyl. 0 -
6829*)
d: 131072 524304 4.2BSD 0 0 0 # (Cyl. 868*-
1085*)
e: 1024000 655376 4.2BSD 0 0 0 # (Cyl. 1085*-
2780*)
f: 2445360 1679376 4.2BSD 0 0 0 # (Cyl. 2780*-
6829*)
partition>?
? print this menu
A adjust the label size to the max disk size
C make partitions contiguous
E print disk label and current partition table
I change label information
L list all known file system types
N name the label
P print current partition table
Q quit
R rounding (c)ylinders (s)ectors
W write the current partition table
[a-l] define named partition
partition>W
Label disk [n]?y
r0=00000000 r1=803c0544 r2=00000000 r3=80fbd360 r4=8046815c r5=00000000
r6=803c04d0 r7=80dec200
r8=803c0544 r9=00000000 r10=803c04d0 r11=00000000
ap=83742b84 fp=83742b60 sp=7fffd638 pc=800b9d5b
panic: SEGV in kernel mode: pc 0x800b9d5b addr 0
dump to dev 23,1 not possible
83 BOOT SYS
I'm now trying the same with the VS3100 M38.
Regards
Holm

Now the CVAX:

-DKA500

Post by Holm Tiffe

NetBSD/vax boot [1.11 (Tue May 13 16:14:00 BST 2014)] <<
Press any key to abort autoboot 0

getdisklabel: no disk label
nfs_open: must mount first.
open netbsd.vax: No such file or directory

Post by Holm Tiffe
boot netbsd

getdisklabel: no disk label
nfs_open: must mount first.
3802808+136060=0x3c1d60
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 6.99.41 (INSTALL) #0: Tue May 13 16:19:50 BST 2014

***@forsaken.absd.org:/var/obj/nbbuild-current-vax/objdir/sys/arch/vax/compile/INSTALL
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19344 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf 0x4f0000-0x4fffff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0

You can now change the sizes for the system partitions. The default is to

allocate all the space to the root file system, however you may wish to
have
separate /usr (additional system files), /var (log files etc) or /home
(users' home directories).

Free space will be added to the partition marked with a '+'.

MB Cylinders Sectors Filesystem
80 272 164288 /
128 435 262740 swap
64 218 131672 /tmp (mfs)
70 (70) 238 143752 + /usr
32 109 65836 /var
1703 5775 3488100 /home
Add a user defined partition
Change input units (sectors/cylinders/MB)
uid 0, pid 6, command sysinst, on /: file system fulltitions.

/: write failed, file system is full
pid 6 (sysinst): user write of ***@0x7f61f000 at 194264 failed: 28
[1] Segmentation fault sysinst
#


.. this time I've used the defaults for the disklabel.
# # .profile etc mnt2 sysinstmsgs.de
targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
#

removed the core, stty sane and started disklabel

# disklabel -i -I sd0
Enter '?' for help
partition>E
# :
type: SCSI
disk: FIREBALL_TM2110S
label: fictitious
flags:
bytes/sector: 512
sectors/track: 151
tracks/cylinder: 4
sectors/cylinder: 604
cylinders: 6810
total sectors: 4124736
rpm: 4500
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0

6 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 262144 16 4.2BSD 0 0 0 # (Cyl. 0*-
434*)
b: 262144 262160 swap # (Cyl. 434*-
868*)
c: 4124736 0 unused 0 0 # (Cyl. 0 -
6829*)
d: 131072 524304 4.2BSD 0 0 0 # (Cyl. 868*-
1085*)
e: 1024000 655376 4.2BSD 0 0 0 # (Cyl. 1085*-
2780*)
f: 2445360 1679376 4.2BSD 0 0 0 # (Cyl. 2780*-
6829*)
partition>

oha, it seems that we hae a label on that disk coming from the last try
with the M76...

Ok, I'll try to use it.

# newfs /dev/rsd0a
/dev/rsd0a: 128.0MB (262144 sectors) block size 8192, fragment size 1024
using 4 cylinder groups of 32.00MB, 4096 blks, 7936 inodes.
super-block backups (for fsck_ffs -b #) at:
32,
65568,
131104,
196640,
# newfs /dev/rsd0d
/dev/rsd0d: 64.0MB (131072 sectors) block size 8192, fragment size 1024
using 4 cylinder groups of 16.00MB, 2048 blks, 3968 inodes.
super-block backups (for fsck_ffs -b #) at:
[1] Illegal instruction (core dumped) newfs /dev/rsd0d
#
..Grrr....


# sync
# sync
# newfs /dev/rsd0e
/dev/rsd0e: 500.0MB (1024000 sectors) block size 8192, fragment size 1024
using 11 cylinder groups of 45.46MB, 5819 blks, 11328 inodes.
super-block backups (for fsck_ffs -b #) at:
[1] Illegal instruction (core dumped) newfs /dev/rsd0e
# newfs /dev/rsd0f
/dev/rsd0f: 1194.0MB (2445360 sectors) block size 16384, fragment size 2048
using 7 cylinder groups of 170.58MB, 10917 blks, 21504 inodes.
super-block backups (for fsck_ffs -b #) at:
[1] Illegal instruction (core dumped) newfs /dev/rsd0f
#


I think we can put assumptions about SCSI cabling and disks aside.
This is another machine with it's own special SCSI cable harness.

The CDROM itself has done his job, the kernel is loaded and the BSD is
running on the mfs.

Suggestions?

At the moment I've extracting the sets from David's cd into a mounted nfs
filesystem.
Have still to dig out how to provide the nfs root path to a netbooted
kernel and have only this linux DNSMASQ thing in my linksys router for
BOOTP, Hints?

Regards,

Holm

[Anders Magnusson]

Post by Holm Tiffe
getdisklabel: no disk label
nfs_open: must mount first.
3802808+136060=0x3c1d60
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 6.99.41 (INSTALL) #0: Tue May 13 16:19:50 BST 2014
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19344 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf 0x4f0000-0x4fffff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0

Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?

The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.

So it may be something in the driver for that scsi chip that is failing.

-- Ragge

[Johnny Billquist]

Post by Anders Magnusson

Post by Holm Tiffe
getdisklabel: no disk label
nfs_open: must mount first.
3802808+136060=0x3c1d60
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 6.99.41 (INSTALL) #0: Tue May 13 16:19:50 BST 2014
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19344 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf
0x4f0000-0x4fffff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0

Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.

Hmm. That is definitely the best idea so far... I have run on my
4000/90, under simh (using MSCP) and a 3600 recently, also with MSCP.
So I have not tested any machine with the same SCSI controller Holm is
using.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Anders Magnusson

Post by Holm Tiffe
getdisklabel: no disk label
nfs_open: must mount first.
3802808+136060=0x3c1d60
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 6.99.41 (INSTALL) #0: Tue May 13 16:19:50 BST 2014
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19344 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf
0x4f0000-0x4fffff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0

Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.

Hmm. That is definitely the best idea so far... I have run on my
4000/90, under simh (using MSCP) and a 3600 recently, also with MSCP.
So I have not tested any machine with the same SCSI controller Holm is
using.
Johnny

The VS4000/90 also has an ncr based SCSI controller but a newer chip,
53C9x or something instead of 53C80..

Regards,

Holm

[Martin Husemann]

Post by Anders Magnusson
Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.

My 4000/96 has this:

asc0 at vsbus0 csr 0x26000080 vec 510 ipl 17 maskbit 1
asc0: NCR53C94, 25MHz, SCSI ID 6

and works fine.

SIMH is using MSCP. While there, does anyone have ideas for
http://gnats.netbsd.org/48826 ?

Martin

[Anders Magnusson]

Post by Martin Husemann
SIMH is using MSCP. While there, does anyone have ideas for
http://gnats.netbsd.org/48826 ?

No, but it should be simple to find.

Did you use another compiler in -current than in 6.1.4?

-- Ragge

[Martin Husemann]

Post by Anders Magnusson
Did you use another compiler in -current than in 6.1.4?

No, both gcc 4.1.

Martin

[Holm Tiffe]

Post by Martin Husemann

Post by Anders Magnusson
Did you use another compiler in -current than in 6.1.4?

No, both gcc 4.1.
Martin

Martin, what the heck has the 11/780 todo with the VaxStations?
Please open another thread for this.

Regards,

Holm

[Cory Smelosky]

Sent from mobile device that advertises itself for no good reason

Post by Martin Husemann

Post by Anders Magnusson
Did you use another compiler in -current than in 6.1.4?

No, both gcc 4.1.

4.1 can still generate VAX code?

Post by Martin Husemann
Martin

[Holm Tiffe]

Post by Anders Magnusson

Post by Holm Tiffe
getdisklabel: no disk label
nfs_open: must mount first.
3802808+136060=0x3c1d60
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 6.99.41 (INSTALL) #0: Tue May 13 16:19:50 BST 2014
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19344 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf 0x4f0000-0x4fffff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0

Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.
-- Ragge

:-))

Ragge this time you are really not the first one that has this idea..

I've wrote four five times that the similarity betwwen all 3
machines ist the ncr controller, they have no mscp.

An erronous driver would'nt explain the page errors since it is all in RAM
to this time.

Regards,

Holm

[Anders Magnusson]

Post by Holm Tiffe

Post by Anders Magnusson
Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.
-- Ragge

:-))
Ragge this time you are really not the first one that has this idea..
I've wrote four five times that the similarity betwwen all 3
machines ist the ncr controller, they have no mscp.
An erronous driver would'nt explain the page errors since it is all in RAM
to this time.

Well, it happens when you newfs, doesn't it? newfs uses mmap, and here
are some funny parts since the 5380 only do DMA to a private area of DMA
RAM where the data gets copied to/from.

// Ragge

[Holm Tiffe]

Post by Anders Magnusson

Post by Holm Tiffe

Post by Anders Magnusson
Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.
-- Ragge

:-))
Ragge this time you are really not the first one that has this idea..
I've wrote four five times that the similarity betwwen all 3
machines ist the ncr controller, they have no mscp.
An erronous driver would'nt explain the page errors since it is all in RAM
to this time.

Well, it happens when you newfs, doesn't it? newfs uses mmap, and here
are some funny parts since the 5380 only do DMA to a private area of DMA
RAM where the data gets copied to/from.
// Ragge

Not only newfs. Tar has paniced the system also while extracting the
base.tgz (...gzip is used..).
Do you mean that the DMA Buffer from the NCR driver overlaps an Area that
mmap has given to newfs?


I have now the -current from David running on the M28, no not right, but
the install system. I've mounted some directory from my FreeBSD WS and the
M38 is extracting flawlessly the binary sets over nfs.
It isn't a direct comparsion, but last time I've tried this on the M76 on
to the disk tar paniced the system.
The M38 hs 24MB RAM the M76 only 16MB but the errors are similar
(disklabel, newfs, tar). All have todo with disk activity.
So in my opinion the cpu (Rigel or CVAX) is irrelevant here.

I've found a posting from 2002 on the Net:

http://osdir.com/ml/os.netbsd.ports.vax/2002-10/msg00053.html

I would try this. Does someone know where I can get an 1.5.2 iso image
for vax from?

Regards,

Holm

[Holm Tiffe]

Post by Holm Tiffe

Post by Anders Magnusson

Post by Holm Tiffe

Post by Anders Magnusson
Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.
-- Ragge

:-))
Ragge this time you are really not the first one that has this idea..
I've wrote four five times that the similarity betwwen all 3
machines ist the ncr controller, they have no mscp.
An erronous driver would'nt explain the page errors since it is all in RAM
to this time.

Well, it happens when you newfs, doesn't it? newfs uses mmap, and here
are some funny parts since the 5380 only do DMA to a private area of DMA
RAM where the data gets copied to/from.
// Ragge

Not only newfs. Tar has paniced the system also while extracting the
base.tgz (...gzip is used..).
Do you mean that the DMA Buffer from the NCR driver overlaps an Area that
mmap has given to newfs?
I have now the -current from David running on the M28, no not right, but
the install system. I've mounted some directory from my FreeBSD WS and the
M38 is extracting flawlessly the binary sets over nfs.
It isn't a direct comparsion, but last time I've tried this on the M76 on
to the disk tar paniced the system.
The M38 hs 24MB RAM the M76 only 16MB but the errors are similar
(disklabel, newfs, tar). All have todo with disk activity.
So in my opinion the cpu (Rigel or CVAX) is irrelevant here.
http://osdir.com/ml/os.netbsd.ports.vax/2002-10/msg00053.html
I would try this. Does someone know where I can get an 1.5.2 iso image
for vax from?
Regards,
Holm
--

Another Panic while trying to copy some files from the mfs to /dev/sd0a on
the M38 running current from the cdrom:

# mkdir var
mkdir: var: File exists
# mkdir sbin
# cd sbin
# cp /sbin/* .
start = 1, len = 4095, fs = /mnt
offset=1166 1166
cg 0
panic: ffs_alloccg: map corrupted

dump to dev 23,1 not possible

?06 HLT INST
PC = 8003BE99
Regards,
Holm

[Holm Tiffe]

Post by Holm Tiffe

Post by Holm Tiffe

Post by Anders Magnusson

Post by Holm Tiffe

Post by Anders Magnusson
Another thing that just popped up: All the machines that has problem
has the same scsi controller (5380), eh?
The 4000/60 or 90 series has 5194, 4000/300 (and simh) uses MSCP I assume.
So it may be something in the driver for that scsi chip that is failing.
-- Ragge

:-))
Ragge this time you are really not the first one that has this idea..
I've wrote four five times that the similarity betwwen all 3
machines ist the ncr controller, they have no mscp.
An erronous driver would'nt explain the page errors since it is all in RAM
to this time.

Well, it happens when you newfs, doesn't it? newfs uses mmap, and here
are some funny parts since the 5380 only do DMA to a private area of DMA
RAM where the data gets copied to/from.
// Ragge

Not only newfs. Tar has paniced the system also while extracting the
base.tgz (...gzip is used..).
Do you mean that the DMA Buffer from the NCR driver overlaps an Area that
mmap has given to newfs?
I have now the -current from David running on the M28, no not right, but
the install system. I've mounted some directory from my FreeBSD WS and the
M38 is extracting flawlessly the binary sets over nfs.
It isn't a direct comparsion, but last time I've tried this on the M76 on
to the disk tar paniced the system.
The M38 hs 24MB RAM the M76 only 16MB but the errors are similar
(disklabel, newfs, tar). All have todo with disk activity.
So in my opinion the cpu (Rigel or CVAX) is irrelevant here.
http://osdir.com/ml/os.netbsd.ports.vax/2002-10/msg00053.html
I would try this. Does someone know where I can get an 1.5.2 iso image
for vax from?
Regards,
Holm
--

Another Panic while trying to copy some files from the mfs to /dev/sd0a on
# mkdir var
mkdir: var: File exists
# mkdir sbin
# cd sbin
# cp /sbin/* .
start = 1, len = 4095, fs = /mnt
offset=1166 1166
cg 0
panic: ffs_alloccg: map corrupted
dump to dev 23,1 not possible
?06 HLT INST
PC = 8003BE99
Regards,
Holm

I've booted Daves -current diskless on the M38 and tried to install on the
local disk. The result ist always the same:

We now have your BSD-disklabel partitions as:
This is your last chance to change them.

Start MB End MB Size MB FS type Newfs Mount Mount point
-------uid 0, pid 6, command sysinst, on /: file system full

/: write failed, file system is full
pid 6 (sysinst): user write of ***@0x7f61f000 at 178520 failed: 28
[1] Segmentation fault sysinst
# .profile etc mnt2 sysinstmsgs.de
targetroot
bin kern sbin sysinstmsgs.es tmp
boot libexec sysinst sysinstmsgs.fr usr
dev mnt sysinst.core sysinstmsgs.pl var
# /dev/md0a on / type ffs (local)
#

So, now I nees some ideas. What should I try next?

Regards,

Holm

[Holm Tiffe]

Holm Tiffe wrote:

NetBSD 1.5.3 is running flawlessly so far and I'm currently unpacking the
sets to the Quantum Disk.

Somewhere between that 1.5.3 and 1.6.2 the VS3100 has died...

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe
NetBSD 1.5.3 is running flawlessly so far and I'm currently unpacking the
sets to the Quantum Disk.
Somewhere between that 1.5.3 and 1.6.2 the VS3100 has died...

Which definitely rules out any hardware issues. As it would seem the
problems also are not universal, it would seem to be some specific
hardware in your machine. And since the problem happens when working
with the disk, the SCSI subsystem is the prime suspect.

Afraid I can't help much in there. I have not played with that code
much, and I also don't have a matching machine to reproduce the problem.

I hope someone else have a similar machine on which to reproduce and fix
this.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe
NetBSD 1.5.3 is running flawlessly so far and I'm currently unpacking the
sets to the Quantum Disk.
Somewhere between that 1.5.3 and 1.6.2 the VS3100 has died...

Which definitely rules out any hardware issues. As it would seem the
problems also are not universal, it would seem to be some specific
hardware in your machine. And since the problem happens when working
with the disk, the SCSI subsystem is the prime suspect.
Afraid I can't help much in there. I have not played with that code
much, and I also don't have a matching machine to reproduce the problem.
I hope someone else have a similar machine on which to reproduce and fix
this.
Johnny

Yes, this is definitve not easy to find a such long lasting bug.
Even if I can draw 1.5.3 Sources out of the CVS (can I?) I think
it wouldn't be possible to crossbuild the entire "world" on my PC.

First I'll try to install fully that 1.5.3 to the disk (still running)
and verify if it is behaving correctly (kernel build?).
Maybe before that I'll put the disk in the M76 to look if it goes
identically there.

Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

Other hints somebody?

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
NetBSD 1.5.3 is running flawlessly so far and I'm currently unpacking the
sets to the Quantum Disk.
Somewhere between that 1.5.3 and 1.6.2 the VS3100 has died...

Which definitely rules out any hardware issues. As it would seem the
problems also are not universal, it would seem to be some specific
hardware in your machine. And since the problem happens when working
with the disk, the SCSI subsystem is the prime suspect.
Afraid I can't help much in there. I have not played with that code
much, and I also don't have a matching machine to reproduce the problem.
I hope someone else have a similar machine on which to reproduce and fix
this.
Johnny

Yes, this is definitve not easy to find a such long lasting bug.
Even if I can draw 1.5.3 Sources out of the CVS (can I?) I think
it wouldn't be possible to crossbuild the entire "world" on my PC.

Not sure if cross-builds had been made possible yet back then.
But yes, you can definitely get the sources out of cvs. That is what cvs
is for.

Post by Holm Tiffe
First I'll try to install fully that 1.5.3 to the disk (still running)
and verify if it is behaving correctly (kernel build?).
Maybe before that I'll put the disk in the M76 to look if it goes
identically there.

Since you've observed the same problems on that machine, odds are that
1.5.3 will also work fine on that machine.

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
NetBSD 1.5.3 is running flawlessly so far and I'm currently unpacking the
sets to the Quantum Disk.
Somewhere between that 1.5.3 and 1.6.2 the VS3100 has died...

Which definitely rules out any hardware issues. As it would seem the
problems also are not universal, it would seem to be some specific
hardware in your machine. And since the problem happens when working
with the disk, the SCSI subsystem is the prime suspect.
Afraid I can't help much in there. I have not played with that code
much, and I also don't have a matching machine to reproduce the problem.
I hope someone else have a similar machine on which to reproduce and fix
this.
Johnny

Yes, this is definitve not easy to find a such long lasting bug.
Even if I can draw 1.5.3 Sources out of the CVS (can I?) I think
it wouldn't be possible to crossbuild the entire "world" on my PC.

Not sure if cross-builds had been made possible yet back then.
But yes, you can definitely get the sources out of cvs. That is what cvs
is for.

Post by Holm Tiffe
First I'll try to install fully that 1.5.3 to the disk (still running)
and verify if it is behaving correctly (kernel build?).
Maybe before that I'll put the disk in the M76 to look if it goes
identically there.

Since you've observed the same problems on that machine, odds are that
1.5.3 will also work fine on that machine.

..likely. At the moment I'm fighting with bootstrap and disklabel ...

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.

More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.
More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.
Johnny

Hmm.. that wasn't there as I've experimented last time with taht rtVAX and
netbooting.. but I'll look for, just in case ...

Another thing:

It is curious, but I can't get the M38 boot from sd0 (dka300).
I've reinstalled the label with 1.5.2 and uses disklabel and
usr/mdec/installboot to install the sdboot on the disk.
I've even enabled the writing of the label with disklabel -W.

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist
b dka300

-DKA300
85 RESTART SYS
84 FAIL

83 BOOT SYS
?41 DEVASSIGN, 0
84 FAIL

I'm remembering that I've read something that boot wasn't supported from
VaxStations sometimes. Is 1.5.3 old enoug for that to be true or should it
work?

So far as I know the sdboot should load boot from the rootfs which then
loads the kernel... I had no problem with that while experimenting mit 6.x

The disklabel is as follows:

# disklabel sd0|less
# /dev/rsd0c:
type: SCSI
disk: FIREBALL_TM2110S
label: fictitious
flags:
bytes/sector: 512
sectors/track: 151
tracks/cylinder: 4
sectors/cylinder: 604
cylinders: 6810
total sectors: 4124736
rpm: 4500
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0

6 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 262144 16 4.2BSD 1024 8192 16 # (Cyl. 0*- 434*)
b: 262144 262160 swap # (Cyl. 434*- 868*)
c: 4124736 0 unused 0 0 # (Cyl. 0 - 6829*)
d: 131072 524304 4.2BSD 1024 8192 16 # (Cyl. 868*- 1085*)
e: 1024000 655376 4.2BSD 1024 8192 16 # (Cyl. 1085*- 2780*)
f: 2445360 1679376 4.2BSD 1024 8192 16 # (Cyl. 2780*- 6829*)


what about the 16 blocks offset from the rootfs to the beginning of the
disk? I know that in the past the offset was set to 0 normally and the fs
reserved place if it was the rootfs. Later the Offset 16 or 64 was introduced
on FreeBSD.. how is this handled here?

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.
More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.
Johnny

Hmm.. that wasn't there as I've experimented last time with taht rtVAX and
netbooting.. but I'll look for, just in case ...

Don't hurt to check. And I definitely remember the system just hanging
if /dev wasn't populated.

Post by Holm Tiffe
It is curious, but I can't get the M38 boot from sd0 (dka300).

[...]

I don't think it was ever not supported to boot, but getting the disk
label on the disk, as well as getting the boot blocks on the disk used
to be very tricky. The tools did not work well.

The fact that you seem to have a fictitious label suggests that this is
your problem.

Afraid I can't give good instructions at that point. I used to have to
jump through various hoops, incantations of disklabel and bypassing the
disk cache in order to get a label on the disk.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.
More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.
Johnny

Hmm.. that wasn't there as I've experimented last time with taht rtVAX and
netbooting.. but I'll look for, just in case ...

Don't hurt to check. And I definitely remember the system just hanging
if /dev wasn't populated.

Post by Holm Tiffe
It is curious, but I can't get the M38 boot from sd0 (dka300).

[...]
I don't think it was ever not supported to boot, but getting the disk
label on the disk, as well as getting the boot blocks on the disk used
to be very tricky. The tools did not work well.
The fact that you seem to have a fictitious label suggests that this is
your problem.
Afraid I can't give good instructions at that point. I used to have to
jump through various hoops, incantations of disklabel and bypassing the
disk cache in order to get a label on the disk.
Johnny

Hm. I'm booting -current over the net now, will try to using its
installboot.
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.

Is it possible that thre is something wrong with interrupts..?

..mumble...


Regards,

Holm

[Cory Smelosky]

Sent from mobile device that advertises itself for no good reason

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.
More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.
Johnny

Hmm.. that wasn't there as I've experimented last time with taht rtVAX and
netbooting.. but I'll look for, just in case ...

Don't hurt to check. And I definitely remember the system just hanging
if /dev wasn't populated.

Post by Holm Tiffe
It is curious, but I can't get the M38 boot from sd0 (dka300).

[...]
I don't think it was ever not supported to boot, but getting the disk
label on the disk, as well as getting the boot blocks on the disk used
to be very tricky. The tools did not work well.
The fact that you seem to have a fictitious label suggests that this is
your problem.
Afraid I can't give good instructions at that point. I used to have to
jump through various hoops, incantations of disklabel and bypassing the
disk cache in order to get a label on the disk.
Johnny

Hm. I'm booting -current over the net now, will try to using its
installboot.
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

More recent netbsd is much much much much much bigger and heavier tbh.

Post by Holm Tiffe
..mumble...
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583

[Holm Tiffe]

Post by Cory Smelosky

Post by Holm Tiffe
Is it possible that thre is something wrong with interrupts..?

More recent netbsd is much much much much much bigger and heavier tbh.

We are talking about the loading of the kernel over nfs, the -current
kerenl is decompressed 3803720 byte s in size, the 1.5.3 1417899 bytes.
That doesn't explain why it takes 100 times as long to load the -current
kernel (no kidding!).
The compressed kernel from - current is 1650631 Bytes long and gzipped.

I can measure the loading time if you wish..

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Next thing would be NEtbooting and teht the folowing available releases
and to find out where it stops.
Anyone knows what the kernel tries next after putting out this "root file
system is ffs" (or so?). That is where 1.6.2 simply halts...

I seem to remember that the main reason if it stops there is if you do
not have /dev populated.
Johnny

Hmm, it halts wenn booting from the vax.iso from NetBSD.org. Not sure if
/dev is populated properly there :-))

Oh. I thought it halted when booting your disk.
I would expect the CD to have /dev populated.
More recent versions will setup a /dev on the fly if it don't exist, but
it takes a hell of a long time on a VAX, I can tell...
But I have no memory of that ability being in 1.5.3.
Johnny

Hmm.. that wasn't there as I've experimented last time with taht rtVAX and
netbooting.. but I'll look for, just in case ...

Don't hurt to check. And I definitely remember the system just hanging
if /dev wasn't populated.

Post by Holm Tiffe
It is curious, but I can't get the M38 boot from sd0 (dka300).

[...]
I don't think it was ever not supported to boot, but getting the disk
label on the disk, as well as getting the boot blocks on the disk used
to be very tricky. The tools did not work well.
The fact that you seem to have a fictitious label suggests that this is
your problem.
Afraid I can't give good instructions at that point. I used to have to
jump through various hoops, incantations of disklabel and bypassing the
disk cache in order to get a label on the disk.
Johnny

Hm. I'm booting -current over the net now, will try to using its
installboot.

Back in the 1.5 days, I believe I used disklabel to install the boot
blocks... Check the arguments to disklabel, there are several that are
relevant here...

Post by Holm Tiffe
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

No idea. I wouldn't suspect interrupts to be the problem, but I can't
really exclude anything.

Johnny

[Holm Tiffe]

Johnny Billquist wrote:

[..]

Post by Johnny Billquist

Post by Holm Tiffe
Hm. I'm booting -current over the net now, will try to using its
installboot.

Back in the 1.5 days, I believe I used disklabel to install the boot
blocks... Check the arguments to disklabel, there are several that are
relevant here...

I've tried installboot and disklabel in several combinations of the
arguments and watched the contens of /dev/rsd0c and wasn't able to
install the boot successfully.

But :-)

The installboot from -current using the sdboot from -current worked
at the first try. I can boot 1.5.3 from the Quantum disk.
The primary bootstrap is rev 1.11 on both systems, dont checked for
differences in the 2nd bootstrap jet..

Post by Johnny Billquist

Post by Holm Tiffe
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

No idea. I wouldn't suspect interrupts to be the problem, but I can't
really exclude anything.
Johnny

:-)

Who can..

That booting is really (really!) dog slow. It takes 15-20 minutes at least
where 1.5.3 is up in a minute or two or so..

Since this happens while booting from cdrom and from the net (from the same
server) I think something is running in timeouts or so..

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe
[..]

Post by Johnny Billquist

Post by Holm Tiffe
Hm. I'm booting -current over the net now, will try to using its
installboot.

Back in the 1.5 days, I believe I used disklabel to install the boot
blocks... Check the arguments to disklabel, there are several that are
relevant here...

I've tried installboot and disklabel in several combinations of the
arguments and watched the contens of /dev/rsd0c and wasn't able to
install the boot successfully.
But :-)
The installboot from -current using the sdboot from -current worked
at the first try. I can boot 1.5.3 from the Quantum disk.
The primary bootstrap is rev 1.11 on both systems, dont checked for
differences in the 2nd bootstrap jet..

Excellent.
Thinking more about it, I might actually have been using dd in the end
to get the boot block in... :-)
I seldom installed a new boot block back then, since once you had one
in, it usually worked and you never touched it again.

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

No idea. I wouldn't suspect interrupts to be the problem, but I can't
really exclude anything.
Johnny

:-)
Who can..
That booting is really (really!) dog slow. It takes 15-20 minutes at least
where 1.5.3 is up in a minute or two or so..

I bet there are several factors, but the unzipping is most of it, I think.
If I remember right, the spinner moves once for every block read (or n
blocks). But the unpacking and moving around will not move the spinner,
which is a data point here.

Post by Holm Tiffe
Since this happens while booting from cdrom and from the net (from the same
server) I think something is running in timeouts or so..

Well, the thing in common then is the unpacking. Reading is done through
two very different paths...

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe
[..]

Post by Johnny Billquist

Post by Holm Tiffe
Hm. I'm booting -current over the net now, will try to using its
installboot.

Back in the 1.5 days, I believe I used disklabel to install the boot
blocks... Check the arguments to disklabel, there are several that are
relevant here...

I've tried installboot and disklabel in several combinations of the
arguments and watched the contens of /dev/rsd0c and wasn't able to
install the boot successfully.
But :-)
The installboot from -current using the sdboot from -current worked
at the first try. I can boot 1.5.3 from the Quantum disk.
The primary bootstrap is rev 1.11 on both systems, dont checked for
differences in the 2nd bootstrap jet..

Excellent.
Thinking more about it, I might actually have been using dd in the end
to get the boot block in... :-)
I seldom installed a new boot block back then, since once you had one
in, it usually worked and you never touched it again.

That's the primary source of my problems:

One installs a NetBSD on a VAX and is updating this thing, not new
installing. This way you may get a working -current sometime, but Nobody
knows if this is still INSTALLABLE at this platform.

Using dd for install the bootstrap has been my next idea, but I had to read
about the exact location of the boot on the disk. It isn't starting at 0 so
far as I know.

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

No idea. I wouldn't suspect interrupts to be the problem, but I can't
really exclude anything.
Johnny

:-)
Who can..
That booting is really (really!) dog slow. It takes 15-20 minutes at least
where 1.5.3 is up in a minute or two or so..

I bet there are several factors, but the unzipping is most of it, I think.
If I remember right, the spinner moves once for every block read (or n
blocks). But the unpacking and moving around will not move the spinner,
which is a data point here.

The first time it is spinning faster and then it slows down.
Like a buffer that is read in and then decompressed as block.
Every next block that get read in has an extra handling or so.
This is how it looks. Nevertheless it takes much much to long.

Post by Johnny Billquist

Post by Holm Tiffe
Since this happens while booting from cdrom and from the net (from the same
server) I think something is running in timeouts or so..

Well, the thing in common then is the unpacking. Reading is done through
two very different paths...
Johnny

At first, I have 1.5.3 running multiuser in the network, fine so far but a
little bit dated. I'm called now to come to the barbicue down in the
backyard. Next I'll measure the times for you so that you get an eassumption
how long this kernel loading takes...

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
[..]

Post by Johnny Billquist

Post by Holm Tiffe
Hm. I'm booting -current over the net now, will try to using its
installboot.

Back in the 1.5 days, I believe I used disklabel to install the boot
blocks... Check the arguments to disklabel, there are several that are
relevant here...

I've tried installboot and disklabel in several combinations of the
arguments and watched the contens of /dev/rsd0c and wasn't able to
install the boot successfully.
But :-)
The installboot from -current using the sdboot from -current worked
at the first try. I can boot 1.5.3 from the Quantum disk.
The primary bootstrap is rev 1.11 on both systems, dont checked for
differences in the 2nd bootstrap jet..

Excellent.
Thinking more about it, I might actually have been using dd in the end
to get the boot block in... :-)
I seldom installed a new boot block back then, since once you had one
in, it usually worked and you never touched it again.

One installs a NetBSD on a VAX and is updating this thing, not new
installing. This way you may get a working -current sometime, but Nobody
knows if this is still INSTALLABLE at this platform.
Using dd for install the bootstrap has been my next idea, but I had to read
about the exact location of the boot on the disk. It isn't starting at 0 so
far as I know.

It truly is block 0. The boot rom have no idea about NetBSD partition
schemes, but just reads in block 0, and starts running...

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
While watching again that spinner, there MUST be something wrong.
You can't compare the speed of netbooting 1.5.3 and 6-current.
The differene is by factor 100 or more. I've gunzipped several kernels in
the mantime, that really doesn't take that long, even on that slow VAXen.
Is it possible that thre is something wrong with interrupts..?

No idea. I wouldn't suspect interrupts to be the problem, but I can't
really exclude anything.
Johnny

:-)
Who can..
That booting is really (really!) dog slow. It takes 15-20 minutes at least
where 1.5.3 is up in a minute or two or so..

I bet there are several factors, but the unzipping is most of it, I think.
If I remember right, the spinner moves once for every block read (or n
blocks). But the unpacking and moving around will not move the spinner,
which is a data point here.

The first time it is spinning faster and then it slows down.
Like a buffer that is read in and then decompressed as block.
Every next block that get read in has an extra handling or so.
This is how it looks. Nevertheless it takes much much to long.

Agree. Lots of things nowadays are way too slow on a VAX. You'll see the
difference once you get current running. 1.5 just flies by...

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
Since this happens while booting from cdrom and from the net (from the same
server) I think something is running in timeouts or so..

Well, the thing in common then is the unpacking. Reading is done through
two very different paths...
Johnny

At first, I have 1.5.3 running multiuser in the network, fine so far but a
little bit dated. I'm called now to come to the barbicue down in the
backyard. Next I'll measure the times for you so that you get an eassumption
how long this kernel loading takes...

No need. I know it takes a long time. I've netbooted current on the 3600
I mentioned a number of times.
From start of booting until I get the login prompt that machine takes
about 30 minutes.

Johnny

[Toby Thain]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe
...
That booting is really (really!) dog slow. It takes 15-20 minutes at least
where 1.5.3 is up in a minute or two or so..

I bet there are several factors, but the unzipping is most of it, I think.
If I remember right, the spinner moves once for every block read (or n
blocks). But the unpacking and moving around will not move the spinner,
which is a data point here.

The first time it is spinning faster and then it slows down.
Like a buffer that is read in and then decompressed as block.
Every next block that get read in has an extra handling or so.
This is how it looks. Nevertheless it takes much much to long.

Agree. Lots of things nowadays are way too slow on a VAX. You'll see the
difference once you get current running. 1.5 just flies by...

This is exactly what I want to know, because I have MicroVAX II's here
and am trying to get a handle on what is realistic to run on them.

Currently I netboot 1.4.1. Should I just forget about anything > 1.5?

--Toby

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist
Johnny

At first, I have 1.5.3 running multiuser in the network, fine so far but a
little bit dated. I'm called now to come to the barbicue down in the
backyard. Next I'll measure the times for you so that you get an eassumption
how long this kernel loading takes...

No need. I know it takes a long time. I've netbooted current on the 3600
I mentioned a number of times.
From start of booting until I get the login prompt that machine takes
about 30 minutes.
Johnny

Ok. ... and where we begin now? (hope to prevent silence this time).

I've now mounted the disk with 1.5.3 to the VS3176 and got something
like this on the first try to boot:

VAXstation 3100/m76
cpu: KA43
primary cache status: 1a<HIT,REFRESH,ENABLE>
secondary cache status: ffe1<TPE,DPE,MISS,ENABLE>
total memory = 16124 KB
avail memory = 12204 KB

[..]

memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
memory error!
primary cache status: 122a<BCHIT,DPERR,INTR,REFRESH,ENABLE>
secondary cache status: fff1<TPE,DPE,MISS,DIRTY,ENABLE>
wsdisplay0: screen 0-7 added (128x57, vt100 emulation)
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <FUJITSU, M2954S-512, 0136> SCSI2 0/direct
fixed
sd0: 4149 MB, 5714 cyl, 9 head, 165 sec, 512 bytes/sect x 8498506 sectors
sd1 at scsibus0 target 3 lun 0: <QUANTUM, FIREBALL_TM2110S, 300X> SCSI2
0/direct fixed
sd1: 2014 MB, 6810 cyl, 4 head, 151 sec, 512 bytes/sect x 4124736 sectors
scsibus1: waiting 2 seconds for devices to settle...


Huh?

I had unmounted a Simm yesterday to find out if I could get additional ones
( seems to be not possible.. $200 and more .. No, thanks).

Before now anyvbody crys that they have known that there must be something
ba with the memory..read more ..


I've found out that this only happens if I stop the Netbooting of the
6-current (set boot esa0) with a break and then boot from dka300,
regardless of the use of unjam.
Ok, so after setting boot to dka300 and repowering that thing it looks like
this:

KA43-A V1.2

F...E...D...C...B...A_..9...8...7...6...5...4...3_..2_..1...


? C 0080 0000.4001
? 6 80A1 0000.4001
? 4 00D4 100F.1F63


83 BOOT SYS
-DKA300

Post by Johnny Billquist

Post by Holm Tiffe
NetBSD/vax boot [Jan 6 2002 22:13:30] <<
Press any key to abort autoboot 0

changing bootrpb.unit from 300 to 3
1174268+57032+195096+[85608+100959]=0x189ca7
[ preserving 186567 bytes of netbsd a.out symbol table ]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 1.5.3 (GENERIC) #5: Mon Jul 1 23:34:54 CEST 2002
***@turing.urc.uninett.no:/usr/src/sys/arch/vax/compile/GENERIC

VAXstation 3100/m76
cpu: KA43
primary cache status: 1a<HIT,REFRESH,ENABLE>
secondary cache status: ffe1<TPE,DPE,MISS,ENABLE>
total memory = 16124 KB
avail memory = 12204 KB
using 227 buffers containing 908 KB of memory
mainbus0 (root)
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 14 maskbit 5 buf
0x283e2000-0x283f1fff
le0: address 08:00:2b:23:c2:5a
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 14 maskbit 6
dz0: 4 lines
lkc0 at dz0
si0 at vsbus0 csr 0x200c0080 vec 770 ipl 14 maskbit 1
si0: NCR5380, SCSI ID 6
scsibus0 at si0: 8 targets, 8 luns per target
si1 at vsbus0 csr 0x200c0180 vec 774 ipl 14 maskbit 0
si1: NCR5380, SCSI ID 6
scsibus1 at si1: 8 targets, 8 luns per target
smg0 at vsbus0 csr 0x200f0000 vec 104 ipl 14 maskbit 3
wsdisplay0 at smg0
wsdisplay0: screen 0-7 added (128x57, vt100 emulation)
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <FUJITSU, M2954S-512, 0136> SCSI2 0/direct
fixed
sd0: 4149 MB, 5714 cyl, 9 head, 165 sec, 512 bytes/sect x 8498506 sectors
sd1 at scsibus0 target 3 lun 0: <QUANTUM, FIREBALL_TM2110S, 300X> SCSI2
0/direct fixed
sd1: 2014 MB, 6810 cyl, 4 head, 151 sec, 512 bytes/sect x 4124736 sectors
scsibus1: waiting 2 seconds for devices to settle...
boot device: sd1
root on sd1a dumps on sd1b
root file system type: ffs
swapctl: adding /dev/sd1b as swap device at priority 0
Automatic boot in progress: starting file system checks.
/dev/rsd1a: file system is clean; not checking
/dev/rsd1d: file system is clean; not checking
/dev/rsd1e: file system is clean; not checking
/dev/rsd1f: file system is clean; not checking
Setting tty flags.
Setting sysctl variables:
Starting network.
Hostname: vs3138.tsht.lan
NIS domainname: tsht.lan
add net 127.0.0.0: gateway 127.0.0.1
add net fe80::: gateway ::1
add net fec0::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::224.0.0.0: gateway ::1
add net ::127.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
add net ::255.0.0.0: gateway ::1
add net 2002:e000::: gateway ::1
add net 2002:7f00::: gateway ::1
add net 2002:0000::: gateway ::1
add net 2002:ff00::: gateway ::1
add net ::0.0.0.0: gateway ::1
IPv6 mode: host
Configuring network interfaces: le0.
add net default: gateway 192.168.50.254
Adding interface aliases:
Building databases...
Starting syslogd.
Checking for core dump...
savecore: no core dump
Mounting all filesystems...
Clearing /tmp.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Creating runtime link editor directory cache.
Updating motd.
starting local daemons:.
Starting inetd.
Starting cron.
Sun May 23 04:27:01 PDT 1999

NetBSD/vax (vs3138.tsht.lan) (console)

login: root
Password:
May 23 04:33:18 vs3138 login: ROOT LOGIN (root) ON console
May 23 04:33:18 vs3138 login: ROOT LOGIN (root) ON console
Copyright (c) 1996, 1997, 1998, 1999, 2000
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

NetBSD 1.5.3 (GENERIC) #5: Mon Jul 1 23:34:54 CEST 2002

Welcome to NetBSD!

Terminal type? [unknown] vt220
Terminal type is vt220.
We recommend creating a non-root account and using su(1) for root access.
vs3138# env
HOME=/root
SHELL=/bin/csh
TERM=unknown
LOGNAME=root
USER=root
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
PWD=/root
BLOCKSIZE=1k
vs3138#

So it successfully boots like the M38.

I've put in the environment here since it knows nothing about the entered
vt220... hmm, minor glitch, maybe something is wrong with my install,
the same happens on the VS3138.

I'll copy now the 1.5.3 to a disk for the M76. Afther that I'll check the
1.6 and 1.61 if I could find the cause for the stall at the boot of 1.6.2.
Ok, I've booted the 1.6.2 from the cdrom where it stalled and the 1.5.3 as
Netboot..maybe the t.6.2 is working with Netboot too?

I'll check this.

On 1.5.3 the ncr driver is called siN, where the later releases used ncrN
so far as I remember. Was that a bigger change, other code or just renaming?

Common Guys, you must get louder now...

Regards,

Holm

[Johnny Billquist]

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist
Johnny

At first, I have 1.5.3 running multiuser in the network, fine so far but a
little bit dated. I'm called now to come to the barbicue down in the
backyard. Next I'll measure the times for you so that you get an eassumption
how long this kernel loading takes...

No need. I know it takes a long time. I've netbooted current on the 3600
I mentioned a number of times.
From start of booting until I get the login prompt that machine takes
about 30 minutes.
Johnny

Ok. ... and where we begin now? (hope to prevent silence this time).

Correct me if I'm wrong.
The problem you are observing is that things like newfs and tar crash
with a signal 11.
That is a real bug, and something that someone needs to look at. I do
not have a machine to reproduce this on. If noone else have one, or the
time to look at it right now, then it's not going to get fixed right now.
The most important thing then is to file a bug so that this do not get
forgotten.

The second issue you are talking about is the slowness of current
versions. That is not really a bug in the same sense (but it might still
be a bug in the end). I, and others, are aware that performance sucks. I
occasionally try to look at it, but don't really have time. Others
occasionally look at it as well.
You can definitely file a bug on that one as well, but who knows when or
how it will be worked on.

As for you specific machines and possible hardware problems. While it
looks funny I have no idea if you actually have an issue there or not.
I would start by checking those self test errors to see what they mean.

Johnny

[Holm Tiffe]

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist

Post by Holm Tiffe

Post by Johnny Billquist
Johnny

At first, I have 1.5.3 running multiuser in the network, fine so far but a
little bit dated. I'm called now to come to the barbicue down in the
backyard. Next I'll measure the times for you so that you get an eassumption
how long this kernel loading takes...

No need. I know it takes a long time. I've netbooted current on the 3600
I mentioned a number of times.
From start of booting until I get the login prompt that machine takes
about 30 minutes.
Johnny

Ok. ... and where we begin now? (hope to prevent silence this time).

Correct me if I'm wrong.
The problem you are observing is that things like newfs and tar crash
with a signal 11.
That is a real bug, and something that someone needs to look at. I do
not have a machine to reproduce this on. If noone else have one, or the
time to look at it right now, then it's not going to get fixed right now.
The most important thing then is to file a bug so that this do not get
forgotten.
The second issue you are talking about is the slowness of current
versions. That is not really a bug in the same sense (but it might still
be a bug in the end). I, and others, are aware that performance sucks. I
occasionally try to look at it, but don't really have time. Others
occasionally look at it as well.
You can definitely file a bug on that one as well, but who knows when or
how it will be worked on.
As for you specific machines and possible hardware problems. While it
looks funny I have no idea if you actually have an issue there or not.
I would start by checking those self test errors to see what they mean.
Johnny

You are right Johnny.
I don't have a single application where I need to run those machines with
NetBSD, the only thing I want is to run NetBSD.
We are here on the ports-vax mailing list from NetBSD, I think that is the
Place where the developers communicate for that port and when I get no
resonance here for fixing that bugs, then simply no one needs it, right?
I've already asked Martin in the past if I should send him the M38 for
debugging purposes, but sending them to you ot overseas where a little bit
expensive..
I don't need it back. I've bought 3 VS3100 from Ebay with some terminals and
a DECServer 300 (or, so, MC68000 in there) for 100 Euros. The machines
where yellow from tabac tar, cleaned and repaired 2 of them and gave the 3rd
one to a friend. ( Even this one is still available if needed, it was a 2nd
M38) If I can help with that thing that NetBSD-vax isn't dying then that is
a good thing. I know, the machines are slow and nobody is really wanting
them, My VS4000/90 would be a completly different case, I know about this.

The slowness of booting IS a bug in my eyes, there MUST be something wrong.
The sum of needed time for decompressing a kernel and loading it over
network or from CD is much much smaller as the time ithat is takes
actually. Maybe it is broken by the design od the actual loader, may be..


For sure I can file bug reports, but since nobody has a machine like mine,
who will ever fix that?

So I think it is the better way if you all with your knowledge about VAXes
telling me where I have to look for what. I'll happyly test and report bak
if I have the time. I don't want that you should fix that for me, I want to
help only.

BTW: OpenBSD is still running on that machines and it still uses a driver
called si0 like the 1.5 or 1.6 NetBSDs. Is that a hint?


Regards,

Holm

[Holm Tiffe]

Post by Holm Tiffe
I've already asked Martin in the past if I should send him the M38 for
debugging purposes, but sending them to you ot overseas where a little bit
expensive..

..got a Mail from Martin, I'll send him the M38.

Regards,

Holm

[Dave McGuire]

Post by Holm Tiffe

Post by Holm Tiffe
I've already asked Martin in the past if I should send him the M38 for
debugging purposes, but sending them to you ot overseas where a little bit
expensive..

..got a Mail from Martin, I'll send him the M38.

Wait...Is Martin in the USA? If he is, I can send him an M38; it
would be cheaper for me than for you.

-Dave

[Martin Husemann]

Post by Dave McGuire
Wait...Is Martin in the USA? If he is, I can send him an M38; it
would be cheaper for me than for you.

Heh, lots of machines to collect everywhere ;-)

I'm in germany (as is Holm), so this is "local shipping". Please, nobody
tell my wife about it, she thinks the machine room is already crowded.

Martin

[Christos Zoulas]

Post by Martin Husemann

Post by Dave McGuire
Wait...Is Martin in the USA? If he is, I can send him an M38; it
would be cheaper for me than for you.

Heh, lots of machines to collect everywhere ;-)
I'm in germany (as is Holm), so this is "local shipping". Please, nobody
tell my wife about it, she thinks the machine room is already crowded.

Nonsense, you just need to move it to a bigger room.

christos

[Dave McGuire]

Post by Christos Zoulas

Post by Martin Husemann

Post by Dave McGuire
Wait...Is Martin in the USA? If he is, I can send him an M38; it
would be cheaper for me than for you.

Heh, lots of machines to collect everywhere ;-)
I'm in germany (as is Holm), so this is "local shipping". Please, nobody
tell my wife about it, she thinks the machine room is already crowded.

Nonsense, you just need to move it to a bigger room.

That's the spirit!

-Dave

[Holm Tiffe]

Post by Martin Husemann

Post by Dave McGuire
Wait...Is Martin in the USA? If he is, I can send him an M38; it
would be cheaper for me than for you.

Heh, lots of machines to collect everywhere ;-)
I'm in germany (as is Holm), so this is "local shipping". Please, nobody
tell my wife about it, she thinks the machine room is already crowded.
Martin

Simply tell her that you send me the 11/94 instead... *grin*

Regards,

Holm

[Martin Husemann]

The machine arrived and boots an NFS versionn of the install CD just fine -
haven't had time to try to install and test anything serious yet though.

Martin


--8<--

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 6.99.43 (GENERIC) #1: Wed May 28 12:37:30 CEST 2014
***@seven-days-to-the-wolves.aprisoft.de:/usr/obj/vax/usr/src/sys/arch/vax/compile/GENERIC
VAXstation 3100/m{38,48}
total memory = 24436 KB
avail memory = 19528 KB
mainbus0 (root)
cpu0 at mainbus0: KA420, CVAX, 1KB L1 cache, 64KB L2 cache
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 17 maskbit 5 buf 0x4c2000-0x4d1fff
le0: address 08:00:2b:13:b1:a0
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 17 maskbit 6
dz0: 4 lines
lkkbd0 at dz0
wskbd0 at lkkbd0 mux 1
lkms0 at dz0
wsmouse0 at lkms0 mux 0
si0 at vsbus0 csr 0x200c0080 vec 770 ipl 17 maskbit 1
si0: NCR5380, SCSI ID 6
scsibus0 at si0: 8 targets, 8 luns per target
si1 at vsbus0 csr 0x200c0180 vec 774 ipl 17 maskbit 0
si1: NCR5380, SCSI ID 6
scsibus1 at si1: 8 targets, 8 luns per target
smg0 at vsbus0 csr 0x200f0000 vec 104 ipl 17 maskbit 3
smg0: could not find 8x15 font
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <IBM, DCAS-34330, S63A> disk fixed
sd0: 4028 MB, 8205 cyl, 6 head, 167 sec, 512 bytes/sect x 8250001 sectors
sd0: async, 8-bit transfers
sd1 at scsibus0 target 3 lun 0: <DEC, RZ25 (C) DEC, 0700> disk fixed
sd1: 406 MB, 1476 cyl, 9 head, 62 sec, 512 bytes/sect x 832527 sectors
sd1: async, 8-bit transfers
boot device: le0
root on le0
nfs_boot: trying DHCP/BOOTP

[Martin Husemann]

Post by Martin Husemann
The machine arrived and boots an NFS versionn of the install CD just fine -
haven't had time to try to install and test anything serious yet though.

I just tried, and I can reproduce Holm's serious trouble with this machine.
On first try I got a kernel SEGV in the exit path of disklabel, so something
seems to be corrupting kernel memory.

Martin

[Holm Tiffe]

Another quick thought - are you using the same SCSI CD-rom in all cases?

Yes, already wrote that. I think I have only one that does the job.
Installed VMS from this drive and the OpenBSD.

Regards,
Holm

[Holm Tiffe]

David Brownlee wrote:
[..]

NetBSD 1.6.2 is bootinig within a few seconds from the cdrom, no stalling
spinner at all.
-DKA500

NetBSD/vax boot [1.11 Wed Feb 11 09:14:20 UTC 2004] <<
Press any key to abort autoboot 4

changing bootrpb.unit from 500 to 5
getdisklabel: no disk label
nfs_open: must mount first.
2371692+117752=0x25fe00
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 1.6.2 (INSTALL) #0: Wed Feb 11 09:24:13 UTC 2004

***@tgm.netbsd.org:/autobuild/netbsd-1-6-PATCH002/vax/OBJ/autobuild/netbsd-1-6-PATCH002/src/sys/arch/vax/compile/INSTALL

VAXstation 3100/m76
cpu: KA43
primary cache status: 1a<HIT,REFRESH,ENABLE>
secondary cache status: ffe1<TPE,DPE,MISS,ENABLE>
total memory = 16124 KB
avail memory = 11196 KB
using 227 buffers containing 908 KB of memory
mainbus0 (root)
vsbus0 at mainbus0
vsbus0: interrupt mask 8
le0 at vsbus0 csr 0x200e0000 vec 120 ipl 14 maskbit 5 buf
0x284de000-0x284edfff
le0: address 08:00:2b:23:c2:5a
le0: 32 receive buffers, 8 transmit buffers
dz0 at vsbus0 csr 0x200a0000 vec 304 ipl 14 maskbit 6
dz0: 4 lines
lkkbd0 at dz0
wskbd0 at lkkbd0 (mux ignored)
si0 at vsbus0 csr 0x200c0080 vec 770 ipl 14 maskbit 1
si0: NCR5380, SCSI ID 6
scsibus0 at si0: 8 targets, 8 luns per target
si1 at vsbus0 csr 0x200c0180 vec 774 ipl 14 maskbit 0
si1: NCR5380, SCSI ID 6
scsibus1 at si1: 8 targets, 8 luns per target
smg0 at vsbus0 csr 0x200f0000 vec 104 ipl 14 maskbit 3
wsdisplay0 at smg0 (kbdmux ignored)
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <IBM OEM, 0663L12, s z> SCSI2 0/direct
fixed
sd0: 958 MB, 2051 cyl, 15 head, 63 sec, 512 bytes/sect x 1962030 sectors
sd0: async, 8-bit transfers
sd1 at scsibus0 target 1 lun 0: <FUJITSU, M2954S-512, 0136> SCSI2 0/direct
fixed
sd1: 4149 MB, 5714 cyl, 9 head, 165 sec, 512 bytes/sect x 8498506 sectors
sd1: async, 8-bit transfers
cd0 at scsibus0 target 5 lun 0: <TOSHIBA, CD-ROM XM-5701TA, 0167> SCSI2
5/cdrom removable
cd0: async, 8-bit transfers
scsibus1: waiting 2 seconds for devices to settle...
md0: internal 1536 KB image area
boot device: cd0
root on md0a dumps on md0b
Clock has gained 3752 days - CHECK AND RESET THE DATE.
root file system type: ffs

...but it is stopping here. No response to any return or ^T ( no shell
running) Don't know what it wants todo, I'll wait a
while..

Regards,

Holm