Re: diagnosing post-install boot failure

[Martin Neitzel <neitzel%hackett.marshlabs.gaertner.de@localhost>]

BC> dmesg shows intelfb0 at i916drmkms0

Do you also happen to have dmesgs refering to the state of the
EDID recognition, i.e.  the resolution and timings of your
monitor/display?

I'm asking because NetBSD will behave the same on an old
ASUS EeePC 1003H (Intel N270 CPU, 945GME graphics):

It will successfully probe for the i915drmkms, and then,
when switching from VGA/BIOS to the framebuffer, just
turn black.

Disabling the i915drmkms driver (via "boot -c" / /boot.cfg)
helped me to get started (as others have already recommended).
(In the older days, the pre-KMS "i1915drm" would take over
and do a good job, too;  but I believe we have dropped that
driver by now, at least in the default GENERIC kernel.)

With an installed system, you can give i915drmkms another
try and then, with a dark/unusable console ssh into the box
and check for the dmesg output.

In my EeePc case, I found a complaint the EDID checksum failing
(and hence the EDID data being ignored).  None of the other
OSes (*BSD, Linuxens) had a problem with that.  I simply
commented out that checksum check in my sources and it happens
to work great:  I can boot using the i915drmkms driver, and
it switches to a high resolution, usable framebuffer console,
and X11 will work, too.

Maybe that EDID checksum problem is botched on more platforms?

One last note:

In order to accomodate modern high-DPI displays, NetBSD-10 and
upwards can DRM-switch from VGA/BIOS to a very large font
in framebuffer mode.  It appears extremely klutzy but *is*
running on a high-resolution framebuffer.  Have a look at
wscons.conf(5) use wscons=YES in rc.conf when you want to
have a more pleasant console (and are not always running X11).

					Martin Neitzel