Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, Previously I ran CURRENT from some time in April without any problems. Symptoms: Consistently high LA (2.6 to 8.0) with all CPUs idle. At the console, depressing and holding a key does not lead to auto-repeat. At the console, sometimes a key only appears on the terminal after another key is pressed. In xorg, key auto-repeat sorta works, but visibly slower than active xset settings, and jerky as well. Moving mouse around helps. During reboot, when the kernel prints the number of dirty buffers periodically before shutting down, it "freezes" and does not print the next number until I press a key. So it takes multiple presses of "Shift" or "Control" before it actually boots. Nothing suspicious according to vmstat, vmstat -i, pcmstat, top, top -SH, top -m io. What I tried, by myself and because of various advices on IRC: - replacing sc with vt & disabling sc - removing atkbdc from kernel configuration - removing uart from kernel configuration - putting "off" for ttyu0 in /etc/ttys (it had "onifconsole") No luck. Verbose dmesg can be obtained from: http://www.tobez.org/download/dmesg.verbose.2014-07-31.txt Any thought? Thanks in advance, \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, On 31.07.2014 16:21, Anton Berezin wrote: At the console, depressing and holding a key does not lead to auto-repeat. At the console, sometimes a key only appears on the terminal after another key is pressed. Maybe this is a problem caused by a misdetected clock source? I've had this problem as well. Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other settings that are listed in kern.timecounter.choice and kern.eventtimer.choice, such as HPET which works great for me. Cheers, Jan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Jan, On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: > On 31.07.2014 16:21, Anton Berezin wrote: > >At the console, depressing and holding a key does not lead to auto-repeat. > > > >At the console, sometimes a key only appears on the terminal after another > >key is pressed. > > Maybe this is a problem caused by a misdetected clock source? I've had this > problem as well. > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other > settings that are listed in kern.timecounter.choice and > kern.eventtimer.choice, such as HPET which works great for me. Setting both to HPET certainly helped the LA. I cannot check the keyboard input until tomorrow, but chances are that it is indeed the fix. Thanks a bunch! \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi, On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: > Jan, > > On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: > > On 31.07.2014 16:21, Anton Berezin wrote: > > >At the console, depressing and holding a key does not lead to auto-repeat. > > > > > >At the console, sometimes a key only appears on the terminal after another > > >key is pressed. > > > > Maybe this is a problem caused by a misdetected clock source? I've had this > > problem as well. > > > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other > > settings that are listed in kern.timecounter.choice and > > kern.eventtimer.choice, such as HPET which works great for me. > > Setting both to HPET certainly helped the LA. I cannot check the keyboard > input until tomorrow, but chances are that it is indeed the fix. Just wanted to throw in another datapoint, I had this issue too and setting kern.eventtimer.timer=HPET alone solved it for me. Steve pgpj6dqznjoLq.pgp Description: PGP signature
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi! On 1 August 2014 11:18, Steve Wills wrote: > Hi, > > On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: >> Jan, >> >> On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: >> > On 31.07.2014 16:21, Anton Berezin wrote: >> > >At the console, depressing and holding a key does not lead to auto-repeat. >> > > >> > >At the console, sometimes a key only appears on the terminal after another >> > >key is pressed. >> > >> > Maybe this is a problem caused by a misdetected clock source? I've had this >> > problem as well. >> > >> > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other >> > settings that are listed in kern.timecounter.choice and >> > kern.eventtimer.choice, such as HPET which works great for me. >> >> Setting both to HPET certainly helped the LA. I cannot check the keyboard >> input until tomorrow, but chances are that it is indeed the fix. > > Just wanted to throw in another datapoint, I had this issue too and setting > kern.eventtimer.timer=HPET alone solved it for me. Please throw this into a bug report ticket and poke mav@ about it. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Hi,
Maybe this is a problem caused by a misdetected clock source? I've had
this problem as well.
I've appended the patch I've been using to fix this problem on this
Intel Core2Duo T6570 processor. There are some model IDs hardcoded in
the TSC detection code that enable TSC even though it's not invariant
here (no TSC_INVARIANT bit set on the CPU). There is some quirk code
further down that disables TSC once again, but it only works for
processors that have C3 power states (the T6570 doesn't). I don't think
any of this model checking code is necessary, but maybe I'm wrong.
Cheers,
Jan
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 2a6c81d..a30424e 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -57,7 +57,8 @@ int tsc_perf_stat;
static eventhandler_tag tsc_levels_tag, tsc_pre_tag, tsc_post_tag;
SYSCTL_INT(_kern_timecounter, OID_AUTO, invariant_tsc, CTLFLAG_RDTUN,
-&tsc_is_invariant, 0, "Indicates whether the TSC is P-state invariant");
+&tsc_is_invariant, 0,
+"Indicates whether the TSC is ACPI P-, C- and T-state invariant");
TUNABLE_INT("kern.timecounter.invariant_tsc", &tsc_is_invariant);
#ifdef SMP
@@ -272,9 +273,7 @@ probe_tsc_freq(void)
switch (cpu_vendor_id) {
case CPU_VENDOR_AMD:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 ||
- (vm_guest == VM_GUEST_NO &&
- CPUID_TO_FAMILY(cpu_id) >= 0x10))
+ if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0)
tsc_is_invariant = 1;
if (cpu_feature & CPUID_SSE2) {
tsc_timecounter.tc_get_timecount =
@@ -282,12 +281,7 @@ probe_tsc_freq(void)
}
break;
case CPU_VENDOR_INTEL:
- if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 ||
- (vm_guest == VM_GUEST_NO &&
- ((CPUID_TO_FAMILY(cpu_id) == 0x6 &&
- CPUID_TO_MODEL(cpu_id) >= 0xe) ||
- (CPUID_TO_FAMILY(cpu_id) == 0xf &&
- CPUID_TO_MODEL(cpu_id) >= 0x3
+ if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0)
tsc_is_invariant = 1;
if (cpu_feature & CPUID_SSE2) {
tsc_timecounter.tc_get_timecount =
@@ -554,20 +548,6 @@ init_TSC_tc(void)
}
/*
- * We cannot use the TSC if it stops incrementing in deep sleep.
- * Currently only Intel CPUs are known for this problem unless
- * the invariant TSC bit is set.
- */
- if (cpu_can_deep_sleep && cpu_vendor_id == CPU_VENDOR_INTEL &&
- (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) {
- tsc_timecounter.tc_quality = -1000;
- tsc_timecounter.tc_flags |= TC_FLAGS_C3STOP;
- if (bootverbose)
- printf("TSC timecounter disabled: C3 enabled.\n");
- goto init;
- }
-
- /*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs
* are synchronized. If the user is sure that the system has
* synchronized TSCs, set kern.timecounter.smp_tsc tunable to a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
Can you file a pr with this patch? https://bugs.freebsd.org/submit/ That way we don't lose track of it. Thanks! -a On 1 August 2014 11:48, Jan Kokemüller wrote: > Hi, > > >> Maybe this is a problem caused by a misdetected clock source? I've had >> this problem as well. > > > I've appended the patch I've been using to fix this problem on this Intel > Core2Duo T6570 processor. There are some model IDs hardcoded in the TSC > detection code that enable TSC even though it's not invariant here (no > TSC_INVARIANT bit set on the CPU). There is some quirk code further down > that disables TSC once again, but it only works for processors that have C3 > power states (the T6570 doesn't). I don't think any of this model checking > code is necessary, but maybe I'm wrong. > > Cheers, > Jan > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction
On 01.08.2014 20:59, Adrian Chadd wrote: Can you file a pr with this patch? Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 Cheers, Jan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
