NetBSD Problem Report #60140
From www@netbsd.org Sat Mar 28 22:09:39 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 73B881A9239
for <gnats-bugs@gnats.NetBSD.org>; Sat, 28 Mar 2026 22:09:39 +0000 (UTC)
Message-Id: <20260328220938.5034C1A923E@mollari.NetBSD.org>
Date: Sat, 28 Mar 2026 22:09:38 +0000 (UTC)
From: opensauce04@gmail.com
Reply-To: opensauce04@gmail.com
To: gnats-bugs@NetBSD.org
Subject: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 more often than not
X-Send-Pr-Version: www-1.0
X-From4GNATS: "opensauce04@gmail.com via gnats" <gnats-admin@NetBSD.org>
>Number: 60140
>Category: kern
>Synopsis: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 (when AC adaptor charging)
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 28 22:10:00 +0000 2026
>Last-Modified: Thu Apr 09 22:15:00 +0000 2026
>Originator: Daniel
>Release: 11.0-RC2
>Organization:
>Environment:
>Description:
The majority of the time I boot into NetBSD 11.0-RC2 after installing it on my laptop, I reach the EFI boot screen, either select "1" or let it finish on its own, it displays several numbers on the screen as usual, and then goes to a black screen and never does anything else no matter how long it's left for.
Importantly, this doesn't happen *every* time the laptop is booted. Sometimes, it boots just fine, and I haven't found any rhyme or reason for why this happens.
No factors I have control over seem to determine whether or not the laptop boots successfully. Waiting on the boot options menu, waiting for an extended period of time between boots, etc all seem to have no effect on when it does or doesn't happen.
This happens in both the installer and the fully installed OS. I have tried re-flashing the install media multiple times, and have verified that the checksum of my install media is correct, and yet I still experienced this issue with consistent inconsistency across all attempts.
These boot issues do not happen under other operating systems such as Linux.
I am unsure of how to diagnose this issue, and I'm also not 100% sure this is a kernel issue, that just seems like the most logical thing that would be failing here. Please direct me on how to collect any useful information.
>How-To-Repeat:
Exact repro conditions unknown
>Fix:
>Release-Note:
>Audit-Trail:
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Sat, 28 Mar 2026 22:17:10 +0000
I accidentally pressed enter on my keyboard before being able to share
my uname -a output. Here it is:
NetBSD netbook.powerhub 11.0_RC2 NetBSD 11.0_RC2 (GENERIC) #0: Wed Mar
4 21:02:00 UTC 2026
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Sat, 28 Mar 2026 22:25:22 +0000
I continued to investigate the issue after submitting this bug, and I
think I may have found the trigger.
It seems like whether or not the bug happens is tied to whether or not
the laptop is *charging*?
I unplugged the charger on a whim, and then got 5 successful boots off
in a row, however after plugging the laptop back in, I got 1 successful
boot before immediately being stuck in a string of failed boots once
again. Once I unplugged the charger again, I once again can't get the
boot process to fail like I can when the charger is plugged in.
How bizarre!
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Sat, 28 Mar 2026 22:38:19 +0000
It also seems like I didn't manage to change the severity to 'critical'
before fat-fingering the enter key; that of course applies here.
Could someone update that, and also maybe update the PR title to reflect
the charging thing if possible?
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 more often than not
Date: Sun, 29 Mar 2026 22:09:43 +0700
Date: Sat, 28 Mar 2026 22:40:02 +0000 (UTC)
From: "opensauce04@gmail.com via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20260328224002.2FBE61A923E@mollari.NetBSD.org>
| Could someone update that, and also maybe update the PR title to reflect
| the charging thing if possible?
I have done that.
When you say "boots to black screen" do you mean doesn't boot at all?
The boot process should start writing some (usually green) text to
the monitor, using the firmware to access the display) - and then
eventually take over the display (you can often see the font change)
and continue writing more configuration info (you will have seen all
of this on the successful boots).
If none of that happens, the boot isn't being successful at all (probably
the kernel is being loaded, those are the "writes some numbers", but after
that something hangs, or similar).
If it reaches the point where the video should switch, and the screen
just goes black instead, then that's an entirely different class of problem.
In that case, if you can (from elsewhere - even from a phone) see if you
can access the system (can you ping it) - if so, that would indicate it
is running OK, and just the video is not functioning. If it isn't responding
then the boot failed somehow.
Which of these is happening would be useful info to find the right person
to help you work out what the issue really is (all I can say about that now
is that I will not be that person).
kre
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Sun, 29 Mar 2026 17:17:39 +0100
> The following reply was made to PR kern/60140; it has been noted by GNATS.
>
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad X240 more often than not
> Date: Sun, 29 Mar 2026 22:09:43 +0700
>
> Date: Sat, 28 Mar 2026 22:40:02 +0000 (UTC)
> From: "opensauce04@gmail.com via gnats" <gnats-admin@NetBSD.org>
> Message-ID: <20260328224002.2FBE61A923E@mollari.NetBSD.org>
>
> | Could someone update that, and also maybe update the PR title to reflect
> | the charging thing if possible?
>
> I have done that.
>
> When you say "boots to black screen" do you mean doesn't boot at all?
>
> The boot process should start writing some (usually green) text to
> the monitor, using the firmware to access the display) - and then
> eventually take over the display (you can often see the font change)
> and continue writing more configuration info (you will have seen all
> of this on the successful boots).
>
> If none of that happens, the boot isn't being successful at all (probably
> the kernel is being loaded, those are the "writes some numbers", but after
> that something hangs, or similar).
>
> If it reaches the point where the video should switch, and the screen
> just goes black instead, then that's an entirely different class of problem.
> In that case, if you can (from elsewhere - even from a phone) see if you
> can access the system (can you ping it) - if so, that would indicate it
> is running OK, and just the video is not functioning. If it isn't responding
> then the boot failed somehow.
>
> Which of these is happening would be useful info to find the right person
> to help you work out what the issue really is (all I can say about that now
> is that I will not be that person).
>
> kre
On failed boots, there is none of the usual green text. Numbers are
printed to the screen in a white font, and then the laptop screen just
goes blank and nothing ever happens. The laptop and its screen are still
powered on, it's just black.
On successful boots, the usual green text appears, and I get dropped
into a TTY login prompt as expected. The system works completely fine
after this point.
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, and everything is fine, but if it's
charging *during the boot process*, it has an extremely high likelihood
of failing.
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.
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.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
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 via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20260329162002.A450E1A923E@mollari.NetBSD.org>
| 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
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Sun, 29 Mar 2026 21:13:58 +0100
This is a multi-part message in MIME format.
--------------knrvqTp877eowhuh7X5yyHab
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
> 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
Plugging in the charger as soon as the green text appears works fine, it
consistently reaches the login prompt.
> 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.)
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. The `flt`
value increases to ~3000 and the `in` value changes from around 30 to
100, 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 regardless
of the state of the charger.
> | 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.
The behaviour is identical between rebooting / shutting down + booting.
The issue appears solely reliant on whether or not the laptop is
charging at the start of the boot process.
> 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).
This has no effect.
> | 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).
Of course :) I meant to say that I don't have any X11 or Wayland session
configured to start at boot, so I just get dropped into the TTY when the
OS boots. Apologies if I was unclear.
----
Is there anything else you'd like me to try/share to help investigate
the issue?
--------------knrvqTp877eowhuh7X5yyHab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite"
cite="mid:20260329191502.14B141A923E@mollari.NetBSD.org">
<pre wrap="" class="moz-quote-pre"> 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 </pre>
</blockquote>
Plugging in the charger as soon as the green text appears works
fine, it consistently reaches the login prompt.
<blockquote type="cite"
cite="mid:20260329191502.14B141A923E@mollari.NetBSD.org">
<pre wrap="" class="moz-quote-pre"> 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.)
</pre>
</blockquote>
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. The `flt` value increases to ~3000 and the `in` value changes
from around 30 to 100, 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 regardless of the state of the charger.<span
style="white-space: pre-wrap">
</span>
<blockquote type="cite"
cite="mid:20260329191502.14B141A923E@mollari.NetBSD.org">
<pre wrap="" class="moz-quote-pre"> | 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.</pre>
</blockquote>
The behaviour is identical between rebooting / shutting down +
booting. The issue appears solely reliant on whether or not the
laptop is charging at the start of the boot process.
<blockquote type="cite"
cite="mid:20260329191502.14B141A923E@mollari.NetBSD.org">
<pre wrap="" class="moz-quote-pre"> 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).
</pre>
</blockquote>
This has no effect.<span style="white-space: pre-wrap"> </span>
<blockquote type="cite"
cite="mid:20260329191502.14B141A923E@mollari.NetBSD.org">
<pre wrap="" class="moz-quote-pre"> | 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).</pre>
</blockquote>
<p>Of course :) I meant to say that I don't have any X11 or Wayland
session configured to start at boot, so I just get dropped into
the TTY when the OS boots. Apologies if I was unclear.</p>
<p>----</p>
<p>Is there anything else you'd like me to try/share to help
investigate the issue?</p>
<br>
</body>
</html>
--------------knrvqTp877eowhuh7X5yyHab--
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
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 via gnats" <gnats-admin@NetBSD.org=
>
Message-ID: <20260329201501.E6D551A923E@mollari.NetBSD.org>
| 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
From: opensauce04@gmail.com
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Thu, 9 Apr 2026 22:09:04 +0100
> The following reply was made to PR kern/60140; it has been noted by GNATS.
>
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@netbsd.org
> 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 via gnats" <gnats-admin@NetBSD.org=
> >
> Message-ID: <20260329201501.E6D551A923E@mollari.NetBSD.org>
>
> | 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
Hi, just checking in on this; will someone need to be assigned to this
problem, or will someone just show up eventually when available/ when
it's appropriate? Wouldn't want this to go buried, it's a kind of
annoying issue for me and something that could discourage use of NetBSD
for others who are using this ThinkPad model (or potentially other
devices which could be affected by the same issue).
Additionally, 11.0_RC3 is also affected. I know that this issue hasn't
been addressed, so that's expected, but it's still probably worth
pointing out regardless.
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
opensauce04@gmail.com
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Thu, 9 Apr 2026 23:51:20 +0200
One question did come to my mind: is it a system with a dual GPU ?
If so, could it be that the system starts with the big GPU when power is
plugged in, and with the little GPU when starting on battery ?
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Daniel Bradbury <opensauce04@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60140: NetBSD 11.0-RC2 boots to black screen on Thinkpad
X240 more often than not
Date: Thu, 9 Apr 2026 23:13:26 +0100
> One question did come to my mind: is it a system with a dual GPU ?
> If so, could it be that the system starts with the big GPU when power is
> plugged in, and with the little GPU when starting on battery ?
It's a single-GPU system; it contains only an Intel HD Graphics 4400
integrated GPU
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home