| Summary: | >=x11-drivers/xf86-video-intel-2.6.2: Xv use crashes X | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bob Raitz <pappy_mcfae> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | david |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.freedesktop.org/show_bug.cgi?id=20525 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | xf86-video-intel-9999.ebuild | ||
|
Description
Bob Raitz
2009-03-07 08:17:21 UTC
Downgrading to xf86-video-intel-2.6.1 solved the issue temporarily. Things operate normally with that driver version. Reassigning to x11 herd. Thanks for doing the grunt work of downgrading to check which bits caused the bug. Please file a bug over in FreeDesktop's bugzilla so that Intel devs can solve this bug. This document [1] will explain what these guys need. If you do, please paste the url here so we can keep track of the issue. Thanks again (In reply to comment #3) > Thanks for doing the grunt work of downgrading to check which bits caused the > bug. > > Please file a bug over in FreeDesktop's bugzilla so that Intel devs can solve > this bug. This document [1] will explain what these guys need. > > If you do, please paste the url here so we can keep track of the issue. > > Thanks again > DONE: https://bugs.freedesktop.org/show_bug.cgi?id=20525 Alright, thanks for doing this. Now upstream would like you to bisect the driver. That means using git's "bisect" command which will help cut down the number of commits to test to find the broken one. Here's how you can do that without messing up your system : - in a local dir, run : "git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel" - cd xf86-video-intel - git bisect start - git bisect good xf86-video-intel-2.6.1 - git bisect bad 2.6.3 Git bisect will now give you a commit number, copy it. - grab the xf86-video-intel-9999 ebuild from the x11 overlay [1] and copy it to a local overlay - edit the ebuild to have the following *before* the "inherit" line : EGIT_TREE="<commit number>" - run : ebuild xf86-video-intel-9999 digest and emerge that ebuild, do your testing. For every test that you do, run either "git bisect good" or "git bisect bad" if the driver works properly or not. After each bisect command, git will give you another commit number to try. Edit the ebuild, re-digest it and re-emerge the driver. Lather, rinse, repeat. Phew, that was long :) Hope you're able to get through that, if you have any questions, don't hesitate to ask here or come talk to us on #gentoo-desktop on FreeNode. Thanks (In reply to comment #5) > Alright, thanks for doing this. > > Now upstream would like you to bisect the driver. That means using git's > "bisect" command which will help cut down the number of commits to test to find > the broken one. > > Here's how you can do that without messing up your system : > > - in a local dir, run : "git clone > git://anongit.freedesktop.org/xorg/driver/xf86-video-intel" > - cd xf86-video-intel > - git bisect start > - git bisect good xf86-video-intel-2.6.1 > - git bisect bad 2.6.3 > > Git bisect will now give you a commit number, copy it. > > - grab the xf86-video-intel-9999 ebuild from the x11 overlay [1] and copy it to > a local overlay > - edit the ebuild to have the following *before* the "inherit" line : > EGIT_TREE="<commit number>" > - run : ebuild xf86-video-intel-9999 digest > > and emerge that ebuild, do your testing. > > For every test that you do, run either "git bisect good" or "git bisect bad" if > the driver works properly or not. After each bisect command, git will give you > another commit number to try. Edit the ebuild, re-digest it and re-emerge the > driver. Lather, rinse, repeat. > > Phew, that was long :) > > Hope you're able to get through that, if you have any questions, don't hesitate > to ask here or come talk to us on #gentoo-desktop on FreeNode. > > Thanks > You're telling me! I'll see what happens. Hopefully, the commit is early on, not the last house on the block. the xf86-video-intel-9999 I have isn't doing anything but failing, badly. Here's what I get: pappy-lap ~ # emerge -av =xf86-video-intel-9999 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-drivers/xf86-video-intel-9999 [2.6.1] USE="dri -debug" 0 kB [0=>1] Total: 1 package (1 upgrade), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /usr/local/portage Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) x11-drivers/xf86-video-intel-9999 from Local Portage Overlay * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * * ERROR: x11-drivers/xf86-video-intel-9999 failed. * Call stack: * ebuild.sh, line 49: Called pkg_setup * xf86-video-intel-9999.ebuild, line 37: Called built_with_use 'x11-base/xorg-server' 'dri' * eutils.eclass, line 1763: Called die * The specific snippet of code: * die) die "$PKG does not actually support the $1 USE flag!";; * The die message: * x11-base/xorg-server-1.5.3-r3 does not actually support the dri USE flag! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/die.env'. * This ebuild is from an overlay named 'Local Portage Overlay': '/usr/local/portage/' * >>> Failed to emerge x11-drivers/xf86-video-intel-9999, Log file: >>> '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/build.log' I have no idea why this is happening. I don't see git sources winding up anywhere. All I have is a failing ebuild. Hum, that's weird, it works fine here. Please make sure your portage tree is up to date as I did some changes to the x-modular eclass a couple days ago. Please also make sure you have the latest version of xorg-server (1.5.3-r3) installed. Thanks (In reply to comment #8) > Hum, that's weird, it works fine here. Please make sure your portage tree is up > to date as I did some changes to the x-modular eclass a couple days ago. > > Please also make sure you have the latest version of xorg-server (1.5.3-r3) > installed. > > Thanks > I sync daily. Please send me your ebuild, and I'll give it a try. You can do so privately so as not to make this thread longer than necessary. I'm not sure my ebuild is up to date. Thanks. Created attachment 184532 [details]
xf86-video-intel-9999.ebuild
This one should work.
Thanks
(In reply to comment #10) > Created an attachment (id=184532) [edit] > xf86-video-intel-9999.ebuild > > This one should work. > > Thanks > Unfortunately, it doesn't. It downloads whatever, and makes it into a .pack file. The pack file doesn't get decompressed into it's working directory, and it comes up with the following error: >>> Emerging (1 of 1) x11-drivers/xf86-video-intel-9999 from Local Portage Overlay * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * git update start --> * repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel * local clone: /usr/portage/distfiles/git-src/xf86-video-intel * committish: f1ed73c1ef3e3daa9f695194dcc813167cbcb53d fatal: not a tree object tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors >>> Unpacked to /var/tmp/portage/x11-drivers/xf86-video-intel-9999/work/xf86-video-intel-9999 >>> Source unpacked in /var/tmp/portage/x11-drivers/xf86-video-intel-9999/work >>> Compiling source in /var/tmp/portage/x11-drivers/xf86-video-intel-9999/work/xf86-video-intel-9999 ... make -j4 make: *** No targets specified and no makefile found. Stop. * * ERROR: x11-drivers/xf86-video-intel-9999 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3117: Called x-modular_src_compile * environment, line 3897: Called x-modular_src_make * environment, line 3936: Called die * The specific snippet of code: * emake || die "emake failed" * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/environment'. * This ebuild is from an overlay named 'Local Portage Overlay': '/usr/local/portage/' * >>> Failed to emerge x11-drivers/xf86-video-intel-9999, Log file: >>> '/var/tmp/portage/x11-drivers/xf86-video-intel-9999/temp/build.log' Wow, this is _really_ weird, I have no idea what's going on here... Does the -9999 ebuild work if you don't modify it (ie, the one directly from the x11 overlay)? Thanks (In reply to comment #12) > Wow, this is _really_ weird, I have no idea what's going on here... > > Does the -9999 ebuild work if you don't modify it (ie, the one directly from > the x11 overlay)? > > Thanks > No, it doesn't. It looks to me as if there is no decompression being done to the .pack file, or whatever is supposed to make this work. If I'm supposed to work to find which commit screwed me, I need to get a workable ebuild. There is no way I want to mess with my systems without being able to return to "stable". I think your git install might be broken. The -9999 ebuilds have been working correctly for months (if not years). Please try to remerge git, or something else, I don't know. Thanks FTR, it's not limited to DVDs, nor to KDE, nor to 945 :) I think I'll push commits that revert the changes. I'll just wait for upstream to comment a bit first. Thanks (In reply to comment #15) > FTR, it's not limited to DVDs, nor to KDE, nor to 945 :) > > I think I'll push commits that revert the changes. I'll just wait for upstream > to comment a bit first. > > Thanks > Yes, it also happens with gen-tosh, my old Toshiba laptop, and it has an I830 chipset. I haven't noticed it do it outside of kaffeine, but considering what I saw while bisecting, yes, it could affect other things. reopening I've committed 2.6.3-r1 which contains a backport of the upstream fix. This patch fixed the bug on my laptop. Closing fixed. Please don't hesitate to reopen this bug if the issue is still there. Thanks (In reply to comment #18) > I've committed 2.6.3-r1 which contains a backport of the upstream fix. > > This patch fixed the bug on my laptop. > > Closing fixed. Please don't hesitate to reopen this bug if the issue is still > there. > > Thanks > I'm going to give it a test here in a few. Thanks for the heads-up and I will definitely let you know if I find a problem. I've still the same bug with x11-base/xorg-server-1.5.3-r5 and x11-drivers/xf86-video-intel-2.6.3-r1. My emerge --info below : Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r8-x86_64-Intel-R-_Core-TM-2_Duo_CPU_L7500_@_1.60GHz-with-glibc2.2.5 Timestamp of tree: Mon, 13 Apr 2009 15:45:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.2-r7 dev-util/cmake: 2.4.8 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/ revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org http://distfiles.gentoo.org http://www.ibiblio.org/pub/L inux/distributions/gentoo" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="fr" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --s tats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 audiofile berkdb bzip2 cdda cddb cdio cli cracklib crypt cscope cups dbus dri dvd dvdr dvdread fbcondecor ffmpeg firefox flac fortran gdbm gnome gpm gstreamer gtk hal iconv id3 ipv6 isdnlog j ava jpeg midi mmx mp3 mpeg mudflap multilib musepack ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcr e pdf perl png pppd python readline reflection rtsp samba sdl session spl sse sse2 sse2sse3 ssl ssse3 svg sysfs t cpd theora tiff unicode vorbis x264 xorg xulrunner xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt8 7x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY I had some problems after the xorg upgrade and I fixed it by removing my xorg.cfg. Is there another package to rebuild besides xf86-video-intel ? (In reply to comment #19) > (In reply to comment #18) > > I've committed 2.6.3-r1 which contains a backport of the upstream fix. > > > > This patch fixed the bug on my laptop. > > > > Closing fixed. Please don't hesitate to reopen this bug if the issue is still > > there. > > > > Thanks This issue remains. Is there any movement in this at all? > > > > I'm going to give it a test here in a few. Thanks for the heads-up and I will > definitely let you know if I find a problem. > I have the same issue. Xorg crashes when using Xv extension. xf86-video-intel-2.6.3-r1 x11-base/xorg-server-1.5.3-r5 # git bisect start # git bisect good xf86-video-intel-2.6.1 # git bisect bad 2.6.3 I find this commit : 8ef4eb50193a849cb9fd0d7a85c6814e1d473101 is first bad commit commit 8ef4eb50193a849cb9fd0d7a85c6814e1d473101 Author: Eric Anholt <eric@anholt.net> Date: Mon Jan 19 14:43:20 2009 -0800 Do check_aperture_space and batch_start_atomic for i965 video. How can I help more ? I've commented on the upstream bug: you should open a new bug in FreeDesktop's bugzilla as the bug seems to be different enough. Don't forget to add "remi@gentoo.org" as a CC on the new bug so I can keep track of it. Thanks (In reply to comment #24) > I've commented on the upstream bug: you should open a new bug in FreeDesktop's > bugzilla as the bug seems to be different enough. > > Don't forget to add "remi@gentoo.org" as a CC on the new bug so I can keep > track of it. > > Thanks > I'll take care of that later on today. Thanks for the heads-up. BB! P Problem still persists. Or doesn't it? If it's fixed, please indicate where or the link to the second upstream bug report. Thanks! xf86-video-intel-2.6.3-r1 gentoo-sources-2.6.28-r5 xorg-server-1.5.3-r6 (In reply to comment #26) > Problem still persists. Or doesn't it? If it's fixed, please indicate where or > the link to the second upstream bug report. Thanks! > > xf86-video-intel-2.6.3-r1 > gentoo-sources-2.6.28-r5 > xorg-server-1.5.3-r6 > With that driver version, yes, it still persists. However, I am currently using x11-drivers/xf86-video-intel-2.7.1, 2.6.29-zen2, and x11-base/xorg-server-1.6.2-r1, and apart from the occasional nifty color patterns when X exits, it works.
> With that driver version, yes, it still persists. However, I am currently using
> x11-drivers/xf86-video-intel-2.7.1, 2.6.29-zen2, and
> x11-base/xorg-server-1.6.2-r1, and apart from the occasional nifty color
> patterns when X exits, it works.
Well, then the issue ain't fixed in my eyes. Sorry for the bickering, but I can't see how a bug is resolved when you have to install another unstable version of software that may bring other problems (Your combination, for instance, gives me nothing but a black screen)
"Stable" is supposed to work isn't it? I can see that yes, upstream may have fixed the bug in a more recent version of their driver but this "it's fixed in ~arch" leads to new problems instead of having a stable release that actually allows everyone to get his work done.
(In reply to comment #28) > > With that driver version, yes, it still persists. However, I am currently using > > x11-drivers/xf86-video-intel-2.7.1, 2.6.29-zen2, and > > x11-base/xorg-server-1.6.2-r1, and apart from the occasional nifty color > > patterns when X exits, it works. > > > Well, then the issue ain't fixed in my eyes. Sorry for the bickering, but I > can't see how a bug is resolved when you have to install another unstable > version of software that may bring other problems (Your combination, for > instance, gives me nothing but a black screen) > "Stable" is supposed to work isn't it? I can see that yes, upstream may have > fixed the bug in a more recent version of their driver but this "it's fixed in > ~arch" leads to new problems instead of having a stable release that actually > allows everyone to get his work done. > I'm with you on that one...but fixing a bug via attrition is valid. I'm doubly with you because I had to stick with 2.6.1 until 2.7.1 came out. However, it's not like either one of us is going to change the course of the river that is open source software. Therefore, I accept that things aren't always going to go my way. It was nearly a year before I could watch a DVD on this machine without wanting to chuck it out my third story window. I stuck with it, and things got better. If you want a better chance of things working right, switch to a .27 kernel. They are the last kernel versions untouched by GEM and other Intel killers. I know that this is a frustrating situation but _please_ understand that I don't have the knowledge nor the resources to fix those kinds of bugs. I just make sure that things build correctly in our packages and I forward bug reports to upstream. It's all I do because it's all I _can_ do. Thank you all for your patience. |
