Bug 7006

Summary:	Clock runs approx 3 times as fast with 2.6.18-rc4 on amd64 with ati chipset
Product:	Timers	Reporter:	hofrichter
Component:	Interval Timers	Assignee:	timers_interval-timers
Status:	CLOSED CODE_FIX
Severity:	high	CC:	akpm, andi-bz, john.stultz
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.18-rc4	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	dmesg of kernel 2.6.18

Description hofrichter 2006-08-15 01:34:44 UTC

Hi
it noticed that the system clock runs three times as fast with the newest kernel
2.6.18-rc4. With the older kernel 2.6.17 it works fine. Was the timer code
changed between these two releases ?
My system is an amd64 notebook (nx6125) with ati chipset. Trying no_timer_check,
disable_timer_pin_1 or acpi=off at the boot prompt did not succeed.

Comment 1 Nishanth Aravamudan 2006-08-15 15:34:31 UTC

Please narrow it down among the 18-rc patches? i.e, does 18-rc3 have the same issue?

Thanks,
Nish

Comment 2 john stultz 2006-08-15 15:37:57 UTC

Yes, the timekeeping code has been changed in 2.6.18-rcX. Is this running an
i386 or x86_64 kernel? Could you please attach a full dmesg from a kernel
showing the problem?

Comment 3 hofrichter 2006-08-16 02:34:50 UTC

Created attachment 8797 [details]
dmesg of kernel 2.6.18

Comment 4 hofrichter 2006-08-16 02:46:17 UTC

This bug seems similar to bug 3341. However bug 3341 was solved with kernel
version 2.6.16. I did not encounter a similar behaviour before with older kernel
versions.
My kernel configuration is very similar to that of kernel 2.6.17 where I don't
have problems with my system clock. Both are x86_64 kernels.
Deactivating high precision timers in the kernel or using command line arguments
like no_timer_check that were proposed in the bug report 3341 did not help so far.

Comment 5 john stultz 2006-08-16 11:54:26 UTC

Does booting w/ "noapic" change the behavior?

Also if you could narrow down which of the 2.6.18-rc releases it first appeared
it would be quite helpful.

Comment 6 hofrichter 2006-08-16 12:23:18 UTC

I already use noapic for both kernel 2.6.17 and 2.6.18 otherwise suspend to ram
does not work on my notebook.
I also installed 2.6.18-rc4 directly without patching up so I cannot say if this
behaviour appeared in earlier release versions too.

Comment 7 hofrichter 2006-08-19 17:03:37 UTC

I cleared all my kernel sources and reinstalled it. I now cannot reproduce the
bug so I mark it as closed.  It seems that there was something wrong with the
kernel sources that I compiled