Environment: Hardware is an Intel Haswell with 8 GB quality RAM Virtualised using Xen 4.2 with NetBSD Dom0 Fresh vanilla FreeBSD 10.0 BETA2 install. At first ssh into the system, it gets a panic. Some basic networking works, including telnet to the ssh port. I've tried giving 256MiB and 512MiB to the FreeBSD guest. The panic happend in both cases. Here is the retyped console output: xn_rxeof: WARNING: response is -1! xn_rxeof: WARNING: response is -1! Fatal trap 12: page fault whle in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x1 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8079e010 stack pointer = 0x28:0xfffffe001b2509a0 frame pointer = 0x28:0xfffffe001b2598f0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, prec 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq771: xn0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: (got tired of copying data here, vnc console will not allow me to cut-and-paste. If this data is needed, I can make a screen dump.)
I suppose non-critical/low might not be appropriate if Xen-based virtualisation is common for FreeBSD. Then critical/high is more suitable! For what it is worth, the exact same panic happens for a x86-32 install (as opposed to x86-64 in the PR) under the same Xen/NetBSD system. I should also perhaps mention that the Xen/NetBSD system runs several guests flawlessly, including 32-bit and 64-bit FreeBSD 9.2, NetBSD 6.1.2, Debian GNU/Linux and Debian GNU/kFreeBSD. I fully realise that the bug might very well be on the Xen side. --=20 Torbj=C3=B6rn
The contents of the stack trace would indeed be very valuable. -- John Baldwin
Those attachments didn't come out too pretty at the web PR interface. I put the screen dumps in png format here: http://gmplib.org/~tege/fbsd32-oh-no-ssh.png http://gmplib.org/~tege/fbsd64-oh-no-ssh.png --=20 Torbj=C3=B6rn
Responsible Changed From-To: freebsd-amd64->freebsd-bugs reclassify.
I spent a lot of time to supply needed information. Then silence. One month later, two BETA releases later. I didn't try the BETA from 2013-11-30, but since I've not gotten any indication of that the xn problem has been addressed, I might not be too pessimistic to assume that FreeBSD 10 still runs as poorly as indicated by my recent testing: http://gmplib.org/~tege/virt.html OK, you're in good company, only NetBSD and older FreeBSD runs well. The other BSDes work as poorly as or worse than FreeBSD 10. (No, I haven't reported the "filesystem malfunctions" problem which happens for 32-bit x86 under both Xen and Linux' KVM. It takes a lot of time to make good bug reports and to follow up timely, and my last few experiences of FreeBSD reporting has not encouraged me. To be fair, the filesystem malfunctions problem might have been fixed.) It's ironic that I cannot use FreeBSD now, since the virtualisation problems and the ignored bin/166994 makes no FreeBSD release or pre-rellease work on newer hardware for what I do. The next major GMP release will happen in a few weeks and that release will not work on FreeBSD as things stand now. (It might run on bare metal, but your bundled clang miscompiled GMP under x86-32 last time I tested...) FreeBSD surely doesn't look like it used to. I've been a user since FreeBSD 1.1. I've never seen such a mound of show-stopper bugs as I do now. Torbj=C3=B6rn Please encrypt, key id 0xC8601622
Responsible Changed From-To: freebsd-bugs->freebsd-xen reclassify, to see if this will attract any attention.
I wonder since there's been work on FreeBSD as a Dom0 if this issue will ever be addressed? I've reported this also in another pr: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188369 I would be glad if we at least get a "NO! FreeBSD 10 will never be supported in NetBSD dom0s"
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.