> 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?
Index: dev/acpi/amdgpio.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
retrieving revision 1.1
diff -u -p -r1.1 amdgpio.c
--- dev/acpi/amdgpio.c 23 Dec 2019 08:05:42 -0000 1.1
+++ dev/acpi/amdgpio.c 10 Jan 2020 07:30:32 -0000
@@ -108,6 +108,8 @@ amdgpio_attach(struct device *parent, st
struct amdgpio_softc *sc = (struct amdgpio_softc *)self;
struct aml_value res;
int64_t uid;
+ uint32_t reg;
+ int i;
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_node = aaa->aaa_node;
@@ -156,6 +158,16 @@ amdgpio_attach(struct device *parent, st
&sc->sc_memh)) {
printf(", can't map registers\n");
goto free;
+ }
+
+ /* Mask and clear all interrupts */
+ for (i = 0; i < sc->sc_npins; i++) {
+ if (i == 63)
+ continue;
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, i * 4);
+ reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ reg |= AMDGPIO_CONF_INT_STS;
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, i * 4, reg);
}
sc->sc_ih = acpi_intr_establish(sc->sc_irq, sc->sc_irq_flags, IPL_BIO,
