bit system, count is 0xFFFE. That's seen as a
negative value, and the "for" loop does not do any iterations. So
nothing bad happens.
But on a 32-bit system, count is 0x7FFE. That's a big
positive number, and the "for" loop iterates to non-existent
mem
://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/
---
Michael, can you please test this patch and confirm that it prevents
the early oops?
Tested-By: Michael Schierl
Applied on top of 6.8.4, it prevents the early oops I previously
observed when booting with 2 vCPUs.
Regards
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
Hello,
Am 16.04.2024 um 01:31 schrieb Michael Kelley:
Can you give me details of the Hyper-V VM configuration? Maybe
a screenshot of the Hyper-V Manager "Settings" for the VM would
be a good starting point, though some of the details are on
sub-panels in the UI.
It used to be possible to ex
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 "hexdum
[please cc: me as I am not subscribed to either mailing list]
Hello,
I am writing to you as Jean is listed as maintainer of dmi, and the rest
are listed as maintainer for Hyper-V drivers. If I should have written
elsewhere, please kindly point me to the correct location.
I am having issues run
