On Sat, Jan 03, 2026 at 08:17:07PM -0800, Mike Larkin wrote:
> On Sat, Jan 03, 2026 at 11:20:04AM +0000, requiem. wrote:
> > I managed to find and re-flash the stock F.16 BIOS version from HP
> > (usually don't trust those 3rd party "driver installer" sites but it
> > came through this time). The whitelist is back (yay, I guess), but with
> > the wi-fi card removed I've managed to run some more tests. As I opened
> > up the case I also installed a new CMOS battery, just to be safe.
> >
> > On Wed, 31 Dec 2025 10:28:07 +0000 Crystal
> > Kolipe <[email protected]> wrote:
> >
> > > > [ 1.023181] wmihp0 at acpiwmi0: HP WMI mappings
> > > > [ 1.023181] wmihp0: autoconfiguration error: failed to get data
> > > > for event 0x80: AE_BAD_DATA
> >
> > This seems to be the case also with the stock BIOS. dmesg.boot on
> > NetBSD still has the same error after flashing the stock F.16 BIOS.
> >
> > > > Just brwowsing through the dmesg I notice the CMOS clock is way off.
> > > > Possibly a dead battery. Would that cause issues?
> > >
> > > Probably not the cause of this specific problem, but in general a
> > > faulty CMOS battery can potentially cause all sorts of non-obvious
> > > and difficult to identify issues, so if you can replace it that would
> > > probably be a good idea.
> >
> > I did, well, didn't seem to make a difference. Clock keeps time at
> > least.
> >
> > > For testing purposes only and to try to gather more information, can
> > > you try booting the OpenBSD installer and disabling the acpi driver
> > > in the bootloader?
> > >
> > Dropping to config with `boot -c` and then calling `disable acpi` gets
> > me a working installer. Attaching a dmesg for this one too.
> >
>
> Sorry, I'm lost here.
>
> To summarize:
>
> 1. you had a configuration that worked before.
>
> 2. you changed a bunch of devices and flashed some hacked/sketchy bios
>
> 3. things broke
As I understand it, that is indeed what the OP did.
> I don't understand the dmesg pastes above, they don't look like openbsd.
The quoted dmesg extract is from an, (apparently working), NetBSD install,
since he couldn't boot the OpenBSD installer with the non-standard bios.
I suggested that he tested booting OpenBSD with the modified bios and with
ACPI disabled in the bootloader so that we could see whether the bios
modifications only broke ACPI or whether there is further unexpected
breakage.
If, as I suspect, it's just a funky ACPI table in the modified bios, it might
be practical and indeed desirable to fix parsing of it in OpenBSD. On the
other hand, if there is futher breakage then the modified bios is probably a
waste of time.
By the way, look at the ACPI table from NetBSD:
On Tue, Dec 30, 2025 at 11:41:05PM +0000, requiem. wrote:
> [ 1.000004] ACPI: RSDP 0x00000000000F9C50 000014 (v00 ACPIAM)
> [ 1.000004] ACPI: RSDT 0x000000003F7B0000 000040 (v01 HPQOEM SLIC-CPC
> 20100430 MSFT 00000097)
> [ 1.000004] ACPI: FACP 0x000000003F7B0200 000084 (v02 HPQOEM SLIC-CPC
> 20100430 MSFT 00000097)
> [ 1.000004] ACPI: DSDT 0x000000003F7B0430 008042 (v01 361A0 361A0F16
> 00000F16 INTL 20060317)
> [ 1.000004] ACPI: FACS 0x000000003F7BE000 000040
> [ 1.000004] ACPI: ???? 0x00000000FFFD5600 FFFFFFFF (v255 ?????? ????????
> FFFFFFFF ???? FFFFFFFF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This looks suspicious.
> [ 1.000004] ACPI: APIC 0x000000003F7B0390 00005C (v01 HPQOEM APIC1004
> 20100430 MSFT 00000097)
> [ 1.000004] ACPI: MCFG 0x000000003F7B03F0 00003C (v01 HPQOEM OEMMCFG
> 20100430 MSFT 00000097)
> [ 1.000004] ACPI: OEMB 0x000000003F7BE040 000224 (v01 HPQOEM OEMB1004
> 20100430 MSFT 00000097)
> [ 1.000004] ACPI: ASF! 0x000000003F7B8480 000075 (v32 LEGEND I865PASF
> 00000001 INTL 20060317)
> [ 1.000004] ACPI: SSDT 0x000000003F7BEBE0 0004F0 (v01 PmRef CpuPm
> 00003000 INTL 20060317)
> [ 1.000004] ACPI: 2 ACPI AML tables successfully acquired and loaded
The previous email included two attachments, which seem to be:
* A regular boot of bsd.rd with the stock vendor bios.
* A boot of bsd.rd with acpi disabled, with the modifier bios.
However, I'm not 100% sure that the boot with acpi disabled was indeed with
the modified bios. The version numbers and strings reported by bios0 are the
same in both cases, so it would be useful if the OP could confirm that the
second dmesg is indeed from a boot with the modified bios.
> I would recommend you start undoing the changes you made one at a time, and
> tell us which change breaks things. And if it's the hacked/sketchy bios then
> you might be SOL. It's too hard to diagnose "I changed a bunch of things
> and now nothing works, please help".
The changes he mentions are swapping out the SSD, and replacing the wifi card.
The replacement SSD is very unlikely to be causing these kinds of issues.
The neither OpenBSD dmesg mentions the atheros chipset based wifi card, so I'm
assuming that it was removed for testing, (especially since it doesn't work
with the stock bios, and it was listed in the NetBSD dmesg).
