Bug 172199

Indeed this is also similar to bug 55223.  Booting with the non-SMP kernel seems
to fix it.

Is your system using powernow-k8? It should be in dmesg if its enabled. Powernow
on SMP systems is known to cause some timekeeping issues.

Also, what timesource is your system using? HPET, PIT, PMTIMER?
Do a "dmesg | grep time.c" to be sure.

Hmm...neither of those dmesg greps returns anything for me.  Any other ways to
check the powernow?

dmesg | grep -i time returns:

ACPI: PM-Timer IO Port: 0x4008
Using tsc for high-res timesource
per-CPU timeslice cutoff: 2926.76 usecs.
task migration cache decay timeout: 3 msecs.
..TIMER: vector=0x31 pin1=0 pin2=-1
Real Time Clock Driver v1.12
PCI: Setting latency timer of device 0000:00:07.0 to 64

Its using TSC for timekeeping, which is known to cause timekeeping issues on
some systems.

Try booting with "notsc" appended to the boot line parameters in grub.
The system should use another timesource. It may likely fix the problem.

As for powernow, when the system first boots, it prints out a bunch of info
about powernow. If this is absent at boot, powernow isnt loaded. Loglevel must
be changed in /etc/syslogd.conf to report KERN_INFO. Otherwise you wont see the
powernow stuff show up in dmesg.

Also, your sysfs should have a bunch of stuff like this if powernow is enabled:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq

Ok /sys/devices/system/cpu/cpu0 has nothing in it.

/etc/syslog.conf has:
kern.*                                                  @loghost
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

so I think that should get reported then.

I'm rebooting with notsc on the kernel line, and I'll see how it goes over the
weekend.

Rebooting with notsc did not work:

Kernel command line: ro root=LABEL=/1 rhgb quiet notsc
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
Using tsc for high-res timesource

I am going to give noapic a try, as in bug 55223.

noapic is still broken.

(In reply to comment #6)
> Rebooting with notsc did not work:
> 
> Kernel command line: ro root=LABEL=/1 rhgb quiet notsc
> notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
> Using tsc for high-res timesource
> 
> I am going to give noapic a try, as in bug 55223.
> 
> 

Does this mean you have to recompile the kernel to accept the "notsc"?

As in bug 171554, clock=pmtmr has this machine running now with an SMP kernel
for 24 hours, no problem.

2.6.9-22.0.2.EL doesn't fix it.  Though it seems the new kernel for FC4 fixes it
on that OS.

This would seem to be the same as bug 5105 on the bugzilla.kernel.org 

I can see if kernel-smp-2.6.9-29.EL.x86_64 has this fix included.

Created attachment 125418 [details]
patch to reorder timesource selection on x86

On AMD systems that are using powernow-k8, the TSC cannot be used as a
timesource being its quite problematic. Problems range from spurious keyboard
repeats to timekeeping issues if TSC is used with powernow-k8. This patch gets
us inline with upstream (as of linux-2.6.15.4 anyway), and additionally gets
timesource ordering on x86 inline with timesource ordering on x86_64.
Timesource selction is now ordered as follows for x86: (Cyclone, HPET, PMTimer,
TSC, PIT), and for x86_64: (HPET, PMTimer, TSC, PIT). 

patch posted 2/28/2006

committed in stream U4 build 34.19. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/ However, there is a *serious* slab
corruption issue with this kernel, and thus it should not be released to
customers under any circumstances. I'll update this bug when the kernel is
stable again.

We've identified the corruption as specfic to x86-64 smp kernel builds 34.16 and
34.17. All other builds are safe for consumption.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0575.html