Re: [BISECTED]: Black screen on 7.0-rc1
From: Harald Arnesen
Date: Mon Feb 23 2026 - 16:29:12 EST
Linus Torvalds [2026-02-23 18:29:43]:
On Mon, 23 Feb 2026 at 03:33, Harald Arnesen <linux@xxxxxxxxxxx> wrote:
When I boot 7.0-rc1, I get a black screen. I bisected it yesterday, so
just before rc1 was out. This is the first bad commit:
commit c6e62d002b7f0613f02d8707c80f2a7bd66808a0
That's unfortunate. It's a merge that didn't even have any really
meaningful conflicts, so it's either slightly timing-dependent (and
your bisection is wrong), or it's some really subtle interaction with
something else.
Would you mind trying both parents a few times to see if it might be
timing? So test-boot the kernel at point
ba268514ea14 ("rust: devres: fix race condition due to nesting")
Boots fine.
which was the top of the driver core tree that was merged by that
commit c6e62d002b7f you bisected to (although it really all is mostly
rust support).
And please double-check the first parent too (ie commit 1c2b4a4c2bcb:
"Merge tag 'pci-v7.0-changes' of
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci") which was my
previous merge before that driver core merge..
Also boots fine.
Finally, please don't send bug reports like this to just me - at least
cc the kernel mailing list to have this all public and searchable.
User error. I intended to send it to the list, and CC you.
I'll forward the original to just Danilo (who is also cc'd here) but I
don't want to make private emails any more public than that, even if
your email seemed to not contain anything that shouldn't be public..
Also, even your working kernel has a *ton* of those
WARN_ALL_UNSEEDED_RANDOM warnings that just hide any real problem -
mind just disabling CONFIG_WARN_ALL_UNSEEDED_RANDOM to make it all
less noisy?
Done. I don't know why I had it enabled.
Because I think that flood of useless warnings might be hiding any real ones.
That said, the kernel you have problems with does have
[ 15.056948] WARNING: mm/vmalloc.c:554 at
vmap_small_pages_range_noflush+0x429/0x550, CPU#4: udevd/499
followed by
[ 15.057285] BUG: unable to handle page fault for address: 0000000000001008
and I assume that's the real smoking gun here (but there might be
others, hidden by those unrelated unseeded randomness messages)
That warning is
if (WARN_ON(!pfn_valid(page_to_pfn(page)))) {
in vmap_pages_pte_range(), called from
ar_context_init+0xcb/0x320 [firewire_ohci]
pci_probe+0x1e9/0x5c0 [firewire_ohci]
pci_device_probe+0x9b/0x120
really_probe+0xc2/0x270
and the page fault is in release_pages(), called from that same call
chain just later in ar_context_init(), so I think the two are very
much related.
So I *suspect* this is related to the changes from the firewire tree -
possibly with some interaction with the driver core tree given that
merge bisect - and I'm adding Takashi to the participants as well (and
I'll forward the original with all the attachments to him as well).
In fact, I would expect it to be related to one (or both) of
f2ae92780ab9 ("firewire: ohci: split page allocation from dma mapping")
993ab48006b3 ("firewire: ohci: stop using page private to store
DMA mapping address")
Should I try reverting one or both of these?
but that's purely because of the whole "that matches both vma()
changes and firewire", not because I see any particular bug.
Takashi, please take a look.
However, Harald - please do make a public email to the kernel mailing
list, and cc both Danilo and Takashi for that email, so that this is
all documented on the mailing lists too. Firewire isn't hugely common
these days, but it's rare that some buge hits just *one* person, and
so having this searchable by google etc is always a good thing.
Danilo / Takashi - I'll send the original report right after this.
Thanks,
Linus
Should I try another bisect to see if I have messed up the first? Can't do it until tomorrow afternoon (Central European Time).
--
Hilsen Harald