Re: Early kernel panic in dmi_decode when running 32-bit kernel on Hyper-V on Windows 11

[Michael Schierl]

Hello Jean,


Thanks for your reply.


Am 17.04.2024 um 11:43 schrieb Jean DELVARE:

> Don't let the type 10 distract you. It is entirely possible that the
> byte corresponding to type == 10 is already part of the corrupted
> memory area. Can you check if the DMI table generated by Hyper-V is
> supposed to contain type 10 records at all?

How? Hyper-V is not open source :-)

My best guess to get Linux out of the equation would be to boot my
trusted MS-DOS 6.2 floppy and use debug.com to dump the DMI:

> | A:\>debug
> | -df000:93d0 [to inspect]
> | -nfromdos.dmi
> | -rcx
> | CX 0000
> | :439B
> | -w f000:93d0
> | -q


The result is byte-for-byte identical to the DMI dump I created from
sysfs and pasted earlier in this thread. Of course, it does not have to
be identical to the memory situation while it was parsed.

> You should also check the memory map (as displayed early at boot, so
> near the top of dmesg) and verify that the DMI table is located in a
> "reserved" memory area, so that area can't be used for memory
> allocation.

The e820 memory map was included in the early printk output I posted
earlier:

> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
> [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffeffff] usable
> [    0.000000] BIOS-e820: [mem 0x000000007fff0000-0x000000007fffefff] ACPI data
> [    0.000000] BIOS-e820: [mem 0x000000007ffff000-0x000000007fffffff] ACPI NVS

And from the dmidecode I pasted earlier:

> Table at 0x000F93D0.

The size is 0x0000439B, so the last byte should be at 0x000FD76A, well
inside the third i820 entry (the second reserved one) - and accessible
even from DOS without requiring any extra effort.

> So the table starts at physical address 0xba135000, which is in the
> following memory map segment:
>
> reserve setup_data: [mem 0x00000000b87b0000-0x00000000bb77dfff] reserved

Looks like UEFI, and well outside the 1MB range :-)

> If the whole DMI table IS located in a "reserved" memory area, it can
> still get corrupted, but only by code which itself operates on data
> located in a reserved memory area.


> Both DMI tables are corrupted, but are they corrupted in the exact same
> way?

At least the dumped tables are byte-for-byte identical on both OS
flavors. And (as I tested above) byte-for-byte identical to a version
dumped from MS-DOS.


Regards,


Michael