as it still tries to handle the error code as
a real interrupt.
Handle this particular case and warn on spurious interrupts.
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20201005140217.1390851-1-...@kernel.org
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
---
drivers
> >> >> > The pca953x driver never checks the result of irq_find_mapping(),
> >> >> >> > which returns 0 when no mapping is found. When a spurious interrupt
> >> >> >> > is delivered (which can happen under obscure circumstances),
nterrupt
>> >> > is delivered (which can happen under obscure circumstances), the
>> >> > kernel explodes as it still tries to handle the error code as
>> >> > a real interrupt.
>> >> >
>> >> > Handle this particular case
rupt
> >> >> > is delivered (which can happen under obscure circumstances), the
> >> >> > kernel explodes as it still tries to handle the error code as
> >> >> > a real interrupt.
> >> >> >
> >> >> >
gt;> > a real interrupt.
>> >
>> > Handle this particular case and warn on spurious interrupts.
>> >
>> > Signed-off-by: Marc Zyngier
>
> Wait, doesn't actually [1] fix the reported issue?
Not at all.
> Marc, can you confirm this?
>
r never checks the result of irq_find_mapping(),
> >> > which returns 0 when no mapping is found. When a spurious interrupt
> >> > is delivered (which can happen under obscure circumstances), the
> >> > kernel explodes as it still tries to handle the error code as
> &
t
> is delivered (which can happen under obscure circumstances), the
> kernel explodes as it still tries to handle the error code as
> a real interrupt.
>
> Handle this particular case and warn on spurious interrupts.
>
> Signed-off-by: Marc Zyngier
Wait, doesn't actu
red (which can happen under obscure circumstances), the
> > kernel explodes as it still tries to handle the error code as
> > a real interrupt.
> >
> > Handle this particular case and warn on spurious interrupts.
> >
> > Signed-off-by: Marc Zyngier
Wait, doesn
ill tries to handle the error code as
> a real interrupt.
>
> Handle this particular case and warn on spurious interrupts.
>
> Signed-off-by: Marc Zyngier
Patch applied for fixes.
Yours,
Linus Walleij
particular case and warn on spurious interrupts.
Signed-off-by: Marc Zyngier
---
drivers/gpio/gpio-pca953x.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index fb61f2fc6ed7..c2d6121c48c9 100644
--- a
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
function to do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
Signed-off-by: Sasha Levin
0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
> function to do after service update got lost, which caused spurious
> interrupts.
>
> Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
> Signed-off-by: Thomas Bogendoerfer
> -
o do after service update got lost, which caused spurious
interrupts.
Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
Signed-off-by: Thomas Bogendoerfer
---
arch/mips/sni/a20r.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/mips/sni/a2
On Fri, 4 Oct 2019 at 15:45, Nicolas Saenz Julienne
wrote:
>
> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
> after multiblock reads even when ACMD12 is disabled. This triggers
> spurious interrupts after the data transfer is done with the following
> mess
The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
after multiblock reads even when ACMD12 is disabled. This triggers
spurious interrupts after the data transfer is done with the following
message:
mmc1: Got data interrupt 0x0002 even though no data operation was in
Am 04.10.19 um 14:59 schrieb Nicolas Saenz Julienne:
> On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote:
>> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
>> after multiblock reads even when ACMD12 is disabled. This triggers
>> spurious
On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote:
> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
> after multiblock reads even when ACMD12 is disabled. This triggers
> spurious interrupts after the data transfer is done with the following
The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
after multiblock reads even when ACMD12 is disabled. This triggers
spurious interrupts after the data transfer is done with the following
message:
mmc1: Got data interrupt 0x0002 even though no data operation was in
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen in case HW trigge
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen in case HW trigge
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen in case HW trigge
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
From: Maya Erez
[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ]
Interrupt is set in ICM (ICR & ~IMV) rising trigger.
As the driver masks the IRQ after clearing it, there can
be a race where an additional spurious interrupt is triggered
when the driver unmask the IRQ.
This can happen
3.16.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It tur
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It tur
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It turn
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It turn
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It tur
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It tur
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Shtylyov
commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It tur
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Osipenko
[ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ]
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't handl
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Osipenko
[ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ]
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't hand
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Osipenko
[ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ]
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't handl
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Osipenko
[ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ]
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't hand
on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias
Signed-off-by: Thomas Gleixner
on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias
Signed-off-by: Thomas Gleixner
check for spurious interrupts
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged
When the interrupts for a combiner span multiple registers we need
to check if any interrupts have been asserted on each register
before checking for spurious interrupts.
Signed-off-by: Agustin Vega-Frias
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Mon, Apr 09, 2018 at 10:28:27PM +0300, Dmitry Osipenko wrote:
> The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
> mask to the interrupt status and don't handle interrupts that MC driver
> haven't asked for. Kernel would disable spurious MC IRQ and report the
> error. This
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't handle interrupts that MC driver
haven't asked for. Kernel would disable spurious MC IRQ and report the
error. This would happen only in a case of a very severe bug.
Signed-off-by: Dmitry
Do not handle interrupts if we haven't asked for them, potentially that
could happen if HW wasn't programmed properly.
Signed-off-by: Dmitry Osipenko
---
drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/tegra-vde/tegra-vde.c
The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
mask to the interrupt status and don't handle interrupts that MC driver
haven't asked for. Kernel would disable spurious MC IRQ and report the
error. This would happen only in a case of a very severe bug.
Signed-off-by: Dmitry
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: David Kozub
commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream.
The interrupt handler mfgpt_tick() is not robust versus spurious interrupts
which happen before the clock event device is
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: David Kozub
commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream.
The interrupt handler mfgpt_tick() is not robust versus spurious interrupts
which happen before the clock event device is
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: David Kozub
commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream.
The interrupt handler mfgpt_tick() is not robust versus spurious interrupts
which happen before the clock event device is
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
On 20/10/2017 09:49, David Kozub wrote:
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
On 20/10/2017 00:25, Thomas Gleixner wrote:
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
On 19/10/2017 22:57, David Kozub wrote:
This solves a BUG on ALIX 2c3 where
/cs5535: Improve resilience to spurious interrupts
The interrupt handler mfgpt_tick() is not robust versus spurious interrupts
which happen before the clock event device is registered and fully
initialized.
The reason is that the safe guard against spurious interrupts solely checks
for the
On 20/10/2017 11:40, Thomas Gleixner wrote:
> On Fri, 20 Oct 2017, Daniel Lezcano wrote:
>> On 20/10/2017 09:49, David Kozub wrote:
>>
>> And it ends up to the bad commit (assuming there are no compilation
>> broken patches in the process).
>
> I don't think it's worth the trouble for this particu
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
> On 20/10/2017 09:49, David Kozub wrote:
>
> And it ends up to the bad commit (assuming there are no compilation
> broken patches in the process).
I don't think it's worth the trouble for this particular issue. We already
know that the commit which made
On 20/10/2017 09:49, David Kozub wrote:
> On Fri, 20 Oct 2017, Daniel Lezcano wrote:
>
>> On 20/10/2017 00:25, Thomas Gleixner wrote:
>>> On Fri, 20 Oct 2017, Daniel Lezcano wrote:
>>>
On 19/10/2017 22:57, David Kozub wrote:
> This solves a BUG on ALIX 2c3 where mfgpt_tick is called befor
The interrupt handler mfgpt_tick() is not robust versus spurious
interrupts which happen before the clock event device is registered and
fully initialized.
The reason is that the safe guard against spurious interrupts solely
checks for the clockevents shutdown state, but lacks a check for
On Fri, 20 Oct 2017, David Kozub wrote:
>
> Now that I'm neither the author of the code nor the author of the commit
> message it doesn't seem right that I should be submitting this.
Don't worry. Just resubmit it for exercise so Daniel or I can pick it up
for merging. You did the hard work of ana
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
On 20/10/2017 00:25, Thomas Gleixner wrote:
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
On 19/10/2017 22:57, David Kozub wrote:
This solves a BUG on ALIX 2c3 where mfgpt_tick is called before
clockevents_config_and_register returns. This caused mfgpt
explanation. Let me give you an example:
The interrupt handler mfgpt_tick() is not robust versus spurious
interrupts which happen before the clock event device is registered and
fully initialized.
The reason is that the safe guard against spurious interrupts solely
checks for the clockevents
On 20/10/2017 00:25, Thomas Gleixner wrote:
> On Fri, 20 Oct 2017, Daniel Lezcano wrote:
>
>> On 19/10/2017 22:57, David Kozub wrote:
>>> This solves a BUG on ALIX 2c3 where mfgpt_tick is called before
>>> clockevents_config_and_register returns. This caused mfgpt_tick to call a
>>> null function
On Fri, 20 Oct 2017, Daniel Lezcano wrote:
> On 19/10/2017 22:57, David Kozub wrote:
> > This solves a BUG on ALIX 2c3 where mfgpt_tick is called before
> > clockevents_config_and_register returns. This caused mfgpt_tick to call a
> > null function pointer.
> >
> > Thanks to Daniel Lezcano and Th
ive you an example:
The interrupt handler mfgpt_tick() is not robust versus spurious
interrupts which happen before the clock event device is registered and
fully initialized.
The reason is that the safe guard against spurious interrupts solely
checks for the clockevents shutdown state,
On 19/10/2017 22:57, David Kozub wrote:
> This solves a BUG on ALIX 2c3 where mfgpt_tick is called before
> clockevents_config_and_register returns. This caused mfgpt_tick to call a
> null function pointer.
>
> Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this
> and suggesti
This solves a BUG on ALIX 2c3 where mfgpt_tick is called before
clockevents_config_and_register returns. This caused mfgpt_tick to call a
null function pointer.
Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this
and suggesting a solution.
Suggested-by: Thomas Gleixner
Signe
old status from causing spurious interrupts when the
> interrupt is unmasked at a later time.
>
> Signed-off-by: Doug Berger
Reviewed-by: Florian Fainelli
--
Florian
Since the DMA interrupt status is latched and the DMA servicing can be
polled, it is a good idea to clear the latched status of a DMA interrupt
before performing the service that would be invoked by the interrupt.
This prevents old status from causing spurious interrupts when the
interrupt is
On Mon, 31 Oct 2016, Eric Anholt wrote:
> Thomas Gleixner writes:
>
> > On Fri, 28 Oct 2016, Eric Anholt wrote:
> >
> >> Thomas Gleixner writes:
> >> > This is missing a fixes tag. I have no idea when that problem was
> >> > introduced, so I have no way to decide whether this needs to be tagged
Thomas Gleixner writes:
> On Fri, 28 Oct 2016, Eric Anholt wrote:
>
>> Thomas Gleixner writes:
>> > This is missing a fixes tag. I have no idea when that problem was
>> > introduced, so I have no way to decide whether this needs to be tagged
>> > stable or not.
>>
>> This code has been there si
s?
> >> write to clear the mailbox interrupt completed before returning
> >> from the interrupt.
That's not what the patch does. It makes sure that the interrupt it cleared
_before_ the IPI handler is called.
> >> The BCM2836 irqchip driver needs the same precaution to a
CM2836 irqchip driver needs the same
>> precaution to avoid spurious interrupts.
>
> This is missing a fixes tag. I have no idea when that problem was
> introduced, so I have no way to decide whether this needs to be tagged
> stable or not.
This code has been there since introduction
On Thu, 27 Oct 2016, Eric Anholt wrote:
> From: Phil Elwell
>
> The old arch-specific IRQ macros included a dsb to ensure the
> write to clear the mailbox interrupt completed before returning
> from the interrupt. The BCM2836 irqchip driver needs the same
> precaution
Eric Anholt writes:
> From: Phil Elwell
>
> The old arch-specific IRQ macros included a dsb to ensure the
> write to clear the mailbox interrupt completed before returning
> from the interrupt. The BCM2836 irqchip driver needs the same
> precaution to avoid spurious interr
From: Phil Elwell
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Signed-off-by: Phil Elwell
Signed-off-by: Eric
From: Phil Elwell
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other
From: Phil Elwell
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other
On 01/22/2016 05:48 PM, Peter Hurley wrote:
> Hi John,
Hi Peter,
> On 01/22/2016 02:27 AM, John Ogness wrote:
>> It has been seen that spurious interrupts are generated when the
>> DMA engine is in use. By disabling timeout interrupts (~IER_RDI)
>> this phenomenon go
Hi John,
On 01/22/2016 02:27 AM, John Ogness wrote:
> It has been seen that spurious interrupts are generated when the
> DMA engine is in use. By disabling timeout interrupts (~IER_RDI)
> this phenomenon goes away, but this driver relies on the timeout
> interrupts, so we just
It has been seen that spurious interrupts are generated when the
DMA engine is in use. By disabling timeout interrupts (~IER_RDI)
this phenomenon goes away, but this driver relies on the timeout
interrupts, so we just consume the spurious interrupts.
Since we are consuming spurious interrupts
, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
right IRQ line, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race cond
line, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
line, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
, registering it, then registering the
serial port and the irq handler for the serial port. During this phase spurious
interrupts for the serial port may happen which then crashes the kernel because
the action handler might not have been set up yet.
So, basically it's a race condition betwee
: Handle spurious interrupts gracefully
Andriy reported that on a virtual machine the warning about negative
expiry time in the clock events programming code triggered:
hpet: hpet0 irq 40 for MSI
hpet: hpet1 irq 41 for MSI
Switching to clocksource hpet
WARNING: at kernel/time/clockevents.c:239
, 7 insertions(+)
> >
> > Index: tip/kernel/time/tick-broadcast.c
> > ===
> > --- tip.orig/kernel/time/tick-broadcast.c
> > +++ tip/kernel/time/tick-broadcast.c
> > @@ -301,6 +301,13 @@ stati
> +++ tip/kernel/time/tick-broadcast.c
> @@ -301,6 +301,13 @@ static void tick_handle_periodic_broadca
> bool bc_local;
>
> raw_spin_lock(&tick_broadcast_lock);
> +
> + /* Handle spurious interrupts gracefully */
> + if (clo
===
--- tip.orig/kernel/time/tick-broadcast.c
+++ tip/kernel/time/tick-broadcast.c
@@ -301,6 +301,13 @@ static void tick_handle_periodic_broadca
bool bc_local;
raw_spin_lock(&tick_broadcast_lock);
+
+ /* Handle spurious interrupts gracef
errupt when nobody had asked for it to be delivered
>>>> or had asked for it to be delivered and later canceled the request. It
>>>> is most often in the latter situation, that there can be race
>>>> conditions. If these race conditions are not taken care of, the
On 11 December 2014 at 10:14, Preeti U Murthy wrote:
> I was talking of the case where we get an interrupt from the clockevent
> device but dont find the hrtimer to service and not really of an anomaly
> in timekeeping.
For sure that's a problem then and its obviously spurious unless we wanted
it
r it to be delivered and later canceled the request. It
>>> is most often in the latter situation, that there can be race
>>> conditions. If these race conditions are not taken care of, they can
>>> result in spurious interrupts.
>>
>> But the delta time
ten in the latter situation, that there can be race
>> conditions. If these race conditions are not taken care of, they can
>> result in spurious interrupts.
>
> But the delta time will be very small then, right ?
I was talking of the case where we get an interrupt from the c
On Wed, 10 Dec 2014, Santosh Shukla wrote:
> The causes I could find:
> - Clockevent device's counter overflow: When we need to program a clockevt
> device for times larger than it can handle, we program it for max time and
> then reprogram again on expiration. Because of hardware counter limit
f these race conditions are not taken care of, they can
> result in spurious interrupts.
But the delta time will be very small then, right ?
> Since the difference is 1us and not a noticeably high value, it is most
> probably because during hrtimer handling, we traverse all queued timers
>
most often in the latter situation, that there can be race
conditions. If these race conditions are not taken care of, they can
result in spurious interrupts.
>
> I tried to catch them with the help of few new trace points in
> hrtimer_interrupt() when it didn't serviced an
1 - 100 of 132 matches
Mail list logo
