Re: TSC as timecounter makes system lag

2017-01-15 Thread Jia-Shiun Li 
BTW please see my other mail of this thread. It seems to be related to
EARLY_AP_STARTUP option.


On Mon, Jan 16, 2017 at 4:20 AM, Konstantin Belousov 
wrote:

> I still do not understand.  Is the sysctl output below from the pristine
> boot where no timecounter/eventtimer reconfiguration were done ?
>
> Show me exact command which you used to revive the machine.  Do not
> describe
> it by words, copy/paste from the console.
>
>
Don't have access to the exact machine right now.
Let me reproduce it on another with a c2d E7400.

login as: jsli
Authenticating with public key "rsa-key-20160711@jsli-pc"
Last login: Mon Jan 16 11:11:28 2017 from tmux(1074).%1
FreeBSD 12.0-CURRENT (GENERIC-NODEBUG) #24 r312210: Sun Jan 15 15:03:40 CST
2017

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:  https://www.FreeBSD.org/handbook/
FreeBSD FAQ:   https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-
questions/
FreeBSD Forums:https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:  man hier

Edit /etc/motd to change this login announcement.
jsli@jsli-bsd:~ % sysctl kern.eventtimer kern.timecounter
kern.eventtimer.periodic: 0
kern.eventtimer.timer: HPET
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440)
LAPIC(100) i8254(100) RTC(0)
kern.eventtimer.et.HPET3.quality: 440
kern.eventtimer.et.HPET3.frequency: 14318180
kern.eventtimer.et.HPET3.flags: 3
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.LAPIC.quality: 100
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.flags: 15
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 5046106
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1449012340
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 10698
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1400076588
kern.timecounter.tc.TSC-low.counter: 2260820915
kern.timecounter.tc.TSC-low.mask: 4294967295
jsli@jsli-bsd:~ % su
Password:
jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=HPET
kern.timecounter.hardware: TSC-low -> HPET
jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer kern.timecounter
kern.eventtimer.periodic: 0
kern.eventtimer.timer: HPET
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440)
LAPIC(100) i8254(100) RTC(0)
kern.eventtimer.et.HPET3.quality: 440
kern.eventtimer.et.HPET3.frequency: 14318180
kern.eventtimer.et.HPET3.flags: 3
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.LAPIC.quality: 100
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.flags: 15

Re: recent change to vim defaults?

2017-01-15 Thread Benjamin Kaduk 
On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote:
> I noticed that suddenly vim is grabbing mouse movements, which makes 
> life really hard.
> 
> Was there a specific revision that brought in this change, and can it 
> be removed?

I remember seeing something go by during an upgrade somewhat recently
about there now being a defaults file that gets used when a user does
not specify a .vimrc.  Unfortunately, I don't remember whether I saw
that notice on a FreeBSD machine or a Debian one, and haven't been able
to find the notice I remember through searching some likely places.

Just to check: do you have a .vimrc file in place already?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: recent change to vim defaults?

2017-01-15 Thread Carsten Kunze 
Julian Elischer  wrote:

> I noticed that suddenly vim is grabbing mouse movements, which makes 
> life really hard.
> 
> Was there a specific revision that brought in this change, and can it 
> be removed?

Of course this behavior can be disabled as suggested by others--or you give it 
a try.  IMHO using the mouse in vim has many advantages.  To temporarily 
disable the mouse you can press the SHIFT key.  As long as SHIFT is pressed vim 
ignores the mouse.  So you may use copy/paste with left and middle mouse 
buttons as before or you now use the mouse to position the cursor or select 
text--very useful IMHO (I actually have "set mouse=a" in .vimrc... ;)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TSC as timecounter makes system lag

