Subject: cg4 problems revisited...
To: None <port-sun3@NetBSD.ORG>
From: Scott Ellis <>
List: port-sun3
Date: 07/10/1996 18:25:02
To recap my situation...

I have a Sun 3/110 which has a cg4 onboard.  The cg4 acts as a 
color framebuffer, and also as a bw2 monochrome framebuffer.

With 1.1 installed, the system would find cg4 and configure it on bootup
like a good little machine.  Xsun from the X11r6 archives on
didn't like to run in cg4 though, giving me a "big" display (i.e.,
the 'X' cursor takes about 1/6th of the screen...looks like a VIC-20).

So..I was happy using bw2. ;-)  Sometime in the migration from 1.1
to 1.2_Beta (actually happened when it was 1.1a), the autoconfig code
broke.  On bootup, when the system got to cg4, initialized it, and was
ready to continue... I'd get an MMU fault, and get dumped to the debugger. 
Not fun.

So, I finally got some time to look into the problem.

kern/subr_autoconf.c contains a function config_search().

config_search() has two nested loops...the innermost one starting
at cf->cf_parents, and going until that is NULL.

For all cg4, this causes a problem (not sure why) in that cf_parents
isn't initialized, and is initially NULL..which leads to an MMU fault.

Wrapping that innermost loop in a "if (cf->cf_parents) {}" solved the
MMU fault problem, and cg4 now is happily detected.

Question A):  What caused cf_parents to be NULL in the first place?
The cg4 code looks nearly identical to the bw2 code..and bw2 works
fine.  I'm completely stumped here.

Question B):  Now that I get cg4 initialized..I'm getting the "big
pixels" problem again when I run Xsun on cgfour0.  Ideas?  I looked
at the sparc cg4 code, and they seem to be addressing the BT dac in a
completely different manner than the sun3 port is..but is the dac the
problem?  Where should I start looking to solve this problem?

(I'd really like color)

  //  Scott Ellis   //   //   //
// WARNING: This signature warps  time and space in its vicinity    //