On Sat, 12 Jun 2021 14:10:36 +0100
Edward Tomasz Napiera__a wrote:
> On 0610T1150, Gary Jennejohn wrote:
> > On Tue, 8 Jun 2021 17:54:05 +0200
> > Gary Jennejohn 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
