On Monday 10 November 2008 06:58:56 pm Matthew Garrett wrote:
> I've now had confirmation from multiple sources that Vista still uses
> the 32-bit addresses for the GPE blocks.
Are you sure that Windows Server implementations also use 32-bit addresses?
Are you sure that upcoming Windows implementations will always use 32-bit
addresses?
Do all X86 machines support Windows or could there be machines, especially
servers which only support Mac OS, Solaris/Linux or other OSes which stick to
the spec which you break with this change?
> We're actually seeing the same
> bug on some currently shipping machines
Which ones?
> , so again I'm going to suggest
> that the blacklist model isn't going to scale and we should just behave
> like Windows. How about this patch instead? It does some sanity
> checking, so I doubt that there's any way it could break a legitimate
> system. I've left IA64 as-is because it seems more likely that there'd
> be a requirement for 64-bit setups there.
If at all, this should not be added for .28, but for .29 and stay in
linux-next for a while.
I wonder why all (hmm, hard to say, at least a lot) recent machines have valid
64 bit addresses.
I also disagree with violating the spec unconditionally, breaking machines
which would stick to it. It's likely that machines do not get a latest
mainline kernel tests. Once this change is in distributions and machines do
break, people are busted. There should at least be a boot param to switch
back.
We might come away with it. But I have the strong feeling that there are
machines running better using 32-bit and machines running better with 64-bit
addresses used.
Thomas
> Signed-off-by: Matthew Garrett <mjg@xxxxxxxxxx>
>
> ---
>
> Are there even any ACPI platforms where a system io address can be
> greater than 32 bits? It's limited to 16 bits on x86, so I *really*
> don't think this is going to break anything. The FADTs I've checked from
> Thinkpads all seem to have valid 32-bit addresses even using the one
> obtained from the XSDT.
>
> diff --git a/drivers/acpi/events/evgpeblk.c
> b/drivers/acpi/events/evgpeblk.c index 73c058e..eed35d7 100644
> --- a/drivers/acpi/events/evgpeblk.c
> +++ b/drivers/acpi/events/evgpeblk.c
> @@ -1107,6 +1107,32 @@ acpi_status acpi_ev_gpe_initialize(void)
> */
>
> /*
> + * The ACPI specification says that we should use the 64-bit
> + * address offset for the GPE blocks if it exists. However,
> + * Windows uses the legacy address. Various vendors have left
> + * incorrect values in the 64-bit field, which then causes
> + * problems later. Since the vast majority of machines have
> + * never been tested with an OS that uses the 64-bit value by
> + * default, we should behave like Windows and ignore the spec
> + * by only using the 64-bit address if it contains something
> + * that can't be represented in the legacy field. Since system
> + * io space is only 16 bits on x86, this should be entirely
> + * safe.
> + */
> +
> +#ifdef CONFIG_X86
> + if (acpi_gbl_FADT.gpe0_block &&
> + acpi_gbl_FADT.xgpe0_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
> + acpi_gbl_FADT.xgpe0_block.address =
> + (u64)acpi_gbl_FADT.gpe0_block;
> +
> + if (acpi_gbl_FADT.gpe1_block &&
> + acpi_gbl_FADT.xgpe1_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
> + acpi_gbl_FADT.xgpe1_block.address =
> + (u64)acpi_gbl_FADT.gpe1_block;
> +#endif
> +
> + /*
> * Determine the maximum GPE number for this machine.
> *
> * Note: both GPE0 and GPE1 are optional, and either can exist without
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
