Run: QEMU crashes on "GLib: Too many handles to wait for!" when using WSL2 with Windows-native QEMU

[kleinesfilmroellchen]

Running SerenityOS on Windows 10 20H2 with WSL2 Debian 10.9. Debian's QEMU can start just fine with an X Server on the host machine. However, when switching over to native QEMU (newest version) and setting the options as required:

export SERENITY_QEMU_BIN='/mnt/c/Program Files/qemu/qemu-system-i386.exe'
export SERENITY_DISK_IMAGE='[...]\serenity\Build\i686\_disk_image'

QEMU will start up but hang at the following message:

[#0 colonel(0:0)]: Scheduler[0]: idle loop running
[init_stage2(2:2)]: PCI [0000:00:00:00] PCI::ID [8086:1237]
[init_stage2(2:2)]: PCI [0000:00:01:00] PCI::ID [8086:7000]
[init_stage2(2:2)]: PCI [0000:00:01:01] PCI::ID [8086:7010]
[init_stage2(2:2)]: PCI [0000:00:01:02] PCI::ID [8086:7020]
[init_stage2(2:2)]: PCI [0000:00:01:03] PCI::ID [8086:7113]
[init_stage2(2:2)]: PCI [0000:00:02:00] PCI::ID [1234:1111]
[init_stage2(2:2)]: PCI [0000:00:03:00] PCI::ID [8086:2922]
[init_stage2(2:2)]: PCI [0000:00:04:00] PCI::ID [1af4:1003]
[init_stage2(2:2)]: PCI [0000:00:05:00] PCI::ID [1af4:1005]
[init_stage2(2:2)]: PCI [0000:00:06:00] PCI::ID [8086:100e]
[#0 init_stage2(2:2)]: BXVGA: framebuffer @ P0xf8000000
[#0 init_stage2(2:2)]: BXVGADevice resolution set to 1024x768 (pitch=4096)
[init_stage2(2:2)]: UHCI: Controller found PCI::ID [8086:7020] @ PCI [0000:00:01:02]
[init_stage2(2:2)]: UHCI: I/O base IO c080
[init_stage2(2:2)]: UHCI: Interrupt line: 11
[#0 init_stage2(2:2)]: UHCI: Allocated framelist at physical address P0x00e40000
[#0 init_stage2(2:2)]: UHCI: Framelist is at virtual address V0xc115d000
[#0 init_stage2(2:2)]: UHCI: QH(0xc115f000) @ 14946304: link_ptr=14946338, element_link_ptr=1
[#0 init_stage2(2:2)]: UHCI: QH(0xc115f020) @ 14946336: link_ptr=14946370, element_link_ptr=1
[#0 init_stage2(2:2)]: UHCI: QH(0xc115f040) @ 14946368: link_ptr=14946402, element_link_ptr=1
[#0 init_stage2(2:2)]: UHCI: QH(0xc115f060) @ 14946400: link_ptr=14946434, element_link_ptr=1
[#0 init_stage2(2:2)]: UHCI: QH(0xc115f080) @ 14946432: link_ptr=14958593, element_link_ptr=1
[#0 init_stage2(2:2)]: UHCI: Reset completed
[#0 init_stage2(2:2)]: UHCI: Started
[#0 init_stage2(2:2)]: DMIExpose: SMBIOS 32bit Entry point @ P0x000f5870
[#0 init_stage2(2:2)]: DMIExpose: Data table @ P0x000f5890
[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00]
[#0 init_stage2(2:2)]: Trying to unregister unused handler (?)
[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported!
[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0
qemu-system-i386.exe: warning: GLib: Too many handles to wait for!

The hang is so severe that even Ctrl-C doesn't do something. The QEMU window appears but is reported as not responding almost immediately by Windows and needs to be force closed.

[n0toose]

So wait, in order to reproduce this and check whether my recent change updating Serenity's built-in QEMU version to the latest release candidate; Is this being caused by the recent 6.0.0-rc3, the Windows build running on top of 6.0.0-rc3 or 5.2.0 (which is the latest stable version)?

[kleinesfilmroellchen]

Yes, this is running on 6.0.0-rc3

[kleinesfilmroellchen]

Just reproduced on 5.2.0

[IdanHo]

Results of testing on a windows virtual machine: This is due to the newly added VirtIO drivers. Since they work just fine on linux i think this is most likely a problem in QEMU's windows builds (as virtio is completely host agnostic).
short term solution: adding a kernel commandline flag to not initialize VirtIO
long term solution: opening a qemu issue on their bugtracker

[kleinesfilmroellchen]

Thanks for this quick info. I'll be submitting this to their bug tracker. @IdanHo How do I specify this command-line flag?

[IdanHo]

Thanks for this quick info. I'll be submitting this to their bug tracker. @IdanHo How do I specify this command-line flag?

well ill first have to add said commandline flag before you can use it :)

[kleinesfilmroellchen]

Bug is now reported as number 1924912 here.

[stweil]

this is most likely a problem in QEMU's windows builds

QEMU has no official Windows builds. Did you use the QEMU for Windows installer from my website?

[ADKaster]

Using this version from your website here: https://qemu.weilnetz.de/w64/2020/

$ "$SERENITY_QEMU_BIN" --version
QEMU emulator version 5.1.0 (v5.1.0-11824-g8699890d91-dirty)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

I am able to repro the issue, yes. It seems like the other people in this thread are using the binaries from there as well?

The instructions for WSL2 point to the qemu link that has a link to your site, anyway.

[kleinesfilmroellchen]

QEMU has no official Windows builds. Did you use the QEMU for Windows installer from my website?

I didn't even realize that they aren't official but yes, I used these installers from the dates that matched the announcements for specific versions.

[stweil]

QEMU works nicely when I remove -device virtio-serial and -device virtconsole,chardev=stdout from the command arguments.

[IdanHo]

QEMU works nicely when I remove -device virtio-serial and -device virtconsole,chardev=stdout from the command arguments.

Well yes, but that removes the VirtIO devices, so thats not very surprising :^)

[stweil]

I did not remove the other VirtIO devices...

[IdanHo]

I did not remove the other VirtIO devices...

I see, you didnt remove the VirtRNG device, so that narrows down the problem a bit, but both virtrng and virtconsole devices are handled by the same code in serenity, so im not entirely sure why there would be any difference in behaviour

[ADKaster]

@stweil It seems the limit we're running into (MAXIMUM_WAIT_OBJECTS) was overcome/avoided in glib version 2.59.1 with this commit/PR:

Commit: https://gitlab.gnome.org/GNOME/glib/-/commit/33158c86c102eccb197bd60918ce1ecebc62ac3f

PR: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/535

How involved would it be to bump the version of glib shipped with your QEMU binaries? It looks like the current version is 2.54.3

[stweil]

I use packages from Cygwin (which are sometimes much behind the official stable releases) for cross compilation on Debian. Building my own glib would require some work and – which is worse – more disk space on my server.

As far as I know Fedora provides recent cross packages, so maybe I have to switch my Linux distribution and use that.