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] [day] [month] [year] [list]
Date:	Mon, 12 Dec 2011 17:40:41 +0100
From:	Andreas Friedrich <afrie@....net>
To:	Rabin Vincent <rabin.vincent@...ricsson.com>
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

On Mo, Dez 12, 2011 at 02:51:39 +0530, Rabin Vincent wrote:

Hello Rabin,

> (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.

I've added some system info:
   dmesg.txt
   linux-3.1.5.config.txt
   lshw.txt
   lspci-vvv.txt
   proc_driver_rtc.txt

I'm using a vanilla kernel without modules. Please tell me if I can
help to find the problem (enable kernel debugs or something else).

Regards Andreas

Download attachment "auto_poweron_3.1.5.tar.gz" of type "application/x-compressed-tar" (40130 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