http://bugzilla.kernel.org/show_bug.cgi?id=12826 ------- Comment #24 from anonymous@xxxxxxxxxxxxxxxxxxxx 2009-03-07 17:37 ------- Reply-To: mjg@xxxxxxxxxx On Sun, Mar 08, 2009 at 02:06:33AM +0100, Maciej Piechotka wrote: > Somehow. It keeps system at 70-80 C but on 2.6.29 it freezes the > computer when I log into Gnome (it seems that gdm is not enought and it > occures after few minutes) - i.e. I cannot move pointer, change VT nor > even ping the system (I use in-kernel radeon driver and Radeon Xpress > 200M card RC410). Ok. That sounds like a separate bug. Can you try with this patch and no kernel argument? commit 546be50e225261e8379731008cdfec336348f048 Author: Matthew Garrett <mjg@xxxxxxxxxx> Date: Sun Mar 8 01:34:03 2009 +0000 Use 32-bit FADT values on X86 The ACPI specification says that we should use the 64-bit address offsets contained within the FADT if they exist. 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. diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c index 3636e4f..ad0e858 100644 --- a/drivers/acpi/acpica/tbfadt.c +++ b/drivers/acpi/acpica/tbfadt.c @@ -361,9 +361,28 @@ static void acpi_tb_convert_fadt(void) ACPI_ADD_PTR(struct acpi_generic_address, &acpi_gbl_FADT, fadt_info_table[i].address64); - /* Expand only if the 64-bit X target is null */ + /* + * The ACPI specification says that we should use the + * 64-bit address offsets if they 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. We also extend + * the 32-bit value into the 64-bit one if no 64-bit + * address is provided. + */ - if (!target64->address) { + if (!target64->address +#ifdef CONFIG_X86 + || (target64->space_id == ACPI_ADR_SPACE_SYSTEM_IO) +#endif + ) { /* The space_id is always I/O for the 32-bit legacy address fields */ -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
