I'm using x86 Gentoo on my amd64 box, and since I update from the 2.6.15-r1 kernel to the 2.6.16-r3 I noticed that it won't show the real clock of the processor on Ksensors. Actually, the thing is that the CPU is overclocked, but ksensors will show the clock the CPU should be, that is 2000MHz on high-load and 1000MHz on idle, but it actually is at 2200MHz on high-load and 1100MHz on idle, and I can't seem to find anywhere where it shows the real cpu clock. Here's emerge --info: Portage 2.1_pre9-r4 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.5-r3, 2.6.16-gentoo-r3 i686) ================================================================= System uname: 2.6.16-gentoo-r3 i686 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 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.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -msse2 -pipe -O2 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -msse2 -pipe -O2 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://adelie.polymtl.ca/" LANG="pt_BR" LC_ALL="pt_BR" LINGUAS="pt_BR" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 16bit 3dnow 3dnowext X acpi alsa amarok apm arts artswrappersuid asf audiofile avi bash-completion berkdb bitmap-fonts bzip2 cddb cdinstall cdrom cli cpudetection css cups dbus dri dvd dvdr dvdread encode epson esd fat fbcon ffmpeg firefox foomaticdb fortran fuse gdbm gif gimpprint glut glx gmail gpm gstreamer gtk2 hal id3 imagemagick imlib insecure-savers isdnlog java jpeg kde kqemu lame lcms libg++ libvisual libwww linguas_pt_BR lm_sensors logrotate mad mikmod mmx mmxext motif moznocompose moznoirc moznomail mozsvg mp3 mpeg mpeg2 mplayer msn msnextras musicbrainz ncurses nfs nls no-old-linux nocd nogg nptl nptlonly nsplugin ntfs offensive ogg opengl oss pam pascal pcre pda pdf pdflib perl png pnp ppds pppd python qt quicktime readline real reflection reiser4 reiserfs samba sblive scp sdl session spell spl sse sse-filters sse2 ssl subtitles swat symlink tcpd transcode truetype truetype-fonts trusted type1-fonts udev unicode userlocales v4l v4l2 vcd vcdimager visualization vorbis wifi win32codecs wma wma123 xcomposite xine xml xmms xorg xprint xscreensaver xv xvid zip zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS
Do you have any idea where ksensors gets it's data from? You could start by comparing /proc/cpuinfo from 2.6.15 to 2.6.16, but I'm doubtful that is the data source being used here..
It's not from /proc/cpuinfo, since it's not dynamically updated. When I first configured powernow I found a file, but I couldn't find it right now, even on 2.6.15. It would display the real clock of the cpu, updated each second. It was on /proc/something... I don't know where ksensors gets it from, and I still ain't got enough programming skills to find it out by examining its sources...
Ah, it is probably /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq Can you confirm the 'bug' is present when comparing the contents of that file in 2.6.15 and 2.6.16?
Well... Actually, after making some more thorough investigations, I found out that I made a mistake. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is not the file I was looking for. It shows the clock the CPU should be at, and that's the bug I'm reporting, but /proc/cpuinfo IS dynamically updated, and on 2.6.15-r1 it would display the real CPU clock, regularly updated. On both cases, I was using Gentoo Sources, always the stable version, according to portage.
I don't quite follow. Can you post output from those 2 files on both 2.6.15 and 2.6.15 to illustrate what you mean?
This is /proc/cpuinfo for 2.6.16: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 0 cpu MHz : 1000.000 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm ts fid vid ttp bogomips : 2212.47 And this is for 2.6.15: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 0 cpu MHz : 1100.920 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm ts fid vid ttp bogomips : 2212.47 As you can see, in 2.6.16 it even shows the real bogomips, but the CPU clock shown is 1000.000MHz, which is the clock the CPU should be, but it ain't at that clock. On 2.6.15, it shows the real CPU clock, and it's really measured somewhere, because it even has decimal digits. Also on 2.6.15 it shows the bogomips right, as on 2.6.16. I know it because I know that the bogomips are usually around double the CPU clock.
Is this reproducible on the latest development kernel? currently 2.6.17-rc3
Just installed portage's vanilla-sources 2.6.17_r3 and it has the same problem...
Created attachment 86558 [details, diff] patch Please apply this patch against 2.6.17-rc3, compile, reboot into new image. Run "cat /proc/cpuinfo" then look in the kernel logs (dmesg). It should say something along the lines of: cpufreq says X khz is Y Paste those lines here
/proc/cpuinfo is still showing wrong info, however, dmesg outputs this: cpufreq says 1800000 khz is 1989971
What has happened is that as of 2.6.16, /proc/cpuinfo asks cpufreq for the current frequency, and if that fails, it falls back on the old way (cpu_khz). So your bug is that cpufreq does not show the real frequency -- you should be able to confirm this by reading /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq If you want to take this bug further, you need to file a bug against 2.6.17-rc3 at http://bugzilla.kernel.org cpufreq component, reporting that it is not giving the true CPU frequency. However they may close or ignore your bug as overclocking generally isn't something that people go out of their way to support. If you do report it upstream, please post the new bug URL here.
zwede on the forums has reported this upstream
Filed bug report against the Linux kernal as 6558 http://bugzilla.kernel.org/show_bug.cgi?id=6558
