It was <2023-10-31 wto 07:00>, when James Seo wrote:
> 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.
Indeed there is one
--8<---------------cut here---------------start------------->8---
# grep -r "" /sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/possible_status:2
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/possible_severity:5
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/category:4
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/source_class:HPBIOS_BIOSEvent
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/source_namespace:root\wmi
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/description:BIOS Settings
/sys/kernel/debug/hp-wmi-sensors-0/platform_events/0/name:4
--8<---------------cut here---------------end--------------->8---
> I'm also curious how it looks in Windows (I used WMI Explorer [1] during
> development). The WMI namespace should be "\\.\root\HP\InstrumentedBIOS".
I'll see if I can find such machine with Windows. It may take a few days
thou.
>> 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?
I am no expert regarding x86 platforms and I don't know how often bugs
like this happen and if making it more generic makes sens. Maybe.
My solution would be to add a module option, let's name it `quirks` and
make it a bit field for future use, that enables the workaound. Plus an
additional error message when probe fails to suggest user to add the
option to kernel command line or whatever file that contains module
options. A nice touch would be to detect if the workaround is still
required.
Thouths.
> Also, if you'd prefer to let me handle it, I'd be glad to write a
> patch myself.
I am fine with that, I know a bit more about device-tree than about ACPI
(-; and PCs in general. I'll be glad to test the patch thou.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
Attachment:
signature.asc
Description: PGP signature
