Yep, in the end I found out that that is a timer and yes, it fires very
often.
However, that is not the timer that is used within the kernel for
scheduling and stuff, correct?
On Sat, May 1, 2021 at 12:37 PM Patrick Wildt <patr...@blueri.se> wrote:
> Am Sat, May 01, 2021 at 11:09:46AM +0200 schrieb Mark Kettenis:
> > > From: Alessandro Pistocchi <apukbusin...@gmail.com>
> > > Date: Thu, 29 Apr 2021 00:50:32 +0200
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > Hi all,
> > > in the kernel I see the code below (file: arm64/dev/ampint.c
> lines:643-666).
> > >
> > > void
> > > ampintc_irq_handler(void *frame)
> > > {
> > > struct ampintc_softc *sc = ampintc;
> > > struct intrhand *ih;
> > > void *arg;
> > > uint32_t iack_val;
> > > int irq, pri, s, handled;
> > >
> > > iack_val = ampintc_iack();
> > > #ifdef DEBUG_INTC
> > > if (iack_val != 27)
> > > printf("irq %d fired\n", iack_val);
> > > else {
> > > static int cnt = 0;
> > > if ((cnt++ % 100) == 0) {
> > > printf("irq %d fired * _100\n", iack_val);
> > > #ifdef DDB
> > > db_enter();
> > > #endif
> > > }
> > >
> > > }
> > > #endif
> > >
> > > Does anyone know what interrupt 27 is for? It seems to fire quite
> often.
> >
> > It probably was the serial console on the machine that was used to
> > develop this driver. At least that is what I've used that snippet of
> > code for in the past. It is not a good idea to print stuff in the
> > interrupt handler for the device that is used for console output since
> > you end up triggering more interrupts that way. But I've always
> > changed the number to whatever was appropriate for the machine at
> > hand. In other word, 27 is just a number.
>
> Nah, that was for the timer. The issue was that the timer was firing so
> quick, you couldn't see if any other interrupts were happening, hence we
> made it so it only prints it a few times.
>
