Bug 1551605 - do_IRQ: X.XX No irq handler for vector
Summary: do_IRQ: X.XX No irq handler for vector
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 30
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-05 13:46 UTC by Jan ONDREJ
Modified: 2021-01-23 02:31 UTC (History)
52 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-22 18:04:10 UTC
Type: Bug


Attachments (Terms of Use)
requested dmesg file (87.79 KB, text/plain)
2019-03-05 18:15 UTC, Jan ONDREJ
no flags Details
dmesg from HP 15-g023cl (71.79 KB, text/plain)
2019-03-06 15:42 UTC, Richard Shaw
no flags Details
dmesg from Lenovo E585 (76.20 KB, text/plain)
2019-06-30 13:31 UTC, Alain Reguera Delgado
no flags Details
dmesg from Biostar X570GT8 (93.16 KB, text/plain)
2020-09-09 20:09 UTC, DanMan
no flags Details

Description Jan ONDREJ 2018-03-05 13:46:11 UTC
Description of problem:
After update to kernel 4.15 there are lots of message like:

[26496.273998] do_IRQ: 2.33 No irq handler for vector
[26556.091857] do_IRQ: 1.37 No irq handler for vector

Different numbers, but still same message. Each message is displayed on ssh remove console, which is very disturbing.

Version-Release number of selected component (if applicable):
kernel-4.15.3-300.fc27.x86_64
kernel-4.15.4-300.fc27.x86_64
kernel-4.15.6-300.fc27.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. boot this kernel on my machine
2. wait one or more minutes
3. look into dmesg, if not connected over ssh

Actual results:
[25843.049681] do_IRQ: 2.34 No irq handler for vector
[25896.256442] do_IRQ: 2.34 No irq handler for vector
[26016.049151] do_IRQ: 2.33 No irq handler for vector
[26022.812247] do_IRQ: 2.33 No irq handler for vector
[26075.935000] do_IRQ: 2.33 No irq handler for vector
[26135.825861] do_IRQ: 2.33 No irq handler for vector
[26195.745711] do_IRQ: 2.33 No irq handler for vector
[26202.569808] do_IRQ: 2.33 No irq handler for vector
[26255.651574] do_IRQ: 2.33 No irq handler for vector
[26315.561435] do_IRQ: 2.33 No irq handler for vector
[26376.451295] do_IRQ: 2.33 No irq handler for vector
[26383.324386] do_IRQ: 2.33 No irq handler for vector
[26436.392150] do_IRQ: 2.33 No irq handler for vector
[26496.273998] do_IRQ: 2.33 No irq handler for vector
[26556.091857] do_IRQ: 1.37 No irq handler for vector
[26563.073956] do_IRQ: 1.37 No irq handler for vector
[26615.920705] do_IRQ: 1.37 No irq handler for vector
[26742.832543] do_IRQ: 1.37 No irq handler for vector
[26795.691276] do_IRQ: 2.33 No irq handler for vector
[26855.555146] do_IRQ: 2.33 No irq handler for vector
[26916.436005] do_IRQ: 2.33 No irq handler for vector
[26922.602092] do_IRQ: 2.33 No irq handler for vector
[26976.312860] do_IRQ: 3.35 No irq handler for vector
[27036.184710] do_IRQ: 3.35 No irq handler for vector

Expected results:
no messages

Additional info:
Trying to disable using various kernel parameters, like "pci=nomsi,noaer intremap=off", but nothing helps. I have to stop rsyslogd if I am connected over ssh, otherwise I can't use this computer. This PC has latest BIOS installed.
There was no problem with kernels 4.14.X or older.

Comment 1 Laura Abbott 2018-03-05 17:04:49 UTC
Can you do a kernel bisect? That's going to be the best way to figure out which commit broke things.

Comment 2 Jan ONDREJ 2018-03-21 17:10:20 UTC
(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

Comment 3 Yajo 2018-03-25 19:11:55 UTC
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.

Comment 4 Gabriel M. Elder 2018-03-26 14:55:01 UTC
+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.

Comment 5 cmiersma 2018-05-05 06:14:06 UTC
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

Comment 6 hiro 2018-06-07 18:26:14 UTC
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.

Comment 7 hiro 2018-06-07 21:54:37 UTC
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?

Comment 8 Justin M. Forbes 2018-07-23 15:27:44 UTC
*********** 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.

Comment 9 Jan ONDREJ 2018-07-26 07:27:43 UTC
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.

Comment 10 Laura Abbott 2018-10-01 21:23:34 UTC
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.

Comment 11 Jan ONDREJ 2018-10-02 05:02:02 UTC
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.

Comment 12 dan 2018-11-07 16:41:51 UTC
Experiencing on FC29 with kernel 4.18.16-300

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

Comment 13 dan 2018-11-07 16:46:53 UTC
Would someone on the cc list with access please update Version to FC29 and reopen?

Comment 14 Richard Shaw 2019-02-08 02:25:12 UTC
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)

Comment 15 Hans de Goede 2019-03-05 16:01:59 UTC
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

