Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On Tue, 14 Dec 2021 07:11:28 +0000
Alexey Dokuchaev <danfe@freebsd.org> wrote:

> On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote:
> > On Mon, 13 Dec 2021 17:01:43 +0000 Alexey Dokuchaev wrote:
> > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote:
> > > > ...
> > > > However, it was a bit harder to see this originally as the 915kms driver
> > > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which
> > > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a
> > > > bad idea).
> > > 
> > > Funny how these new Linuxish DRM bits could affect so many things. :(
> > 
> > What is this comment about exactly?
> 
> Oh, you know, it's about steadily deteriorating quality of our gfx stack
> once we had started pulling things from Linux.

 Right.
 That just proves that you know nothing and will just complain on
everything "new".

 We've *always* pulled drm bits from Linux, always.
 What changed is that instead of, say, replacing all calls to kmalloc
in the drm sources to our malloc we have stubs in linuxkpi. And this
helped a lot, not patching the upstream sources helps us updating drm
much faster.
 Now for John's case, this is very edge case. The panic happened in a
critical section, which put us in a problematic state. I think that
Linux can malloc almost all the time and we can't. Even if we had done
drm porting "the old way" we will had the same problem. Getting the
framebuffer working on a panic works today, unless this kind of stuff
happens and I don't think that we can fix that (at least easily).

> > > > The fact that that sysbeep is off so I couldn't tell if typing in commands
> > > > was doing anything vs emitting errors probably didn't improve trying to
> > > > diagnose the hang as "sitting in ddb" initially, though I don't know if
> > > > DDB itself emits a beep for invalid commands, etc.
> > > 
> > > Now that Warner had fixed the beeper frequency, why we still didn't enable
> > > it back on by default?
> > 
> > Because all people who wanted it off wasn't because it wasn't the
> > right vt100 frequency, they just wanted it off.
> 
> In FreeBSD chat and with less biased poll than the one Warner had posted
> on Twitter, most people had actually voted against making it off by
> default: https://t.me/FreeBSD1/25129.  

 So nothing changes then ?

> If John's assumption that muting
> it pessimizes debugging is correct, it really leaves no strong reasons
> NOT to turn it back on by default.
> 
> ./danfe

 I wouldn't be opposed to enable the beep when we drop to ddb.
 It's already annoying to panic so adding annoying beep that *could*
help in some edge cases isn't the end of the world.

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>