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 
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





More information about the freebsd-stable mailing list