Hi Jason, all,

> On Tue, 21 Nov 1995 09:21:36 -0500 (EST)=20
[snip]
> Just about a month ago, I had a 14gb RAID box attached to one of my=20
> NetBSD systems.  It was the type that appears as a single SCSI disk t=
o=20
> the host.  There was a single filesystem taking up the entire space. =
=20We=20
> can do that because we use 64-bit off_t's, as opposed to the 32-bit o=
ff_t=20
> (well, long) that SunOS used.

Wow, 14 GB!

The disadvantage, however, is that when compiling stuff on my Sun3/60 u=
nder
NetBSD, the 64-bit off_t's cause lots of troubles. Apart from the file-
system stuff, anything I tried so far compiles fine, but for PGP, for
instance, I had to fix all lseek()'s, and I can't get xsky running yet,
because of similar problems.

Back to kernel-hacking:

I got my new 120M SCSI fully installed now, with the 1.1.1.1 UFS-boot o=
n it.
It's a bit stubborn in that only wants to boot from sd0, so I decided t=
o
switch SCSI-adresses (Does anyone know of a *gentle* way to open a shoe=
box?)
The disks I have are a Quantum 120M, sd0, and a 150M Maxtor, sd2.
on si_options=3D0 or 1 they work perfectly, just like on the 21-aug ker=
nel.

With si_options 3, however, I get the same behaviour as with the previo=
us
test-kernel: generally, things work fine, but when starting X (heavy lo=
ad on
the SCSI?) things start coredumping, and I get stuck in the xdm-login-
requester. I can, however, still login from the ttya or le0. (I previou=
sly
reported I couldn't, but that seems to be due to a root partition fille=
d to
the brim (107%) with core-files, the new / is twice as big.)

With si_options 7 the Sun does boot into single-user, and seems just fi=
ne
then. It will hang itself when going multiuser, somewhere in the execut=
ion
of /etc/rc, at varying positions.

Would anyone be interested in some traces, or in general more detailed
information?

How could I make si_options 1 permanent into the kernel?
Are there more kernel-settings to play with?

Paul