[BKPATCH] ACPI for 2.4

[BKPATCH] ACPI for 2.4

[Len Brown]

Hi Marcelo, please do a 

	bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.25

	the AML param fix is in 2.6 -- the others changes
	are Asus and Toshiba model specific.

thanks,
-Len

ps. a plain patch is also available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.25/acpi-20040116-2.4.25.diff.gz

This will update the following files:

 drivers/acpi/asus_acpi.c           |  753 +++++++++++++++----------
 drivers/acpi/dispatcher/dsmthdat.c |   10 
 drivers/acpi/pci_irq.c             |   12 
 drivers/acpi/toshiba_acpi.c        |   81 +-
 4 files changed, 533 insertions(+), 323 deletions(-)

through these ChangeSets:

<sziwan@hell.org.pl> (04/02/06 1.1063.46.71)
   [PATCH] acpi4asus update from Karol 'sziwan' Kozimor
   
   The attached patch updates the acpi4asus driver to 0.27 through the
   following changes:
   - add support for M1300A, S5200N, L8400L,
   - remove WLED support for certain models, since it is not controlled
by
     AML,
   - add LCD backlight switching for L2E / L3H,
   - C99 initializers,
   - generic LED handlers,
   - the output of ASYM method to provide battery state information
(might be
     more accurate under certain conditions) in /proc/acpi/asus/info,
   - fix several oddities, various clean-ups and other minor changes.
   
   The patch itself is quite big, which is mostly due to the C99
initializers
   and the fact that diff doesn't like moving code around.
   
   This has been compile-tested in various configurations, the
substantive
   changes were discussed on the acpi4asus mailing list.
   
   The code should apply to current bk (both for 2.4 and 2.6). The patch
is
   also available here:
   http://hell.org.pl/~sziwan/asus/acpi4asus-0.26-0.27.diff
   
   Thanks to all the contributors (notably Pontus Fuchs) to this
release.

<john@neggie.net> (04/02/05 1.1063.46.70)
   [PATCH] toshiba_acpi 0.17 from John Belmonte
   
   Fix remote chance of invalid buffer access in write_video.
   Support alternate HCI method path (recent "Phoenix BIOS" Toshiba's).
   Signal more proc-write errors.
   On proc-reads, report errors via printk instead of proc output.
   Add log level and driver name prefix to all printk's.
   Add missing __init and __exit function attributes.
   Be explicit about vars for which code relies on zero-init of BSS.

<len.brown@intel.com> (04/02/05 1.1063.46.69)
   [ACPI] fix IA64 build warning
   from Martin Hicks

<len.brown@intel.com> (04/01/30 1.1293)
   [ACPI] proposed fix for AML parameter passing from Bob Moore
     http://bugzilla.kernel.org/show_bug.cgi?id=1766

Re: [BKPATCH] ACPI for 2.4

[Willy Tarreau]

Hi Len,

On Sat, Feb 07, 2004 at 04:10:24AM -0500, Len Brown wrote:
> 	bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.25
> 
> 	the AML param fix is in 2.6 -- the others changes
> 	are Asus and Toshiba model specific.

I encountered something strange that I still cannot explain. I have two
machines, one athlon-based VAIO notebook and one P4-based supermicro 1U
server, which don't poweroff when I halt them or send them a Sysrq-O. At
first, I only noticed this on the VAIO so I thought that something changed
in ACPI recently, because it was OK around 2.4.21 or 2.4.22 with acpi patch
from around 09/2003, but I believe that the problem appeared when I used
2.4.23 + the acpi-20031203 patch, which is now included in 2.4.25-rc1. But
then I discovered that I can poweroff both the notebook and the 1U by a
simple "echo 5 >/proc/acpi/sleep".

So I've added printk's into acpi_power_off(), and I see that the system
doesn't return from acpi_enter_sleep_state_prep(S5), which itself hangs
on the call to acpi_evaluate_object(NULL, "\\_PTS",...). If I comment
out this line, it now goes on through the next calls, then normally leaves
acpi_enter_sleep_state_prep(), then powers off correctly. I have not tested
yet you very latest patch, but I don't think it would change anything.

Do you have any idea ? What can I provide to help in resolving this problem ?

Regards,
Willy

Re: [BKPATCH] ACPI for 2.4

[Willy Tarreau]

Replying to myself...

On Sun, Feb 08, 2004 at 09:20:59AM +0100, Willy Tarreau wrote:
> 
> So I've added printk's into acpi_power_off(), and I see that the system
> doesn't return from acpi_enter_sleep_state_prep(S5), which itself hangs
> on the call to acpi_evaluate_object(NULL, "\\_PTS",...). If I comment
> out this line, it now goes on through the next calls, then normally leaves
> acpi_enter_sleep_state_prep(), then powers off correctly.

Searching for _PTS on google directed me to the ACPI spec. I found in
section 9 that _PTS (prepare to sleep) is only used for S1-S4, but 9.1.7
says that it should be called for S5 too. I suspect that depending on the
paragraph they read, hardware makers do or don't implement _PTS(S5) correctly
:-/ BTW, 9.1.5 says that "S5 is not a sleeping state, but a G2 state". So it
might seem logical not to call something named "prepare to sleep" in this
case.

I checked the last working version. It was acpi-030424 + the two little
patches I sent to you at this time and which were merged. This version
called _PTS and _GTS in acpi_enter_sleep_state_prep(), while now we call
_PTS, _GTS, and _SI._SST. So I'm amazed that in previous version, _PTS
worked and that it does not anymore !

Regards,
Willy

[RFC] ACPI power-off on P4 HT

[Willy Tarreau]

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

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

[Len Brown]

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
> 

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

[Zwane Mwaikambo]

On Wed, 25 Feb 2004, Len Brown wrote:

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

set_cpus_allowed?

> 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.

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

[Gregory Finch]

My workstation has a problem with power-off as well. It is a dual P3
(Katmai) Epox motherboard with Intel 440BX chipset. About 50% of the
time I try powering off the system, the NMI watchdog fires detecting
CPU1 as locked up. I would be willing to try any patches that may fix
this, as I miss being able to let my workstation shutdown on it's own.

Thanks,
-Greg

On Wed, Feb 25, 2004 at 02:55:01AM -0500, Len Brown wrote:
> 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
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Willy Tarreau]

