Avoid grabbing locks when grabbing the vt(4) console for DDB.

[jhb]

Summary

Trying to grab locks during cngrab() when entering the debugger is
deadlock prone as all other CPUs are already halted (and thus unable
to release locks) when cngrab() is invoked. One could instead use
try-locks. However, the case that the try-lock fails still has to
be handled. In addition, if the try-lock works it doesn't provide
any greater ordering guarantees than is already provided by entering
and exiting DDB. It is simpler to define a simpler path for the
case that the try-lock would fail and always use that when entering
DDB. Messing with timers, etc. when entering DDB is dubious even if
the try-lock succeeds.

This patch attempts to use the smallest possible set of operations to
grab the vt(4) console when entering DDB without using any locks.

Test Plan

• tested by Matt Macy on a panic that always hung in VT_LOCK in cngrab() previously

[kmacy]

Just a "works for me." I haven't had time to dig in to what's holding the lock, but the inability to enter ddb consistently when not entering by way of a proper panic has been a serious issue for me for at least the past 6 months. I don't know what others are doing to never see this.

[emaste]

LGTM

sys/dev/vt/vt_core.c

544–547

This existing path seems somewhat dubious

[jhb]

sys/dev/vt/vt_core.c

544–547

I think a cngrab() when the console is already ttyv0 isn't that rare. :) That said, I think the only place this would now get used is during a clean shutdown and I think the existing path with locking is fine for that?

[emaste]

sys/dev/vt/vt_core.c

544–547

I don't think the existing lock will cause a problem, but am unsure exactly what it's accomplishing.

[kmacy]

Update: Although it works fine with SOL through ipmitool, iKVM/HTML5 does _not_ work once it drops you to the db> prompt
Please pull in the keyboard bits as well.