[9front] slow boot (under OpenBSD vmm)

[9front] slow boot (under OpenBSD vmm)

[rsykora]

Dear list,

I tried to run 9front under the virtual machine provided by OpenBSD and
one thing I repeatedly encounter is a very slow boot. I monitor the boot
using the command

vmctl console 9front

and I quite quickly reach the "fingerprint" line:

Plan 9
125 holes free
0x00021000 0x0009f000 516096
0x00100000 0x00110000 65536
0x0059b000 0x269ee000 642068480
642650112 bytes free
cpu0: 6781MHz GenuineIntel P6 (AX 000306A9 CX F6982203 DX 079BA97F)
ELCR: 02E8
#l0: virtio: 1000Mbps port 0x2000 irq 5 ea 52540000ee03
i8042: kbd init failed
1998M memory: 618M kernel data, 1380M user, 2005M swap
bootfs: Wed Apr 13 14:58:09 GMT 2022
fingerprint: 158c55aeed3a9f19e1243d78fdbcf31890b5e2ef

Then it may take 5 minutes to see
nusb/usbd: no hubs
current fs is "main"
11 uids read, 3 groups used
63-bit cwfs as of Wed Apr 13 16:57:24 2022
last boot Sun May 22 10:25:20 2022

then it again takes some minutes before
ipconfig: write(try fe80::5054:ff:fe00:ee03 /64 fe80:: 0): interface does not support multicast
ipconfig: can't start IPv6 on /net/ether0, address fe80::5054:ff:fe00:ee03
ipconfig: dialicmp6: cs: can't translate address

and I also saw the line
init: starting /bin/rc
take a long time (from time to time) before a prompt finally appears.

Can anybody tell me what can be happening and if I can help it
boot faster?

Thank you.

Best regards
Ruda

Re: [9front] slow boot (under OpenBSD vmm)

[mkf9]

rsykora@disroot.org wrote:

> I tried to run 9front under the virtual machine provided by OpenBSD and
> one thing I repeatedly encounter is a very slow boot. I monitor the boot
> using the command
> [snip]
> take a long time (from time to time) before a prompt finally appears.
> 
> Can anybody tell me what can be happening and if I can help it
> boot faster?
> 
> Thank you.
> 
Afaik, openbsd 7.0 had some changes in clock emulation which casuses 
thing hang. used to work correctly on 6.9.
Not sure of any workaround for this issue.

Re: [9front] slow boot (under OpenBSD vmm)

[cinap_lenrek]

pass nora6=1 to boot arguments (plan9.ini or multiboot aruments).

see plan9.ini(8):

        nora6=
          Disable automatic IPv6 configuration from incoming router
          advertisements.


it is most likely trying to do SLAAC, but the emulated virtio
ethernet is busted and wont support multicast anyway.

--
cinap

Re: [9front] slow boot (under OpenBSD vmm)

[james palmer]

also experiencing this issue, passing nora6= does not fix the slowness.

seems like something is wrong with the way 9 calculates the clock speed or something about the way vmm reports it.

on the openbsd host:
sysctl hw.model -> Intel(R) Xeon E5-2430L 0 @ 2.00GHz
sysctl hw.cpuspeed -> 2300

in the 9front vm:
cpu0: 3998MHz GenuineIntel Xeon5000-series (AX 000206D7 CX 96982203 DX 079BA97F)

the clock speed reported in the vm varies i have seen 3900-4000 MHz.

- james

On 23 May 2022 18:15:35 BST, cinap_lenrek@felloff.net wrote:
>pass nora6=1 to boot arguments (plan9.ini or multiboot aruments).
>
>see plan9.ini(8):
>
>        nora6=
>          Disable automatic IPv6 configuration from incoming router
>          advertisements.
>
>
>it is most likely trying to do SLAAC, but the emulated virtio
>ethernet is busted and wont support multicast anyway.
>
>--
>cinap

Re: [9front] slow boot (under OpenBSD vmm)

[ori]

Quoth james palmer <james@biobuf.link>:
> also experiencing this issue, passing nora6= does not fix the slowness.
> 
> seems like something is wrong with the way 9 calculates the clock speed or something about the way vmm reports it.
> 
> on the openbsd host:
> sysctl hw.model -> Intel(R) Xeon E5-2430L 0 @ 2.00GHz
> sysctl hw.cpuspeed -> 2300
> 
> in the 9front vm:
> cpu0: 3998MHz GenuineIntel Xeon5000-series (AX 000206D7 CX 96982203 DX 079BA97F)
> 
> the clock speed reported in the vm varies i have seen 3900-4000 MHz.
> 
> - james

clocks on vmm have always been a bit wonky. I'm
not convinced that this is the cause of the slow
boot.

I suspect the fix is going to be on the OpenBSD
side. If someone has time, I'd suggest bisecting
vmd to find the commit that broke it.