On Wed, Nov 23, 2016 at 12:09:57AM +0100, s...@openbsd.org wrote: > On Tue, 22 Nov 2016, Mike Belopuhov wrote: > > > vmd hackers and users seem to be able to trigger the assertion > > below every time they do down and then up (with a dhclient for > > instance): > > > > panic: kernel diagnostic assertion "m != NULL" failed: file > > "/usr/src/sys/dev/pci/if_vio.c", line 1008 > > Starting stack trace... > > panic() at panic+0x10b > > __assert() at __assert+0x25 > > vio_rxeof() at vio_rxeof+0x1db > > vio_rx_intr() at vio_rx_intr+0x28 > > virtio_check_vqs() at virtio_check_vqs+0x8c > > virtio_pci_legacy_intr() at virtio_pci_legacy_intr+0x71 > > intr_handler() at intr_handler+0x67 > > Xintr_legacy7() at Xintr_legacy7+0xdd > > --- interrupt --- > > > > The culprit is that vio_rx_drain and vio_tx_drain functions > > are not properly implemented: they m_freem mbufs attached to > > ring slots but do nothing about unconfiguring the backend > > virtqueue. This results in us thinking that the ring is > > empty when we UP the interface the next time, but then a > > completion event arrives for the slot that doesn't have an > > associated mbuf anymore. > > No, that's wrong. vio_*_drain don't need to do anything with the rings > because the device is reset before they are called. (the virtio_reset() > call). It sounds like vmd does not implement the reset properly. When the
It doesn't. At least not yet.
