Re: ACPI call for testing

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Wed, Aug 25, 2010 at 03:57:32PM +0200, Wolfgang Solfrank wrote:
> Ok, turns out that interrupts aren't really blocked, but that the CPU
> has a bug (AMD erratum #400) that makes it not wake up from C1E or C3
> sleep state from a lapic timer interrupt. 

We have been pondering with this some time now. The conclusion from the last
round was that there seems to be no way to "overcome" the AMD C1E easily
without having what is needed for functional C-states generally.

With the "normal" C3-state -- which is really just renamed as C1E by AMD --
the operating system has some control over when to enter this deep sleep-
state and what to do with the APIC/TSC timer issues. This is impossible
with AMD C1E.

> So it's not really an ACPI problem, but a result from the side effect that
> with ACPI the cpu is sent into some sleep state in the idle loop.

While the BIOS may enable C1E when ACPI is present, my impression from the
AMD BKDGs is that the C1E-state is entered when all cores are in HALT,
supposedly with or without ACPI, at least in theory. On AMD systems
x86_cpu_idle_halt() is the default cpu_idle(9) and thus BIOS-triggered C1E
is right there waiting to be entered.

> Disabling the use of lapic_clockintr, i.e. using the i8254 for clock
> interrupts, makes the system more or less work with ACPI.  However,
> it's still a bit slow, as building my custom kernel requires 1:31 with
> ACPI enabled, while without ACPI the system does it in 0:55.

This was also one of the workarounds suggested by @cegger for the errata #400.

But I guess your options at the moment are: disable ACPI, check whether it
might be possible to disable C1E from the BIOS, or wait for a firmware
update if that is not the case :-(.

- Jukka.