On Mon, Jan 25, 2021 at 09:46:19PM +0000, Chris Wilson wrote: > Quoting Mike Rapoport (2021-01-25 21:33:48) > > On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote: > > > On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <ch...@chris-wilson.co.uk> > > > wrote: > > > > > > > > Quoting Linus Torvalds (2021-01-25 01:06:40) > > > > > Mike Rapoport (3): > > > > ... > > > > > mm: fix initialization of struct page for holes in memory layout > > > > > > > > We have half a dozen or so different machines in CI that are silently > > > > failing to boot, that we believe is bisected to this patch. > > > > > > That commit reverts cleanly - so if you can verify that reverting it > > > fixes your CI machines, I think that that's the right thing to do for > > > now, unless Mike can figure out some obvious "Duh!" moment from your > > > working dmesg. > > > > Unfortunately not, at least at 11pm :( > > Maybe tomorrow I'll have something smarter to say. > > CI does confirm that the revert of d3921cb8be29 brings the machines back > to life.
I still cannot see what could possibly go wrong, so let's revert d3921cb8be29 for now and I'll continue to work with Chris to debug this. > > > Mike: should we perhaps revert the first patch too (commit > > > bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")? This change should be quite innocuous, we anyway never allocate pfn 0 but treat 0 as memory start in many places. > > I wonder, maybe actually this one is causing troubles? > > > > Chris, would it be possible to check what happens if you revert only > > bde9cfa3afe4? > > Queued for CI, will be run in about an hour. > -Chris -- Sincerely yours, Mike.
