ACPI for 2.4

BKPATCH Len Brown 6 participants 12 messages Feb 7, 2004 – Mar 1, 2004 2 messages not in the archive ACPI

lore

Share & tools

lore

Len Brown

author

2004-02-07 09:10 UTC #0 lore raw

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-DETuoxkZsSqrDJvtcaxF/[email protected]> (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.

<[email protected]> (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.

<[email protected]> (04/02/05 1.1063.46.69)
[ACPI] fix IA64 build warning
from Martin Hicks

<[email protected]> (04/01/30 1.1293)
[ACPI] proposed fix for AML parameter passing from Bob Moore

     http://bugzilla.kernel.org/show_bug.cgi?id=1766

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Willy Tarreau

2004-02-08 08:20 UTC #1 lore raw

Hi Len,

Quoted 4 lines · Len Brown

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

Willy Tarreau

2004-02-08 09:08 UTC #2 lore raw

Replying to myself...

Quoted 6 lines · Willy Tarreau

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

Willy Tarreau

2004-02-25 07:08 UTC #5 lore raw

[RFC] ACPI power-off on P4 HT

In reply to a message not in the archive

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

Len Brown

author

2004-02-25 07:55 UTC #6 lore raw

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

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

Quoted 27 lines · 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 ?

Quoted 5 lines

I need some feedback here. Any suggestions ?
Regards,
Willy

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Zwane Mwaikambo

2004-02-25 16:13 UTC #7 lore raw

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

Quoted 3 lines · Len Brown

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

set_cpus_allowed?

Quoted 9 lines

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.

Gregory Finch

2004-02-26 07:56 UTC #8 lore raw

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

In reply to Len Brown

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

Quoted 52 lines · 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
Quoted 27 lines · 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 ?
Quoted 5 lines
I need some feedback here. Any suggestions ?
Regards,
Willy

Quoted 5 lines

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

Willy Tarreau

2004-02-26 10:57 UTC #9 lore raw

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

Hello Greg,

Quoted 5 lines · 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.

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

drivers/acpi/system.c +57 -0

@@ -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);

Stian Jordet

2004-02-26 12:28 UTC #10 lore raw

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

tor, 26.02.2004 kl. 11.57 skrev Willy Tarreau:

Quoted 5 lines

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

Willy Tarreau

2004-02-26 13:07 UTC #11 lore raw

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

Quoted 10 lines · Stian Jordet

tor, 26.02.2004 kl. 11.57 skrev Willy Tarreau:
Quoted 5 lines
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

Stian Jordet

2004-02-26 13:29 UTC #12 lore raw

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

tor, 26.02.2004 kl. 14.07 skrev Willy Tarreau:

Quoted 8 lines · Stian Jordet

Quoted 3 lines
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

Pavel Machek

2004-03-01 12:43 UTC #13 lore raw

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

In reply to Willy Tarreau

Hi!

Quoted 20 lines

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

Quoted 1 line

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.

Signature · 1 line

64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms