lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11925125.x6prlrSt00@vostro.rjw.lan>
Date:	Fri, 14 Mar 2014 02:06:42 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Ruchi Kandoi <kandoiruchi@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Greg Hackmann <ghackmann@...gle.com>,
	John Stultz <john.stultz@...aro.org>,
	Todd Poynor <toddpoynor@...gle.com>
Subject: Re: [PATCH v3] power: add an API to log wakeup reasons

On Thursday, March 13, 2014 05:43:20 PM Ruchi Kandoi wrote:
> This should be true most of the times.
> 
> But there might be cases otherwise too.
> 
> For instance, there was a bug earlier with wi-fi which would cause the
> system to wake up but not get hold of a wakeup source because there
> wasn't any work for it to do. In that case, the wakeup sources would
> not log such an event.
> 
> Additionally, there could be a situation where an IRQ caused the
> system to resume from suspend. And since the system was up, a driver
> could take a wakeup source. In this case we would assume that the
> driver would have woken the system, but in reality the driver held the
> wakeup source only because the system was up and did not cause the
> wake up to happen.

But you can create special wakeup sources associated with interrupts (in
addition to the existing ones) and use the statistics for those.

It is possible to define wakeup sources that don't correspond to any
devices.

Rafael


> On Thu, Mar 13, 2014 at 3:18 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > Hi,
> >
> > I saw the v4, but I don't have it handy, so replying here.
> >
> > On Wednesday, March 12, 2014 12:46:38 PM Ruchi Kandoi wrote:
> >> For power management diagnostic purposes, it is often useful to know
> >> what interrupts are frequently waking the system from low power
> >> suspend mode, especially on battery-powered consumer electronics
> >> devices that are expected to spend much of their time in low-power
> >> suspend while not in active use.  For example, reduced battery life on
> >> a mobile phone may be caused in part by frequent wakeups by broadcast
> >> traffic on a busy wireless LAN even while the screen is off and the
> >> phone not in active use.
> >>
> >> Add API log_wakeup_reason() exposes it to userspace via the sysfs path
> >> /sys/kernel/wakeup_reasons/last_resume_reason. This API would be called
> >> from the paltform specific, or from the driver for the interrupt controller,
> >> when the system resumes because of an IRQ. It logs the reasons which caused
> >> the system to wakeup from the low-power mode.
> >
> > So what exactly is wrong with using wakeup sources for this purpose?
> >
> > --
> > I speak only for myself.
> > Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