phil-opp/blog_os

panicked at 'assertion failed: max_phys_addr < (1 << 48) / 512' in post-09

willothy opened this issue · 8 comments

willothy commented

Crashed when running my code, and confirmed occurring as well with the code from post-09 branch.

It does not appear to be using my own panic handler (won't print text other than the error), even though other panics do.

Running Arch Linux, Rustc 1.65 nightly, QEMU 7.1.0. Same error occurs on Windows.

6th gen i7, 48GB RAM.

Error does not appear on another PC which is running a 10th gen i7 (QEMU 7.0.0).

abusch commented

Seeing the same thing on Macos with rustc 1.65.0-nightly (9243168fa 2022-08-31). It seems to happen as soon as I enable the map_physical_memory feature of the bootloader crate.

phil-opp commented

Thanks for reporting!

We currently see a test failure on our macOS CI runners as well. When I compared the logs for the last-working run and the first failing one, I noticed that QEMU updated from v7.0.0 to v7.1.0. The runners for Ubuntu and Windows stil use much older QEMU versions and don't show any problems.

Since Arch Linux is also typically running the newest software, I could imagine that this is triggered by the QEMU v7.1.0 release. Could you check your QEMU versions to see if my suspicion is correct?

phil-opp commented

The assertion failure happens here: https://github.com/rust-osdev/bootloader/blob/42da77b47558478c5a948d27cac80767b484eacc/src/main.rs#L289-L291 . If the assertion fails, it means that the memory map contains a memory region at address >512GiB, which is a bit strange. I think you should be able to bypass the assertion by creating a [package.metadata.bootloader] table in your Cargo.toml and add a physical-memory-offset = "0x0000f00000000000" field to it (choose any address you like). Then you should be able to inspect the memory map in your kernel. Maybe this tells us the reason for this assertion failure.

abusch commented

I can confirm I have QEmu 7.1.0 installed.

I used your workaround which indeed removed the panic, and was able to print the memory map:

Memory map: [
    MemoryRegion {
        range: FrameRange(0x0..0x1000),
        region_type: FrameZero,
    },
    MemoryRegion {
        range: FrameRange(0x1000..0x5000),
        region_type: PageTable,
    },
    MemoryRegion {
        range: FrameRange(0x5000..0x17000),
        region_type: Bootloader,
    },
    MemoryRegion {
        range: FrameRange(0x17000..0x18000),
        region_type: BootInfo,
    },
    MemoryRegion {
        range: FrameRange(0x18000..0x1f000),
        region_type: Kernel,
    },
    MemoryRegion {
        range: FrameRange(0x1f000..0x9f000),
        region_type: KernelStack,
    },
    MemoryRegion {
        range: FrameRange(0x9f000..0xa0000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xf0000..0x100000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0x100000..0x280000),
        region_type: KernelStack,
    },
    MemoryRegion {
        range: FrameRange(0x280000..0x400000),
        region_type: Usable,
    },
    MemoryRegion {
        range: FrameRange(0x400000..0x448000),
        region_type: Kernel,
    },
    MemoryRegion {
        range: FrameRange(0x448000..0x854000),
        region_type: PageTable,
    },
    MemoryRegion {
        range: FrameRange(0x854000..0x7fe0000),
        region_type: Usable,
    },
    MemoryRegion {
        range: FrameRange(0x7fe0000..0x8000000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xfffc0000..0x100000000),
        region_type: Reserved,
    },
    MemoryRegion {
        range: FrameRange(0xfd00000000..0x10000000000),
        region_type: Reserved,
    },
]

Hope this helps.

  • 👍1
phil-opp commented

It does, thanks a lot! Looks like there is indeed a new reserved memory region just below the 1TiB mark now.

  • 👍2
willothy commented

Since Arch Linux is also typically running the newest software, I could imagine that this is triggered by the QEMU v7.1.0 release. Could you check your QEMU versions to see if my suspicion is correct?

Yes, can confirm that the computer it's failing on runs QEMU 7.1.0 and the one it works on is running 7.0.0.

Also, set the offset in Cargo.toml and it is now working again (on 7.1.0). Thanks for the workaround!

phil-opp commented

Thanks! Let's keep this issue open for now, this is something that we should fix in the bootloader crate.

  • 👍2