6.0_BETA observations

[John D. Baker]

I'm making my first foray into running netbsd-6 on my hoarde of sparc
boxes, starting with my "big" workstation (SS5, 110MHz, 256MB, cgsix).

Although most of my sparc will use serial console only, a few will have
a framebuffer console. Video console handling is much improved over
netbsd-5 (where it was basically unusable due to freezing some random
time after login).

As I was simply updating over a copy of my old netbsd-5 install (NFS),
I was glad to see that it "Just Worked"(tm). I did an appreciable
amount of work at the console finishing the upgrade and adjusting things.
No stuck console.

Since wscons is turned on by default now, I set out to finish enabling
it on my installation. The result was not what I expected, though.
Running '/etc/rc.d/wscons start' handled the default/console/ttyE0
well enough, then three iterations of the following line:

wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured

followed by a line indicating that ttyE4 was added without problems.
"Stop-Fn" for "2<n<4" didn't do anything, but "n=1, n=5" switched to
the appropriate console.

When the terminals were enabled in /etc/ttys, getty complained similarly
that "/dev/ttyE[1-3]" were not configured.

I checked that the device files existed (ttyE[0-7], wsfont, wskbd(|[0-3]),
wsmouse(|[0-3]), wsmux[0-3], wsmuxctl[0-3]). I running GENERIC, so I expect
all the necessary things to be defined there.

Any hints to what I'm missing?

I tried 'startx' and the server started up, but I couldn't switch consoles
with it active. It started 'twm', but I coudln't open an xterm. Exiting
the window manager didn't terminate the server, but instead reset it.
Guessing that it would behave like its x86 counterparts, I used
Control-Alt-Backspace to "Zap" the server. Then I was able to switch
consoles again.

Right now, the console/X is not as important--I'm using the machine to
build packages that will be needed for my other (headless) sparcs via ssh.
I would eventually like to get the console/X functional.

Thanks for the work put into the sparc port for netbsd-6.

[John Nemeth]

On Aug 22, 12:26am, "John D. Baker" wrote:
}
} I'm making my first foray into running netbsd-6 on my hoarde of sparc
} boxes, starting with my "big" workstation (SS5, 110MHz, 256MB, cgsix).
}
} Although most of my sparc will use serial console only, a few will have
} a framebuffer console. Video console handling is much improved over
} netbsd-5 (where it was basically unusable due to freezing some random
} time after login).
}
} As I was simply updating over a copy of my old netbsd-5 install (NFS),
} I was glad to see that it "Just Worked"(tm). I did an appreciable
} amount of work at the console finishing the upgrade and adjusting things.
} No stuck console.
}
} Since wscons is turned on by default now, I set out to finish enabling
} it on my installation. The result was not what I expected, though.
} Running '/etc/rc.d/wscons start' handled the default/console/ttyE0
} well enough, then three iterations of the following line:
}
} wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
}
} followed by a line indicating that ttyE4 was added without problems.
} "Stop-Fn" for "2<n<4" didn't do anything, but "n=1, n=5" switched to
} the appropriate console.

Try adding this to GENERIC and rebuilding it:

# allocate a number of virtual screens at autoconfiguration time
options WSDISPLAY_DEFAULTSCREENS=4

If that does it, then we'll need to do it in the main codebase.

}-- End of excerpt from "John D. Baker"

[John D. Baker]

Returning to this issue with more data.
^^^^^^
I think someone's clock is off. My "sent" mailbox shows 6 May 2012.

Anyway...

Booting GENERIC with the stock "/etc/wscons.conf" elicits:

wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured

on the console and:

wsdisplay0: screen 4 added (std, sun emulation)

recorded in 'dmesg'.

While on screen 0, Stop-F2 through Stop-F4 do apparently nothing. Stop-F5
switches to a blank white screen with a grey cursor in the top-left
corner, presumedly screen 4. Again, Stop-F2 through Stop-F4 do apparently
nothing and Stop-F1 switches back to the terminal output on screen 0.

Just to see what would happen, I turned on the "screen 5" example in
"wscons.conf" and tried restarting wscons. I got:

wsconscfg: screen 4 is already configured

and the "not configured" message for all of the other screens, including
the one I just tried to enable.

Possible clue here: Instead of screen 5 having a terminal emulation
defined on it, I made a duplicate of screen 4:

#screen 0 - vt100
screen 1 - vt100
screen 2 - vt100
screen 3 - vt100
screen 4 - -
screen 5 - -
#screen 4 80x25bf vt100
# Note: You must uncomment the 'font ibm' line above to get a useful
# font for any 50 line screens.
#screen 5 80x50 vt100

When I restarted wscons,

wsdisplay0: screen 5 added (std, sun emulation)

was recorded in 'dmesg' (I otherwise saw no output related to the
creation of screen 5.) Pressing Stop-F6 switched me to screen 5 (I could
only really tell by the cursor flicker when switching between screens
4 and 5, but it seems to work).

