linux-kernel - Re: REGRESSION 3.2-rcX: RTC auto poweron after 5 minutes

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]

Date:	Tue, 3 Jan 2012 00:10:07 +0100
From:	Andreas Friedrich <afrie@....net>
To:	Rabin Vincent <rabin@....in>
Cc:	john.stultz@...aro.org, gregkh@...e.de, torvalds@...l.org,
	Wolfgang Erig <Wolfgang.Erig@...fujitsu.com>,
	linux-kernel@...r.kernel.org, rtc-linux@...glegroups.com
Subject: Re: REGRESSION 3.2-rcX: RTC auto poweron after 5 minutes

On Di, Dez 27, 2011 at 08:07:05 +0530, Rabin Vincent wrote:

Hello Rabin,
...
> Perhaps we can avoid your five-minute problem by just attempting
> to disable the irq without setting a new alarm time (not yet tested):
> 
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
...
I have tested your patch and for me it works!

> btw, if you haven't done so yet, could you please confirm that it's not
> something in your userspace which is _asking_ for the alarm to be
> enabled?  You could add a printk() of the 'enabled' argument into
> cmos_alarm_irq_enable() to do this (and one in cmos_set_alarm()
> wouldn't hurt too).

No, I haven't done this test, because my environment didn't change
when testing the two different kernel versions.

Nevertheless I have added the printk() calls starting with the string
'afrie:' in cmos_alarm_irq_enable() and cmos_set_alarm(). The console
output was captured by a second PC via serial line:

When booting there are no extra log messages (see boot.log).

Wenn calling 'init 0' there are 3 extra messages. I have tested it
with and without your patch (refer to init_0_with_patch.log and
init_0_without_patch.log). The last one is always a 'disable' message
but I found the following difference: In the 'patched' case the
disable message comes from cmos_alarm_irq_enable(). In the other case
the disable message comes from cmos_set_alarm(). May be you can
explain what's going on?

With best regards,
Andreas

Download attachment "logs.tar.gz" of type "application/x-compressed-tar" (13336 bytes)