Bug 1551605

Can you do a kernel bisect? That's going to be the best way to figure out which commit broke things.

(In reply to Laura Abbott from comment #1)
> Can you do a kernel bisect? That's going to be the best way to figure out
> which commit broke things.

Sorry, I use only precompiled packaged kernels.

I found this in linux-4.15/arch/x86/kernel/irq.c

pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n",                                                                           
                                             __func__, smp_processor_id(),      
                                             vector);

No sure, what this pr_emerg is, but should this be too verbose? May be we need to make this message quiet for most reasons.

As for kern_levels.h, there is:

KERN_EMERG - system is unusable

My system works well, just need to hide this message. Please change this to WARNING or something, what is not displayed in rsyslog. This is how it looks for logged user:

Message from syslogd@work at Mar 21 18:05:02 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@work at Mar 21 18:06:01 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@work at Mar 21 18:06:22 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@work at Mar 21 18:07:01 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@work at Mar 21 18:09:01 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@work at Mar 21 18:09:21 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

In my case I always see this log in a old-style terminal for some seconds after I boot the computer from suspend, before the GNOME lock screen appears.

+1 for a "me too":

do_IRQ: 0.55 No irq handler for vector

Message is visible during boot, when all I used to see, and should be seeing, is the funky fedora graphical boot logo filling up, which eventually appears after this message.

Only started happening recently, after 4.15.x kernel update(s). Additionally, and perhaps unrelated, the system no longer successfully powers itself off after shutting down. I now have to do this manually after waiting for an extended period of time.

After a search, the only relevant infos I found were:

https://lkml.org/lkml/2017/12/6/280 and

https://www.reddit.com/r/archlinux/comments/7wvapc/big_thread_of_linux_415_problems/

LMK if further information is needed.

This is happening for me as well, but only on a single desktop system after the latest update.

May 05 00:03:44 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 05 00:03:27 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 05 00:02:05 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 05 00:00:26 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 04 23:59:36 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 04 23:58:30 vm-host kernel: do_IRQ: 2.33 No irq handler for vector
May 04 23:57:57 vm-host kernel: do_IRQ: 2.33 No irq handler for vector

Message from syslogd@xxxx at Jun  7 11:20:29 ...
 kernel:do_IRQ: 1.34 No irq handler for vector

Message from syslogd@xxxx at Jun  7 11:20:45 ...
 kernel:do_IRQ: 1.34 No irq handler for vector

Message from syslogd@xxxx at Jun  7 11:21:02 ...
 kernel:do_IRQ: 1.34 No irq handler for vector

Message from syslogd@xxxx at Jun  7 11:21:35 ...
 kernel:do_IRQ: 1.34 No irq handler for vector

$ uname -a
Linux xxxx.yyyy.com 4.16.13-300.fc28.x86_64 #1 SMP Wed May 30 14:31:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


This shows up on each ssh login, but not on local terminal windows.

This is essentially disabling ssh access to the machine.

Tried a 10 year old VTd setting magic in ASUS BIOS, but no effect.

As a work-around, I created /etc/rsyslog.d/do_IRQ.conf with the following one line:

:msg, contains, "No irq handler for vector" stop

Then, the annoying periodic messages have stopped.

Is this a right solution?

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

On kernel 4.17.7-200.fc28.x86_64 messages are still present, but not displayed on ssh console. Looks like problem was fixed.

I don't use Fedora 27 anymore, so I can't test it.

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.18.10-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 28 or Fedora 29, and are still experiencing this issue, please change the version to Fedora 28 or 29.
 
If you experience different issues, please open a new bug report for those.

As I already said, I moved to Fedora 28, messages are still present with 4.18.10-200.fc28.x86_64, but do not disturb on console. Closing this bug.
If anyone else sill experiencing problems, feel free to reopen it.

Experiencing on FC29 with kernel 4.18.16-300

do_IRQ: 0.35 No irq handler for vector seen in the systemd journal.

Would someone on the cc list with access please update Version to FC29 and reopen?

Not sure what all needs to be captured so here's some kernel output before and after the error...

