Subject: Re: SparcStation ipx versus Sparc Classic
To: PORT-SPARC <Port-SPARC@NetBSD.org>
From: Don Yuniskis <auryn@GCI-Net.com>
List: port-sparc
Date: 05/04/2002 20:01:56
> "der Mouse" <mouse@Rodents.Montreal.QC.CA> a ecrit:
>
> >>>>> And, very few have heads on them so dragging out a
> >>>>> keyboard/monitor just to [...]
> [...]
> >> Neither break-detect nor ttys(5) is relevant to using serial console
> >> to stop the machine's clock prior to mothballing it.
> > You missed the point.  I don't *use* serial consoles because THEY are
> > problematic (for these reasons).  So, turning off the oscillator in
> > the "clock chip" means I have to drag out a device to act as a serial
> > console *just* for the purpose of shutting off the oscillator.
> 
> Ah.  Yes, sorry, I misunderstood; I took "dragging out a
> keyboard/monitor" to refer to giving the machine a graphics head.  If

Well, *any* head...  If I have a monitor keyboard already out for
other purposes, then I might opt to use that.  Otherwise, drag out a
portable running a terminal emulator and play serial console.
*But*, I only do these things if something has *died* and I can't
talk to it over the wire...

> you normally run them with any sort of console, you should be able to
> use that console; if you normally run without any console at all, yes,

Yes.  I had originally tethered an NCD to each of these boxes.
But, powering the NCD on/off while connected causes the "problem"
wit BREAKs.  If I am going to have to exercise care in how I
attach & power sequence an external "terminal", then there is no
advantage to using the NCD's (since they can't be "permanently"
connected to serve in this secondary role) which means drag *out*
a box just for this purpose...

> any operation involving the console could be annoying.

My point exactly.  I would rather just "fix" the BBSRAM so
that it doesn't "need" to have the energy source conserved.
(And, as I said, most of the SPARCs I have came to me
with toasted batteries so it was a no-brainer to decide to
replace them while prepping the machine to put it into service)

> > It would be nice if I could plug in a console (when it appears that
> > this has happened) and:
> > - not have that drop me to the ROM monitor (BREAK)
> 
> I've never had this happen.  Perhaps it's the connectors I use or
> something; I can only conjecture.
> 
> > - have a login prompt waiting for me (ttys(5))
> > It would likewise be nice to be able to do this with a
> > monitor/keyboard without having ttya disappear.
> 
> Right.  NetBSD/sparc needs something akin to sun3's kd device.  wscons
> is *supposed* to be the Right Fix for this....

In light of that "inavailability", is there a fallback configuration
that is "always usable"?  I.e. it seems that if you start a getty
on /dev/console (ttys(5)), then also starting a getty on ttya
will give you grief if you run without a keyboard ("headless"
in my nominal case).

This suggests if you want to run headless, DON'T mention
/dev/console in ttys(5).

Yet, if you omit /dev/console, then you are inclined to
spawn a getty on ttya "knowing" that it will be the console
"in a jam" (headless).  But, then you *can't* attach a
monitor/keyboard and get a console "login:" (though you
can still use this console with the boot monitor, etc.

I.e. it would be nice if "console" and "ttya" were *never*
"equivalent".  So, you could have entries for all three in
ttys(5) and not have to worry...

BTW, I picked up a copy of gousses/rames  :>  Thanks!