From: Adrian Bunk <bunk@stusta.de>
To: davidm@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [2.6 patch] IA64 irq.c: remove CONFIG_X86 code
Date: Fri, 19 Nov 2004 00:19:15 +0000 [thread overview]
Message-ID: <20041119001915.GL4943@stusta.de> (raw)
I don't see hos this code could ever be used.
Am I correct or did I miss something?
diffstat output:
arch/ia64/kernel/irq.c | 33 ---------------------------------
1 files changed, 33 deletions(-)
Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
--- linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c.old 2004-11-19 01:14:22.000000000 +0100
+++ linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c 2004-11-19 01:16:31.000000000 +0100
@@ -132,23 +132,7 @@
* each architecture has to answer this themselves, it doesn't deserve
* a generic callback i think.
*/
-#ifdef CONFIG_X86
- printk(KERN_ERR "unexpected IRQ trap at vector %02x\n", irq);
-#ifdef CONFIG_X86_LOCAL_APIC
- /*
- * Currently unexpected vectors happen only on SMP and APIC.
- * We _must_ ack these because every local APIC has only N
- * irq slots per priority level, and a 'hanging, unacked' IRQ
- * holds up an irq slot - in excessive cases (when multiple
- * unexpected vectors occur) that might lock up the APIC
- * completely.
- */
- ack_APIC_irq();
-#endif
-#endif
-#ifdef CONFIG_IA64
printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq, smp_processor_id());
-#endif
}
/* startup is the same as "enable", shutdown is same as "disable" */
@@ -166,11 +150,6 @@
};
atomic_t irq_err_count;
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-atomic_t irq_mis_count;
-#endif
-#endif
/*
* Generic, controller-independent functions:
@@ -220,19 +199,7 @@
if (cpu_online(j))
seq_printf(p, "%10u ", nmi_count(j));
seq_putc(p, '\n');
-#ifdef CONFIG_X86_LOCAL_APIC
- seq_puts(p, "LOC: ");
- for (j = 0; j < NR_CPUS; j++)
- if (cpu_online(j))
- seq_printf(p, "%10u ", irq_stat[j].apic_timer_irqs);
- seq_putc(p, '\n');
-#endif
seq_printf(p, "ERR: %10u\n", atomic_read(&irq_err_count));
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
- seq_printf(p, "MIS: %10u\n", atomic_read(&irq_mis_count));
-#endif
-#endif
}
return 0;
}
WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: davidm@hpl.hp.com
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [2.6 patch] IA64 irq.c: remove CONFIG_X86 code
Date: Fri, 19 Nov 2004 01:19:15 +0100 [thread overview]
Message-ID: <20041119001915.GL4943@stusta.de> (raw)
I don't see hos this code could ever be used.
Am I correct or did I miss something?
diffstat output:
arch/ia64/kernel/irq.c | 33 ---------------------------------
1 files changed, 33 deletions(-)
Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
--- linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c.old 2004-11-19 01:14:22.000000000 +0100
+++ linux-2.6.10-rc2-mm2-full/arch/ia64/kernel/irq.c 2004-11-19 01:16:31.000000000 +0100
@@ -132,23 +132,7 @@
* each architecture has to answer this themselves, it doesn't deserve
* a generic callback i think.
*/
-#ifdef CONFIG_X86
- printk(KERN_ERR "unexpected IRQ trap at vector %02x\n", irq);
-#ifdef CONFIG_X86_LOCAL_APIC
- /*
- * Currently unexpected vectors happen only on SMP and APIC.
- * We _must_ ack these because every local APIC has only N
- * irq slots per priority level, and a 'hanging, unacked' IRQ
- * holds up an irq slot - in excessive cases (when multiple
- * unexpected vectors occur) that might lock up the APIC
- * completely.
- */
- ack_APIC_irq();
-#endif
-#endif
-#ifdef CONFIG_IA64
printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq, smp_processor_id());
-#endif
}
/* startup is the same as "enable", shutdown is same as "disable" */
@@ -166,11 +150,6 @@
};
atomic_t irq_err_count;
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
-atomic_t irq_mis_count;
-#endif
-#endif
/*
* Generic, controller-independent functions:
@@ -220,19 +199,7 @@
if (cpu_online(j))
seq_printf(p, "%10u ", nmi_count(j));
seq_putc(p, '\n');
-#ifdef CONFIG_X86_LOCAL_APIC
- seq_puts(p, "LOC: ");
- for (j = 0; j < NR_CPUS; j++)
- if (cpu_online(j))
- seq_printf(p, "%10u ", irq_stat[j].apic_timer_irqs);
- seq_putc(p, '\n');
-#endif
seq_printf(p, "ERR: %10u\n", atomic_read(&irq_err_count));
-#ifdef CONFIG_X86_IO_APIC
-#ifdef APIC_MISMATCH_DEBUG
- seq_printf(p, "MIS: %10u\n", atomic_read(&irq_mis_count));
-#endif
-#endif
}
return 0;
}
next reply other threads:[~2004-11-19 0:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-19 0:19 Adrian Bunk [this message]
2004-11-19 0:19 ` [2.6 patch] IA64 irq.c: remove CONFIG_X86 code Adrian Bunk
2004-11-19 6:42 ` Luck, Tony
2004-11-19 6:42 ` Luck, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041119001915.GL4943@stusta.de \
--to=bunk@stusta.de \
--cc=davidm@hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.