Hi,
I do have the same issue on 8.4-RELEASE, 9.1-RELEASE, 9.2-RELEASE based on
XENHVM config (amd64).
The 'uname' in the guests looks like this one:
root@my:/ # uname -a
FreeBSD my.vm 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Mon Aug 19 14:08:42 EEST 2013
r...@my.vm:/usr/obj/usr/src/sys/XENHVM amd64
I could also confirm the issue doesn't affect 8.2 8.3, 9.0 versions.
The Hypervisor is CentOS release 5.9 with Xen 3.4.3, and its details are:
# cat /proc/cpuinfo
...
processor : 15
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6128
stepping: 1
cpu MHz : 2000.140
cache size : 512 KB
physical id : 15
siblings: 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush mmx
fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni
cx16 popcnt lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse
bogomips: 5002.23
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]
# xm info
host : hv.build
release: 2.6.18-308.20.1.el5.xen
version: #1 SMP Wed Dec 5 13:30:38 GMT 2012
machine: x86_64
nr_cpus: 16
nr_nodes : 1
cores_per_socket : 8
threads_per_core : 1
cpu_mhz: 2000
hw_caps:
178bf3ff:efd3fbff::0310:00802001::000837ff:
virt_caps : hvm
total_memory : 49150
free_memory: 45664
node_to_cpu: node0:0-15
node_to_memory : node0:45664
xen_major : 3
xen_minor : 4
xen_extra : .4
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params: virt_start=0x8000
xen_changeset : unavailable
cc_compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)
cc_compile_by : root
cc_compile_domain : hv.build
cc_compile_date: Wed Sep 5 18:01:10 EEST 2012
xend_config_format : 4
Could anybody please help/assist me with the issue fixing ?
Thanks
---
Yura
On Jun 2, 2011, at 10:22 PM, Sergi se...@estrafolari.com wrote:
On 01/06/11 23:36, Kostik Belousov wrote:
On Wed, Jun 01, 2011 at 03:00:51PM +0200, Sergi wrote:
On 01/06/11 11:36, Sergi wrote:
On 01/06/11 10:21, Kostik Belousov wrote:
On Wed, Jun 01, 2011 at 09:44:23AM +0200, Sergi wrote:
Hello,
I'm working with full virtual FreeBSD 8.2-RELEASE-p1 domU under debian
squeeze and xen-hypervisor-4.0-amd64.
If I cfg this hvm with cpu 4 :
vcpus= 5
these messages block the server :
fpudna: fpcurthread == curthread times
The machine is pingable but I'm unable to ssh to it.
On single user it works fine, fsck an so on ok, but when switching to
multiuser these fpudna messages start flooding.
I've googled but haven't found anything; something from 2005 about
fpudna :
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004413.html
and this link, but I don't have the options he mentions enabled on the
kernel :
http://forums.freebsd.org/showthread.php?t=17979
Has anyone stepped on this behaviour before?, is there any workaround?
The machine really seems to detect cpu's available and responds to
keyboard
on VNC, but it's impossible to see whats written down because of the
messages flooding the screen.
You did not specified the architecture of the domu. From the message,
I can
guess that your guest is running amd64 kernel. There are slight
differences
in the handling of the FPU in i386 and amd64 that may matter there.
The message you reported means that the FreeBSD kernel assumes that FPU
is currently loaded with the context of the current thread, but the
CR0.TS bit is set, meaning that FPU context is set for switch.
AFAIR, HVM means that you run bare-metal kernel, right ? Most likely,
it is some issue with Xen itself. I am curious whether the following
will cause any usermode-visible regression for you:
diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
index 08e5e57..a5ee853 100644
--- a/sys/amd64/amd64/fpu.c
+++ b/sys/amd64/amd64/fpu.c
@@ -394,14 +394,8 @@ fpudna(void)
struct pcb *pcb;
critical_enter();
-if (PCPU_GET(fpcurthread) == curthread) {
-printf(fpudna: fpcurthread == curthread %d times\n,
-++err_count);
-stop_emulating();
-critical_exit();
-return;
-}
-if (PCPU_GET(fpcurthread) != NULL) {
+if (PCPU_GET(fpcurthread) != NULL
+
