The dmesg output you posted confirms that max_low_pfn is indeed 0x373fe, and it
appears
that the value of phys_mem being checked mat be 0x3f401ff1, which translates to
pfn 0x3f401,
at least if what's still in registers can be believed.
Since that is indeed greater than max_low_pfn, VIRTUAL_BUG
You might be hitting a bug I found.
Try applying this patch:
https://marc.info/?l=linux-kernel&m=155355953012985&w=2
Unfortunately it did not change anything.
--
Meelis Roos
On 3/26/19 6:52 AM, William Kucharski wrote:
Does this still happen on 5.1-rc2?
Do you have idea as to what max_low_pfn() gets set to on your system at boot
time?
From the screen shot I'm guessing it MIGHT be 0x373fe, but it's hard to know
for sure.
On Mar 21, 2019, at 2:22 PM, Meelis
Does this still happen on 5.1-rc2?
Yes. 4.20 and 5.0 and anything after that up to 5.1-rc2.
Do you have idea as to what max_low_pfn() gets set to on your system at boot
time?
From the screen shot I'm guessing it MIGHT be 0x373fe, but it's hard to know
for sure.
From dmesg of 5.1-rc2 wit
Does this still happen on 5.1-rc2?
Do you have idea as to what max_low_pfn() gets set to on your system at boot
time?
From the screen shot I'm guessing it MIGHT be 0x373fe, but it's hard to know
for sure.
> On Mar 21, 2019, at 2:22 PM, Meelis Roos wrote:
>
> I tried to debug another problem
I tried to debug another problem and turned on most debug options for memory.
The resulting kernel failed to boot.
Bisecting the configurations led to CONFIG_DEBUG_VIRTUAL - if I turned it on
in addition to some other debug options, the machine crashed with
kernel BUG at arch/x86/mm/physaddr.c:7
6 matches
Mail list logo
