Since updating to the 2.6.12-gentoo-r4 kernel, my machines clocks go crazy. They go wrong for a couple of minutes per hours. Well, I'm not really sure if this is a kernel issue (after all, I haven't had this before), but anyway, since the update the clocks on my three machines go crazy - besides chrony, which should take care of time setting. Any ideas? Reproducible: Always Steps to Reproduce: guess it was installing the current kernel Actual Results: computers clock goes wrong Expected Results: guess the time should be right :) enina ~ # emerge info Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.5-r0, 2.6.1 2-gentoo-r4 i686) ================================================================= System uname: 2.6.12-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.12 dev-lang/python: 2.3.4-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share /config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/ mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/ distributions/gentoo" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa apache2 apm arts avi berkdb bitmap-fonts cdr cjk cr ypt cups curl dvd dvdr eds emboss encode esd evo fam foomaticdb fortran gdbm gif glx gnome gphoto2 gpm gstreamer gtk gtk2 imlib ipv6 java jpeg libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pa m pdflib perl png python quicktime readline samba sdl slang spell sse ssl tcpd t iff truetype truetype-fonts type1-fonts unicode usb vorbis wmf xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LINGUAS, PORTDIR_OVERLAY
(In reply to comment #0) > Well, I'm not really sure if this is a kernel issue > (after all, I haven't had this before), but anyway, since the > update the clocks on my three machines go crazy - besides chrony, > which should take care of time setting. If you are not really sure then downgrade the kernel to version you used before and check again and post back the results.
Definitely true for me; Upgraded another machine to 2.6.12-r4 and it showed the same symptoms. Downgraded and every- thing is "normal". Strangely, it seems related to the time of the day; around midday, the time is set correct, in the morning and evening hours its quite wrong.
(In reply to comment #0) > Since updating to the 2.6.12-gentoo-r4 kernel, my machines clocks > go crazy. They go wrong for a couple of minutes per hours. What did you upgrade from?
Hi Daniel, I upgraded from 2.6.11-gentoo-r11 to 2.6.12-r4; today, I upgraded to the 2.6.12-gentoo-r5 kernel. I'll keep you informed if anything changes... Kind regards, Georg
I have the same problem. All kernels I have tried so far drifts with time. From 5 to 30 minutes a day, but it never gets worse than about 1 hour into the future. I have also tries the new option in 2.6.12 about syncing clock to other sources than the irq scheduler without success. Only solution I have on my machine is to run ntp-client regulary. (Which I'm unable to get to run as a deamon, causing init-script to fail to kill it, and thus fail to start it later since it has a pid file) I'm using the Oslo (timezone)
Stian: It sounds like your problem is different, if its been happening always (rather than a post-2.6.12 regression). Feel free to open a new bug for that. Georg: Any chance you could attach full "dmesg" output from both 2.6.11 and 2.6.12? If you could see if vanilla-sources-2.6.13_rc3 suffers the same problem it would also be appreciated.
Hi Daniel, sorry for the delay, have been away for a couple of days. Anyway, here's the dmesg output of kernel 2.6.11-gentoo-r11: http://www.argeo.de/dmesg-2.6.11-gentoo-r11 kernel 2.6.12-gentoo-r5: http://www.argeo.de/dmesg-2.6.12-gentoo-r5 Unfortunately, r5 suffers the same problem as do r4 and r3 :( Will try vanilla-sources today and keep you informed. Regards, Georg
Hi Daniel, tried to compile the vanilla-sources 2.6.12.13-rc3; unfortunately, already patching with rc3 fails at af_netlink (patch already applied). Trying to compile the kernel despite this fails at this very part (I admit, not very surprising :) Is it of any help if I try the 2.6.12.13 without the release-candidate patch?
You are saying that "emerge =vanilla-sources-2.6.13-rc3" fails with a patching error?
Ähm, actually, no :) This is getting embarrasing - I hadn't realized that there is an ebuild for the vanilla-sources, so I tried installing them the good old way by hand. Which should work anyway, but I admit, using emerge should be the choice. However, emerge is running right now and I'll keep you informed.
Hi Daniel, after a good nights rest, I can confirm that 2.6.13-rc3 shows the same (d)ef(f)ect than the 2.6.12-gentoo ones :( However, I'm not particularly sure if this is good or bad... Regards, Georg
Ok, this indicates that its an upstream bug. Please report this at http://bugzilla.kernel.org and post the new bug URL here. If you have time, you could assist the debugging by finding out where abouts in the 2.6.12-rc series it broke, by testing 2.6.12-rc1, 2.6.12-rc2, 2.6.12-rc3, .......
posted to bugzilla.kernel.org with nr. 4932 Peace, Georg
Untagging this as it looks like the issue has mysteriously run away. I'd suggest that you close the upstream bug for now. If the issue appears in future, feel free to retag this bug as watch-linux-bugzilla in the status whiteboard, and reopen the upstream bug.
