[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1191853361.4281.5.camel@ghaskins-t60p.haskins.net>
Date: Mon, 08 Oct 2007 10:22:41 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, mingo@...e.hu,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] [RFC] RT: Optionally allow IRQF_NODELAY on serial
console
On Mon, 2007-10-08 at 10:10 -0400, Steven Rostedt wrote:
> This issue has hit me enough times where I've played with a few other
> ideas. I just haven't had the time to finish them. The main problem is if
> the system locks up somewhere we have a lock held that keeps us from
> scheduling. Once that happens in -rt, we are as good as dead. Since you
> can't get much info out without a JTAG or some other mechanism.
>
> One thought I had was to create a small handler that could read the serial
> and place data into a buffer. This handler would be a IRQ_NODELAY, and it
> would wake up a serial thread to handle the data just like it would for
> normal serial output. But the serial thread would just read from the
> buffer instead of the serial itself. In the case of a sysrq key coming
> in, the IRQ_NODELAY handler would handle it.
>
Hi Steve,
What you describe is exactly what I did. The IRQF_NODELAY handler
just minimally checks to see if the character is a sysrq related one (or
KDB, if you have the KDB patches applied). If it is not, it puts the
character into a ring-buffer and wakes a (kthread-based) tasklet to do
the normal serial/tty rx path by processing the ring.
Hope that helps to clarify.
Regards,
-Greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists