Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes(Re: 2.6.27-rc8+ - first impressions)

[Maciej W. Rozycki]

On Mon, 6 Oct 2008, Ingo Molnar wrote:

> i think it was caused by this stream of IO-APIC changes:
> 
>  49a66a0: x86: I/O APIC: Always report how the timer has been set up
>  17c4469: x86: I/O APIC: Include <asm/i8259.h> required by some code
>  593f4a7: x86: APIC: remove apic_write_around(); use alternatives
>  ce8b06b: x86: I/O APIC: remove an IRQ2-mask hack
>  af17478: x86: I/O APIC: Never configure IRQ2
>  c88ac1d: x86: L-APIC: Always fully configure IRQ0
>  1baea6e: x86: L-APIC: Set IRQ0 as edge-triggered
> 
> Rafael/Maciej, which of these is causing it? ce8b06b ("x86: I/O APIC: 
> remove an IRQ2-mask hack")?

 None of the above.  This:

691874f: x86: I/O APIC: timer through 8259A second-chance

This change has fixed a problem with the timer for a lot of systems and 
permitted the removal of a bunch of horrible hacks we used to have in our 
I/O-APIC/timer code, including a command-line override parameter, needed 
so that some systems would boot at all.

 This single instance of a piece of some HP gear being twisted beyond 
belief is IMO a minor annoyance and price to pay compared to the gain.  
Please note that apart from the DSDT being buggy on this machine, it has 
an incorrect IRQ 0 override in the ACPI table pointing to the pin #2 of 
the I/O APIC, which is in fact routed to the output of the master 8259A.  
Additionally the pin #0 of the I/O APIC which is indeed routed to the 
output of the 8254 does not receive any interrupts, presumably because of 
some misconfiguration during BIOS initialisation.  So in fact this machine 
suffers from three configuration problems at once of which all add up to 
the end result we can observe.

> Current theory is that this specific flavor of BIOS on HP / AMD / Turion 
> laptops (no other type is known to be affected at the moment) somehow 
> detects the IO-APIC masking patterns and uses an SMI quirk to change the 
> ACPI thermal trip point to very low settings, and thus confusing cpufreq 
> to (correctly) go into a very slow frequency.

 It is not just theory.  I did actually analyse the AML code coming from 
the broken DSDT and found the responsible snippets.  See: 
http://lkml.org/lkml/2008/6/20/442 for a reference.  No SMI is involved 
here -- this is native ACPI operation -- Linux calls these snippets 
explicitly as required by the ACPI spec for various actions.

> Activating the quirk works this around. Should we perhaps default to 
> this 'quirk' enabled by default?

 It will break many if not most of the systems out there which have the 
PIT (rather than the master 8259A) wired to the pin #2 of the I/O APIC 
and correctly reported as such with an ACPI IRQ override.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/