While not trying to malign anybody, I am curious to learn if it is possible that the AUX_NIRQ interrupt on the balloon3 board has never been adequately tested. I ask because some of the code I see in arch/arm/mach-pxa/balloon3.c looks just plain wrong, and because, right or wrong (I haven't even gotten to that code yet), I can't seem to get my FPGA to generate an interrupt that is serviced by my kernel. I will debug this problem differently depending on whether I should assume that the code is known to work than I would if I don't have that up front knowledge. The questionable code looks like: static void balloon3_irq_handler(unsigned int irq, struct irq_desc *desc) { unsigned long pending = __raw_readl(BALLOON3_INT_CONTROL_REG) & balloon3_irq_enabled; do { /* clear useless edge notification */ if (desc->chip->ack) desc->chip->ack(BALLOON3_AUX_NIRQ); while (pending) { irq = BALLOON3_IRQ(0) + __ffs(pending); generic_handle_irq(irq); pending &= pending - 1; } pending = __raw_readl(BALLOON3_INT_CONTROL_REG) & balloon3_irq_enabled; } while (pending); } The part that confuses me however is the line that reads: pending &= pending - 1; Shouldn't that be more like: pending &= ~(1 << (irq - BALLOON3_IRQ(0))) (I wouldn't do it exactly that way, but I'm just trying to make a point here). Feel free to tell me the code works fine in millions of applications worldwide, and I'll continue down the path of assuming balloon3.c is correct and my code is wrong. If I don't hear from anybody, I'm going to start assuming that balloon3.c is questionable, fix things the way I think they should be fixed, and submit a patch to the list. Oh yeah, for purely hysterical reasons, I'm working with the 2.6.37.6 kernel from the stock balloonboard tree, if that makes any difference. --wpd