Re: Time keeping Issues with the low-resolution TSC timecounter

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   _at_ 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