2017-01-15 Thread Konstantin Belousov 
On Sun, Jan 15, 2017 at 10:35:26PM +0800, Jia-Shiun Li wrote:
> Sorry just saw this. Bad Gmail.
> 
> 
> On Fri, Jan 13, 2017 at 8:05 PM, Konstantin Belousov 
> wrote:
> 
> > On Fri, Jan 13, 2017 at 08:26:04AM +0800, Jia-Shiun Li wrote:
> > > Hi all,
> > >
> > > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium
> > > T4200 notebook lagged a lot. System time was running a lot slower,
> > > sometimes even looked like it freezed. Keystroke repeat rate was slow
> > too.
> > >
> > > Since system time is slow, I tried to change timecounter from default TSC
> > > to HPET. And it resumed normal immediately.
> > Please show the output of sysctl kern.timecounter and kern.eventtimer.
> > I suspect that you changed eventtimer and not timecounter.
> >
> 
> Files attached. I changed it by "sysctl kern.timecounter.hardware=HPET"
> 
> 
> > The same world binary works fine on other Ivybridge and Haswell desktops,
> > > so I assume this may be related to CPU or mainboard generations.
> > >
> > > version is
> > >
> > > FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan  9
> > > 04:07:27 CST 2017
> > > jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/
> > fbsdsrc/sys/MINIMAL-NODEBUG
> > > amd64
> > >
> > > and CPU is
> > >
> > > CPU: Pentium(R) Dual-Core CPU   T4200  @ 2.00GHz (1995.04-MHz
> > K8-class
> > > CPU)
> > >   Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
> > >
> > > Features=0xbfebfbff > APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,
> > MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > >
> > > Features2=0xc00e39d > SSSE3,CX16,xTPR,PDCM,XSAVE,OSXSAVE>
> > >   AMD Features=0x20100800
> > >   AMD Features2=0x1
> > >   TSC: P-state invariant, performance statistics
> > >
> > > Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the
> > same
> > > generation as the Pentium T4200). The same lag also happens on it.
> > >
> > > BTW on both system, cpuX:timer interrupts do not fire at all and count
> > > remains 0.
> > It is known that LAPIC is shut down in C2 and deeper CPU sleep states on
> > Core2.  FreeBSD 11 (and HEAD) started using MWAIT and requesting deep
> > wait states from BIOS.  If the configuration uses LAPIC and deep sleeps
> > are enabled, eventtimers do not work reliably.
> >
> 
> > Default configuration should strongly prefer HPET eventtimer over LAPIC for
> > machines which do not have LAPIC armed in Cx states, see r309189.  If you
> > do not have any customizations of eventtimer selection, then please provide
> > verbose dmesg from your boot.
> >
> > If you prefer to not use deep Cx and MWAIT, set loader tunable
> > debug.acpi.disabled to include word "mwait", see acpi(4).  You can check
> > that this worked by looking at sysctl dev.cpu.N output.
> >
> 
> Thanks for the explanation. Looks eventtimer favored HPET over LAPIC
> like you described on this notebook.
I still do not understand.  Is the sysctl output below from the pristine
boot where no timecounter/eventtimer reconfiguration were done ?

Show me exact command which you used to revive the machine.  Do not describe
it by words, copy/paste from the console.

> 
> -Jia-Shiun.

