Date: Mon, 5 Jul 2021 18:33:24 +0200 From: Gary Jennejohn <gljennjohn@gmail.com> To: Edward Tomasz =?ISO-8859-1?Q?Napiera=3Fa?= <trasz@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: panic: Unaligned free (was: kernel panic while copying files) Message-ID: <20210705163324.29466849@ernst.home> In-Reply-To: <YOMRgHbqndqTcZrU@brick> References: <20210608084646.6a7e1bc7@ernst.home> <CANCZdfpODXLP9B%2BAAXSd5dTS4-V_9r%2BEg90z7sz18wTaE8ELZA@mail.gmail.com> <20210608155405.5cf0e200@ernst.home> <20210610095041.38d7597c@ernst.home> <20210629094201.77ef5f22@ernst.home> <cf5067d4-73c5-2885-7526-8917182ed2a3@gmail.com> <20210630125703.2b5544e7@ernst.home> <CANCZdfooeOmTu2cGN3K5DeaW0hfLTW66hzuJmHdzCVp98bWwLQ@mail.gmail.com> <20210701035800.410d2376@ernst.home> <20210701113026.59f864e9@ernst.home> <YOMRgHbqndqTcZrU@brick>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jul 2021 15:04:48 +0100 Edward Tomasz Napiera__a <trasz@freebsd.org> wrote: > On 0701T1330, Gary Jennejohn wrote: > > Gary Jennejohn <gljennjohn@gmail.com> wrote: > > > I noticed that the value of vm.debug.divisor affects what value is > > > returned in uma_core.c:uma_dbg_kskip(), so I decided to try a few > > > different values. > > > > > > The returned value is used to set skipdbg in uma_core.c:item_dtor(). > > > > > > The default is vm.debug.divisor=1. > > > > > > vm.debug.divisor is only present when INVARIANTS is defined. > > > > > > kskipdbg eventually affects the value of freei. > > > > > > With these values: > > > vm.debug.divisor: 0 > > > kern.cam.da.enable_uma_ccbs: 1 > > > I can turn on the disk and it comes up without a panic! > > > > > > However, I didn't try to do any large data transfers to the disk. > > > > > > So, it appears that at least vm.debug.divisor is a big factor in > > > whether or not a panic happens with INVARIANTS. > > > > > > > I decided to do a real test. So I built a kernel w/o INVARIANTS and > > installed it to /boot/test. > > > > Then I stuck a 160GB disk I had around into an external USB3 enclosure > > and put a filesystem on it. > > > > The I booted the new kernel from /boot/test and set the sysctls so: > > kern.cam.da.enable_uma_ccbs: 1 > > kern.cam.ada.enable_uma_ccbs: 1 > > > > After that I plugged in the external USB3 enclosure and copied about > > 114GiB of data from an internal SSD to it - without a kernel panic: > > Filesystem Size Used Avail Capacity Mounted on > > /dev/da0p1 144G 114G 18G 86% /mnt > > > > I'm pretty sure that's more than I could copy without a kernel panic > > prior to the recent changes made in cam and umass. > > > > My test may not be real proof that all bugs have been squashed, but it > > certainly seems to be a better situation than we had before. > > I think the vm.debug.divisor simply masks the problem; the underlying > bug is still there. > > Could you go back to the setup which panics, and then test the patch > at https://reviews.freebsd.org/D31054? It fixes the scenario described > by Warner. > It looks like this patch fixes things. I used the default value vm.debug.divisor=1 and both enable_uma_ccbs=1 (which are now the default values on my system). I used the 8TiB disk, which spins up very slowly and usually resulted very quickly in a panic - no panic with the patch. Then using dd to /dev/null (bs=1m) I transferred: 308755+0 records in 308755+0 records out 323753082880 bytes transferred in 1366.162410 secs (236979938 bytes/sec) from the disk, so about 324GiB without a panic. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210705163324.29466849>