I can reproduce it with this in QEMU 8.0 in Winders (thanks Antun who sent something like this to the bugs@ list):
qemu-system-x86_64 -accel whpx,kernel-irqchip=off -machine q35 \ -cpu EPYC-Rome,-monitor -m 8g -smp 6,sockets=1,cores=6 \ -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 -vga virtio \ -drive if=virtio,file=miniroot73.img -device virtio-scsi-pci,id=scsi The temporary workaround patch results in a booting system. On Mon, May 1, 2023 at 4:56 AM Stefan Fritsch <s...@sfritsch.de> wrote: > > Hi, > > what qemu version are you using? I cannot reproduce this with qemu 7.2. > Can you try with a newer qemu? > > Cheers, > Stefan > > Am 25.04.23 um 14:53 schrieb Aaron Mason: > >>>> Yeah I'm getting the same thing. Trying a build in QEMU and > >>>> transferring in to see if that helps. Will report back. > >>>> > >>> > >>> Ok, good news, it still crashes at the same spot, but this time I've > >>> got more data. Copying in tech@ - if I've forgotten anything let me > >>> know and I'll fire up a fresh instance. > >>> > >>> [REDACTED] > >>> vioscsi_req_done(e,ffff800000024a00,fffffd803f81c338,e,ffff800000024a00,ffff800 > >>> 0000d3228) at vioscsi_req_done+0x26 > >>> [REDACTED] > >> > >> Ok, so based on the trace I got, I was able to trace the stop itself > >> back to line 299 of vioscsi.c (thank. you. random relink. And > >> anonymous CVS): > >> > >> 293 vioscsi_req_done(struct vioscsi_softc *sc, struct virtio_softc > >> *vsc, > >> 294 struct vioscsi_req *vr) > >> 295 { > >> 296 struct scsi_xfer *xs = vr->vr_xs; > >> 297 DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr, > >> xs); > >> 298 > >> -->299 int isread = !!(xs->flags & SCSI_DATA_IN); > >> 300 bus_dmamap_sync(vsc->sc_dmat, vr->vr_control, > >> 301 offsetof(struct vioscsi_req, vr_req), > >> 302 sizeof(struct virtio_scsi_req_hdr), > >> 303 BUS_DMASYNC_POSTWRITE); > >> > >> Maybe if I follow the rabbit hole enough, I might find out what's > >> going wrong between the driver and OCI. I've got a day off tomorrow > >> (yay for war I guess), I'll give it a bash and see where we end up. > >> > >> -- > >> Aaron Mason - Programmer, open source addict > >> I've taken my software vows - for beta or for worse > > > > I enabled debugging on the vioscsi driver, rebuilt the RAMDISK kernel > > with those drivers enabled, and got this: > > > > vioscsi0 at virtio1: qsize 128 > > scsibus0 at vioscsi0: 255 targets > > vioscsi_req_get: 0xfffffd803f80d338 > > vioscsi_scsi_cmd: enter > > vioscsi_scsi_cmd: polling... > > vioscsi_scsi_cmd: polling timeout > > vioscsi_scsi_cmd: done (timeout=0) > > vioscsi_scsi_cmd: enter > > vioscsi_scsi_cmd: polling... > > vioscsi_vq_done: enter > > vioscsi_vq_done: slot=127 > > vioscsi_req_done: enter vr: 0xfffffd803f80d338 xs: 0xfffffd803f8a5e58 > > vioscsi_req_done: done 0, 2, 0 > > vioscsi_vq_done: slot=127 > > vioscsi_req_done: enter vr: 0xfffffd803f80d338 xs: 0x0 > > uvm_fault(0xffffffff813ec2e0, 0x8, 0, 1) -> e > > fatal page fault in supervisor mode > > trap type 6 code 0 rip ffffffff810e6190 cs 8 rflags 10286 cr2 8 cpl e > > rsp ffffffff81606670 > > gsbase 0xffffffff813dfff0 kgsbase 0x0 > > panic: trap type 6, code=0, pc=ffffffff810e6190 > > > > That "xs: 0x0" bit feels like a clue. It should be trivial to pick up > > and handle, but what would be the correct way to handle that? > > > > If I have it return if "xs" is found to be NULL, it continues - the > > debugging suggests it goes through each possible target before > > finishing up. I don't know if that's correct, but it seems to continue > > booting after that even if my example didn't detect the drive with the > > kernel I built (I used the RAMDISK kernel and it was pretty stripped > > down). > > > > I'm about to attempt a -STABLE build (I've got 7.3 installed and thus > > can't yet build a snapshot, but I will do that if this test succeeds) > > - here's the patch that hopefully fixes the problem. (and hopefully > > gmail doesn't clobber the tabs) > > > > Index: sys/dev/pv/vioscsi.c > > =================================================================== > > RCS file: /cvs/src/sys/dev/pv/vioscsi.c,v > > retrieving revision 1.30 > > diff -u -p -u -p -r1.30 vioscsi.c > > --- sys/dev/pv/vioscsi.c 16 Apr 2022 19:19:59 -0000 1.30 > > +++ sys/dev/pv/vioscsi.c 25 Apr 2023 12:51:16 -0000 > > @@ -296,6 +296,7 @@ vioscsi_req_done(struct vioscsi_softc *s > > struct scsi_xfer *xs = vr->vr_xs; > > DPRINTF("vioscsi_req_done: enter vr: %p xs: %p\n", vr, xs); > > > > + if (xs == NULL) return; > > int isread = !!(xs->flags & SCSI_DATA_IN); > > bus_dmamap_sync(vsc->sc_dmat, vr->vr_control, > > offsetof(struct vioscsi_req, vr_req), > > > > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse