On Mon, 24 Jun 2019, Hodaszi, Robert wrote: > >> Stared some more into the interrupt code. I think Robert was on the right > >> track, but I did not see the tree in the forest. > >> > >> The scenario he described can actually happen and yes, we should deactivate > >> the interrupt after the synchronize_hardirq() and not before. Tentative fix > >> below. ... > > It significantly decreased appearance of the problem log (at least in my tests), > > But unfortunately, the problem still exists. > > I tried it as well, and unfortunately, the error messages are still > there. I'm seeing, what you're doing, and theoretically it should fix > the problem, but something is still wrong. Let me try to check on my > board, what is happening. The best way to figure out how the timing is of all those moving parts is to enable trace points and selective function tracing. That should give us a good picture. Thanks, tglx