> kern.eventtimer.periodic: 0
> kern.eventtimer.timer: HPET
> kern.eventtimer.idletick: 0
> kern.eventtimer.singlemul: 2
> kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(100) 
> i8254(100) RTC(0)
> kern.eventtimer.et.i8254.quality: 100
> kern.eventtimer.et.i8254.frequency: 1193182
> kern.eventtimer.et.i8254.flags: 1
> kern.eventtimer.et.HPET3.quality: 440
> kern.eventtimer.et.HPET3.frequency: 14318180
> kern.eventtimer.et.HPET3.flags: 3
> kern.eventtimer.et.HPET2.quality: 440
> kern.eventtimer.et.HPET2.frequency: 14318180
> kern.eventtimer.et.HPET2.flags: 3
> kern.eventtimer.et.HPET1.quality: 440
> kern.eventtimer.et.HPET1.frequency: 14318180
> kern.eventtimer.et.HPET1.flags: 3
> kern.eventtimer.et.HPET.quality: 450
> kern.eventtimer.et.HPET.frequency: 14318180
> kern.eventtimer.et.HPET.flags: 3
> kern.eventtimer.et.RTC.quality: 0
> kern.eventtimer.et.RTC.frequency: 32768
> kern.eventtimer.et.RTC.flags: 17
> kern.eventtimer.et.LAPIC.quality: 100
> kern.eventtimer.et.LAPIC.frequency: 0
> kern.eventtimer.et.LAPIC.flags: 15
> kern.timecounter.tsc_shift: 1
> kern.timecounter.smp_tsc_adjust: 0
> kern.timecounter.smp_tsc: 1
> kern.timecounter.invariant_tsc: 1
> kern.timecounter.fast_gettime: 1
> kern.timecounter.tick: 1
> kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC(1000) 
> dummy(-100)
> kern.timecounter.hardware: TSC
> kern.timecounter.alloweddeviation: 5
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.ACPI-fast.quality: 900
> kern.timecounter.tc.ACPI-fast.frequency: 3579545
> kern.timecounter.tc.ACPI-fast.counter: 79078
> kern.timecounter.tc.ACPI-fast.mask: 16777215
> kern.timecounter.tc.i8254.quality: 0
>

Re: recent change to vim defaults?

2017-01-15 Thread Ngie Cooper 

> On Jan 15, 2017, at 08:03, Julian Elischer  wrote:
> 
> I noticed that suddenly vim is grabbing mouse movements, which makes life 
> really hard.
> 
> Was there a specific revision that brought in this change, and can it be 
> removed?

"set mouse=" will disable the feature you're describing.
-Ngie

PS I find the new feature incredibly annoying and disable it on all FreeBSD 
clients where I install vim.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Installing opt_*.h kernel headers

2017-01-15 Thread Adrian Chadd 
hi,

As much as I'd like to see everything be default-options and ABI
compliant, things like INET/INET6 throw that assumption under the bus
a bit.
(Yes, I'd love to see INET/INET6 be .ko's..)

So yes, I'd like to see a solution to this too. I think installing the
kernel config for the running kernel somewhere would be nice. No, not
/usr/include, because you want it cycled /with/ the kernel you just
installed. We already have the problem with /usr/lib/debug/ and where
it puts kernel modules.

We already have the 'one file' option, it's called 'kernel config',
and so maybe:

* store the kernel config with the built kernel;
* have config patched to 'just' generate the .h files from the given config, and
* let the build system use that if needed?

However - it all feels terrible. Ideally (hah), there'd be separate
submodules for vt/syscons and the modules would combine appropriately
to provide increasing functionality - but that's a lot to ask given
the complexity of the current system.

2c,



-adrian


