Hi Alexandre, I'm away on holiday and also connectivity is so-so here, so just a quick reply.
> > Is there an MMIO completion barrier missing there somewhere by any chance > > causing an IRQ that has been handled already to be redelivered because an > > MMIO write meant to clear the IRQ at its origin at handler's completion > > has not reached its destination before interrupts have been reenabled in > > the issuing CPU? Just a thought. > > I've finally got a chance to bisect the IRQ14 (nobody cared) regression > on my yeeloong. It took me to MIPS: Enforce strong ordering for MMIO > accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f). Thanks for looking into it. > I've only just started trying to figure out what exactly in the change > leads to problems. So far, I've determined that changing both uses of > __BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1 > removes the undesirable effects, both on top of that patch, and on top > of v5.0: > > #define __BUILD_IOPORT_PFX(bus, bwlq, type) \ > - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \ > - __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p) > + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,) \ > + __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p) So this seems backwards to me, port I/O is supposed to be strongly ordered, so if removing the ordering guarantee "fixes" your problem, then there must be a second bottom here. Offhand either there is a race condition somewhere which the lack of ordering here covers somehow, or there is a silicon erratum of some sort somewhere that the SYNC instruction triggers. A further investigation is required I'm afraid. Does your platform use `war_io_reorder_wmb'? Maciej
