Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 more often than not

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60140; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 more often than not
Date: Mon, 30 Mar 2026 02:09:34 +0700

     Date:        Sun, 29 Mar 2026 16:20:02 +0000 (UTC)
     From:        "opensauce04%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260329162002.A450E1A923E%mollari.NetBSD.org@localhost>
 
   |  On failed boots, there is none of the usual green text.
 
 OK, that points to either a problem in efiboot, as part of the handoff
 to NetBSD, or in the very early stages of the NetBSD startup.
 
 Someone who understands x86 internals and its startup code might be
 able to suggest what to try next.
 
   |  To clarify, whether or not the charger is plugged in only matters during 
   |  the boot process. I can unplug the charger, wait for it to boot, and 
   |  then plug the charger back in,
 
 My guess would be that you could probably plug it back in as soon as
 the (green text) autoconfiguration messages start appearing.   If that
 doesn't work (if the boot were to hang at that time as soon as you plug
 in the charger) it would be a clue that the issue is related to unprocessed
 interrupts - with an interrupt pending that is never acknowledged, and
 simply occurs again as soon as the interrupt handler is done.   Once the
 system has got far enough into its config, interrupts might still happen,
 but do no more than waste cpu time - which suggests something else you
 can look at.  On a boot that works, when you later plug in the charger,
 use either vmstat -w1  or  systat vm   and look at the interrupt rate.
 If you see many thousands (or more) of interrupts per second, continuously,
 that would be a good clue (but not seeing that means nothing.)
 
   | it has an extremely high likelihood of failing.
 
 One other question worth asking is whether it makes any difference
 whether the laptop was powered off (as in shut down completely) before
 the boot, rather than just reset or a reboot.   Also perhaps whether
 it makes any difference if you interact with the firmware between starting
 the boot sequence and the firmware actually attempting an OS boot
 (that is if you enter the firmware setup mode, and then do the "save & exit"
 operation to boot, does that make any difference).
 
 It is likely that none of this will be relevant - but more information,
 that is, more clues, never hurts.
 
   |  I have no desktop environment installed on this device, and as I 
   |  mentioned, this also happens with flashed USB installers, which also 
   |  have no graphical environment.
 
 On a laptop there is always a graphical environment (or 99% of the time).
 
 There might be no window system running, but the text console is a
 graphical environment - just a primitive one - it is still all using the
 graphics hardware to generate everything that you see on the display.
 
 The only way you'd be avoiding that would be by using a serial console,
 and doing that on a laptop (particularly a modern one with no rs232 ports)
 is a very unusual thing.
 
 It was obvious from your initial message that you were (when things fail
 anyway, which is when it matters) never getting to the state where a
 window system could be conceivably relevant.
 
   |  I am unable to ping the laptop when the boot fails, but can ping it 
   |  successfully without logging in when the boot is successful. Definitely 
   |  seems like NetBSD is failing to boot rather than it being any video issue.
 
 Yes, if you're not getting any of the autoconfig messages at all - the first
 of which are just calls to the firmware to output text - and we know that
 works, because that's the exact same thing that efiboot is using - then
 NetBSD is certainly not starting (properly) at all.
 
 kre