Hello Michael,
Am 15.04.2024 um 05:17 schrieb Michael Kelley:
Let me suggest some additional diagnostics. The DMI information is
provided by the virtual firmware, which is provided by the Hyper-V
host. The raw DMI bytes are available in Linux at
/sys/firmware/dmi/tables/DMI
If you do "hexdump /sys/firmware/dmi/tables/DMI" on your
patched 32-bit kernel and on a working 64-bit kernel, do you see the
same hex data? (send the output to a file in each case, and then
compare the two files)
For convenience, as I currently have no installed system with 64-bit
kernel on this Hyper-v instance, I tested with 32-bit and 64-bit kernel
6.0.8 from live media (grml96 2022.11 from www.grml.org), as well as
with my own 32-bit kernel (only for 2-core case).
In any case, I see the same content for /sys/firmware/rmi/tables/DMI as
well as /sys/firmware/dmi/tables/smbios_entry_point on 32-bit vs. 64-bit
kernels. But I see different content when booted with 1 vs. 2 vCPU.
So it is understandable to me why 1 vCPU behaves different from 2vCPU,
but not clear why 32-bit behaves different from 64-bit (assuming in both
cases the same parts of the dmi "blob" are parsed).
If the DMI data is exactly the same, and a
64-bit kernel works, then perhaps there's a bug in the
DMI parsing code when the kernel is compiled in 32-bit mode.
Also, what is the output of "dmidecode | grep type", both on your
patched 32-bit kernel and a working 64-bit kernel?
On 64-bit I see output on stderr as well as stdout.
Invalid entry length (0). DMI table is broken! Stop.
The output before is the same when grepping for type
Handle 0x0000, DMI type 0, 20 bytes
Handle 0x0001, DMI type 1, 25 bytes
Handle 0x0002, DMI type 2, 8 bytes
Handle 0x0003, DMI type 3, 17 bytes
Handle 0x0004, DMI type 11, 5 bytes
When not grepping for type, the only difference is the number of structures
1core: 339 structures occupying 17307 bytes.
2core: 356 structures occupying 17307 bytes.
I put everything (raw and hex) up at
<https://gist.github.com/schierlm/4a1f38565856c49e4e4b534cf51961be>
root@mhkubun:~# dmidecode | grep type
Handle 0x0000, DMI type 0, 26 bytes
Handle 0x0001, DMI type 1, 27 bytes
Handle 0x0002, DMI type 3, 24 bytes
Handle 0x0003, DMI type 2, 17 bytes
Handle 0x0004, DMI type 4, 48 bytes
Handle 0x0005, DMI type 11, 5 bytes
Handle 0x0006, DMI type 16, 23 bytes
Handle 0x0007, DMI type 17, 92 bytes
Handle 0x0008, DMI type 19, 31 bytes
Handle 0x0009, DMI type 20, 35 bytes
Handle 0x000A, DMI type 17, 92 bytes
Handle 0x000B, DMI type 19, 31 bytes
Handle 0x000C, DMI type 20, 35 bytes
Handle 0x000D, DMI type 32, 11 bytes
Handle 0xFEFF, DMI type 127, 4 bytes
That looks healthier than mine... Maybe it also depends on the host...?
Interestingly, there's no entry of type "10", though perhaps your
VM is configured differently from mine. Try also
dmidecode -u
What details are provided for "type 10" (On Board Devices)? That
may help identify which device(s) are causing the problem. Then I
might be able to repro the problem and do some debugging myself.
No type 10, but again the error on stderr (even with only 1 vCPU).
One final question: Is there an earlier version of the Linux kernel
where 32-bit builds worked for you on this same Windows 11
version?
I am not aware of any (I came from Windows 10 with VirtualBox and wanted
to move my setup to Windows 11 with Hyper-V).
I just tested a 10-year old Linux live media with kernel 3.16.7, and it
behaves the same (2vCPU 32-bit does not boot, the other configurations
do). I may have some more really old live media on physical CDROMs
around, but I doubt is is useful testing these to find out if some
really old kernel would work better.
Thanks again,
Michael
