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

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

Hello,

On Wed, 4 Dec 2019 20:05:45 -0500
Jacob Ritorto <jacob.ritorto%gmail.com@localhost> wrote:

> > > 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.  
> 
> Any chance you could walk show me that logic?  I'm still spooling up
> in my NetBSD efforts here and am just now figuring out this world's
> version of loading sources and compiling kernels, etc.  But I do this
> sort of stuff a lot - including way back to pdp11 2BSD and v7, etc, so
> I can get there.  But a touch of hand holding could really accelerate
> me if you have a sec..

You mean the driver source?
For now it tries to acquire an EDID block from a device property
( mach64 has no standard way to talk to DDC2-monitors, different cards
use different GPIOs, but firmware may provide an EDID block and there
is machine-specific code in place to forward it to display drivers ),
tries to find the monitor's preferred mode, or the best mode supported
by both the monitor and the graphics chip, and switch to that one if
successful and different from what the firmware set up.
This logic is driver specific since different chips have different
limitations that can't be easily generalized.

> > Since I'm working on a similar issue reported on port-macppc@ - any
> > chance you can try a -current kernel?  
> 
> Yeah, I *think* I did that (kinda guessing from general unix habits)
> with the December 1 build of HEAD by slapping the new kernel down on
> the root fs and telling boot to boot it instead of the default.  Was
> that the right way?  Anyway, it crashed exactly the same way using
> that HEAD kernel and method.

Yes. Most of our kernels contain a lot of backwards compatibility code
so it's usually safe to just build a new kernel and boot it, even with
a relatively ancient userland.

> Related datapoint: I tried this same kernel supplanting test with
> other kernel release versions down to 7.0.2 and that was the first one
> that allowed normal boot to proceed without the crash.  7.1 crashes
> just the same as 8.1 and HEAD (now 9).  So according to NetBSD release
> dates webpage, the date gap there when it went from working to broken
> is October 2016 to March 2017, so presumably whatever's triggering the
> fault came in in that timeframe.  I've not yet figured out how PRs /
> code changes correlate to releases, but working on it..

Hmm, I'll have a look t machfb changes in that time frame.

> Generally, I'm eager to dive in here and answer whatever questions you
> posit and have quite a few SPARCs and Macintoshes to help with real
> hardware variety!

That's the majority of my hardware zoo - throw in a few SGIs, ARMs and
the occasional weirdo machine...

> P.S. In minutes-old news, here, boot -c and disable machfb worked and
> the machine booted okay using the generic fb.  It even shifted the
> genfb0 resolution to 1280x1024 successfully with keyboard plugged in
> and with screen/keyboard being used as wscons or whatever that's
> called.  But X won't start with this genfb, so I'm still stuck.

Genfb doesn't change resolutions, ever. It runs with whatever it finds,
which is its whole reason to exist - you point it at a framebuffer,
give it some info on how it's organized and a handful callbacks to
change palette registers, that's it. Without the callbacks it will
assume an ANSI-ish palette and disable anti-aliased fonts ( unless it's
running on something like a 24bit true colour fb )
So whatever goes wrong is machfb's fault, not some firmware weirdness.

have fun
Michael