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

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.

> > > 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.  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