0.1.208 crashes windows 11 on loading viostor

[m9x3mos]

Was attempting to setup windows 11 VM with .208 version and when I install the storage driver during the install process the system crashes out completely. I attempt the same operations with .185 and it is working correctly. There is something in the new driver that is incompatible with Windows 11 22000.282.

[vrozenfe]

@m9x3mos Was it a BSOD? Can you post the bugcheck code or even better a screenshot from the failing VM. Can you post the qemu command line. Since this project is mostly related to the virtio-win packaging and RPM building process, I would suggest opening a new issue in virtio-win project.

Btw, how did you get that 282 build? Through the official Windows Insider Program channel? We need this information for reproducing the problem.

Best regards,

[si458]

@m9x3mos try the latest build .215 as i have no issues here for Windows 11 https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.215-1/

[m9x3mos]

Hello @si458, I just tried .215 and I am still running into the same issue. .185 still works without issue.

[si458]

Hello @si458, I just tried .215 and I am still running into the same issue. .185 still works without issue.

What hypervisor are you using? Can you output the command you are running?

No issues here with proxmox 7.1 and Windows 11 iso direct from Windows and the 215-2 virtio iso

[m9x3mos]

Hello @si458, I am using bhyve on TrueNAS Core 12 U7. Creation is all done by UI. I mount a Win 11 ISO and the ISO with Virtio drivers for the install process. Then when getting to the storage part, I point it to the win11 folder to find the storage driver.

[vrozenfe]

@m9x3mos Can you please post the qemu command line? Thanks, Vadim.

[m9x3mos]

Hello @vrozenfe, I can try and open a ticket with TrueNAS but that is not exposed to the user and is handled in the System DB which can't be viewed easily.

[m9x3mos]

Hello @vrozenfe, Think I was able to find what you are looking for /usr/sbin/bhyve -c cpus=12,sockets=1,cores=6,threads=2 -m 16384 -A -w -H -s 0:0,hostbridge -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -s 3:0,ahci,cd:/mnt/MyPool/DatabaseStaging/Win11.22000.438.220115-R.ISO,cd:/mnt/MyPool/DatabaseStaging/virtio-win-0.1.215.iso -s 30:0,xhci,tablet -s 31,lpc -s 2:0,ahci -s 5:0,e1000,tap1,mac=00:a0:98:01:42:f5 -s 4:0,virtio-blk,/dev/zvol/MyPool/VMStorage/TrueNAS_11SQL-pidyr -l com1,/dev/nmdm8A -s 29,fbuf,vncserver,tcp=0.0.0.0:6077,w=1280,h=720 8_TrueNAS_11SQL

I think the last line here in the log is pointing to the problem 24/01/2022 19:44:07 Listening for VNC connections on TCP port 6077 24/01/2022 19:44:07 Listening for VNC connections on TCP6 port 6077 Unhandled ps2 keyboard command 0x02 24/01/2022 19:44:12 other clients: 24/01/2022 19:44:12 Client Protocol Version 3.8 24/01/2022 19:44:12 Protocol version sent 3.8, using 3.8 24/01/2022 19:44:12 rfbProcessClientSecurityType: executing handler for type 1 24/01/2022 19:44:12 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 24/01/2022 19:44:12 Pixel format for client 127.0.0.1: 24/01/2022 19:44:12 32 bpp, depth 24, little endian 24/01/2022 19:44:12 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 24/01/2022 19:44:12 Using image quality level 6 for client 127.0.0.1 24/01/2022 19:44:12 Using JPEG subsampling 0, Q79 for client 127.0.0.1 24/01/2022 19:44:12 Using compression level 2 for client 127.0.0.1 24/01/2022 19:44:12 Enabling NewFBSize protocol extension for client 127.0.0.1 24/01/2022 19:44:12 Enabling LastRect protocol extension for client 127.0.0.1 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC8) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC7) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECD) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xC0A1E5CE) 24/01/2022 19:44:12 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5664) 24/01/2022 19:44:12 Enabling full-color cursor updates for client 127.0.0.1 24/01/2022 19:44:12 Using tight encoding for client 127.0.0.1 Unhandled ps2 keyboard command 0x02 Unhandled ps2 keyboard command 0x02 rdmsr to register 0x3a on vcpu 0 Assertion failed: (n >= 2 && n <= BLOCKIF_IOV_MAX + 2), function pci_vtblk_proc, file /truenas-releng/freenas/_BE/os/usr.sbin/bhyve/pci_virtio_block.c, line 278. fbuf frame buffer base: 0xc42600000 [sz 16777216]

[vrozenfe]

@m9x3mos Thanks. Yeah, it makes sense niw Assertion failed: (n >= 2 && n <= BLOCKIF_IOV_MAX + 2), function pci_vtblk_proc, file /truenas-releng/freenas/_BE/os/usr.sbin

if the following patch https://pagure.io/freebsd-src/c/476068647b63dab6244e9bee4b478cf18ced2389 is still correct then BLOCKIF_IOV_MAX is equal to 128 this is definitely contradicts with https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viostor/virtio_stor.h#L90

I think that increasing the MAX_PHYS_SEGMENTS to 512 was a kind of premature action from my side. The same sort of problem was also reported in the case of direct LUN configuration. I will try to address this issue in the next release.

Best regards, Vadim.