[ACPI] Re: [RFC] ACPI power-off on P4 HT

[Len B. <len...@in...>]

Willy,
I do think we need a generic way to be sure that certain routines are
run only on cpu0.

I don't see it in the ACPI spec, but it seems that on some platforms,
some register accesses (such as writing to the sleep control reg) are
reliable only when accessed from cpu0.

This issue has been with us for some time:
http://bugzilla.kernel.org/show_bug.cgi?id=1141

I am hopeful that the prepare-shutdown sequence you suggest below will
not be necessary.

thanks,
-Len


On Wed, 2004-02-25 at 02:00, Willy Tarreau wrote:
> Hi Len & Marcelo,
> 
> as I previously said, the patch I sent which fixes the poweroff on my VAIO is
> not enough to shut down the supermicro P4 HT. So I borrowed some code from
> machine_restart() to try to :
>   - disable APIC  => was not enough, but I must retry on the VAIO
>   - stop the second CPU => was not enough either
>   - bounce on boot_cpu and stop the others => it did work.
> 
> So I think that ACPI is not SMP-proof nor HT-proof on some hardware. My new
> problem is that I feel like the code I have included in acpi_power_off() to
> do this is a bit too much x86 specific, so I'd like to move this to
> arch/i386/kernel/process.c with all the rest, but I don't know how to cut
> this. I think that a general function such as machine_prepare_shutdown() or
> something like this would be useful and could be shared by both ACPI and
> machine_restart(). It would basically to everything that is needed in such
> a case :
>   - on SMP, bounce on boot_cpu, then halt the current CPU if != boot_cpu
>   - on SMP, stop all other CPUs
>   - on UP, disable IOAPIC
>   - disable local APIC
> 
> I suspect that this function would be useful for some suspend cases, but I'm
> not sure. My other problem is to know what we should do then with other
> arches. Create an identical function for everyone, or just call it from
> ACPI on CONFIG_X86, or even add a CONFIG_MACHINE_PREPARE_SHUTDOWN ?
> 
> I need some feedback here. Any suggestions ?
> 
> Regards,
> Willy
>