Messages in this thread | | | Date | Thu, 7 Mar 2019 17:59:42 +0000 (GMT) | From | "Maciej W. Rozycki" <> | Subject | Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers |
| |
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
| |