Maxim Levitsky | 1 Jul 01:31 2010
Picon

[REGRESSION] usb devices don't wake up the system

Hi,

This is my desktop, and I don't use it much.
I updated the kernel from 2.6.33 to 2.6.35-rc3, and my usb mouse (usb
1.1 of course) doesn't wake the system anymore.

I used (and still do) to enable wakeup via /proc/acpi/wakeup.

maxim <at> MAIN:~$ cat bin/system/wake_all 
#! /bin/bash

echo "UHC1" > /proc/acpi/wakeup		# ICH8 UHCI1
echo "UHC2" > /proc/acpi/wakeup		# ICH8 UHCI2
echo "UHC3" > /proc/acpi/wakeup		# ICH8 UHCI3
echo "UHC4" > /proc/acpi/wakeup		# ICH8 UHCI4
echo "UHC5" > /proc/acpi/wakeup		# ICH8 UHCI5

echo "ILAN" > /proc/acpi/wakeup		# ICH8 internal (lan/azal//EHCI)
echo "P32" >  /proc/acpi/wakeup 	# ICH8 external (PCI/PCI express)
echo "UAR1" > /proc/acpi/wakeup		# SUPERIO (UART/Sleep button)

I checked, and it looks like power/wakeup attributes are enabled:

root <at> MAIN:/sys/bus/pci/devices/0000:00:1d.0# cat power/wakeup 
enabled
root <at> MAIN:/sys/bus/pci/devices/0000:00:1d.0# cd usb5/
root <at> MAIN:/sys/bus/pci/devices/0000:00:1d.0/usb5# cat power/wakeup 
enabled
root <at> MAIN:/sys/bus/pci/devices/0000:00:1d.0/usb5# cd 5-1/
root <at> MAIN:/sys/bus/pci/devices/0000:00:1d.0/usb5/5-1# cat power/wakeup 
(Continue reading)

Rafael J. Wysocki | 1 Jul 01:40 2010
Picon

Re: [REGRESSION] usb devices don't wake up the system

On Thursday, July 01, 2010, Maxim Levitsky wrote:
> Hi,
> 
> 
> This is my desktop, and I don't use it much.
> I updated the kernel from 2.6.33 to 2.6.35-rc3, and my usb mouse (usb
> 1.1 of course) doesn't wake the system anymore.

Please wait for 2.6.35-rc4 to appear and see if there's any difference.

> I used (and still do) to enable wakeup via /proc/acpi/wakeup.
> 
> 
> maxim <at> MAIN:~$ cat bin/system/wake_all 
> #! /bin/bash
> 
> echo "UHC1" > /proc/acpi/wakeup		# ICH8 UHCI1
> echo "UHC2" > /proc/acpi/wakeup		# ICH8 UHCI2
> echo "UHC3" > /proc/acpi/wakeup		# ICH8 UHCI3
> echo "UHC4" > /proc/acpi/wakeup		# ICH8 UHCI4
> echo "UHC5" > /proc/acpi/wakeup		# ICH8 UHCI5
> 
> echo "ILAN" > /proc/acpi/wakeup		# ICH8 internal (lan/azal//EHCI)
> echo "P32" >  /proc/acpi/wakeup 	# ICH8 external (PCI/PCI express)
> echo "UAR1" > /proc/acpi/wakeup		# SUPERIO (UART/Sleep button)

That shouldn't be necessary.

> I checked, and it looks like power/wakeup attributes are enabled:
> 
(Continue reading)

Rafael J. Wysocki | 1 Jul 01:52 2010
Picon

Re: [update] Re: [PATCH] PM: Make it possible to avoid wakeup events from being lost

