On Sun, May 24, 2015 at 07:04:18PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > >On Sat, May 23, 2015 at 03:26:47PM -0500, Bruce Dubbs wrote: > >>Armin K. wrote: > >>>On 23.05.2015 04:14, BLFS Trac wrote: > >>>>#6526: xf86-video-intel segfaults unless forcing uxa acceleration on > >>>>current BLFS- > >>>>svn. > >>>> 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. > >>>> > >>> > >>>Arch uses post-release GCC snapshots. So they already include all (most) > >>>patches > >>>from gcc 5 branch. > >> > >>For me the patch applies cleanly and the build is OK. I'm running tests > >>now. > >>I need to update some packages in LFS anyway so I'll add this patch and > >>start a new build on a system that uses the intel driver to see if that > >>fixes things up. Since I'll need to build X on the new system, I may not > >>get to that until tomorrow. > >> > >I intend to continue with the released version of the driver, to see > >if I can get a backtrace when I build an unstripped system. > > > >If not, or if that gets blamed on gcc, it will be useful to know if > >the git version will build with a patched version of gcc. > > I didn't do a git version, but I did build Xorg today with yesterday's LFS > svn. I built the following drivers in this order: > > libvdpau-1.1 > libevdev-1.4.2 > xf86-input-evdev-2.9.2 > xf86-input-synaptics > xf86-video-intel-2.99.917 > libva-1.5.1 > libva-intel-driver-1.5.1 > libvdpau-va-gl-0.3.4 > > My video is: > > 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor > Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) > Subsystem: Toshiba America Info Systems 4th Gen Core Processor Integrated > Graphics Controller > > model name : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz > > With the patch in gcc, everything built fine, but with the default sna > acceleration I *did* get a seg fault. > > Adding the /etc/X11/xorg.conf.d/20-intel.conf file as in the current book > did allow Xorg to come up. > Thanks. I've just started to build/test gcc with the upstream_fixes-1 patch.
Earlier, I managed to build enough of a system with '-g' in my CFLAGS, and managed to get a backtrace from xorg in gdb. [ aside: I luckily had a tarball of /tools because of issues while I was upgrading my scripts, and built LFS chroot without running any tests - I was shocked at how quickly that completed ;-) ] Filed at https://bugs.freedesktop.org/show_bug.cgi?id=90622 After filing that I became convinced it must be a kernel bug because 3.19.0 works (with gcc-5 and 4.0.3 headers) and 4.0+ do not. But Chris Wilson's initial response is that it is in libdrm and already fixed (I haven't looked at libdrm at the moment), although he wants to look some more at the backtrace. So, I guess I don't need to rebuild current libdrm / Mesa / xserver / intel : but I probably will, just to be sure. Depending what happens, I'll probably look at libdrm next, and then intel git. > One other thing. The first time I ran xorg, I had some driver failures. It > was easily fixed by running ldconfig, but we might want to consider adding > that to the instructions to run startx at the beginning of Xorg-7.7 Testing > and Configuration. > > -- Bruce > I guess it depends on what order you build the drivers, and whether or not you add any extras. Ideally, all the drivers and all the libs should run ldconfig, but it wouldn't be the first time that something didn't run that. Any idea which driver(s) were involved ? But perhaps it would just be easiest - and future proof - to add that to the Testing and Configuration instructions. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
