On Fri, 2007-10-05 at 18:41 +0200, Thomas Gleixner wrote:
quoted text
> On Fri, 5 Oct 2007, Gregory Haskins wrote:
> > This series may help debugging certain circumstances where the serial
> > console is unreponsive (e.g. RT51+ spinner, or scheduler problem).  It =
changes
quoted text
> > the serial8250 driver to use IRQF_NODELAY so that interrupts execute in=
 irq
quoted text
> > context instead of a kthread.
> >=20
> > It works pretty well on this end, though it is admitted not fully baked=
  For
quoted text
> > instance, a few paths in sysrq can still call into non-raw spinlocks
> > (sched_debug_show, for instance) which will cause subsequent errors.  A=
lso,
quoted text
> > if you use KDB, be sure to convert the kdb_printf_lock to raw as well. =
 I may
quoted text
> > send a KDB related patch seperately.
> >=20
> > I am sending this out now in case it is helpful to someone.
>=20
> The simple non-patch solution is to up the priority of the serial=20
> console irq to maximum. That's usually sufficient to catch runnaway tasks=
=20
quoted text
> etc. It does not interfere with the system in normal operation as long as=
=20
quoted text
> you do not hit keys in your minicom.
>=20
> I doubt that your patch has a chance to survive lockdep and anything whic=
h=20
quoted text
> is not a sysrq.

Your point is valid, and I thought of this too.  The one problem with it
is that it is not immune to problems in the scheduler itself (which at
the time, I thought I was chasing..turned out to be lockdep), but that
is probably a rarity.  In any case, we have been using it on a number of
debug systems here for a few weeks and the console continues to work
well in all functions besides sysrq, believe it or not (*).  But I don't
see this as being anything used for real.  Just thought I would throw it
out there in case it was useful or inspired someone to give it some
love.

Regards,
-Greg

(*) The trick is that once it figures out its not for sysrq, it
schedules a (kthread based) tasklet to do the actual tty() callbacks.