Created attachment 160331 [details] logs, Xconfigure, pciconf, pkg info (core dump not here but is available) Xorg will not start in a new, clean install of FreeBSD 10.2 in kvm/qemu virtualization: illegal instruction at address 0x4a40d0 I had been running FreeBSD 10.1 in kvm/qemu virtualization and when I upgraded to 10.2 xorg would not start. I used the same installation process for 10.1 and 10.2. The physical machine is an old macbook pro from 2008 that has hardware virtualization. I got a similar error on the latest FreeBSD 11 FreeBSD-11.0-CURRENT-amd64-20150722-r285794-bootonly.iso from Aug 23, 2015 but not from FreeBSD-11.0-CURRENT-amd64-20150722-r285794-disc1.iso (I had a different error in FreeBSD-11.0-CURRENT-amd64-20150722-r285794-disc1.iso) [ 1146.450] (II) Loading sub module "fb" [ 1146.450] (II) LoadModule: "fb" [ 1146.451] (II) Loading /usr/local/lib/xorg/modules/libfb.so [ 1146.451] (II) Module fb: vendor="X.Org Foundation" [ 1146.451] compiled for 1.14.7, module version = 1.0.0 [ 1146.451] ABI class: X.Org ANSI C Emulation, version 0.4 [ 1146.452] (==) Depth 24 pixmap format is 32 bpp [ 1146.452] (II) Loading sub module "int10" [ 1146.452] (II) LoadModule: "int10" [ 1146.452] (II) Loading /usr/local/lib/xorg/modules/libint10.so [ 1146.453] (II) Module int10: vendor="X.Org Foundation" [ 1146.453] compiled for 1.14.7, module version = 1.0.0 [ 1146.453] ABI class: X.Org Video Driver, version 14.1 [ 1146.453] (II) VESA(0): initializing int10 [ 1146.454] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 1146.454] (II) VESA(0): VESA BIOS detected [ 1146.454] (II) VESA(0): VESA VBE Version 3.0 [ 1146.454] (II) VESA(0): VESA VBE Total Mem: 4096 kB [ 1146.454] (II) VESA(0): VESA VBE OEM: SeaBIOS VBE(C) 2011 [ 1146.454] (II) VESA(0): VESA VBE OEM Software Rev: 0.0 [ 1146.454] (II) VESA(0): VESA VBE OEM Vendor: SeaBIOS Developers [ 1146.454] (II) VESA(0): VESA VBE OEM Product: SeaBIOS VBE Adapter [ 1146.454] (II) VESA(0): VESA VBE OEM Product Rev: Rev. 1 [ 1146.456] (II) VESA(0): virtual address = 0x804400000, physical address = 0xfc000000, size = 4194304 [ 1146.457] (EE) Illegal instruction at address 0x4a40d0 [ 1146.458] (EE) Fatal server error: [ 1146.458] (EE) Caught signal 4 (Illegal instruction). Server aborting [ 1146.458] (EE) [ 1146.458] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1146.458] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 1146.458] (EE) [ 1146.483] (EE) Server terminated with error (1). Closing log file.
Same problem here on 10.2, but this is inside a Hyper-V VM on Windows 10. Gives the same error address of 0x4a40d0 but a different code: signal 10 (bus error). I also rent a dedicated server running 10.2 and they use KVM/QEMU. Don't get an error on starting X, but the virtual console screen displays random colours and freezes; the VM shows as "paused" until manual intervention.
FreeBSD forum link for same/similar issue: https://forums.freebsd.org/threads/10-1-kvm-guest-cant-startx-ee-illegal-instruction-at-address-0x4a40f0.50953/ The editing /etc/make.conf solution provided there worked on my Hyper-V VM, until I did a "pkg upgrade" today without thinking and that broke it again. Haven't tried it yet on my dedicated server as I can't be sure it's the same issue.
This may have something to do with SeaBIOS (what kvm and qemu use). I just installed 10.2-RELEASE amd64 on VMware, then installed all X.org packages using pkg, and it ran just fine. The VESA part of Xorg.log goes: [ 578.712] (II) VESA(0): initializing int10 [ 578.712] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 578.712] (II) VESA(0): VESA BIOS detected [ 578.712] (II) VESA(0): VESA VBE Version 2.0 [ 578.712] (II) VESA(0): VESA VBE Total Mem: 65536 kB [ 578.712] (II) VESA(0): VESA VBE OEM: V M ware, Inc. VBE support 2.0 [ 578.712] (II) VESA(0): VESA VBE OEM Software Rev: 2.0 [ 578.712] (II) VESA(0): VESA VBE OEM Vendor: VMware, Inc [ 578.712] (II) VESA(0): VESA VBE OEM Product: VMware virtual machine [ 578.712] (II) VESA(0): VESA VBE OEM Product Rev: 2.0 [ 578.724] (II) VESA(0): virtual address = 0x804400000, physical address = 0xe8000000, size = 67108864 [ 578.728] (II) VESA(0): Setting up VESA Mode 0x164 (1280x720) [ 578.764] (==) VESA(0): Default visual is TrueColor [ 578.764] (==) VESA(0): Backing store disabled [ 578.764] (==) VESA(0): DPMS enabled I'll try it on Hyper-V next.
Actually tried it on kvm, where you indeed get this crash. It looks like a bug in xf86SlowBcopy: Program received signal SIGILL, Illegal instruction. [Switching to Thread 803406400 (LWP 100055/Xorg)] 0x00000000004a40d0 in xf86SlowBcopy () (gdb) disassemble Dump of assembler code for function xf86SlowBcopy: [...snip...] 0x00000000004a40d0 <xf86SlowBcopy+128>: movups (%rdi,%rax,1),%xmm0 0x00000000004a40d4 <xf86SlowBcopy+132>: movups 0x10(%rdi,%rax,1),%xmm1 0x00000000004a40d9 <xf86SlowBcopy+137>: movups %xmm0,(%rsi,%rax,1) 0x00000000004a40dd <xf86SlowBcopy+141>: movups %xmm1,0x10(%rsi,%rax,1) 0x00000000004a40e2 <xf86SlowBcopy+146>: add $0x20,%rax 0x00000000004a40e6 <xf86SlowBcopy+150>: cmp %rax,%rdx 0x00000000004a40e9 <xf86SlowBcopy+153>: jne 0x4a40d0 <xf86SlowBcopy+128> E.g. it crashes on that movups. No idea why it thinks that is an illegal instruction, though. It certainly isn't, on amd64. The registers are: (gdb) info registers rax 0x0 0 rbx 0x803452280 34414600832 rcx 0x0 0 rdx 0x2000 8192 rsi 0x803502000 34415321088 rdi 0x800899000 34368753664 rbp 0x7fffffffe8d0 0x7fffffffe8d0 rsp 0x7fffffffe8d0 0x7fffffffe8d0 r8 0x2000 8192 r9 0x80089b000 34368761856 r10 0x803504000 34415329280 r11 0x803401830 34414270512 r12 0x803452280 34414600832 r13 0x3c4 964 r14 0x3c5 965 r15 0x1 1 rip 0x4a40d0 0x4a40d0 <xf86SlowBcopy+128> eflags 0x13246 78406 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 I restarted it a bunch of times, and it crashes with SIGILL about half of the time. The other times it starts OK, and seems to work...
Indeed, as a forum comment suggested. But here's the weird thing (unless I'm much mistaken): in that comment the author mentions a particular library that needs to be recompiled with gcc instead of clang... ... HOWEVER, if I take a "working" version of that library and graft it onto a system producing the error with no other changes, it doesn't actually solve the problem... :/
(In reply to Ephelyon from comment #5) > But here's the weird thing (unless I'm much mistaken): in that comment the > author mentions a particular library that needs to be recompiled with gcc > instead of clang... Maybe gcc does not emit the SSE instructions, and then it appears to work. However, they *should* work, since amd64 always supports SSE.
Exactly what instruction sets are we talking about here? A number of (quite modern) AMD CPUs don't support SSSE3, for example...
(In reply to Ephelyon from comment #7) > Exactly what instruction sets are we talking about here? > > A number of (quite modern) AMD CPUs don't support SSSE3, for example... movups is just plain SSE (SSE1, if you will).
Is any of this of any help? http://iswwwup.com/t/3c659feae5bc/persuading-the-compiler-to-set-registers-outside-a-loop.html
(In reply to Ephelyon from comment #7) I'm the person who posted the original bug report. About the SSSE3 thing... I am running an old MacBook pro from 2008. I don't know what SSSE3 is, but my computer does have "hardware virtualization." I can run a command to check the hardware if you tell me what to enter. My main desktop right now is Debian 8 (I virtualize FreeBSD).
I think the virtualisation element might be the key issue here. If you were to run FreeBSD natively on that hardware - and I'm not asking you to, it's just to highlight the issue - my suspicion is that Xorg would probably work.
(In reply to Ephelyon from comment #11) > I think the virtualisation element might be the key issue here. If you were to run FreeBSD natively on that hardware - and I'm not asking you to, it's just to highlight the issue - my suspicion is that Xorg would probably work. If I boot from a live DVD, would that suffice as a test? Is this a live DVD: File:FreeBSD-10.2-RELEASE-amd64-dvd1.iso Would that answer who should fix the bug (KVM vs FreeBSD)? Should FreeBSD fix it to work with KVM for the purpose of backward compatibility??
Nobody knows what the actual root cause is, so at the moment there is nothing to fix. A workaround is to just start Xorg again, and then it might work. If I would have to guess now, I would say there's some bug in qemu that is triggered by the int10 x86 emulator. It is not strictly related to virtualization, since the problem does not occur at all in VMware: no matter how many times I restart Xorg, it always works correctly.
Does that not suggest the real bug is related to the virtual hardware set that a particular hypervisor chooses to expose?
(In reply to Ephelyon from comment #14) > Does that not suggest the real bug is related to the virtual hardware set > that a particular hypervisor chooses to expose? It does not seem likely. In my own test setup, qemu/kvm just runs a regular x86_64 instance, which exposes the minimum subset that all x86_64 processors share. This includes at least SSE and SSE2.
(In reply to Ephelyon from comment #14) I can run FreeBSD 10.1 in the same KVM/qemu setup that fails when I try to run 10.2. I install the VM with scripts, so the setup options are the same. Something changed, but what changed I don't know. I am running virtualized 10.1 right now.
What I meant was that there would seem to be a bug (or other change) in 10.2, but not 10.1, that relates to the set of virtual hardware exposed.
(In reply to nogcjx from comment #16) > I can run FreeBSD 10.1 in the same KVM/qemu setup that fails when I try to > run 10.2. I install the VM with scripts, so the setup options are the same. > Something changed, but what changed I don't know. I am running virtualized > 10.1 right now. Maybe you were just lucky, as it *does* crash for me on FreeBSD 10.1-RELEASE. I started both 10.1-RELEASE and 10.2-RELEASE instances on KVM, installed all of xorg with pkg (from the 'latest' pkg repo), and started /usr/local/bin/Xorg on them. Both crash with: Program received signal SIGILL, Illegal instruction. [Switching to Thread 803406400 (LWP 100054/Xorg)] 0x00000000004a40d0 in xf86SlowBcopy () (gdb) bt #0 0x00000000004a40d0 in xf86SlowBcopy () #1 0x0000000802dd2b99 in VESASaveRestore () from /usr/local/lib/xorg/modules/drivers/vesa_drv.so #2 0x0000000802dd1e27 in VESAScreenInit () from /usr/local/lib/xorg/modules/drivers/vesa_drv.so #3 0x0000000000439ec0 in AddScreen () #4 0x000000000047e104 in InitOutput () #5 0x0000000000429056 in _start () #6 0x0000000000428d4f in _start () #7 0x0000000800814000 in ?? () #8 0x0000000000000000 in ?? () I'll see if it gives a little more information to rebuild these with debug info.
Created attachment 160694 [details] Disable SSE for hw/xfree86/os-support/misc/SlowBcopy.c This patch works for me, can the original submitters please try dropping it in /usr/ports/x11-servers/xorg-server/files, and then rebuilding and reinstalling /usr/ports/x11-servers/xorg-server? I think what is happening is the following: - Xorg calls the VESA driver's VESAScreenInit() function - VESAScreenInit() calls VESAMapVidMem(), which uses pci_device_map_legacy() to map PCI memory into pVesa->VGAbase - VESAScreenInit() later calls VESASaveRestore(), which in turn calls SaveFonts() - SaveFonts() (and its inverse RestoreFonts()) calls xf86SlowBcopy(), with pVesa->VGAbase as source address - For some reason, QEmu does not like copying from the just-mapped PCI memory using SSE instructions (e.g. movups) - QEmu throws either an illegal instruction exception, or some other exception (which causes either SIGILL or SIGBUS) I'm guessing that this is the whole reason for the existence of a "slow bcopy" function in X.org: the function attempts to "slowly" copy byte by byte, even inserting outb(0x80, 0x00) instructions in between, if the really_slow_bcopy flag is set. However, clang recognizes the "while (len--) *dst++ = *src++;" idiom, and replaces this with SSE, which leads to QEmu throwing a fit, as described above. Note that this may very well also occur with newer gcc versions, since those will probably also transform copying loops into SSE. In any case, to make the "slow bcopy" really slow again, and avoid QEmu blowing up, I've added -mno-sse to the CFLAGS for the SlowBcopy.c file. (This flag is only needed on x86, btw.) The resulting assembly does not use SSE anymore, but just old-fashioned byte by byte copying: 0000000000000010 <xf86SlowBcopy>: [...] 47: 85 c9 test %ecx,%ecx 49: 74 15 je 60 <xf86SlowBcopy+0x50> 4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 50: ff c9 dec %ecx 52: 8a 07 mov (%rdi),%al 54: 48 8d 7f 01 lea 0x1(%rdi),%rdi 58: 88 06 mov %al,(%rsi) 5a: 48 8d 76 01 lea 0x1(%rsi),%rsi 5e: 75 f0 jne 50 <xf86SlowBcopy+0x40> 60: 5d pop %rbp 61: c3 retq
(In reply to Dimitry Andric from comment #19) >can the original submitters please try dropping it in /usr/ports/x11-servers> > /xorg-server/files, and then rebuilding and reinstalling > /usr/ports/x11-servers/xorg-server? I will see if I know where to put the patch when I finish the current test (seeing if a new install of 10.1 fails under qemu/KVM).
1 out of 1 hunks failed Patch failed to apply cleanly
(In reply to Ephelyon from comment #21) > 1 out of 1 hunks failed > Patch failed to apply cleanly Strange, it works fine for me. How did you download the patch, where did you put it, and what commands did you execute to build the port?
Couldn't see where to download it as a literal file so copied the text into a new file named patch-Xserver-hw-xfree86-os-support-misc-Makefile.in saved to /usr/ports/x11-servers/xorg-server/files. Then changed to that directory and ran: make clean make install BATCH=yes
Hmm, sometimes these files end up with DOS line endings, or get mangled in some other way. Can you please check whether the MD5 hash of the patch file is 232370b3f51cddb15de8a1f1bb06750b?
Hehe, very embarrassed now but yes, the problem was DOS line endings (file created on my Windows box and FTP'd over). Fixed with awk. Now recompiled and tested successfully - you have solved it, sir! :)
(In reply to Dimitry Andric from comment #18) The patch does work for me for 10.2, so that's good news. Related to the 10.1 situation, Dimitry said: > Maybe you were just lucky, as it *does* crash for me on FreeBSD 10.1-RELEASE. My old install of 10.1 still runs in my kvm/qemu virtual environment, but I tried create a new one with the old 10.1 install disk and I got the same error. I'm not sure where I created the old install that still runs (I have been running different OSs and I ship the binary image to other computers) but the one I created today was on a Debian 8 host. Maybe that means the kvm/qemu environment changed, but now that the patch works it is a moot point. thanks to everybody. For a recap: 1) Install 10.2 in your KVM/qemu environment and be sure to include the ports tree. 2) download the patch -- the web page does not work for my seamonkey browser, but the file can be retrieved with this curl command (if the backslashes work correctly in this forum): <code> curl -L --url https://bugs.freebsd.org/bugzilla/attachment.cgi?id=160694\&action=diff\&context=patch\&collapsed=\&headers=1\&format=raw -o patch-Xserver-hw-xfree86-os-support-misc-Makefile.in </code> 3) put the downloaded text into a new file named patch-Xserver-hw-xfree86-os-support-misc-Makefile.in saved to /usr/ports/x11-servers/xorg-server/files. 4) from the command line, change directory to /usr/ports/x11-servers/xorg-server and run make install BATCH=yes 5) you probably have to make and install /usr/ports/xorg too. 6) run startx to run the graphical desktop. 7) you might have conflicts if you try to install other things from pkg, so you might have to use ports to install other packages???
Thanks for the confirmations. Dear freebsd-x11@, can I now please add the patch-Xserver-hw-xfree86-os-support-misc-Makefile.in to the xorg-server port? Also, are you aware of that particular SlowBcopy.c file being used in any other xorg component?
With my x11@ I do approve that patch, Dimitry please commit (bumping port revision)
A commit references this bug: Author: dim Date: Sat Sep 5 11:57:53 UTC 2015 New revision: 396167 URL: https://svnweb.freebsd.org/changeset/ports/396167 Log: Disable use of SSE instructions in Xorg's xf86SlowBcopy() function. When such instructions are used to copy data from/to mapped video memory, some hypervisors (e.g. KVM, Microsoft Hyper-V) can generate SIGILL or SIGBUS exceptions, causing Xorg to crash. Reported by: nogcjx@fastmail.fm Approved by: x11 (bapt) PR: 202643 MFH: 2015Q3 Changes: head/x11-servers/xorg-server/Makefile head/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-misc-Makefile.in
A commit references this bug: Author: dim Date: Sat Sep 5 14:34:19 UTC 2015 New revision: 396175 URL: https://svnweb.freebsd.org/changeset/ports/396175 Log: MFH: r396167 Disable use of SSE instructions in Xorg's xf86SlowBcopy() function. When such instructions are used to copy data from/to mapped video memory, some hypervisors (e.g. KVM, Microsoft Hyper-V) can generate SIGILL or SIGBUS exceptions, causing Xorg to crash. Reported by: nogcjx@fastmail.fm Approved by: ports-secteam (feld) PR: 202643 Changes: _U branches/2015Q3/ branches/2015Q3/x11-servers/xorg-server/Makefile branches/2015Q3/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-misc-Makefile.in
Any updates on this? I again encountered this bug. Xorg crashing on Qemu KVM (with illegal instruction error) when it is installed by pkg or build from ports with clang. Building x11-servers/xorg-server port with gcc results working Xorg. My CPU is Intel Core i5 6200U, I'm using Qemu KVM on Antergos. I run virtual machine from command line with this parameters: "qemu-system-x86_64 -enable-kvm -cpu host -smp cores=2 -m 2048 -drive file=fbsd.qcow2,if=virtio,index=0 -soundhw hda -vga std"
(In reply to gcx61 from comment #31) > Any updates on this? I again encountered this bug. Obviously not, this bug was closed years ago. You are the first person to report anything new. :) > Xorg crashing on Qemu KVM > (with illegal instruction error) when it is installed by pkg or build from > ports with clang. Building x11-servers/xorg-server port with gcc results > working Xorg. > > My CPU is Intel Core i5 6200U, I'm using Qemu KVM on Antergos. I run virtual > machine from command line with this parameters: > "qemu-system-x86_64 -enable-kvm -cpu host -smp cores=2 -m 2048 -drive > file=fbsd.qcow2,if=virtio,index=0 -soundhw hda -vga std" It would be more informative to have a backtrace or some other information about the actual crash, so we can be certain it is a similar issue as was reported originally in this bug. If it is a different type of crash, we should create a new PR instead.
Created attachment 184779 [details] Re-add dropped patch to disable SSE in SlowBcopy.c Aha, I see now what has happened: in ports r433863 ("Xorg-servers update to 1.18.4 with driver updates and revision bumps"), the patch we added for this PR got dropped, probably accidentally. Here is a rebased patch. I have verified that SlowBcopy.c is now compiled properly, and the resulting object file does not contain SSE instructions anymore.
(In reply to Dimitry Andric from comment #33) Indeed this was accidentally dropped in the shuffle. Thank you for verifying that restoring the patch restores correct behavior. I have added this to the 1.19 WIP with a brief comment in the patch.
I'm(In reply to Dimitry Andric from comment #32) I'm sorry for not responding. Error is same as before - illegal instruction in xf86SlowBcopy. I can add log, but You re-added patch. Thank You very much for verifying this. I can still attach log if You want it, but I think it shouldn't be necessary.
Created attachment 195183 [details] Xorg logs Looks like this is still an issue with 11.2, unfortunately. Fresh 11.2 install into a KVM/QEMU domain managed by virt-install running on Ubuntu.
Same problem with the QEMU variant used in official QNAP Network Attached Storage machines using their official Virtualization Station.
It seems the patch was still not added to x11-servers/xorg-server. Niclas or Koop, are you OK with me committing that? (And probably bumping port revision?)
This bug appears to still exist, now in FreeBSD 12.0. I've tested in kvm/qemu as of 7 January 2019. [ 183.347] (EE) Backtrace: [ 183.349] (EE) 0: ? (?+0xee5c5c) [0x8012e670c] [ 183.349] (EE) 1: /lib/libthr.so.3 (pthread_sigmask+0x544) [0x800aec924] [ 183.350] (EE) 2: /lib/libthr.so.3 (pthread_getspecific+0xe12) [0x800aec6f2] [ 183.351] (EE) 3: ? (?+0xe12) [0x7ffffffffe15] [ 183.351] (EE) 4: /usr/local/bin/X (?+0xe12) [0x2f5262] [ 183.352] (EE) 5: /usr/local/lib/xorg/modules/drivers/vesa_drv.so (?+0xe12) [0x801acc582] [ 183.353] (EE) 6: /usr/local/lib/xorg/modules/drivers/vesa_drv.so (?+0xe12) [0x801acb842] [ 183.353] (EE) 7: /usr/local/bin/X (?+0xe12) [0x28c362] [ 183.354] (EE) 8: /usr/local/bin/X (?+0xe12) [0x2d3902] [ 183.355] (EE) 9: /usr/local/bin/X (?+0xe12) [0x28ff42] [ 183.355] (EE) 10: /usr/local/bin/X (?+0xe12) [0x279e12] [ 183.356] (EE) 11: ? (?+0xe12) [0x80043de12] [ 183.356] (EE) [ 183.356] (EE) Illegal instruction at address 0x2f4580 [ 183.356] (EE) Fatal server error: [ 183.356] (EE) Caught signal 4 (Illegal instruction). Server aborting [ 183.356] (EE) [ 183.356] (EE)
A commit references this bug: Author: zeising Date: Wed Jan 9 07:25:56 UTC 2019 New revision: 489754 URL: https://svnweb.freebsd.org/changeset/ports/489754 Log: Fix illegal instruction when running in kvm/qemu Fix illegal instruction when running xserver in kvm or qemu (and possibly others) virtualisation. This is solved by disabling sse instructions while compiling the xf86SlowBcopy (don't ask) function. This fix was originally committed by dim as r396167 in 2015, and then most likely accidentally removed in r433863 in 2017. Bump portrevision Original commit message: > Disable use of SSE instructions in Xorg's xf86SlowBcopy() function. > > When such instructions are used to copy data from/to mapped video > memory, some hypervisors (e.g. KVM, Microsoft Hyper-V) can generate > SIGILL or SIGBUS exceptions, causing Xorg to crash. PR: 202643 Reported by: nogcjx@fastmail.fm Requested by: dim Diagnose and fix by: dim MFH: 2019Q1 Changes: head/x11-servers/xorg-server/Makefile head/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-misc-Makefile.in
Committed (again). Awaiting MFH approval.
A commit references this bug: Author: zeising Date: Wed Jan 9 17:52:04 UTC 2019 New revision: 489817 URL: https://svnweb.freebsd.org/changeset/ports/489817 Log: MFH: r489754 Fix illegal instruction when running in kvm/qemu Fix illegal instruction when running xserver in kvm or qemu (and possibly others) virtualisation. This is solved by disabling sse instructions while compiling the xf86SlowBcopy (don't ask) function. This fix was originally committed by dim as r396167 in 2015, and then most likely accidentally removed in r433863 in 2017. Bump portrevision Original commit message: > Disable use of SSE instructions in Xorg's xf86SlowBcopy() function. > > When such instructions are used to copy data from/to mapped video > memory, some hypervisors (e.g. KVM, Microsoft Hyper-V) can generate > SIGILL or SIGBUS exceptions, causing Xorg to crash. PR: 202643 Reported by: nogcjx@fastmail.fm Requested by: dim Diagnose and fix by: dim Approved by: ports-secteam (miwi) Changes: _U branches/2019Q1/ branches/2019Q1/x11-servers/xorg-server/Makefile branches/2019Q1/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-misc-Makefile.in
Merged, closing.
Thanks! Sorry for the noob question, but is this available via ports now? I compiled and installed /usr/ports/x11/xorg but got the same error when launching with startx. Is there something else I need to do to compile this? Thanks!
I actually got it to work now by compiling the port. Don't know what I did wrong the first time. X11 boots fine now. Thanks for fixin' and sorry for the chatter here in the bug report!