Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #247562 > unrolled thread

"Disabling IRQ #9" - how to check for impact

Started byChristian Britz <cbritz@t-online.de>
First post2022-04-26 09:30 +0200
Last post2022-05-03 09:40 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.debian.user


Contents

  "Disabling IRQ #9" - how to check for impact Christian Britz <cbritz@t-online.de> - 2022-04-26 09:30 +0200
    Re: "Disabling IRQ #9" - how to check for impact IL Ka <kazakevichilya@gmail.com> - 2022-04-28 03:00 +0200
      Re: "Disabling IRQ #9" - how to check for impact Christian Britz <cbritz@t-online.de> - 2022-04-28 10:40 +0200
        Re: "Disabling IRQ #9" - how to check for impact Christian Britz <cbritz@t-online.de> - 2022-05-03 09:40 +0200

#247562 — "Disabling IRQ #9" - how to check for impact

FromChristian Britz <cbritz@t-online.de>
Date2022-04-26 09:30 +0200
Subject"Disabling IRQ #9" - how to check for impact
Message-ID<EgnO1-bgYt-3@gated-at.bofh.it>
Hello Debianists,

some days ago I updated the BIOS of my Lenovo IdeaPad S145-15IIL (had to
boot a certain proprietary OS for this). I think since then there is a
new error in the kernel log. I never noticed it before.

[    9.967601] irq 9: nobody cared (try booting with the "irqpoll" option)
[    9.967607] CPU: 1 PID: 981 Comm: sddm-greeter Tainted: G
OE     5.10.0-13-amd64 #1 Debian 5.10.106-1
[    9.967608] Hardware name: LENOVO 81W8/LNVNB161216, BIOS DKCN54WW
01/27/2022
[    9.967608] Call Trace:
[    9.967615]  dump_stack+0x6b/0x83
[...]
[    9.967636] handlers:
[    9.967639] [<00000000872fa119>] acpi_irq
[    9.967640] Disabling IRQ #9

This IRQ seems to be related to ACPI on this machine. I am unsure, what
exactly gets diabled and what might be the impact. So far I notice no
problems with performance or overheating, compiling a small tool went as
always I would say.

Do you have any hints for me about what I should/could check?

Regards,
Christian

-- 
http://www.cb-fraggle.de

[toc] | [next] | [standalone]


#247682

FromIL Ka <kazakevichilya@gmail.com>
Date2022-04-28 03:00 +0200
Message-ID<Eh0FH-bEMS-3@gated-at.bofh.it>
In reply to#247562

[Multipart message — attachments visible in raw view] — view raw

Hi.

Short answer:
This is a known kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=207749

Long answer:
This message means some hardware generates an interrupt request, but the
interrupt handler (kernel driver) failed to process it.
See:
https://stackoverflow.com/questions/13861282/understanding-kernel-message-nobody-cared-try-booting-with-the-irqpoll-optio

As we see from stacktrace, this handler is "acpi_irq" (you can also check
it by reading /proc/interrupts):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-interrupts

Many hardware things in laptops use ACPI: Brightness buttons, FN buttons,
volume buttons, lid etc.

It seems that your latest firmware (or BIOS as you called it) is
incompatible with your kernel (either kernel or firmware should be fixed)

This situation is common with Lenovo hardware:
https://support.lenovo.com/at/en/solutions/ht505228
https://bugzilla.kernel.org/show_bug.cgi?id=207749 (I suggest you to write
to this issue and to follow it)
https://www.reddit.com/r/linuxquestions/comments/jhxlia/rip_acpi_irq_disabling_irq_9_any_way_to_figure/

