Project

General

Profile

Bug #1442

apic_timer_reprogram request is too far in future (on vmware workstation)

Added by Dan Kruchinin almost 8 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
kernel
Start date:
2011-09-02
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

There's a problem that appears from time to time on vmware workstation: there're a lot messages in syslog like the following:

Sep  2 11:35:12 illumos pcplusmp: apic_timer_reprogram, request at  313206003906250  too far in future, current time  178110130125436 
Sep  2 11:35:12 illumos pcplusmp: apic_timer_reprogram, request at  313206003906250  too far in future, current time  178110150901468 
Sep  2 11:35:12 illumos pcplusmp: apic_timer_reprogram, request at  313206003906250  too far in future, current time  178110170210231 
Sep  2 11:35:13 illumos pcplusmp: apic_timer_reprogram, request at  313206003906250  too far in future, current time  178110190187131 

The message is printed very frequently (probably from softirq) and significantly slows down machine performance.

It's printed from src/uts/i86pc/io/pcplusmp/:oneshot_timer_reprogram()

Stack:

  3  -> oneshot_timer_reprogram               
              pcplusmp`apic_timer_reprogram+0x19
              unix`cbe_reprogram+0x25
              genunix`cyclic_fire+0x297
              unix`cbe_fire+0x67
              unix`av_dispatch_autovect+0x8f
              unix`dispatch_hilevel+0x1f
              unix`switch_sp_and_call+0x13
              unix`do_interrupt+0x137
              unix`_interrupt+0x1e9
              unix`mach_cpu_idle+0x6
              unix`cpu_idle+0xaf
              unix`idle+0x114
              unix`thread_start+0x8

History

#1

Updated by Dan Kruchinin almost 8 years ago

#2

Updated by Jason King almost 8 years ago

Would this also explain the system clock randomly returning epoch while under VMware? I mention because caiman (which is also used for Openindiana) and the old S10 installer effectively lock up when that happens (I suspect it might be more in inability to deal with time going backwards than the specific value), which causes issues if one wants to use Illumos in an existing VMware environment.

#3

Updated by Dan Kruchinin almost 8 years ago

Would this also explain the system clock randomly returning epoch while under VMware?

Unfortunately I have no idea about that.
I can try to check it when I can the bug again (it's sort of random). How can I check it? Is it enough to call time()?

#4

Updated by Stepan Zastupov over 7 years ago

I have the same issue on vbox 4.1.8.

#5

Updated by Jon Strabala over 7 years ago

Hi Dan and Stepan,

Perhaps this is the same issue (or related) as Bug #1333 [https://www.illumos.org/issues/1333]

If it is the same, I think if you are running oi_151a you might solve your problem with a temporary /etc/system work around (and do a configuration reboot)

set apix:apic_timer_preferred_mode = 0x0

or better yet build a new nightly as #1333 has a patch (or code change) to fix the issue, change set: 13533:6c1a51927cbd from 26 days ago - which change eliminated the need for the above work around for me.

#6

Updated by Javier Alcázar almost 7 years ago

Same problem with a clean build from 13794:7c5e0e746b2c, using virtualbox-ose 4.0.4-dfsg-1ubuntu4.1.
set apix:apic_timer_preferred_mode = 0x0 on /etc/system doesn't not help.

#7

Updated by Rich Lowe almost 7 years ago

Is it really emulating an x2apic? If it is, you want to make it stop doing so, the x2apic support is in a real mess.

#8

Updated by Josef Sipek over 5 years ago

All the message appear to come from pcplusmp, not apix so I wouldn't expect tweaking apix to have any effect.

Also available in: Atom PDF