NetBSD 5.0 and SPARCstation 5 not a lucky combination
Bill Roman
resist trying a shiny new version. 5.0 installed and boots without
trouble, but it locks up shortly after I log in.
The lockups seem to have to do with console output that includes long
lines (not necessarily exceeding the number of columns) and an embedded
newline. Usually the long line after the newline is truncated (but its
terminating newline still scrolls), I get a shell prompt, and that's it.
No panic, no messages of any sort, no response to anything but Stop-A.
The machine is a pretty standard 170 MHz model, with a CG6 console.
Anyone have any suggestions on how to troubleshoot this?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Erik Fair
SuperSPARC-II CPU) with 8MB VSIMM (SX/cg14), and a SPARC LX (50 MHz
microSPARC-I CPU) with 1MB VSIMM (cg6); any attempt to use more(1)
makes the screen/keyboard lockup in a mode which suggests the video
mode is mismatched to the screen size, or that some piece of GPU/fb
config data is being scribbled on: I see three or four small copies of
the screen in the top half of the monitor, and the lower half is a
magnified copy of what was on the console, but garbled; there also
appear to be giant letters in the background (larger still than the
lower half text).
Fortunately, the system still runs, and you can ssh in to reboot it.
There is no further response to typing blind commands that I could
detect.
I note that wscons isn't compiled into GENERIC ... I thought that was
supported in 5.0?
I am building 5.0_STABLE optimized for supersparc/sun4m right now (for
old, slow systems, I find it's best to eke every cycle you can out of
'em), and I intend to experiment further with a SPARC Classic (cg3),
and a SunJavastation (Krups, tcx) that I have.
BTW, do we have toolchain cross-compiles working well enough that I
could reliably build an optimized (e.g. CPUFLAGS="-mcpu=supersparc -
mtune=supersparc") on, say, an i386? I have this vague memory of an
issue which made that not work ...
Erik <fa...@netbsd.org>
Andrew Smallshaw
> I had NetBSD 4.0 running on my SS5 with no trouble, but I couldn't
> resist trying a shiny new version. 5.0 installed and boots without
> trouble, but it locks up shortly after I log in.
>
> The lockups seem to have to do with console output that includes long
> lines (not necessarily exceeding the number of columns) and an embedded
> newline. Usually the long line after the newline is truncated (but its
> terminating newline still scrolls), I get a shell prompt, and that's it.
> No panic, no messages of any sort, no response to anything but Stop-A.
>
> The machine is a pretty standard 170 MHz model, with a CG6 console.
I have a very similar machine here (170MHz SS5 with CG6) and I
found I had exactly the same problem. Didn't explore it too much
because that was a machine that I _needed_ to get working, so I
stopped fussing and went back to 4.0 which I knew works perfectly.
I did notice a couple of things that may be useful though.
Firstly, just before the hang the last character output is slightly
misaligned. Not by a whole character cell - from memory the text
was a pixel or two higher than it was supposed to be. That suggests
to me that possibly address arithmetic is going slightly awry
somewhere.
The other thing I noticed was that it happens much more quickly if
the mouse is not connected. I am hesitant to state that there is
a definite relationship between the two factors but it seemed to
happen too consistently to be purely by chance. This is using a
type 4 keyboard and mouse BTW.
The only other relevant factor I can think of is the screen resolution
- mine is set to 1024x768x60. That may be relevant if it is that
addresses within the framebuffer are being miscalculated. Are you
using some other resolution Bill?
--
Andrew Smallshaw
and...@sdf.lonestar.org
der Mouse
> SuperSPARC-II CPU) with 8MB VSIMM (SX/cg14), and a SPARC LX (50 MHz
> small copies of the screen in the top half of the monitor, and the
> lower half is a magnified copy of what was on the console, but
> garbled; there also appear to be giant letters in the background
> (larger still than the lower half text).
This is what I see on the cg14 (SS20 with VSIMM) when different pieces
of the system disagree about whether the framebuffer is 8bpp or 32bpp.
The multiple small copies occur when the hardware switches from 8bpp to
32bpp; the converse produces the corrupted large copies. I've never
seen anything that produces both at once, though, and I've never seen
it on a cg6, so this may not actually be related. (I _have_ had cg6s
wedge, when software doesn't drain the command queue often enough.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Bill Roman
> I have a very similar machine here (170MHz SS5 with CG6) and I
> found I had exactly the same problem. Didn't explore it too much
> because that was a machine that I _needed_ to get working, so I
> stopped fussing and went back to 4.0 which I knew works perfectly.
> I did notice a couple of things that may be useful though.
>
> Firstly, just before the hang the last character output is slightly
> misaligned. Not by a whole character cell - from memory the text
> was a pixel or two higher than it was supposed to be. That suggests
> to me that possibly address arithmetic is going slightly awry
> somewhere.
Good eye! I think I'm seeing something similar.
I tried another experiment with a slightly more interesting text pattern
than "XXXXX...". Using a repeating "123456789.", with four lines of 60
characters, the first line is fine, the second line is garbled, and the
third and fourth lines are intact. There's a shell prompt after this,
but no more response to keyboard input.
The garble is interesting:
1234569.123456789.123456789.9.12345678*
Notice missing digits near the beginning. At "9.9.", the second "9."
and the remainder of the line look like they are displaced one pixel
down. The "*" represents a black cursor rectangle; there is another
cursor after the shell prompt.
> The other thing I noticed was that it happens much more quickly if
> the mouse is not connected. I am hesitant to state that there is
> a definite relationship between the two factors but it seemed to
> happen too consistently to be purely by chance. This is using a
> type 4 keyboard and mouse BTW.
This is so quickly reproducible for me, I haven't tried the "no mouse"
test.
> The only other relevant factor I can think of is the screen resolution
> - mine is set to 1024x768x60. That may be relevant if it is that
> addresses within the framebuffer are being miscalculated. Are you
> using some other resolution Bill?
I've left it at the default (which I think is something like
1152x864x76). I'm new to both SPARC and NetBSD, so I'm trying not to
mess with too many things at once.
Given that an extremely similar issue has been reported on another 170
MHz SS5, I'm starting to wonder if perhaps it's some sort of race
condition that's evident with the faster CPU. In another response that
seems possibly relevant:
On Sun, 2009-07-26 at 19:40 -0400, der Mouse wrote:
> I _have_ had cg6s wedge, when software doesn't drain the command queue
> often enough.
Are there any cg6 experts that would like to comment on this?
der Mouse
> I've left it at the default (which I think is something like
> 1152x864x76).
Unless you have a relatively unusual monitor connected,
1152x900xsomething. The boot-time message should say.
> Given that an extremely similar issue has been reported on another
> 170 MHz SS5, I'm starting to wonder if perhaps it's some sort of race
> condition that's evident with the faster CPU. In another response
> that seems possibly relevant:
>> I _have_ had cg6s wedge, when software doesn't drain the command
>> queue often enough.
> Are there any cg6 experts that would like to comment on this?
Actually, much of this could be explained by assuming that locking is
broken somewhere, so that the registers set up before writing a
character get stomped on by something else before the character gets
written. I'm having trouble explaining characters misplaced by less
than a character cell any other way. (Well, short of broken hardware,
which seems implausible under the circumstances.)
I don't know the cg6 enough to be sure, but I suspect that postulating
suitable stompage could also explain the wedges. (The problems I sawa
were that my aargon code - which draws directly on cg6s - would wedge
when run on certain cg6s but not others. Adding suitable drain calls,
waiting for the 0x10000000 bit to clear in the register at offset 0x10,
cured it for aargon. (I've never seen any authoritative programmer's
doco on the cg6; I don't know whether this is the correct fix or not.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Michael
Hash: SHA1
Hello,
On Jul 25, 2009, at 8:11 PM, Bill Roman wrote:
> I had NetBSD 4.0 running on my SS5 with no trouble, but I couldn't
> resist trying a shiny new version. 5.0 installed and boots without
> trouble, but it locks up shortly after I log in.
>
> The lockups seem to have to do with console output that includes long
> lines (not necessarily exceeding the number of columns) and an
> embedded
> newline. Usually the long line after the newline is truncated (but
> its
> terminating newline still scrolls), I get a shell prompt, and that's
> it.
> No panic, no messages of any sort, no response to anything but Stop-A.
>
> The machine is a pretty standard 170 MHz model, with a CG6 console.
I have a machine like that, and I have several CG6, one of them in the
SS20 - I have never seen this problem. There was a problem with the
cg6 driver a while ago which would result in kernel memory being
scribbled over during palette changes which would later on panic the
machine but that has been fixed.
Do you have a short and reliable way to reproduce this?
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm3rHcpnzkX8Yg2nAQI1Wwf9GgH1H3GPf7nyfQKdqpqNaE4aZ6BpvZqR
9EYpronlOUgpv6kOSP+DkGsu1m4didx669mms+7oP40VT0yKS4gsTcKziAgJg5Rr
v+hA76F3KjoZFQdNYxmXCsRdyEXBzieLurv8iEMKyKYPAsK07+l6lHMugaGYlI6n
NYvvtvdJugVbKtcIq7OujTGJ6rwYLa98oFKBqnGcFPJr3MOWmwPAVQFiN4j8CJkO
iPoV7liSxJUxL3M9xFO8Iv6Z/QF1st501wWbL8fRfahAN0yncYnUbAC5zVrr8HZE
DiVKRlsOX2c8fcMMbiXE9n0d7K/hpjMcfCMCVbfjQDwRsvyLexQvZQ==
=eKoL
-----END PGP SIGNATURE-----
Michael
Hash: SHA1
Hello,
On Jul 26, 2009, at 2:19 AM, Erik Fair wrote:
> I've seen some video/graphics strangeness on an SS20 (SM81 85 MHz
> SuperSPARC-II CPU) with 8MB VSIMM (SX/cg14), and a SPARC LX (50 MHz
> microSPARC-I CPU) with 1MB VSIMM (cg6); any attempt to use more(1)
> makes the screen/keyboard lockup in a mode which suggests the video
> mode is mismatched to the screen size, or that some piece of GPU/fb
> config data is being scribbled on: I see three or four small copies
> of the screen in the top half of the monitor, and the lower half is
> a magnified copy of what was on the console, but garbled; there also
> appear to be giant letters in the background (larger still than the
> lower half text).
Any way to reproduce this?
> I note that wscons isn't compiled into GENERIC ... I thought that
> was supported in 5.0?
Eh? It's supported since before 3.0 but only got enabled in 5.0. And
it should be in GENERIC.
> I am building 5.0_STABLE optimized for supersparc/sun4m right now
> (for old, slow systems, I find it's best to eke every cycle you can
> out of 'em), and I intend to experiment further with a SPARC Classic
> (cg3), and a SunJavastation (Krups, tcx) that I have.
Krups has an IGS1682, not a tcx.
> BTW, do we have toolchain cross-compiles working well enough that I
> could reliably build an optimized (e.g. CPUFLAGS="-mcpu=supersparc -
> mtune=supersparc") on, say, an i386? I have this vague memory of an
> issue which made that not work ...
This has been working for ages. COPTS="-mwhatever" is your friend.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm3sIcpnzkX8Yg2nAQKGxgf+PNzfCVTi3zuxCDTJPUa8ufVrxNBSyKLH
Mia9K2rvV7jZR3T0fbnwMNtTfKCO3DiY287OozB9QhxT7BUvMHdN8DIzoJybrswt
GvdzMFzFMD0U2VEtK8NnR8NEXKfO4mAb1/6OQ9CYePT6N7/o1h7aqI1XcNBBpb8R
9ielbmO9ZDc9XUPUX6LzBhFaHplowZuogG41n6SLf1tFV4L8S/evl/ER0dI7l71j
uikDRcA+6MpOyL2n7qiTTNCukWwvImUZ4ouQesp0aIVHhQvEqMkQLKnwzTAIN5j/
l18uVSh5ra1ljbHkYDYukHdBlcQpJ5dZmj8M7+6+4rFsJJ2cRvJFEA==
=AGQ2
-----END PGP SIGNATURE-----
Erik Fair
On Jul 27, 2009, at 11:04, Michael wrote:
> On Jul 26, 2009, at 2:19 AM, Erik Fair wrote:
>
>> I've seen some video/graphics strangeness on an SS20 (SM81 85 MHz
>> SuperSPARC-II CPU) with 8MB VSIMM (SX/cg14), and a SPARC LX (50 MHz
>> microSPARC-I CPU) with 1MB VSIMM (cg6); any attempt to use more(1)
>> makes the screen/keyboard lockup in a mode which suggests the video
>> mode is mismatched to the screen size, or that some piece of GPU/fb
>> config data is being scribbled on: I see three or four small copies
>> of the screen in the top half of the monitor, and the lower half is
>> a magnified copy of what was on the console, but garbled; there
>> also appear to be giant letters in the background (larger still
>> than the lower half text).
>
> Any way to reproduce this?
"dmesg|page" shortly after boot with /bin/csh as shell, and term=sun
on the SS20 reliably caused this lockup. Even did so with the
CPUFLAGS="-mcpu=supersparc" SS20 kernel I compiled up (removed all
that useless VME and sun4/sun4c stuff, among other things).
>> I note that wscons isn't compiled into GENERIC ... I thought that
>> was supported in 5.0?
>
> Eh? It's supported since before 3.0 but only got enabled in 5.0. And
> it should be in GENERIC.
There are no wscons configuration declarations in the NetBSD/sparc 5.0
GENERIC kernel config. If it is supported in NetBSD/sparc, it should
be in the GENERIC config, and therefore we should pull up the
necessary patches to the release branch.
Sounds like I need to modify my kernel configs to include wscons. I
had a look at the mainline CVS log for src/sys/arch/sparc/conf/GENERIC
last night, and saw the addition of wscons support last year, but
apparently it was never pulled up to the netbsd-5 release branch. I
didn't find any obvious discussion of a decision about inclusion of
sparc wscons in the release, one way or the other.
Could the lack of wscons to manage the sparc graphics devices be
triggering the kind of unserialized register setting that der Mouse
described as a possible cause of this effect?
>> I am building 5.0_STABLE optimized for supersparc/sun4m right now
>> (for old, slow systems, I find it's best to eke every cycle you can
>> out of 'em), and I intend to experiment further with a SPARC
>> Classic (cg3), and a SunJavastation (Krups, tcx) that I have.
>
> Krups has an IGS1682, not a tcx.
Apologies - you're right. I also have a Mr. Coffee JavaStation-1 that
I'll be testing which does have a tcx.
>
>> BTW, do we have toolchain cross-compiles working well enough that I
>> could reliably build an optimized (e.g. CPUFLAGS="-mcpu=supersparc -
>> mtune=supersparc") on, say, an i386? I have this vague memory of an
>> issue which made that not work ...
>
> This has been working for ages. COPTS="-mwhatever" is your friend.
CPUFLAGS="-mcpu=foo" is really what you want for this. A few releases
back (I pretty much skipped NetBSD 4.x), one had to modify an internal
mk.* variable "DBG" to get this functionality, without stomping
default optimization flags. See /usr/share/mk/bsd.README for a clearer
description of the (somewhat subtle) semantics.
Erik <fa...@netbsd.org>
Michael
Hash: SHA1
Hello,
On Jul 27, 2009, at 3:15 PM, Erik Fair wrote:
>
> On Jul 27, 2009, at 11:04, Michael wrote:
>
>> On Jul 26, 2009, at 2:19 AM, Erik Fair wrote:
>>
>>> I've seen some video/graphics strangeness on an SS20 (SM81 85 MHz
>>> SuperSPARC-II CPU) with 8MB VSIMM (SX/cg14), and a SPARC LX (50
>>> MHz microSPARC-I CPU) with 1MB VSIMM (cg6); any attempt to use
>>> more(1) makes the screen/keyboard lockup in a mode which suggests
>>> the video mode is mismatched to the screen size, or that some
>>> piece of GPU/fb config data is being scribbled on: I see three or
>>> four small copies of the screen in the top half of the monitor,
>>> and the lower half is a magnified copy of what was on the console,
>>> but garbled; there also appear to be giant letters in the
>>> background (larger still than the lower half text).
>>
>> Any way to reproduce this?
>
> "dmesg|page" shortly after boot with /bin/csh as shell, and term=sun
> on the SS20 reliably caused this lockup. Even did so with the
> CPUFLAGS="-mcpu=supersparc" SS20 kernel I compiled up (removed all
> that useless VME and sun4/sun4c stuff, among other things).
Alright, I'll try that.
> I note that wscons isn't compiled into GENERIC ... I thought that
> was supported in 5.0?
>>
>> Eh? It's supported since before 3.0 but only got enabled in 5.0.
>> And it should be in GENERIC.
>
> There are no wscons configuration declarations in the NetBSD/sparc
> 5.0 GENERIC kernel config. If it is supported in NetBSD/sparc, it
> should be in the GENERIC config, and therefore we should pull up the
> necessary patches to the release branch.
I'm sure I requested the pullup - need to check that.
> Sounds like I need to modify my kernel configs to include wscons. I
> had a look at the mainline CVS log for src/sys/arch/sparc/conf/
> GENERIC last night, and saw the addition of wscons support last
> year, but apparently it was never pulled up to the netbsd-5 release
> branch. I didn't find any obvious discussion of a decision about
> inclusion of sparc wscons in the release, one way or the other.
Hmm, I remember one, although a rather short one.
> Could the lack of wscons to manage the sparc graphics devices be
> triggering the kind of unserialized register setting that der Mouse
> described as a possible cause of this effect?
Maybe, but I don't know the old rcons code very well and never used it
myself.
>>> I am building 5.0_STABLE optimized for supersparc/sun4m right now
>>> (for old, slow systems, I find it's best to eke every cycle you
>>> can out of 'em), and I intend to experiment further with a SPARC
>>> Classic (cg3), and a SunJavastation (Krups, tcx) that I have.
>>
>> Krups has an IGS1682, not a tcx.
>
> Apologies - you're right. I also have a Mr. Coffee JavaStation-1
> that I'll be testing which does have a tcx.
We don't have a wsdisplay driver for the tcx, mosly because I don't
have the hardware. IIRC it's more or less an 8bit only S24, someone
promised to send me one but never actually did it :/
>>> BTW, do we have toolchain cross-compiles working well enough that
>>> I could reliably build an optimized (e.g. CPUFLAGS="-
>>> mcpu=supersparc -mtune=supersparc") on, say, an i386? I have this
>>> vague memory of an issue which made that not work ...
>>
>> This has been working for ages. COPTS="-mwhatever" is your friend.
>
> CPUFLAGS="-mcpu=foo" is really what you want for this. A few
> releases back (I pretty much skipped NetBSD 4.x), one had to modify
> an internal mk.* variable "DBG" to get this functionality, without
> stomping default optimization flags. See /usr/share/mk/bsd.README
> for a clearer description of the (somewhat subtle) semantics.
One's passed to the tools build, the other to the actual build. CFLAGS
is passed to both IIRC and that causes trouble.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm4CsMpnzkX8Yg2nAQKX2gf/SmM93Z5s099AeeIirdjTGXX32B5ykbe+
OGreYLRgGBD8xQHejBvqJVeAO0mwFO5D1+d0RQtpbfVGLpitldWH2EScM9cKJhfb
JLhBIMuov9kcMcC8aohXR+vOR8/E54klegSocW9/s5FPWuPklGBXIdM0Lz501Xlu
2Qqu2gm66UY2W3OwOf9TTDB8PwmyjVBMj2tYz2QooCYRVibn8W5l7tSZ/NJ15fVw
xq8XF/L90hXbvfWc6m8uuMBmGHuib993TirYgTB6BOu+MRhOCs12IoNPg6/YnNEB
iXPknC5BW344Wq5Ikdajm5lWWyH2hQrXMzRJeM0reE5hi+PkFJJSnw==
=80bq
-----END PGP SIGNATURE-----
der Mouse
> triggering the kind of unserialized register setting that der Mouse
> described as a possible cause of this effect?
Not directly, because that means that the kernel isn't scribbling on
the framebuffer to draw console text; rather, it's punting to the PROM
output routines. At least, unless RASTERCONSOLE still exists and
you're using it.
However, I don't know how much the PROM output routines expect to own
the machine when they're entered. If they expect to be entered with
interrupts disabled but aren't, that might account for it.
...hmm, that, actually, could explain the cross-platform nature of
this, how it's being observed across multiple machines (LX, SS5, SS20)
and even multiple framebuffer architectures (cg6, cg14). Maybe try
wscons (or RASTERCONSOLE, if that still exists) and see if it makes any
difference.
While it's strictly armchair quarterbacking at this point, my
front-runner theory is now incorrect locking, or broken disabling of
interrupts, or some such, when calling out to the PROM routines for
console output.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Michael
Hash: SHA1
Hello,
Hmm, I have seen what you describe on other graphics chips when
characters are drawn by software but scrolling etc. is done by
hardware and the software drawing routines either don't wait only
enough for the blitter to finish whatever it's doing before scribbling
into video memory or if whatever they scribbled doesn't completely
make it into video memory before the next blitter command is issued
( when vram is mapped cacheable for example, but that shouldn't happen
on sparc - sbus space should always be mapped uncached ). The CG6
driver however should do everything through the blitter, including
drawing characters and the cursor.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm3uY8pnzkX8Yg2nAQJwBwf/Y4aZNuTUQuhc12R8yb0Ci4ojZqh8Au0/
2xg64BiuJ71dDhn6bE+z5BmTkRRCnfe5+heQ/MF9aDZII1jwPtSnYZojUa6FM2H9
zp+GvSdtfu40ZBLD+1b69EbyhL4pdMuODO2JB9YIqRxmQk0SKh0knWqLO6JZhYSX
+J8ajJHwVvrnFHksGnKyh2SJShn3s/tjo/oO+8nIRNDiOTpFunvJPaEuD9yzxdFg
xS6dVnixmpYffnLoOXS7PUbcckmt3X71MH5Z3W7xV8zg3ndzXG8N5vuFSa8PM0Wa
WlGprDG5Fr0m7eu8k65FuniCLnUAwvmgxLGrltlJOLqORXE5SSv5zw==
=PKrh
-----END PGP SIGNATURE-----
Erik Fair
On Jul 27, 2009, at 12:55, der Mouse wrote:
>> Could the lack of wscons to manage the sparc graphics devices be
>> triggering the kind of unserialized register setting that der Mouse
>> described as a possible cause of this effect?
>
> Not directly, because that means that the kernel isn't scribbling on
> the framebuffer to draw console text; rather, it's punting to the PROM
> output routines. At least, unless RASTERCONSOLE still exists and
> you're using it.
RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.
Perhaps the next step is shutting that off, and seeing if the problem
persists.
Erik <fa...@clock.org>
der Mouse
>>> triggering the kind of unserialized register setting that der Mouse
>>> described as a possible cause of this effect?
>> the framebuffer to draw console text; rather, it's punting to the
>> PROM output routines. At least, unless RASTERCONSOLE still exists
>> and you're using it.
> RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.
Oh, that makes it more interesting. Then the console _is_ talking
directly to the framebuffer.
_Lack of_ wscons is unlikely to cause problems, it seems to me. wscons
combined with RASTERCONSOLE, I don't know what that would do; I haven't
looked at sparc wscons at all. I wonder if the other observed cases
were all using RASTERCONSOLE? If it's on by default, quite likely so;
perhaps that's where the bug is.
> Perhaps the next step is shutting that off, and seeing if the problem
> persists.
That would be an interesting datapoint. With no wscons and no
REASTERCONSOLE, console display _should_ go through the PROM callbacks,
AIUI; if _that_ misbehaves, it's probably what someone suggested about
scrolling or other copies going on, though I have trouble imagining
what would be doing it - something would have to be drawing on the
framebuffer, which shouldn't be happening with just text-console I/O
going on.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
matthew green
RASTERCONSOLE and wscons don't go together afaik.
wscons uses "rasops".
.mrg.
Bill Roman
> On Jul 25, 2009, at 8:11 PM, Bill Roman wrote:
> Do you have a short and reliable way to reproduce this?
I've been doing more or less:
foo=123456789.123456789.123456789.123456789.123456789.123456789.
echo -e "$foo\n$foo\n$foo\n$foo\n"
Bill Roman
> On Jul 27, 2009, at 12:55, der Mouse wrote:
>
> >> triggering the kind of unserialized register setting that der Mouse
> >> described as a possible cause of this effect?
> >
> > the framebuffer to draw console text; rather, it's punting to the PROM
> > output routines. At least, unless RASTERCONSOLE still exists and
> > you're using it.
>
> RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.
> Perhaps the next step is shutting that off, and seeing if the problem
> persists.
As I said, I'm new to NetBSD, so... can I use 4.0 to build a kernel for
the 5.0 installation, with a different config? I'm not sure 5.0 will
stay up long enough to build a kernel.
I don't mind experimenting, the SS5 is one of my toys for learning
NetBSD, and this promises to be a great learning experience.
der Mouse
>> Perhaps the next step is shutting that off, and seeing if the
>> problem persists.
> for the 5.0 installation, with a different config?
I think this is supposed to work, but I haven't tried it myself, so I
don't actually know. You might be able to just use 4.x to build the
5.x config and then compile with the 4.x compiler, but that's the risky
way. While I also need to qualify it with the remark that I neither
like nor really understand the `new' build mechanisms, I think build.sh
is supposed to work to cross-build kernels if you put all the pieces in
the right places. (I don't cross-build unless I can't help it, and so
far I've been able to avoid it, so I don't know how well that support
works.) Reading BUILDING and build.sh should at least get you moving
in the right direction; I've been told there are also some webpages
that may help, though I haven't looked with that in mind myself.
"Cross-build" here includes cross-version as well as
cross-architecture; as I understand it, all builds are handled as cross
builds, even if the host and target arch and/or OS are the same.
> I'm not sure 5.0 will stay up long enough to build a kernel.
You might consider running with serial console. That should sidestep
the whole writing-to-the-framebuffer question and give you a stable
machine, albeit one without a graphics head. (Well, at least, stable
unless other bugs start causing trouble; while not impossible, it seems
unlikely to me that the bug behind this problem would disrupt operation
when using serial console.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Michael
Hash: SHA1
Hello,
On Jul 27, 2009, at 9:18 PM, der Mouse wrote:
>>>> Could the lack of wscons to manage the sparc graphics devices be
>>>> triggering the kind of unserialized register setting that der Mouse
>>>> described as a possible cause of this effect?
>>> Not directly, because that means that the kernel isn't scribbling on
>>> the framebuffer to draw console text; rather, it's punting to the
>>> PROM output routines. At least, unless RASTERCONSOLE still exists
>>> and you're using it.
>> RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.
>
> Oh, that makes it more interesting. Then the console _is_ talking
> directly to the framebuffer.
>
> _Lack of_ wscons is unlikely to cause problems, it seems to me.
The acceleration code is slightly different.
> wscons combined with RASTERCONSOLE, I don't know what that would do;
It would #error out
> I haven't looked at sparc wscons at all. I wonder if the other
> observed cases
> were all using RASTERCONSOLE? If it's on by default, quite likely so;
> perhaps that's where the bug is.
Probably, I dimly remember that the old rcons code draws at least the
cursor and maybe all text by software and uses the blitter only for
scrolling and rectangle fills.
>> Perhaps the next step is shutting that off, and seeing if the problem
>> persists.
>
> That would be an interesting datapoint. With no wscons and no
> REASTERCONSOLE, console display _should_ go through the PROM
> callbacks,
> AIUI; if _that_ misbehaves, it's probably what someone suggested about
> scrolling or other copies going on, though I have trouble imagining
> what would be doing it - something would have to be drawing on the
> framebuffer, which shouldn't be happening with just text-console I/O
> going on.
I'm pretty sure the PROM drawing routines for the cg6 use the blitter
for at least a few things.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm56/spnzkX8Yg2nAQKWkwgAndx1xG0ajELbmzFeciWmB8JpQpDWg2xr
/oTeqGYJnfJtGaqZKE21JPnl8oAEKJ27sRUCQ2Y9knzbX02TxPL02W1ELZOsBtHN
F2XDkCTt/T8cmq2/RC0TGHxz1vXrn81DjpU0a282ZibOnUz9kXn+QDULs6U4KJB3
dkrF+LSOmtsQcWmxL7N8iGr/u9XoDoCzep6J7c7a7cKpeU73hVQ1rsIDOYL55hNd
mS+AKBfXwESHA6DOQIoJTL5ONYZTfBRpO2AKEmtzv0my1XaGEynWJmnJj0/m13hJ
z3Qg4RzREKI3ZpLtMeec8IkvpwSqWgHkNWbq+JJ/90lN1VEl9Hk5xg==
=A0S4
-----END PGP SIGNATURE-----
der Mouse
> and maybe all text by software and uses the blitter only for
> scrolling and rectangle fills.
Depends. Looking at the 3.1 code, I see CG6_BLIT_CURSOR, which if
turned on seems to do the cursor with the blitter.
As I recall, most of the usability gain from cg6 acceleration came from
scrolling. There is some font-draw support in the hardware, but I
suspect it's not that much faster than software font-draw.
>>> Perhaps the next step is shutting [RASTERCONSOLE] off, and seeing
>>> if the problem persists.
>> That would be an interesting datapoint. With no wscons and no
>> REASTERCONSOLE, console display _should_ go through the PROM
>> callbacks, AIUI; [...]
> I'm pretty sure the PROM drawing routines for the cg6 use the blitter
> for at least a few things.
Yes. Scrolls, at the very least; it scrolls too fast to be anything
else. However, don't callouts to the ROM code run with a bunch of
stuff disabled? That should help some....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Erik Fair
recompiling a kernel appears to make the graphics console hard hang go
away on both the SS20 (cg14/SX) and the LX (cg6/TGX) that I have tested.
The SS20 seems entirely fine, in as much as my easy "dmesg|page" was
unable to duplicate the problem, but I did not exercise it much
further. dmesg(8) reports:
cgfourteen0 at obio0 slot 2 offset 0x0 level 8: 8 MB VRAM: cgeight
emulated at 1152x900x24bppcgfourteen0: attached to /dev/fb0
Perhaps a missing "\n" in the driver?
The LX also works, but has some odd problems in its terminal emulation
still; in particular, when vi(1) quits and attempts to reset the
screen with what appears to be a reverse scroll (?), the monitor
window gets covered in a series of black 1" long horizontal
rectangles. However, running clear(1) makes them go away and the
keyboard/console does not hang. dmesg(8) reports:
cgsix0 at sbus0 slot 3 offset 0x0 level 9: SUNW,501-1672, 1152 x 900,
rev 8 (console)
cgsix0: attached to /dev/fb0
cgsix0: framebuffer size: 2 MB
cgsix0: FBC: 00229540
Both systems are attached to Sun GDM-17E10 (Sony) 17" CRT monitors.
Next step for me: wscons testing.
Erik <fa...@netbsd.org>
Izumi Tsutsui
> unable to duplicate the problem, but I did not exercise it much
> further. dmesg(8) reports:
The similar hang also happens on SS20 with ZX (leo).
It might be framebuffer independent, but problem around
PROM console vs RASTERCONSOLE/rasops?
---
Izumi Tsutsui
Michael
Hash: SHA1
Hello,
On Jul 28, 2009, at 1:01 AM, der Mouse wrote:
>> I dimly remember that the old rcons code draws at least the cursor
>> and maybe all text by software and uses the blitter only for
>> scrolling and rectangle fills.
>
> Depends. Looking at the 3.1 code, I see CG6_BLIT_CURSOR, which if
> turned on seems to do the cursor with the blitter.
I added that option years ago when I found out that it locked up one
of my CG6. For some reason the same code works fine with wscons.
> As I recall, most of the usability gain from cg6 acceleration came
> from
> scrolling. There is some font-draw support in the hardware, but I
> suspect it's not that much faster than software font-draw.
It's several orders of magnitude faster ( I implemented it for
NetBSD's own xf86-video-suncg6, it beats the pants off most
contemporary and many newer chips. x11perf -ftext yields more than
400000 characters per second on a TGX )
But as you said, scrolling is by far the most noticeable acceleration
feature in the kernel driver.
When using the blitter for all operations we can queue up character
drawing too instead of having to wait for the blitter to finish which
is the main reason why I added it to most of my drivers. Less CPU time
spent spinning.
>>>> Perhaps the next step is shutting [RASTERCONSOLE] off, and seeing
>>>> if the problem persists.
>>> That would be an interesting datapoint. With no wscons and no
>>> REASTERCONSOLE, console display _should_ go through the PROM
>>> callbacks, AIUI; [...]
>> I'm pretty sure the PROM drawing routines for the cg6 use the blitter
>> for at least a few things.
>
> Yes. Scrolls, at the very least; it scrolls too fast to be anything
> else.
Exactly what I thought - see a cg14 for comparison, then add sbus's
lower bandwidth...
> However, don't callouts to the ROM code run with a bunch of stuff
> disabled? That should help some....
I think we disable at least interrupts when calling the PROM.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSm9EVcpnzkX8Yg2nAQKhiQf/Zk3Fhvw6sP0VPHqxci/kavixdIU0qOmM
WP4ryomML07XZTBeWhtoOkEaRRJDwUtoIdKjeTogx9K5luBOEPJEGtuMuOxppHex
Ci7cbhBgwKeg4NO/4Ft4NOjxehfBYY8r0iWdyk+BPo1g/4In/kSpwY/mnojR1GLi
3DmP9/q1n4nb76z7zcNoBw6MYkOdy658AEFBZeJtoFBhHkclL3h98DLyww6NFmc/
YK72vPI4q1wqDjesTeOMZsHGqkAO2kAJ8H/Lk6eghKd1+U73RitH7LvBuzWwZbys
IDAFRMbMVqv+MVksYCeqwCf4LqBtsBZTjfN+mw0zdzJbA0nz+wGraQ==
=y+iK
-----END PGP SIGNATURE-----
Erik Fair
SS20 kernel configs (copied from -current GENERIC), wscons appears to
work in NetBSD/sparc 5.0 for both cg6 and cg14, and doesn't hang.
Also, as expected, the cg6 text scrolling is a whole lot faster than
PROM/OF calls (RASTERCONSOLE also provides this benefit for cg6, but
there has apparently been a regression wherein it hangs).
There are artifacts when control of the graphics device passes from
PROM/OF to kernel driver (and back again), e.g. clearing the screen,
text area resize, but I don't believe any of them are sufficiently
serious to warrant holding back on turning on wscons support by default.
So, I'd like to see the wscons kernel configuration in -current
GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster, can
you please do the honors and make the necessary requests of our
release engineering team?
Michael
Hash: SHA1
Hello,
On Jul 29, 2009, at 3:46 PM, Erik Fair wrote:
> So, I'd like to see the wscons kernel configuration in -current
> GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster,
> can you please do the honors and make the necessary requests of our
> release engineering team?
Not sure that makes all that much sense - we need a few more changes
for that ( mostly in /etc/ttys and such ) and 5.1 will be branched
pretty soon - since it's going to branch from -current it will just
inherit wscons.
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSnEQYcpnzkX8Yg2nAQISlQf+KPrj3obog0cHd162N51zaiQD6o9/wRyY
kqsd/4qXsU6O4z1N+MpMZrPd4o3X3zDGU9N3Kycbu2CIqqnvV/I9EvzV0bZXJnKl
U8HtA85bdibR/pDfiVVkffVIoGZhmnGzCkYVgRYmeTEFYio1wK74k1QnbH/MFwcI
PSO1szV3xYk+/pbMZGB5U+vHmC4KR2WPLi0y2aj9wDuO2nz5argcqrDgG12nb44O
4oQUjYHp/2oWKG+ZQAQINVT+n9hoZy8FjZ4a65SEowOpFtfXesF9vhxybCw3YNaN
ql88VZwppemDOahbKlwUa+yD1K9N5cbJ5ksoceeNN1GUbqOXj0106w==
=X32v
-----END PGP SIGNATURE-----
matthew green
> So, I'd like to see the wscons kernel configuration in -current
> GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster,
> can you please do the honors and make the necessary requests of our
> release engineering team?
Not sure that makes all that much sense - we need a few more changes
for that ( mostly in /etc/ttys and such ) and 5.1 will be branched
pretty soon - since it's going to branch from -current it will just
inherit wscons.
i think you may have misunderstood something i said.
netbsd 5.1 'src' will come from netbsd-5 branch. so, pullups
need to happen for the kernel.
we do want to re-branch 'xsrc' for netbsd 5.1, if we can get it
into a state we're happy with, but this is still not a known
quanitity.
.mrg.
Michael
Hash: SHA1
Hello,
On Jul 30, 2009, at 12:19 AM, matthew green wrote:
>
>> So, I'd like to see the wscons kernel configuration in -current
>> GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster,
>> can you please do the honors and make the necessary requests of our
>> release engineering team?
>
> Not sure that makes all that much sense - we need a few more changes
> for that ( mostly in /etc/ttys and such ) and 5.1 will be branched
> pretty soon - since it's going to branch from -current it will just
> inherit wscons.
>
>
> i think you may have misunderstood something i said.
Sounds like I did.
> netbsd 5.1 'src' will come from netbsd-5 branch. so, pullups
> need to happen for the kernel.
Alright, I'll dig up the relevant commits then.
> we do want to re-branch 'xsrc' for netbsd 5.1, if we can get it
> into a state we're happy with, but this is still not a known
> quanitity.
Indeed, a lot is still untested at best :/
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSnEhIspnzkX8Yg2nAQIdWwf/T4GvcytnDv7ip0kte5rk802qLpXbeUzg
AFcqzDeAgxorFI4LfU/cPSyiT1aajynutBJGFiuTDRFi49qk6uSfpPCbm08GFRTa
oaw4dUgPjPMzKUlVOhwnbzXhzkUCATVtzTLnZgFTj1q450E6SL+/rXadEl3pRuaf
E6ZoTk40bZKmLZ4iVQirEGkFagzLJvmkEccBic7pDl2wP+SBsENZhQYwbpq+ZeMf
Y15iy4yqr7zqvAVuAW5aNV5gc9UPPxWeux1UwdGbdIcPfdkBNxuuH8dCJ7PdVIKb
eV2WY1PEb6H3zpjQXXO4YT7OYLCxFe30UPoOHGXSjv/H3vkkgzHKZA==
=rxHe
-----END PGP SIGNATURE-----
Jon Buller
> On Jul 29, 2009, at 3:46 PM, Erik Fair wrote:
>
>> GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster,
>> can you please do the honors and make the necessary requests of our
>> release engineering team?
>
> for that ( mostly in /etc/ttys and such ) and 5.1 will be branched
> pretty soon - since it's going to branch from -current it will just
> inherit wscons.
Since when is a minor release branched off -current instead of the major
release it is following?
And while on the subject of problems with the console, I saw this
problem on my SS20s with either a cg6 or a cg14, and on my LX. But
before I got that far I had to install a 4.0 system and upgrade it to 5
to see the wscons/video problem, as I couldn't get 5 on the machine any
other way.
It seems that 5_rc or -current from that time has some real difficulty with
starting up something. It appeared the either /dev/kbd disappeared when
login finished, or login was unable to pass open file descriptors for
stdin and stdout to the shell it forked.
The only suggestion I got at the time was "It works for me on a serial
console"... It may or not be related, but while you are testing new
kernels, you might want to try that. As I remember, the install kernel
would get to the spot where it asks if you want to install, upgrade, get
a shell, or reboot. It would accept the answer, print out the next bit
and then give you the shaft at the next request for input.
Jon
Michael
Hash: SHA1
Hello,
On Jul 29, 2009, at 11:44 PM, Jon Buller wrote:
> Michael wrote:
>> On Jul 29, 2009, at 3:46 PM, Erik Fair wrote:
>>> So, I'd like to see the wscons kernel configuration in -current
>>> GENERIC pulled up to the netbsd-5 release branch. Mr. Portmaster,
>>> can you please do the honors and make the necessary requests of our
>>> release engineering team?
>> Not sure that makes all that much sense - we need a few more
>> changes for that ( mostly in /etc/ttys and such ) and 5.1 will be
>> branched pretty soon - since it's going to branch from -current it
>> will just inherit wscons.
>
> Since when is a minor release branched off -current instead of the
> major
> release it is following?
ESMOKEDCRACK
> And while on the subject of problems with the console, I saw this
> problem on my SS20s with either a cg6 or a cg14, and on my LX. But
> before I got that far I had to install a 4.0 system and upgrade it
> to 5
> to see the wscons/video problem, as I couldn't get 5 on the machine
> any
> other way.
Hrm, I never saw it on any of my hardware but it's all running wscons
which was kind of the point of getting it in the first place.
> It seems that 5_rc or -current from that time has some real
> difficulty with
> starting up something. It appeared the either /dev/kbd disappeared
> when
> login finished, or login was unable to pass open file descriptors for
> stdin and stdout to the shell it forked.
Any chance to check if this still happens with a wscons kernel?
have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBSnEs/cpnzkX8Yg2nAQKkuQgAthhqSPqKroDoJDLxZLnR27PuLeU610rI
S788s/knMPrXUe7zc974DOJOTuF0MELIOBWs5bmok/oQWdmnD3lcJ9khPvsT8YI+
+Rl98U3U2KraYQAhM94wz9F2EcVmwzpKqVNeIZfUjya15Gpe+gXABqZn9Vt9xwHz
Al4sv8wx6Fb6PSYPUVA0j0VclXkmgCqOHu5EFZAQ1Nln/FxVPEbzyq7usypr4N7F
yx2hdGhAbVzlY9VceH42xm3DWVEBqNNcU0UeS8uIe3jrwvn7pQmhrBKf5N8DRLjl
iDsbYJbIJQAEquO4CaFuB36QF+8X5KwTQc6BNsbQ8vfWErUoX6JO6Q==
=Aeng
-----END PGP SIGNATURE-----
Jon Buller
> On Jul 29, 2009, at 11:44 PM, Jon Buller wrote:
>> And while on the subject of problems with the console, I saw this
>> problem on my SS20s with either a cg6 or a cg14, and on my LX. But
>> before I got that far I had to install a 4.0 system and upgrade it
>> to 5 to see the wscons/video problem, as I couldn't get 5 on the
>> machine any other way.
>
> Hrm, I never saw it on any of my hardware but it's all running wscons
> which was kind of the point of getting it in the first place.
>
>> It seems that 5_rc or -current from that time has some real
>> difficulty with starting up something. It appeared the either
>> /dev/kbd disappeared when login finished, or login was unable to
>> pass open file descriptors for stdin and stdout to the shell it
>> forked.
>
> Any chance to check if this still happens with a wscons kernel?
Just checked. I did a cvs update this morning, and did a full
-current/sparc release build. The miniroot.fs it generated seems to
be working fine. Not that I did a full install with it, but I was
going through all the menus until I got to the parts that wrote
something out. It's light-years ahead of the previous attempt with
5.0 or one of the later 5_RC builds.
Please get this pulled up ASAP, or we should update the install notes
to tell everyone not using a serial console how to custom build their
NetBSD-5/sparc install tools and kernels. :)
Thanks,
Jon
Bill Roman
> On Jul 27, 2009, at 9:18 PM, der Mouse wrote:
>
> >>>> triggering the kind of unserialized register setting that der Mouse
> >>>> described as a possible cause of this effect?
> >>> the framebuffer to draw console text; rather, it's punting to the
> >>> PROM output routines. At least, unless RASTERCONSOLE still exists
> >>> and you're using it.
> >> RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.
> >
> > Oh, that makes it more interesting. Then the console _is_ talking
> > directly to the framebuffer.
> >
> > _Lack of_ wscons is unlikely to cause problems, it seems to me.
>
> The acceleration code is slightly different.
>
> > wscons combined with RASTERCONSOLE, I don't know what that would do;
>
> It would #error out
>
> > I haven't looked at sparc wscons at all. I wonder if the other
> > observed cases
> > were all using RASTERCONSOLE? If it's on by default, quite likely so;
> > perhaps that's where the bug is.
>
> Probably, I dimly remember that the old rcons code draws at least the
> cursor and maybe all text by software and uses the blitter only for
> scrolling and rectangle fills.
Whew! The last few days it's been too hot to even think about powering
up a SPARCstation in the house.
Now that it's cooled off a little, I've enabled ssh (to avoid console
problems) and built a kernel with wscons enabled (and a lot of stuff not
applicable to the SS5 disabled). It seems to work just fine, no
problems with scrolling.
So, there's something different about what wscons and RASTERCONSOLE do
to a cg6. That should at least give a clue... maybe I'll meditate on
the relevant source when it cools off again this evening. But I bet
someone who knows more about this might have suggestions exactly where
to look, and where to find relevant information.
Erik Fair
On Jul 27, 2009, at 12:40, Michael wrote:
> We don't have a wsdisplay driver for the tcx, mosly because I don't have the hardware. IIRC it's more or less an 8bit only S24, someone promised to send me one but never actually did it :/
Is this still the case? If so, I can send you one. (it's amazing what you find when you actually inventory your old computers ...)
matthew green
> > We don't have a wsdisplay driver for the tcx, mosly because I don't
> > have the hardware. IIRC it's more or less an 8bit only S24, someone
> > promised to send me one but never actually did it :/
>
> Is this still the case? If so, I can send you one. (it's amazing what
> you find when you actually inventory your old computers ...)
fortunately, this happened shortly afterwards:
revision 1.32
date: 2009/08/06 18:26:03; author: macallan; state: Exp; lines: +535 -117
make the tcx driver do something useful:
- attach a wsdisplay
- make it work with an S24
- accelerate scrolling and character drawing
This isn't quite finished yet, it works fine as a console but most things
X will need are not functional right now.
... and 10 or so more revisions :)
.mrg.
Erik E. Fair
playing with the "netbsd-5" release branch on ... so, no full
wscons, or did those changes not get pulled up to the release
branch?
Erik <fa...@netbsd.org>
Michael
On Jul 27, 2009, at 12:40, Michael wrote:We don't have a wsdisplay driver for the tcx, mosly because I don't have the hardware. IIRC it's more or less an 8bit only S24, someone promised to send me one but never actually did it :/
Is this still the case? If so, I can send you one. (it's amazing what you find when you actually inventory your old computers ...)
matthew green
> I ask because I'm not seeing the result on an SS5-like box I'm
> playing with the "netbsd-5" release branch on ... so, no full
> wscons, or did those changes not get pulled up to the release
> branch?
not on the release branch. bring on 6.0! :-)