Bug 7006 - Clock runs approx 3 times as fast with 2.6.18-rc4 on amd64 with ati chipset
Summary: Clock runs approx 3 times as fast with 2.6.18-rc4 on amd64 with ati chipset
Status: CLOSED CODE_FIX
Alias: None
Product: Timers
Classification: Unclassified
Component: Interval Timers (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: timers_interval-timers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-15 01:34 UTC by hofrichter
Modified: 2006-08-19 17:03 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.18-rc4
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg of kernel 2.6.18 (15.07 KB, text/plain)
2006-08-16 02:34 UTC, hofrichter
Details

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

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