Now that release is done I am not opposed to this.
On Tue, Aug 31, 2010 at 03:58:43PM +0200, Niklas Hallqvist wrote:
> On 08/08/10 12:18, Mark Kettenis wrote:
> >> Date: Sun, 8 Aug 2010 17:57:20 +0800
> >>
> >> Is there someone who would be willing to test this diff on a physical
> >> machine th
On 08/08/10 12:18, Mark Kettenis wrote:
>> Date: Sun, 8 Aug 2010 17:57:20 +0800
>>
>> Is there someone who would be willing to test this diff on a physical
>> machine that currently reports "ACPI control unavailable" in dmesg,
>> e.g.
>>
>> acpi0 at bios0: rev 2, ACPI control unavailable
> I'm pr
> Date: Sun, 8 Aug 2010 17:57:20 +0800
>
> Is there someone who would be willing to test this diff on a physical
> machine that currently reports "ACPI control unavailable" in dmesg,
> e.g.
>
> acpi0 at bios0: rev 2, ACPI control unavailable
I'm pretty sure such hardware does not exist, at least
Is there someone who would be willing to test this diff on a physical
machine that currently reports "ACPI control unavailable" in dmesg,
e.g.
acpi0 at bios0: rev 2, ACPI control unavailable
If you have such a machine, but you are not able to test the diff, I'd
still be interested to know the mod
Some ACPI systems do not support legacy mode and do not provide an smi_cmd
port within the FADT. This is mentioned in the following:
http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf (p119, SMI_CMD)
http://wiki.osdev.org/ACPI (Switching to ACPI Mode)
OpenBSD aborts ACPI initialisation if the FADT do
