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:
[EMAIL PROTECTED]:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9
rev=0x00 hdr=0x00
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:
http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3
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.
cheers
BMS
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
