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 <sf@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
No comments:
Post a Comment