rtc_cmos: error after first write to wakealarm

On Fri, 15 Jun 2007 08:33:08 +0200

Post by Tino Keitel
Hi,
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
bash: echo: write error: Device or resource busy
$ rmmod rtc_cmos
$ modprobe rtc_cmos
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
bash: echo: write error: Device or resource busy
$

If the alarm has already been enabled, you cannot set the next alarm.
You should disable first.

Ah, ok.

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.

Regards,
Tino

Alessandro Zummo

2007-06-19 12:24:04 UTC

On Fri, 15 Jun 2007 09:03:19 +0200

Post by Tino Keitel
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
bash: echo: write error: Device or resource busy
$ rmmod rtc_cmos
$ modprobe rtc_cmos
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
$ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
bash: echo: write error: Device or resource busy
$

If the alarm has already been enabled, you cannot set the next alarm.
You should disable first.

Ah, ok.
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.

--
Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it

Tino Keitel

2007-06-19 17:24:29 UTC

Post by Alessandro Zummo
On Fri, 15 Jun 2007 09:03:19 +0200

If the alarm has already been enabled, you cannot set the next
alarm. You should disable first.

Ah, ok.
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?

I don't know if there is any centralized form sysfs documentation. I
guess not. So at least a short text like the one below somewhere in
Documentation/ would be useful.

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?

-----------------------------------------------------------------------

How to use /sys/class/rtc/rtcX/wakealarm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This file takes the seconds since epoch to enable a wake event at the
specified time.

If a '0' is written, the alarm is disabled.

If the alarm was already enabled, a new alarm can only be set after the
old alarm is disabled.

Migration from /proc/acpi/alarm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Users of /proc/acpi/alarm have to change their code to supply the
seconds since epoch instead of a date string.

For shell scripts, this can be done using the date command, e.g. like
this:

date -d tomorrow "+%s"

This returns the seconds since epoch of the current time on the
following day.

Please note that you have to disable the old alarm first, if you want
to set a new alarm. Otherwise, you get an error. Example:

echo 12345 > /sys/class/rtc/rtc0/wakealarm
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo 23456 > /sys/class/rtc/rtc0/wakealarm

-----------------------------------------------------------------------

Regards,
Tino

Alessandro Zummo

2007-06-22 17:34:31 UTC

On Tue, 19 Jun 2007 19:24:29 +0200

Post by Tino Keitel
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?
I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to
$ 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?

I'll have to check that. Sorry for the delay, i've been a bit busy.

--
Best regards,

Alessandro Zummo,
Tower Technologies - Torino, Italy

http://www.towertech.it

David Brownell

2007-06-22 18:45:52 UTC

Post by Alessandro Zummo
On Tue, 19 Jun 2007 19:24:29 +0200

Post by Tino Keitel
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.

Post by Tino Keitel
I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to
$ 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

Post by Alessandro Zummo
I'll have to check that. Sorry for the delay, i've been a bit busy.
--

Tino Keitel

2007-06-22 19:44:17 UTC

Post by David Brownell

Post by Alessandro Zummo
On Tue, 19 Jun 2007 19:24:29 +0200

Post by Tino Keitel
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?

What GIT comment are you referring to?

Post by David Brownell
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.

What RTC driver is that using?

rtc_cmos

Post by David Brownell
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".

With the old /proc/acpi/alarm, the year 2007 became 0007. Maybe this is
the culprit?

Regards,
Tino

David Brownell

2007-06-23 03:18:53 UTC

[ please don't edit folk off the cc list unless you *know* they
are getting duplicates ... ]

Post by David Brownell
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.

What GIT comment are you referring to?

What "git log drivers/rtc/rtc-sysfs.c" shows ... date Feb 12.
The web interface shows it too.

Post by David Brownell
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".

With the old /proc/acpi/alarm, the year 2007 became 0007. Maybe this is
the culprit?

That's essentially the same issue. It needs some sort
of generic fix at the rtc_read_alarm() level.

Yoichi Yuasa

2007-06-15 06:59:04 UTC