Bug 174068 - Time gone mad
Time gone mad
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-24 04:42 EST by Vladimir Kosovac
Modified: 2015-01-04 17:23 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 21:56:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
PCI bus list (11.21 KB, text/plain)
2005-12-01 05:02 EST, Vladimir Kosovac
no flags Details
Output from lspci (15.44 KB, text/plain)
2006-03-07 09:20 EST, Philippe Rigault
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 168053 None None None Never

  None (edit)
Description Vladimir Kosovac 2005-11-24 04:42:28 EST
Description of problem:
After installing FC5-T1, I've noticed that system time on the machine is going
way too fast - after 25 actual minutes passed, computer is showing 20 minutes
more. Looking at seconds counter, I can tell that it's going at almost double
the normal speed.

Version-Release number of selected component (if applicable):
Not sure which component this relates to but it is happening on stock
(kernel-smp-2.6.14-1.1696_FC5) and development (kernel-smp-2.6.14-1.1707_FC5)
i686 kernels. Also, is it normal that installer selected smp kernel for
PresarioM2000 laptop, with Turion 64 CPU?

How reproducible:
Always

Steps to Reproduce:
1. Turn the machine on
2. Watch the clock running
3. File 'new' in bugzilla
  
Actual results:


Expected results:


Additional info:
Not sure what else can I provide at this stage - will be happy to upon suggestions.

Thanks, Vladimir
Comment 1 Thomas Antony 2005-11-24 07:14:15 EST
This bug is also present in FC4 and there is already a bug entry.
Comment 2 Vladimir Kosovac 2005-11-24 17:18:42 EST
OK guys, I've checked that FC4 bug entries, although I haven't had any similar
problems while running Core 4 on this same machine. 

It appears that only smp kernels suffer from that particular issue, mostly on
AMD 64 processors. I've just installed and booted kernel-2.6.14-1.1696_FC5 -
seems that this one handles rtc well.

As a side note, smp kernels need mem=nopentium option passed at boot time for
successful start, single CPU kernel does not. 
Comment 3 Dave Jones 2005-12-01 04:43:48 EST
the mem=nopentium thing isn't needed in the current builds from rawhide.

can you paste your lspci output please ?
Comment 4 Vladimir Kosovac 2005-12-01 05:02:50 EST
Created attachment 121671 [details]
PCI bus list

Here's the long listing.
Comment 5 Philippe Rigault 2006-03-07 09:20:01 EST
Created attachment 125753 [details]
Output from lspci

This happens to me on FC5test3 on x86_64   
   
System time is about _twice_ as fast as real time. 
`sleep 60` runs in about 28 seconds.   
  
Acer Ferrari  4005WLMi
AMD Turion64 2.0GHz
Comment 6 Philippe Rigault 2006-03-07 09:26:20 EST
FWIW, this happens with both 'userspace' and 'performance' CPU governors.  
  
# cat /proc/cpuinfo   
processor       : 0   
vendor_id       : AuthenticAMD   
cpu family      : 15   
model           : 36   
model name      : AMD Turion(tm) 64 Mobile Technology ML-37   
stepping        : 2   
cpu MHz         : 2000.000   
cache size      : 1024 KB   
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 pni lahf_lm   
bogomips        : 3988.13   
TLB size        : 1024 4K pages   
clflush size    : 64   
cache_alignment : 64   
address sizes   : 40 bits physical, 48 bits virtual   
power management: ts fid vid ttp tm stc   
   
Comment 7 Philippe Rigault 2006-03-08 12:42:21 EST
Looks like it is fixed in kernel-2.6.15-1.2032_FC5.x86_64.rpm  
 
Comment 8 Dave Jones 2006-03-08 13:38:38 EST
Vlad, fixed for you too ?
Comment 9 Philippe Rigault 2006-03-10 13:50:18 EST
FWIW, it is also fine with kernel-2.6.15-1.2039_FC5.x86_64.rpm  
Comment 10 Philippe Rigault 2006-03-11 11:02:09 EST
Dave, I don't know if this may help: 
  
From the excellent:  
http://gentoo-wiki.com/HARDWARE_Gentoo_Acer_Ferrari_4005WLMi_Manual#Troubleshooting  
 
<snip>  
With a current kernel (2.6.14), the only major problem of this machine (not  
counting buggy ACPI DSDT) is a very annoying IO-APIC bug causing system timer  
to run twice as fast as it should. For now it can be rectified with a  
following kernel option:   
"no_timer_check"  
  
added to "image ... append=" section of the lilo.conf or "kernel" line of the  
grub.conf.   
[Joël]: We got one positive report that "disable_timer_pin_1" works with  
64-bit and 2.6.14-gentoo-r2. That flag allows APIC to operate, unlike  
"no_timer_check". So try it :-)  
 <snip>  
 
Comment 11 John Thacker 2006-05-04 21:56:59 EDT
Closing per previous comments.

Thre are a few other bad time/APIC related bugs floating around still open.

Note You need to log in before you can comment on or make changes to this bug.