Bug 201817 - irq 7: nobody cared for HP laptop with with touchscreen and AMD processor
Summary: irq 7: nobody cared for HP laptop with with touchscreen and AMD processor
Status: NEW
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
Depends on: 198715
Blocks:
  Show dependency tree
 
Reported: 2018-11-29 18:40 UTC by Bram Coenen
Modified: 2020-05-21 23:57 UTC (History)
21 users (show)

See Also:
Kernel Version: 4.19.4
Tree: Mainline
Regression: No


Attachments
dmesg after boot, 4.19.4, no touchscreen (75.64 KB, text/plain)
2018-11-29 18:40 UTC, Bram Coenen
Details
dmesg after boot, 4.19.3, working touchscreen (73.19 KB, text/plain)
2018-11-29 18:51 UTC, Bram Coenen
Details
cat /proc/interrupts (1.22 KB, text/plain)
2018-12-20 21:09 UTC, nospamming11+kernel
Details
modified function (1.81 KB, text/plain)
2019-01-18 18:20 UTC, nospamming11+kernel
Details
modified - dmesg - working (322.06 KB, text/plain)
2019-01-18 18:22 UTC, nospamming11+kernel
Details
[RFC] pinctrl/amd: Clear interrupt enable bits on probe (10.20 KB, patch)
2019-02-19 13:24 UTC, Hans de Goede
Details | Diff
dmesg with leonard patch and a non-working touchscreen (72.48 KB, text/plain)
2019-02-20 14:26 UTC, Bram Coenen
Details
dmesg with leonard patch and a working touchscreen (72.85 KB, text/plain)
2019-02-20 16:41 UTC, Bram Coenen
Details
dmesg_leonard_patch_no_touchscreen (77.45 KB, text/plain)
2019-02-21 05:05 UTC, Bram Coenen
Details
cat /sys/kernel/debug/gpio - linux-zen 5.5.8 (49.91 KB, text/plain)
2020-03-11 21:35 UTC, Alois Nespor
Details
cat /sys/kernel/gpio result (49.66 KB, text/plain)
2020-03-12 00:27 UTC, Jose Silva
Details
cat /sys/kernel/debug/gpio (49.76 KB, text/plain)
2020-03-12 08:09 UTC, philipp_023
Details
cat /sys/kernel/debug/gpio. Cuz why not (49.66 KB, text/plain)
2020-03-27 21:10 UTC, Neil
Details

Description Bram Coenen 2018-11-29 18:40:08 UTC
Created attachment 279741 [details]
dmesg after boot, 4.19.4, no touchscreen

The Elan touchscreen on HP laptops with an AMD processor just got fixed and worked properly for a while in 4.19.3. However after installing a new kernel version, 4.19.4, the touchscreen stopped working and new errors appeared.