On Wednesday, June 30, 2010, Alan Stern wrote:
> On Wed, 30 Jun 2010, Rafael J. Wysocki wrote:
> 
> > > Since there's no longer any way to cancel a call to pm_wakeup_event()  
> > > or close the "no suspend" period early, there is no need to use
> > > dynamically-allocated delayed_work structures.  You can make do with a
> > > single static timer; always keep it set to expire at the latest time
> > > passed to pm_wakeup_event().
> > 
> > The decremenations of events_in_progress wouldn't be balanced with
> > incrementations this way.  Or do you have any clever way of dealing with
> > that in mind?
> 
> Keep track of the current expiration time in a static variable called
> wakeup_timeout, and use 0 to indicate there is no timeout.

I invented a slightly different version in the meantime, which is appended
as a patch on top of the original one (I don't want to modify the original
patch, since it's been reviewed already by several people and went to my
linux-next branch).

> In pm_wakeup_event() (everything protected by the spinlock):
> 
> 	unsigned long new_timeout = jiffies + msecs_to_jiffies(msecs);
> 	if (new_timeout == 0)
> 		new_timeout = 1;
> 
> 	++event_count;
> 	if (!wakeup_timeout || time_after(new_timeout, wakeup_timeout)) {
> 		if (!wakeup_timeout)
(Continue reading)

Maxim Levitsky | 1 Jul 02:28 2010
Picon

Re: [REGRESSION] usb devices don't wake up the system

On Thu, 2010-07-01 at 01:40 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 01, 2010, Maxim Levitsky wrote:
> > Hi,
> > 
> > 
> > This is my desktop, and I don't use it much.
> > I updated the kernel from 2.6.33 to 2.6.35-rc3, and my usb mouse (usb
> > 1.1 of course) doesn't wake the system anymore.
> 
> Please wait for 2.6.35-rc4 to appear and see if there's any difference.
Why should I?
I always compile from git.
Just pulled Linus' tree, and nothing changed.

Best regards,
	Maxim Levitsky

> 
> > I used (and still do) to enable wakeup via /proc/acpi/wakeup.
> > 
> > 
> > maxim <at> MAIN:~$ cat bin/system/wake_all 
> > #! /bin/bash
> > 
> > echo "UHC1" > /proc/acpi/wakeup		# ICH8 UHCI1
> > echo "UHC2" > /proc/acpi/wakeup		# ICH8 UHCI2
> > echo "UHC3" > /proc/acpi/wakeup		# ICH8 UHCI3
> > echo "UHC4" > /proc/acpi/wakeup		# ICH8 UHCI4
> > echo "UHC5" > /proc/acpi/wakeup		# ICH8 UHCI5
> > 
(Continue reading)

Shilimkar, Santosh | 1 Jul 06:27 2010
Picon

Re: Additional fix : (was [v2]printk: fix delayed messages from CPU hotplug events)

(Adding linux-pm <at> lists.linux-foundation.org)

> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Tuesday, June 29, 2010 2:22 PM
> To: 'Kevin Cernekee'
> Cc: linux-kernel <at> vger.kernel.org; Russell King - ARM Linux
> Subject: Additional fix : (was [v2]printk: fix delayed messages from CPU
> hotplug events)
> 
> Hi,
> 
> I have faced similar issue as what is being described in below with
> latest kernel.
> 
> ------------------------------------------------
> https://patchwork.kernel.org/patch/103347/
> 
> When a secondary CPU is being brought up, it is not uncommon for
> printk() to be invoked when cpu_online(smp_processor_id()) == 0.  The
> case that I witnessed personally was on MIPS:
> 
> http://lkml.org/lkml/2010/5/30/4
> 
> If (can_use_console() == 0), printk() will spool its output to log_buf
> and it will be visible in "dmesg", but that output will NOT be echoed to
> the console until somebody calls release_console_sem() from a CPU that
> is online.  Therefore, the boot time messages from the new CPU can get
> stuck in "limbo" for a long time, and might suddenly appear on the
> screen when a completely unrelated event (e.g. "eth0: link is down")
(Continue reading)

Sergey Senozhatsky | 1 Jul 08:17 2010
Picon

Re: [PATCH] cpuidle: avoid using smp_processor_id() in preemptible code (nr_iowait_cpu) v4

On (06/30/10 12:58), Andrew Morton wrote:
> Subject: Re: [PATCH] cpuidle: avoid using smp_processor_id() in
>  preemptible
>  code (nr_iowait_cpu) v4
> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
> 
> On Fri, 25 Jun 2010 16:39:33 +0200
> Peter Zijlstra <peterz <at> infradead.org> wrote:
> 
> > On Thu, 2010-06-17 at 09:29 +0300, Sergey Senozhatsky wrote:
> > > Fix
> > >    
> > >  BUG: using smp_processor_id() in preemptible [00000000] code: s2disk/3392
> > 
> > > The initial fix was to use get_cpu/put_cpu in nr_iowait_cpu.  However,
> > > Arjan stated that "the bug is that it needs to be nr_iowait_cpu(int cpu)".
> > > 
> > > This patch introduces nr_iowait_cpu(int cpu) and changes to its callers.
> > > 
> > > Arjan also pointed out that we can't use get_cpu/put_cpu in update_ts_time_stats
> > > since we "pick the current cpu, rather than the one denoted by ts" in that case.
> > > To match given *ts and cpu denoted by *ts we use new field in the struct tick_sched: int cpu.
> > 
> > 
> > > diff --git a/include/linux/tick.h b/include/linux/tick.h
> > > index b232ccc..db14691 100644
> > > --- a/include/linux/tick.h
> > > +++ b/include/linux/tick.h
> > >  <at>  <at>  -51,6 +51,7  <at>  <at>  struct tick_sched {
> > >  	unsigned long			check_clocks;
(Continue reading)

Peter Zijlstra | 1 Jul 09:07 2010

[PATCH] sched: Cure nr_iowait_cpu() users

With 0224cf4c5e (sched: Intoduce get_cpu_iowait_time_us()) Arjan broke
things by not making sure preemption was indeed disabled by the callers
of nr_iowait_cpu() which took the iowait value of the current cpu.

This resulted in a heap of preempt warnings. Cure this by making
nr_iowait_cpu() take a cpu number and fix up the callers to pass in the
right number.

Signed-off-by: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
---
Confirmed to work..

 drivers/cpuidle/governors/menu.c |    4 ++--
 include/linux/sched.h            |    2 +-
 kernel/sched.c                   |    4 ++--
 kernel/time/tick-sched.c         |   16 ++++++++--------
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 52ff8aa..1b12870 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
 <at>  <at>  -143,7 +143,7  <at>  <at>  static inline int which_bucket(unsigned int duration)
 	 * This allows us to calculate
 	 * E(duration)|iowait
 	 */
-	if (nr_iowait_cpu())
+	if (nr_iowait_cpu(smp_processor_id()))
 		bucket = BUCKETS/2;

(Continue reading)

Sergey Senozhatsky | 1 Jul 10:18 2010
Picon

Re: [PATCH] sched: Cure nr_iowait_cpu() users

Acked-by: Sergey Senozhatsky <sergey.senozhatsky <at> gmail.com> (??)

	Sergey

On (07/01/10 09:07), Peter Zijlstra wrote:
> Subject: [PATCH] sched: Cure nr_iowait_cpu() users
> X-Mailer: Evolution 2.28.3 
> 
> With 0224cf4c5e (sched: Intoduce get_cpu_iowait_time_us()) Arjan broke
> things by not making sure preemption was indeed disabled by the callers
> of nr_iowait_cpu() which took the iowait value of the current cpu.
> 
> This resulted in a heap of preempt warnings. Cure this by making
> nr_iowait_cpu() take a cpu number and fix up the callers to pass in the
> right number.
> 
> Signed-off-by: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
> ---
> Confirmed to work..
> 
>  drivers/cpuidle/governors/menu.c |    4 ++--
>  include/linux/sched.h            |    2 +-
>  kernel/sched.c                   |    4 ++--
>  kernel/time/tick-sched.c         |   16 ++++++++--------
>  4 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index 52ff8aa..1b12870 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
(Continue reading)

Pavel Machek | 1 Jul 15:32 2010
Picon

Re: [PATCH] PM: Make it possible to avoid wakeup events from being lost

Hi!

>  <at>  <at>  -114,3 +114,17  <at>  <at>  Description:
>  		if this file contains "1", which is the default.  It may be
>  		disabled by writing "0" to this file, in which case all devices
>  		will be suspended and resumed synchronously.
> +
> +What:		/sys/power/wakeup_count
> +Date:		July 2010
> +Contact:	Rafael J. Wysocki <rjw <at> sisk.pl>
> +Description:
> +		The /sys/power/wakeup_count file allows user space to avoid
> +		losing wakeup events when transitioning the system into a sleep
> +		state.  Reading from it returns the current number of registered
> +		wakeup events and it blocks if some wakeup events are being
> +		processed at the time the file is read from.  Writing to it
> +		will only succeed if the current number of wakeup events is
> +		equal to the written value and, if successful, will make the
> +		kernel abort a subsequent transition to a sleep state if any
> +		wakeup events are reported after the write has returned.

I assume that second suspend always succeeds?

I can't say I quite like the way two sysfs files interact with each
other, but it is certainly better then wakelocks...

Maybe we should create sys_suspend()?

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(Continue reading)

Raj Kumar | 1 Jul 15:54 2010
Picon

Re: About run time power management in linux

 
Hi Alan,
 
I have seen in run time power management helper functions. I have some questions during deep sleep modes
and runtime sleep modes.
 
1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for
pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.
So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?
 
2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and
if it is zero then it will ask try again.
 
3) if run time suspend is going on,  Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then
gracefully do the shutdown. correct?
 
4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?
 
RegardsRaj
 
 
 
 
 
 
 
 
 

 
> Date: Wed, 30 Jun 2010 12:25:21 -0400
> From: stern <at> rowland.harvard.edu
> To: rajkumar278 <at> hotmail.com
> CC: linux-pm <at> lists.linux-foundation.org
> Subject: RE: [linux-pm] About run time power management in linux
>
> On Wed, 30 Jun 2010, Raj Kumar wrote:
>
> > Hi Alan,
> >
> >
> >
> > First thanks for reply. ok as also seems to be in runtime.c, if device wants to suspend and resume
> >
> >
> >
> > then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,
> >
> >
> >
> > which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.
> >
> >
> >
> > correct ?
>
> Yes.
>
> Alan Stern
>
<div>
&nbsp;<br>
Hi Alan,<br>
&nbsp;<br>
I have seen in&nbsp;run time power management helper functions. I have some questions during deep sleep modes<br>
and runtime sleep modes.<br>
&nbsp;<br>
1)&nbsp;I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for<br>
pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.<br>
So it means system suspend can not be done forcefully&nbsp;if the&nbsp;some peripheral jobs are running, correct?<br>
&nbsp;<br>
2) it means when System deep sleep is going on, run time suspend will never come&nbsp;to peripheral as it checks for usage counter and<br>
if it is zero then it will ask try again.<br>
&nbsp;<br>
3) if run time suspend is going on, &nbsp;Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then <br>
gracefully do the shutdown. correct?<br>
&nbsp;<br>
4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?<br>
&nbsp;<br>
RegardsRaj<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br><br>&nbsp;<br>&gt; Date: Wed, 30 Jun 2010 12:25:21 -0400<br>&gt; From: stern <at> rowland.harvard.edu<br>&gt; To: rajkumar278 <at> hotmail.com<br>&gt; CC: linux-pm <at> lists.linux-foundation.org<br>&gt; Subject: RE: [linux-pm] About run time power management in linux<br>&gt; <br>&gt; On Wed, 30 Jun 2010, Raj Kumar wrote:<br>&gt; <br>&gt; &gt; Hi Alan,<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; First thanks for reply. ok as also seems to be in runtime.c, if device wants to suspend and resume<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; correct ?<br>&gt; <br>&gt; Yes.<br>&gt; <br>&gt; Alan Stern<br>&gt; <br>
</div>

Gmane