Date: Mon, 22 Dec 2014 11:06:14 -0700 From: Stephen Mcconnell <stephen.mcconnell@avagotech.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: RE: changing kern.bio_transient_maxcnt fixes panic Message-ID: <10ae75e487522c53d4bf5da0545fd755@mail.gmail.com> In-Reply-To: <20141220155615.GT2148@kib.kiev.ua> References: <ceed8e57113129c0425c649b457afb89@mail.gmail.com> <20141220155615.GT2148@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > Sent: Saturday, December 20, 2014 8:56 AM > To: Stephen Mcconnell > Cc: freebsd-scsi@freebsd.org; slm@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10ae75e487522c53d4bf5da0545fd755>