I once got this in 4.19.3 as well, but after a few shutdowns and the last shutdown holding the power button, this was resolved. I did have issues login in as well (Don't)

I'm on a HP ENVY x360 Convertible 15-bq0xx/8311, BIOS F.08 with only Fedora 28.

The APCI-config was fixed in https://bugzilla.kernel.org/show_bug.cgi?id=198715 .
Comment 1 Bram Coenen 2018-11-29 18:51:30 UTC
Created attachment 279743 [details]
dmesg after boot, 4.19.3, working touchscreen
Comment 2 Bram Coenen 2018-11-29 18:58:55 UTC
Just checked. The kernel version doesn't matter, a decent about of reboots does the trick to get the touchscreen working even on 4.19.4.
Comment 3 Bram Coenen 2018-11-29 19:11:53 UTC
[   16.587361] irq 7: nobody cared (try booting with the "irqpoll" option)
[   16.587366] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        4.19.4-200.fc28.x86_64 #1
[   16.587367] Hardware name: HP HP ENVY x360 Convertible 15-bq0xx/8311, BIOS F.08 03/30/2018
[   16.587368] Call Trace:
[   16.587372]  <IRQ>
[   16.587381]  dump_stack+0x5c/0x80
[   16.587385]  __report_bad_irq+0x37/0xae
[   16.587388]  note_interrupt.cold.9+0xa/0x69
[   16.587390]  handle_irq_event_percpu+0x6a/0x80
[   16.587392]  handle_irq_event+0x27/0x44
[   16.587394]  handle_fasteoi_irq+0x7f/0x120
[   16.587398]  handle_irq+0xbf/0x100
[   16.587400]  do_IRQ+0x49/0xd0
[   16.587403]  common_interrupt+0xf/0xf
[   16.587405]  </IRQ>
[   16.587409] RIP: 0010:native_safe_halt+0x2/0x10
[   16.587411] Code: ff ff 7f c3 65 48 8b 04 25 00 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 75 c4 eb 8c 90 90 90 90 90 90 90 90 90 90 90 90 90 fb f4 <c3> 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
[   16.587412] RSP: 0018:ffffffffbd203e18 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd8
[   16.587415] RAX: 0000000080000000 RBX: ffff887df5a01c00 RCX: 0000000000000034
[   16.587416] RDX: 4ec4ec4ec4ec4ec5 RSI: ffffffffbd2dd200 RDI: ffff887df5a01c64
[   16.587418] RBP: ffff887df5a01c64 R08: 0000000000000002 R09: 0000000000020800
[   16.587419] R10: 0000000f66cccf99 R11: ffff887df721fde8 R12: 0000000000000001
[   16.587420] R13: 0000000000000001 R14: 0000000000000001 R15: 00000000d0c2fae0
[   16.587424]  acpi_safe_halt+0x1b/0x30
[   16.587427]  acpi_idle_enter+0x104/0x2a0
[   16.587431]  cpuidle_enter_state+0x71/0x320
[   16.587435]  do_idle+0x226/0x260
[   16.587438]  cpu_startup_entry+0x6f/0x80
[   16.587442]  start_kernel+0x523/0x543
[   16.587446]  secondary_startup_64+0xa4/0xb0
[   16.587448] handlers:
[   16.587453] [<00000000e6019074>] amd_gpio_irq_handler [pinctrl_amd]
[   16.587455] Disabling IRQ #7
Comment 4 Hans de Goede 2018-11-30 09:45:15 UTC
I discussed this a bit on the mailinglist. Here are the relevant parts of the discussion:

Me:

The amd_gpio chip/driver appears to be the only driver
connected to IRQ 7, so I think there is an issue with the
amd_gpio driver where it does not properly clear the interrupt
source. E.g. it might be that the BIOS requested interrupts
on a GPIO which Linux does not monitor and that the driver
does not disable this GPIO-IRQ on probe and since it is not
handling that pin in IRQ mode also does not clear it.

Anyways that is just a theory. It would greatly help if
someone who knows the amd_gpio driver better could take
a look.

Reply by Daniel Drake:

Sorry that I can't be much help here - I don't have access to any
useful info beyond the source code already present in Linux.

Maybe you could explore your theory by dumping the GPIO/GPIO-INT
enable regs, see if any of them are marked as enabled by something
other than Linux.

###

I'm afraid I don't have time to look into this myself atm. Maybe someone can add some printk calls to drivers/pinctrl/pinctrl-amd.c to dump relevant register values as Daniel suggested and see if that yields any useful info?
Comment 5 mruize85 2018-12-16 15:20:55 UTC
Forcing `amd_gpio_irq_handler()` from `drivers/pinctrl/pinctrl-amd.c` to always return `IRQ_HANDLED` makes touchscreen work, but now system is sending interrupts at very high rate (around 100 k/s). I a completely newbie to kernel development, so I don't really know what I'm doing... Any idea?
Comment 6 nospamming11+kernel 2018-12-20 21:09:07 UTC
Created attachment 280107 [details]
cat /proc/interrupts

Seeing the exact same problem on 4.19.10 (HP Envy x360 13-ag0004ng)

Attached the output of /proc/interrupts
Comment 7 Lukas Kahnert 2018-12-24 20:01:51 UTC
The only case where I got the "nobody cared" panic on my HP Envy x360 bq-1xx was if I used Windows 10 on my last boot and rebooted into Linux.
My theory is that Windows set the IRQ 7 on a state that persists on reboot(and trigger the panic in linux) and only get cleared if you hold down power button.
My Laptop is now Linux only and since then I never had this issue again(using 4.19.5 now).
Comment 8 JerryD 2019-01-15 02:33:41 UTC
This issue occurs without regard to Windows 10 previous boot. From cold powerup I get failure to boot about 2 out of 3 attempts. Anyway to remove this touchscreen driver? I think it should be backed out until the regression is fixxed.
Comment 9 Bram Coenen 2019-01-15 07:22:10 UTC
(In reply to JerryD from comment #8)
> This issue occurs without regard to Windows 10 previous boot. From cold
> powerup I get failure to boot about 2 out of 3 attempts. Anyway to remove
> this touchscreen driver? I think it should be backed out until the
> regression is fixxed.

I don't even have Windows any more and get the bug sometimes. However, I do not agree that the driver should be removed. I still use the touchscreen daily because for me it is working most of the time. Besides, it does not hurt having it there, does it?
Comment 10 JerryD 2019-01-17 02:22:07 UTC
Are there any workarounds?
Comment 11 nospamming11+kernel 2019-01-17 13:34:38 UTC
Some suggest here: https://github.com/linuxwacom/wacom-hid-descriptors/issues/12
that switching to Legacy BIOS boot helped them.
Comment 12 nospamming11+kernel 2019-01-18 18:19:59 UTC
I can confirm that always returning IRQ_HANDLED fixes the error, but spams the system with a lot of these interrupts (it never stops)

Sometimes booting with the kernel option noirqdebug helped me to get the touchscreen up and running again.

I then noticed the following: See attached three files. One with a modified amd_gpio_irq_handler and two dmesg outputs. One of them with a working touchscreen and one where the touchscreen does not work. I can see that in the working case all interrupts are handled correctly while in the "not-working"-case there are A LOT of interrupts handled at all.
Comment 13 nospamming11+kernel 2019-01-18 18:20:41 UTC
Created attachment 280583 [details]
modified function
Comment 14 nospamming11+kernel 2019-01-18 18:22:35 UTC
Created attachment 280585 [details]
modified - dmesg - working
Comment 15 nospamming11+kernel 2019-01-18 18:27:24 UTC
Not working - dmesg (too large to attach directly): https://bit.ly/2FHChBb
Comment 16 JerryD 2019-01-20 00:21:56 UTC
(In reply to nospamming11+kernel from comment #12)
> I can confirm that always returning IRQ_HANDLED fixes the error, but spams
> the system with a lot of these interrupts (it never stops)
> 
> Sometimes booting with the kernel option noirqdebug helped me to get the
> touchscreen up and running again.
> 
> I then noticed the following: See attached three files. One with a modified
> amd_gpio_irq_handler and two dmesg outputs. One of them with a working
> touchscreen and one where the touchscreen does not work. I can see that in
> the working case all interrupts are handled correctly while in the
> "not-working"-case there are A LOT of interrupts handled at all.

What does this imply? Does the driver need to actually handle this interupt? What hardware is actually generating this interupt? Or is IRQ 7 and unused pin that if floating and therefore must be disabled?
Comment 17 JerryD 2019-02-09 19:35:50 UTC
Appears to be fixed on Fedora kernel 4.20.6-200.fc29.x86_64
Comment 18 nospamming11+kernel 2019-02-09 19:59:22 UTC
Sadly, I can't confirm that. Neither on 4.20.6.arch1-1-ARCH nor on 4.20.7-arch1-1-ARCH the problem is fixed for me. (Laptop Firmware: F.32)

Still noirqdebug is a workaround.
Comment 19 JerryD 2019-02-10 01:11:38 UTC
(In reply to nospamming11+kernel from comment #18)
> Sadly, I can't confirm that. Neither on 4.20.6.arch1-1-ARCH nor on
> 4.20.7-arch1-1-ARCH the problem is fixed for me. (Laptop Firmware: F.32)
> 
> Still noirqdebug is a workaround.

I am on HP Envy Laptop with Bios F19 which HP pulled evidently because it has some other big problem. But since everything is stable for me at the moment I am just leaving it alone. From what I am reading the only way to back that bios out is with a special USB stick which they will send you. My current kernel boot line is:

BOOT_IMAGE=/vmlinuz-4.20.6-200.fc29.x86_64 root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet LANG=en_US.UTF-8 idle=nomwait processor.max_cstate=5
Comment 20 Bram Coenen 2019-02-14 04:48:29 UTC
(In reply to JerryD from comment #17)
> Appears to be fixed on Fedora kernel 4.20.6-200.fc29.x86_64

It isn't fixed for me on the 4.20.6-200.fc29.x86_64. But it doesn't always happen, sometimes it can go days without the bug appearing.
Comment 21 JerryD 2019-02-16 03:16:40 UTC
(In reply to Bram Coenen from comment #20)
> (In reply to JerryD from comment #17)
> > Appears to be fixed on Fedora kernel 4.20.6-200.fc29.x86_64
> 
> It isn't fixed for me on the 4.20.6-200.fc29.x86_64. But it doesn't always
> happen, sometimes it can go days without the bug appearing.

You are right, it is intermittent, sometimes I get it and sometimes I dont.

A side note, I upgraded to Bios F20.  Dont do this. 4.20.xx fails to boot. 4.18 seems to boot fine.
Comment 22 nospamming11+kernel 2019-02-16 14:59:58 UTC
Can you guys confirm that "noirqdebug" as a kernel boot param works for you too?
Comment 23 JerryD 2019-02-17 16:53:37 UTC
(In reply to nospamming11+kernel from comment #22)
> Can you guys confirm that "noirqdebug" as a kernel boot param works for you
> too?

With Linux version 4.18.16-300.fc29.x86_64 mockbuild@bkernel04.phx2.fedoraproject.org)

I see no irq7 issue.

With 4.20.7-200.fc29.x86_64 it locks up right away and unable to get any sort of backtrace with ot without "noirqdebug" ABRT reports insufficiant information to generate a report and to contact kernel mailing list.
Comment 24 JerryD 2019-02-17 16:59:33 UTC
For clarity on comment 23: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018
Comment 25 Hans de Goede 2019-02-19 13:24:40 UTC
Created attachment 281207 [details]
[RFC] pinctrl/amd: Clear interrupt enable bits on probe

Good news, Leonard Crestez has come up with a patch which likely fixes this.

I'm attaching the patch here, please give it a try.
Comment 26 nospamming11+kernel 2019-02-19 18:35:13 UTC
Unfortunately this still does not fix it for me.

I applied it to 4.20.10-arch1-1 (Archlinux kernel) and I still get the error:

"irq 7:nobody cared (try booting with the "irqpoll" option)"
with a Call Trace afterwards.

I can see that the new function is getting called and tells me that a bunch of PINs get disabled

"amd_gpio: AMD10030:00: Pin 67 interrupt enabled on boot: disable
.....
"

But right after that IRQ 7 starts to spam my logs again (having still added the above described log-outputs
Comment 27 Bram Coenen 2019-02-20 14:26:55 UTC
Created attachment 281231 [details]
dmesg with leonard patch and a non-working touchscreen

Dmesg output when trying Leonard Crestez's patch the first time and it didn't work. It worked when booting into the kernel the second time and I think the relevant error message was the one shown below. I'll come back and give an update if/when the touchscreen stops working again. 

The nobody cared error is gone at least! 

[    2.964272] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided an Int IRQ
[    2.964330] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22

(This is my first time compiling a kernel in fedora. So I could also have done something wrong.)
Comment 28 nospamming11+kernel 2019-02-20 14:47:32 UTC
I have seen the i2c-error too - when my touchscreen worked, but the patch does not work for me (even after several linux-only-boots).

Do you have a windows system installed @Bram Coenen? Can you boot into it and test if the touchscreen still works, when you boot back into linux?
Comment 29 Bram Coenen 2019-02-20 16:39:29 UTC
(In reply to nospamming11+kernel from comment #28)
> I have seen the i2c-error too - when my touchscreen worked, but the patch
> does not work for me (even after several linux-only-boots).
> 
> Do you have a windows system installed @Bram Coenen? Can you boot into it
> and test if the touchscreen still works, when you boot back into linux?

No, unfortunately I don't have windows installed. However the bug happens now and again anyways
Comment 30 Bram Coenen 2019-02-20 16:41:30 UTC
Created attachment 281233 [details]
dmesg with leonard patch and a working touchscreen

I think the interesting parts here are these prints.

[    2.988099] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vdd not found, using dummy regulator
[    2.988146] i2c_hid i2c-ELAN0732:00: Linked as a consumer to regulator.0
[    2.988148] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vddl not found, using dummy regulator
[    2.993265] audit: type=1130 audit(1550670938.923:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[    3.015329] acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
[    3.015354] wmi_bus wmi_bus-PNP0C14:01: WQBJ data block query control method not found
[    3.017236] input: ELAN0732:00 04F3:24BC Touchscreen as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input13
[    3.017377] input: ELAN0732:00 04F3:24BC as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input14
[    3.017434] input: ELAN0732:00 04F3:24BC as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input15
[    3.017492] input: ELAN0732:00 04F3:24BC as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input16
[    3.017589] hid-generic 0018:04F3:24BC.0004: input,hidraw3: I2C HID v1.00 Device [ELAN0732:00 04F3:24BC] on i2c-ELAN0732:00
[    3.064691] nvme nvme0: pci function 0000:03:00.0
[    3.107262] AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de>
[    3.213210] input: ELAN0732:00 04F3:24BC as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input18
[    3.213350] input: ELAN0732:00 04F3:24BC as /devices/platform/AMD0010:00/i2c-0/i2c-ELAN0732:00/0018:04F3:24BC.0004/input/input21
[    3.213445] hid-multitouch 0018:04F3:24BC.0004: input,hidraw2: I2C HID v1.00 Device [ELAN0732:00 04F3:24BC] on i2c-ELAN0732:00
Comment 31 Bram Coenen 2019-02-20 19:52:49 UTC
I got the bug again, but no print from the patch. So I probably messed up the compilation of the kernel with the patch. I'll try to patch it correctly tomorrow!
Comment 32 JerryD 2019-02-21 03:22:58 UTC
(In reply to JerryD from comment #23)
> (In reply to nospamming11+kernel from comment #22)
> > Can you guys confirm that "noirqdebug" as a kernel boot param works for you
> > too?
> 
> With Linux version 4.18.16-300.fc29.x86_64
> mockbuild@bkernel04.phx2.fedoraproject.org)
> 
> I see no irq7 issue.
> 
> With 4.20.7-200.fc29.x86_64 it locks up right away and unable to get any
> sort of backtrace with ot without "noirqdebug" ABRT reports insufficiant
> information to generate a report and to contact kernel mailing list.

Turns out the problem I have with the 4.20 kernel is not bios related and bios F.20 is OK. I ran into this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=109206

Kernel 4.19.15-300.fc29.x86_64 is working fine.
Comment 33 Bram Coenen 2019-02-21 04:55:25 UTC
(In reply to JerryD from comment #32)
> (In reply to JerryD from comment #23)
> > (In reply to nospamming11+kernel from comment #22)
> > > Can you guys confirm that "noirqdebug" as a kernel boot param works for
> you
> > > too?
> > 
> > With Linux version 4.18.16-300.fc29.x86_64
> > mockbuild@bkernel04.phx2.fedoraproject.org)
> > 
> > I see no irq7 issue.
> > 
> > With 4.20.7-200.fc29.x86_64 it locks up right away and unable to get any
> > sort of backtrace with ot without "noirqdebug" ABRT reports insufficiant
> > information to generate a report and to contact kernel mailing list.
> 
> Turns out the problem I have with the 4.20 kernel is not bios related and
> bios F.20 is OK. I ran into this bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=109206
> 
> Kernel 4.19.15-300.fc29.x86_64 is working fine.

Try a higher version of 4.20. Mine is working on 4.20.10 for example.
Comment 34 Bram Coenen 2019-02-21 05:05:04 UTC
Created attachment 281253 [details]
dmesg_leonard_patch_no_touchscreen

I applied the patch made by Leonard correctly this time. The touchscreen does not work and prints the following for pin 67 to 148.

[    3.080467] amd_gpio AMD0030:00: Pin 67 interrupt enabled on boot: disable
Comment 35 Bram Coenen 2019-02-21 05:11:12 UTC
(In reply to Bram Coenen from comment #34)
> Created attachment 281253 [details]
> dmesg_leonard_patch_no_touchscreen
> 
> I applied the patch made by Leonard correctly this time. The touchscreen
> does not work and prints the following for pin 67 to 148.
> 
> [    3.080467] amd_gpio AMD0030:00: Pin 67 interrupt enabled on boot: disable

"irq 7: nobody cared" is also still present.
Comment 36 Bram Coenen 2019-02-21 10:24:27 UTC
(In reply to Bram Coenen from comment #35)
> (In reply to Bram Coenen from comment #34)
> > Created attachment 281253 [details]
> > dmesg_leonard_patch_no_touchscreen
> > 
> > I applied the patch made by Leonard correctly this time. The touchscreen
> > does not work and prints the following for pin 67 to 148.
> > 
> > [    3.080467] amd_gpio AMD0030:00: Pin 67 interrupt enabled on boot:
> disable
> 
> "irq 7: nobody cared" is also still present.

Now my touchscreen is working with the patch. It still prints that the same pins are disabled and the nobody cared is gone. So I don't think the patch made any difference.
Comment 37 nospamming11+kernel 2019-07-01 18:54:43 UTC
Giving a quick update:

On Linux 5.1.15 (archlinux) with Firmware F.32 the bug still persists reliable (Linux boot after Windows boot)
Comment 38 JerryD 2019-07-28 15:45:57 UTC
Still present on 5.1.19-300 (Fedora 30)
Comment 39 Daniel Drake 2019-08-14 09:17:38 UTC
I just faced a similar problem on a new platform: the BIOS boots with a GPIO IRQ enabled, the boot-time GPIO state causes the IRQ to fire. pinctrl-amd tries to handle the IRQ, but doesn't call any handler, and as a result we get a boot-time interrupt storm.

I considered the patch here, but I checked Windows vs Linux. After boot, both OSes have the same 41 GPIO IRQs enabled. This is many more than the ones listed in the DSDT. I believe this means that Windows does not disable all GPIO IRQs at boot time, and hence the patch posted here (based on an earlier suggestion that I made) is somewhat risky.

I guess from the comments above that approach didn't help either.

I took an alternative approach, to just disable the spurious IRQ, which solves the issue I was facing:
   [PATCH] pinctrl/amd: disable spurious-firing GPIO IRQs
but if the disable-all approach didn't work then I don't think this patch will help your case either.

If anyone wants to investigate further, I think the next step here is to dump the contents of the "status" variable in amd_gpio_irq_handler(). The fact that you are getting "nobody cared" indicates that the pinctrl-amd driver itself doesn't know even which GPIO is causing the interrupt to be fired. From that angle it's understandable that disabling all the GPIO interrupts didn't make a difference. Checking the exact value of "status" will give us more clarity.
Comment 40 nospamming11+kernel 2019-08-14 09:34:51 UTC
You can already find logs with the status variable dumped in this thread. 

I attached them: one version with a boot where the touchscreen was working and one version with a boot where the touchscreen was not working. (and the source code of the modified handler that creates the dump)

The problem still persists and a workaround is booting with the kernel-option noirqdebug or let the device powered off for a few days. Then the touchscreen works again (until you boot to windows).
Comment 41 Daniel Drake 2019-08-15 02:58:49 UTC
Ah, I see it in Comment #15.

So when your issue bites, the pinctrl-amd status register is zero.
The GPIO controller is indicating that it did not generate any interrupt at all.

So as you probably already grasped, the cause of your issue almost certainly resides outside of pinctrl-amd.

To look for clues here, two more ideas:

1. Check closely when the interrupt spam starts appearing. Is it right after pinctrl-amd loads, or is it triggered somewhat later in boot? If it's triggered later then you can try to figure out precisely what causes it.

2. Look for differences elsewhere between the working & non-working setups. Perhaps differences in the APIC registers (or something like that) could explain the weird interrupts on irq 7. I'm a bit out of my knowledge area there though.
Comment 42 Shmerl 2019-11-05 20:23:16 UTC
I have a similar problem with Lenovo Thinkpad E495 (see below for dmesg snippet). This laptop doesn't even have a touchscreen display.

The error doesn't really cause any hangs or slowdown (I'm running 5.4-rc6), only that message in the log (shown during boot). Is there a way though to get rid of it without using Windows? I don't have access to Windows installation on this computer anymore.

Thanks!

Here is what I see in dmesg:

[    2.380193] irq 7: nobody cared (try booting with the "irqpoll" option)
[    2.380216] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G            E     5.4.0-rc5+ #25
[    2.380217] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET30W (1.10 ) 10/11/2019
[    2.380218] Call Trace:
[    2.380220]  <IRQ>
[    2.380225]  dump_stack+0x5c/0x80
[    2.380228]  __report_bad_irq+0x38/0xad
[    2.380230]  note_interrupt.cold+0xb/0x6e
[    2.380232]  handle_irq_event_percpu+0x72/0x80
[    2.380233]  handle_irq_event+0x3c/0x5c
[    2.380234]  handle_fasteoi_irq+0xa3/0x160
[    2.380236]  do_IRQ+0x53/0xe0
[    2.380238]  common_interrupt+0xf/0xf
[    2.380238]  </IRQ>
[    2.380241] RIP: 0010:cpuidle_enter_state+0xc4/0x450
[    2.380243] Code: e8 c1 94 ad ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 61 03 00 00 31 ff e8 e3 b1 b3 ff fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 8c 02 00 00 49 63 cc 4c 2b 6c 24 10 48 8d 04 49 48
[    2.380243] RSP: 0018:ffffaea10015fe68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
[    2.380245] RAX: ffff8f99708ea6c0 RBX: ffffffff9babcb00 RCX: 000000008dcbf47f
[    2.380246] RDX: 000000008e08fd75 RSI: 000000008dcbf47f RDI: 0000000000000000
[    2.380246] RBP: ffff8f996ddcf800 R08: 000000008dcbf8a5 R09: 00000049b4d1ac6b
[    2.380246] R10: ffff8f99708e95a0 R11: ffff8f99708e9580 R12: 0000000000000002
[    2.380247] R13: 000000008dcbf8a5 R14: 0000000000000002 R15: ffff8f996efe8000
[    2.380249]  ? cpuidle_enter_state+0x9f/0x450
[    2.380251]  cpuidle_enter+0x29/0x40
[    2.380253]  do_idle+0x1dc/0x270
[    2.380254]  cpu_startup_entry+0x19/0x20
[    2.380257]  start_secondary+0x15f/0x1b0
[    2.380259]  secondary_startup_64+0xa4/0xb0
[    2.380260] handlers:
[    2.380270] [<0000000027c08871>] amd_gpio_irq_handler
[    2.380283] Disabling IRQ #7
Comment 43 nospamming11+kernel 2019-11-06 16:08:59 UTC
(In reply to Shmerl from comment #42)
> I have a similar problem with Lenovo Thinkpad E495 (see below for dmesg
> snippet). This laptop doesn't even have a touchscreen display.
> 
> The error doesn't really cause any hangs or slowdown (I'm running 5.4-rc6),
> only that message in the log (shown during boot). Is there a way though to
> get rid of it without using Windows? I don't have access to Windows
> installation on this computer anymore.
> 
> Thanks!

Did you try to start your kernel with noirqdebug (as kernel option) which is a workaround for the issue with touchscreens
Comment 44 Shmerl 2019-11-11 16:30:12 UTC
(In reply to nospamming11+kernel from comment #43)
> 
> Did you try to start your kernel with noirqdebug (as kernel option) which is
> a workaround for the issue with touchscreens

Just tried it. With noirqdebug, the message doesn't pop up anymore during boot, but on next boot returns if I boot without noirqdebug, so it just masks the issue, rather than changing something permanently like in some examples above.
Comment 45 nospamming11+kernel 2019-11-11 17:08:29 UTC
(In reply to Shmerl from comment #44)
> (In reply to nospamming11+kernel from comment #43)
> > 
> > Did you try to start your kernel with noirqdebug (as kernel option) which
> is
> > a workaround for the issue with touchscreens
> 
> Just tried it. With noirqdebug, the message doesn't pop up anymore during
> boot, but on next boot returns if I boot without noirqdebug, so it just
> masks the issue, rather than changing something permanently like in some
> examples above.

For the touchscreen: with noirqdebug the touchscreen works without (and thus the appearing error) the touchscreen does not work. So it has to do more than just suppressing the error message in dmesg.
Comment 46 Fruhwirth Clemens 2019-12-17 09:10:33 UTC
Another data point when waking up from suspend for Thinkpad T495 on Ryzen 3700 which has an amdgpu:

[  373.071812] irq 7: nobody cared (try booting with the "irqpoll" option)
[  373.071822] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         5.5.0-rc2 #1-NixOS
[  373.071823] Hardware name: LENOVO 20NJCTO1WW/20NJCTO1WW, BIOS R12ET46W(1.16 ) 10/28/2019
[  373.071824] Call Trace:
[  373.071828]  <IRQ>
[  373.071837]  dump_stack+0x66/0x90
[  373.071842]  __report_bad_irq+0x37/0xb1
[  373.071846]  note_interrupt.cold.10+0xa/0x6d
[  373.071849]  handle_irq_event_percpu+0x6a/0x80
[  373.071852]  handle_irq_event+0x3c/0x5c
[  373.071855]  handle_fasteoi_irq+0xa3/0x150
[  373.071859]  do_IRQ+0x51/0xe0
[  373.071862]  common_interrupt+0xf/0xf
[  373.071863]  </IRQ>
[  373.071868] RIP: 0010:cpuidle_enter_state+0xbe/0x3f0
[  373.071872] Code: e8 27 c6 b3 ff 80 7c 24 13 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 d5 02 00 00 31 ff e8 f9 d3 b9 ff fb 66 0f 1f 44 00 00 <85> ed 0f 88 42 02 00 00 48 63 c5 4c 8b 3c 24 4c 2b 7c 24 08 48 8d
[  373.071873] RSP: 0018:ffffffff94203e48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffc8
[  373.071877] RAX: ffff98d838a2c300 RBX: ffff98d83677c000 RCX: 000000000000001f
[  373.071878] RDX: 00000056dccfecc1 RSI: 0000000037b5a6f8 RDI: 0000000000000000
[  373.071879] RBP: 0000000000000001 R08: 0000000000000002 R09: 000000000002bb80
[  373.071880] R10: 0000000285c499ea R11: ffff98d838a2b3e4 R12: ffffffff942b9da0
[  373.071881] R13: ffffffff942b9e20 R14: 0000000000000001 R15: 0000000000000001
[  373.071886]  ? cpuidle_enter_state+0x99/0x3f0
[  373.071889]  cpuidle_enter+0x29/0x40
[  373.071894]  do_idle+0x22b/0x260
[  373.071898]  cpu_startup_entry+0x19/0x20
[  373.071901]  start_kernel+0x4e2/0x504
[  373.071906]  secondary_startup_64+0xb6/0xc0
[  373.071908] handlers:
[  373.071916] [<0000000085173049>] amd_gpio_irq_handler [pinctrl_amd]
[  373.071918] Disabling IRQ #7
Comment 47 Alois Nespor 2020-01-07 15:22:26 UTC
i have same problem, HP desktop M01-F0xxx, Ryzen 5 3400G, no touchscreen:

[    5.799887] irq 7: nobody cared (try booting with the "irqpoll" option)
[    5.799890] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           OE     5.4.8-zen1-1-zen #1
[    5.799891] Hardware name: HP HP Desktop M01-F0xxx/8643, BIOS F.11 11/26/2019
[    5.799892] Call Trace:
[    5.799894]  <IRQ>
[    5.799898]  dump_stack+0x66/0x90
[    5.799901]  __report_bad_irq+0x35/0xaa
[    5.799902]  note_interrupt.cold+0xb/0x69
[    5.799903]  handle_irq_event+0xa9/0xb0
[    5.799904]  handle_fasteoi_irq+0xcc/0x1e0
[    5.799906]  do_IRQ+0x84/0x140
[    5.799907]  common_interrupt+0xf/0xf
[    5.799908]  </IRQ>
[    5.799910] RIP: 0010:cpuidle_enter_state+0xc4/0xa20
[    5.799911] Code: e8 41 cb 87 ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 06 09 00 00 31 ff e8 13 10 8f ff fb 66 0f 1f 44 00 00 <45> 85 e4 0f 88 86 02 00 00 49 63 cc 4c 2b 6c 24 10 48 8d 04 49 48
[    5.799912] RSP: 0018:ffffafbf40177e50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd9
[    5.799913] RAX: ffff936a509c0000 RBX: ffffffffbb4c1ba0 RCX: 000000000000001f
[    5.799913] RDX: 0000000000000000 RSI: 0000000022a8e515 RDI: 0000000000000000
[    5.799914] RBP: ffff936a481a9800 R08: 0000000159b326b3 R09: 00000001687d2800
[    5.799914] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000002
[    5.799915] R13: 0000000159b326b3 R14: 0000000000000002 R15: ffff936a4efe9e40
[    5.799917]  cpuidle_enter+0x29/0x40
[    5.799919]  do_idle+0x202/0x2b0
[    5.799920]  cpu_startup_entry+0x19/0x20
[    5.799922]  start_secondary+0x1c6/0x220
[    5.799923]  secondary_startup_64+0xb6/0xc0
[    5.799924] handlers:
[    5.799927] [<00000000abfe7a71>] amd_gpio_irq_handler [pinctrl_amd]
[    5.799928] Disabling IRQ #7

If i try  add irqpoll option for boot, my hpet will be broken: 
hpet: Lost 9601 RTC interrupts

Archlinux, kernel linux-zen 5.4.8-zen1,
Comment 48 Rui Ventura 2020-01-24 10:24:10 UTC
Ditto, Archlinux kernel 5.4.14-arch1-1, ThinkPad E595 Ryzen 3500U

[   11.749810] irq 7: nobody cared (try booting with the "irqpoll" option)
[   11.749814] CPU: 5 PID: 444 Comm: systemd-journal Not tainted 5.4.14-arch1-1 #1
[   11.749816] Hardware name: LENOVO 20NFCTO1WW/20NFCTO1WW, BIOS R11ET31W (1.11 ) 11/20/2019
[   11.749817] Call Trace:
[   11.749820]  <IRQ>
[   11.749827]  dump_stack+0x66/0x90
[   11.749831]  __report_bad_irq+0x35/0xaa
[   11.749834]  note_interrupt.cold+0xb/0x69
[   11.749836]  handle_irq_event_percpu+0x6f/0x80
[   11.749839]  handle_irq_event+0x37/0x54
[   11.749842]  handle_fasteoi_irq+0xb5/0x160
[   11.749845]  do_IRQ+0x84/0x140
[   11.749848]  common_interrupt+0xf/0xf
[   11.749849]  </IRQ>
[   11.749851] RIP: 0033:0x7f3e23058524
[   11.749854] Code: 48 89 ca 4c 89 c1 45 85 c9 41 0f 9f c0 48 85 f6 74 0e 45 0f b6 c0 47 8d 44 00 04 e9 16 a6 f6 ff 50 e8 a0 04 00 00 f3 0f 1e fa <48> 81 ec d8 00 00 00 41 89 d2 4c 89 c2 4c 89 4c 24 48 84 c0 74 >
[   11.749855] RSP: 002b:00007ffd0eedf6d8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffda
[   11.749858] RAX: 0000000000000000 RBX: 000000000000001a RCX: 0000000000000030
[   11.749859] RDX: 0000000000000001 RSI: 000000000000002c RDI: 00005637261d73f0
[   11.749860] RBP: 0000000000000000 R08: 00005637254a7008 R09: 000000000000004d
[   11.749861] R10: 0000000000000000 R11: 00007f3e2310ba40 R12: 0000000000000000
[   11.749861] R13: 00007ffd0eedfa40 R14: 00005637261d7360 R15: 00007ffd0eedfd28
[   11.749864] handlers:
[   11.749869] [<000000000dea8798>] amd_gpio_irq_handler [pinctrl_amd]
[   11.749870] Disabling IRQ #7
Comment 49 JerryD 2020-03-06 17:18:35 UTC
ditto 5.6.0-0.rc3.git0.1.fc32.x86_64

This went away for a while and then the 5.5 kernels started showing it again for me.

The irq 7: nobody cared statement is quite true. I have no touchscreen function now either.
Comment 50 YinH 2020-03-11 00:25:01 UTC
Hi There!

Just to advise those that were having this issue with Lenovo ThinkPads, my
T495 () in particular had this IRQ#7 issue with 5.5.7-200.fc31.x86_64 and lower.

I updated the BIOS version to 1.19 (for T495) and the issue appears to have now
gone away. I'll continue to observe and report back if the problem returns.

This update also fixed Linux not being able to see the Battery's status (unsure if related to IRQ#7)

Thankfully, Lenovo are releasing stand-alone .ISOs for BIOS updating, just make
sure to disable Secure Boot before booting into it off a USB.

Just quickly checking some of the E series Ryzen ThinkPads they've also had
a BIOS update in the last week or so.

I hope other hardware vendors have released, or will release a fix for this! I'm wondering if AMD have pushed some newer byte-code for these chips?

Cheers,
Comment 51 philipp_023 2020-03-11 16:28:54 UTC
Hi,
For me this issue is still present, even there is not much impact as far as I know.

Machine:
Lenovo ThinkPad E495, model 20NECTO1WW, ThinkPad BIOS R11ET35W (1.15 ), EC R11HT35W

OS:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=19.10
DISTRIB_CODENAME=eoan

Kernel:
Linux e495 5.5.8-050508-generic #202003051633 SMP Thu Mar 5 16:37:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Exception:
[Wed Mar 11 08:39:44 2020] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET35W (1.15 ) 02/19/2020
[Wed Mar 11 08:39:44 2020] Call Trace:
[Wed Mar 11 08:39:44 2020]  <IRQ>
[Wed Mar 11 08:39:44 2020]  dump_stack+0x6d/0x9a
[Wed Mar 11 08:39:44 2020]  __report_bad_irq+0x3a/0xaf
[Wed Mar 11 08:39:44 2020]  note_interrupt.cold+0xb/0x61
[Wed Mar 11 08:39:44 2020]  handle_irq_event_percpu+0x73/0x80
[Wed Mar 11 08:39:44 2020]  handle_irq_event+0x3b/0x5a
[Wed Mar 11 08:39:44 2020]  handle_fasteoi_irq+0x9c/0x150
[Wed Mar 11 08:39:44 2020]  do_IRQ+0x55/0xf0
[Wed Mar 11 08:39:44 2020]  common_interrupt+0xf/0xf
[Wed Mar 11 08:39:44 2020]  </IRQ>
[Wed Mar 11 08:39:44 2020] RIP: 0010:__call_rcu+0xd3/0x1d0
[Wed Mar 11 08:39:44 2020] Code: 0f a3 05 e0 5b 72 01 73 1c 49 8b 94 24 98 00 00 00 48 8b 05 1f ab 54 01 49 03 84 24 b0 00 00 00 48 39 c2 7f 77 4c 89 ef 57 9d <0f> 1f 44 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 d4
[Wed Mar 11 08:39:44 2020] RSP: 0018:ffffa8f2405f7e08 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
[Wed Mar 11 08:39:44 2020] RAX: 0000000000002710 RBX: 000000000002df00 RCX: ffffffffa3ae5b90
[Wed Mar 11 08:39:44 2020] RDX: 0000000000000014 RSI: ffff91bb81d92e00 RDI: 0000000000000246
[Wed Mar 11 08:39:44 2020] RBP: ffffa8f2405f7e40 R08: ffff91bb8d5d3a40 R09: 0000000000000064
[Wed Mar 11 08:39:44 2020] R10: 0000000040000010 R11: ffff91bb8d009068 R12: ffff91bb8f2edf00
[Wed Mar 11 08:39:44 2020] R13: 0000000000000246 R14: ffff91bb8f2edf50 R15: ffff91bb81d92e00
[Wed Mar 11 08:39:44 2020]  ? get_max_files+0x20/0x20
[Wed Mar 11 08:39:44 2020]  ? get_max_files+0x20/0x20
[Wed Mar 11 08:39:44 2020]  call_rcu+0x10/0x20
[Wed Mar 11 08:39:44 2020]  __fput+0x150/0x260
[Wed Mar 11 08:39:44 2020]  ____fput+0xe/0x10
[Wed Mar 11 08:39:44 2020]  task_work_run+0x8f/0xb0
[Wed Mar 11 08:39:44 2020]  exit_to_usermode_loop+0x131/0x160
[Wed Mar 11 08:39:44 2020]  do_syscall_64+0x170/0x1b0
[Wed Mar 11 08:39:44 2020]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[Wed Mar 11 08:39:44 2020] RIP: 0033:0x7f2302ff1ab7
[Wed Mar 11 08:39:44 2020] Code: ff ff e8 3c 13 02 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 33 5e f8 ff
[Wed Mar 11 08:39:44 2020] RSP: 002b:00007ffdf4a630e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[Wed Mar 11 08:39:44 2020] RAX: 0000000000000000 RBX: 00007f2302a887a0 RCX: 00007f2302ff1ab7
[Wed Mar 11 08:39:44 2020] RDX: 00007ffdf4a63150 RSI: 00007ffdf4a63150 RDI: 0000000000000000
[Wed Mar 11 08:39:44 2020] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000562965a2f720
[Wed Mar 11 08:39:44 2020] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[Wed Mar 11 08:39:44 2020] R13: 0000000000000005 R14: 00007ffdf4a63238 R15: 0000000000000005
[Wed Mar 11 08:39:44 2020] handlers:
[Wed Mar 11 08:39:44 2020] [<000000003328b550>] amd_gpio_irq_handler
[Wed Mar 11 08:39:44 2020] Disabling IRQ #7

Philipp
Comment 52 Thomas Gleixner 2020-03-11 21:22:04 UTC
Phillip,

bugzilla-daemon@bugzilla.kernel.org writes:
> Kernel:
> Linux e495 5.5.8-050508-generic #202003051633 SMP Thu Mar 5 16:37:27 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>
> Exception:
> [Wed Mar 11 08:39:44 2020] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS
> R11ET35W (1.15 ) 02/19/2020
> [Wed Mar 11 08:39:44 2020] handlers:
> [Wed Mar 11 08:39:44 2020] [<000000003328b550>] amd_gpio_irq_handler
> [Wed Mar 11 08:39:44 2020] Disabling IRQ #7

Can you please enable CONFIG_DEBUG_FS and provide the output of

    cat /sys/kernel/debug/gpio

Thanks,

        tglx
Comment 53 Alois Nespor 2020-03-11 21:34:19 UTC
(In reply to Alois Nespor from comment #47)
> i have same problem, HP desktop M01-F0xxx, Ryzen 5 3400G, no touchscreen:
> 
> [    5.799887] irq 7: nobody cared (try booting with the "irqpoll" option)
> [    5.799890] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           OE    
> 5.4.8-zen1-1-zen #1
> [    5.799891] Hardware name: HP HP Desktop M01-F0xxx/8643, BIOS F.11
> 11/26/2019
> [    5.799892] Call Trace:
> [    5.799894]  <IRQ>
> [    5.799898]  dump_stack+0x66/0x90
> [    5.799901]  __report_bad_irq+0x35/0xaa
> [    5.799902]  note_interrupt.cold+0xb/0x69
> [    5.799903]  handle_irq_event+0xa9/0xb0
> [    5.799904]  handle_fasteoi_irq+0xcc/0x1e0
> [    5.799906]  do_IRQ+0x84/0x140
> [    5.799907]  common_interrupt+0xf/0xf
> [    5.799908]  </IRQ>
> [    5.799910] RIP: 0010:cpuidle_enter_state+0xc4/0xa20
> [    5.799911] Code: e8 41 cb 87 ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00
> 00 f6 c4 02 0f 85 06 09 00 00 31 ff e8 13 10 8f ff fb 66 0f 1f 44 00 00 <45>
> 85 e4 0f 88 86 02 00 00 49 63 cc 4c 2b 6c 24 10 48 8d 04 49 48
> [    5.799912] RSP: 0018:ffffafbf40177e50 EFLAGS: 00000246 ORIG_RAX:
> ffffffffffffffd9
> [    5.799913] RAX: ffff936a509c0000 RBX: ffffffffbb4c1ba0 RCX:
> 000000000000001f
> [    5.799913] RDX: 0000000000000000 RSI: 0000000022a8e515 RDI:
> 0000000000000000
> [    5.799914] RBP: ffff936a481a9800 R08: 0000000159b326b3 R09:
> 00000001687d2800
> [    5.799914] R10: 0000000000000008 R11: 0000000000000008 R12:
> 0000000000000002
> [    5.799915] R13: 0000000159b326b3 R14: 0000000000000002 R15:
> ffff936a4efe9e40
> [    5.799917]  cpuidle_enter+0x29/0x40
> [    5.799919]  do_idle+0x202/0x2b0
> [    5.799920]  cpu_startup_entry+0x19/0x20
> [    5.799922]  start_secondary+0x1c6/0x220
> [    5.799923]  secondary_startup_64+0xb6/0xc0
> [    5.799924] handlers:
> [    5.799927] [<00000000abfe7a71>] amd_gpio_irq_handler [pinctrl_amd]
> [    5.799928] Disabling IRQ #7
> 
> If i try  add irqpoll option for boot, my hpet will be broken: 
> hpet: Lost 9601 RTC interrupts
> 
> Archlinux, kernel linux-zen 5.4.8-zen1,


@Thomas Gleixner,

if you help my output of 'cat /sys/kernel/debug/gpio', linux-zen 5.5.8, please see gpio.txt
Comment 54 Alois Nespor 2020-03-11 21:35:16 UTC
Created attachment 287877 [details]
cat /sys/kernel/debug/gpio - linux-zen 5.5.8
Comment 55 Jose Silva 2020-03-12 00:25:13 UTC
Issue still persists in my Lenovo ThinkPad E595, BIOS (1.15).


Attached my /sys/kernel/debug/gpio, will run again with CONFIG_DEBUG_FS on tomorrow.

Kernel 5.5.8-arch1-1.
Comment 56 Jose Silva 2020-03-12 00:27:32 UTC
Created attachment 287879 [details]
cat /sys/kernel/gpio result
Comment 57 philipp_023 2020-03-12 08:09:26 UTC
Created attachment 287883 [details]
cat /sys/kernel/debug/gpio

Output of cat /sys/kernel/debug/gpio

Machine:
Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET35W (1.15 ) 02/19/2020

OS:
Ubuntu 19.10

Kernel: 
Linux e495 5.5.8-050508-generic #202003051633 SMP Thu Mar 5 16:37:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Comment 58 Thomas Gleixner 2020-03-12 15:32:46 UTC
bugzilla-daemon@bugzilla.kernel.org writes:

Thanks for the files!

This starts to be really puzzling.

The files from Alois and Phillip have dozens of interrupts enabled, but
ALL of them are masked which means they cannot raise an interupt unless
the masking is broken.

Joses file has not a single interrupt line enabled which means that the
interrupt fires for completely different reasons.

I'm trying to get some more detailed information about the inner working
of these chips. Will take a while.

Thanks,

        tglx
Comment 59 Neil 2020-03-27 20:54:46 UTC
Similar issue.  Fedora 31, Linux version 5.5.11.  Thinkpad E495.

[    5.809023] irq 7: nobody cared (try booting with the "irqpoll" option)
[    5.809027] CPU: 4 PID: 31 Comm: ksoftirqd/4 Not tainted 5.5.11-200.fc31.x86_64 #1
[    5.809028] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET35W (1.15 ) 02/19/2020
[    5.809029] Call Trace:
[    5.809033]  <IRQ>
[    5.809044]  dump_stack+0x66/0x90
[    5.809051]  __report_bad_irq+0x35/0xa7
[    5.809053]  note_interrupt.cold+0xb/0x63
[    5.809056]  handle_irq_event_percpu+0x6f/0x80
[    5.809058]  handle_irq_event+0x36/0x53
[    5.809060]  handle_fasteoi_irq+0x8b/0x130
[    5.809063]  do_IRQ+0x50/0xe0
[    5.809067]  common_interrupt+0xf/0xf
[    5.809069]  </IRQ>
[    5.809072] RIP: 0010:finish_task_switch+0x80/0x2a0
[    5.809074] Code: 8b 1c 25 c0 8b 01 00 0f 1f 44 00 00 0f 1f 44 00 00 41 c7 45 38 00 00 00 00 4c 89 e7 c6 07 00 0f 1f 40 00 fb 66 0f 1f 44 00 00 <65> 48 8b 04 25 c0 8b 01 00 0f 1f 44 00 00 4d 85 f6 74 21 65 48 8b
[    5.809076] RSP: 0018:ffffbb45c025be40 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
[    5.809078] RAX: ffff9efd68482680 RBX: ffff9efd7260a680 RCX: 0000000000000000
[    5.809079] RDX: 0000000002068000 RSI: 0000000000000000 RDI: ffff9efd74b2ae00
[    5.809080] RBP: ffffbb45c025be68 R08: ffff9efd68482730 R09: ffff9efd68482730
[    5.809080] R10: 00000000000000bb R11: ffff9efd74b2aeb8 R12: ffff9efd74b2ae00
[    5.809081] R13: ffff9efd68482680 R14: 0000000000000000 R15: 0000000000000000
[    5.809087]  __schedule+0x2cf/0x740
[    5.809089]  schedule+0x4a/0xb0
[    5.809093]  smpboot_thread_fn+0x10b/0x160
[    5.809097]  kthread+0xf9/0x130
[    5.809099]  ? sort_range+0x20/0x20
[    5.809100]  ? kthread_park+0x90/0x90
[    5.809102]  ret_from_fork+0x22/0x40
[    5.809104] handlers:
[    5.809109] [<00000000463020c1>] amd_gpio_irq_handler [pinctrl_amd]
[    5.809110] Disabling IRQ #7
Comment 60 Neil 2020-03-27 21:10:14 UTC
Created attachment 288097 [details]
cat /sys/kernel/debug/gpio.  Cuz why not
Comment 61 damkrat 2020-04-21 20:03:16 UTC
Here the same problem with IRQ 7 on Lenovo E495 with BIOS 1.15; running CentOS 8 Stream, Linux 5.6.3-1.el8.elrepo.x86_64. 

Enabling noapic kernel option will let the "IRQ 7" warning disappear.

I haven't noticed any issues with system, seems to run same as without this tweak.
Comment 62 Jan Sordid 2020-05-03 12:28:29 UTC
To all here who also have an E495, BIOS 1.15 was removed from Lenovo's pages some time ago, but there is now a newer 1.16 available.
https://pcsupport.lenovo.com/us/de/products/laptops-and-netbooks/thinkpad-edge-laptops/thinkpad-e495-type-20ne/downloads/DS539418
If someone feels like trying this one out, please ping me if you had success.

I'm still on BIOS 1.10 for now, since I have no real problems and the laptop really needs to continue working until I finished my thesis ;)

Just for reference
- E495 with BIOS 1.10
- IRQ 7 nobody cared
- Never booted a Windows, only Linux (Xubuntu 19.10)
- Kernel 5.3.0-51-generic #44-Ubuntu SMP
Comment 63 Neil 2020-05-03 18:05:34 UTC
(In reply to Jan Sordid from comment #62)
> If someone feels like trying this one out, please ping me if you had success.

[    4.985889] irq 7: nobody cared (try booting with the "irqpoll" option)
[    4.985894] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.6.8-200.fc31.x86_64 #1
[    4.985895] Hardware name: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET36W (1.16 ) 03/30/2020
[    4.985896] Call Trace:
[    4.985900]  <IRQ>
[    4.985911]  dump_stack+0x66/0x90
[    4.985917]  __report_bad_irq+0x35/0xa7
[    4.985920]  note_interrupt.cold+0xb/0x63
[    4.985923]  handle_irq_event_percpu+0x4f/0x60
[    4.985925]  handle_irq_event+0x36/0x53
[    4.985927]  handle_fasteoi_irq+0x8b/0x130
[    4.985931]  do_IRQ+0x50/0xe0
[    4.985934]  common_interrupt+0xf/0xf
[    4.985935]  </IRQ>
[    4.985941] RIP: 0010:cpuidle_enter_state+0xc9/0x3e0
[    4.985943] Code: e8 3c 2d 91 ff 80 7c 24 0f 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 ea 02 00 00 31 ff e8 3e 5f 97 ff fb 66 0f 1f 44 00 00 <45> 85 ed 0f 88 40 02 00 00 49 63 d5 4c 2b 64 24 10 48 8d 04 52 48
[    4.985944] RSP: 0018:ffffad9c4015fe78 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdb
[    4.985947] RAX: ffff9258f4b2ae80 RBX: ffff9258ea173400 RCX: 00000001292e3489
[    4.985948] RDX: 00000001293d76b5 RSI: 00000001292e3489 RDI: 0000000000000000
[    4.985949] RBP: ffffffff90769f40 R08: 00000001292e349d R09: 000000007fffffff
[    4.985950] R10: 0000000000000001 R11: ffff9258f4b29ca4 R12: 00000001292e349d
[    4.985950] R13: 0000000000000002 R14: 0000000000000002 R15: ffff9258f2ff0000
[    4.985955]  ? cpuidle_enter_state+0xa4/0x3e0
[    4.985957]  cpuidle_enter+0x29/0x40
[    4.985961]  do_idle+0x1c0/0x260
[    4.985964]  cpu_startup_entry+0x19/0x20
[    4.985967]  start_secondary+0x152/0x190
[    4.985972]  secondary_startup_64+0xb6/0xc0
[    4.985974] handlers:
[    4.985979] [<00000000cf504361>] amd_gpio_irq_handler [pinctrl_amd]
[    4.985980] Disabling IRQ #7



Nothing new.
Comment 64 albertogomezmarin 2020-05-21 23:55:44 UTC
I have this problem too in a lenovo thinkpad E595 with Linux 5.6 from manjaro and arch kernels. It appear that not generate any problem at all.. but I dont know well
Comment 65 albertogomezmarin 2020-05-21 23:57:01 UTC
Created attachment 289205 [details]
dmseg with linux 5.6ck

Note You need to log in before you can comment on or make changes to this bug.