Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim
jkim at FreeBSD.org
Wed Jun 29 22:55:25 UTC 2011
On Wednesday 29 June 2011 05:50 pm, Matt wrote:
> On 06/23/11 08:25, Jung-uk Kim wrote:
> > On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
> >> Jung-uk Kim wrote:
> >>> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
> >>>> Can you please try the attached patch? It should disable
> >>>> TSC/TSC-low timecounter for your CPU models, I think.
> >>>
> >>> Sorry, I attached a wrong patch. Please ignore the previous
> >>> one and try this, instead.
> >>
> >> TSC-low is not presented as an option any more:
> >>
> >> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz
> >> 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6
> >> Model = 1c Stepping = 2
> >>
> >> Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,
> >>MTR
> >> R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,
> >>PBE>
> >> Features2=0x40c39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDC
> >>M,M OVBE> AMD Features2=0x1<LAHF>
> >> TSC: P-state invariant, performance statistics
> >>
> >> Event timer "LAPIC" quality 400
> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> >> acpi_timer0:<24-bit timer at 3.579545MHz> port 0x408-0x40b on
> >> acpi0 atrtc0:<AT realtime clock> port 0x70-0x77 on acpi0
> >> atrtc0: Warning: Couldn't map I/O.
> >> Event timer "RTC" frequency 32768 Hz quality 0
> >> hpet0:<High Precision Event Timer> iomem
> >> 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET"
> >> frequency 14318180 Hz quality 950 Event timer "HPET" frequency
> >> 14318180 Hz quality 450
> >> Event timer "HPET1" frequency 14318180 Hz quality 440
> >> Event timer "HPET2" frequency 14318180 Hz quality 440
> >> attimer0:<AT timer> port 0x40-0x43,0x50-0x53 on acpi0
> >> Timecounter "i8254" frequency 1193182 Hz quality 0
> >> Event timer "i8254" frequency 1193182 Hz quality 100
> >>
> >> kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950)
> >> ACPI-fast(900) dummy(-1000000)
> >
> > It's already committed (r223426).
> >
> > Thanks!
> >
> > Jung-uk Kim
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe at freebsd.org"
>
> I had been holding off on csup on this machine for a moment:
> Machine: Thinkpad SL410 Core2Duo T6570
> I rm -rf /usr/src& csup'd sources yesterday.
>
> Issues still exist with TSC-low on Intel laptop hardware. Quality
> was set to 1000, but time was inaccurate. Felt like 300 baud serial
> console over a very long link!
>
> I have C2& powerd:
>
> /etc/sysctl.conf:
> ...
> # Save electricity& thermal
> hw.pci.do_power_nodriver=3
This betther be set from /boot/loader.conf.
> hw.acpi.cpu.cx_lowest=C2
> dev.cpu.1.cx_lowest=C2
> dev.cpu.0.cx_lowest=C2
There is no reason to do this here. Just add a line in /etc/rc.conf:
economy_cx_lowest="C2"
> ...
>
> /etc/rc.conf:
> ...
> #power
> powerd_enable="YES"
> powerd_flags="-b adaptive -a maximum"
> ...
>
> I'm getting as far as
> /usr/src/sys/x86/x86:
> ...
> if (smp_cpus> 1) {
> tsc_timecounter.tc_quality = test_smp_tsc();
> max_freq>>= 8;
> ...
>
> test_smp_tsc() returns 1000, allowing TSC-slow to "win".
> Forcing this to 50 fixed all time/speed issues, allowing HPET to
> "win".
>
> I think the test for C3 above that may need to include additional
> machines under its protection! I have no C3 support, but it's clear
> that issues are occuring with TSC clocks even in C2 on intel
> platforms.
Hmm... That's strange. Can you show me verbose dmesg output? Also,
I'd like to see 'acpidump -dt' output.
Sorry about the trouble.
Jung-uk Kim
More information about the freebsd-current
mailing list