Re: kernel panic while copying files

On Sat, 12 Jun 2021 14:10:36 +0100
Edward Tomasz Napiera__a <trasz@freebsd.org> wrote:

> On 0610T1150, Gary Jennejohn wrote:
> > On Tue, 8 Jun 2021 17:54:05 +0200
> > Gary Jennejohn <gljennjohn@gmail.com> wrote:
> > 
> > [big snip]  
> 
> [..]
> 
> > So, I did ``git reset --hard 8dc96b74edb844bb621afeba38fe4af104b13120'',
> > which was the penultimate commit made by trasz to clear CCBs on the stack
> > after he committed 3394d4239b85b5577845d9e6de4e97b18d3dba58, the change
> > to allocate CCBs in UMA.
> > 
> > Note that I only built the kernel and not world.
> > 
> > I tried to reset to 3394d4239b85b5577845d9e6de4e97b18d3dba58 itself,
> > but without the following commits for CCBs on the stack the kernel
> > paniced during startup in AHCI.
> > 
> > Anyway, this is the minimum set of changes relevant to the uma_ccbs
> > story and also results in a panic identical to the one listed above
> > when I set kern.cam.da.enable_uma_ccbs=1 and turn on the external USB
> > disk.
> > 
> > So, Warner is probably right and at least the da_uma_ccbs commits
> > should be reverted until more research can be done on why the panic
> > happens.
> > 
> > The ada_uma_ccbs commits do not cause any problems in my experience and
> > could probably be left in the kernel.  
> 
> Thank you, I'm working on a fix.  Meanwhile - does the current code
> cause any problems with set kern.cam.da.enable_uma_ccbs set to 0?
> If it doesn't, it probably doesn't require backing off, since 0 is
> the default, and will keep being the default until bugs such as this
> one are fixed.
> 

No, with the sysctl set to 0 it works really well.  I've been running
it that way for several days and have transferred large amounts of
data to an external USB3 disk with no problems.

I didn't mention it, but I also tested the reset kernel (with INVARIANTS)
with the sysctl set to 0 and the kernel did not panic.

I've had ada_enable_uma_ccbs set to 1 the whole time and never saw any
problems.

I agree, as long as the default is 0 all the code can stay in the tree.

-- 
Gary Jennejohn