Port-sparc archive

[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.

        Erik <fair%netbsd.org@localhost>

Home | Main Index | Thread Index | Old Index