On Sun, Mar 16, 2003 at 12:39:04PM +0000, Matt Dainty wrote:

> I've found the problem, in stic_reset():
> 
> ---8<---
> /* Second PixelStamp */
> if (yconfig > 0) {
> 	si->si_stamp[0x100b0] = config | 8;
> 	si->si_stamp[0x100b4] = 0;
> }
> ---8<---
> 
> Commenting this small block out stops the machine check, and the
> hardware appears to work okay. I've now learnt not to trust what I see
> on the monitor with the S3 switch flipped to serial. Console seems to
> work okay, and colours all appear as they should. I'm tempted to see how
> X behaves now...
> 
> Does this code error make any sense to you?

At a guess: it thinks there's a second PixelStamp chip, but there isn't.
What does dmesg say for the board? There's a server you can grab at the URL
below. To get X working you might need to tweak this line:

	yconfig = (modtype & 0x600) >> 9;

... to read like this:

	yconfig = 0;

But maybe not. Make sure your kernel has the INSECURE option set, and that
you have one of these:

pelican$ ls -l /dev/stic0
crw-------  1 root  wheel  68, 0 Apr 27  2002 /dev/stic0

http://www.interlude.eu.org/~ad/wscons/XdecNetBSD-alpha.gz

Andrew