More information on my multiple-monitor woes...

earlier, I wrote:
> - Having Mode32 installed and 32-bit mode turned on seems to cause an
> infinite loop of "Panic:  kernel jump to zero" messages when booting.
> Booting in 24-bit mode works fine, though.  (This could be a conflict
> with something else, but after turning off Mode32 fixed the problem I
> didn't pursue it any further.)

This turned out to be something else.  Mode32 wasn't causing the
problem.  In fact, I had to boot from 32-bit mode to get the RasterOps
264 card to work as the main screen.  It _does_ work, though.

However, when I boot on internal video and run dt, it gets about 2/3 of
the way through clearing the screen on the RasterOps card, and core
dumps with a signal 11 (seg fault?) in grf_blankscreen at address
0x1004b000.  (That's what a post-mortem on the core file says, anyway.
Gdb has been lying like a dog lately. :-P )

Another interesting point:  I've only looked at it briefly, but it
appears that when dt clears the screen or scrolls, it does more than it
needs to.  Sometimes MUCH more.  On the RasterOps card, each scanline
takes up 80 bytes in 1-bit color mode.  Rowbytes is fixed at 0x400
(1024).  If I'm reading the code right, the screen-clearing and
scrolling code looks at rowbytes but ignores the width of the screen,
and thus often ends up moving 12 times (!) as much data as it needs
to.  (This would be much less severe on other cards, but would still
slow things down a bit.)

I just finished compiling a version of dt that specifically ignores
/dev/grf0 (the RasterOps card), and it works.  That should make the
machine usable while I try and figure out the problem with the card.

[time passes...]

IF the source on ftp.netbsd.org is really current, then I think I've
found a kernel bug.

Stop.  Read that again.  I don't know if the source I looked at is even
in the current kernel.  However, if it is:

in /src/sys/arch/mac68k/dev/grf.c (I think I got that right...),

in the function macvideo_init():
...
	gi->gd_fbsize=image->right*image->bottom;
...

Ahem.  That should be:
	gi->gd_fbsize=image->rowbytes*image->bottom

As long as fbwidth > rowbytes (as could easily be the case in 1-bit
mode), you'll never catch this one.  Unfortunately, that's not the case
for my card.  When erasing the screen, dt segfaults precisely 0x4b000
bytes into the framebuffer.  (The really sharp people reading this will
notice that 640x480 = 0x4b000.  I had to work it out on a calculator.)

BTW, There's something similar in the function fake_internal in the
same file.

I'd fix this one myself, but I'm not set up to build the kernel (not
enough disk space), and it should get fixed in the real sources
anyway.

Would some kind soul please put up a kernel that fixes this?  ;-)

- monroe
------------------------------------------------------------------------
Monroe Williams                                        monroe@cs.pdx.edu