Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Apr 2019 19:08:29 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arm@FreeBSD.org
Subject:   [Bug 237078] generic_timer not handling interrupts properly
Message-ID:  <bug-237078-7@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237078

            Bug ID: 237078
           Summary: generic_timer not handling interrupts properly
           Product: Base System
           Version: CURRENT
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: andrew@tao11.riddles.org.uk

generic_timer.c installs interrupt handlers for up to four timer interrupts,
causing those interrupts to be enabled on the local PIC. But the handler th=
at
it installs assumes that all interrupts come from a specific timer (either =
the
physical one on 32bit or the virtual one on 64bit).

If an interrupt occurs on the other timer, then the interrupt is never mask=
ed
or cleared, so a CPU is put into a permanent interrupt handling loop; this =
is
commonly observed on RPI2 platforms at least.

The unexpected interrupt can occur because while the driver attach routine
tries to mask off both the physical and virtual (on 32bit) interrupts, it d=
oes
this on only one CPU, when in fact each CPU has its own timer.

I have tested a crude workaround (not installing handlers for the unused
interrupts) which fixes the observed problems as far as I can determine.

This bug could potentially apply on 64bit as well, but I am not in a positi=
on
to test that.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237078-7>