Post by John Nemeth
# allocate a number of virtual screens at autoconfiguration time
options WSDISPLAY_DEFAULTSCREENS=4

I did so and it does produce the expected 4 terminal screens, although
starting "wscons" produces the following:

wsconscfg: screen 1 is already configured
wsconscfg: screen 2 is already configured
wsconscfg: screen 3 is already configured

init is able to start getty on each one and they seem to work.

[Michael]

Hello,

Post by John D. Baker
Returning to this issue with more data.
^^^^^^
I think someone's clock is off. My "sent" mailbox shows 6 May 2012.
Anyway...
wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
wsconscfg: WSDISPLAYIO_ADDSCREEN: Device not configured
wsdisplay0: screen 4 added (std, sun emulation)
recorded in 'dmesg'.
While on screen 0, Stop-F2 through Stop-F4 do apparently nothing.
Stop-F5
switches to a blank white screen with a grey cursor in the top-left
corner, presumedly screen 4. Again, Stop-F2 through Stop-F4 do apparently
nothing and Stop-F1 switches back to the terminal output on screen 0.
Just to see what would happen, I turned on the "screen 5" example in
wsconscfg: screen 4 is already configured
and the "not configured" message for all of the other screens,
including
the one I just tried to enable.
Possible clue here: Instead of screen 5 having a terminal emulation
#screen 0 - vt100
screen 1 - vt100
screen 2 - vt100
screen 3 - vt100
screen 4 - -
screen 5 - -
#screen 4 80x25bf vt100
# Note: You must uncomment the 'font ibm' line above to get a useful
# font for any 50 line screens.
#screen 5 80x50 vt100
When I restarted wscons,
wsdisplay0: screen 5 added (std, sun emulation)

Hmm, I'd suspect that the sparc GENERIC kernel is only built with Sun
terminal emulation support.
Does it work if you s/vt100/sun in wscons.conf?

have fun
Michael

[John D. Baker]

Post by Michael
Hmm, I'd suspect that the sparc GENERIC kernel is only built with Sun
terminal emulation support.
Does it work if you s/vt100/sun in wscons.conf?

Yes, that works. Perhaps the default "wscons.conf" file for sparc{,64}
systems should be set this way?

[Michael]

Hello,

On Sun, 24 Jun 2012 08:06:01 -0500 (CDT)

Post by John D. Baker

Post by Michael
Hmm, I'd suspect that the sparc GENERIC kernel is only built with Sun
terminal emulation support.
Does it work if you s/vt100/sun in wscons.conf?

Yes, that works. Perhaps the default "wscons.conf" file for sparc{,64}
systems should be set this way?

Indeed, I just wanted to make sure that's actually the problem.
Or, since sparc64's GENERIC defaults to VT100 these days, maybe sparc should follow.
have fun
Michael

[Martin Husemann]

Post by John D. Baker
Yes, that works. Perhaps the default "wscons.conf" file for sparc{,64}
systems should be set this way?

No, it all is fine on sparc64, the sparc GENERIC kernel needs to be fixed.

Martin

[Martin Husemann]

Post by Martin Husemann

Post by John D. Baker
Yes, that works. Perhaps the default "wscons.conf" file for sparc{,64}
systems should be set this way?

No, it all is fine on sparc64, the sparc GENERIC kernel needs to be fixed.

And of course src/etc/etc.sparc/ttys

Martin

[Michael]

Hello,

On Sun, 24 Jun 2012 15:46:58 +0200

Post by Martin Husemann

Post by John D. Baker
Yes, that works. Perhaps the default "wscons.conf" file for sparc{,64}
systems should be set this way?

No, it all is fine on sparc64, the sparc GENERIC kernel needs to be fixed.

Depends if anyone can come up with a reason to keep the default to WSEMUL_SUN on sparc. I can't, all my kernels use VT100, but that doesn't mean nobody can.

So, if nobody objects I'll change sparc's GENERIC, INSTALL etc. tomorrow and have it pulled into -6.

have fun
Michael

[Mouse]

Post by Michael
Depends if anyone can come up with a reason to keep the default to
WSEMUL_SUN on sparc. I can't, all my kernels use VT100, but that
doesn't mean nobody can.

How much does NetBSD care about compatability with historical practice
and/or with other OSes on the same hardware?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[Martin Husemann]

Post by Mouse

Post by Michael
Depends if anyone can come up with a reason to keep the default to
WSEMUL_SUN on sparc. I can't, all my kernels use VT100, but that
doesn't mean nobody can.

How much does NetBSD care about compatability with historical practice
and/or with other OSes on the same hardware?

A lot, in general. And emulation type "sun" will stay around, so if you
prefer it, you can use it.

However, in most cases the change is not user noticable, as long as the
term type is set correctly and everything "just works".

