On Thursday 12 June 2008, Joey Hess wrote: > > On Thursday 12 June 2008, Franklin Piat wrote: > > > However, there's a clock bug : > > > > # hwclock > > > > select() to /dev/rtc to wait for clock tick timed out > > > > hwclock --directisa > > > > Thu 12 Jun 2008 01:00:01 AM CEST -0.461109 seconds > > > > > > (looks similar to > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397096 ) > > > Workround: add "HWCLOCKPARS=--directisa" in /etc/default/rcS > > > > We continue to see this fairly regularly. There are also various BRs > > open against util-linux for this. > > There's also a bug open on the kernel with this, with a known fix of > changing a config option (CONFIG_HPET_EMULATE_RTC). #398449 Not sure if that would fix all cases. > Using genrtc rather than the rtc module also works for me. > > I've been thinking that this bug should be RC. It affects installed > systems too; not having a working hardware clock is not good. Seems not even present in the -686 config for .24, which normally indicates that it cannot be set... That's special as from lkml I can see that it's an option that should be set automatically. Maybe that was screwed up for some time. There has been a lot of discussion about RTC migration on lkml the past few months. Not sure if that was this exact issue though. Looks like 2.6.25 will fix it: $ grep -E "HPET_(TIMER|EMU)" /boot/config-2.6.2* /boot/config-2.6.24-1-686:CONFIG_HPET_TIMER=y (only .24 installed) /boot/config-2.6.25-2-486:CONFIG_HPET_TIMER=y /boot/config-2.6.25-2-486:CONFIG_HPET_EMULATE_RTC=y /boot/config-2.6.25-2-686:CONFIG_HPET_TIMER=y /boot/config-2.6.25-2-686:CONFIG_HPET_EMULATE_RTC=y /boot/config-2.6.25-2-686-bigmem:CONFIG_HPET_TIMER=y /boot/config-2.6.25-2-686-bigmem:CONFIG_HPET_EMULATE_RTC=y /boot/config-2.6.25-2-amd64:CONFIG_HPET_TIMER=y /boot/config-2.6.25-2-amd64:CONFIG_HPET_EMULATE_RTC=y Dann, how's this in .24 for etch+1/2? Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.