Hello Greg,

On Wed, Feb 25, 2004 at 11:56:09PM -0800, Gregory Finch wrote:
> My workstation has a problem with power-off as well. It is a dual P3
> (Katmai) Epox motherboard with Intel 440BX chipset. About 50% of the
> time I try powering off the system, the NMI watchdog fires detecting
> CPU1 as locked up. I would be willing to try any patches that may fix
> this, as I miss being able to let my workstation shutdown on it's own.

OK, could you try this patch ? please note that it's just a test patch, not
one which should be applied to any tree !
If it hangs, it may be interesting to know what is the last line displayed.
Please halt your system out of X11 to see console messages.
It works for me on the P4 HT 100% of the time now.

Cheers,
Willy

--- linux-2.4.25/drivers/acpi/system.c	Wed Nov 19 15:31:22 2003
+++ linux-2.4.25-wt1/drivers/acpi/system.c	Mon Feb 23 20:03:27 2004
@@ -89,12 +89,69 @@
    -------------------------------------------------------------------------- */
 
 #ifdef CONFIG_PM
+#include <asm/smpboot.h>
 
 static void
 acpi_power_off (void)
 {
+	static int reboot_cpu = -1;
+	int cpuid;
 	if (unlikely(in_interrupt())) 
 		BUG();
+#ifdef CONFIG_SMP
+	
+	cpuid = GET_APIC_ID(apic_read(APIC_ID));
+	printk(KERN_EMERG "running on cpu %d\n", cpuid);
+
+	if (cpuid != boot_cpu_physical_apicid) {
+printk(KERN_EMERG "within if(cpuid)\n");
+
+		/* check to see if reboot_cpu is valid 
+		   if its not, default to the BSP */
+		if ((reboot_cpu == -1) ||  
+		      (reboot_cpu > (NR_CPUS -1))  || 
+		      !(phys_cpu_present_map & apicid_to_phys_cpu_present(cpuid)))
+			reboot_cpu = boot_cpu_physical_apicid;
+
+		/* re-run this function on the other CPUs
+		   it will fall though this section since we have 
+		   cleared reboot_smp, and do the reboot if it is the
+		   correct CPU, otherwise it halts. */
+		if (reboot_cpu != cpuid)
+			smp_call_function((void *)acpi_power_off , NULL, 1, 0);
+	}
+printk(KERN_EMERG "after if(cpuid)\n");
+
+	/* if reboot_cpu is still -1, then we want a tradional reboot, 
+	   and if we are not running on the reboot_cpu,, halt */
+	if ((reboot_cpu != -1) && (cpuid != reboot_cpu)) {
+printk(KERN_EMERG "halting this cpu: %d\n", cpuid);
+		for (;;)
+		__asm__ __volatile__ ("hlt");
+	}
+	/*
+	 * Stop all CPUs and turn off local APICs and the IO-APIC, so
+	 * other OSs see a clean IRQ state.
+	 */
+printk(KERN_EMERG "before smp_send_stop()\n");
+	smp_send_stop();
+printk(KERN_EMERG "after smp_send_stop()\n");
+#elif CONFIG_X86_LOCAL_APIC
+	if (cpu_has_apic) {
+printk(KERN_EMERG "before __cli()\n");
+		__cli();
+printk(KERN_EMERG "between __cli() and disable_local_APIC()\n");
+		disable_local_APIC();
+printk(KERN_EMERG "between disable_local_APIC() and __sti()\n");
+		__sti();
+printk(KERN_EMERG "after __cli()\n");
+	}
+#endif
+#ifdef CONFIG_X86_IO_APIC
+printk(KERN_EMERG "before disable_IO_APIC()\n");
+	disable_IO_APIC();
+printk(KERN_EMERG "after disable_IO_APIC()\n");
+#endif
 	acpi_enter_sleep_state_prep(ACPI_STATE_S5);
 	ACPI_DISABLE_IRQS();
 	acpi_enter_sleep_state(ACPI_STATE_S5);

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

[Stian Jordet]

tor, 26.02.2004 kl. 11.57 skrev Willy Tarreau:
> OK, could you try this patch ? please note that it's just a test patch, not
> one which should be applied to any tree !
> If it hangs, it may be interesting to know what is the last line displayed.
> Please halt your system out of X11 to see console messages.
> It works for me on the P4 HT 100% of the time now.

Hi Willy,

Do you have a similar patch for 2.6?

Best regards,
Stian

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

[Willy Tarreau]

On Thu, Feb 26, 2004 at 01:28:49PM +0100, Stian Jordet wrote:
> tor, 26.02.2004 kl. 11.57 skrev Willy Tarreau:
> > OK, could you try this patch ? please note that it's just a test patch, not
> > one which should be applied to any tree !
> > If it hangs, it may be interesting to know what is the last line displayed.
> > Please halt your system out of X11 to see console messages.
> > It works for me on the P4 HT 100% of the time now.
> 
> Hi Willy,
> 
> Do you have a similar patch for 2.6?

No, but since Marcelo recently told me that acpi_power_off() was the same in
2.4 and 2.6, I think it should apply without much difficulties. A dirty gpm
cut-n-paste in vi should be enough ;-)

