> Obviously I'm guessing just as much as you are. > I would first check to see if the interrupt fired at all in the case > where the timeout occurred. The completion only fires if we have > a flag set in the status register. Add an else to that block see > if we get interrupts where it isn't set. For example if we are > getting spurious interrupts from somewhere occasionally we might > get a race in there as it clears all the irq sources, not just the > ones we have actually handled (which is dubious as there is defintely > a race in there if any of the others are firing). > You could cynically add a spinning loop of some type to waste time > in that race period and see if you can open the window up to replicate > on your system. > I don't have one of these, but perhaps try on your 'good' system > with just clearing the SR_E0Q interrupt and it may give us some insight > into why the others are being cleared. > Note that if we don't find an expected interrupt (and there isn't > a weird hardware bug that needs working around) then we should > return IRQ_NONE to let the kernel spurious interrupt handling kick > in correctly. > Otherwise, I would indeed look at the interrupt controller driver. > Might be something dubious in there. Of course the RTC error > could be something entirely different. > Of course the usual issues of power brownout and similar might > also be going on. The delights of systems at customers working > differently than the ones you have! > Jonathan Hey Jonathan, thanks for your reply and your guesses, too. I will try some changes and maybe come back again. Like it wrote before it could take 2 months. I thought maybe somebody else could have the same problem or better I hoped somebody had the same problem and a solution for me. But I know that this hardware is really rare. Benjamin
