> Date: Thu, 26 Dec 2019 19:02:26 +0100
> From: Klemens Nanni <k...@openbsd.org>
>
> On Thu, Dec 26, 2019 at 06:25:10PM +0100, Mark Kettenis wrote:
> > Hmm, you really shouldn't end up there if you're booting by WWN. I
> > guess the
> >
> > bp->val[0] == sl->port_wwn
> >
> > check is failing in your case. What are the values of:
> >
> > bp->val[0]
> > sl->port_wwn
> > sl->node_wwn
> >
> > in your case?
> For the RAID volume sd0:
>
> bp->val[0] = 0x3aa32290d5dcd16c
> sl->port_wwn = 0
> sl->node_wwn = 0
Well, there's your problem. The mpii(4) doesn't fill in the WWNs for
the logical volume so there is nothing that can be matched to the WWN
from the bootpath.
> See below a diff for debug printf() I use to look at thoes values.
> Complete console log from OBP prompt to multiuser follows to to show the
> boot process and debug output for all devices.
>
> What I find odd is how 0aa32290d5dcd16c is the WWID of the RAID volume,
> and yet all devices attaching to scsibus* including those not being part
> of the RAID show the very same bp->val[0] of 3aa32290d5dcd16c.
bp->val[0] comes from the boot path; there is only one.
As you can see, the WWNs are filled in for the other disks (sd1, cd0)
that attach to the controller. So you probably need some additional
code in mpii(4) to fill in the WWNs for logical volumes. I recommend
talking to dlg@ and jmatthew@ directly about that.
Cheers,
Mark
P.S. dlg@ and jmatthew@ may also be interested in the following
unrecognized device:
> vendor "Symbios Logic", unknown product 0x007e (class mass storage subclass
> SAS, rev 0x03) at pci19 dev 0 function 0 not configured
