On 986571659 seconds since the Beginning of the UNIX epoch
Simon Burge wrote:
>

>>  >panic: tga_console(12, 0): unknown board configuration
>>  >Stopped at 0xfffffc0000537fc4: ret zero,(ra)
>> 
>> Is there any chance to fix this for 1.5.1?
>
>I've seen this crop up every now any then on this list.  Is it used as a
>console device on 1.4.3?  Maybe we can just hack tgamatch() to fail for
>this particular product/rev combination?

This is my bad.  The PowerStorm 4d20 has the same product/vendor
IDs as the 3d30, which now has X support.  I accidentally broke
the 4d20 in the process.  Unfortunately, I have been separated from
my alpha hardware for quite a long time now and that has sort of
stymied my plans to fix this.

There is a short term work-around:

	configure a kernel without TGA support.  This will work
	exactly as 1.4.3 does.  (I realise that this is a bit of
	a kludge.)

I will be getting my alpha in about two weeks, and I'll be able to
do something about it then -- which will include actual X support
on the card as well, perhaps with an acceleration or two.

I'll work on a short term fix to get the card to successfully fail
to be recognised, but I won't be abl;e to test it until then.  I'll
put a quick discussion of the relevant code:

In src/sys/arch/alpha/pci/pci_machdep.c you see (line 93):

#if NTGA
	nmatch = DEVICE_IS_TGA(class, id);
	if (nmatch > match) {
		match = nmatch;
		fn = tga_cnattach;
	}
#endif

The thing here is that DEVICE_IS_TGA is a macro that simply evaluates the
vendor id and product id.  The PowerStorm 3d30 and 4d20 have the same of
those -- so this macro is going to expand the same way for both.

Then on line 101:

	if (fn != NULL)
		(*fn)(iot, memt, pc, bus, device, function);
	else
		panic("pci_display_console: unconfigured device at %d/%d/%d",
		    bus, device, function);
}

It calls _one_ of the functions.  In this case tga_cnattach().
tga_cnattach() panics on an failure, which for my purposes is
suboptimal.  So, what we need here is a more expressive mechanism
to determine if we recognise the card as a TGA.

So, either I'll make DEVICE_IS_TGA() success cause a probe of the
Deep register to determine how much video ram is available and fail
to match in the 4d20 case, or I'll fix tga_cnattach to be able to
fail without panicking and pci_machdep.c to accept that means that
it can fall back to VGA (if it got a match for it.)

Comments?

Anyway, as I said, I'll have my alphas and cards here on the 30th
and at that point I'll be able to get something working for this
in the short term (i.e.:  4d20 will be recognised as VGA) and in
the slightly longer term the 4d20 will be a frame buffer device
like the 3d30.  :-)

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==