On Thu, Sep 08, 2022 at 08:24:11AM -0500, Scott Cheloha wrote:
> On Thu, Sep 08, 2022 at 05:52:43AM +0300, Pavel Korovin wrote:
> > On 09/07, Scott Cheloha wrote:
> > > Just to make sure that my changes to acpihpet(4) actually caused
> > > the problem, I have a few more questions:
> > >
> > > 1.
On Thu, Sep 08, 2022 at 05:52:43AM +0300, Pavel Korovin wrote:
> On 09/07, Scott Cheloha wrote:
> > Just to make sure that my changes to acpihpet(4) actually caused
> > the problem, I have a few more questions:
> >
> > 1. When did you change the OS type?
>
> 03 August, after that, there was a
On 09/07, Scott Cheloha wrote:
> Just to make sure that my changes to acpihpet(4) actually caused
> the problem, I have a few more questions:
>
> 1. When did you change the OS type?
03 August, after that, there was a local snpashot built from sources
fetched on 17 Aug 2022 22:12:57 +0300 which
Oh no, sorry, that was too early.
Double-checked once again, no, this problem still exists if Guest OS
Version is set to "FreeBSD Pre-11 versions (32-bit)".
If I set Guest OS Version to "FreeBSD 11 (32-bit)", the problem
disappears.
On 09/08, Pavel Korovin wrote:
> Hi Scott,
>
> Thank you for
On Thu, Sep 08, 2022 at 05:01:33AM +0300, Pavel Korovin wrote:
> Hi Scott,
>
> Thank you for the fix!
>
> I found what triggered this behaviour: it was the change in Guest OS
> Version in VM Options.
>
> I deploy VMs with sysutils/packer, some time ago I noticed that VM type in
> my templates
Hi Scott,
Thank you for the fix!
I found what triggered this behaviour: it was the change in Guest OS
Version in VM Options.
I deploy VMs with sysutils/packer, some time ago I noticed that VM type in
my templates is specified as freebsd11_64Guest, which isn't consistent with
vmt(4), as it
On Sat, Sep 03, 2022 at 01:50:28PM +0300, Pavel Korovin wrote:
> After these changes, OpenBSD VMware guest's clock is galloping into the
> future like this:
> Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s
> Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by
After these changes, OpenBSD VMware guest's clock is galloping into the
future like this:
Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s
Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s
Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by
> On Aug 29, 2022, at 22:54, Jonathan Gray wrote:
>
> On Mon, Aug 29, 2022 at 12:02:42PM -0500, Scott Cheloha wrote:
>> If hv_delay() never causes a vm exit, but tsc_delay() *might* cause a
>> vm exit, and both have microsecond or better resolution, then
>> hv_delay() is the preferable delay(9)
On Mon, Aug 29, 2022 at 12:02:42PM -0500, Scott Cheloha wrote:
> If hv_delay() never causes a vm exit, but tsc_delay() *might* cause a
> vm exit, and both have microsecond or better resolution, then
> hv_delay() is the preferable delay(9) implementation where it is
> available because vm exits
On Thu, Aug 25, 2022 at 03:57:48PM +1000, Jonathan Gray wrote:
> On Wed, Aug 24, 2022 at 11:05:30PM -0500, Scott Cheloha wrote:
> > On Wed, Aug 24, 2022 at 05:51:14PM +1000, Jonathan Gray wrote:
> > > On Tue, Aug 23, 2022 at 12:20:39PM -0500, Scott Cheloha wrote:
> > > > > Hyper-V generation 1 VMs
On Wed, Aug 24, 2022 at 11:05:30PM -0500, Scott Cheloha wrote:
> On Wed, Aug 24, 2022 at 05:51:14PM +1000, Jonathan Gray wrote:
> > On Tue, Aug 23, 2022 at 12:20:39PM -0500, Scott Cheloha wrote:
> > > > Hyper-V generation 1 VMs are bios boot with emulation of the usual
> > > > devices. 32-bit and
On Wed, Aug 24, 2022 at 05:51:14PM +1000, Jonathan Gray wrote:
> On Tue, Aug 23, 2022 at 12:20:39PM -0500, Scott Cheloha wrote:
> > > Hyper-V generation 1 VMs are bios boot with emulation of the usual
> > > devices. 32-bit and 64-bit guests.
> > >
> > > Hyper-V generation 2 VMs are 64-bit uefi
On Tue, Aug 23, 2022 at 12:20:39PM -0500, Scott Cheloha wrote:
> > Hyper-V generation 1 VMs are bios boot with emulation of the usual
> > devices. 32-bit and 64-bit guests.
> >
> > Hyper-V generation 2 VMs are 64-bit uefi with paravirtualised devices.
> > 64-bit guests only.
> >
> > There is no
On Tue, Aug 23, 2022 at 04:04:39PM +1000, Jonathan Gray wrote:
> On Mon, Aug 22, 2022 at 09:37:02AM -0500, Scott Cheloha wrote:
> > On Wed, Aug 17, 2022 at 09:00:12PM +1000, Jonathan Gray wrote:
> > > On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote:
> > > >
> > > > It seems to me it
On Mon, Aug 22, 2022 at 09:37:02AM -0500, Scott Cheloha wrote:
> On Wed, Aug 17, 2022 at 09:00:12PM +1000, Jonathan Gray wrote:
> > On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote:
> > >
> > > It seems to me it would be cleaner if the decision of what to use for
> > > delay could be
On Wed, Aug 17, 2022 at 09:00:12PM +1000, Jonathan Gray wrote:
> On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote:
> >
> > It seems to me it would be cleaner if the decision of what to use for
> > delay could be moved into an md file.
> >
> > Or abstract it by having a numeric
On Wed, Aug 17, 2022 at 09:00:12PM +1000, Jonathan Gray wrote:
> On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote:
> >
> > It seems to me it would be cleaner if the decision of what to use for
> > delay could be moved into an md file.
> >
> > Or abstract it by having a numeric weight
On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote:
>
> It seems to me it would be cleaner if the decision of what to use for
> delay could be moved into an md file.
>
> Or abstract it by having a numeric weight like timecounters or driver
> match return numbers.
diff against your
On Wed, Aug 17, 2022 at 12:37:52AM -0500, Scott Cheloha wrote:
> On Wed, Aug 17, 2022 at 02:28:14PM +1000, Jonathan Gray wrote:
> > On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> > > On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> > > >
> > > > In the future
On Wed, Aug 17, 2022 at 02:28:14PM +1000, Jonathan Gray wrote:
> On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> > On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> > >
> > > In the future when the LAPIC timer is run in oneshot mode there will
> > > be no
On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> >
> > In the future when the LAPIC timer is run in oneshot mode there will
> > be no lapic_delay().
> >
> > [...]
> >
> > This is *very* bad for older amd64
On Tue, Aug 16, 2022 at 11:53:51AM -0500, Scott Cheloha wrote:
> On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> >
> > In the future when the LAPIC timer is run in oneshot mode there will
> > be no lapic_delay().
> >
> > [...]
> >
> > This is *very* bad for older amd64
On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
>
> In the future when the LAPIC timer is run in oneshot mode there will
> be no lapic_delay().
>
> [...]
>
> This is *very* bad for older amd64 machines, because you are left with
> i8254_delay().
>
> I would like to offer a less
On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> Hi,
>
> In the future when the LAPIC timer is run in oneshot mode there will
> be no lapic_delay().
>
> This is fine if you have a constant TSC, because we have tsc_delay().
>
> This is *very* bad for older amd64 machines, because
On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote:
> Hi,
>
> In the future when the LAPIC timer is run in oneshot mode there will
> be no lapic_delay().
>
> This is fine if you have a constant TSC, because we have tsc_delay().
>
> This is *very* bad for older amd64 machines, because
26 matches
Mail list logo
