Re: NetBSD 5.0 and SPARCstation 5 not a lucky combination

[Erik Fair <fair%netbsd.org@localhost>]

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 <fair%netbsd.org@localhost>