Regards,
Willy

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

[Pavel Machek]

Hi!

> 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

Well, to be usefull for suspend, also "opposite" code would be
neccessary (enable apic, restart other cpus).
And yes, that would be very welcome.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

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

[Stian Jordet]

tor, 26.02.2004 kl. 14.07 skrev Willy Tarreau:
> On Thu, Feb 26, 2004 at 01:28:49PM +0100, Stian Jordet wrote:
> > Hi Willy,
> > 
> > Do you have a similar patch for 2.6?
> 
> No, but since Marcelo recently told me that acpi_power_off() was the same in
> 2.4 and 2.6, I think it should apply without much difficulties. A dirty gpm
> cut-n-paste in vi should be enough ;-)

Well, I cut-n-paste it into drivers/acpi/sleep/poweroff.c (which must
have been the place it fits in 2.6). Get this compile failures:

drivers/acpi/sleep/poweroff.c: In function `acpi_power_off':
drivers/acpi/sleep/poweroff.c:30: warning: implicit declaration of
function `apicid_to_phys_cpu_present'
drivers/acpi/sleep/poweroff.c:30: error: invalid operands to binary &
drivers/acpi/sleep/poweroff.c:69: warning: implicit declaration of
function `disable_IO_APIC'
make[3]: *** [drivers/acpi/sleep/poweroff.o] Error 1
make[2]: *** [drivers/acpi/sleep] Error 2
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2

But I'm sure a patch like yours for 2.6 would have fixed my, since using
a non-smp kernel works everytime :) Anyway, thanks for your efforts,
hope someone will get this fixed soon :)

Best regards,
Stian