Date: Fri, 22 Jan 2010 08:46:17 -0500 From: John Baldwin <jhb@freebsd.org> To: Stephane LAPIE <stephane.lapie@darkbsd.org> Cc: freebsd-hardware@freebsd.org Subject: Re: DELL SAS5/E Controller bug Message-ID: <201001220846.17419.jhb@freebsd.org> In-Reply-To: <4B59057D.9000500@darkbsd.org> References: <4B56CD4C.80503@darkbsd.org> <201001210749.40575.jhb@freebsd.org> <4B59057D.9000500@darkbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 21 January 2010 8:55:09 pm Stephane LAPIE wrote:
> John Baldwin wrote:
> > Gah, that should be the case that I ignore. Can you replace the second
> > warnx() call I added with this:
> >
> > warnx("mpt_read_ioc_page(6): %s (%x)", mpt_ioc_status(IOCStatus),
> > IOCStatus);
>
> I now get the following message :
> mptutil: mpt_read_ioc_page(6): Invalid configuration page (8022)
>
> (Though I guess this doesn't tell anything that we did not know initially)
Ah, I need to mask IOCStatus to only get the error code. The patch below
should quiet the warning:
Index: mpt_show.c
===================================================================
--- mpt_show.c (revision 202705)
+++ mpt_show.c (working copy)
@@ -78,6 +78,7 @@
CONFIG_PAGE_MANUFACTURING_0 *man0;
CONFIG_PAGE_IOC_2 *ioc2;
CONFIG_PAGE_IOC_6 *ioc6;
+ U16 IOCStatus;
int fd, comma;
if (ac != 1) {
@@ -108,7 +109,7 @@
free(man0);
- ioc2 = mpt_read_ioc_page(fd, 2, NULL);
+ ioc2 = mpt_read_ioc_page(fd, 2, &IOCStatus);
if (ioc2 != NULL) {
printf(" RAID Levels:");
comma = 0;
@@ -151,9 +152,11 @@
printf(" none");
printf("\n");
free(ioc2);
- }
+ } else if ((IOCStatus & MPI_IOCSTATUS_MASK) !=
+ MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
+ warnx("mpt_read_ioc_page(2): %s", mpt_ioc_status(IOCStatus));
- ioc6 = mpt_read_ioc_page(fd, 6, NULL);
+ ioc6 = mpt_read_ioc_page(fd, 6, &IOCStatus);
if (ioc6 != NULL) {
display_stripe_map(" RAID0 Stripes",
ioc6->SupportedStripeSizeMapIS);
@@ -172,7 +175,9 @@
printf("-%u", ioc6->MaxDrivesIME);
printf("\n");
free(ioc6);
- }
+ } else if ((IOCStatus & MPI_IOCSTATUS_MASK) !=
+ MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
+ warnx("mpt_read_ioc_page(6): %s", mpt_ioc_status(IOCStatus));
/* TODO: Add an ioctl to fetch IOC_FACTS and print firmware version. */
@@ -541,7 +546,8 @@
for (i = 0; i <= 0xff; i++) {
pinfo = mpt_pd_info(fd, i, &IOCStatus);
if (pinfo == NULL) {
- if (IOCStatus != MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
+ if ((IOCStatus & MPI_IOCSTATUS_MASK) !=
+ MPI_IOCSTATUS_CONFIG_INVALID_PAGE)
warnx("mpt_pd_info(%d): %s", i,
mpt_ioc_status(IOCStatus));
continue;
> > I know that the rescan after removing a device is a bit messy (lots of
> > messages before daX actually goes away), but I don't recall it taking such a
> > long time.
>
> Even without rescanning the bus, the device actually goes away on its
> own after the same delay of three minutes.
>
> > The documentation is not public. The 0x12 and 0x16 messages are events that
> > I have seen. You can try talking to scottl@ as he has access to the docs.
>
> I could contact Scott, and here are the relevant bits of his answer :
> > The basic problem is that FreeBSD still sees all of this as parallel SCSI, subject to rescans and resets and timeouts. It's fighting with the SAS controller. I'll explain more below.
>
> > I'm working on code that will make FreeBSD more aware of how SAS works. It's several months from being done, though.
>
> Reposting here for reference the meaning of 0x12 and 0x16 events :
> 0x12 : SAS Link status changed
> 0x16 : SAS Discovery Event
>
> I was wondering if using an Areca SAS controller could be a better
> solution, but Scott's answer has me wondering if this is a common issue
> to all SAS controllers on FreeBSD.
I have no idea, I'd have to defer to Scott in that regard.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001220846.17419.jhb>