> 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
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> syncing disks...st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> st 1f00000000000008
> 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.
