Re: machfb still broken for first gen iMacs

[Michael <macallan%NetBSD.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Oct 2, 2010, at 8:30 PM, John Klos wrote:

> > > The first two are for reference and show a genfb kernel. This is a  
> > > first generation iMac with a VGA connection to a regular monitor.
> >
> > What about the built-in monitor?
>
> There is none. This iMac doesn't support more than one monitor. The  
> motherboard was saved from a junked iMac.

Ah, ok. I remember the typical DB15 monitor connector inside ;)
If I remember correctly the built-in monitor does not support DDC,  
instead the firmware puts an EDID block in a property attached to the  
graphics chip's node. It would be interesting if the EDID block  
provided is from your monitor or the one for the built-in screen. But  
that doesn't seem to have anything to do with your problem and the  
machfb version in the netbsd-5 branch doesn't even try to use it.

> > Does the iMac lock up here or does it continue booting with an  
> > unreadable console?
>
> It seems to continue because I see small groups of pixels change for  
> the next minute or so, but I wasn't able to access it via the  
> network. For a little while other small screen changes happened when  
> I hit keys, but a reboot command didn't (reboot).

Hmm, this is getting weirder. Did it not make it into userland or did  
you just not set things up (yet) ?
I'd like to see the whole dmesg output with debug info when this  
happens.

> > Since this seems to be drawing engine related I'm afraid it's a  
> > lockup though, and since you see the 'initial resolution...' line  
> > we made it past engine initialization and mode setup.
> > Please do this:
> > - - comment out the mach64_clearscreen() call in mach64_attach() so  
> > output doesn't get lost
> > - - sprinkle printf()s to find out where exactly the messup  
> > happens, normal console output should work right up to  
> > wsdisplay_cnattach()
> > - - set options_MACHFB_DEBUG in your kernel config for extra loudness
> > This should give us an idea where the messup happens. As I said  
> > before, I have a beige G3 with onboard Rage II and a Sun PGX  
> > ( which is another Rage II on a PCI card ) - both work fine.
> > Finally, you could try to if (0) the ri->ri_ops.putchar = ... line  
> > in mach64_init_screen() so we fall back to software character  
> > drawing. If that helps at least I know where to look.
>
> I'll try those when I'm on that machine again. Thanks!

I wonder if it has anything to do with the fact that your iMac has 6MB  
video memory ( as does the one in the PR ) while all the mach64s I  
have here have 4MB at most. Back when I had access to an iMac it did  
have 6MB as well though. I don't really see how that would make a  
difference though - the drawing engine registers are at the end of  
each aperture, there is no overlap unless you have 8MB VRAM.

That reminds me, since you have been dealing with these machines far  
longer than I did - my beige G3 has a 2MB onboard Rage II. I added a  
4MB VRAM module ( I have two of them, same effect with either one )  
yet both machfb and MacOS only see 4MB. Any idea why? It seems to be a  
firmware thing unrelated to the operating system, with the console on  
a different graphics chip machfb sees only 2MB.
Firmware is 2.0f1.
I may be able to fix this in machfb but first I'd like to know if  
that's a known problem with some beige G3s, if there's a way around it  
etc.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTKfa8cpnzkX8Yg2nAQKTQAgAgcCa6Wtxcnm07lNGlGu6YmQGZh4H7gVl
66cqkK1K6HeCWdEg34On9tw/7PK7VvuEGWyZ62F2jgGDKlNF03fVy7dRHxDT8oCX
FWNQClmP8Scbb4FcQrOXjvUatVc35HKa33XnjfntKuROUOgZVe9pVevzMuL0gPJB
Mc1VtS2b4U3akZlUqFZJLBa9ayS1kagP9skb1Bdtk0Bo/4wS2GFOGOJbbO4mgg+l
VNBLEhpQlbPb78Pia6AAFqWkQ+7URpqHNyL1yL+okjAauI9G6z7Gu4RKWdfUgwlG
W0wsEFUINKTPq7lPB8oaCNtDL5QsrYiP7WhmhhOcG3c4+vJ7JZELSg==
=44Nh
-----END PGP SIGNATURE-----