On Wed, Jul 25, 2012 at 1:25 PM, Ted Unangst wrote:
> tc_setclock - doesn't seem to do much itself. What are the
> consquences of timehands->th_offset getting raced?
Racing calls to {micro,nano,bin}time() can get bogus times (e.g.,
interrupts or even other userspace threads that call clock_getti
On Wed, Jul 25, 2012 at 11:14, Matthew Dempsky wrote:
> In vmt_tick() we could notice anytime the reported sensor value jumps
> significantly and then wind forward the clocks like we do when
> recovering from ACPI sleep.
I like this, and I think it even works. Scary warnings about no
locking in k
On Wed, Jul 25, 2012 at 11:14, Matthew Dempsky wrote:
> In vmt_tick() we could notice anytime the reported sensor value jumps
> significantly and then wind forward the clocks like we do when
> recovering from ACPI sleep.
Yes, I was thinking something like that. vmt should maybe provide a
real tim
In vmt_tick() we could notice anytime the reported sensor value jumps
significantly and then wind forward the clocks like we do when
recovering from ACPI sleep.
On Wed, Jul 25, 2012 at 10:52 AM, Ted Unangst wrote:
> I have an OpenBSD guest running in vmware player on my laptop. My
> problem is t
I have an OpenBSD guest running in vmware player on my laptop. My
problem is that when I suspend the laptop, the clock in vmware doesn't
keep ticking, and before I know it, openbsd thinks it's last Monday.
I see vmt provides a timedelta sensor, but I don't think ntp is up to
the task of jamming t
5 matches
Mail list logo
