Re: RTC wakealarm write-only, still has 644 permissions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

Sorry for long delay. I got rtc wakeup to work... once per boot. On
2.6.24-rc3.


> > > root@amd:/sys/class/rtc/rtc0# ls -al wakealarm 
> > > -rw-r--r-- 1 root root 0 Sep 20 12:30 wakealarm
> > > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> 
> The alarm isn't set; so no value gets displayed.
> 
> 
> > > root@amd:/sys/class/rtc/rtc0# 
> > > 
> > > 
> > > ...standard PC with reasonably recent kernel...
> 
> Yeah, well a "standard PC" is chock full of fairly bizarrely
> glitchey hardware.  Clocks and timers have more than their
> fair share, or x86_64 NOHZ support would be merged by now!

Oops. Ok, this is thinkpad x60, if that helps.

> > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > 2051629528
> > root@amd:/sys/class/rtc/rtc0# date +%s
> > 1190285030
> 
> OK, in that situation you've definitely got some buglike behavior.
> My question is:  how to fix it?
> 
> The problem is that the RTC is reporting an alarm value with some
> fields flagged as "wildcard" -- e.g. day/month/year "out of range"
> so the hardware ignores those fields.  This is very common on PC
> based RTCs, and much less common on embedded systems.  (Which for
> some reason don't tend to cheap out on full date specs like PCs.)

I see... so situation is not nice :-(.

> I'm not sure which fix would be best; maybe Alessandro has an
> opinion.

Alessandro?

> Better might be
> 
> 	echo $(( $(cat since_epoch) + 20 )) > wakealarm
> 
> which has no timezone offset issues.

Good. that actually works.

> > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > root@amd:/sys/class/rtc/rtc0# 
> > 
> > Also, is there some documentation for wakealarm?
> 
> "git show 3925a5ce44330767f7f0de5c58c6a797009f0f75" has some.

Thanks. Will put it into Doc*/rtc.txt.

> Are you sure it's not working?  Other than the two issues I noted
> above -- borkage w.r.t. ACPI (which wasn't necessarily shown in your
> scripts above), and with wildcarding -- it looked to be correct.

It seems to be working now, not sure what changed.

rtc-sysfs.c: why this?

        if (alarm > now) {
                /* Avoid accidentally clobbering active alarms; we
can't
                 * entirely prevent that here, without even the
minimal
                 * locking from the /dev/rtcN api.
                 */
                retval = rtc_read_alarm(rtc, &alm);
                if (retval < 0)
                        return retval;
                if (alm.enabled)
                        return -EBUSY;

                alm.enabled = 1;

People should not be "accidentally" writing to sysfs files...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux