changing kern.bio_transient_maxcnt fixes panic

[Stephen Mcconnell]

> -----Original Message-----
> From: Konstantin Belousov [mailto:kostikbel at gmail.com]
> Sent: Saturday, December 20, 2014 8:56 AM
> To: Stephen Mcconnell
> Cc: freebsd-scsi at freebsd.org; slm at freebsd.org
> Subject: Re: changing kern.bio_transient_maxcnt fixes panic
>
> On Fri, Dec 19, 2014 at 11:16:36AM -0700, Stephen Mcconnell wrote:
> >    changing kern.bio_transient_maxcnt fixes panic
> >
> > Hi Konstantine.  I hope you are the right person to help with this.
> > Or perhaps someone else on the list can help.
> >
> > We (Avago) have a customer who is getting the following panic.  They
> > are using the mrsas (MegaRAID) driver in FreeBSD 10.  In a test, they
> > tried to restore a database backup of 3GB.  After the restore they
> > queried the database and then saw the panic.  They found this link,
> > saying that changing the value of kern.bio_transient_maxcnt should fix
> > the problem.  It did fix the problem, be we would like to know why it
> > helped so that we???re not just putting a band-aid on it.
> >
> > *https://lists.freebsd.org/pipermail/freebsd-stable/2013-October/07557
> > 7.html*
> > <https://lists.freebsd.org/pipermail/freebsd-stable/2013-October/07557
> > 7.html>
> >
> > Also, I found this link with the same type of question.
> >
> > *https://docs.freebsd.org/cgi/getmsg.cgi?fetch=179246+182329+/usr/loca
> > l/www/db/text/2014/freebsd-questions/20141019.freebsd-questions*
> > <https://docs.freebsd.org/cgi/getmsg.cgi?fetch=179246+182329+/usr/loca
> > l/www/db/text/2014/freebsd-questions/20141019.freebsd-questions>
> >
> > Can you explain why changing this value fixes this problem, and what
> > we might need to do in the driver to make a permanent fix?
>
> The tunable controls the size of the KVA area used to map pages of the
bio's
> which are not mapped into KVA, but which are passed to a driver that
requires
> mapped bio's.
>
> The auto-tuning logic was developed with an assumption that the system
load
> consists of the typical UFS-generated I/O. It is possible, for some i/o
pathes. to
> generate more i/o.
>
> Note that the transient mappings are only needed when the driver does
not
> handle unmapped bio's. So the proper fix is to add support for the
unmapped
> i/o, see e.g. mfi(4); the required modifications are relatively simple.
If you driver
> already supports unmapped i/o, then there is something else going on.

Thanks for your help Konstantin.  It looks like we may need to add that
support.