I bet you have some ASCII art games that only work with hardcoed
TERM=sun?

If there are serious reasons to keep using "sun" or "ss5" as the
default, I will gladly modify the installation process to install a
sparc specific wscons.conf file instead.

Martin

[Mouse]

Post by Mouse

[...] a reason to keep the default to WSEMUL_SUN on sparc. [...]

How much does NetBSD care about compatability with historical
practice and/or with other OSes on the same hardware?

A lot, in general. And emulation type "sun" will stay around, so if
you prefer it, you can use it.
However, in most cases the change is not user noticable, as long as
the term type is set correctly and everything "just works".

Well, except that vt100 isn't "set correctly", not unless you're on a
VT-100. The terminal size is wrong, there are a number of sequences it
doesn't emulate, the keyboard layout is wrong, the speed is all
wonky...that it works as often as it does is a testament to the extent
to how much software doesn't use all the capabilities of VT-100s.

I bet you have some ASCII art games that only work with hardcoed
TERM=sun?

Personally? No. I have no personal horse in this race; my personal
view is that this would be a switch from one broken emulation to
another broken emulation - I find anything without :am:bw:, or with
:xn:, broken enough for general-purpose use I tolerate it only when I
must. My own kernels include WSEMUL_MTERM and
WSEMUL_DEFAULT="\"mterm\"" - well, on wscons-capable <port,version>s,
at least.

If there are serious reasons to keep using "sun" or "ss5" [...]
However, in most cases the change is not user noticable, [...]

"Most cases". So, there are others. How much does NetBSD care about
those others?

For that matter, what would be the downside of keeping it at sun?
Going back to the start of this thread, it looks to me as though the
price is that the sparc wscons.conf differs from other ports'. To me
this does not outweigh the reasons to keep sun.

To me.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[David Brownlee]

Post by Martin Husemann

Post by Mouse

Post by Michael
Depends if anyone can come up with a reason to keep the default to
WSEMUL_SUN on sparc.  I can't, all my kernels use VT100, but that
doesn't mean nobody can.

How much does NetBSD care about compatability with historical practice
and/or with other OSes on the same hardware?

A lot, in general. And emulation type "sun" will stay around, so if you
prefer it, you can use it.
However, in most cases the change is not user noticable, as long as the
term type is set correctly and everything "just works".
I bet you have some ASCII art games that only work with hardcoed
TERM=sun?
If there are serious reasons to keep using "sun" or "ss5" as the
default, I will gladly modify the installation process to install a
sparc specific wscons.conf file instead.

Providing we do not lose the ability to enable WSEMUL_SUN then I'd
like to be counted on the side of "consistent default terminal
emulation across all platforms" :)

Though I'd much prefer it if the wscons.conf and kernel options
referred to it correctly as wsvt25 with vt100 as a compatibility
alias.

[John D. Baker]

Seeing some additional discourse on this topic, I offer my $0.02.

I'm mostly interested that things adhere to "PoLA" (Principle of Least
Astonishment). When a naive user/admin notices "Hey, NetBSD/sparc has
wscons support in GENERIC now! Let me check it out." and sets "wscons=YES"
in "/etc/rc.conf" and either starts it explictly or reboots, it should
Just Work(tm).

I'm not so concerned with exactly which terminal emulation is compiled
in or how it will be referenced in "/etc/ttys", just as long as I'm not
left wondering why it doesn't work as seamlessly as
other-port-that's-been-using-wscons-forever.

That said, I'd think it'd make the most sense to make wscons-using ports
uniform across the board. Same emulation and default terminal type.
The only difference would be the hardware-dependent geometry of the
terminal display (which presumedly it can set at initialization).

[John D. Baker]

On my sparc systems that use serial console, I've noticed an odd behavior
with netbsd-6 and -current that did not occur with 5.1_STABLE or earlier.

I added the "cs" (clear screen) capability to the default entry in
"/etc/gettytab". I turn the "console" entry off and turn the "ttya"
entry on and use "vt100" for the terminal type in "/etc/ttys". With
netbsd-6 and -current, when 'getty' clears the screen, before it prints
the "im" string, I see:

$<50>

on the top left on the terminal (I've written it indented 2 spaces above
for display purposes, but it actually appears exactly at the beginning of
the top line of the terminal display).

This occurs even on machines with custom kernel configurations that
omit/remove wscons-related options and devices. Thinking this might
be an interaction with the "sun-ss5" terminal type in the "console"
terminal (even though it's marked "off"), I changed it to "vt100"
as well. The behavior remains. I turned on "ttyb" and it prints
the extraneous string on it, too, when 'getty' clears the screen.

Without the "cs" capability, no extraneous output appears.

On the one machine with a video console (cgsix) that I've been able to
test so far, the "cs" capability causes no extraneous output.

I seem to recall seeing that same extra output on macppc video consoles
as well...