If everything works as expected (you see no problem with lid, buttons etc)
simply ignore it.
If no, try to install the latest kernel and file a bug to Debian (I think
it should be forwarded upstream and handled by the kernel developer,
probably duplicating 207749
<https://bugzilla.kernel.org/show_bug.cgi?id=207749>).

You can also add "irqpoll" kernel param which will ask the kernel to check
all IRQ handlers to find the one which can process it, but I am 99% sure
this wouldn't help since
we know it should be processed by ACPI.
https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re17.html




On Tue, Apr 26, 2022 at 10:21 AM Christian Britz <cbritz@t-online.de> wrote:

> Hello Debianists,
>
> some days ago I updated the BIOS of my Lenovo IdeaPad S145-15IIL (had to
> boot a certain proprietary OS for this). I think since then there is a
> new error in the kernel log. I never noticed it before.
>
> [    9.967601] irq 9: nobody cared (try booting with the "irqpoll" option)
> [    9.967607] CPU: 1 PID: 981 Comm: sddm-greeter Tainted: G
> OE     5.10.0-13-amd64 #1 Debian 5.10.106-1
> [    9.967608] Hardware name: LENOVO 81W8/LNVNB161216, BIOS DKCN54WW
> 01/27/2022
> [    9.967608] Call Trace:
> [    9.967615]  dump_stack+0x6b/0x83
> [...]
> [    9.967636] handlers:
> [    9.967639] [<00000000872fa119>] acpi_irq
> [    9.967640] Disabling IRQ #9
>
> This IRQ seems to be related to ACPI on this machine. I am unsure, what
> exactly gets diabled and what might be the impact. So far I notice no
> problems with performance or overheating, compiling a small tool went as
> always I would say.
>
> Do you have any hints for me about what I should/could check?
>
> Regards,
> Christian
>
> --
> http://www.cb-fraggle.de
>
>

[toc] | [prev] | [next] | [standalone]


#247688

FromChristian Britz <cbritz@t-online.de>
Date2022-04-28 10:40 +0200
Message-ID<Eh7QR-bJNA-3@gated-at.bofh.it>
In reply to#247682
Hello Ilya,

thank you for sharing so many interesting details!

On 2022-04-28 02:53 UTC+0200, IL Ka wrote:

> This is a known kernel
> bug: https://bugzilla.kernel.org/show_bug.cgi?id=207749
> <https://bugzilla.kernel.org/show_bug.cgi?id=207749> 

I was almost sure the messages first appeared after the firmware update,
but the kernel bug is much older. I will definitely follow this thread.

> As we see from stacktrace, this handler is "acpi_irq" (you can also
> check it by reading /proc/interrupts):

There is a high number on CPU1:

   9:          0  819113116          0          0          0          0
         0          0  IR-IO-APIC    9-fasteoi   acpi

Should I be worried about that?

> Many hardware things in laptops use ACPI: Brightness buttons, FN
> buttons, volume buttons, lid etc.

They seem to work.
> If everything works as expected (you see no problem with lid, buttons
> etc) simply ignore it.

It seems so.

> If no, try to install the latest kernel and file a bug to Debian (I

Latest kernel from backports did not help.

> You can also add "irqpoll" kernel param which will ask the kernel to

I think I have read somewhere that this can make the machine very slow.

So far I notice no impact of the bug, luckily. I guess I will live with
it and hope for a fix in a kernel of a later Debian release.

Best Regards,
Christian

-- 
http://www.cb-fraggle.de

[toc] | [prev] | [next] | [standalone]


#247838

FromChristian Britz <cbritz@t-online.de>
Date2022-05-03 09:40 +0200
Message-ID<EiVix-cSng-5@gated-at.bofh.it>
In reply to#247688
Problem seems to be gone with latest Debian stable kernel update! I
don't see the message anymore with 5.10.113.

On 2022-04-28 10:34 UTC+0200, Christian Britz wrote:
> Hello Ilya,
> 
> thank you for sharing so many interesting details!
> 
> On 2022-04-28 02:53 UTC+0200, IL Ka wrote:
> 
>> This is a known kernel
>> bug: https://bugzilla.kernel.org/show_bug.cgi?id=207749
>> <https://bugzilla.kernel.org/show_bug.cgi?id=207749> 
> 
> I was almost sure the messages first appeared after the firmware update,
> but the kernel bug is much older. I will definitely follow this thread.
> 
>> As we see from stacktrace, this handler is "acpi_irq" (you can also
>> check it by reading /proc/interrupts):
> 
> There is a high number on CPU1:
> 
>    9:          0  819113116          0          0          0          0
>          0          0  IR-IO-APIC    9-fasteoi   acpi
> 
> Should I be worried about that?
> 
>> Many hardware things in laptops use ACPI: Brightness buttons, FN
>> buttons, volume buttons, lid etc.
> 
> They seem to work.
>> If everything works as expected (you see no problem with lid, buttons
>> etc) simply ignore it.
> 
> It seems so.
> 
>> If no, try to install the latest kernel and file a bug to Debian (I
> 
> Latest kernel from backports did not help.
> 
>> You can also add "irqpoll" kernel param which will ask the kernel to
> 
> I think I have read somewhere that this can make the machine very slow.
> 
> So far I notice no impact of the bug, luckily. I guess I will live with
> it and hope for a fix in a kernel of a later Debian release.
> 
> Best Regards,
> Christian
> 

-- 
http://www.cb-fraggle.de

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web