On Mon, Apr 24, 2023 at 3:47 PM Aaron Mason <simplersolut...@gmail.com> wrote: > > On Fri, Apr 21, 2023 at 2:50 PM Aaron Mason <simplersolut...@gmail.com> wrote: > > > > On Fri, Apr 21, 2023 at 1:39 PM Aaron Mason <simplersolut...@gmail.com> > > wrote: > > > > > > On Fri, Apr 7, 2023 at 3:25 AM Antun Matanović > > > <matanovic.an...@gmail.com> wrote: > > > > > > > > On Thu, 6 Apr 2023 at 12:55, Fabio Martins <fosf...@gmail.com> wrote: > > > > > > > > > > Try to add an entry in grub like in this article: > > > > > > > > > > https://raby.sh/installing-openbsd-on-ovhs-vps-2016-kvm-machines.html > > > > > > > > I have tried that, but it did not resolve the issue. Sorry I forgot to > > > > mention it originally. > > > > > > > > On Thu, 6 Apr 2023 at 14:24, Janne Johansson <icepic...@gmail.com> > > > > wrote: > > > > > > > > > > That is very much not the same issue. The arm64 instances on Oracle > > > > > finds the correct kernel and boots it, it just crashes at or after the > > > > > scsi attachment. > > > > > > > > This has been my experience as well, except on the amd64 instance, > > > > haven't tried arm64. > > > > > > > > > > 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