[blfs-dev] #6526: xf86-video-intel segfaults unless forcing uxa acceleration on current BLFS-svn.
bruce.dubbs at gmail.com
Sun May 24 21:52:37 PDT 2015
Ken Moffat wrote:
> On Mon, May 25, 2015 at 04:44:22AM +0100, Ken Moffat wrote:
> only you didn't see it, because it was too big - must have been the
> attachment. Oh well, you can git clone for yourselves if you want
> to :-)
> Here is the actualy mail without the attachment.
>> On Mon, May 25, 2015 at 04:14:04AM +0100, Ken Moffat wrote:
>>> Normally, I run ../gcc-5.1.0/contrib/test_summary but that is giving
>>> me no output at all. ??? This is from upgrading gcc on the existing
>>> Also, the build and tests completed in just over 10 minutes, which
>>> is a lot less than I was expecting (SandyBridge i3, -j4). Colour me
>>> baffled and very much wishing I'd never touched this.
>> Well, I gave the git version of xf86-video-intel another try with
>> the patched compiler. Needs autoreconf -fiv (don't do like I did on
>> my first encounter and run ./autogen.sh, that did not work). As
>> Armin said, it builds ok, but I'm "once bitten, twice shy" so I
>> continued to enable uxa as well as the default sna.
>> Tested it, without the conf file to force uxa : seems to be working
>> fine (with the released libdrm).
>> I'm more confused than ever, and at a loss about which is the best
>> way forward.
>> AFAICS, we seem to have the following options:
>> 2. Use the intel driver from git, and mention that gcc-5.1.0 needs
>> to be patched.
Tried that and it worked for both sna and uxa. When I removed the 20-intel.conf
file, I did see:
[ 17878.141] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 17878.141] (++) using VT number 1
[ 17878.141] (--) controlling tty is VT number 1, auto-enabling KeepTty
[ 17878.141] (II) intel(0): Using Kernel Mode Setting driver: i915, version
[ 17878.141] (WW) Falling back to old probe method for modesetting
I'm not sure what that WW warning means, if anything. When I left the
20-intel.conf and just commented out the Option, it was not there.
>> We seem to be getting closer to using non-released versions of
>> everything :-(
Well, everything is a bit of an exaggeration. Generally it's because upstream
does not release "stable" packages in a timely manner (if at all).
>> Whatever we do, I think it would be a good idea to keep some info
>> about using uxa to work around sna problems. But perhaps that
>> belongs in the wiki ?
I think it's OK in the book as it is until a stable release is made.
More information about the blfs-dev