When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
I get:
ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o init/do_mounts.o init/initramfs.o
ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/i386/kernel/built-in.o arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o net/built-in.o --end-group -o vmlinux
arch/i386/kernel/built-in.o(.data+0x1304): In function `do_suspend_lowlevel':
: undefined reference to `save_processor_state'
arch/i386/kernel/built-in.o(.data+0x130a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esp'
arch/i386/kernel/built-in.o(.data+0x130f): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eax'
arch/i386/kernel/built-in.o(.data+0x1315): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebx'
arch/i386/kernel/built-in.o(.data+0x131b): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ecx'
arch/i386/kernel/built-in.o(.data+0x1321): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edx'
arch/i386/kernel/built-in.o(.data+0x1327): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebp'
arch/i386/kernel/built-in.o(.data+0x132d): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esi'
arch/i386/kernel/built-in.o(.data+0x1333): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edi'
arch/i386/kernel/built-in.o(.data+0x133a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eflags'
arch/i386/kernel/built-in.o(.data+0x137a): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esp'
arch/i386/kernel/built-in.o(.data+0x1380): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebp'
arch/i386/kernel/built-in.o(.data+0x1385): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eax'
arch/i386/kernel/built-in.o(.data+0x138b): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ebx'
arch/i386/kernel/built-in.o(.data+0x1391): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_ecx'
arch/i386/kernel/built-in.o(.data+0x1397): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edx'
arch/i386/kernel/built-in.o(.data+0x139d): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_esi'
arch/i386/kernel/built-in.o(.data+0x13a3): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_edi'
arch/i386/kernel/built-in.o(.data+0x13a8): In function `do_suspend_lowlevel':
: undefined reference to `restore_processor_state'
arch/i386/kernel/built-in.o(.data+0x13ae): In function `do_suspend_lowlevel':
: undefined reference to `saved_context_eflags'
make: *** [vmlinux] Fehler 1
Try turning on software suspend in the kernel hacking section. I had
to clean and recompile a couple times after doing that but that
eventually got it to compile. Of course, once I got it compiled it
oops'ed on boot, so that may not get you anywhere, but.... :-)
eric
On Monday 02 December 2002 12:24, Jochen Hein wrote:
> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> I get:
>
> ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o
> init/do_mounts.o init/initramfs.o ld -m elf_i386 -e stext -T
> arch/i386/vmlinux.lds.s arch/i386/kernel/head.o
> arch/i386/kernel/init_task.o init/built-in.o --start-group
> usr/built-in.o arch/i386/kernel/built-in.o
> arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> security/built-in.o crypto/built-in.o lib/lib.a
> arch/i386/lib/lib.a drivers/built-in.o sound/built-in.o
> arch/i386/pci/built-in.o net/built-in.o --end-group -o vmlinux
>
> arch/i386/kernel/built-in.o(.data+0x1304): In function
`do_suspend_lowlevel':
> : undefined reference to `save_processor_state'
>
> arch/i386/kernel/built-in.o(.data+0x130a): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esp'
>
> arch/i386/kernel/built-in.o(.data+0x130f): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eax'
>
> arch/i386/kernel/built-in.o(.data+0x1315): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebx'
>
> arch/i386/kernel/built-in.o(.data+0x131b): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ecx'
>
> arch/i386/kernel/built-in.o(.data+0x1321): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edx'
>
> arch/i386/kernel/built-in.o(.data+0x1327): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebp'
>
> arch/i386/kernel/built-in.o(.data+0x132d): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esi'
>
> arch/i386/kernel/built-in.o(.data+0x1333): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edi'
>
> arch/i386/kernel/built-in.o(.data+0x133a): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eflags'
>
> arch/i386/kernel/built-in.o(.data+0x137a): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esp'
>
> arch/i386/kernel/built-in.o(.data+0x1380): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebp'
>
> arch/i386/kernel/built-in.o(.data+0x1385): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eax'
>
> arch/i386/kernel/built-in.o(.data+0x138b): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ebx'
>
> arch/i386/kernel/built-in.o(.data+0x1391): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_ecx'
>
> arch/i386/kernel/built-in.o(.data+0x1397): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edx'
>
> arch/i386/kernel/built-in.o(.data+0x139d): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_esi'
>
> arch/i386/kernel/built-in.o(.data+0x13a3): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_edi'
>
> arch/i386/kernel/built-in.o(.data+0x13a8): In function
`do_suspend_lowlevel':
> : undefined reference to `restore_processor_state'
>
> arch/i386/kernel/built-in.o(.data+0x13ae): In function
`do_suspend_lowlevel':
> : undefined reference to `saved_context_eflags'
>
> make: *** [vmlinux] Fehler 1
>
> -
> 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/
--
"First they ignore you. Then they laugh at you.
Then they fight you. And then you win." -Gandhi
Eric Altendorf <[email protected]> writes:
> On Monday 02 December 2002 12:24, Jochen Hein wrote:
>> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
>> I get:
>>
>> arch/i386/kernel/built-in.o(.data+0x1304): In function
> `do_suspend_lowlevel':
>> : undefined reference to `save_processor_state'
>>
>> arch/i386/kernel/built-in.o(.data+0x130a): In function
> `do_suspend_lowlevel':
>> : undefined reference to `saved_context_esp'
>>
> Try turning on software suspend in the kernel hacking section.
It is off (and has been all the time, AFAIR).
Jochen
--
Wenn Du nicht wei?t was Du tust, tu's mit Eleganz.
On Tuesday 03 December 2002 10:35, Jochen Hein wrote:
> Eric Altendorf <[email protected]> writes:
> > On Monday 02 December 2002 12:24, Jochen Hein wrote:
> >> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> >> I get:
> >>
> >> arch/i386/kernel/built-in.o(.data+0x1304): In function
> >
> > `do_suspend_lowlevel':
> >> : undefined reference to `save_processor_state'
> >>
> >> arch/i386/kernel/built-in.o(.data+0x130a): In function
> >
> > `do_suspend_lowlevel':
> >> : undefined reference to `saved_context_esp'
> >
> > Try turning on software suspend in the kernel hacking section.
>
> It is off (and has been all the time, AFAIR).
Right ... I'm no kernel hacker so I don't know why, but I can only get
the recent kernels to compile with sleep states if I turn *ON*
software suspend as well. However, as soon as I turn on swsusp and
get a compiled kernel, it oops'es on boot.
eric
--
"First they ignore you. Then they laugh at you.
Then they fight you. And then you win." -Gandhi
Hi!
> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
Enable SWSUSP... Then investigate why it is possible to select
ACPI_SLEEP but not SWSUSP...
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
On Wed, Dec 04, 2002 at 12:41:19PM +0100, Pavel Machek wrote:
> Hi!
Hi Pavel!
> > When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
>
> Enable SWSUSP... Then investigate why it is possible to select
> ACPI_SLEEP but not SWSUSP...
In drivers/acpi/Config.in in 2.5.44:
<-- snip -->
...
if [ "$CONFIG_ACPI_HT_ONLY" != "y" ]; then
bool ' Sleep States' CONFIG_ACPI_SLEEP
...
define_bool CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
...
fi
...
<-- snip -->
This double definition was at least confusing, a simple
dep_bool ' Sleep States' CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
would have expressed it better.
The transition to the new kconfig converted this confusing Config.in
snipped to the following code in drivers/acpi/Kconfig:
<-- snip -->
...
config ACPI_SLEEP
bool "Sleep States"
depends on X86 && ACPI && !ACPI_HT_ONLY
default SOFTWARE_SUSPEND
...
<-- snip -->
The following patch makes it work the way it was intended:
--- linux-2.5.50/drivers/acpi/Kconfig.old 2002-12-04 14:24:14.000000000 +0100
+++ linux-2.5.50/drivers/acpi/Kconfig 2002-12-04 14:27:17.000000000 +0100
@@ -58,7 +58,7 @@
config ACPI_SLEEP
bool "Sleep States"
- depends on X86 && ACPI && !ACPI_HT_ONLY
+ depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
default SOFTWARE_SUSPEND
---help---
This option adds support for ACPI suspend states.
Another thing that seems to be suboptimal is that the question for
SOFTWARE_SUSPEND comes _after_ the question for ACPI_SLEEP, IOW someone
doing a "make config" to configure his kernel doesn't have a chance to
select ACPI_SLEEP. To fix this (and it seems to be logical) the
SOFTWARE_SUSPEND question should be moved to the "Power management
options" menu. The patch below tries to solve this and it makes ACPI
dependant on PM as the comments in PM indicate:
- move "Software Suspend" to the "Power management options" menu above
the ACPI entry
- let ACPI depend on PM
Any comments on this patch?
> Pavel
cu
Adrian
--- linux-2.5.50/arch/i386/Kconfig.old 2002-12-04 14:47:03.000000000 +0100
+++ linux-2.5.50/arch/i386/Kconfig 2002-12-04 14:43:48.000000000 +0100
@@ -789,8 +789,6 @@
menu "Power management options (ACPI, APM)"
-source "drivers/acpi/Kconfig"
-
config PM
bool "Power Management support"
---help---
@@ -811,6 +809,37 @@
will issue the hlt instruction if nothing is to be done, thereby
sending the processor to sleep and saving power.
+config SOFTWARE_SUSPEND
+ bool "Software Suspend (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && PM
+ ---help---
+ Enable the possibilty of suspendig machine. It doesn't need APM.
+ You may suspend your machine by 'swsusp' or 'shutdown -z <time>'
+ (patch for sysvinit needed).
+
+ It creates an image which is saved in your active swaps. By the next
+ booting the, pass 'resume=/path/to/your/swap/file' and kernel will
+ detect the saved image, restore the memory from
+ it and then it continues to run as before you've suspended.
+ If you don't want the previous state to continue use the 'noresume'
+ kernel option. However note that your partitions will be fsck'd and
+ you must re-mkswap your swap partitions/files.
+
+ Right now you may boot without resuming and then later resume but
+ in meantime you cannot use those swap partitions/files which were
+ involved in suspending. Also in this case there is a risk that buffers
+ on disk won't match with saved ones.
+
+ SMP is supported ``as-is''. There's a code for it but doesn't work.
+ There have been problems reported relating SCSI.
+
+ This option is about getting stable. However there is still some
+ absence of features.
+
+ For more information take a look at Documentation/swsusp.txt.
+
+source "drivers/acpi/Kconfig"
+
config APM
tristate "Advanced Power Management BIOS support"
depends on PM
@@ -1516,35 +1545,6 @@
menu "Kernel hacking"
-config SOFTWARE_SUSPEND
- bool "Software Suspend (EXPERIMENTAL)"
- depends on EXPERIMENTAL && PM
- ---help---
- Enable the possibilty of suspendig machine. It doesn't need APM.
- You may suspend your machine by 'swsusp' or 'shutdown -z <time>'
- (patch for sysvinit needed).
-
- It creates an image which is saved in your active swaps. By the next
- booting the, pass 'resume=/path/to/your/swap/file' and kernel will
- detect the saved image, restore the memory from
- it and then it continues to run as before you've suspended.
- If you don't want the previous state to continue use the 'noresume'
- kernel option. However note that your partitions will be fsck'd and
- you must re-mkswap your swap partitions/files.
-
- Right now you may boot without resuming and then later resume but
- in meantime you cannot use those swap partitions/files which were
- involved in suspending. Also in this case there is a risk that buffers
- on disk won't match with saved ones.
-
- SMP is supported ``as-is''. There's a code for it but doesn't work.
- There have been problems reported relating SCSI.
-
- This option is about getting stable. However there is still some
- absence of features.
-
- For more information take a look at Documentation/swsusp.txt.
-
config DEBUG_KERNEL
bool "Kernel debugging"
help
--- linux-2.5.50/drivers/acpi/Kconfig.old 2002-12-04 14:39:24.000000000 +0100
+++ linux-2.5.50/drivers/acpi/Kconfig 2002-12-04 14:42:57.000000000 +0100
@@ -3,6 +3,7 @@
#
menu "ACPI Support"
+ depends on PM
config ACPI
bool "ACPI Support" if X86
Adrian Bunk <[email protected]> writes:
> Any comments on this patch?
Both look reasonable to me. "make config" works as intended. I'll
try compiling them now. Thanks.
Jochen
--
Wenn Du nicht wei?t was Du tust, tu's mit Eleganz.
Hi,
On Wed, 4 Dec 2002, Adrian Bunk wrote:
> In drivers/acpi/Config.in in 2.5.44:
>
> <-- snip -->
>
> ...
> if [ "$CONFIG_ACPI_HT_ONLY" != "y" ]; then
> bool ' Sleep States' CONFIG_ACPI_SLEEP
> ...
> define_bool CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
> ...
> fi
> ...
>
> <-- snip -->
>
>
> This double definition was at least confusing, a simple
>
> dep_bool ' Sleep States' CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
>
> would have expressed it better.
It's not really the same and the first probably heavily confuses xconfig.
If CONFIG_SOFTWARE_SUSPEND can do without CONFIG_ACPI_SLEEP, the second
version should work fine.
> config ACPI_SLEEP
> bool "Sleep States"
> - depends on X86 && ACPI && !ACPI_HT_ONLY
> + depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
> default SOFTWARE_SUSPEND
> ---help---
> This option adds support for ACPI suspend states.
The default is probably not needed anymore.
> Another thing that seems to be suboptimal is that the question for
> SOFTWARE_SUSPEND comes _after_ the question for ACPI_SLEEP, IOW someone
> doing a "make config" to configure his kernel doesn't have a chance to
> select ACPI_SLEEP.
That was only true with the old "make config". :)
> To fix this (and it seems to be logical) the
> SOFTWARE_SUSPEND question should be moved to the "Power management
> options" menu. The patch below tries to solve this and it makes ACPI
> dependant on PM as the comments in PM indicate:
> - move "Software Suspend" to the "Power management options" menu above
> the ACPI entry
> - let ACPI depend on PM
Is ACPI really only a PM thingie?
Anyway, I had a cleaned up drivers/acpi/Kconfig lying around. The ACPI
config file was not really easy to convert automatically. I integrated
your change from above, it would be nice if some could check if every
still works as it should.
bye, Roman
--- linux/drivers/acpi/Kconfig 31 Oct 2002 13:26:48 -0000 1.1.1.1
+++ linux/drivers/acpi/Kconfig 4 Dec 2002 20:12:43 -0000
@@ -35,9 +35,11 @@ config ACPI
available at:
<http://www.acpi.info>
+if ACPI
+
config ACPI_HT_ONLY
bool "CPU Enumeration Only"
- depends on X86 && ACPI && X86_LOCAL_APIC
+ depends on X86_LOCAL_APIC
---help---
This option enables limited ACPI support -- just enough to
enumerate processors from the ACPI Multiple APIC Description
@@ -51,15 +53,12 @@ config ACPI_HT_ONLY
There is no command-line option to disable this, but the kernel
will fall back to the MPS table if the MADT is not present.
-config ACPI_BOOT
- bool
- depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN) || X86 && ACPI && !ACPI_HT_ONLY || X86 && ACPI
- default y
+
+if X86 && !ACPI_HT_ONLY || IA64 && !IA64_HP_SIM
config ACPI_SLEEP
bool "Sleep States"
- depends on X86 && ACPI && !ACPI_HT_ONLY
- default SOFTWARE_SUSPEND
+ depends on X86 && SOFTWARE_SUSPEND
---help---
This option adds support for ACPI suspend states.
@@ -78,7 +77,7 @@ config ACPI_SLEEP
config ACPI_AC
tristate "AC Adapter"
- depends on X86 && ACPI && !ACPI_HT_ONLY
+ depends on X86
help
This driver adds support for the AC Adapter object, which indicates
whether a system is on AC, or not. Typically, only mobile systems
@@ -86,7 +85,7 @@ config ACPI_AC
config ACPI_BATTERY
tristate "Battery"
- depends on X86 && ACPI && !ACPI_HT_ONLY
+ depends on X86
help
This driver adds support for battery information through
/proc/acpi/battery. If you have a mobile system with a battery,
@@ -94,7 +93,6 @@ config ACPI_BATTERY
config ACPI_BUTTON
tristate "Button"
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
help
This driver registers for events based on buttons, such as the
power, sleep, and lid switch. In the future, a daemon will read
@@ -104,14 +102,12 @@ config ACPI_BUTTON
config ACPI_FAN
tristate "Fan"
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
help
This driver adds support for ACPI fan devices, allowing user-mode
applications to perform basic fan control (on, off, status).
config ACPI_PROCESSOR
tristate "Processor"
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
help
This driver installs ACPI as the idle handler for Linux, and uses
ACPI C2 and C3 processor states to save power, on systems that
@@ -119,7 +115,7 @@ config ACPI_PROCESSOR
config ACPI_PROCESSOR_PERF
bool "Processor Performance States"
- depends on X86 && ACPI && !ACPI_HT_ONLY && ACPI_PROCESSOR && CPU_FREQ
+ depends on X86 && ACPI_PROCESSOR && CPU_FREQ
help
This driver adds support for CPU frequency scaling, if this is supported
by the hardware and the BIOS. If you are compiling for a mobile system,
@@ -135,12 +131,12 @@ config ACPI_THERMAL
may be damaged without it.
config ACPI_NUMA
- bool "NUMA support" if NUMA && (IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY)
- default y if IA64 && IA64_SGI_SN
+ bool "NUMA support"
+ depends on NUMA
config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
- depends on X86 && ACPI && !ACPI_HT_ONLY
+ depends on X86
---help---
This driver adds support for access to certain system settings
on "legacy free" Toshiba laptops. These laptops can be recognized by
@@ -166,7 +162,6 @@ config ACPI_TOSHIBA
config ACPI_DEBUG
bool "Debug Statements"
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
help
The ACPI driver can optionally report errors with a great deal
of verbosity. Saying Y enables these statements. This will increase
@@ -174,17 +169,15 @@ config ACPI_DEBUG
config ACPI_BUS
bool
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
default y
config ACPI_INTERPRETER
bool
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
default y
config ACPI_EC
bool
- depends on X86 && ACPI && !ACPI_HT_ONLY
+ depends on X86
default y
help
This driver is required on some systems for the proper operation of
@@ -193,26 +186,35 @@ config ACPI_EC
config ACPI_POWER
bool
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
default y
config ACPI_PCI
bool
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
default PCI
config ACPI_SYSTEM
bool
- depends on IA64 && !IA64_HP_SIM || X86 && ACPI && !ACPI_HT_ONLY
default y
help
This driver will enable your system to shut down using ACPI, and
dump your ACPI DSDT table using /proc/acpi/dsdt.
+endif
+
+config ACPI_NUMA
+ depends IA64 && IA64_SGI_SN
+ default y
+
config ACPI_EFI
bool
depends on IA64 && (!IA64_HP_SIM || IA64_SGI_SN)
default y
+
+config ACPI_BOOT
+ bool
+ default y
+
+endif
endmenu
Thats what I thought until Pavel told me SOFTWARE_SUSPEND requires ACPI_SLEEP
and ACPI_SLEEP should not be unchecked if SOFTWARE_SUSPEND is disabled.
My patch was only to fix a link error in 2.5.49/50. A better solution is
needed :-)
Shawn.
>List: linux-kernel
>Subject: Re: [2.5.50, ACPI] link error
From: Roman Zippel <[email protected]>
>Date: 2002-12-04 20:29:08
>[Download message RAW]
>
>Hi,
>
>On Wed, 4 Dec 2002, Adrian Bunk wrote:
>
> In drivers/acpi/Config.in in 2.5.44:
>
> <-- snip -->
>
> ...
> if [ "$CONFIG_ACPI_HT_ONLY" != "y" ]; then
> bool ' Sleep States' CONFIG_ACPI_SLEEP
> ...
> define_bool CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
> ...
> fi
> ...
>
> <-- snip -->
>
>
> This double definition was at least confusing, a simple
>
> dep_bool ' Sleep States' CONFIG_ACPI_SLEEP $CONFIG_SOFTWARE_SUSPEND
>
> would have expressed it better.
>It's not really the same and the first probably heavily confuses xconfig.
>If CONFIG_SOFTWARE_SUSPEND can do without CONFIG_ACPI_SLEEP, the second
>version should work fine.
> config ACPI_SLEEP
> bool "Sleep States"
> - depends on X86 && ACPI && !ACPI_HT_ONLY
> + depends on X86 && ACPI && !ACPI_HT_ONLY && SOFTWARE_SUSPEND
> default SOFTWARE_SUSPEND
> ---help---
> This option adds support for ACPI suspend states.
>The default is probably not needed anymore.
--
Shawn Starr
UNIX Systems Administrator, Operations
Datawire Communication Networks Inc.
10 Carlson Court, Suite 300
Toronto, ON, M9W 6L2
T: 416-213-2001 ext 179 F: 416-213-2008
[email protected]
"The power to Transact" - http://www.datawire.net
Hi,
On Wed, 4 Dec 2002, Shawn Starr wrote:
> Thats what I thought until Pavel told me SOFTWARE_SUSPEND requires ACPI_SLEEP
> and ACPI_SLEEP should not be unchecked if SOFTWARE_SUSPEND is disabled.
Is there then any reason to ask the user for ACPI_SLEEP?
bye, Roman
Hi,
On Wed, 4 Dec 2002, Shawn Starr wrote:
> ACPI_SLEEP should only be required if the user selects SOFTWARE_SUSPEND.
> Otherwise if the user selects only ACPI_SLEEP then they don't get software
> suspend mode (S3).
>
> Then problem is, I can't figure out how to get Kconfig to do this ;-(
This should do it:
config ACPI_SLEEP
bool "Sleep States" if !SOFTWARE_SUSPEND
default SOFTWARE_SUSPEND
depends on X86
bye, Roman
Hi,
On Wed, 4 Dec 2002, Shawn Starr wrote:
> if ACPI_SLEEP = selected then display SOFTWARE_SUSPEND
> else if SOFTWARE_SUSPEND selected select ACPI_SLEEP
> else if ACPI_SLEEP unselected unselect SOFTWARE_SUSPEND
> endif
Recursive dependencies are not allowed, the parser currently accepts them
silently, but that will change.
Anyway, I don't really understand above, SOFTWARE_SUSPEND can only be
selected if ACPI_SLEEP sleep is selected, so why should it select
ACPI_SLEEP?
Could you please make a table of all possible combinations?
bye, Roman
Hi,
On Wed, 4 Dec 2002, Shawn Starr wrote:
> Well, SOFTWARE_SUSPEND needs ACPI_SLEEP. If ACPI_SLEEP is selected only then we don't care about software suspend.
>
> So to list:
>
> 1). SOFTWARE_SUSPEND requires ACPI_SLEEP.
> 2). ACPI_SLEEP does not require SOFTWARE_SUSPEND.
>
> That's about it =)
That doesn't make it really easier. I want a table like this:
SUSPEND SLEEP SUSPEND visible? SLEEP visible?
n n
n y
y y
All I can parse from above is that SUSPEND=y && SLEEP=n isn't possible,
but what are the possible user choices and how does the state change if
the user (de)selects an option?
bye, Roman
Hi,
On Thu, 5 Dec 2002, Shawn Starr wrote:
> SLEEP SUSPEND SLEEP visible SUSPEND visible
> n n y n
> y n y y
> y y y y
>
> We really do need recursive support though. A user should not be able to
> select SOFTWARE_SUSPEND without SLEEP selected.
So just let SOFTWARE_SUSPEND depend on ACPI_SLEEP, if ACPI_SLEEP is
independent it doesn't has to depend on SUSPEND.
Another possibility is that you might want to restore the old behaviour,
that SOFTWARE_SUSPEND is always visible and forces ACPI_SLEEP to y if
needed, but then you have to explicitly disable the user prompt and
SOFTWARE_SUSPEND must not depend on ACPI_SLEEP:
config ACPI_SLEEP
bool "Sleep States" if !SOFTWARE_SUSPEND
default SOFTWARE_SUSPEND
config SOFTWARE_SUSPEND
bool "Software Suspend (EXPERIMENTAL)"
depends on EXPERIMENTAL && PM
bye, Roman
PS: Could you check your mailer why your mails don't reach lkml?
Hi!
> > >> When compiling 2.5.50 with CONFIG_ACPI_SLEEP=y
> > >> I get:
> > >>
> > >> arch/i386/kernel/built-in.o(.data+0x1304): In function
> > >
> > > `do_suspend_lowlevel':
> > >> : undefined reference to `save_processor_state'
> > >>
> > >> arch/i386/kernel/built-in.o(.data+0x130a): In function
> > >
> > > `do_suspend_lowlevel':
> > >> : undefined reference to `saved_context_esp'
> > >
> > > Try turning on software suspend in the kernel hacking section.
> >
> > It is off (and has been all the time, AFAIR).
>
> Right ... I'm no kernel hacker so I don't know why, but I can only get
> the recent kernels to compile with sleep states if I turn *ON*
> software suspend as well. However, as soon as I turn on swsusp and
> get a compiled kernel, it oops'es on boot.
Can you mail me decoded oops?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
Note that this link error occurs for me when swsusp is off, but
CONFIG_ACPI_SLEEP is on.
Disabling CONFIG_ACPI_SLEEP fixes the kernel build.
Hi!
> Note that this link error occurs for me when swsusp is off, but
> CONFIG_ACPI_SLEEP is on.
>
> Disabling CONFIG_ACPI_SLEEP fixes the kernel build.
Yes, there are about 10 patches to fix it floating around... I just
hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
swsusp).
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Pavel Machek wrote:
> Yes, there are about 10 patches to fix it floating around... I just
> hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> swsusp).
I haven't seen the patch, but does it make sense for hardware suspend to
depend on software suspend?
IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to
depend on swsusp. That way you get the _least_ common denominator, not
the union of two sets.
Jeff
Hi!
> >>>Yes, there are about 10 patches to fix it floating around... I just
> >>>hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> >>>swsusp).
> >>
> >>
> >>I haven't seen the patch, but does it make sense for hardware suspend to
> >>depend on software suspend?
> >>
> >>IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to
> >>depend on swsusp. That way you get the _least_ common denominator, not
> >>the union of two sets.
> >
> >
> >Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
> >see big need to do that.
>
>
> Why should I fix your fix?
>
> Doesn't that imply your fix is broken to begin with?
ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
overdesign to me, OTOH if you do the work it is okay with me.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Pavel Machek wrote:
> Hi!
>
>
>>>Yes, there are about 10 patches to fix it floating around... I just
>>>hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
>>>swsusp).
>>
>>
>>I haven't seen the patch, but does it make sense for hardware suspend to
>>depend on software suspend?
>>
>>IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to
>>depend on swsusp. That way you get the _least_ common denominator, not
>>the union of two sets.
>
>
> Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
> see big need to do that.
Why should I fix your fix?
Doesn't that imply your fix is broken to begin with?
Hi!
> >Yes, there are about 10 patches to fix it floating around... I just
> >hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
> >swsusp).
>
>
> I haven't seen the patch, but does it make sense for hardware suspend to
> depend on software suspend?
>
> IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to
> depend on swsusp. That way you get the _least_ common denominator, not
> the union of two sets.
Feel free to fix that, but as swsusp is needed for S4, anyway, I do not
see big need to do that.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
> > Doesn't that imply your fix is broken to begin with?
>
> ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> overdesign to me, OTOH if you do the work it is okay with me.
You broke the design. S3 support was developed long before swsusp was in
the kernel, and completely indpendent of it. It should have remained that
way.
S3 support is a subset of what is need for S4 support.
swsusp is an implementation of S4 support. In theory, there could be
multiple implementations that all use the same core (saving/restoring
state).
There could also be different power management schemes that use swsusp as
an implementation for suspend-to-disk. But, that's another tangent.
CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4
support. The comment in the config option should tell the user that they
must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should
prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The
ACPI side can make an empty call to swsusp if no implementation is
selected).
Some time ago, I made a BK repo for suspend support. I axed it, since no
one ever used it. But, it's back again, and I'll be integrating your
patches and try to dedicate a few extra cycles to resolving some of the
issues. I'll send an announcement to the list once I've integrated your
patches.
-pat
Hi!
> > > Doesn't that imply your fix is broken to begin with?
> >
> > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > overdesign to me, OTOH if you do the work it is okay with me.
>
> You broke the design. S3 support was developed long before swsusp was in
> the kernel, and completely indpendent of it. It should have remained that
> way.
>
> S3 support is a subset of what is need for S4 support.
That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
but not for S4. Big part of driver support is only needed for S3.
> swsusp is an implementation of S4 support. In theory, there could be
> multiple implementations that all use the same core (saving/restoring
> state).
There were patches for S4bios floating around, but it never really
worked, IIRC.
> There could also be different power management schemes that use swsusp as
> an implementation for suspend-to-disk. But, that's another tangent.
>
> CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4
> support.
What's ACPI side of S4 good for when you can not do S4?
> The comment in the config option should tell the user that they
> must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should
> prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The
> ACPI side can make an empty call to swsusp if no implementation is
> selected).
S3 needs process stopper from kernel/suspend.c. I did not want to have
#ifdefs all over suspend.c...
> Some time ago, I made a BK repo for suspend support. I axed it, since no
> one ever used it. But, it's back again, and I'll be integrating your
> patches and try to dedicate a few extra cycles to resolving some of the
> issues. I'll send an announcement to the list once I've integrated your
> patches.
I probably will not persuade you to make it CVS, right? [Sorry, I'm
not going to touch bitkeeper.]
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
> > S3 support is a subset of what is need for S4 support.
>
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.
Ok, acpi_wakeup.S is only for S3.
As for drivers, I'm dubious of swsusp's handling of device and driver
support. A suspend cycle is supposed to leave devices in the same state
they were in before the cycle. So, you need suspend and resume hooks in
the drivers, even for S4 support, to capture and restore context in the
devices themselves. Then again, I've no proof that swsusp doesn't get
everything right as is.
> > CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4
> > support.
>
> What's ACPI side of S4 good for when you can not do S4?
To not litter the code with #ifdefs.
> > The comment in the config option should tell the user that they
> > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should
> > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The
> > ACPI side can make an empty call to swsusp if no implementation is
> > selected).
>
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...
Then break it up into separate files in a separate directory.
> > Some time ago, I made a BK repo for suspend support. I axed it, since no
> > one ever used it. But, it's back again, and I'll be integrating your
> > patches and try to dedicate a few extra cycles to resolving some of the
> > issues. I'll send an announcement to the list once I've integrated your
> > patches.
>
> I probably will not persuade you to make it CVS, right? [Sorry, I'm
> not going to touch bitkeeper.]
I know, and that's fine. I won't touch CVS again, unless there's a hefty
sum and a lot of good beer involved. (Or, after I've consumed a lot of
good beer). Patches can be made from the repo, most easily after merging
to a new kernel version.
-pat
Hi!
> > > S3 support is a subset of what is need for S4 support.
> >
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
>
> Ok, acpi_wakeup.S is only for S3.
>
> As for drivers, I'm dubious of swsusp's handling of device and driver
> support. A suspend cycle is supposed to leave devices in the same state
Some devices do not really have a state (timer -- it needs to be set
to 1kHz, but that's it), and they do not need support for S4 but need
it for S3.
> > > The comment in the config option should tell the user that they
> > > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should
> > > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The
> > > ACPI side can make an empty call to swsusp if no implementation is
> > > selected).
> >
> > S3 needs process stopper from kernel/suspend.c. I did not want to have
> > #ifdefs all over suspend.c...
>
> Then break it up into separate files in a separate directory.
Uff, having kernel/suspend/freezer.c and kernel/suspend/disk.c would
seem very ugly to me, and freezer is pretty short in fact... I do not
think we want separate directory for suspend.
> > > Some time ago, I made a BK repo for suspend support. I axed it, since no
> > > one ever used it. But, it's back again, and I'll be integrating your
> > > patches and try to dedicate a few extra cycles to resolving some of the
> > > issues. I'll send an announcement to the list once I've integrated your
> > > patches.
> >
> > I probably will not persuade you to make it CVS, right? [Sorry, I'm
> > not going to touch bitkeeper.]
>
> I know, and that's fine. I won't touch CVS again, unless there's a hefty
> sum and a lot of good beer involved. (Or, after I've consumed a lot of
> good beer). Patches can be made from the repo, most easily after merging
> to a new kernel version.
:-) there should be some good beer around here ;-).
I'd like to keep it simple for now. I feel alone developing sleep on
2.5, and it is easier for me not to ave to test different
configurations. So I think ACPI_SLEEP requiring SOFTWARE_SUSPEND is
okay for now (code bloat is not too bad). If you are joining and will
work on ACPI_SLEEP && !SOFTWARE_SUSPEND, you can easily catch
non-compilations and similar mistakes, and it will be okay to separate
the two.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Pavel Machek wrote:
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...
Then move it to a different file, that may be shared between various
CONFIG_xxx features.
The odd part is that I must enable ACPI and SW SUSPEND to get things to
compile but then I have to turn around and put acpi=off in my boot
config because it still hangs my laptop (as well as IDE w/ DMA).
So I find it a bit ironic :)
-d
Jeff Garzik wrote:
> Pavel Machek wrote:
>
>> Yes, there are about 10 patches to fix it floating around... I just
>> hope linus takes one of them. (Fix is make ACPI_SLEEP depend on
>> swsusp).
>
>
>
> I haven't seen the patch, but does it make sense for hardware suspend
> to depend on software suspend?
>
> IMO there should be a common core (CONFIG_SUSPEND?), not force ACPI to
> depend on swsusp. That way you get the _least_ common denominator,
> not the union of two sets.
>
> Jeff
>
>
>
> -
> 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/
On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Doesn't that imply your fix is broken to begin with?
> > >
> > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > overdesign to me, OTOH if you do the work it is okay with me.
> >
> > You broke the design. S3 support was developed long before swsusp was in
> > the kernel, and completely indpendent of it. It should have remained that
> > way.
> >
> > S3 support is a subset of what is need for S4 support.
>
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.
>
> > swsusp is an implementation of S4 support. In theory, there could be
> > multiple implementations that all use the same core (saving/restoring
> > state).
>
> There were patches for S4bios floating around, but it never really
> worked, IIRC.
No. It work. I do not resubmmited patches because I think that
swsusp is better.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Hi, Pavel.
On Fri, Dec 06, 2002 at 07:57:02PM +0100, Ducrot Bruno wrote:
> On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > Doesn't that imply your fix is broken to begin with?
> > > >
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > >
> > > You broke the design. S3 support was developed long before swsusp was in
> > > the kernel, and completely indpendent of it. It should have remained that
> > > way.
> > >
> > > S3 support is a subset of what is need for S4 support.
> >
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> >
> > > swsusp is an implementation of S4 support. In theory, there could be
> > > multiple implementations that all use the same core (saving/restoring
> > > state).
> >
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
>
> No. It work. I do not resubmmited patches because I think that
> swsusp is better.
>
I attach also this patch, it is ughly, though, but if you are sure
that your laptop can support S4BIOS (I do not include basic checks for
that), it should survive (I need myself to reset at wakeup the keyboard controller,
though).
It is again acpi on sf.net of today, and some of your patches for S3 support.
echo 4b > /proc/acpi/sleep if you want to say goodbye to your data :)
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
On Thursday 05 December 2002 09:31, Pavel Machek wrote:
> Hi!
>
> > Right ... I'm no kernel hacker so I don't know why, but I can
> > only get the recent kernels to compile with sleep states if I
> > turn *ON* software suspend as well. However, as soon as I turn
> > on swsusp and get a compiled kernel, it oops'es on boot.
>
> Can you mail me decoded oops?
> Pavel
This is the first time I've decoded an oops, and since I had to decode it on a different kernel (2.5.25) than the one I'm debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't get the ksyms file, I used -K ... and because I built w/o modules I used -L and -O. Let me know if I did it wrong or if you need more info... Thanks. (Also I had to transcribe the oops by hand ... I'm pretty sure I got all the values right but I could have missed something)
ksymoops 2.4.4 on i586 2.5.25. Options used
-v vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m System.map (specified)
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c013a6b1>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: a55a5a5a ebx: 00001000 ecx: 00000000 edx: 00000200
esi: c130f628 edi: cedc5000 ebp: c0326e00 esp: c12bdf7c
ds: 0068 es: 0068 ss: 0068
Stack: c130f628 00000000 c0121816 c130f628 00001000 c130d628 00000001 00000000
00000003 c03f0080 00000000 c03f0045 00000000 c0121937 c0326e00 00000000
c02c5c9f c0326e00 c01051c4 c02bed13 00000000 00000000 c0105020 00000000
[<c0121816>] read_suspend_image+0x81/0x107
[<c0121937>] software_resume+0x9b/0xc0
[<c01051c4>] prepare_namespace+0x84/0x10c
[<c0105020>] init+0x0/0x120
[<c010503f>] init+0x1f/0x120
[<c0105020>] init+0x0/0x120
[<c0106ca9>] kernel_thread_helper+0x5/0xb
Code: 8b 40 28 85 c0 74 11 66 83 b8 b6 00 00 00 00 74 07 0f b7 90
>>EIP; c013a6b1 <set_blocksize+26/83> <=====
Code; c013a6b1 <set_blocksize+26/83>
00000000 <_EIP>:
Code; c013a6b1 <set_blocksize+26/83> <=====
0: 8b 40 28 mov 0x28(%eax),%eax <=====
Code; c013a6b4 <set_blocksize+29/83>
3: 85 c0 test %eax,%eax
Code; c013a6b6 <set_blocksize+2b/83>
5: 74 11 je 18 <_EIP+0x18> c013a6c9 <set_blocksize+3e/83>
Code; c013a6b8 <set_blocksize+2d/83>
7: 66 83 b8 b6 00 00 00 cmpw $0x0,0xb6(%eax)
Code; c013a6bf <set_blocksize+34/83>
e: 00
Code; c013a6c0 <set_blocksize+35/83>
f: 74 07 je 18 <_EIP+0x18> c013a6c9 <set_blocksize+3e/83>
Code; c013a6c2 <set_blocksize+37/83>
11: 0f b7 90 00 00 00 00 movzwl 0x0(%eax),%edx
<0>Kernel panic: Attempted to kill init!
eric
--
"First they ignore you. Then they laugh at you.
Then they fight you. And then you win." -Gandhi
Hi!
> > > > > Doesn't that imply your fix is broken to begin with?
> > > >
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > >
> > > You broke the design. S3 support was developed long before swsusp was in
> > > the kernel, and completely indpendent of it. It should have remained that
> > > way.
> > >
> > > S3 support is a subset of what is need for S4 support.
> >
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> >
> > > swsusp is an implementation of S4 support. In theory, there could be
> > > multiple implementations that all use the same core (saving/restoring
> > > state).
> >
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
>
> No. It work. I do not resubmmited patches because I think that
> swsusp is better.
I think that s4bios is nice to have. Its similar to S3 and easier to
set up than swsusp... It would be nice to have it.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> Hi!
>
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > >
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > >
> > > > You broke the design. S3 support was developed long before swsusp was in
> > > > the kernel, and completely indpendent of it. It should have remained that
> > > > way.
> > > >
> > > > S3 support is a subset of what is need for S4 support.
> > >
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > >
> > > > swsusp is an implementation of S4 support. In theory, there could be
> > > > multiple implementations that all use the same core (saving/restoring
> > > > state).
> > >
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> >
> > No. It work. I do not resubmmited patches because I think that
> > swsusp is better.
>
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.
(I do not know much, but) another reason may be that some laptops do not
support S3, while they support S4? for example, in my Compaq Presario
1700T:
$ more /proc/acpi/info
ACPI-CA Version: 20011018
Sx States Supported: S0 S1 S4 S5
(unpatched 2.4.19, if this has anything to do)
Costas
> Pavel
--
Constantinos Antoniou
Ph.D. Candidate
Massachusetts Institute of Technology
Intelligent Transportation Systems Program
77 Massachusetts Ave., NE20-208, Cambridge, MA 02139
(T) 617-252-1113 * (F) 617-252-1130 * (email) [email protected]
> Thats what I thought until Pavel told me SOFTWARE_SUSPEND requires ACPI_SLEEP
> and ACPI_SLEEP should not be unchecked if SOFTWARE_SUSPEND is disabled.
Did I say that? That is wrong, sorry. acpi_sleep
should require swsusp but not the other way
round.
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
On Mon, Dec 09, 2002 at 12:01:11PM +0100, Pavel Machek wrote:
> Hi!
>
> > > I think that s4bios is nice to have. Its similar to S3 and easier to
> > > set up than swsusp... It would be nice to have it.
> >
> > for me:
> > pros:
> > -----
> > 1- it is really really more easier to implement than S4;
> > 2- we can even have it with 2.4 kernels (it seems that it work without
> > the need of freezing processes, but I suspect that this statement
> > is 'wrong' by nature).
> >
> > cons:
> > -----
> > 1- it is much slower (especially at save time) than your swsusp;
> > 2- end users must setup their systems (need to create a suspend partition,
> > or to keep a vfat partition as the really first one (/dev/hda1));
> > 3- we use a bios function. Actually, everything can happen...
> >
> > That why I prefer swsusp at this time, or any other implementation of S4 (I
> > think about an implementation of S4 via LKCD).
>
> Yes I think swsusp is better (long term), but it might be worth it to
> have S4bios, too. At least it has nice graphical task bars :-). Can
> you push the patch, or is it okay for me to try to get it merged?
>
Ok, ok. I will try to push the patch.
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
Hi!
> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
>
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
>
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function. Actually, everything can happen...
>
> That why I prefer swsusp at this time, or any other implementation of S4 (I
> think about an implementation of S4 via LKCD).
Yes I think swsusp is better (long term), but it might be worth it to
have S4bios, too. At least it has nice graphical task bars :-). Can
you push the patch, or is it okay for me to try to get it merged?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel:
On Sun, Dec 08, 2002 at 08:49:45PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > >
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > >
> > > > You broke the design. S3 support was developed long before swsusp was in
> > > > the kernel, and completely indpendent of it. It should have remained that
> > > > way.
> > > >
> > > > S3 support is a subset of what is need for S4 support.
> > >
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > >
> > > > swsusp is an implementation of S4 support. In theory, there could be
> > > > multiple implementations that all use the same core (saving/restoring
> > > > state).
> > >
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> >
> > No. It work. I do not resubmmited patches because I think that
> > swsusp is better.
>
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.
for me:
pros:
-----
1- it is really really more easier to implement than S4;
2- we can even have it with 2.4 kernels (it seems that it work without
the need of freezing processes, but I suspect that this statement
is 'wrong' by nature).
cons:
-----
1- it is much slower (especially at save time) than your swsusp;
2- end users must setup their systems (need to create a suspend partition,
or to keep a vfat partition as the really first one (/dev/hda1));
3- we use a bios function. Actually, everything can happen...
That why I prefer swsusp at this time, or any other implementation of S4 (I
think about an implementation of S4 via LKCD).
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
On Sun, Dec 08, 2002 at 03:46:20PM -0500, Constantinos Antoniou wrote:
> On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> > Hi!
> >
> > > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > >
> > > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > >
> > > > > You broke the design. S3 support was developed long before swsusp was in
> > > > > the kernel, and completely indpendent of it. It should have remained that
> > > > > way.
> > > > >
> > > > > S3 support is a subset of what is need for S4 support.
> > > >
> > > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > > but not for S4. Big part of driver support is only needed for S3.
> > > >
> > > > > swsusp is an implementation of S4 support. In theory, there could be
> > > > > multiple implementations that all use the same core (saving/restoring
> > > > > state).
> > > >
> > > > There were patches for S4bios floating around, but it never really
> > > > worked, IIRC.
> > >
> > > No. It work. I do not resubmmited patches because I think that
> > > swsusp is better.
> >
> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
>
> (I do not know much, but) another reason may be that some laptops do not
> support S3, while they support S4? for example, in my Compaq Presario
> 1700T:
>
> $ more /proc/acpi/info
> ACPI-CA Version: 20011018
> Sx States Supported: S0 S1 S4 S5
Some southbrigdes have well know design flaw that prevent a 'good' S3
functionality. Those this is disabled.
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
Hi!
> > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > only get the recent kernels to compile with sleep states if I
> > > turn *ON* software suspend as well. However, as soon as I turn
> > > on swsusp and get a compiled kernel, it oops'es on boot.
> >
> > Can you mail me decoded oops?
> > Pavel
>
> This is the first time I've decoded an oops, and since I had to decode it on a different kernel (2.5.25) than the one I'm debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
Can you try passing
"resume=hda5_or_whatever_your_swap_partition_is"?
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
On Sunday 08 December 2002 23:29, Pavel Machek wrote:
> Hi!
>
> > > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > > only get the recent kernels to compile with sleep states if I
> > > > turn *ON* software suspend as well. However, as soon as I
> > > > turn on swsusp and get a compiled kernel, it oops'es on boot.
> > >
> > > Can you mail me decoded oops?
> > > Pavel
> >
> > This is the first time I've decoded an oops, and since I had to
> > decode it on a different kernel (2.5.25) than the one I'm
> > debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
>
> Can you try passing
> "resume=hda5_or_whatever_your_swap_partition_is"?
Well, I've had "resume=/dev/hda6" in there the whole time (same as it
was on prior kernels that booted). I tried passing "resume=hda6"
instead just for kicks and got the same result, though... (This is
still on the 2.5.50 + Dec6ACPI kernel)
Thanks,
Eric
--
"First they ignore you. Then they laugh at you.
Then they fight you. And then you win." -Gandhi
Hi!
> >
> > > > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > > > only get the recent kernels to compile with sleep states if I
> > > > > turn *ON* software suspend as well. However, as soon as I
> > > > > turn on swsusp and get a compiled kernel, it oops'es on boot.
> > > >
> > > > Can you mail me decoded oops?
> > > > Pavel
> > >
> > > This is the first time I've decoded an oops, and since I had to
> > > decode it on a different kernel (2.5.25) than the one I'm
> > > debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
> >
> > Can you try passing
> > "resume=hda5_or_whatever_your_swap_partition_is"?
>
> Well, I've had "resume=/dev/hda6" in there the whole time (same as it
> was on prior kernels that booted). I tried passing "resume=hda6"
> instead just for kicks and got the same result, though... (This is
> still on the 2.5.50 + Dec6ACPI kernel)
Strange... Can you report if it is still broken with 2.5.51?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.