On Thu, Aug 21, 2025 at 07:59:24AM +0200, Christof Meerwald wrote: > On Wed, Aug 20, 2025 at 09:58:23PM -0000, Michael van Elst wrote: > > cme...@cmeerw.org (Christof Meerwald) writes: > > > > >It's a virtio block device, and I am not seeing any errors on the > > >console. And everything starts working again when I enter a username > > >on the VNC console (once I get asked for a password). > > > > >So to me it looks like something gets stuck in the virtio > > >communication. > > > > Yes. On the other hand, I haven't seen the virtio block device > > locking up. Is there any other virtio device active? What exactly > > is "VNC console" to the guest ?
Did some print-style debugging (mainly in sys/dev/pci/virtio.c adding a print when it doesn't call "sc->sc_ops->kick" from virtio_enqueue_commit). Also added the virtqueue addresses when those are initialized, so I can later use those to inspect them in ddb. That showed that it didn't call kick for d3f8. And then inspecting the virtqueue data structures from ddb I see that vq->vq_avail->idx is 0xd3f8 and vq->vq_used->idx is 0xd3f7, and vq->vq_used->flags is 0. So it does look like some kind of race condition, also I thought that should be handled by qemu by first setting the vq->vq_used->flags to 0 and then checking vq->vq_used->idx again before relying on notifications being sent. BTW, when I then manually call sc->sc_ops->kick from ddb, it all starts working again. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
