The reason behind it is that irqbalance parses the /proc/interrupts
and whenever it hits something it can't understand:
RES: 191614137 73904910 Rescheduling interrupts
It will count the number of interrupts towards the IRQ 0. That IRQ does exist
when the kernel boots under baremetal:
0: 46 0 IO-APIC-edge timer
but under Xen, the timer interrupts are initialized much later:
272: 41197188 0 xen-percpu-virq timer0
and the first IRQ that is used is not zero, but rather one:
1: 73037 0 0 0 0 0
xen-pirq-ioapic-edge i8042
so when irqbalance tries to account for the IRQ 'RES' to the IRQ 0
it fails and segfaults. The attached patch fixes it for whoever else is
hitting this problem. I am not sure who the upstream maintainer is for this so
I am sending this patch to the different distros as well.
--- irqbalance-0.56.orig/procinterrupts.c 2010-06-10 10:45:55.000000000
-0400
+++ irqbalance-0.56/procinterrupts.c 2011-05-10 20:22:06.897465003 -0400
@@ -50,7 +50,7 @@ void parse_proc_interrupts(void)
int cpunr;
int number;
uint64_t count;
- char *c, *c2;
+ char *c, *c2, *err;
if (getline(&line, &size, file)==0)
break;
@@ -64,7 +64,11 @@ void parse_proc_interrupts(void)
continue;
*c = 0;
c++;
- number = strtoul(line, NULL, 10);
+ number = strtoul(line, &err, 10);
+ /* Man page says that if that happens and number == 0, then it
+ * failed to parse. */
+ if (err == line && number == 0)
+ continue;
count = 0;
cpunr = 0;
irqbalance.patch
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|