On Tue, Oct 31, 2023 at 11:20:00AM +0100, Lukasz Stelmach wrote:
> I am attaching dsdt.dat. It is the only file that contains the
> "HPBIOS_BIOSEvent" string and the above UUID.
OK, I think I've figured it out.
Earlier, I focused on "probe of 8F1F6435-9F42-42C8-BADC-0E9424F20C9A failed"
(the GUID of HPBIOS_BIOSNumericSensor), and missed it when you said the failure
is happening when check_wobj() is called from check_platform_events_wobj().
So the issue is actually with HPBIOS_PlatformEvents.Name, since any instances
of that WMI object are examined during driver init as well.
After using iasl to decompile the DSDT you sent to ACPI Source Language (ASL),
everything looks fine with HPBIOS_BIOSNumericSensor. Not that I'm particularly
familiar with ASL, but search for "Name (SEN1, Package (0x06)" and read on to
the "Method (_INI, 0, NotSerialized)" and the "Method (WQAE, 1, Serialized)"
lines below. It certainly looks like that's how the BIOS on that system is
generating HPBIOS_PlatformEvents instances at runtime.
For HPBIOS_PlatformEvents instances, that BIOS seems to generate them in two
places. The driver is interested in those from "Method (WQBC, 1, Serialized)",
which rely on the section above that beginning at "Name (EVNT, Package (0x0D)".
There are also some generated in "Method (WQPE, 1, Serialized)", relying on:
Name (CBWE, Package (0x02)
{
Package (0x05)
{
Unicode ("4BIOS Configuration Change"), // Oops.
"BIOS Settings",
0x04,
0x05,
0x02
},
Package (0x05)
{
"BIOS Configuration Security",
"An attempt has been made to Access BIOS features unsuccessfully",
0x04,
0x0A,
0x06
}
})
So yes, Armin was right, UTF-16 is the culprit. And it's only for this one
instance of HPBIOS_PlatformEvents on this one system's BIOS.
Can you find the wonky object instance in the debugfs interface? I imagine
its name shows up as either "4" or an empty string, depending on the UTF-16
byte order.
I'm also curious how it looks in Windows (I used WMI Explorer [1] during
development). The WMI namespace should be "\\.\root\HP\InstrumentedBIOS".
> The readings of hp_wmi_sensors-virtual-0 look sensible and they change
> reasonably under load.
Good. I guess that part working wasn't so surprising after all :)
Regarding how we proceed from here, I think the main question is whether a
workaround should be limited to only specific machines (maybe detected using
DMI data), and if so, to specific WMI object types and instances (cf.
hp_wmi_get_wobj(), though limiting on instance number would be fragile if
BIOS updates change instance numbering). Other questions are how thoroughly
to validate UTF-16 in a buffer and whether to convert to UTF-8 internally.
For what it's worth, I personally don't see much value in doing much more than
a machine-limited workaround for now. To me it's clear that this UTF-16 corner
case is a BIOS bug and its consequences are minimal once a workaround is in
place.
Thoughts? Also, if you'd prefer to let me handle it, I'd be glad to write a
patch myself.
[1] https://github.com/vinaypamnani/wmie2
