Messages in this thread | | | Date | Wed, 17 Apr 2024 23:08:02 +0200 | Subject | Re: Early kernel panic in dmi_decode when running 32-bit kernel on Hyper-V on Windows 11 | From | 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
| |