ACPI on Acer TravelMate 2483WXMi

John Baldwin jhb at
Mon Jul 16 12:43:53 UTC 2007

On Friday 13 July 2007 11:52:05 am Oleg Lomaka wrote:
> Hello.
> Could you please help to clear out some acpi problems on this laptop.
> When boot with acpi enabled, msk and ath interfaces doesn't work. And when
> acpi is disabled, msk is staring up, but ath still doesn't.
> Following is dmesg with acpi enabled.
> Also there are some additional info:
> pciconf -lv:
> acpidump -dt:
> dmesg with acpi disabled:
> dmesg with acpi enabled (the same as inlined):

This is why msk(4) doesn't work when ACPI is disabled:

> pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
> pcib1:   secondary bus     2
> pcib1:   subordinate bus   2
> pcib1:   I/O decode        0x0-0x0
> pcib1:   memory decode     0x0-0x0
> pcib1:   prefetched decode 0x0-0x0
> pci2: <ACPI PCI bus> on pcib1
> pci2: physical bus=2
> found->    vendor=0x11ab, dev=0x4352, revid=0x14
>     bus=2, slot=0, func=0
>     class=02-00-00, hdrtype=0x00, mfdev=0
>     cmdreg=0x0000, statreg=0x4010, cachelnsz=16 (dwords)
>     lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>     intpin=a, irq=11
>     powerspec 2  supports D0 D1 D2 D3  current D0
>     MSI supports 2 messages, 64 bit
>     map[10]: type 1, range 64, base 00000000, size 14, memory disabled
>     map[18]: type 4, range 32, base 00000000, size  8, port disabled
> pcib1: matched entry for 2.0.INTA
> pcib1: slot 0 INTA hardwired to IRQ 16
> mskc0: <Marvell Yukon 88E8038 Gigabit Ethernet> irq 16 at device 0.0 on pci2
> pcib1: mskc0 requested unsupported memory range 0x0-0xffffffff (decoding
> 0x0-0x0, 0x0-0x0)
> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
> mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000
> mskc0: unknown device: id=0xff, rev=0x0f
> device_attach: mskc0 attach returned 6

The BIOS hasn't assigned resources for the PCI-PCI bridge and FreeBSD isn't 
smart enough to alloc resources from the parent for this case (this one 
should be solvable in FreeBSD w/o too much pain since it's a matter of 
allocating resources for the bus rather than extending an existing resource).

As far as ath(4), if you fix this problem then ath(4) on ACPI will likely run 
into the HAL issue that it runs into with ACPI disabled.  That is a separate 

John Baldwin

More information about the freebsd-acpi mailing list