linux-kernel - Re: REGRESSION 3.1.5: 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-next>] [day] [month] [year] [list]

Message-ID: <20111211212110.GA8839@bnru05.bnr.st.com>
Date:	Mon, 12 Dec 2011 02:51:39 +0530
From:	Rabin Vincent <rabin.vincent@...ricsson.com>
To:	Andreas Friedrich <afrie@....net>
Cc:	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	<rtc-linux@...glegroups.com>, <linux-kernel@...r.kernel.org>
Subject: Re: REGRESSION 3.1.5: auto poweron after 5 minutes

(CCing the lists)

On Sat, Dec 10, 2011 at 15:09:08 +0100, Andreas Friedrich wrote:
> with kernel 3.1.5 I've got a problem on my Toshiba Tecra notebook:
> 
> After shuting down my system as usual, it powers on automatically
> after about 5 minutes. With kernel 3.1.4 the system stays off.
> 
> After wondering around some time I read something about "ACPI RTC
> wakealarm" and found the description of your fix in the changelog of
> kernel 3.1.5:
> 
>   commit 0cbc008c56f7b4a11ba6fe80e196d7ab322baabf
>   Author: Rabin Vincent <rabin.vincent@...ricsson.com>
>   Date:   Tue Nov 22 11:03:14 2011 +0100
> 
>       rtc: Disable the alarm in the hardware
> 
>       commit c0afabd3d553c521e003779c127143ffde55a16f upstream.
> 
>       Currently, the RTC code does not disable the alarm in the hardware.
> 
>       This means that after a sequence such as the one below (the files are in the
>       RTC sysfs), the box will boot up after 2 minutes even though we've
>       asked for the alarm to be turned off.
> 
>           # echo $((`cat since_epoch`)+120) > wakealarm
>           # echo 0 > wakealarm
>           # poweroff
> 
>       Fix this by disabling the alarm when there are no timers to run.
> 
> So may be your fix caused the opposite reaction on my system. Have you
> any ideas to fix this problem?

That patch, in order to disable the alarm, calls set_alarm() on the
RTC driver with alarm->enabled as zero (and a time value that is five
minutes ahead).

Perhaps the ACPI RTC driver enables the alarm even when alarm->enable
is zero?  There appears to be handling for this in rtc-cmos.c (I assume
that's what is being used) but I don't know enough about that hardware
to say if that's sufficient or not.
--
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/