Messages in this thread | | | Date | Wed, 12 May 2004 11:50:26 -0700 (PDT) | From | Dmitry Torokhov <> | Subject | RE: Why pass pt_regs throughout the input system? |
| |
Hi David,
First off sorry for breaking the thread but I am insteresed in the topic and writing this mail via a web-based interface.
> On Wed, 12 May 2004 10:40:56 +0200 > Vojtech Pavlik <vojtech@suse.cz> wrote: > > > Ask David S. Miller for details - I think the problem was with > > simultaneous invocation of multiple pt_regs printouts. > > That's correct, if i'm using multiple keyboards (say one i8042 based > and one USB based) in order to get fancy debugging dumps, any scheme > that saves away info at interrupt time simply will be inaccurate and > not work.
I understand that but is the keyboard interrupt data is the most interesting? I thought that the "middle" part of the call trace is much more important as it shows what is happening to the system. Or am I missing something?
As far as multiple keyboards issue going - SysRq is a debug tool and I relly do not see you hitting SysRq on the two keyboards at the very same time to mess up the call traces.
Anyway, my "problem" is the following: SysRq register dump and call trace require keyboard.c event handler to be caled from hard interrupt context which is not always feasible. If it is called from a tasklet even if I save registers I will not be able to reconstruct the call trace. I wonder if the following change is acceptable:
- SysRq posts a request for registers and call trace to be printed - When next interrupt comes in (any interrupt) do_IRQ will check the flag and print registes and the trace. The check can be made pretty cheap as we can coarsely check if it is set without any locks and only if it is set do the fine-grained locking stuff so it processed only one. If we miss the flag in one interrupt it is not a big deal as it will be noticed when the next interrupt arrives.
This is assuming that we are actually interested in what system was doing _besides_ processing keyboard interrupt.
Dmitry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |