Index | Thread | Search

From:
Mark Kettenis <mark.kettenis@xs4all.nl>
Subject:
Re: sys/octeon: cleanup all interrupts
To:
Kirill A. Korinsky <kirill@korins.ky>
Cc:
tech@openbsd.org, visa@openbsd.org
Date:
Thu, 16 Apr 2026 13:20:39 +0200

Download raw body.

Thread
> Date: Thu, 16 Apr 2026 13:04:23 +0200
> From: Kirill A. Korinsky <kirill@korins.ky>
> 
> tech@, visa@,
> 
> I think I finally figured out why my small octen is hangs randomly under
> load, it was very long week of printf-based debugin.
> 
> So, octciu_next_irq() operates on a uint64_t pending interrupt bitmap, and
> irq spans the full 0..63 range. Using 1u << irq therefore builds a 32 bit
> mask for a 64 bit word; once irq >= 32, the selected pending bit is no
> longer cleared correctly.
> 
> The immediate consequence is loss of forward progress in the dispatcher
> loop: the same interrupt can remain logically pending in the local copy of
> isr, the loop can revisit it indefinitely, and the CPU can remain trapped in
> interrupt handling.
> 
> After I applied that, I can't hang it anymore on my tests.
> 
> Ok? Probably it worth to include into 7.9

ok kettenis@

And I'd say that this is 7.9 material (but make sure you talk to
deraadt@ for that)

> Index: sys/arch/octeon/dev/octciu.c
> ===================================================================
> RCS file: /home/cvs/src/sys/arch/octeon/dev/octciu.c,v
> diff -u -p -r1.20 octciu.c
> --- sys/arch/octeon/dev/octciu.c	4 Apr 2026 09:00:20 -0000	1.20
> +++ sys/arch/octeon/dev/octciu.c	16 Apr 2026 10:54:54 -0000
> @@ -452,7 +452,7 @@ octciu_next_irq(uint64_t *isr)
>  	: "=r" (tmp) : "0" (tmp));
>  
>  	irq = 63u - tmp;
> -	*isr &= ~(1u << irq);
> +	*isr &= ~(1ULL << irq);
>  	return irq;
>  }
>  
> 
> 
> -- 
> wbr, Kirill
> 
>