Subject: Re: Installing 1.5 on a DS10
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Robert Elz <kre@munnari.OZ.AU>
List: port-alpha
Date: 02/10/2001 16:58:51
    Date:        Thu, 8 Feb 2001 15:56:02 +0100
    From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
    Message-ID:  <20010208155602.A9671@antioche.lip6.fr>

  | Well, if you're looking for stability I would recommend the 1-5
  | branch instead :)

Yes, of course, and OK, you convinced me .. though all I really need is
for it to be stable enough that I can compile new kernels on the system.
Once I can do that (or even get it running so I can compile new ones
elsewhere and ftp them and boot them) I can play from afar.   The only
real issue at the minute is getting it booted the first time (given I
am a quarter a world away from it...)

  | Well, a kernel compiled with -g, and stack trace when it panics would
  | be a good starting point. Other debug options may be way too verbose if the
  | kernel works fine.

Sure (though there's no way to actually get kdbg to this one at the minute).

Too verbose isn't an issue - I figure I can probably prevail upon people
to help me make 2 CDs and carry them to the CD drive on this system to
boot it).   If 1.5-release (the current pre 1.5.1 branch) simply works
the first time, then I can use the 2nd attempt to make an easier to use
version if needed.   But if it doesn't, I really need to get enough
info out of the first attempt (the first CD making, I can boot that CD
over and over again as needed of course) so the problem can be found
and fixed for the next one - otherwise this system will probably remain
as a Tru64 beast for the rest of its life (once it gets made operational
it won't be touched very much - this is to become the new munnari.oz.au,
and as such is an FTP server, DNS for half the universe, ...)

Once I start the install, if debug printfs out of the siop driver
were to slow the system down to a crawl, I can easily just let it
crawl for a week ...   If I was actually sure it was the siop driver
that caused this, I'd just delete it from the install kernel
completely for now - I don't need it to install onto (it will become
the root device someday, once I am happy with the config, etc - either
for Tru64 or NetBSD, mirrored, and all that - but that is all later).

So, it is unlikely that any debug noise in it would have much effect,
as once it is probed and configured, it isn't going to be used again
in the short term - it is just there (and I'm too far away to yank the
card and try it that way, if I was home, that's what I'd do).

So, if there is anything at all that would help if it was enabled,
let's just enable it, and not worry about the effects.

kre