VMware Communities
ac2014
Contributor
Contributor

spurious APIC interrupt on CPU#1, should never happen.

Did anyone notice the message below in /var/log/syslog?

"spurious APIC interrupt on CPU#<n>, should never happen."

where <n> is the CPU ID, e.g. CPU#1 or CPU#2.

I've checked my "syslog" files corresponding to VMware Workstation 10 period, and no such messages can be found then.

Thank you.

Reply
0 Kudos
16 Replies
RLynch
Contributor
Contributor

I'm seeing this too.  It started after my upgrade to VMWare Workstation 11.  If VMWare is not running I don't get the message.  I have no resolution.

Rich

ac2014
Contributor
Contributor

Rich,

Thank you for your reply -- I'm glad, I'm not the only one.

The same thing here -- no messages when no VMs are running.

My host workstation is:

CPU: i7-4770

OS: Debian 7

Are you running a Haswell processor as well?

I've reported this issue to VMware using my 30-day complimentary support, and will update the thread upon any response from VMware.

Thank you again,

Alex.

Reply
0 Kudos
RLynch
Contributor
Contributor

Hi Alex,

I'm running a core i7 860 2.8ghz.  I think it is a haswell, can't remember for sure.  It is a bit old.  My host is CentOS 6.6.

cat /proc/cpuinfo | grep model

model name  : Intel(R) Core(TM) i7 CPU     860  @ 2.80GHz

Glad I'm not alone.  As people upgrade to WS11 we'll be hearing more.

Rich

ac2014
Contributor
Contributor

Hi Rich,

Then, it looks like this problem is not limited to any particular CPU or Linux distribution.

Hopefully, someone else will check their syslog as well, and will reply to this thread.

I'll reference the thread in my VMware support ticket.

Best,

Alex.

Reply
0 Kudos
ac2014
Contributor
Contributor

Just a clarification.

The message is written to /var/log/kern.log, and duplicated to /var/log/syslog.

Reply
0 Kudos
RLynch
Contributor
Contributor

In Redhat/CentOS distributions the message is written to /var/log/messages.

Rich

Reply
0 Kudos
admin
Immortal
Immortal

These messages are the result of an optimization Workstation 11 uses for inter-processor interrupts between virtual CPUs.  The interrupt vector used for this purpose is 0xff, which is the Linux spurious APIC interrupt vector.  In some cases, an inter-processor interrupt may arrive on a physical processor after Workstation has relinquished the processor to the host OS.  Linux will discard the interrupt and print this message.

Unless these messages occur with high frequency, they should be innocuous.

The following configuration option should disable the optimization and make the messages stop:

monitor_control.disable_hostedIPI = TRUE

You can add this setting to /etc/vmware/config, and it will take effect for all VMs the next time they are powered on.

Reply
0 Kudos
ac2014
Contributor
Contributor

Here's an extract from my kern.log just for one hour:

Dec  6 22:01:32 host kernel: [94357.691710] spurious APIC interrupt on CPU#6, should never happen.

Dec  6 22:01:41 host kernel: [94366.568217] spurious APIC interrupt on CPU#0, should never happen.

Dec  6 22:05:30 host kernel: [94594.952440] spurious APIC interrupt on CPU#4, should never happen.

Dec  6 22:07:17 host kernel: [94702.508002] spurious APIC interrupt on CPU#3, should never happen.

Dec  6 22:12:54 host kernel: [95038.524471] spurious APIC interrupt on CPU#0, should never happen.

Dec  6 22:16:59 host kernel: [95283.704960] spurious APIC interrupt on CPU#1, should never happen.

Dec  6 22:17:46 host kernel: [95330.274178] spurious APIC interrupt on CPU#0, should never happen.

Dec  6 22:17:46 host kernel: [95330.954803] spurious APIC interrupt on CPU#7, should never happen.

Dec  6 22:19:01 host kernel: [95405.219228] spurious APIC interrupt on CPU#0, should never happen.

Dec  6 22:20:31 host kernel: [95495.337533] spurious APIC interrupt on CPU#4, should never happen.

Dec  6 22:20:59 host kernel: [95523.587393] spurious APIC interrupt on CPU#4, should never happen.

Dec  6 22:21:00 host kernel: [95523.805565] spurious APIC interrupt on CPU#4, should never happen.

Dec  6 22:21:31 host kernel: [95555.436663] spurious APIC interrupt on CPU#4, should never happen.

Dec  6 22:22:48 host kernel: [95631.711465] spurious APIC interrupt on CPU#6, should never happen.

Dec  6 22:23:44 host kernel: [95687.975849] spurious APIC interrupt on CPU#0, should never happen.

Dec  6 22:27:09 host kernel: [95892.952456] spurious APIC interrupt on CPU#0, should never happen.

16 messages per hour -- it is not innocuous, and I have just a few VMs running.

IMHO, there's an error in Workstation 11 utilizing inter-processor interrupts between virtual CPUs.

Anyway, I've disabled the optimization, and no more messages for me.

Thank you very much for your reply!

Reply
0 Kudos
RLynch
Contributor
Contributor

Thanks for the help.  Adding that option to my VMWare config file did correct the problem for me.  Now I'm left to wonder if giving up the optimization is worth it just to prevent the non-harmful messages.  In my case I'm getting a lot of them.  About 100,000 since 1pm yesterday.

Reply
0 Kudos
SamXray
Contributor
Contributor

ac2014  FWIW, in addition to Workstation 11, this is happening on all our Player 7.0.0 machines on Linux hosts as well.  We didn't see the messages under Player 6.0.3.

Reply
0 Kudos
imbezol
Contributor
Contributor

I've noticed this message since upgrading to Workstation 11 as well. The messages are accompanied by a very noticeable lag to the system.

Reply
0 Kudos
SamXray
Contributor
Contributor

Unfortunately the "spurious APIC interrupts" (thousands of messages in syslog) are still occurring on Player 7.1.0 (released 17 February 2015).

Reply
0 Kudos
admin
Immortal
Immortal

For anyone plagued by these messages, I would recommend adding the following configuration option to /etc/vmware/config on the host:

monitor_control.disable_hostedIPI = TRUE

Reply
0 Kudos
SamXray
Contributor
Contributor

jmattson  Thanks very much J.  Are there any other implications in making that change (aside from a presumed performance hit)? 


Or for example would going back to the WS 10 or Player 6 series be preferable?  (We didn't see this problem prior to Workstation 11.x or Player 7.x on our Linux hosts).  If you could point us to any documentation on that parameter, we would greatly appreciate it.

Thanks,

Sam

Reply
0 Kudos
admin
Immortal
Immortal

SamXray wrote:

jmattson  Thanks very much J.  Are there any other implications in making that change (aside from a presumed performance hit)? 


Or for example would going back to the WS 10 or Player 6 series be preferable?  (We didn't see this problem prior to Workstation 11.x or Player 7.x on our Linux hosts).  If you could point us to any documentation on that parameter, we would greatly appreciate it.

Thanks,

Sam

These messages are the result of a performance optimization introduced in Workstation 11.  The configuration option given above disables the optimization.  There is no documentation.

Reply
0 Kudos
SamXray
Contributor
Contributor

jmattson OK...thanks very much.

Reply
0 Kudos