Feb 07 20:14:29 localhost.localdomain kernel: smpboot: CPU0: AMD A8-6410 APU with AMD Radeon R5 Graphics (family: 0x16, model: 0x30, stepping: 0x1)
Feb 07 20:14:29 localhost.localdomain kernel: Performance Events: AMD PMU driver.
Feb 07 20:14:29 localhost.localdomain kernel: ... version:                0
Feb 07 20:14:29 localhost.localdomain kernel: ... bit width:              48
Feb 07 20:14:29 localhost.localdomain kernel: ... generic registers:      4
Feb 07 20:14:29 localhost.localdomain kernel: ... value mask:             0000ffffffffffff
Feb 07 20:14:29 localhost.localdomain kernel: ... max period:             00007fffffffffff
Feb 07 20:14:29 localhost.localdomain kernel: ... fixed-purpose events:   0
Feb 07 20:14:29 localhost.localdomain kernel: ... event mask:             000000000000000f
Feb 07 20:14:29 localhost.localdomain kernel: rcu: Hierarchical SRCU implementation.
Feb 07 20:14:29 localhost.localdomain kernel: random: crng done (trusting CPU's manufacturer)
Feb 07 20:14:29 localhost.localdomain kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
Feb 07 20:14:29 localhost.localdomain kernel: smp: Bringing up secondary CPUs ...
Feb 07 20:14:29 localhost.localdomain kernel: x86: Booting SMP configuration:
Feb 07 20:14:29 localhost.localdomain kernel: .... node  #0, CPUs:      #1
Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 1.55 No irq handler for vector
Feb 07 20:14:29 localhost.localdomain kernel:  #2
Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 2.55 No irq handler for vector
Feb 07 20:14:29 localhost.localdomain kernel:  #3
Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 3.55 No irq handler for vector
Feb 07 20:14:29 localhost.localdomain kernel: smp: Brought up 1 node, 4 CPUs
Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Max logical packages: 1
Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Total of 4 processors activated (15968.49 BogoMIPS)

Hi Richard,

(In reply to Richard Shaw from comment #14)
> Not sure what all needs to be captured so here's some kernel output before
> and after the error...
> 
> Feb 07 20:14:29 localhost.localdomain kernel: smpboot: CPU0: AMD A8-6410 APU
> with AMD Radeon R5 Graphics (family: 0x16, model: 0x30, stepping: 0x1)
> Feb 07 20:14:29 localhost.localdomain kernel: Performance Events: AMD PMU
> driver.
> Feb 07 20:14:29 localhost.localdomain kernel: ... version:                0
> Feb 07 20:14:29 localhost.localdomain kernel: ... bit width:              48
> Feb 07 20:14:29 localhost.localdomain kernel: ... generic registers:      4
> Feb 07 20:14:29 localhost.localdomain kernel: ... value mask:            
> 0000ffffffffffff
> Feb 07 20:14:29 localhost.localdomain kernel: ... max period:            
> 00007fffffffffff
> Feb 07 20:14:29 localhost.localdomain kernel: ... fixed-purpose events:   0
> Feb 07 20:14:29 localhost.localdomain kernel: ... event mask:            
> 000000000000000f
> Feb 07 20:14:29 localhost.localdomain kernel: rcu: Hierarchical SRCU
> implementation.
> Feb 07 20:14:29 localhost.localdomain kernel: random: crng done (trusting
> CPU's manufacturer)
> Feb 07 20:14:29 localhost.localdomain kernel: NMI watchdog: Enabled.
> Permanently consumes one hw-PMU counter.
> Feb 07 20:14:29 localhost.localdomain kernel: smp: Bringing up secondary
> CPUs ...
> Feb 07 20:14:29 localhost.localdomain kernel: x86: Booting SMP configuration:
> Feb 07 20:14:29 localhost.localdomain kernel: .... node  #0, CPUs:      #1
> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 1.55 No irq handler
> for vector
> Feb 07 20:14:29 localhost.localdomain kernel:  #2
> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 2.55 No irq handler
> for vector
> Feb 07 20:14:29 localhost.localdomain kernel:  #3
> Feb 07 20:14:29 localhost.localdomain kernel: do_IRQ: 3.55 No irq handler
> for vector
> Feb 07 20:14:29 localhost.localdomain kernel: smp: Brought up 1 node, 4 CPUs
> Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Max logical packages:
> 1
> Feb 07 20:14:29 localhost.localdomain kernel: smpboot: Total of 4 processors
> activated (15968.49 BogoMIPS)

On which model hardware is this ? Can you attach full dmesg output please?

Regards,

Hans

Sure, I can get that when I get home. It's an Acer AMD A8 based system.

Created attachment 1541116 [details]
requested dmesg file

Here is my dmesg. My computer is an Intel machine.

Created attachment 1541467 [details]
dmesg from HP 15-g023cl

It was my HP not my Acer (model number in attachment description)

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.
 
Fedora XX has now been rebased to 5.0.6  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30.
 
If you experience different issues, please open a new bug report for those.

Yes, still problem with 5.0.5 kernel:

[84521.724338] do_IRQ: 3.33 No irq handler for vector                          
[84581.645211] do_IRQ: 3.33 No irq handler for vector                          
[84641.781062] do_IRQ: 3.33 No irq handler for vector                          
[84701.982917] do_IRQ: 3.33 No irq handler for vector                          
[84722.846214] do_IRQ: 3.33 No irq handler for vector                          
[84821.741621] do_IRQ: 3.33 No irq handler for vector                          
[84881.629474] do_IRQ: 3.33 No irq handler for vector                          
[85001.428179] do_IRQ: 3.33 No irq handler for vector                          
[85061.330028] do_IRQ: 3.33 No irq handler for vector                          
[85181.131747] do_IRQ: 3.33 No irq handler for vector                          
[85242.004572] do_IRQ: 3.33 No irq handler for vector                          
[85301.928450] do_IRQ: 3.33 No irq handler for vector                          
[85421.708154] do_IRQ: 3.33 No irq handler for vector                          
[85442.860453] do_IRQ: 3.33 No irq handler for vector                          
[85481.607003] do_IRQ: 3.33 No irq handler for vector                          
[85541.490857] do_IRQ: 3.33 No irq handler for vector                          
[85622.605009] do_IRQ: 3.33 No irq handler for vector                          
[ondrejj@work ~]$ uname -a
Linux work.salstar.sk 5.0.5-200.fc29.x86_64 #1 SMP Wed Mar 27 20:58:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[ondrejj@work ~]$ uptime
 07:18:41 up 23:48,  1 user,  load average: 0,92, 0,40, 0,23
[ondrejj@work ~]$ dmesg | grep "No irq handler for vector" | wc -l
1258

And same problem for 5.0.6 too.

It seems we are paying the cost for not having bisected the issue earlier.
At least it should still be possible to install old kernel 4.14/4.15 kernel and see which one showed the problem first
https://koji.fedoraproject.org/koji/packageinfo?buildStart=550&packageID=8&buildOrder=-completion_time&tagOrder=name&tagStart=300#buildlist

One could install the related kernel using:
koji download-build kernel-4.14.0-1.fc28

Unfortunately I won't have time to pick this task anytime soon. So is there a volunteer ? (or a better idea) ?

OK, here are some more testst with older kernels:

kernel-4.14.0-1.fc28.x86_64     OK
kernel-4.15.0-1.fc28.x86_64     do_IRQ: 2.33 No irq handler for vector
kernel-4.14.18-300.fc27.x86_64  OK

Does this help? I can't bisect, I have to reboot my work machine for each test. I have no other machine with this problem. Reboot takes 5-10 minutes.

With current latest kernels message disappeared, so currently it's only in background and in dmesg causes no problems in console. Earlier version displayed messages on terminal console, which disturbed me to use my PC.

My PC works well, even if there are these messages.

If there is no volunteer, who can fix this, I suggest to close as CANTFIX.

If you need to test more koji kernels, let me know which ones, I can still test some.

My laptop that exhibits this error is currently down with a HD failure but I should receive a replacement tomorrow. I can attempt to reproduce Jan's results then unless he has provided enough data.

Well I think the big bulk of changes are between 4.14.0 and 4.15-rc1 then until stable.
It would be nice to have a test on 4.15-rc1 to know if we need to test rc? or git snapshot.

On my side, I've seen this message and at the same time I started to experience issue when shutdown doesn't poweroff, but it might be a different issue.

Bonjour,

Same problem here :amd64 debian kernel 4.19

The «not poweroff» problem has been solved by using nvidia driver instead of nouveau one, without doing anything.
Verify your bios setting too : I've had APIC disabled (motherboard  asus M4N78 PRO) and experimented very slow working . In fact, the kernel was seeing just one core instead of 4 (athlon x4) !!!
With apic enabled, everything returns to nice working.

But irq .55 message still present but seems without effect.

cordialement,

Still saw the problem on 4.15.0-0.rc1.git3.1.fc28.x86_64.

We are running into this issue on https://bugzilla.redhat.com/show_bug.cgi?id=1684605. I am not sure why this bug is was in MODIFIED state. Changing it back to ASSIGNED.

Hi,
Please provide the hardware details of the Lenovo system that is having this issue..Thx.

With kernel 5.0.16-300.fc30.x86_64 started to happen again, that these messages have high priority and are displayed on each ssh session. This is very disturbing and hard to work on this computer. Som e examples:

Message from syslogd@work at May 22 18:22:02 ...
 kernel:do_IRQ: 2.34 No irq handler for vector

Message from syslogd@work at May 22 18:23:02 ...
 kernel:do_IRQ: 2.34 No irq handler for vector

Message from syslogd@work at May 22 18:24:02 ...
 kernel:do_IRQ: 2.37 No irq handler for vector

Message from syslogd@work at May 22 18:25:10 ...
 kernel:do_IRQ: 1.34 No irq handler for vector

Bisected the kernel between 4.14 and 4.15-rc8 on the fedora kernel git:
2ef4e8028f509354fb5a339bd2f8d0d1df8f2e8d is the first bad commit

So this message was introduced by the second git snapshot during the 4.15 merge window.

On my side, I was not able to reproduce the halt/reboot issue before the git4 snapshot, but it might be some other side effect as the behaviour is sometime random.
I also mention that unfortunately, the older kernel was garbage collected on koji, so I needed to rebuild using an older compiler to reproduce the build (used epel-7-x86_64).

On Fedora 30, kernel 5.1.12, on a Lenovo x140e I am getting these messages:

Jun 25 09:03:44 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
Jun 25 09:03:44 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
Jun 25 09:03:44 lx140e kernel: do_IRQ: 3.55 No irq handler for vector

I got one back on F28 on my old Lenovo x120e.

If you need more information from the message file or other information, let me know.

On Fedora 30, kernel 5.1.15-300, on Lenovo ThinkPad E585 the messages are present:

Jun 30 09:41:04 kernel: do_IRQ: 1.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #2
Jun 30 09:41:04 kernel: do_IRQ: 2.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #3
Jun 30 09:41:04 kernel: do_IRQ: 3.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #4
Jun 30 09:41:04 kernel: do_IRQ: 4.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #5
Jun 30 09:41:04 kernel: do_IRQ: 5.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #6
Jun 30 09:41:04 kernel: do_IRQ: 6.55 No irq handler for vector
Jun 30 09:41:04 kernel:   #7
Jun 30 09:41:04 kernel: do_IRQ: 7.55 No irq handler for vector

I see them only when the system boots up.

Created attachment 1586009 [details]
dmesg from Lenovo E585

I have not seen these messages since a couple of kernel updates.  Note below that I went from 3 messages at boot to one to none:

Jun 26 05:46:29 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
Jun 26 05:46:29 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
Jun 26 05:46:29 lx140e kernel: do_IRQ: 3.55 No irq handler for vector
Jun 26 21:01:58 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
Jun 26 21:01:58 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
Jun 26 21:01:58 lx140e kernel: do_IRQ: 3.55 No irq handler for vector
Jun 29 22:34:09 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul  6 22:46:56 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 13 22:52:05 lx140e kernel: do_IRQ: 0.55 No irq handler for vector

So looks like this is no longer an issue on my system.

Still happening for me as of 5.1.16...

I don't have it experienced with 5.3-rc0 from current kernel-rawhide-nodebug
(but still have the reboot/halt issue that might be separated).

Using fedora 29 on a desktop PC.
This *started* for me today after I updated to kernel 5.1.18-200.fc29.x86_64 #1 SMP Mon Jul 15 16:09:08 UTC 2019
(from 5.1.16-200)

E.g. in an idle xterm window:
Message from syslogd@vig at Jul 20 22:28:22 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@vig at Jul 20 22:28:22 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@vig at Jul 20 22:28:23 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@vig at Jul 20 22:28:32 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Message from syslogd@vig at Jul 20 22:28:33 ...
 kernel:do_IRQ: 2.33 No irq handler for vector

Also recorded in /var/log/messages, but only after kernel update.

Also seeing these messages at boot prior to login screen in my Thinkpad E585.  

From dmesg:
[    0.341816] smp: Bringing up secondary CPUs ...
[    0.342068] x86: Booting SMP configuration:
[    0.342069] .... node  #0, CPUs:        #1
[    0.342738] TSC synchronization [CPU#0 -> CPU#1]:
[    0.342738] Measured 10981151139 cycles TSC warp between CPUs, turning off TSC clock.
[    0.342738] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[    0.001690] do_IRQ: 1.55 No irq handler for vector
[    0.343959]   #2
[    0.001690] do_IRQ: 2.55 No irq handler for vector
[    0.344837]   #3
[    0.001690] do_IRQ: 3.55 No irq handler for vector
[    0.345149]   #4
[    0.001690] do_IRQ: 4.55 No irq handler for vector
[    0.345995]   #5
[    0.001690] do_IRQ: 5.55 No irq handler for vector
[    0.346972]   #6
[    0.001690] do_IRQ: 6.55 No irq handler for vector
[    0.347311]   #7
[    0.001690] do_IRQ: 7.55 No irq handler for vector
[    0.347974] smp: Brought up 1 node, 8 CPUs

Linux 5.1.17-300.fc30.x86_64 #1 SMP Wed Jul 10 15:20:27 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

/proc/cmdline;
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.1.17-300.fc30.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet amd_iommu=pt ivrs_ioapic[32]=00:14.0 iommu=soft trace_clock=global

Please guys, let's stop adding same un-useful log with me too comments. We know how the bug "looks like".
Anyone to reproduce with rawhide-kernel-nodebug (kernel 5.3) or stabilization branch 5.2 ?
Thx for the understanding.

(In reply to comment #40)
> Please guys, let's stop adding same un-useful log with me too comments. We
> know how the bug "looks like".
> Anyone to reproduce with rawhide-kernel-nodebug (kernel 5.3) or
> stabilization branch 5.2 ?
> Thx for the understanding.

Apologies: I hoped that by specifying the kernel change that introduced these reports I might help someone identify what had changed in 5.1.18-200.fc29.x86_64.
If that type of change information is too unspecific, I'll not report such things in future.
Sorry for noise.

I see there have been intermittent bug reports using the same form of words over several years, so something seems to be easily broken in that code region.

If the message 'No irq handler for vector' is too non-specific to be helpful, could the location(s) in source code where the message is generated be altered to give more information about context? Or is there too much asynchrony for that to be possible? Sorry I can't help more directly, as I've never worked on operating system sources.

Ignore this message if it's based on too much ignorance!

FWIW, I can reliably trigger this by plugging in an arduino (Duemilanova, if the model makes any difference) and calling up the "arduino" software.

I am at the IETF conference where I am regularly suspending my system (by closing it) and resuming in the next session or whatever.  Looks like I get a new No irg nandler each time I resume.  And at resume I see all the messages flash on the screen since the last reboot.

Here is a grep of messages for just

Jul 21 09:55:58 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 21 14:01:35 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 21 15:40:38 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 21 17:52:23 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 21 20:26:46 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 22 09:40:52 lx140e kernel: do_IRQ: 0.55 No irq handler for vector

And here are some of the messages around that last event:

# head messages -n 91963|tail -n10
Jul 22 09:40:52 lx140e kernel: smpboot: CPU 2 is now offline
Jul 22 09:40:52 lx140e kernel: smpboot: CPU 3 is now offline
Jul 22 09:40:52 lx140e kernel: ACPI: Low-level resume complete
Jul 22 09:40:52 lx140e kernel: ACPI: EC: EC started
Jul 22 09:40:52 lx140e kernel: PM: Restoring platform NVS memory
Jul 22 09:40:52 lx140e kernel: LVT offset 0 assigned for vector 0x400
Jul 22 09:40:52 lx140e kernel: microcode: CPU0: new patch_level=0x0700010f
Jul 22 09:40:52 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Jul 22 09:40:52 lx140e kernel: Enabling non-boot CPUs ...
Jul 22 09:40:52 lx140e kernel: x86: Booting SMP configuration:

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Thank you for information. I don't see this on 5.2.8-200.fc30.x86_64. Unable to upgrade today to newer kernel, but I think this is fixed.

Thank you for the update.

Just updated w/ kernel 5.2.9 and there is no change for me on my HP 15-g023cl...

Message from syslogd@xabbu at Aug 24 19:10:15 ...
 kernel:do_IRQ: 1.55 No irq handler for vector

5.2.9-200.fc30.x86_64

HP Pavilion dm1 Notebook PC
AMD E-350 Processor

(In reply to Nicolas Chauvet (kwizart) from comment #40)
> Please guys, let's stop adding same un-useful log with me too comments. We
> know how the bug "looks like". 
> Anyone to reproduce with rawhide-kernel-nodebug (kernel 5.3) or
> stabilization branch 5.2 ?
> Thx for the understanding.

I am running 5.2.9-200.fc30.x86_64 
Today on wake from resume, received on multiple open terminals: 

"Message from syslogd@red at Aug 30 10:54:10 ...
 kernel:do_IRQ: 5.44 No irq handler for vector"

I had not noticed this on earlier kernels.

I was doing fine until this weekend's resume.  I get these MOST of the time resuming from suspend.

I had them back in early Aug, then they stopped.



Aug  6 20:31:54 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Aug  7 18:08:04 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Aug  7 21:17:40 lx140e kernel: do_IRQ: 0.55 No irq handler for vector


I resumed Sat night (I suspend fridays and resume sat nights)

Aug 31 21:26:46 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Sep  1 08:07:53 lx140e kernel: do_IRQ: 0.55 No irq handler for vector
Sep  1 12:30:10 lx140e kernel: do_IRQ: 0.55 No irq handler for vector

Now I am traveling so lots of suspend/resume.

I am running 5.2.9-200

This is now marked CLOSED:CURRENTRELEASE , what release is that , I just upgraded to fed31 and still get this message.

[    0.413265] localhost.localdomain kernel: smpboot: CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (family: 0xf, model: 0x43, stepping: 0x3)
[    0.413473] localhost.localdomain kernel: Performance Events: AMD PMU driver.
[    0.413473] localhost.localdomain kernel: ... version:                0
[    0.413473] localhost.localdomain kernel: ... bit width:              48
[    0.413473] localhost.localdomain kernel: ... generic registers:      4
[    0.413473] localhost.localdomain kernel: ... value mask:             0000ffffffffffff
[    0.413474] localhost.localdomain kernel: ... max period:             00007fffffffffff
[    0.413593] localhost.localdomain kernel: ... fixed-purpose events:   0
[    0.413710] localhost.localdomain kernel: ... event mask:             000000000000000f
[    0.413891] localhost.localdomain kernel: rcu: Hierarchical SRCU implementation.
[    0.414567] localhost.localdomain kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[    0.414760] localhost.localdomain kernel: smp: Bringing up secondary CPUs ...
[    0.415044] localhost.localdomain kernel: x86: Booting SMP configuration:
[    0.415172] localhost.localdomain kernel: .... node  #0, CPUs:      #1
[    0.018229] localhost.localdomain kernel: do_IRQ: 1.55 No irq handler for vector
[    0.474547] localhost.localdomain kernel: smp: Brought up 1 node, 2 CPUs

Linux fedbox 5.3.9-300.fc31.x86_64 #1 SMP Wed Nov 6 16:13:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Its back......

Fedora 32 on a Lenovo x140e:

# grep do_IR messages*
messages:May 13 09:21:13 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
messages:May 13 09:21:13 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
messages:May 13 09:21:13 lx140e kernel: do_IRQ: 3.55 No irq handler for vector
messages-20200510:May  5 17:25:36 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
messages-20200510:May  5 17:25:36 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
messages-20200510:May  5 17:25:36 lx140e kernel: do_IRQ: 3.55 No irq handler for vector
messages-20200510:May  5 19:49:16 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
messages-20200510:May  5 19:49:16 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
messages-20200510:May  5 19:49:16 lx140e kernel: do_IRQ: 3.55 No irq handler for vector
messages-20200510:May  9 21:59:36 lx140e kernel: do_IRQ: 1.55 No irq handler for vector
messages-20200510:May  9 21:59:36 lx140e kernel: do_IRQ: 2.55 No irq handler for vector
messages-20200510:May  9 21:59:36 lx140e kernel: do_IRQ: 3.55 No irq handler for vector


May 10th was when I built this system.  I got the error on firstboot.  And again when I rebooted after running updates.

Then today I rebooted again and errors.

So each time I have booted, I have gotten these 3 messages.

I also see this on Fedora 32. Can this bug be reopened, please?

I swapped out my motherboard for a new motherboard, and didn't see this problem on the old motherboard, but I do see it on the new motherboard, with the same exact CPU, RAM, video card, and SSD.

[    0.791389] smp: Bringing up secondary CPUs ...
[    0.791432] x86: Booting SMP configuration:
[    0.791433] .... node  #0, CPUs:        #1
[    0.319300] do_IRQ: 1.55 No irq handler for vector
[    0.792751]   #2
[    0.319300] do_IRQ: 2.55 No irq handler for vector
[    0.793754]   #3
[    0.319300] do_IRQ: 3.55 No irq handler for vector
[    0.794750]   #4
[    0.319300] do_IRQ: 4.55 No irq handler for vector
[    0.796760]   #5
[    0.319300] do_IRQ: 5.55 No irq handler for vector
[    0.797748]   #6
[    0.319300] do_IRQ: 6.55 No irq handler for vector
[    0.798752]   #7
[    0.319300] do_IRQ: 7.55 No irq handler for vector
[    0.800723]   #8
[    0.319300] do_IRQ: 8.55 No irq handler for vector
[    0.801760]   #9
[    0.319300] do_IRQ: 9.55 No irq handler for vector
[    0.802749]  #10
[    0.319300] do_IRQ: 10.55 No irq handler for vector
[    0.803753]  #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 #24 #25 #26 #27 #28 #29 #30 #31
[    0.829732] smp: Brought up 1 node, 32 CPUs
[    0.829732] smpboot: Max logical packages: 1
[    0.829732] smpboot: Total of 32 processors activated (223560.12 BogoMIPS)

CPU: AMD Ryzen 3950X
Old chipset (without the problem): B350 (MSI mothermoard)
New chipset (exhibiting the above dmesg logs): B550 (Asus motherboard)

I assume the problem is not serious, since the machine seems to work fine, but it would be nice to know what is causing the problem.

https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

depending on your specific processor revision, this might be errata 1043 above

The suggested workaround in the doc only says "system software may contain a workaround to this issue", but I've no idea what that might amount too.  Intel had a simmilar problem years ago, and the fix there was to disable interrupt remapping.  Not sure if thats feasible here though.

In my case, this is for a Ryzen 3950X CPU, which is a 3rd gen Ryzen, and is therefore not covered by the errata note you linked. (No idea if they actually fixed that bug between gen 2 and gen 3.)

given that the revision guide indicated no fix was planned, and that they seem to think some sort of software workaround might be possible (though I still don't know what that would be, other than to ignore the interrupt, which is effectively what we do), I'm guessing they didn't fix it.

I just did a BIOS upgrade on my X570GT8 Biostar MB and now I get the same messages on boot. The only change listed is an upgrade to AGESA Combov2 PI 1.0.0.2  from AGESA ComboAM4 PI 1.0.0.4B. Using Fedora 32.

Created attachment 1714334 [details]
dmesg from Biostar X570GT8

After BIOS update to X57AG710

I had the same error messages with a MSI X570-A PRO and BIOS 7C37vHA featuring AGESA ComboAm4v2PI 1.0.8.1.
They went away after updating to 7C37vHB with AGESA ComboAm4v2PI 1.1.0.0 Patch C.

This suggests the modern occurrences of this can be fixed by BIOS updates with new AGESA versions.

I have a Gigabyte X570 Aorus Ultra motherboard. I upgraded to BIOS F31 (AMD AGESA ComboV2 1.1.0.0 patch D), and it did not resolve the issue in my case.

I assume that the issue going away for Thomas was specific to the MSI motherboard or the MSI part of the BIOS, not to the AMD AGESA component of the BIOS.

I see that AMD AGESA ComboV2 1.2.0.0 is available for other motherboards, but I don't suspect that this or subsequent updates will make a difference if this issue is not on AMD's radar.

Hm. The AGESA uprgade was the only line in the Changelog between the versions in my case, but that of course doesn't mean that it was the only change. At any rate, I can discern no functional difference with the error messages gone.

I am experiencing this bug on Fedora 33 on Dell Precision 5510 with BIOS version 1.15.0.

Operating System: Fedora 33
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.7-200.fc33.x86_64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6820HQ CPU @ 2.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 530

Please open a new bug and link to this one, since clearly this one will get zero attention now that it has been marked CLOSED because of the release info.

(In reply to Federic from comment #63)
> Please open a new bug and link to this one, since clearly this one will get
> zero attention now that it has been marked CLOSED because of the release
> info.

Done, https://bugzilla.redhat.com/show_bug.cgi?id=1919494