Re: NetBSD 8.1 / Sun Ultra5 install crash during initial kernel device autosizing

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

Hello,

On Tue, 3 Dec 2019 21:45:18 -0500
Jacob Ritorto <jacob.ritorto%gmail.com@localhost> wrote:

> I've since my initial post gathered up serial console plumbing and
> have gone through headless boot (and successful 8.1 install!) .  Works
> fine, no crashes.  One really interesting thing was that after
> install, when I tried Michael's advice and plugged in a different
> monitor (while running), the system panicked!

That's odd - machfb has no support for hotplugging monitors, I don't
even know if the hardware can detect it. You may have moved the card
while plugging in the monitor, that's the only reason I can think of
for this to cause a crash.

> The last boot message I can grab when booting with head and using my
> eyes is something about post_div, which I suspect comes right after
> the machfb stuff.  Planning to review other boot messages and try to
> interpret what that means.  But in the meantime, does anyone know of a
> way to let me instrument the machfb piece?  Like, where's that in the
> source tree?  Sorry for the newbie question -- new here.  Can I change
> and rebuild machfb and stuff it into the kernel to provide some
> tracers and see EDID, etc? I'd like to sanity-check my EDID info
> coming in and ascertain whether the existing code digests it.

Machfb lives in src/sys/dev/pci/machfb.c
options MACHFB_DEBUG in your kernel config will enable a bunch of debug
output, including the EDID block.

> Another question (and forgive me if this is contentious -- again, new
> here) is: while I do enjoy the more snazzy font and resolution switch
> at boot on my other spares that work well,  why is the video mode
> changed at boot?  For aesthetics?  If so, wouldn't it be less fragile
> and more accommodating to leave it at default?

The intention is to switch to the monitor's preferred mode - Sun OF has
a nasty habit of sticking to VESA modes. We should really skip mode
setting if what we want matches what the firmware set up for us though.

Since I'm working on a similar issue reported on port-macppc@ - any
chance you can try a -current kernel?

have fun
Michael