We have the SAS2008 on our board but we don't have the NVRAM
populated. We do have a flash on the board that holds the
firmware and so on. What we found (by experimentation) is
that the firmware detects or knows there isn't an NVRAM and
stores some of the NVRAM settings somewhere in the flash
(we've dumped the flash and confirmed there are things in
it).
We've seen a problem where we use the max/min linkrate in
sysfs -- it looks like the linkrates get set correctly in
page1, we also copy the port/port flags/phy flags per some
errata. The problem shows up when it updates pg1. At that
point, the following code is executed ... I guess this would
be ok, except what we see happen is that whatever gets
written to the NVRAM fails to make anything work and since
it is in the NVRAM, even rebooting doesn't help. We have
figured out that using restore defaults in lsiutil fixes the
problem, but we would rather figure out why the linkrate
doesn't work.
mpt2sas_config_set_sas_iounit_pg1(struct MPT2SAS_ADAPTER
*ioc, Mpi2ConfigReply_t
*mpi_reply, Mpi2SasIOUnitPage1_t *config_page, u16
...
MPI2_CONFIG_ACTION_PAGE_WRITE_NVRAM;
r = _config_request(ioc, &mpi_request, mpi_reply,
MPT2_CONFIG_PAGE_DEFAULT_TIMEOUT,
config_page, sz);
What it looks like is that Pg1 has the autoconfig set, but
rather than having "0" in the dynamic port group, it how has
many phy numbers so it seems that on the next reboot, the
dynamic setup doesn't work -- however, I don't know that for
sure since I don't really know what the f/w does with it.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
