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 15:16:34 +0700

     Date:        Sun, 29 Mar 2026 20:15:01 +0000 (UTC)
     From:        "opensauce04%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost=
 >
     Message-ID:  <20260329201501.E6D551A923E%mollari.NetBSD.org@localhost>
 
   |  Plugging in the charger as soon as the green text appears works fine,=
  it =
 
   |  consistently reaches the login prompt.
 
 OK, good, that significanyly reduces the possibilities for where the
 problem might be.
 
   |  I'm not quite sure how to read the values produced by these commands,=
  =
 
   |  but the output doesn't seem to change in any meaningful way.
 
 That's fine, I suspect you'd recognise it if there was anything untoward.
 
   | The `flt` value increases to ~3000
 
 That is "faults", ie traps, mostly caused by memory management for the
 kernel - usually processes accessing code/memory they have not accessed
 before which the kernel needs to make available.   All that is perfectly
 normal.
 
   | and the `in` value changes from around 30 to 100,
 
 That one is interrupts, that's the one that (might) have been an issue,
 but clearly isn't - if there was some kind of interrupt storm you'd be
 seeing that with a value in the tens of thousands (or more) probably, so
 that probably is not the problem (it was just a random guess of mine).
 
   |  before both then go back to their baselines, but I can get this to =
 
   |  happen by just doing stuff on the computer while it's running regardl=
 ess =
 
   |  of the state of the charger.
 
 Yes, all that is also all perfectly normal, all I/O causes interruts.  The=
 re
 are also clock interrupts that occur 100 times/second all the time (on a s=
 ystem
 configured the default way) - but I suspect that vmstat might hide those a=
 s
 not being useful to display, if you used "systat vm" you'd get a long colu=
 mn
 showing each of the interruot sources and the number of interrupts each is
 causing .. but look there only for your own benefit, no need to mention
 anything here, as interrupts are not looking to be relevant.   You can ass=
 ociate
 most interrupt sources with their cause by looking at the autoconfiguratio=
 n
 output (which is saved in /var/run/dmesg.boot so you can consult it later)
 
 Look for info like:
 
 	ahcisata0: interrupting at msi3 vec 0
 
 in that file, then expect to see "msi3 vec 0" with a counter next to it,
 when that counter is non-zero that SATA (disc) controller is interrupting,
 indicating filesystem (and similar) I/O is happening.
 
 What sources you have depends entirely upon what hardware exists, and how
 it is being used (AHCI is just one way to use SATA controllers for example=
 ).
 
 Note: all of this is just FYI, unrelated to finding the cause of your boot=
  hangs.
 
   |  The behaviour is identical between rebooting / shutting down + bootin=
 g. =
 
   |  The issue appears solely reliant on whether or not the laptop is =
 
   |  charging at the start of the boot process.
 
 OK, that is also useful information - it indicates that there is nothing b=
 eing
 changed after being used which isn't correctly being reset at boot time, a=
 nd
 eliminates more possible issues.
 
   |  Of course :) I meant to say that I don't have any X11 or Wayland sess=
 ion =
 
   |  configured to start at boot, so I just get dropped into the TTY when =
 the =
 
   |  OS boots. Apologies if I was unclear.
 
 No, it was clear, there are times I just like to be pedantic - particularl=
 y here
 as there are times when NetBSD has issues with the graphics hardware in so=
 me
 systems, which can be annoying to deal with.   That doesn't seem to be an =
 issue
 in your case (whether it would be if you started a window system is not ye=
 t
 known, but given that things are working now, when the charger is not plug=
 ged in
 when you boot, any issues in that area, if they ever become relevant, woul=
 d have
 workarounds.) =
 
 
 Your issue is happening much too early to be related to now NetBSD relates=
  to
 that hardware however, so that is another issue which is clearly not relat=
 ed.
 
 I'm afraid however that my knowledge of how x86 systems boot is now exhaus=
 ted,
 and you are going to need help from someone who understands how that happe=
 ns,
 and has some idea what might go wrong - and who can possibly suggest thing=
 s try.
 
 I'd suggest trying with boot options to increase the amount of autoconfig =
 output
 to get a better idea where things are stopping - but as you get none of th=
 at at
 all when things hang, I don't think that would provide any useful info at =
 all,
 and would just be a waste of time.   There might be more information you c=
 an get
 from efiboot, before attempting to boot, but for that you'd need advice fr=
 om
 someone who knows what is available, and how to interpret the results.   N=
 ot me.
 
 kre