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
