On Mar 7, 2019, Aaro Koskinen <aaro.koski...@iki.fi> wrote: > Hi, > On Thu, Mar 07, 2019 at 03:41:01AM -0300, Alexandre Oliva wrote: >> On Feb 17, 2019, "Maciej W. Rozycki" <ma...@linux-mips.org> wrote: >> >> > 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).
> This is interesting, thanks for the research, but I'm afraid it doesn't seem > to be the root cause. Oh, I didn't mean to offer anything definitive, just to report the findings of my investigation so far, since I had no clue when I'd find another significant time slot to get back onto it. > Could you check your /proc/interrupts counters after the boot with > your change? 16k to 18k interrupts after booting up into multi-user mode, including some idle time (and possibly anacron jobs) in the case that got more interrupts. That's not unlike what I get with 4.19.26-gnu. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