Comment 16 Richard Shaw 2019-03-05 16:30:42 UTC
Sure, I can get that when I get home. It's an Acer AMD A8 based system.

Comment 17 Jan ONDREJ 2019-03-05 18:15:15 UTC
Created attachment 1541116 [details]
requested dmesg file

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

Comment 18 Richard Shaw 2019-03-06 15:42:16 UTC
Created attachment 1541467 [details]
dmesg from HP 15-g023cl

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

Comment 19 Laura Abbott 2019-04-09 20:46:53 UTC
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.

Comment 20 Jan ONDREJ 2019-04-10 05:19:23 UTC
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

Comment 21 Jan ONDREJ 2019-04-10 05:49:19 UTC
And same problem for 5.0.6 too.

Comment 22 Nicolas Chauvet (kwizart) 2019-04-10 07:21:48 UTC
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) ?

Comment 23 Jan ONDREJ 2019-04-10 09:20:46 UTC
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.

Comment 24 Richard Shaw 2019-04-10 13:55:11 UTC
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.

Comment 25 Nicolas Chauvet (kwizart) 2019-04-10 17:47:45 UTC
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.

Comment 26 Moebius 2019-04-11 11:23:17 UTC
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,

Comment 27 Richard Shaw 2019-04-12 21:50:01 UTC
Still saw the problem on 4.15.0-0.rc1.git3.1.fc28.x86_64.

Comment 28 Ameen Rahman 2019-04-12 23:03:40 UTC
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.

Comment 29 Vamshee Paduru 2019-05-22 13:19:26 UTC
Hi,
Please provide the hardware details of the Lenovo system that is having this issue..Thx.

Comment 30 Jan ONDREJ 2019-05-22 16:27:24 UTC
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

Comment 31 Nicolas Chauvet (kwizart) 2019-05-30 19:14:53 UTC
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).

Comment 32 Robert Moskowitz 2019-06-26 12:31:06 UTC
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.

Comment 33 Alain Reguera Delgado 2019-06-30 13:26:25 UTC
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.

Comment 34 Alain Reguera Delgado 2019-06-30 13:31:45 UTC
Created attachment 1586009 [details]
dmesg from Lenovo E585

Comment 35 Robert Moskowitz 2019-07-18 17:07:24 UTC
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.

Comment 36 Richard Shaw 2019-07-18 21:33:59 UTC
Still happening for me as of 5.1.16...

Comment 37 Nicolas Chauvet (kwizart) 2019-07-19 07:44:13 UTC
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).

Comment 38 aaronsloman 2019-07-20 23:17:27 UTC
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.

Comment 39 billgrzanich 2019-07-21 16:37:48 UTC
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

Comment 40 Nicolas Chauvet (kwizart) 2019-07-21 19:05:10 UTC
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.

Comment 41 aaronsloman 2019-07-21 20:11:13 UTC
(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!

Comment 42 Neil Thompson 2019-07-22 10:01:34 UTC
FWIW, I can reliably trigger this by plugging in an arduino (Duemilanova, if the model makes any difference) and calling up the "arduino" software.

Comment 43 Robert Moskowitz 2019-07-22 13:52:50 UTC
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:

Comment 44 Justin M. Forbes 2019-08-20 17:42:19 UTC
*********** 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.

Comment 45 Jan ONDREJ 2019-08-22 16:00:42 UTC
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.

Comment 46 Justin M. Forbes 2019-08-22 18:04:10 UTC
Thank you for the update.

Comment 47 Richard Shaw 2019-08-24 14:18:16 UTC
Just updated w/ kernel 5.2.9 and there is no change for me on my HP 15-g023cl...

Comment 48 Kim Bisgaard 2019-08-24 17:19:18 UTC
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

Comment 49 Phil V 2019-08-30 03:22:33 UTC
(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.

Comment 50 Robert Moskowitz 2019-09-01 17:52:36 UTC
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

Comment 51 Federic 2019-11-15 06:19:19 UTC
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

Comment 52 Robert Moskowitz 2020-05-13 13:53:01 UTC
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.

Comment 53 Luke Hutchison 2020-07-12 07:48:51 UTC
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.

Comment 54 Neil Horman 2020-07-12 11:43:20 UTC
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.

Comment 55 Luke Hutchison 2020-07-12 14:28:24 UTC
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.)

Comment 56 Neil Horman 2020-07-12 15:23:30 UTC
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.

Comment 57 DanMan 2020-09-09 20:08:10 UTC
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.

Comment 58 DanMan 2020-09-09 20:09:56 UTC
Created attachment 1714334 [details]
dmesg from Biostar X570GT8

After BIOS update to X57AG710

Comment 59 Thomas 2021-01-17 01:02:06 UTC
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.

Comment 60 Luke Hutchison 2021-01-19 11:26:17 UTC
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.

Comment 61 Thomas 2021-01-20 00:30:06 UTC
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.

Comment 62 Sudhir Khanger 2021-01-22 02:06:25 UTC
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

Comment 63 Federic 2021-01-22 06:05:46 UTC
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.

Comment 64 Sudhir Khanger 2021-01-23 02:31:23 UTC
(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


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