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
