[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD 5.0 and SPARCstation 5 not a lucky combination
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.
Main Index |
Thread Index |