Re: [PATCH 2/2] apic: Add print error interrupt reason

From: Jason Baron
Date: Thu Jan 06 2011 - 17:13:30 EST


On Wed, Jan 05, 2011 at 08:34:51PM -0800, Joe Perches wrote:
> On Thu, 2011-01-06 at 11:28 +0800, Youquan Song wrote:
> > End user worry about the error interrupt information and intend to know what
> > kind of error interrupts are generated, so this patch add printing out the
> > detail debug information of error interrupt.
> >
> > Signed-off-by: Youquan Song <youquan.song@xxxxxxxxx>
> > ---
> > arch/x86/kernel/apic/apic.c | 28 +++++++++++++++++++++++++++-
> > 1 files changed, 27 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> []
> > +static const char *error_interrupt_reason[] = {
>
> static const char * const etc[]
>
> > + "Send CS error",
> > + "Receive CS error",
> > + "Send accept error",
> > + "Receive accept error",
> > + "Redirectable IPI",
> > + "Send illegal vector",
> > + "Received illegal vector",
> > + "Illegal register address",
> > +};
> > +
> > +static void print_error_interrupt_reason(u32 reason)
> > +{
> > + u32 i = 0;
> > + reason = reason & 0xff;
> > + do {
> > + if (reason & 0x1)
> > + pr_debug(" : %s", error_interrupt_reason[i]);
>
> This isn't correct as it will emit <7> for each reason.
>
> You want pr_cont surrounded by #ifdef DEBUG
> or some new #define pr_debug_cont in printk.h
> but that won't play well with dynamic_debug.
>
> Jason? Got a cure for this?
>
>

hmmm...right, we could introduce a pr_debug_cont(), but I think it would
be complex to implement, since we would have to pass a reference to
where we are continued from...the #ifdef DEBUG isn't great either, since
we need this for every pr_debug() statement which might be followed by a
pr_cont()...

perhaps, the simplest thing is just to code this explicitly as:
printk(KERN_DEBUG, blah), followed by the regular pr_cont()?

thanks,

-Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/