alpm(4) I/O range is claimed by ACPI
Bruce M Simpson
bms at incunabulum.net
Sat Sep 13 02:13:35 UTC 2008
John Baldwin wrote:
> Umm, ACPI will allow children devices to allocate their resources out of
> the "sysresource" pool. IPMI has to do this on some systems where ACPI
> claims the IPMI I/O ports as a system resource.
But surely if alpm(4) were to attach to such a range in this way, it
would need to be a child of the acpi bus device, yes? The IPMI driver
probes for a specific ACPI ID in the DSDT.
PCI ID looks like this:
alpm0 at pci0:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9
So I grabbed the M1543 datasheet off the web and looked in CSR space.
Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the
PMU. The function is still visible, it just has no active I/O mappings.
No wonder alpm(4) does not attach.
I tried looking for this device in the DSDT, I don't see anything which
obviously resembles it. The equivalent Linux driver has a means of
forcing the mapping to be set up if it isn't available:
It looks like there used to be a means of doing this in the FreeBSD
driver but it got nuked. And that ASUS didn't much care about power
management support in this machine...
Oh well! I know ichsmb works on at least one machine that I have.
More information about the freebsd-stable