tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "adapter resource shortage"?



> I believe you're getting an XS_RESOURCE_SHORTAGE status sent back to
> you from the driver at the scsipi layer.  [...]

I found three places XS_RESOURCE_SHORTAGE could be returned in
mpt_netbsd.c.  Two of them were in switches where the code was attached
to two different switch values (eg, in one switch, MPI_IOCSTATUS_BUSY
and MPI_IOCSTATUS_INSUFFICIENT_RESOURCES were treated identically.)  I
broke these out, printing a distinct message in each of the resulting
five cases.

I then deliberately provoked the kind of case where I saw the "adapter
resource shortage" messages before, by mounting a scratch filesystem
async and dumping data to it faster than the disk could handle.

It appears the basis for the messages is always mpt_get_request
failing, in mpt_run_xfer.  "This should happen very infrequently", the
comment there says; this doesn't look infrequent to me. :-)

I then tried setting adapt_openings and adapt_max_periph three lower:

@@ -107,13 +107,14 @@ mpt_scsipi_attach(mpt_softc_t *mpt)
 
        maxq = (mpt->mpt_global_credits < MPT_MAX_REQUESTS(mpt)) ?
            mpt->mpt_global_credits : MPT_MAX_REQUESTS(mpt);
+       if (maxq > 5) maxq -= 5; else maxq = 1;
 
        /* Fill in the scsipi_adapter. */
        memset(adapt, 0, sizeof(*adapt));
        adapt->adapt_dev = &mpt->sc_dev;
        adapt->adapt_nchannels = 1;
-       adapt->adapt_openings = maxq - 2;       /* Reserve 2 for driver use*/
-       adapt->adapt_max_periph = maxq - 2;
+       adapt->adapt_openings = maxq;
+       adapt->adapt_max_periph = maxq;
        adapt->adapt_request = mpt_scsipi_request;
        adapt->adapt_minphys = mpt_minphys;
 

With this change, I have been unable to provoke the "adapter resource
shortage" message even once, despite having no trouble doing so before.
An additional printf, not shown above, indicates that the value now
being used for adapt_openings and adapt_max_periph is 251.

I hope this is helpful information for you; it certainly is helpful to
me, in that I now have a system that doesn't cut disk throughput by a
factor of two to three - and babble on the console - in the presence of
a flood of writes.

Thank you, people, for pointing me in such helpful directions!

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index