Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Aug 2022 15:29:46 +0100
From:      Jamie Landeg-Jones <jamie@catflap.org>
To:        mason@blisses.org, freebsd-hackers@FreeBSD.org
Cc:        eugen@grosbein.net
Subject:   Re: Help debugging Vultr boot delay...?
Message-ID:  <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net>
In-Reply-To: <YwWoo5t22D33YNTA@blisses.org>
References:  <YwWoo5t22D33YNTA@blisses.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Mason Loring Bliss <mason@blisses.org> wrote:

> The second issue is still there and while I've brought it to their
> attention, it'd probably be useful if they had some expert help. What I'm
> observing with new VMs, both their images and via FreeBSD's own install
> media, is a pause of one and three quarters minutes (around 105 seconds)
> between:
>
>     ugen0.2: <QEMU QEMU USB Tablet> at usbus0
>
> and the next line, which appears to be:
>
>     hdacc0: <Generic (0x1af40022) HDA CODEC> at cad 0 on hdac0
>
> FreeBSD believes it's on Hyper-V 10.0.14393 [SP0] but the same VM booted
> into GNU/Linux probes KVM, so I've got to ask about that.

It appears to be their new KVM software. I have a number of vultr VMs (all
running FreeBSD, obviously!) and there is no problem.

I created a new 13.1 and a new 12.3 and saw the problem you describe.

I then snapshotted one of my live 13.0 instances, and restored that to a
new VM, and the problems you describe then appeared.

Remember, identical disk contents, different results.

Doing a 'kenv' on both boxes, the only relevant difference is
smbios.system.version / smbios.chassis.version as such:

< smbios.chassis.version="pc-i440fx-5.2"
> smbios.chassis.version="pc-i440fx-7.0"
< smbios.system.version="pc-i440fx-5.2"
> smbios.system.version="pc-i440fx-7.0"

The new instances are clearly being installed with a newer QEMU/KVM host.

Comparing dmesg.boot is more interesting.

As you say, the hypervisor is now grocked as Microsoft Hv

These are the relevant differences.
Again, exactly the same disk contents (running 13.0 in this case):

> Hyper-V Version: 10.0.14393 [SP0]
>   Features=0xa7e<TMREFCNT,SYNIC,SYNTM,APIC,HYPERCALL,VPINDEX,REFTSC,TMFREQ>
>   PM Features=0x0 [C0]
>   Features3=0x108<PCPUDPE,TMFREQ>
> Timecounter "Hyper-V" frequency 10000000 Hz quality 2000
> CPU: Intel Core Processor (Skylake, IBRS) (3408.00-MHz K8-class CPU)

< Hypervisor: Origin = "KVMKVMKVM"
---
> Hypervisor: Origin = "Microsoft Hv"

> Timecounter "Hyper-V-TSC" frequency 10000000 Hz quality 3000

> vmbus0: <Hyper-V Vmbus> on pcib0

> hdac0: <Intel 82801I HDA Controller> mem 0xfebf0000-0xfebf3fff irq 11 at device 4.0 on pci0

> hdacc0: <Generic (0x1af40022) HDA CODEC> at cad 0 on hdac0
> hdaa0: <Generic (0x1af40022) Audio Function Group> at nid 1 on hdacc0
> pcm0: <Generic (0x1af40022) (Analog)> at nid 3 and 5 on hdaa0

Why is the host even announcing an audio device to the guests?!
And is it more than coincidence that the delay comes before hdacc0 is groked?

Anyway, if the fault is with FreeBSD, it's not a recent fault, it's just that
changes in their host software are revealing them.

Hope this helps a bit.

Cheers, Jamie




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202208271429.27RETkGg063822>