Bug 202643 - x11-servers/xorg-server: illegal instruction starting xorg in FreeBSD >10.x in kvm/qemu virtualization
Summary: x11-servers/xorg-server: illegal instruction starting xorg in FreeBSD >10.x i...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Dimitry Andric
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-25 06:38 UTC by nogcjx
Modified: 2019-01-11 17:57 UTC (History)
12 users (show)

See Also:
zeising: merge-quarterly+


Attachments
logs, Xconfigure, pciconf, pkg info (core dump not here but is available) (30.00 KB, application/x-tar)
2015-08-25 06:38 UTC, nogcjx
no flags Details
Disable SSE for hw/xfree86/os-support/misc/SlowBcopy.c (470 bytes, patch)
2015-09-03 22:59 UTC, Dimitry Andric
no flags Details | Diff
Re-add dropped patch to disable SSE in SlowBcopy.c (1.16 KB, patch)
2017-07-27 21:43 UTC, Dimitry Andric
no flags Details | Diff
Xorg logs (55.70 KB, text/plain)
2018-07-17 00:21 UTC, Jack Neely
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nogcjx 2015-08-25 06:38:19 UTC
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.
Comment 1 Ephelyon 2015-08-25 17:09:50 UTC
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.
Comment 2 Ephelyon 2015-08-25 17:14:25 UTC
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.
Comment 3 Dimitry Andric freebsd_committer 2015-09-02 18:31:30 UTC
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.
Comment 4 Dimitry Andric freebsd_committer 2015-09-02 19:22:07 UTC
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...
Comment 5 Ephelyon 2015-09-02 19:30:06 UTC
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... :/
Comment 6 Dimitry Andric freebsd_committer 2015-09-02 20:42:01 UTC
(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.
Comment 7 Ephelyon 2015-09-02 20:47:27 UTC
Exactly what instruction sets are we talking about here?

A number of (quite modern) AMD CPUs don't support SSSE3, for example...
Comment 8 Dimitry Andric freebsd_committer 2015-09-02 20:53:19 UTC
(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).
Comment 10 nogcjx 2015-09-02 21:02:49 UTC
(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).
Comment 11 Ephelyon 2015-09-02 21:05:06 UTC
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.
Comment 12 nogcjx 2015-09-02 21:13:10 UTC
(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??
Comment 13 Dimitry Andric freebsd_committer 2015-09-02 21:16:15 UTC
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.
Comment 14 Ephelyon 2015-09-02 21:17:41 UTC
Does that not suggest the real bug is related to the virtual hardware set that a particular hypervisor chooses to expose?
Comment 15 Dimitry Andric freebsd_committer 2015-09-02 21:25:42 UTC
(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.
Comment 16 nogcjx 2015-09-02 21:28:30 UTC
(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.
Comment 17 Ephelyon 2015-09-03 18:27:38 UTC
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.
Comment 18 Dimitry Andric freebsd_committer 2015-09-03 19:51:09 UTC
(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.
Comment 19 Dimitry Andric freebsd_committer 2015-09-03 22:59:18 UTC
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
Comment 20 nogcjx 2015-09-04 00:21:22 UTC
(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).
Comment 21 Ephelyon 2015-09-04 16:58:15 UTC
1 out of 1 hunks failed
Patch failed to apply cleanly
Comment 22 Dimitry Andric freebsd_committer 2015-09-04 17:57:14 UTC
(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?
Comment 23 Ephelyon 2015-09-04 18:12:50 UTC
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
Comment 24 Dimitry Andric freebsd_committer 2015-09-04 18:44:32 UTC
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?
Comment 25 Ephelyon 2015-09-04 19:49:44 UTC
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! :)
Comment 26 nogcjx 2015-09-05 06:47:15 UTC
(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???
Comment 27 Dimitry Andric freebsd_committer 2015-09-05 10:14:50 UTC
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?
Comment 28 Baptiste Daroussin freebsd_committer 2015-09-05 10:50:35 UTC
With my x11@ I do approve that patch, Dimitry please commit (bumping port revision)
Comment 29 commit-hook freebsd_committer 2015-09-05 11:58:33 UTC
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
Comment 30 commit-hook freebsd_committer 2015-09-05 14:34:49 UTC
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
Comment 31 gcx61 2017-07-27 19:44:38 UTC
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"
Comment 32 Dimitry Andric freebsd_committer 2017-07-27 20:45:51 UTC
(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.
Comment 33 Dimitry Andric freebsd_committer 2017-07-27 21:43:06 UTC
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.
Comment 34 Matthew Rezny freebsd_committer 2017-07-30 12:02:21 UTC
(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.
Comment 35 gcx61 2017-08-03 15:14:31 UTC
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.
Comment 36 Jack Neely 2018-07-17 00:21:45 UTC
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.
Comment 37 Enver Haase 2018-12-12 10:20:47 UTC
Same problem with the QEMU variant used in official QNAP Network Attached Storage machines using their official Virtualization Station.
Comment 38 Dimitry Andric freebsd_committer 2018-12-12 12:09:34 UTC
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?)
Comment 39 Henrik 2019-01-08 16:35:06 UTC
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)
Comment 40 commit-hook freebsd_committer 2019-01-09 07:26:54 UTC
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
Comment 41 Niclas Zeising freebsd_committer 2019-01-09 07:30:39 UTC
Committed (again).  Awaiting MFH approval.
Comment 42 commit-hook freebsd_committer 2019-01-09 17:52:31 UTC
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
Comment 43 Niclas Zeising freebsd_committer 2019-01-09 18:02:06 UTC
Merged, closing.
Comment 44 Henrik 2019-01-10 22:12:38 UTC
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!
Comment 45 Henrik 2019-01-11 17:57:01 UTC
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!