On Sun, Dec 29, 2019 at 03:30:15AM +0100, Klemens Nanni wrote:
> On Sun, Dec 29, 2019 at 10:29:48AM +1000, Jonathan Matthew wrote:
> > > + memset(&vpg, 0, sizeof(vpg));
> > > + pagelen = hdr.page_length * 4;
> >
> > We probably should check that this isn't larger than the size of vpg.
> pagelen is 64, sizeof(vpg) is 80.
>
> > link->target isn't the right place to put this, for one thing it's only 16
> > bits
> > and the wwn is 64 bits, and it's used throughout the driver to look up
> > devices
> > in an array, so changing it will break things. I think link->port_wwn is
> > the
> > right place to store it.
> Ah, link->target was there because I played with that in earlier diffs,
> port_wwn is indeed correct here.
>
> > The fields in the page returned by the driver are also little endian, so
> > you'd
> > need letoh64(vpg.wwid) here.
> Thanks, I see that is done elsewhere in the driver, too.
>
> > You should still return 0 here, as continuing on will send the SAS device
> > page 0 request to the raid volume, which will probably upset the controller
> > enough to stop talking to you.
> Oh well... that explains the hangs - I accidentially dropped the return,
> it should obviously stay and my diff should only add another page fetch.
>
> With the return the kernel no longer loops in mpii_wait() and boots fine.
>
> vpg.wwid however is zero; the other members volume_id, volume_bus, and
> volume_ioc are set/non-zero, guid contains "LSI" and name contains
> "ssd1e" which I how I named this RAID volume in OBP.
>
> So why are those bits filled in but not the WWID?
I think we have the wrong size for the volume name, hence the difference
between the size reported by the controller and the size of vpg.
try this out?
diff --git sys/dev/pci/mpiireg.h sys/dev/pci/mpiireg.h
index 638f31171d1..11dacf86953 100644
--- sys/dev/pci/mpiireg.h
+++ sys/dev/pci/mpiireg.h
@@ -1355,7 +1355,7 @@ struct mpii_cfg_raid_vol_pg1 {
u_int8_t guid[24];
- u_int8_t name[32];
+ u_int8_t name[16];
u_int64_t wwid;
