Messages in this thread | | | Subject | Re: AMD X2 unsynced TSC fix? | From | Sergio Monteiro Basto <> | Date | Sat, 28 Oct 2006 04:58:27 +0100 |
| |
On Fri, 2006-10-27 at 18:08 -0400, Lee Revell wrote: > On Fri, 2006-10-27 at 15:48 -0600, Chris Friesen wrote: > > Lee Revell wrote: > > > > > What exactly does that AMD patch do? > > > > "...by periodically adjusting the core time-stamp-counters, so that they > > are synchronized." > > > > It sounds like they just periodically write a new value to the TSC. > > Presumably they set the "slower" one equal to the "faster" one. > > > > You'd likely still have windows where time might run backwards, but it > > would be better than nothing. > > The patch also apparently changes boot params to make the OS use the > ACPI PM timer, so it must not be a complete solution.
Hi, So far, has I can understand. Seems to me that my computer which have a Pentium D (Dual Core) on VIA chipset, also have unsynchronized TSC and with the patch of hrtimers on ( http://www.tglx.de/projects/hrtimers/2.6.18/ ) Kernel found and use a new clocksource, the acpi_pm. And works stable but I don't deny that could be a little slower.
Just to point out. This could be more a problem of chipsets than CPUs (AMD or Intel). AMD just begin first using x86_64 archs :)
Last Note: I still have other minor problem, seems (to me) related with SATA drives. Kernel 2.4.19-rc3 have big changes on SATA and I like to test it but can't apply hrtimers patch (I don't understand half seems in kernel other half not). In rc3 with jiffies clocksource even with boot parameter "notsc" I have unsynchronized issues and many "Lost timer tickets", but I can say that is a regression because computer never work well.
Thanks, -- Sérgio M. B.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |