Processing of xserver-xorg-video-intel_2.99.917-1~bpo8+1_amd64.changes
xserver-xorg-video-intel_2.99.917-1~bpo8+1_amd64.changes uploaded successfully to localhost along with the files: xserver-xorg-video-intel_2.99.917-1~bpo8+1.dsc xserver-xorg-video-intel_2.99.917.orig.tar.gz xserver-xorg-video-intel_2.99.917-1~bpo8+1.diff.gz xserver-xorg-video-intel_2.99.917-1~bpo8+1_amd64.deb xserver-xorg-video-intel-dbg_2.99.917-1~bpo8+1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yuxtn-sa...@franck.debian.org
xserver-xorg-video-intel: Changes to 'debian-jessie-backports'
debian/changelog |6 ++ 1 file changed, 6 insertions(+) New commits: commit 2b436a949c0a0579c733bb6da69e250855786131 Author: Vincent Cheng vch...@debian.org Date: Tue May 19 23:16:52 2015 -0700 rebuild for jessie-backports diff --git a/debian/changelog b/debian/changelog index 1593856..1afc011 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +xserver-xorg-video-intel (2:2.99.917-1~bpo8+1) jessie-backports; urgency=medium + + * Rebuild for jessie-backports. + + -- Vincent Cheng vch...@debian.org Tue, 19 May 2015 23:16:31 -0700 + xserver-xorg-video-intel (2:2.99.917-1) unstable; urgency=medium * Upload to unstable. (Closes: #748753) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yuxja-0007nt...@moszumanska.debian.org
xserver-xorg-video-intel: Changes to 'debian-jessie-backports'
New branch 'debian-jessie-backports' available with the following commits: -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yuxis-000530...@moszumanska.debian.org
xserver-xorg-video-intel_2.99.917-1~bpo8+1_amd64.changes is NEW
binary:xserver-xorg-video-intel is NEW. binary:xserver-xorg-video-intel-dbg is NEW. source:xserver-xorg-video-intel is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yuxzm-0001pk...@franck.debian.org
xserver-xorg-video-intel: Changes to 'refs/tags/xserver-xorg-video-intel-2_2.99.917-1-bpo8+1'
Tag 'xserver-xorg-video-intel-2_2.99.917-1-bpo8+1' created by Vincent Cheng vch...@debian.org at 2015-05-20 06:24 + Debian release 2:2.99.917-1~bpo8+1 Changes since xserver-xorg-video-intel-2_2.99.917-1: Vincent Cheng (1): rebuild for jessie-backports --- debian/changelog |6 ++ 1 file changed, 6 insertions(+) --- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yuxr3-0008t0...@moszumanska.debian.org
Bug#785448: Fwd: Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
Thanks for that. So my problem has narrowed down a bit (it still happens but I can fix it by changing the input colour format using the buttons on the side of the screen). The screen switches to use YCbCr input format: ** When the computer is booted up ** When I log in using kdm ** When the screen switches off after a period of inactivity I've used this screen for more than a year and it hasn't happened before. Is there any reason that the driver might set the input colour format to YCbCr, or is it possible for a Radeon card to set a hint for input colour format that could persist across a reboot? I'll try with the 4.1 kernel and see if anything changes. Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 19 May 2015 at 23:21, Alex Deucher alexdeuc...@gmail.com wrote: On Mon, May 18, 2015 at 4:32 AM, Owen Riddy owen.ri...@gmail.com wrote: No worries. It turns out that the problem was the Color Format of my screen. Dunno what that is, but it was configuring poorly and the open source driver seems happier when it is set to RGB rather than YCbCr. Maybe Catalyst is a bit more forgiving or maybe there is some configuration issue here I don't understand. My problem is solved; there may still be a minor bug here in how the auto-configuration of the driver works. The open source driver does not support YCbCr at the moment. Alex Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 17:41, Michel Dänzer mic...@daenzer.net wrote: On 18.05.2015 16:28, Owen Riddy wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. I guess I misunderstood the comments about fglrx in your original report. I agree it's probably a software bug then, though it's more likely in the kernel driver than in the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#785265: Segfault
I am getting this problem as well. I had two computers one of which was working after the recent set of updates in stretch and the other was crashing. I decided to check on differences in the installations and on the computer that was working I had all the xserver video packages installed and on the other I only had the package for the (Intel) graphics card in use. I deleted the extra packages from the working computer and it now crashes. I reinstalled all the deleted packages and it still crashes. The one thing I could not reinstall were the modesetting configuration files which I had purged. I would provide a gdb trace but I am hitting some problems. I am using lightdm and xfce so the instructions for getting a core file at http://x.debian.net/howto/use-gdb.html do not help. What should I set on my system? Also I do not have a file /etc/X11/core for # gdb -c /etc/X11/core /usr/bin/Xorg. And when I try Starting X from gdb I get a blank screen and an unresponsive system John -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yv0yc-0002zo...@rmm6prod02.runbox.com
Processed: severity of 775781 is normal
Processing commands for cont...@bugs.debian.org: severity 775781 normal Bug #775781 [src:mesa] mesa 10.4.2 from unstable won't build packages on jessie Severity set to 'normal' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 775781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775781 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.143210971627499.transcr...@bugs.debian.org
Bug#775781: Breaks debian policy ?
On Tue, May 19, 2015 at 22:33:36 +0200, Mathieu Malaterre wrote: Control: severity -1 grave AFAIK this should be considered grave issue as per §4.2 Package relationships. So clearly a Build-Conflicts is missing IMHO. A build-conflicts isn't missing, as explained before in this bug a --disable switch is missing. This does not a grave bug make. Cheers, Julien signature.asc Description: Digital signature
Bug#775781: Breaks debian policy ?
On Wed, May 20, 2015 at 10:23 AM, Julien Cristau jcris...@debian.org wrote: On Tue, May 19, 2015 at 22:33:36 +0200, Mathieu Malaterre wrote: Control: severity -1 grave AFAIK this should be considered grave issue as per §4.2 Package relationships. So clearly a Build-Conflicts is missing IMHO. A build-conflicts isn't missing, as explained before in this bug a --disable switch is missing. This does not a grave bug make. It should have been a `serious` severity since it is in violation of $4.2 (my mistake with grave): In particular, this means that version clauses should be used rigorously in build-time relationships so that one cannot produce bad or inconsistently configured packages when the relationships are properly satisfied. Technically one would need to define `produce bad`, since nothing is produced here...oh well -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+7wUsxaA-Whh=PrdYz4BaKWiyL+g4KpZjXkC8=muvt-smt...@mail.gmail.com
Re: Bug#785770: RM: xserver-xorg-video-siliconmotion [arm64] -- RoP; FTBFS; out-of-date; uninstallable; quite possiblly never worked, little if any utility
Control: tag -1 moreinfo On Wed, May 20, 2015 at 01:49:08 +0100, peter green wrote: I belive the out of date binary should be removed from sid for the following reasons. 1: it's uninstallable with the xorg currently in sid/stretch 2: while I have not investigated throughly it seems very likely that the use of stub versions of those functions would have rendered the driver unusable. 3: the siliconmotion chips in question seem to be obsolete parts mostly used for onboard graphics in old systems (though I did find one industrial minipcie card that claimed to use a siliconmotion chip, dunno if it's one supported by this driver). It seems unlikely that one would end up in an arm64 system. If this removal request is actioned I will downgrade bug 785491 Please don't do that quite yet. I'm still undecided whether to keep the package in the archive at all. Cheers, Julien signature.asc Description: Digital signature
Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver
I booted up into the install with fglrx installed, looked through the settings and found where the screen was being set to YCbCr, and set it to RGB. On rebooting my green tinged screen was gone. Thanks for your help. Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 20 May 2015 at 19:26, Owen Riddy owen.ri...@gmail.com wrote: Thanks for that. So my problem has narrowed down a bit (it still happens but I can fix it by changing the input colour format using the buttons on the side of the screen). The screen switches to use YCbCr input format: ** When the computer is booted up ** When I log in using kdm ** When the screen switches off after a period of inactivity I've used this screen for more than a year and it hasn't happened before. Is there any reason that the driver might set the input colour format to YCbCr, or is it possible for a Radeon card to set a hint for input colour format that could persist across a reboot? I'll try with the 4.1 kernel and see if anything changes. Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 19 May 2015 at 23:21, Alex Deucher alexdeuc...@gmail.com wrote: On Mon, May 18, 2015 at 4:32 AM, Owen Riddy owen.ri...@gmail.com wrote: No worries. It turns out that the problem was the Color Format of my screen. Dunno what that is, but it was configuring poorly and the open source driver seems happier when it is set to RGB rather than YCbCr. Maybe Catalyst is a bit more forgiving or maybe there is some configuration issue here I don't understand. My problem is solved; there may still be a minor bug here in how the auto-configuration of the driver works. The open source driver does not support YCbCr at the moment. Alex Owen Riddy Email: owen.ri...@gmail.com Mobile: 040 163 2663 -- On 18 May 2015 at 17:41, Michel Dänzer mic...@daenzer.net wrote: On 18.05.2015 16:28, Owen Riddy wrote: I have not, but if I reboot the computer to an install of Jessie using fglrx the tinge is not present; and it appeared shortly after updating to Jessie + unstable. I'll try a few things with the cable report back if any of them have an impact, but the fglrx test suggests this problem is 100% fixable in software. I guess I misunderstood the comments about fglrx in your original report. I agree it's probably a software bug then, though it's more likely in the kernel driver than in the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-driver-ati mailing list xorg-driver-...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#785940: xserver-xorg: xserver fails to start cannot read int vect
Package: xserver-xorg Version: 1:7.7+9 Severity: important Dear Maintainer, Updating to 1.17.1 renders xserver unable to start for some using VESA. It appears that a patch is in the ubuntu repositories but has not yet made it back to debian. Link below https://launchpad.net/ubuntu/+source/xorg-server/2:1.17.1-0ubuntu3 -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Feb 5 2014 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2384712 May 4 18:24 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1 to
Bug#786345: pixman: enable vmx for ppc64el
Source: pixman
Version: 0.32.6-3
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Dear Maintainer,
The package pixman had the usage of vmx disabled for ppc64el arch, because it
had tests failing when it was enabled.
That happened due to some differences on how data is treated from big to little
endian.
I am attaching a patch that re-enables vmx and includes some work arounds for
cases that have endianness conflicts.
I tested the patch on ppc64le and powerpc vms.
If you have questions or suggestions, please let me know.
Regards.
Fernando
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 3.16.0-4-powerpc64le (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u pixman-0.32.6/debian/changelog pixman-0.32.6/debian/changelog
--- pixman-0.32.6/debian/changelog
+++ pixman-0.32.6/debian/changelog
@@ -1,3 +1,10 @@
+pixman (0.32.6-3ppc64el1) UNRELEASED; urgency=medium
+
+ * Reenabled vmx for ppc64el and provided some workarounds so vmx works for
+both endiannesses.
+
+ -- Fernando Seiti Furusato ferse...@br.ibm.com Wed, 20 May 2015 15:21:10 -0400
+
pixman (0.32.6-3) sid; urgency=medium
[ intrigeri ]
diff -u pixman-0.32.6/debian/patches/series pixman-0.32.6/debian/patches/series
--- pixman-0.32.6/debian/patches/series
+++ pixman-0.32.6/debian/patches/series
@@ -1,2 +1,3 @@
-ppc64el.diff
+#ppc64el.diff
test-increase-timeout.diff
+vmx-le.patch
only in patch2:
unchanged:
--- pixman-0.32.6.orig/debian/patches/vmx-le.patch
+++ pixman-0.32.6/debian/patches/vmx-le.patch
@@ -0,0 +1,126 @@
+--- a/pixman/pixman-vmx.c
b/pixman/pixman-vmx.c
+@@ -34,13 +34,25 @@
+
+ #define AVV(x...) {x}
+
++#ifndef __LITTLE_ENDIAN__
++#define MERGEH(a,b) vec_mergeh(a,b)
++#define MERGEL(a,b) vec_mergel(a,b)
++#define SPLAT_VEC AVV( \
++ 0x00, 0x00, 0x00, 0x00, 0x04, 0x04, 0x04, 0x04, \
++ 0x08, 0x08, 0x08, 0x08, 0x0C, 0x0C, 0x0C, 0x0C)
++#else
++#define MERGEH(a,b) vec_mergeh(b,a)
++#define MERGEL(a,b) vec_mergel(b,a)
++#define SPLAT_VEC AVV( \
++ 0x03, 0x03, 0x03, 0x03, 0x07, 0x07, 0x07, 0x07, \
++ 0x0B, 0x0B, 0x0B, 0x0B, 0x0F, 0x0F, 0x0F, 0x0F)
++#endif
++
+ static force_inline vector unsigned int
+ splat_alpha (vector unsigned int pix)
+ {
+ return vec_perm (pix, pix,
+- (vector unsigned char)AVV (
+- 0x00, 0x00, 0x00, 0x00, 0x04, 0x04, 0x04, 0x04,
+- 0x08, 0x08, 0x08, 0x08, 0x0C, 0x0C, 0x0C, 0x0C));
++ (vector unsigned char)SPLAT_VEC);
+ }
+
+ static force_inline vector unsigned int
+@@ -50,11 +62,11 @@
+
+ /* unpack to short */
+ hi = (vector unsigned short)
+- vec_mergeh ((vector unsigned char)AVV (0),
++ MERGEH ((vector unsigned char)AVV (0),
+ (vector unsigned char)p);
+
+ mod = (vector unsigned short)
+- vec_mergeh ((vector unsigned char)AVV (0),
++ MERGEH ((vector unsigned char)AVV (0),
+ (vector unsigned char)a);
+
+ hi = vec_mladd (hi, mod, (vector unsigned short)
+@@ -67,10 +79,10 @@
+
+ /* unpack to short */
+ lo = (vector unsigned short)
+- vec_mergel ((vector unsigned char)AVV (0),
++ MERGEL ((vector unsigned char)AVV (0),
+ (vector unsigned char)p);
+ mod = (vector unsigned short)
+- vec_mergel ((vector unsigned char)AVV (0),
++ MERGEL ((vector unsigned char)AVV (0),
+ (vector unsigned char)a);
+
+ lo = vec_mladd (lo, mod, (vector unsigned short)
+@@ -125,25 +137,35 @@
+ }
+
+ /* in == pix_multiply */
++#ifndef __LITTLE_ENDIAN__
++#define MASK_SHIFT(pointer) vec_lvsl(0,pointer)
++#else
++#define MASK_SHIFT(pointer) \
++vec_xor(*((typeof(pointer ## _mask)*)pointer), \
++ (typeof(pointer ## _mask))AVV(\
++ 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, \
++ 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03))
++#endif
++
+ #define in_over(src, srca, mask, dest) \
+ over (pix_multiply (src, mask), \
+ pix_multiply (srca, mask), dest)
+
+-
+ #define COMPUTE_SHIFT_MASK(source) \
+-source ## _mask = vec_lvsl (0, source);
++source ## _mask = MASK_SHIFT(source);
+
+ #define COMPUTE_SHIFT_MASKS(dest, source)\
+-source ## _mask = vec_lvsl (0, source);
++source ## _mask = MASK_SHIFT(source);
+
+ #define COMPUTE_SHIFT_MASKC(dest, source, mask)\
+-mask ## _mask = vec_lvsl (0, mask); \
+-source ## _mask = vec_lvsl (0, source);
++mask ## _mask = MASK_SHIFT(mask); \
++source ## _mask = MASK_SHIFT(source);
+
+ /* notice you have to declare temp vars...
+ * Note: tmp3 and tmp4 must remain untouched!
+ */
+
++#ifndef __LITTLE_ENDIAN__
+ #define LOAD_VECTORS(dest, source) \
+ tmp1 = (typeof(tmp1))vec_ld (0, source); \
+ tmp2 = (typeof(tmp2))vec_ld (15, source); \
+@@ -162,11 +184,22 @@
+ v ## mask = (typeof(v ## mask))
Bug#785265: marked as done (xorg: SEG FAULT! CANNOT USE X!)
Your message dated Thu, 21 May 2015 07:41:40 +0800 with message-id 87r3qarf4b@jidanni.org and subject line Re: Bug#785265: xorg: SEG FAULT! CANNOT USE X! has caused the Debian Bug report #785265, regarding xorg: SEG FAULT! CANNOT USE X! to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 785265: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785265 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: xorg Version: 1:7.7+9 Severity: grave Justification: renders package unusable Starting today I cannot use X windows, thus cannot do almost anything anymore! Furthermore it is not clear which package I need to revert to its previous version to be able to hardly use my computer anymore! -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 2013-07-27 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2544344 05-05 06:49 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G [GeForce 6100] [10de:0242] (rev a2) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.0.0-1-686-pae (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) Xorg X server log files on system: -- -rw-r--r-- 1 root root 24454 05-14 07:41 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [94.673] X.Org X Server 1.17.1 Release Date: 2015-02-10 [94.673] X Protocol Version 11, Revision 0 [94.673] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian [94.673] Current Operating System: Linux jidanni6 4.0.0-1-686-pae #1 SMP Debian 4.0.2-1 (2015-05-11) i686 [94.673] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-686-pae root=UUID=d1f948b9-ebb5-45d8-bf20-035d65853302 ro panic=33 [94.673] Build Date: 04 May 2015 10:46:42PM [94.673] xorg-server 2:1.17.1-2 (http://www.debian.org/support) [94.673] Current version of pixman: 0.32.6 [94.673]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [94.673] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [94.673] (==) Log file: /var/log/Xorg.0.log, Time: Thu May 14 07:41:52 2015 [94.673] (==) Using system config directory /usr/share/X11/xorg.conf.d [94.674] (==) No Layout section. Using the first Screen section. [94.674] (==) No screen section available. Using defaults. [94.674] (**) |--Screen Default Screen Section (0) [94.674] (**) | |--Monitor default monitor [94.674] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [94.674] (==) Automatically adding devices [94.674] (==) Automatically enabling devices [94.674] (==) Automatically adding GPU devices [94.674] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [94.674]Entry deleted from font path. [94.674] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [94.674] (==) ModulePath set to /usr/lib/xorg/modules [94.675] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [94.675] (II) Loader magic: 0xb7709700 [94.675] (II) Module ABI versions: [94.675]X.Org ANSI C Emulation: 0.4 [94.675]X.Org Video Driver: 19.0 [94.675]X.Org XInput driver : 21.0 [94.675]X.Org Server Extension : 9.0 [94.675] (II) xfree86: Adding drm device (/dev/dri/card0) [94.678] (--) PCI:*(0:0:5:0) 10de:0242:: rev 162, Mem @ 0xfc00/16777216, 0xd000/268435456, 0xfb00/16777216, BIOS @ 0x/131072 [94.678] (II) LoadModule: glx [94.678] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [94.681] (II) Module glx: vendor=X.Org Foundation [94.681]compiled for 1.17.1,
Bug#785265: xorg: SEG FAULT! CANNOT USE X!
Of course now I am facing https://bugs.freedesktop.org/show_bug.cgi?id=36090 slow visual bell, and various artifacts upon ALT TAB window switching. All of which never happened a month ago. But I guess that is life. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbfmsqc8@jidanni.org
Bug#785265: xorg: SEG FAULT! CANNOT USE X!
JC == Julien Cristau jcris...@debian.org writes:
JC Please provide a backtrace from gdb. See
JC http://x.debian.net/howto/use-gdb.html
http://x.debian.net/howto/use-gdb.html doesn't mention NODM!
Please mention there:
In /etc/default/nodm say
{
NODM_X_OPTIONS='-nolisten tcp -core'
This will produce a core file in the root file system, /core.
}
# gdb -c /core /usr/bin/Xorg
GNU gdb (Debian 7.9-1) 7.9
Reading symbols from /usr/bin/Xorg...Reading symbols from
/usr/lib/debug/.build-id/8b/70d55debb4b00efecd44c0b860b6ee29e840ad.debug...done.
done.
[New LWP 25178]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
Core was generated by `/usr/bin/X :0 -nolisten tcp -core vt7'.
Program terminated with signal SIGABRT, Aborted.
#0 0xb748abe0 in __kernel_vsyscall ()
(gdb) bt
#0 0xb748abe0 in __kernel_vsyscall ()
#1 0xb706be07 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2 0xb706d3d9 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#3 0xb7656e79 in OsAbort () at ../../os/utils.c:1342
#4 0xb752eec4 in ddxGiveUp (error=EXIT_ERR_ABORT) at
../../../../hw/xfree86/common/xf86Init.c:1065
#5 0xb752ef65 in AbortDDX (error=EXIT_ERR_ABORT) at
../../../../hw/xfree86/common/xf86Init.c:1109
#6 0xb765ca9f in AbortServer () at ../../os/log.c:784
#7 0xb765d3c4 in FatalError (f=0xb76867f0 Caught signal %d (%s). Server
aborting\n) at ../../os/log.c:925
#8 0xb765453d in OsSigHandler (signo=11, sip=0xbf8bfb4c, unused=0xbf8bfbcc) at
../../os/osinit.c:147
#9 signal handler called
#10 0xb6af6543 in drmmode_load_cursor_argb (crtc=0xb8206e70, image=0xb85a3ef8)
at ../../../../../hw/xfree86/drivers/modesetting/drmmode_display.c:461
#11 0xb7567f86 in xf86_driver_load_cursor_argb (cursor_argb=0xb85a3ef8,
crtc=0xb8206e70) at ../../../../hw/xfree86/modes/xf86Cursors.c:241
#12 xf86_crtc_convert_cursor_to_argb (crtc=crtc@entry=0xb8206e70,
src=src@entry=0xb85a9428 ) at ../../../../hw/xfree86/modes/xf86Cursors.c:281
#13 0xb756848d in xf86_load_cursor_image (scrn=0xb8172770, src=0xb85a9428 )
at ../../../../hw/xfree86/modes/xf86Cursors.c:507
#14 0xb757313a in xf86DriverLoadCursorARGB (pCursor=optimized out,
infoPtr=optimized out) at ../../../../hw/xfree86/ramdac/xf86Cursor.h:55
#15 xf86SetCursor (pScreen=0xb820bc28, pCurs=0xb8ae5130, x=640, y=512) at
../../../../hw/xfree86/ramdac/xf86HWCurs.c:156
#16 0xb7571b33 in xf86CursorSetCursor (pDev=0xb88cd3f8, pScreen=0xb820bc28,
pCurs=0xb8ae5130, x=640, y=512) at
../../../../hw/xfree86/ramdac/xf86Cursor.c:357
#17 0xb763af3a in miPointerUpdateSprite (pDev=0xb88cd3f8) at
../../mi/mipointer.c:456
#18 0xb763b1a1 in miPointerDisplayCursor (pDev=0xb88cd3f8, pScreen=0xb820bc28,
pCursor=0xb8ae5130) at ../../mi/mipointer.c:194
#19 0xb7580069 in CursorDisplayCursor (pDev=0xb88cd3f8, pScreen=0xb820bc28,
pCursor=0xb8ae5130) at ../../xfixes/cursor.c:150
#20 0xb75cced4 in AnimCurDisplayCursor (pDev=0xb88cd3f8, pScreen=0xb820bc28,
pCursor=0xb8ae5130) at ../../render/animcur.c:225
#21 0xb74f4d31 in ChangeToCursor (pDev=0xb8172fd8, cursor=0x0) at
../../dix/events.c:937
#22 0xb74f623b in WindowHasNewCursor (pWin=0xb8625dc0) at
../../dix/events.c:3359
#23 0xb751c08c in ChangeWindowAttributes (pWin=optimized out,
vmask=optimized out, vlist=optimized out, client=optimized out)
at ../../dix/window.c:1439
#24 0xb74e5ba7 in ProcChangeWindowAttributes (client=0xb8ae3c20) at
../../dix/dispatch.c:679
#25 0xb74ebe56 in Dispatch () at ../../dix/dispatch.c:432
#26 0xb74f003f in dix_main (argc=6, argv=0xbf8c03f4, envp=0xb771ba5c
noPanoramiXExtension) at ../../dix/main.c:298
#27 0xb74d9d7a in main (argc=6, argv=0xbf8c03f4, envp=0xbf8c0410) at
../../dix/stubmain.c:34
(gdb) bt full
#0 0xb748abe0 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb706be07 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb706d3d9 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
No symbol table info available.
#3 0xb7656e79 in OsAbort () at ../../os/utils.c:1342
No locals.
#4 0xb752eec4 in ddxGiveUp (error=EXIT_ERR_ABORT) at
../../../../hw/xfree86/common/xf86Init.c:1065
i = optimized out
#5 0xb752ef65 in AbortDDX (error=EXIT_ERR_ABORT) at
../../../../hw/xfree86/common/xf86Init.c:1109
i = 1
#6 0xb765ca9f in AbortServer () at ../../os/log.c:784
No locals.
#7 0xb765d3c4 in FatalError (f=0xb76867f0 Caught signal %d (%s). Server
aborting\n) at ../../os/log.c:925
args = 0xbf8bfb24 \v
args2 = 0xbf8bfb24 \v
beenhere = 1
#8 0xb765453d in OsSigHandler (signo=11, sip=0xbf8bfb4c, unused=0xbf8bfbcc) at
../../os/osinit.c:147
unused = 0xbf8bfbcc
sip = 0xbf8bfb4c
signo = 11
#9 signal handler called
No symbol table info available.
#10 0xb6af6543 in drmmode_load_cursor_argb (crtc=0xb8206e70, image=0xb85a3ef8)
at ../../../../../hw/xfree86/drivers/modesetting/drmmode_display.c:461
ms = 0xb8172fd8
