>> > Tested working on E7400 against r313909. And changing timecounter
> >> from/to
> >> > TSC
> >> > correctly enables/disables C2.
> >> >
> >> > The latter part cpu_disable_c2_sleep++ is not needed. When
> >> > init_T
On Fri, Feb 24, 2017 at 9:32 PM, Jia-Shiun Li wrote:
> On Fri, Feb 24, 2017 at 7:45 PM, Konstantin Belousov
> wrote:
>
>> On Fri, Feb 24, 2017 at 12:15:26PM +0800, Jia-Shiun Li wrote:
>> > Tested working on E7400 against r313909. And changing timecounter
>> f
On Fri, Feb 24, 2017 at 7:45 PM, Konstantin Belousov
wrote:
> On Fri, Feb 24, 2017 at 12:15:26PM +0800, Jia-Shiun Li wrote:
> > Tested working on E7400 against r313909. And changing timecounter from/to
> > TSC
> > correctly enables/disables C2.
> >
> > The latt
times for kernel idle threads (but not
> > * for any non-idle threads).
> > */
> > - if (cpu_deepest_sleep >= 2 && cpu_vendor_id == CPU_VENDOR_INTEL &&
> > + if (cpu_vendor_id == CPU_VENDOR_INTEL &&
> > (amd_pminfo & AMDPM
id == CPU_VENDOR_INTEL &&
> (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) {
> tsc_timecounter.tc_flags |= TC_FLAGS_C2STOP;
> + if (timecounter == &tsc_timecounter)
> + cpu_disable_c2_sleep++;
> if (b
eep is only changed in tc_windup() when timecounter
> > is changed. If existing and already engadged timecounter suddenly gets
> > TC_FLAG_C2STOP set, tc_windup() ignores the flag. And with the early
> > AP startup, tsc seems to be set as timecounter too early.
> >
> > Ju
On Thu, Feb 23, 2017 at 6:08 PM, Konstantin Belousov
wrote:
>
> This is a useful analysis.
>
> Yes, I think that there is an init ordering issue. Note that
> cpu_disable_c2_sleep is only changed in tc_windup() when timecounter
> is changed. If existing and already engadged ti
On Thu, Feb 23, 2017 at 01:11:29AM +0800, Jia-Shiun Li wrote:
> I got the impression that TSC was not preferred timecounter
> if it is not C-state invariant. But this apparenly is not the case now.
> Dig a bit and found r277900 chose to prefer TSC over saving power
> by disabling C2 st
I got the impression that TSC was not preferred timecounter
if it is not C-state invariant. But this apparenly is not the case now.
Dig a bit and found r277900 chose to prefer TSC over saving power
by disabling C2 state when TSC is selected as timecounter.
But with EARLY_AP_STARTUP, and TSC as
FYI since it was not really solved as of r313090,
I created bug 216833 to keep track of it.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216833
-Jia-Shiun.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
FYI:
https://svnweb.freebsd.org/changeset/base/312551
--HPS
___
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"
On Tue, Jan 17, 2017 at 10:05 PM, Hans Petter Selasky
wrote:
> I've seen something similar. Does the attached patch make any difference?
>
> Can you dump:
>
> vmstat -i
>
> Just after boot w/ and w/o the attached patch, when the keystroke did not
> repeat smoothly.
>
>
Your patch fixes this issue
On 01/16/17 15:34, Jia-Shiun Li wrote:
Yes. I noticed this because systat refreshes looked slower,
and keystroke did not repeat smoothly for 30/s.
I've seen something similar. Does the attached patch make any difference?
Can you dump:
vmstat -i
Just after boot w/ and w/o the attached patch,
port that changing the
> timecounter makes the lags go away still does not fit into my understanding
> of the code.
>
> Most likely this is an interaction between the EARLY_AP_STARTUP and the
> fact that HPET interrupt is global, while most modern systems use LAPIC
> event timer,
On Mon, Jan 16, 2017 at 12:28:54PM +0800, Jia-Shiun Li wrote:
> BTW please see my other mail of this thread. It seems to be related to
> EARLY_AP_STARTUP option.
Yes, I noted, I might have an idea, but the report that changing the
timecounter makes the lags go away still does not fit i
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 reconfiguratio
t;
> > > 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.
> > >
> > >
,
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
k 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.
&
. 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
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
ha
te 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.
>
> The same wo
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
Hmm... GPF seems to be related to unclean %rcx. Can you please
try the attached patch? Please note you have to rebuild kernel
from scratch because this is a header file change. It may not fix
"hang", though. Please let me know.
It is just committed at r223796.
JK
This issue is resolved
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.
> >>
> >> T
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
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.
> >
&g
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
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
> t
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.
Jung-uk Kim
Index: sys/dev/
vels: 1600/2000 1400/1750 1333/1533
> > > > 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375
> > > > 400/300 300/225 200/150 100/75 dev.cpu.0.cx_supported: C1/1
> > > > C2/1 C3/57 dev.cpu.0.cx_lowest: C3
> > > > dev.cpu.0.cx_usage: 0.00% 8.69%
x_lowest: C3
> > > dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us
> > > dev.cpu.1.%desc: ACPI CPU
> > > dev.cpu.1.%driver: cpu
> > > dev.cpu.1.%location: handle=\_PR_.CPU1
> > > dev.cpu.1.%pnpinfo: _HID=none _UID=0
> > > dev.cpu.1.%parent:
C1/1 C2/1 C3/57
> > dev.cpu.0.cx_lowest: C3
> > dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us
> > dev.cpu.1.%desc: ACPI CPU
> > dev.cpu.1.%driver: cpu
> > dev.cpu.1.%location: handle=\_PR_.CPU1
> > dev.cpu.1.%pnpinfo: _HID=none _UID=0
> > dev.cpu.1.%parent: a
U1
> dev.cpu.1.%pnpinfo: _HID=none _UID=0
> dev.cpu.1.%parent: acpi0
> dev.cpu.1.cx_supported: C1/1 C2/1 C3/57
> dev.cpu.1.cx_lowest: C3
> dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us
>
> Pulling the power cord and re-inserting it has the cx_lowest
> correctly trantsit
; > > > The "error beep" seems to take longer than usual, too,
> > > > > > and the system "feels sluggish" in general.
> > > > > >
> > > > > > An effect that is easier to measure is that the system is
> > > > &g
as the cx_lowest correctly
trantsition to C1 and then TSC-low behaves properly as the system
timecounter. But, time will be wierd when on battery.
In light of this, I doubt the patch in your other email will have
any effect. Perhaps the thing to do is to have the timecounter
code aware of the lowest
er: 2028502028
kern.timecounter.tc.TSC-low.frequency: 12469046
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
real0m10.084s
user0m0.030s
sys 0m0.045s
[mini] /usr/home/ianf $ exit
Script done on Thu Jun 16 08:24:04 2011
> > I had do something sim
l, too,
> > > > > and the system "feels sluggish" in general.
> > > > >
> > > > > An effect that is easier to measure is that the system is
> > > > > unable to properly keep the time. Again the problem is less
> > > &
>
> > > > An effect that is easier to measure is that the system is
> > > > unable to properly keep the time. Again the problem is less
> > > > severe when using i8254 instead of HPET:
> > >
> > > [SNIP]
> > >
> > > Fir
> unable to properly keep the time. Again the problem is less
> > > severe when using i8254 instead of HPET:
> >
> > [SNIP]
> >
> > First of all, please do not mix timecounter issues with
> > eventtimer. They are not directly related.
> >
> > Can you please
ms to take longer than usual, too,
> > and the system "feels sluggish" in general.
> >
> > An effect that is easier to measure is that the system is unable
> > to properly keep the time. Again the problem is less severe when
> > using i8254 instead of HPE
On Monday 13 June 2011 12:44 pm, Fabian Keil wrote:
> I'm experiencing time-related issues that seem to be caused by
> the low-resolution TSC timecounter (r222866).
>
> The problem I noticed first is that it takes unusually long until a
> key press is repeated. With the defa
I'm experiencing time-related issues that seem to be caused by
the low-resolution TSC timecounter (r222866).
The problem I noticed first is that it takes unusually long until a
key press is repeated. With the default eventtimer (HPET) it seems
to take about 4s, which can be slightly improv
priorities of HPET and ACPI-fast. I
> support this change (some others may not), but please make it as a
> separate commit.
Yes, that is my intention but it's continuation of your original
patch. :-)
> - Not sure if the quality test code is of much use if a user has to
> set some tuna
code is of much use if a user has to set some
tunable to actually use it over HPET or ACPI-fast. I thought that the whole
point was in automatically choosing the best timecounter. I would go the
opposite way - if automatic selection of TSC causes any trouble then provide a
way to disable it.
eset to zero when APs start, we cannot use TSC
> > as a timecounter hardware until all APs are started properly.
>
> Great! Thank you for the info and your work.
Can you please test attached patch? You can get it from here, too:
http://people.freebsd.org/~jkim/tsc_smp_test.diff
on 07/04/2011 23:00 Jung-uk Kim said the following:
> Although it looks okay, please don't commit it just yet. I am working
> in this area actively. Also, if the Intel's claim is true, i.e.,
> TSCs reset to zero when APs start, we cannot use TSC as a timecounter
> hard
On 4/7/11 10:12 AM, Andriy Gapon wrote:
Guys,
what do you think about the following change?
The idea is mark TSC as the best timecounter when it's invariant and
synchronized
between cores.
Unfortunately I don't have code to auto-detect the synchronization and keep
relying on the cor
On Thursday 07 April 2011 01:12 pm, Andriy Gapon wrote:
> Guys,
>
> what do you think about the following change?
> The idea is mark TSC as the best timecounter when it's invariant
> and synchronized between cores. Unfortunately I don't have code to
> auto-detect
Hi--
On Apr 7, 2011, at 10:12 AM, Andriy Gapon wrote:
> what do you think about the following change?
> The idea is mark TSC as the best timecounter when it's invariant and
> synchronized
> between cores.
> Unfortunately I don't have code to auto-detect the synchronizat
Guys,
what do you think about the following change?
The idea is mark TSC as the best timecounter when it's invariant and
synchronized
between cores.
Unfortunately I don't have code to auto-detect the synchronization and keep
relying on the corresponding tunable. I thought about auto-
I upgraded to -CURRENT on a Xen machine yesterday, and found
that that the clock wasn't being updated because the dummy timecounter
was being used:
kern.timecounter.choice: TSC(-100) dummy(-100)
kern.timecounter.hardware: dummy
Shouldn't the TSC have been chosen since it has a high
Roberto Nunnari <[EMAIL PROTECTED]> writes:
> What is interesting is that with 4.7-Stable the faulty timer was
> handled correctly (or correctly ignored)..
That's because 4.7 incorrectly fails to use ACPI to configure the
system. As a result, 4.7 is unusable on newer laptops (which no
longer supp
On Thu, Mar 07, 2002 at 10:40:07AM +0900, I wrote:
> > Apparently you have KTR enabled (not the default in GENERIC). I think
> > WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and
> > we now get an endless loop when nanotime() is called with an invalid
>
caused nasty recursion from the mtx_lock_spin, and
> we now get an endless loop when nanotime() is called with an invalid
> timecounter in the following call chain:
>
> tc_init -> tc_windup -> tco_delta -> i8254_get_timecount -> mtx_foo ->
> witness_fo
lled from tc_init(), but not when called from somewhere else.
> (maybe an interrupt handler?)
Apparently you have KTR enabled (not the default in GENERIC). I think
WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and
we now get an endless loop when nanotime() is called with an
n
tc_windup() is called from tc_init() or switch_timecounter() (because
timecounter->generation is 0). At least one of these calls is made
unconditionally at boot time, but there is normally no problem, at
least if WITNESS and KTR are not enabled (my default) because the
functions that spin on
On Wed, Mar 06, 2002 at 08:49:18AM +0100, Poul-Henning Kamp wrote:
> > In message <20020306054514.GA395@gzl>, [EMAIL PROTECTED] writes:
> > >Hello.
> > >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped
> > >booting just after the
en timeout code is always run on entry
+* to ddb, and it calls here.
+ */
+ if (gen == 0 && timecounter == &dummy_timecounter)
+ (void)tc->tc_get_timecount(tc);
} while (gen == 0 || gen != tc->tc_generation);
}
%%
Hello.
After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped
booting just after the message:
Timecounter "i8254" frequency 1193182 Hz
With some debugging printf()'s inserted, I found it was tc->tc_get_timecount()
called from tco_delta() called just af
In message <[EMAIL PROTECTED]>, Yann Berthier writes:
>
> FYI, the increase from 15 to 31 in acpi_timer.c was needed for me to
> have my kernel boot with acpi loaded (ie no hang during boot).
Thanks, this was the kind of info I needed!
> Anyway, my system died after 2 hours or so of use, a
On Mon, 25 Feb 2002, Poul-Henning Kamp wrote:
>
> Machines with ACPI timecounters will now print 10 lines at boot when
> the timer is tested.
>
> If you are lucky you will see ten times something like:
> ACPI timer looks GOOD min = 3, max = 3, width = 1
> That means that you have well imp
f -l -v" for your machine. I'm am interested in reports
> both from good and bad machines.
I will send you mine as soon as I can figure out how to extract
the information usefully as the machine behaves VERY badly with
the ACPI timecounter -- the only way I can see output on the
sy
ease the 15 to 31 in this line:
} while (u1 > u2 || u2 > u3 || (u3 - u1) > 15);
Hopefully this commit fixes the "timecounter backwards" problem
with broken ACPI timers, if not, let me know.
Enjoy,
Poul-Henning
In message <[EMAIL PROTECTED]>, Poul-Henning
On Tue, Nov 14, 2000, John Baldwin wrote:
> > I'm seeing something similar with -current on this laptop here. Magically,
> > if I jiggle the mouse whilst playing an mp3, things start to skip and the
> > clock goes *way* off way (sometimes by a few seconds in a few seconds. :)
>
> That is probabl
>I'm seeing something similar with -current on this laptop here. Magically,
>if I jiggle the mouse whilst playing an mp3, things start to skip and the
>clock goes *way* off way (sometimes by a few seconds in a few seconds. :)
I've had this for a few weeks now (the skipage). It has been explained
On 14-Nov-00 Adrian Chadd wrote:
> On Mon, Nov 13, 2000, Poul-Henning Kamp wrote:
>>
>> It seems that something recently toasted the quasi-magic i8254 timecounter
>> code to the point of unusability.
>>
>> On my laptop I run a ntpdate every minute, and the res
On Mon, Nov 13, 2000, Poul-Henning Kamp wrote:
>
> It seems that something recently toasted the quasi-magic i8254 timecounter
> code to the point of unusability.
>
> On my laptop I run a ntpdate every minute, and the result looks like this:
>
I'm seeing something simila
It seems that something recently toasted the quasi-magic i8254 timecounter
code to the point of unusability.
On my laptop I run a ntpdate every minute, and the result looks like this:
Nov 13 23:37:00 [...] step time server 212.242.40.181 offset -2.862805 sec
Nov 13 23:38:00 [...] step time
The rtc is not a timecounter, and I doubt the the problem is related
to timecounters at all.
The RTC is always detected, because we know it is there, but it may
be that you don't get any interrupts from it, I don't know why that
might be.
Poul-Henning
In message <[EMAIL PROTECTE
Around the time we changed over to gcc-2.95.2, I noticed that rtc0
is no longer detected, and only one timecounter is detected at boot. The
bad effect of this is that the system doesn't accurately show the cpu
usage. Any suggestions on how to fix this, or pointers to where the
cpu_initclocks() fu
71 matches
Mail list logo