On 15 January 2017 at 09:08, Tijl Coosemans  wrote:
> Hi,
>
> The latest version of x11/nvidia-driver contains a call to a syscons
> function which is only available if the kernel config contains device
> sc (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216050).  The call
> doesn't seem to be critical so I'd like to patch it like this:
>
> +#include "opt_syscons.h"
>  ...
> +#ifdef DEV_SC
>  syscons stuff here
> +#endif
>
> And add opt_syscons.h to SRCS in the module Makefile.
>
> This doesn't work however because sys/conf/kmod.mk creates empty opt_*.h
> files in the module build directory.  Only when KERNBUILDDIR is set does
> it create opt_*.h files as symlinks to the same file in KERNBUILDDIR.
> This means that to build this port correctly users would have to have a
> kernel build directory (even if they just need the nvidia driver and
> don't otherwise build kernels) and the ports tree would need some way to
> find it (using KERNCONF etc.).
>
> It would be better if these opt_*.h files were installed along with the
> kernel.  Somewhere in /usr/include or /boot/kernel(.old)?  Perhaps
> concatenated into one file?  Then kmod.mk could create symlinks to this
> file if KERNBUILDDIR is undefined.  Building a module directly from
> sys/modules would then also just work without .if !defined(KERNBUILDDIR)
> magic that several Makefiles contain.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-15 Thread Steven Hartland 

On 15/01/2017 17:45, Pete Wright wrote:



On 1/15/17 8:22 AM, Kyle Evans wrote:

On Jan 15, 2017 10:03, "Julian Elischer"  wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes 
life

really hard.

Was there a specific revision that brought in this change, and can it be
removed?




Yea I can second this - IIRC it looks like around Sept or Oct vim now 
defaults to enabling Visual Mode.  I've been setting this in my 
~/.vimrc to disable it - but not enabling Visual Mode by default would 
awesome for me:


set mouse-=a

Yer we hatted this change too.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-15 Thread Pete Wright 



On 1/15/17 8:22 AM, Kyle Evans wrote:

On Jan 15, 2017 10:03, "Julian Elischer"  wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?




Yea I can second this - IIRC it looks like around Sept or Oct vim now 
defaults to enabling Visual Mode.  I've been setting this in my ~/.vimrc 
to disable it - but not enabling Visual Mode by default would awesome 
for me:


set mouse-=a


-pete

--
Pete Wright
p...@nomadlogic.org
nomadlogicLA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Installing opt_*.h kernel headers

2017-01-15 Thread Tijl Coosemans 
Hi,

The latest version of x11/nvidia-driver contains a call to a syscons
function which is only available if the kernel config contains device
sc (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216050).  The call
doesn't seem to be critical so I'd like to patch it like this:

+#include "opt_syscons.h"
 ...
+#ifdef DEV_SC
 syscons stuff here
+#endif

And add opt_syscons.h to SRCS in the module Makefile.

This doesn't work however because sys/conf/kmod.mk creates empty opt_*.h
files in the module build directory.  Only when KERNBUILDDIR is set does
it create opt_*.h files as symlinks to the same file in KERNBUILDDIR.
This means that to build this port correctly users would have to have a
kernel build directory (even if they just need the nvidia driver and
don't otherwise build kernels) and the ports tree would need some way to
find it (using KERNCONF etc.).

It would be better if these opt_*.h files were installed along with the
kernel.  Somewhere in /usr/include or /boot/kernel(.old)?  Perhaps
concatenated into one file?  Then kmod.mk could create symlinks to this
file if KERNBUILDDIR is undefined.  Building a module directly from
sys/modules would then also just work without .if !defined(KERNBUILDDIR)
magic that several Makefiles contain.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TSC as timecounter makes system lag [-> jhb]

2017-01-15 Thread Larry Rosenman 

On 2017-01-14 23:03, Julian Elischer wrote:

On 15/01/2017 10:11 AM, Jia-Shiun Li wrote:
On Fri, Jan 13, 2017 at 8:26 AM, Jia-Shiun Li  
wrote:



Hi all,

since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel 
Pentium

T4200 notebook lagged a lot. System time was running a lot slower,
sometimes even looked like it freezed. Keystroke repeat rate was slow 
too.


Since system time is slow, I tried to change timecounter from default 
TSC

to HPET. And it resumed normal immediately.



Did a binary search. Turns out it was caused by r310177 "Enable
EARLY_AP_STARTUP on amd64 and i386 kernels by default." r310175 does 
not
have this issue. Removing this option from kernel config also solves 
it.


making sure jhb notices this.
FWIW, I noted similar "slowness", and nooptions EARLY_AP_STARTUP makes 
it "normal"

again.

Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights 
reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #13 r311997: Sat Jan 14 22:35:29 CST 2017
r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on 
LLVM 3.9.1)

MEMGUARD DEBUGGING ALLOCATOR INITIALIZED:
MEMGUARD map base: 0xfe40
MEMGUARD map size: 128600960 KBytes
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6
  
Features=0xbfebfbff
  
Features2=0xce3bd

  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65353601024 (62326 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs


--
Larry Rosenman http://people.freebsd.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-15 Thread Adam Weinberger 
> On 15 Jan, 2017, at 9:03, Julian Elischer  wrote:
> 
> I noticed that suddenly vim is grabbing mouse movements, which makes life 
> really hard.
> 
> Was there a specific revision that brought in this change, and can it be 
> removed?

Which patchlevel are you running?

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: recent change to vim defaults?

2017-01-15 Thread Kyle Evans 
On Jan 15, 2017 10:03, "Julian Elischer"  wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Hi,

You might add "set mouse=v" to your vimrc -- it was a new default as of
8.0, IIRC. "set nohl" if the new highlighted of search matches irritates as
well.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

recent change to vim defaults?

2017-01-15 Thread Julian Elischer 
I noticed that suddenly vim is grabbing mouse movements, which makes 
life really hard.


Was there a specific revision that brought in this change, and can it 
be removed?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TSC as timecounter makes system lag

2017-01-15 Thread Jia-Shiun Li 
Sorry just saw this. Bad Gmail.


On Fri, Jan 13, 2017 at 8:05 PM, Konstantin Belousov 
wrote:

> On Fri, Jan 13, 2017 at 08:26:04AM +0800, Jia-Shiun Li wrote:
> > Hi all,
> >
> > since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium
> > T4200 notebook lagged a lot. System time was running a lot slower,
> > sometimes even looked like it freezed. Keystroke repeat rate was slow
> too.
> >
> > Since system time is slow, I tried to change timecounter from default TSC
> > to HPET. And it resumed normal immediately.
> Please show the output of sysctl kern.timecounter and kern.eventtimer.
> I suspect that you changed eventtimer and not timecounter.
>

Files attached. I changed it by "sysctl kern.timecounter.hardware=HPET"


> The same world binary works fine on other Ivybridge and Haswell desktops,
> > so I assume this may be related to CPU or mainboard generations.
> >
> > version is
> >
> > FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan  9
> > 04:07:27 CST 2017
> > jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/
> fbsdsrc/sys/MINIMAL-NODEBUG
> > amd64
> >
> > and CPU is
> >
> > CPU: Pentium(R) Dual-Core CPU   T4200  @ 2.00GHz (1995.04-MHz
> K8-class
> > CPU)
> >   Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
> >
> > Features=0xbfebfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,
> MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >
> > Features2=0xc00e39d SSSE3,CX16,xTPR,PDCM,XSAVE,OSXSAVE>
> >   AMD Features=0x20100800
> >   AMD Features2=0x1
> >   TSC: P-state invariant, performance statistics
> >
> > Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the
> same
> > generation as the Pentium T4200). The same lag also happens on it.
> >
> > BTW on both system, cpuX:timer interrupts do not fire at all and count
> > remains 0.
> It is known that LAPIC is shut down in C2 and deeper CPU sleep states on
> Core2.  FreeBSD 11 (and HEAD) started using MWAIT and requesting deep
> wait states from BIOS.  If the configuration uses LAPIC and deep sleeps
> are enabled, eventtimers do not work reliably.
>

> Default configuration should strongly prefer HPET eventtimer over LAPIC for
> machines which do not have LAPIC armed in Cx states, see r309189.  If you
> do not have any customizations of eventtimer selection, then please provide
> verbose dmesg from your boot.
>
> If you prefer to not use deep Cx and MWAIT, set loader tunable
> debug.acpi.disabled to include word "mwait", see acpi(4).  You can check
> that this worked by looking at sysctl dev.cpu.N output.
>

Thanks for the explanation. Looks eventtimer favored HPET over LAPIC
like you described on this notebook.

-Jia-Shiun.
kern.eventtimer.periodic: 0
kern.eventtimer.timer: HPET
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(100) 
i8254(100) RTC(0)
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.HPET3.quality: 440
kern.eventtimer.et.HPET3.frequency: 14318180
kern.eventtimer.et.HPET3.flags: 3
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.LAPIC.quality: 100
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.flags: 15
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) TSC(1000) 
dummy(-100)
kern.timecounter.hardware: TSC
kern.timecounter.alloweddeviation: 5
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 79078
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 55592
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 1931486323
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.TSC.quality: 1000
kern.timecounter.tc.TSC.frequency: 1995044550
kern.timecounter.tc.TSC.counter: 2329785074
kern.timecounter.tc.TSC.mask: 4294967295
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994