On Sat, Jan 11, 2020 at 08:16:23PM -0500, James Hastings wrote: > > 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.
Thanks for the patch and sorry for the delay. I have committed this.
