Just build new system with Athlon64 4200+ Dual-core on a MSI NEO4 motherboard. Since I build new kernel for it, clock is running ahead. The drift increase when system is active. I read about RTC not being reliable for SMP system ,so I rebuild kernel with HPET_TIMER, HPET_EMULATE_RTC ,RTC. It improves a lot. But problem remains. Now, at rest, drift is 1 hour every 8 hour. If running programs, up to 1 hour per hour. It was worst before. I discussed it on that thread (not first post, later on, name "Ikshaar"): http://forums.gentoo.org/viewtopic-p-2651024.html#2651024 Disk intensive operations seems to be the ones having the most effect. Kernel is gentoo-sources-2.6.12-r6. I will try to attach my .config Reproducible: Always Steps to Reproduce: 1.System MSI NEO4 + Athlon dual-core 2.Run any CPU and/or disk intensive program 3.Compare date and hwclock Actual Results: date report time drift ahead of hwclock Expected Results: remain reasonably stable Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) ================================================================= System uname: 2.6.12-gentoo-r6 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 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.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://gentoo.risq.qc.ca/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://gentoo.ccccom.com" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/altsrc/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 X adns alsa avi berkdb bitmap-fonts bonobo bootsplash cdr cups curl dbus dvd dvdr dvdread dvi encode fam fftw firefox flac font-server foomaticdb fortran gd gdbm gif gimp gimpprint glitz glut gnome gnomedb gpm gstreamer gtk gtk2 gtkhtml hal imagemagick imlib ipv6 java jpeg kerberos libwww lm_sensors lua lzw lzw-tiff mad metar motif mozilla mozsvg mp3 mpeg mysql ncurses network nptl nptlonly nvidia odbc ogg oggvorbis opengl oss pam pdflib perl plotutils png postgres ppds python quicktime readline samba sdl sensord slang smp spell ssl svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts usb userlocales v4l v4l2 vorbis xine xml xml2 xmms xpm xprint xscreensaver xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 66079 [details] .config .config for gentoo-sources-2.6.12-r6
Please try and reproduce on the latest development kernel (currently vanilla-sources-2.6.13_rc6)
Using same config with 2.6.13-rc6, so far having run nbench and copied 25Gb, clock did not drift at all. Seems fixed in this kernel. Thanks. PS: I try to keep a stable amd64 tree (desktop for work). Any warning on using "unstable" 2.6.13-rc6 ? Or will lower kernel get fixed ?
I'd fix 2.6.12 if I knew which 2.6.13 change fixed it. I've had a quick look and its not obvious - there have been a lot of clock/timing changes. 2.6.13-rc6 should be stable, probably more stable than 2.6.12. Leaving this bug open until 2.6.13 appears. Hopefully someone will point us in the direction of the 2.6.13 patch which fixes it :)
Well in fact, only half solved. The drift was dramatically reduced, but apparently still ongoing. As of now : 1 min ahead over 14 hours when not working 15 min ahead over 8 hours when working (CPU/disk) I heavily used external Firewire drives. And - as mentionned in the thread - they might to be part of the problem. Compiled as modules currently.
Ok, please file a bug against 2.6.13-rc6 at http://bugzilla.kernel.org and post the new bug URL here. Please attach a full dmesg output to the upstream bug once you have filed it.
FYI, problem was almost solved by merging Firewire-related drivers in kernel for 2.6.13-rc6. But problems resurfaced with new 2.6.13.1 kernel despite that.
*** Bug 108080 has been marked as a duplicate of this bug. ***
