From: Thomas Falcon <tlfal...@linux.vnet.ibm.com> Date: Thu, 26 Jan 2017 10:44:22 -0600
> On 01/25/2017 10:04 PM, David Miller wrote: >> From: Thomas Falcon <tlfal...@linux.vnet.ibm.com> >> Date: Wed, 25 Jan 2017 15:02:19 -0600 >> >>> Move most interrupt handler processing into a tasklet, and >>> introduce a delay after re-enabling interrupts to fix timing >>> issues encountered in hardware testing. >>> >>> Signed-off-by: Thomas Falcon <tlfal...@linux.vnet.ibm.com> >> I don't think you have any idea what the real problem is. This looks >> like a hack, at best. Next patch you'll increase the delay to "20", >> right? And if that doesn't work you'll try "40". >> >> Or if you do know the reason, you need to explain it in detail in this >> commit message so that we can properly evaluate this patch. > > You're right, I should have given more explanation in the commit message > about the bug encountered and our reasons for this sort of fix. The issue is > that there are some scenarios during the device init where multiple messages > are sent by firmware in one interrupt request. > > We have observed behavior where messages are delayed, resulting in the > interrupt handler completing before the delayed messages can be processed, > fouling up the device bring-up in the device probing and elsewhere. The goal > of the delay is to buy some time for the hypervisor to forward all the CRQ > messages from the firmware. Then isn't there an event you can sleep and wait for, or a piece of state for you to poll and test for in a timeout based loop? This delay is a bad solution for the problem of waiting for A to happen before you do B.
