On 17 July 2018 at 10:59, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> On 14 July 2018 at 08:20, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Fri, Jul 13, 2018 at 4:51 PM Linus Torvalds
>> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> I'm building a "replace VM_BUG_ON() with proper printk's instead" right now.
>>
>> Ok, the machine now stays up, and I get messages like
>>
>> Removed VM_BUG_ON()!
>> pfn c2400 - c25ff
>> zone DMA32 DMA
>> zone pfn 1000 1
>>
>> Removed VM_BUG_ON()!
>> pfn c0a00 - c0bff
>> zone DMA32 DMA
>> zone pfn 1000 1
>>
>> Removed VM_BUG_ON()!
>> pfn c2200 - c23ff
>> zone DMA DMA32
>> zone pfn 1 1000
>>
>> instead.
>>
>> That's from
>>
>> + printk("Removed VM_BUG_ON()!\n");
>> + printk(" pfn %lx - %lx\n", page_to_pfn(start_page),
>> page_to_pfn(end_page));
>> + printk(" zone %s %s\n", page_zone(start_page)->name,
>> page_zone(end_page)->name);
>> + printk(" zone pfn %lx %lx\n",
>> page_zone(start_page)->zone_start_pfn,
>> page_zone(end_page)->zone_start_pfn);
>>
>> inside an if() statement that replaced that VM_BUG_ON().
>>
>> WTF? That's just odd.
>>
>> But everything seems to work fine, and now it doesn't crash.
>>
>> But there's something really odd going on wrt page_zone() and/or page_to_pfn().
>>
>> page_to_pfn() implies this is just regular memory in the 3GB area. It
>> is likely related to this:
>>
>> BIOS-e820: [mem 0x00000000c0b33000-0x00000000c226cfff] reserved
>> BIOS-e820: [mem 0x00000000c226d000-0x00000000c227efff] ACPI data
>> BIOS-e820: [mem 0x00000000c227f000-0x00000000c2439fff] usable
>> BIOS-e820: [mem 0x00000000c243a000-0x00000000c2a61fff] ACPI NVS
>> BIOS-e820: [mem 0x00000000c2a62000-0x00000000c32fefff] reserved
>> BIOS-e820: [mem 0x00000000c32ff000-0x00000000c32fffff] usable
>> BIOS-e820: [mem 0x00000000c3300000-0x00000000c7ffffff] reserved
>>
>> I dunno. It's a bit odd. I'm not sure I understand that VM_BUG_ON().
>> Adding Ard (who worked on the memblock_next_valid_pfn() thing not that
>> long ago) and must have hit this same BUG_ON() because he modified it
>> not that long ago.
>>
>> Ard, I triggered the VM_BUG_ON() in mm/page_alloc.c:2016, with a call trace opf
>>
>> RIP: move_pfreepages_block()
>> Call Trace:
>> steal_suitable_fallback
>> get_page_from_freelist
>> ...
>>
>> just for some context.
>>
>
> Pavel's fix for this issue in commit e181ae0c5db9 is causing boot
> problems on i686 for me.
>
> Is anyone else seeing the same?
>
> I get no output whatsoever when booting a i386_defconfig kernel under
> qemu/kvm (without EFI)
Never mind, I spotted the followup fix.
