changing kern.bio_transient_maxcnt fixes panic
Konstantin Belousov
kostikbel at gmail.com
Sat Dec 20 15:56:26 UTC 2014
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/075577.html*
> <https://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075577.html>
>
> Also, I found this link with the same type of question.
>
> *https://docs.freebsd.org/cgi/getmsg.cgi?fetch=179246+182329+/usr/local/www/db/text/2014/freebsd-questions/20141019.freebsd-questions*
> <https://docs.freebsd.org/cgi/getmsg.cgi?fetch=179246+182329+/usr/local/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.
More information about the freebsd-scsi
mailing list