Hello Steven, > Remy, sorry about this round-a-bout. But I don't have any of the hardware > that this affects, and I'm just being cautious. No problem, I expected this discussion when I submitted the patch. It is logical that everybody is cautious on this subject. But still, there is a bug here. The question is how to figure out the best solution. (with the least chance of regression). I do not think Russell is right here with assuming that the wrong interrupt handler type is used. Looking at the behaviour of the mainline kernel (non-RT), the implementation is quite different: On mainline the handle_simple_irq() in chip.c is not re-entrant, the masking is **only** done in case of errors, and therefor never unmasked again, of course. On RT the masking is done when the next interrupt arrives, while the 1st interrupt is in progress by the interrupt thread, so it is masked under normal valid conditions, and never unmasked. So, this is where the real bug is. So, I see 2 solutions: * Never mask the interrupt in the first place. (should also work for this type of interrupt) * Add an unmask to the interrupt, once it is handled. (I chose this route with my patch) It is definitely only related to interrupt threading, and thus only RT related. Kind Regards, Remy - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
