Bug #1442
open
apic_timer_reprogram request is too far in future (on vmware workstation)
0%
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
Updated by Dan Kruchinin almost 12 years ago
The same behavior was observed on VirtualBox: http://mail.opensolaris.org/pipermail/on-discuss/2010-June/001935.html
Updated by Jason King almost 12 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.
Updated by Dan Kruchinin almost 12 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()?
Updated by Stepan Zastupov over 11 years ago
I have the same issue on vbox 4.1.8.
Updated by Jon Strabala over 11 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.
Updated by Javier Alcázar over 10 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.
Updated by Rich Lowe over 10 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.
Updated by Josef Sipek about 9 years ago
All the message appear to come from pcplusmp, not apix so I wouldn't expect tweaking apix to have any effect.