xf86-video-intel segfaults unless forcing uxa acceleration on current BLFS-svn.

[ken@…]

With all-current versions of xorg packages, gcc5, system using linux-4.0.3 headers, xorg segfaults on my SandyBridge i3 using the default SNA acceleration.

Xorg works if I remove the intel driver and use ModeSetting from the server, so the intel driver is the problem.

Thanks to assistance from Armin (he said Chris narrowed down the issue to the SNA code), I've recompiled it with --enable-uxa (did not help on its own) and added a conf file to force uxa.

At the moment, I have no idea what has triggered this for me (current instructions worked in BLFS-7.7 with 3.19.0 headers), but the book's instructions no longer work on my hardware. I can fix this (add a switch and a conf file) but I cannot, at the moment, adequately explain why this is needed now.

[ken@…]

The pointer to SNA was on irc. I'll take this an put in an initial fix, people can change it later if a better form of words comes along.

[ken@…]

I can confirm that the current system can use a 3.19.0 kernel with SNA, so it seems to be an interaction between the kernel-4.0+ headers and gcc5, or perhaps just something unfortunate in the 4.0 headers themselves. There is an upstream workaround for gcc5, but that only fixes a build failure when -D_FORTIFY_SOURCE=2 is used.

So, it looks as if many intel SVN systems will need the UXA acceleration to be forced. The intel driver covers a wide-enough range that somebody probably has a system which will still work with SNA, so I think we should enable both variants in the driver and show people how to set up the conf file.

But I'm open to different opinions.

[ken@…]

NB current xf86-video-trunk fails to build with gcc-5(first error is in SNA code), upstream regard that as a known problem in gcc5. ​https://bugs.freedesktop.org/show_bug.cgi?id=90597

I'm thinking about building a new system with -g in my CFLAGS to try to get a useful backtrace from 2.99.917.

[bdubbs@…]

Pretty poor response. What known error in gcc5? Is there a workaround? Surely they don't expect user to revert to gcc-4.x. Surely inline doesn't produce that much overhead on most current systems.

[ken@…]

Replying to bdubbs@…:

Pretty poor response. What known error in gcc5? Is there a workaround? Surely they don't expect user to revert to gcc-4.x. Surely inline doesn't produce that much overhead on most current systems.

I think it is regarded as the same problem as ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873

If so, looks as if current git versions of the intel driver will not be usable with gcc-5.1.

But I only tried the git version to see if the segfault had already been fixed. Unfortunately, we are on the bleeding edge here, along with Arch.

[ken@…]

Initial workaround committed in r16014. This ticket should remain open pending attempts to get a more detailed diagnosis and a better fix.

[ken@…]

The initial comment from upstream was that this is a known problem which has been fixed in libdrm. There is now (25th May) also a commit in master to prevent the segfault - it applies to 2.99.917 but does not solve the problem there.

With gcc rebuilt to use the upstream_fixes-1 patch, I can build intel git master from 19th May and that worked fine using sna.

Closing, the workaround will have to do until there is a new release of libdrm and/or the intel driver.