linux-kernel - Re: [PATCH] alarmtimer: add error prints when suspend failed

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51399243.6050007@nvidia.com>
Date:	Fri, 8 Mar 2013 12:54:51 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"toddpoynor@...gle.com" <toddpoynor@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] alarmtimer: add error prints when suspend failed

On Friday 08 March 2013 04:46 AM, Greg KH wrote:
> On Fri, Mar 08, 2013 at 12:57:37AM +0530, Laxman Dewangan wrote:
>> The alramtimer suspend failed when nearest alarm wakeup time is
>> less than 2 sec or rtc timer can not start.
>>
>> In suspend/resume stress testing, we found that sometimes alramtimer
>> failed to suspend and hence it cancel the suspend ops. Add error prints
>> in suspend failure to provide more info when failure occurs to help
>> debugging.
>>
>> Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>
>> ---
>>   kernel/time/alarmtimer.c |    6 +++++-
>>   1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
>> index f11d83b..eed5646 100644
>> --- a/kernel/time/alarmtimer.c
>> +++ b/kernel/time/alarmtimer.c
>> @@ -249,6 +249,8 @@ static int alarmtimer_suspend(struct device *dev)
>>   
>>   	if (ktime_to_ns(min) < 2 * NSEC_PER_SEC) {
>>   		__pm_wakeup_event(ws, 2 * MSEC_PER_SEC);
>> +		dev_err(dev,
>> +			"Nearest alarm wakeup time < 2sec, avoiding suspend\n");
> What can userspace now do with this information?  How often is this now
> going to spam the syslog and cause confusion?


When we executed the stress on suspend/resume for system stability, 
occasionally we get such error (3/4 times in 1000 cycle):
[ 235.508010] dpm_run_callback(): platform_pm_suspend+0x0/0x64 returns -16
[ 235.514999] PM: Device alarmtimer failed to suspend: error -16
[ 235.520958] PM: Some devices failed to suspend


After tracing back the failure case, we found that possible reason could 
be above one.
In this case, if any function returns error then always better to print 
the error so that it is easy to findout the cause of the error and analyse.

It should not generate spam as this does happen on some cases.


--
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/