search for: clock_monoton

...2013-08-03 01:41, Darren Tucker wrote: > On Sat, Aug 3, 2013 at 5:58 PM, Damien Miller <djm at mindrot.org> wrote: >>> Looking at failure logs - this is what's killing it: >>> clock_gettime: Invalid argument > [...] >> Maybe these platforms lack CLOCK_MONOTONIC? Darren, perhaps we should >> wrap clock_gettime and have a fallback for platforms that lack this? > I thought we did. We check for clock_gettime in configure, and misc.c has: > > #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) > [...] clock_getttim...

...laptop in the morning and then suspend it at the end of the working day, usually a little while before the lifetime of the identities expires. Recently, however, this hasn't worked because the agent still has the identities the following morning. I believe that this is because monotime() uses CLOCK_MONOTONIC but in recent kernels this has changed slightly. From clock_gettime(2): CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspecified starting point. This clock is not affected by discontinuous jumps in the system time (e....

...e_vsyscall(struct timekeeper * base->sec = tk->xtime_sec; base->nsec = tk->tkr_mono.xtime_nsec; + base = &vdata->basetime[VGTOD_TAI]; + base->sec = tk->xtime_sec + (s64)tk->tai_offset; + base->nsec = tk->tkr_mono.xtime_nsec; + base = &vdata->basetime[CLOCK_MONOTONIC]; base->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; nsec = tk->tkr_mono.xtime_nsec; --- a/arch/x86/include/asm/vgtod.h +++ b/arch/x86/include/asm/vgtod.h @@ -19,9 +19,13 @@ struct vgtod_ts { }; #define VGTOD_BASES (CLOCK_MONOTONIC_COARSE + 1) -#define VGTOD_HRES (BIT(C...

I''m continuing to investigate the usage of rdtsc in userspace and whether there are programs "out there" that use it "unsafely" that might randomly break under Xen if rdtsc is not emulated, e.g. across a migration. Some have argued that nobody should use rdtsc and any programs that use rdtsc directly are "fundamentally broken" so the default for rdtsc

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

...= tk->xtime_sec; > base->nsec = tk->tkr_mono.xtime_nsec; > > + base = &vdata->basetime[VGTOD_TAI]; > + base->sec = tk->xtime_sec + (s64)tk->tai_offset; > + base->nsec = tk->tkr_mono.xtime_nsec; > + > base = &vdata->basetime[CLOCK_MONOTONIC]; > base->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; > nsec = tk->tkr_mono.xtime_nsec; > --- a/arch/x86/include/asm/vgtod.h > +++ b/arch/x86/include/asm/vgtod.h > @@ -19,9 +19,13 @@ struct vgtod_ts { > }; > > #define VGTOD_BASES (CLOCK_MONOTO...

...= tk->xtime_sec; > base->nsec = tk->tkr_mono.xtime_nsec; > > + base = &vdata->basetime[VGTOD_TAI]; > + base->sec = tk->xtime_sec + (s64)tk->tai_offset; > + base->nsec = tk->tkr_mono.xtime_nsec; > + > base = &vdata->basetime[CLOCK_MONOTONIC]; > base->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; > nsec = tk->tkr_mono.xtime_nsec; > --- a/arch/x86/include/asm/vgtod.h > +++ b/arch/x86/include/asm/vgtod.h > @@ -19,9 +19,13 @@ struct vgtod_ts { > }; > > #define VGTOD_BASES (CLOCK_MONOTO...

...similar. Thanks in advance for any advice/help you can provide. -----------8<-------- #!/usr/bin/perl -w use strict; use warnings; use Search::Xapian::Document; use Search::Xapian qw/:standard/; use Search::Xapian::WritableDatabase; use File::Temp qw(tempdir); use Time::HiRes qw(clock_gettime CLOCK_MONOTONIC); my $tmp = tempdir('xapian-test-XXXXXXX', CLEANUP => 1, TMPDIR => 1); my $flag = Search::Xapian::DB_CREATE_OR_OPEN; my $xdb = Search::Xapian::WritableDatabase->new($tmp, $flag); my $n = shift || 100; for my $i (0..$n) { $xdb->begin_transaction; for my $j (0..2000) { my $...

...three more times and even dug through the git > history. It seems like what you're saying is that, under certain > conditions (which arguably would be bugs in the core Linux timing > code), I don't see that as a bug. Its just a side effect of reading two different clocks (one is CLOCK_MONOTONIC and the other is TSC), and using those two clocks to as a "base + offset". As the comment explains, if you do that, can't guarantee monotonicity. > actually calling ktime_get_boot_ns() could be non-monotonic > with respect to the kvmclock timing. But get_kvmclock_ns() isn...

...three more times and even dug through the git > history. It seems like what you're saying is that, under certain > conditions (which arguably would be bugs in the core Linux timing > code), I don't see that as a bug. Its just a side effect of reading two different clocks (one is CLOCK_MONOTONIC and the other is TSC), and using those two clocks to as a "base + offset". As the comment explains, if you do that, can't guarantee monotonicity. > actually calling ktime_get_boot_ns() could be non-monotonic > with respect to the kvmclock timing. But get_kvmclock_ns() isn...

...t; history. It seems like what you're saying is that, under certain > > > conditions (which arguably would be bugs in the core Linux timing > > > code), > > > > I don't see that as a bug. Its just a side effect of reading two > > different clocks (one is CLOCK_MONOTONIC and the other is TSC), > > and using those two clocks to as a "base + offset". > > > > As the comment explains, if you do that, can't guarantee monotonicity. > > > > > actually calling ktime_get_boot_ns() could be non-monotonic > > > with re...

...t; history. It seems like what you're saying is that, under certain > > > conditions (which arguably would be bugs in the core Linux timing > > > code), > > > > I don't see that as a bug. Its just a side effect of reading two > > different clocks (one is CLOCK_MONOTONIC and the other is TSC), > > and using those two clocks to as a "base + offset". > > > > As the comment explains, if you do that, can't guarantee monotonicity. > > > > > actually calling ktime_get_boot_ns() could be non-monotonic > > > with re...

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Hi, I've submitted a patch to the Alioth tracker but thought to give a heads up here as well, I have an issue with nut not working when the clock is moved backwards. I provided a patch[1] to use clock_gettime with CLOCK_MONOTONIC to fix this, based on comments from Charles Lepple I made a few changes and it can be seen in a git branch I created at [2]. Let me know what you think. Baruch [1] https://alioth.debian.org/tracker/index.php?func=detail&aid=313714&group_id=30602&atid=411544 [2] https://github.com/b...

Using an 8-way ES7000 with 32GB of ram, I''m running xen at changset 11217 with dom0_mem=3092M as a kernel parameter on a x86_64 hyperviser. It appears that qemu is adding too much overhead to virtual machines to display graphics. If I boot a sles9sp3 domVT in runlevel 5 with vga=0x314 for a graphicalboot, and immediately use vncviewer simply to watch the virtual machine as it boots,

I used strace and the result is bus is busy: clock_gettime(CLOCK_MONOTONIC, {8158, 708518222}) = 0 timerfd_settime(11, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={8159, 708518000}}, NULL) = 0 ioctl(12, USBDEVFS_SUBMITURB, 0x40810) = 0 poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLOUT}], 4, 60000) = 1 ([{fd=12, reve...

Hello, We use Asterisk extensively for conferencing - for the last 8 years or so this has been the 1.4/1.6/1.8 releases running chan_sip and meetme for up to around 350 concurrent users. Right around that number DAHDI hit's a hard coded memory limit and kicks allocation errors in the log. [Jun 22 10:04:13] WARNING[9095] app_meetme.c: Unable to open DAHDI pseudo channel: Cannot allocate

...g through the git > > history. It seems like what you're saying is that, under certain > > conditions (which arguably would be bugs in the core Linux timing > > code), > > I don't see that as a bug. Its just a side effect of reading two > different clocks (one is CLOCK_MONOTONIC and the other is TSC), > and using those two clocks to as a "base + offset". > > As the comment explains, if you do that, can't guarantee monotonicity. > > > actually calling ktime_get_boot_ns() could be non-monotonic > > with respect to the kvmclock timing....

...e what you're saying is that, under certain > > > > conditions (which arguably would be bugs in the core Linux timing > > > > code), > > > > > > I don't see that as a bug. Its just a side effect of reading two > > > different clocks (one is CLOCK_MONOTONIC and the other is TSC), > > > and using those two clocks to as a "base + offset". > > > > > > As the comment explains, if you do that, can't guarantee monotonicity. > > > > > > > actually calling ktime_get_boot_ns() could be non-monoton...