On Mon, 24 Jun 2019, Thomas Gleixner wrote:
>
> +#ifdef CONFIG_X86_LOCAL_APIC
> + .align 8
> +ENTRY(spurious_entries_start)
> +vector=FIRST_SYSTEM_VECTOR
> +.rept (NR_VECTORS - FIRST_SYSTEM_VECTOR)
> + pushl $(~vector+0x80) /* Note: always in signed byte
> range
On Mon, 24 Jun 2019, Thomas Gleixner wrote:
> On Mon, 24 Jun 2019, Jan Kiszka wrote:
> > On 24.06.19 12:09, Thomas Gleixner wrote:
> > > If it is a vectored one it _IS_ acked.
> > >
> > > inc_irq_stat(irq_spurious_count);
> > >
> > > /* see sw-dev-man vol 3, chapter 7.4.13.5 */
On 24.06.19 12:09, Thomas Gleixner wrote:
Jan,
On Mon, 24 Jun 2019, Jan Kiszka wrote:
probably since "x86: Avoid building unused IRQ entry stubs" (2414e021ac8d),
the kernel can no longer tell spurious IRQs by the APIC apart from spuriously
triggered unused vectors.
Err. It does.
We've manag
On Mon, 24 Jun 2019, Jan Kiszka wrote:
> On 24.06.19 12:09, Thomas Gleixner wrote:
> > If it is a vectored one it _IS_ acked.
> >
> > inc_irq_stat(irq_spurious_count);
> >
> > /* see sw-dev-man vol 3, chapter 7.4.13.5 */
> > pr_info("spurious APIC interrupt through vector %0
Jan,
On Mon, 24 Jun 2019, Jan Kiszka wrote:
> probably since "x86: Avoid building unused IRQ entry stubs" (2414e021ac8d),
> the kernel can no longer tell spurious IRQs by the APIC apart from spuriously
> triggered unused vectors.
Err. It does.
> We've managed to trigger such a cause with the Jai
5 matches
Mail list logo