MFC r304804:

Less-quick fix for locking fixes in r172250.  r172250 added a second
syscons spinlock for the output routine alone.  It is better to extend
the coverage of the first syscons spinlock added in r162285.  2 locks
might work with complicated juggling, but no juggling was done.  What
the 2 locks actually did was to cover some of the missing locking in
each other and deadlock less often against each other than a single
lock with larger coverage would against itself.  Races are preferable
to deadlocks here, but 2 locks are still worse since they are harder
to understand and fix.

Prefer deadlocks to races and merge the second lock into the first one.

Extend the scope of the spinlocking to all of sc_cnputc() instead of
just the sc_puts() part.  This further prefers deadlocks to races.

Extend the kdb_active hack from sc_puts() internals for the second lock
to all spinlocking.  This reduces deadlocks much more than the other
changes increases them.  The s/p,10* test in ddb gets much further now.
Hide this detail in the SC_VIDEO_LOCK() macro.  Add namespace pollution
in 1 nested #include and reduce namespace pollution in other nested
#includes to pay for this.

Move the first lock higher in the witness order.  The second lock was
unnaturally low and the first lock was unnaturally high.  The second
lock had to be above "sleepq chain" and/or "callout" to avoid spurious
LORs for visual bells in sc_puts().  Other console driver locks are
already even higher (but not adjacent like they should be) except when
they are missing from the table.  Audio bells also benefit from the
syscons lock being high so that audio mutexes have chance of being
lower.  Otherwise, console drviver locks should be as low as possible.
Non-spurious LORs now occur if the bell code calls printf() or is
interrupted (perhaps by an NMI) and the interrupt handler calls
printf().  Previous commits turned off many bells in console i/o but
missed ones done by the teken layer.

0 files changed, 0 insertions, 0 deletions