All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] Re: Small pm documentation cleanups
Date: Tue, 05 Feb 2008 16:34:57 +1100	[thread overview]
Message-ID: <47A7F581.8060300@nigel.suspend2.net> (raw)
In-Reply-To: <200802050224.51039.rjw@sisk.pl>

Hi.

Rafael J. Wysocki wrote:
> Len, please pick this up, thanks.
> 
> On Tuesday, 5 of February 2008, Pavel Machek wrote:
>> Small documentation fixes/additions that accumulated in my tree.
>>
>> Signed-off-by: Pavel Machek <pavel@suse.cz>
> 
> Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> 
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index cf38689..3be3328 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -147,8 +147,10 @@ and is between 256 and 4096 characters. 
>>  			default: 0
>>  
>>  	acpi_sleep=	[HW,ACPI] Sleep options
>> -			Format: { s3_bios, s3_mode }
>> -			See Documentation/power/video.txt
>> +			Format: { s3_bios, s3_mode, s3_beep }
>> +			See Documentation/power/video.txt for s3_bios and s3_mode.
>> +			s3_beep is for debugging; it beeps on PC speaker as soon as
>> +			kernel's real-mode entry point is called.

s/kernel's/the kernel's/

>>  
>>  	acpi_sci=	[HW,ACPI] ACPI System Control Interrupt trigger mode
>>  			Format: { level | edge | high | low }
>> diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
>> index aea7e92..d3e5e4e 100644
>> --- a/Documentation/power/swsusp.txt
>> +++ b/Documentation/power/swsusp.txt
>> @@ -386,6 +386,11 @@ before suspending; then remount them aft
>>  There is a work-around for this problem.  For more information, see
>>  Documentation/usb/persist.txt.
>>  
>> +Q: Can I suspend-to-disk using a swap partition under LVM?
>> +
>> +A: No. You can suspend successfully, but you'll not be able to
>> +resume. uswsusp should be able to work with LVM, see suspend.sf.net.

s/LVM, see/LVM. See/

>> +
>>  Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
>>  compiled with the similar configuration files. Anyway I found that
>>  suspend to disk (and resume) is much slower on 2.6.16 compared to
>> diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
>> index fd1c4ba..058d0be 100644
>> --- a/drivers/acpi/hardware/hwsleep.c
>> +++ b/drivers/acpi/hardware/hwsleep.c
>> @@ -286,13 +286,13 @@ acpi_status asmlinkage acpi_enter_sleep_
>>  	}
>>  
>>  	/*
>> +	 * 1) Disable/Clear all GPEs
>>  	 * 2) Enable all wakeup GPEs
>>  	 */
>>  	status = acpi_hw_disable_all_gpes();
>>  	if (ACPI_FAILURE(status)) {
>>  		return_ACPI_STATUS(status);
>>  	}
>> -
>>  	acpi_gbl_system_awake_and_running = FALSE;
>>  
>>  	status = acpi_hw_enable_all_wakeup_gpes();
>> diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
>> index 485de13..56e09cf 100644
>> --- a/drivers/acpi/sleep/main.c
>> +++ b/drivers/acpi/sleep/main.c
>> @@ -170,7 +170,7 @@ static int acpi_pm_enter(suspend_state_t
>>  	/* Reprogram control registers and execute _BFS */
>>  	acpi_leave_sleep_state_prep(acpi_state);
>>  
>> -	/* ACPI 3.0 specs (P62) says that it's the responsabilty
>> +	/* ACPI 3.0 specs (P62) says that it's the responsibilty

s/responsibilty/responsibility/

>>  	 * of the OSPM to clear the status bit [ implying that the
>>  	 * POWER_BUTTON event should not reach userspace ]
>>  	 */
>> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
>> index ef9b802..b275ffb 100644
>> --- a/kernel/power/Kconfig
>> +++ b/kernel/power/Kconfig
>> @@ -74,14 +74,14 @@ config PM_TRACE_RTC
>>  	RTC across reboots, so that you can debug a machine that just hangs
>>  	during suspend (or more commonly, during resume).
>>  
>> -	To use this debugging feature you should attempt to suspend the machine,
>> -	then reboot it, then run
>> +	To use this debugging feature you should attempt to suspend the
>> +	machine, then reboot it, then run

More readable would be "machine, reboot it and then run"

>>  
>>  		dmesg -s 1000000 | grep 'hash matches'
>>  
>>  	CAUTION: this option will cause your machine's real-time clock to be
>>  	set to an invalid time after a resume.
>>  
>>  config PM_SLEEP_SMP
>>  	bool
>>  	depends on SMP
>> @@ -123,7 +129,8 @@ config HIBERNATION
>>  	  called "hibernation" in user interfaces.  STD checkpoints the
>>  	  system and powers it off; and restores that checkpoint on reboot.
>>  
>> -	  You can suspend your machine with 'echo disk > /sys/power/state'.
>> +	  You can suspend your machine with 'echo disk > /sys/power/state' 
>> +	  after placing resume=/dev/swappartition on kernel command line.

s/on kernel/on the kernel/

Maybe add "in your bootloader's configuration file"?

>>  	  Alternatively, you can use the additional userland tools available
>>  	  from <http://suspend.sf.net>.
>>  
>> diff --git a/kernel/power/main.c b/kernel/power/main.c
>> index 6a6d5eb..d3df5af 100644
>> --- a/kernel/power/main.c
>> +++ b/kernel/power/main.c
>> @@ -223,6 +226,7 @@ void __attribute__ ((weak)) arch_suspend
>>   *	@state:		state to enter
>>   *
>>   *	This function should be called after devices have been suspended.
>> + *	May not sleep.
>>   */
>>  static int suspend_enter(suspend_state_t state)
>>  {
>> @@ -250,6 +255,8 @@ static int suspend_enter(suspend_state_t
>>   *	suspend_devices_and_enter - suspend devices and enter the desired system
>>   *				    sleep state.
>>   *	@state:		  state to enter
>> + *
>> + *	Needs to be called from process context and may sleep.
>>   */
>>  int suspend_devices_and_enter(suspend_state_t state)
>>  {
>> @@ -341,6 +349,8 @@ static inline int valid_state(suspend_st
>>   *	happen when we wake up.
>>   *	Then, do the setup for suspend, enter the state, and cleaup (after
>>   *	we've woken up).
>> + *
>> + *	Needs to be called from process context, and may sleep.
>>   */
>>  static int enter_state(suspend_state_t state)
>>  {
>>
> 
> 
> 

Regards,

Nigel

  reply	other threads:[~2008-02-05  5:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04 23:47 Small pm documentation cleanups Pavel Machek
2008-02-05  1:24 ` Rafael J. Wysocki
2008-02-05  5:34   ` Nigel Cunningham [this message]
2008-02-05 18:27     ` [linux-pm] " Pavel Machek
2008-02-05 21:27       ` Jesper Juhl
2008-02-06 21:27       ` Nigel Cunningham
2008-02-06 21:31         ` Pavel Machek
2008-02-07  6:28         ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47A7F581.8060300@nigel.suspend2.net \
    --to=nigel@nigel.suspend2.net \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.