http://bugzilla.kernel.org/show_bug.cgi?id=9475
------- Comment #13 from [EMAIL PROTECTED] 2007-12-06 21:16 ------- (In reply to comment #12) > Some Intel TSC facts, for the record: > > if (family == 6 && model < 14) || (family == 15 && model < 3) > TSC rate = Core MHz rate (ie. it changes with core/bus ratio shifts) > WRMSR on the TSC writes bottom 32-bits, clears upper 32 bits. Thank you for the info. > But note that the bigger problem may be that on all Intel processors > with C3 that have shipped to date, the TSC COMPLETELY STOPS > for the duration of C3. During C2 as well, maybe? > I believe that tsc_unstable is set upon either of these situations. Yes, no worries, I hit both :) Nov 29 07:55:29 morte [ 6.530752] Marking TSC unstable due to: possible TSC halt in C2. Nov 29 07:55:29 morte [ 6.530761] Time: acpi_pm clocksource has been installed. Nov 29 07:55:29 morte [ 6.620700] Clocksource tsc unstable (delta = -456217276 ns) and Nov 29 20:50:31 morte [ 297.562722] Marking TSC unstable due to: cpufreq changes. Anyway, I tried to follow your two suggestions and I must say that variable TSC causes issues, while TSC stoppage doesn't, in my case. In both cases, the timestamp isn't correct, but while TSC stoppage causes, well, a stop, the big trouble is when the timestamp leaps back because of cpufreq changes, and drivers get confused by this behaviour. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
