> On Sat, Jan 11, 2020 at 12:42:50 +0100, Mark Kettenis wrote:
> > Date: Fri, 10 Jan 2020 13:37:38 -0500
> > From: Bryan Steele <[email protected]>
> >
> > On Fri, Jan 10, 2020 at 02:59:10AM -0500, James Hastings wrote:
> > > > On Sat, Jan 04, 2020 at 06:23:44PM +0100, Mark Kettenis wrote:
> > > > > Date: Sat, 4 Jan 2020 12:03:14 -0500
> > > > > From: Bryan Steele <[email protected]>
> > > > >
> > > > > On Sat, Jan 04, 2020 at 11:30:56AM -0500, Bryan Steele wrote:
> > > > > > On Sat, Jan 04, 2020 at 05:07:04PM +0100, Mark Kettenis wrote:
> > > > > > > > Date: Sat, 4 Jan 2020 10:52:24 -0500
> > > > > > > > From: Bryan Steele <[email protected]>
> > > > > > > >
> > > > > > > > I noticed an unusually high interrupt rate for amdgpio0 on my
> > > > > > > > Huawei
> > > > > > > > Matebook D laptop. I'm suspecting this may be partially why it
> > > > > > > > apmd -A
> > > > > > > > has been struggling, as the CPU is constantly busy so it never
> > > > > > > > has a
> > > > > > > > chance to scale down.
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > >
> > > > > > > Please send acpidump output (all files in /var/db/acpi).
> > > > > > >
> > > > > > > Try to figure out which GPIO pin is causing the interrupt. That
> > > > > > > may
> > > > > > > be tricky since the interrupt fires again and again, so if you
> > > > > > > add a
> > > > > > > printf in amdgpio_intr() your machine will become unusable. Maybe
> > > > > > > just print the pin every 10000 times:
> > > > > > >
> > > > > > > static count = 0;
> > > > > > >
> > > > > > > ....
> > > > > > >
> > > > > > > if ((count++ % 10000) == 0)
> > > > > > > printf("st %llx\n", status)
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Mark
> > > > > >
> > > > > > Thanks, for some reason it vanished with on a cold boot. I'm not
> > > > > > sure
> > > > > > what it was that caused it. In case it helps, sending the acpidump
> > > > > > anyway.
> > > > > >
> > > > > > If I can figure out what caused it, I'll try your other suggestion.
> > > > > >
> > > > > > Sigh.. :-)
> > > > >
> > > > > Aha! I must of accidentally bumped the Touchscreen at some point,
> > > > > doing
> > > > > that causes the amdgpio0 rate to spike.
> > > > >
> > > > > I had sent a diff to add AMD controller support to dwiic(4) months
> > > > > ago,
> > > > > I could never get interrupts to work, only polling mode. Perhaps this
> > > > > issue explains some of that. I don't have this diff in my tree at the
> > > > > moment, had to restore from backup.
> > > > >
> > > > > Managed to login and type shutdown, lol.
> > > > >
> > > > > ..
> > > > > st 1f00000000000008
> > > >
> > > > Very likely. The AML defines an I2C device with:
> > > >
> > > > Name (_DDN, "Raydium Touchscreen") // _DDN: DOS Device Name
> > > >
> > > > that uses a GPIO interrupt that matches the lowest bit set in the
> > > > status register.
> > > >
> > > > This suggest we may need to be a little bit more careful and mask
> > > > interrupts for which we don't have an interrupt handler.
> > > That is my fault. Does this diff stop your interrupt storm?
> >
> > Yes. This works, thanks!
> >
> > ok brynet@ (if Mark agrees)
>
> I fear that this isn't the right approach. Some of the GPIO pins
> might be used for SMIs. And it isn't clear to me whether disabling
> interrupts will also stop SMIs from being generated.
>
> A better strategy would be to have the interrupt handler disable pins
> for which it sees an interrupt pending when there is no interrupt
> handler registered. I believe that is what Linux does.
>
> James, is that something you'd like to work on?
>
> Also, I don't think that this will fix the issue that claudo@ and I
> are seeing on the m715q. There I'm starting to suspect that the
> problem is that the interrupt is shared with a quirky PCI device.
> There a BIOS update (which stops amdgpio(4) from attaching) may
> actually be the only reasonable fix.
>
> Cheers,
>
> Mark
I changed the interrupt routine to mask pins that do not have an
interrupt handler registered.
Index: dev/acpi/amdgpio.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 amdgpio.c
--- dev/acpi/amdgpio.c 23 Dec 2019 08:05:42 -0000 1.1
+++ dev/acpi/amdgpio.c 11 Jan 2020 23:56:02 -0000
@@ -260,20 +260,28 @@ int
amdgpio_pin_intr(struct amdgpio_softc *sc, int pin)
{
uint32_t reg;
+ int rc = 0;
reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
- if (!(reg & AMDGPIO_CONF_INT_STS) ||
- !(reg & AMDGPIO_CONF_INT_MASK))
- return 0;
+ if (reg & AMDGPIO_CONF_INT_STS) {
+ if (sc->sc_pin_ih[pin].ih_func) {
+ sc->sc_pin_ih[pin].ih_func(sc->sc_pin_ih[pin].ih_arg);
- if (sc->sc_pin_ih[pin].ih_func)
- sc->sc_pin_ih[pin].ih_func(sc->sc_pin_ih[pin].ih_arg);
+ /* Clear interrupt */
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
+ pin * 4);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ pin * 4, reg);
+ rc = 1;
+ } else {
+ /* Mask unhandled interrupt */
+ reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ pin * 4, reg);
+ }
+ }
- /* Clear interrupt */
- reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
- bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
-
- return 1;
+ return rc;
}
int
