Here is another strange thing, timezone info is not preserved through reboots (this is w/o _any_ network connection) and then hwclock and date although reported in the same timezone they have different time eg: [r...@localhost olpc]# hwclock Fri 14 Aug 2009 05:14:30 PM CEST -0.042609 seconds [r...@localhost olpc]# date Fri Aug 14 23:14:53 CEST 2009
although the control panel timezone is in CEST+2 and the /etc/adjtime is polulated with: [r...@localhost olpc]# more /etc/adjtime 0.000000 1250285471 0.000000 1250285471 LOCAL Doing an ntpdate update puts th clock in the right timezone without affecting the hwclock. One strange thing I notice looking for localtime files with mc and hitting Edit by mistake (the first time :) is that both /etc/localtime or /etc/avahi/etc/localtime said "converting from Mac format" when opened for editing. Is this normal? I do not know to what extend the timezone problem may be related to the rtcwake problems but is strange on its own. --- On Fri, 8/14/09, Paul Fox <[email protected]> wrote: > From: Paul Fox <[email protected]> > Subject: Re: New F11 for the XO-1 build 5 > To: "Yioryos Asprobounitis" <[email protected]> > Cc: "OLPC Development" <[email protected]>, "OLPC Testing" > <[email protected]>, "Fedora OLPC List" <[email protected]> > Date: Friday, August 14, 2009, 8:31 AM > yioryos wrote: > > > > > > --- On Thu, 8/13/09, Paul Fox <[email protected]> > wrote: > > > > > From: Paul Fox <[email protected]> > > > Subject: Re: New F11 for the XO-1 build 5 > > > To: "Yioryos Asprobounitis" <[email protected]> > > > Cc: "OLPC Development" <[email protected]>, > "OLPC Testing" > > <[email protected]>, > "Fedora OLPC List" <[email protected]> > > > Date: Thursday, August 13, 2009, 5:50 PM > > > hi yioryos -- > > > > > > yioryos wrote: > > > > > > > > --- On Thu, 8/13/09, James Cameron > <[email protected]> > wrote: > > > > > > > > > > rtcwake testing has shown that > it needs --utc after the > > > > > first shutdown. > > > > > Prior to then the /etc/adjtime > file is zero. > > > > > > > > > > > > > In my hands both time 'rtcwake -um > mem -a -s 10' and 'time > > > > rtcwake -m mem -a -s 10' are a hit > and miss. '-um' is better > > > > (~50%) while without the UCT option > is hardly 10%. Usually > > > > > > what exactly do you mean, by "50%" and "10%". > rtcwake > > > doesn't wake at all? wakes too soon? > > > > Either. 10, 50% sucess means wakeup in 11-12sec > > okay. waking too soon means you were woken by > something > other than the RTC. you can "cat > /sys/power/wakeup-source" > to see what it was. > > > > hmm. i think we need to step back a bit. > > > > > > let's ignore powerd for now -- please disable it > with: > > > # initctl stop powerd > > > > > > then, let's get rid of spurious wakeups, by > turning off > > > most wakeup events: > > > # echo 0 > > > > /sys/power/wakeup_events/all > > > > > > the lid, the power button, and the RTC alarm > should still > > > be > > > capable of waking the system at this point. > > > > > > now run: > > > # rtcwake --utc -m mem -s 10 > > > > > > > As JC reported, under these conditions the XO wakes > up reliably. > > excellent. so rtcwake is reliable, except for the > timezone issue. > > thanks for your testing. olpc-powerd-10-1.fc11 should > be > available soon, which contains a workaround for the > rtcwake > issue. (you can try it sooner by simply adding > "--utc" to each > of the rtcwake commandlines in the powerd script.) > and quozl and > i have brought the issue to the attention of the > util-linux-ng > folks. (it actually seems that the kernel might be > treating the > daylight savings time field from the RTC a little too > casually.) > > paul > =--------------------- > paul fox, [email protected] > _______________________________________________ Testing mailing list [email protected] http://lists.laptop.org/listinfo/testing
