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: <200706221145.53157.david-b@pacbell.net>
Date:	Fri, 22 Jun 2007 11:45:52 -0700
From:	David Brownell <david-b@...bell.net>
To:	Alessandro Zummo <alessandro.zummo@...ertech.it>
Cc:	Tino Keitel <tino.keitel@....de>, rtc-linux@...glegroups.com,
	Yoichi Yuasa <yoichi_yuasa@...peaks.co.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm

On Friday 22 June 2007, Alessandro Zummo wrote:
> On Tue, 19 Jun 2007 19:24:29 +0200
> Tino Keitel <tino.keitel@....de> wrote:
> 
> > > > Where is the documentation that describes that I have to disable it
> > > > first, and how to do this? A migration document for
> > > > /proc/acpi/alarm users would be nice, too.
> > > 
> > >  Well, I guess there is no documentation. Maybe we could add
> > >  a dev_warn with an explicit message.
> > 
> > Isn't it somewhat ridiculous to plan the removal of a feature for
> > several months, and then replace it with something that behaves
> > differently without any documentation?

It's got as much documentation in the kernel tree as that
old /proc/acpi/alarm thing.  More, in fact, since the GIT
comment for the putback creating /sys/rtc/.../wakealarm
files has lots of info about how to use it.

But sure, having documentation for the rtc sysfs interface
would be a Fine Thing.  It should cover the other values
too, not just that one attribute.


> > I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to
> > behave. With 2.6.22-rc5, I get this:
> > 
> > $ echo 1182351177 > /sys/class/rtc/rtc0/wakealarm 
> > $ cat /sys/class/rtc/rtc0/wakealarm
> > 2051644873
> > 
> > There seems to be a constant difference of 869984896 seconds. Is this a
> > bug?

What RTC driver is that using?

One theory:  it's an RTC that doesn't support all the fields,
so its driver is returning "-1" in fields like "year" or "month".

Right now there's no code forcing rtc_read_alarm() to return
values for which rtc_valid_tm(&alarm->time), and bogus values
in wakealarm would be a symptom.  I suspect most of the systems
I tested the "wakealarm" attribute with have RTC alarms that
don't have those particular deficiencies.

- Dave

> 
>  I'll have to check that. Sorry for the delay, i've been a bit busy.
> 
> 
> -- 
> 
-
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