mac68k built-in video (PR#58164)

[David Brownlee <abs%absd.org@localhost>]

(split from the bootable mac68k thread)

On Mon, 3 Jun 2024 at 21:36, Stan Johnson <userm57%yahoo.com@localhost> wrote:

> 3) There is still an issue on the IIci with RAM-based video (RBV, i.e.
> built-in video). The issue is described in NetBSD Problem Report #58164:
> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=58164
>
> When a Toby frame buffer video card is installed and RBV is being used,
> the kernel panics as described in the problem report. If a Toby card is
> installed and is being used, then there is this different panic (seen
> only on the serial console):
>
> [   1.0000000] panic: Cannot work with the current memory mappings.
> [   1.0000000] cpu0: Begin traceback...
> [   1.0000000] ?(100000,385938,363fc4,1efca4,2c596a) at 0
> [   1.0000000] cpu0: End traceback...
> Stopped in pid 0.0 (system) at  2ea08:  unlk    a6
> db>
>
> The memory issue is related to the Nubus video card issue. It's possible
> that the problem is only seen on systems that have RBV and Nubus video,
> so the IIci and IIsi, but those are two of the most common mac68k
> systems. And there's the added complication for the IIci in being able
> to have up to 64 MiB in its Bank A. The IIsi has 1 MiB soldered-in for
> its Bank A. The most common configuration today for a IIci system that
> still works is Nubus video and 64 MiB in both Banks A and B, though both
> NetBSD and Linux will ignore all of Bank A memory if RBV is being used,
> and NetBSD 10 will crash if RBV is being used and a Nubus video card is
> installed.
>
> Nubus unaccelerated video worked on the IIci in NetBSD 8.2, and it
> stopped working sometime between 8.2 and 9.3. I don't know how to do the
> Linux equivalent of a "git bisect" in NetBSD to identify which commit
> may have triggered the regression.

Yea... cvs does not make that as easy. I'd suggest checkout
https://github.com/NetBSD/src and start from the current branch around
the time of the NetBSD-8.0 release (it will have some changes not in
-8, so you may want to go back or forward from there)

It should be sufficient to runs something like
 ./build.sh -U -m mac68k -j 22 tools kernel=GENERIC
(adjust 22 based on your spare core count and GENERIC as needed!)

You may need to make sure you have an older gcc installed to bootstrap
the build.

If you have time it would be great to track down the point of breakage.

Also the incorrect total memory reporting in 58164 is... curious, and
potentially indicative of something deeper. Would you have time to
build some test kernels to try to get more details out of that? :)

David