The system clock ist set to 01.01.1905 (!?) when booted through efi. it seems like the programe "hwclock --hctosys" is not run. is there a possibility to force the setting of of system clock to the hardware clock? who is responsible for the inital setting of the system clock? the kernel? Reproducible: Always
is the clock init.d script not being run ? that handles execution of the hwclock program
The clock init script is started in runlevel boot. After commenting these lines the system clock is set to the correct values: ebegin "Setting system clock using the hardware clock" "[${TBLURB}]" if [ ${fakeit} -eq 1 ] ; then retval=0 elif [ -x /sbin/hwclock ] ; then # Don't call hwclock unless we need to # if [ "${TBLURB}" != "UTC" -o "${myadj}" != "--noadjfile" ] ; then # Since hwclock always exit's with a 0, need to check its output. # errstr="$(/sbin/hwclock ${myadj} ${myopts} 2>&1 >/dev/null)" errstr="${errstr}$(/sbin/hwclock --hctosys ${myopts} 2>&1 >/dev/null)" # if [ -n "${errstr}" ] ; then # ewarn "${errstr}" # retval=1 # fi # errstr="Failed to set clock" # fi else retval=1 errstr="/sbin/hwclock not found" fi eend ${retval} "${errstr}" "You will need to set the clock yourself" return 0 So as far as i understand above code the program "hwclock --hctosys" is not called at start of the script "when not necessary". So i guess there is a difference how the kernel itself set the initial system date values. Please correct my if i'm wrong.
(In reply to comment #2) > So as far as i understand above code the program "hwclock --hctosys" is not > called at start of the script "when not necessary". > > So i guess there is a difference how the kernel itself set the initial system > date values. Please correct my if i'm wrong. That's probably the case. However, all systems should set the system clock to UTC from the hardware clock by default. We've tested on an EFI IA64 system, so it's not EFI related. Please attach your `emerge --info`. CC'ing kernel team to see if they have a clue also.
I get this error in the kernel log: Oops: efitime: can't read time status: 0x80000007 Here is the not so obvious call chain: -> timekeeping_init (kernel/time/timekeeping.c) -> read_persistent_clock() (arch/i386/kernel/time.c) -> get_wallclock() (include/asm-i386/time.h) -> native_get_wallclock() -> efi_get_time() (arch/i386/kernel/efi.c) So timekeeping_init() is called before efi_enter_virtual_mode() in init/main.c but this is correct and checked in efi_get_time(), so the physical efi call is made. The efi spec says that the caller to GetTime must synchronize the access to a PC-AT CMOS device. That's all. So, currently i'm a bit clueless. This error happens on a macbook pro first gen. with 2.6.23-rc5. The system date/time after boot is set to "Do 11. Mai 20:53:29 CET 1905"
For the record :-) Portage 2.1.3.7 (default-linux/x86/2006.1, gcc-4.2.0, glibc-2.6.1-r0, 2.6.23-rc5 i686) ================================================================= System uname: 2.6.23-rc5 i686 Genuine Intel(R) CPU T2400 @ 1.83GHz Gentoo Base System release baselayout-2.0.0_rc4 Timestamp of tree: Mon, 03 Sep 2007 18:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0_rc4 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18 sys-devel/gcc-config: 1.4.0-r2 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=prescott -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo" LANG="de_DE" LC_ALL="de_DE" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/thomas/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acpi alsa apache2 berkdb bitmap-fonts bzip2 cairo cli cracklib crypt cups dbus directfb dmi dri dts dvb dvd dvdread encode exif fam fbcon ffmpeg firefox flac fortran gd gdbm gif gnutls gphoto2 gpm gtk hal iconv ieee1394 imlib ipod ipv6 isdnlog java joystick jpeg jpeg2k kde kerberos ldap mad matroska midi mmx mp3 mpeg mudflap mysql nas ncurses nls nptl nptlonly nsplugin odbc offensive ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 readline reflection samba sdl session sox speex spell spl sse sse2 ssl svg tcl tcltk tcpd theora threads tiff tk truetype truetype-fonts type1-fonts unicode usb utempter v4l vorbis win32codecs wxwindows x86 xcb xine xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="fbdev radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
have this problem appeared only in 2.6.23-rc5?
No. 2.6.22 shows the same behaviour. Can somebody please confirm, that the (old) baselayout-1 always did set the system date with "hwclock --hctosys"?!
i'd point out it's pretty trivial for you to unpack an older release and read the init.d script yourself hwclock has always been run with hctosys at boot when possible
To be fair, we do not run hwclock if desired clock is UTC with no adjustment file (which is the default) as the kernel should have already set this already. baselayout-1 always ran hwclock regardless and always with an adjustment file, so to get the same effect from a baselayout perspective (ie hwclock is always run), simply set an adjustment file in /etc/conf.d/clock
Thomas, Can you please post your kernel .config and your dmesg output? Thanks.
Created attachment 131464 [details] dmesg output
Created attachment 131466 [details] config for linux kernel
According to the EFI specifications, error 0x80000007 is "The time could not be retrieved due to a hardware error." (That's the error code in this message: "Oops: efitime: can't read time status: 0x80000007"). So this looks like a hardware problem and not a kernel bug. Have you ever seen your EFI report the correct time, maybe while booting another distro/OS? Can you access the EFI time yourself, through a BIOS-like interface? Have you tried replacing your CMOS battery?
If you have reason to believe this is not a hardware issue and can provide the requested info, please reopen.
