I have never seen these messages. I will check them.
This seems to be an intermittent problem. I just got my serial console
working again to get you a full stack trace, and the first time I booted the
kernel with your vector domain patch it didn't crash.
Second boot did crash. Here's the
This seems to be an intermittent problem.
One more note on that ... my test system often kicks out some
Unexpected irq vector 0x13 on CPU xx!
messages as it boots. Looking at the logs of previous boots, I see between
zero and two such messages in the last few dozen boots, When the
kernel
Hi Tony,
Luck, Tony wrote:
Here is a series of patches for ia64 vector domain. By these patches, we can
use more than 256 irqs. The patchset is based on existing x86-64 vector
domain
code. This is for 2.6.22-rc5 and I tested them on my ia64 box.
There are a few whitespace issues
Luck, Tony wrote:
include/asm/hardirq.h:30:3: #error HARDIRQ_BITS is too low!
This one is a direct consequence of the new definition of NR_IRQS:
#define NR_IRQS (NR_VECTORS + 32 * NR_CPUS))
With a large NR_CPUS value, this gets too big. Do we really need to scale
it with the number of
Here is a series of patches for ia64 vector domain. By these patches, we can
use more than 256 irqs. The patchset is based on existing x86-64 vector domain
code. This is for 2.6.22-rc5 and I tested them on my ia64 box.
There are a few whitespace issues (spacetab) amongst these patches (I think
arch/ia64/kernel/irq_ia64.c: In function `parse_vector_domain':
arch/ia64/kernel/irq_ia64.c:270: error: `no_int_routing' undeclared (first
use in this function)
Fix for this is just:
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index 8efb6e1..91abd1b 100644
---
include/asm/hardirq.h:30:3: #error HARDIRQ_BITS is too low!
This one is a direct consequence of the new definition of NR_IRQS:
#define NR_IRQS (NR_VECTORS + 32 * NR_CPUS))
With a large NR_CPUS value, this gets too big. Do we really need to scale
it with the number of cpus? I don't think this
