Hi,
I have the following strange behaviour with rtc_cmos:
$ 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
$
The kernel is git eedab661a51966c454e38c17266a531aa58b4a98 (something
after 2.6.22-rc4).
Regards,
Tino
On Fri, Jun 15, 2007 at 15:59:04 +0900, Yoichi Yuasa wrote:
> On Fri, 15 Jun 2007 08:33:08 +0200
> Tino Keitel <[email protected]> wrote:
>
> > Hi,
> >
> > I have the following strange behaviour with rtc_cmos:
> >
> > $ 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
On Fri, 15 Jun 2007 08:33:08 +0200
Tino Keitel <[email protected]> wrote:
> Hi,
>
> I have the following strange behaviour with rtc_cmos:
>
> $ 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.
Yoichi
On Fri, 15 Jun 2007 09:03:19 +0200
Tino Keitel <[email protected]> wrote:
> > > I have the following strange behaviour with rtc_cmos:
> > >
> > > $ 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
On Tue, Jun 19, 2007 at 14:24:04 +0200, Alessandro Zummo wrote:
> On Fri, 15 Jun 2007 09:03:19 +0200
> Tino Keitel <[email protected]> wrote:
>
> > > > I have the following strange behaviour with rtc_cmos:
> > > >
> > > > $ 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.
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
On Tue, 19 Jun 2007 19:24:29 +0200
Tino Keitel <[email protected]> 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?
>
> 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?
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
On Friday 22 June 2007, Alessandro Zummo wrote:
> On Tue, 19 Jun 2007 19:24:29 +0200
> Tino Keitel <[email protected]> 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.
>
>
> --
>
On Fri, Jun 22, 2007 at 11:45:52 -0700, David Brownell wrote:
> On Friday 22 June 2007, Alessandro Zummo wrote:
> > On Tue, 19 Jun 2007 19:24:29 +0200
> > Tino Keitel <[email protected]> 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.
What GIT comment are you referring to?
>
> 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?
rtc_cmos
>
> 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
[ please don't edit folk off the cc list unless you *know* they
are getting duplicates ... ]
> > 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.
> > 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.