Re: [PATCH 2/6] libdrm: Add missing string.h include
strings.h (strcasecmp is posix function) On Sat, Jul 4, 2009 at 10:32 PM, Julien Cristaujcris...@debian.org wrote: On Sat, Jul 4, 2009 at 02:18:50 +0300, Pauli Nieminen wrote: --- libdrm/xf86drm.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libdrm/xf86drm.h b/libdrm/xf86drm.h index c1d173c..a7f9763 100644 --- a/libdrm/xf86drm.h +++ b/libdrm/xf86drm.h @@ -37,6 +37,7 @@ #include stdarg.h #include sys/types.h #include stdint.h +#include strings.h #include drm.h /* Defaults, if nothing set in xf86config */ commit message says string.h, patch has strings.h. Which is it? Cheers, Julien -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/6] libdrm: Add missing string.h include
On Sat, Jul 4, 2009 at 02:18:50 +0300, Pauli Nieminen wrote: --- libdrm/xf86drm.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libdrm/xf86drm.h b/libdrm/xf86drm.h index c1d173c..a7f9763 100644 --- a/libdrm/xf86drm.h +++ b/libdrm/xf86drm.h @@ -37,6 +37,7 @@ #include stdarg.h #include sys/types.h #include stdint.h +#include strings.h #include drm.h /* Defaults, if nothing set in xf86config */ commit message says string.h, patch has strings.h. Which is it? Cheers, Julien -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22621] New: graphics corruption after resume with radeon and with KDE 4 with compositing enabled
http://bugs.freedesktop.org/show_bug.cgi?id=22621 Summary: graphics corruption after resume with radeon and with KDE 4 with compositing enabled Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: mar...@lichtvoll.de Created an attachment (id=27387) -- (http://bugs.freedesktop.org/attachment.cgi?id=27387) X.org configuration file After resume from suspend to ram or suspend to disk using TuxOnIce there is graphics garbage around window borders. It goes away when I start systemsettings, untick the checkmark for activating desktop effect, tick it again and press Apply. It also goes away when I disable compositing and re-enable it again afterwards. I did not see other malfunctions, just the graphics corruption while compositing is still working after resume. I don't know whether DRI is the approbiate place to report this against. I do not even know whether it might be a KDE 4 kwin problem instead. But I had to start somewhere. This is happening on an IBM ThinkPad T42 with radeon chipset: mar...@shambhala:~ lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50] Using XOrg CVS as 7.4 is not in the version list. I use the following on a mixture of Debian Lenny/Squeeze/Sid/Experimental: mar...@shambhala:~ apt-show-versions | egrep (libgl1-mesa-dri|xserver-xorg-video-radeon|xserver-xorg/|xserver-xorg-core/) libgl1-mesa-dri/sid uptodate 7.4.4-1 xserver-xorg/sid uptodate 1:7.4+3 xserver-xorg-core/sid uptodate 2:1.6.1.901-3 xserver-xorg-video-radeon/sid uptodate 1:6.12.2-2 xserver-xorg-video-radeonhd/sid uptodate 1.2.5-1 (I made sure that X.org and Mesa related packages are consistently at Sid.) I am using radeon driver. I attach my xorg.conf. I also attach two screenshots that demonstrate the problem. Regarding my xorg.conf: I am using XAA, since X.org tends to use 99% CPU with EXA. Yes, I know glxgears is not a benchmark. I am using CONFIG_FB_RADEON. My current kernel is: mar...@shambhala:~ cat /proc/version Linux version 2.6.29.2-tp42-toi-3.0.1 (mar...@shambhala) (gcc version 4.3.3 (Debian 4.3.3-3) ) #2 PREEMPT Tue Apr 28 22:08:44 CEST 2009 I do not yet use 2.6.30 since it reboots after resuming from TuxOnIce hibernation. I am building a new kernel with 2.6.30.1 and some TuxOnIce fixes that might work tough. I will report when it works and it makes any difference. Please tell me when you need anything more. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22621] graphics corruption after resume with radeon and with KDE 4 with compositing enabled
http://bugs.freedesktop.org/show_bug.cgi?id=22621 --- Comment #1 from Martin Steigerwald mar...@lichtvoll.de 2009-07-05 02:22:53 PST --- Created an attachment (id=27388) -- (http://bugs.freedesktop.org/attachment.cgi?id=27388) Window border graphics corruption after resuming from suspend to RAM -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 --- Comment #16 from Maciej Cencora m.cenc...@gmail.com 2009-07-05 06:13:45 PST --- (In reply to comment #15) (In reply to comment #14) Seems to be fixed with current mesa master. Can you confirm? It certainly doesn't work with vanilla Fedora 11 (Mesa 7.6-devel), and mesa-git is failing to compile for me: Try make realclean and then autogen.sh before running configure. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 --- Comment #17 from Chris Rankin ranki...@googlemail.com 2009-07-05 07:39:27 PST --- (In reply to comment #16) Try make realclean and then autogen.sh before running configure. Running autogen.sh again did the trick, and yes, my rubiks cube is no longer grey. But it's still slow, and these messages are appearing in my kernel log: rubik:16882 freeing invalid memtype c8102000-c8112000 rubik:16882 freeing invalid memtype c8112000-c8122000 rubik:16882 freeing invalid memtype c8122000-c8132000 rubik:16882 freeing invalid memtype c8132000-c8142000 rubik:16882 freeing invalid memtype c8142000-c8152000 rubik:16882 freeing invalid memtype c8152000-c8162000 rubik:16882 freeing invalid memtype c8162000-c8172000 rubik:16882 freeing invalid memtype c8172000-c8182000 rubik:16882 freeing invalid memtype c8182000-c8192000 rubik:16882 freeing invalid memtype c8192000-c81a2000 rubik:16882 freeing invalid memtype c81a2000-c81b2000 rubik:16882 freeing invalid memtype c81b2000-c81c2000 rubik:16882 freeing invalid memtype c81c2000-c81d2000 rubik:16882 freeing invalid memtype c81d2000-c81e2000 rubik:16882 freeing invalid memtype c81e2000-c81f2000 rubik:16882 freeing invalid memtype c81f2000-c8202000 rubik:16882 freeing invalid memtype c8202000-c8212000 rubik:16882 freeing invalid memtype c8212000-c8222000 rubik:16882 freeing invalid memtype c8222000-c8232000 rubik:16882 freeing invalid memtype c8232000-c8242000 rubik:16882 freeing invalid memtype c8242000-c8252000 rubik:16882 freeing invalid memtype c8252000-c8262000 rubik:16882 freeing invalid memtype c8262000-c8272000 rubik:16882 freeing invalid memtype c8272000-c8282000 rubik:16882 freeing invalid memtype c8282000-c8292000 rubik:16882 freeing invalid memtype c8292000-c82a2000 rubik:16882 freeing invalid memtype c82a2000-c82b2000 rubik:16882 freeing invalid memtype c82b2000-c82c2000 rubik:16882 freeing invalid memtype c82c2000-c82d2000 rubik:16882 freeing invalid memtype c82d2000-c82e2000 rubik:16882 freeing invalid memtype c82e2000-c82f2000 rubik:16882 freeing invalid memtype c82f2000-c8302000 I can confirm that it's not using swrast accidentally: $ LIBGL_DEBUG=verbose /usr/libexec/xscreensaver/rubik libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0) libGL: OpenDriver: trying /usr/local/lib/dri/r300_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/6] libdrm: Add missing strings.h include
strcasecmp is declared in strings.h --- libdrm/xf86drm.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libdrm/xf86drm.h b/libdrm/xf86drm.h index c1d173c..a7f9763 100644 --- a/libdrm/xf86drm.h +++ b/libdrm/xf86drm.h @@ -37,6 +37,7 @@ #include stdarg.h #include sys/types.h #include stdint.h +#include strings.h #include drm.h /* Defaults, if nothing set in xf86config */ -- 1.6.3.1 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 5/6] libdrm: Make chown check for return value and in case a signal call again chown.
Attached improved patch.
On Sat, Jul 4, 2009 at 11:14 AM, Pekka Paalanenp...@iki.fi wrote:
On Sat, 4 Jul 2009 02:18:53 +0300
Pauli Nieminen suok...@gmail.com wrote:
---
libdrm/xf86drm.c | 49 ++---
1 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index 7b05386..bf80fd4 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -269,6 +269,49 @@ static int drmMatchBusID(const char *id1, const char
*id2)
return 0;
}
+static int chownCheckReturn(const char *path, uid_t owner, gid_t group)
+{
+ int rv;
+ do {
+ rv = chown(path, owner, group);
+ } while( rv != 0 errno == EINTR);
+ if (rv == 0)
+ return 0;
+ char *errMsg = ;
+ switch(errno)
+ {
+ case EACCES:
+ errMsg = Read permission denied.;
+ break;
+ case ELOOP:
+ errMsg = Recursive symbolic link.;
+ break;
+ case ENAMETOOLONG:
+ errMsg = Too long path.;
+ break;
+ case ENOTDIR:
+ errMsg = Path isn't in a directory.;
+ break;
+ case ENOENT:
+ errMsg = No file found.;
+ break;
+ case EPERM:
+ errMsg = No permission to change the permission.;
+ break;
+ case EROFS:
+ errMsg = Read-only file system.;
+ break;
+ case EIO:
+ errMsg = I/O error.;
+ break;
+ case EINVAL:
+ errMsg = The owner or group id is invalid.;
+ break;
+ }
+ drmMsg(Failed to change ower or group for file %s! %d: %s\n,path,
errno, errMsg);
+ return -1;
+}
+
Is there a reason for not using strerror() here?
No good one. Only reason was that I have never used it before.
/**
* Open the DRM device, creating it if necessary.
*
@@ -307,7 +350,7 @@ static int drmOpenDevice(long dev, int minor, int type)
if (!isroot)
return DRM_ERR_NOT_ROOT;
mkdir(DRM_DIR_NAME, DRM_DEV_DIRMODE);
- chown(DRM_DIR_NAME, 0, 0); /* root:root */
+ chownCheckReturn(DRM_DIR_NAME, 0, 0); /* root:root */
chmod(DRM_DIR_NAME, DRM_DEV_DIRMODE);
}
@@ -320,7 +363,7 @@ static int drmOpenDevice(long dev, int minor, int type)
}
if (drm_server_info) {
- chown(buf, user, group);
+ chownCheckReturn(buf, user, group);
chmod(buf, devmode);
}
#else
@@ -363,7 +406,7 @@ wait_for_udev:
remove(buf);
mknod(buf, S_IFCHR | devmode, dev);
if (drm_server_info) {
- chown(buf, user, group);
+ chownCheckReturn(buf, user, group);
chmod(buf, devmode);
}
}
--
1.6.3.1
--
Pekka Paalanen
http://www.iki.fi/pq/
From cdf9faaab782f2a84ee16c27a4e7b1f70d2e6ad5 Mon Sep 17 00:00:00 2001
From: Pauli Nieminen suok...@gmail.com
Date: Sun, 5 Jul 2009 18:31:18 +0300
Subject: [PATCH 5/6] libdrm: Make chown check for return value.
If call was interrupted by signal we have to make call again.
---
libdrm/xf86drm.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index 7b05386..3da0380 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -269,6 +269,19 @@ static int drmMatchBusID(const char *id1, const char *id2)
return 0;
}
+static int chownCheckReturn(const char *path, uid_t owner, gid_t group)
+{
+ int rv;
+ do {
+ rv = chown(path, owner, group);
+ } while( rv != 0 errno == EINTR);
+ if (rv == 0)
+ return 0;
+ char *errMsg = strerror(errno);
+ drmMsg(Failed to change ower or group for file %s! %d: %s\n,path, errno, errMsg);
+ return -1;
+}
+
/**
* Open the DRM device, creating it if necessary.
*
@@ -307,7 +320,7 @@ static int drmOpenDevice(long dev, int minor, int type)
if (!isroot)
return DRM_ERR_NOT_ROOT;
mkdir(DRM_DIR_NAME, DRM_DEV_DIRMODE);
- chown(DRM_DIR_NAME, 0, 0); /* root:root */
+ chownCheckReturn(DRM_DIR_NAME, 0, 0); /* root:root */
chmod(DRM_DIR_NAME, DRM_DEV_DIRMODE);
}
@@ -320,7 +333,7 @@ static int drmOpenDevice(long dev, int minor, int type)
}
if (drm_server_info) {
- chown(buf, user, group);
+ chownCheckReturn(buf, user, group);
chmod(buf, devmode);
}
#else
@@ -363,7 +376,7 @@ wait_for_udev:
remove(buf);
mknod(buf, S_IFCHR | devmode, dev);
if (drm_server_info) {
- chown(buf, user, group);
+ chownCheckReturn(buf, user, group);
chmod(buf, devmode);
}
}
--
1.6.3.1
--
--
___
Dri-devel mailing list
Re: [PATCH 6/6] libdrm: Add configuration option to enable strict compilation Also add -pedantic to list of warning flags.
On Sat, Jul 4, 2009 at 2:37 AM, Pauli Nieminensuok...@gmail.com wrote: This might also require -std=c99 to set c standard correctly. I did use that in my CFLAGS when I tried to compile with -Werror. New version of patch attached to add the -std=c99 if using strict compilation From fc7f62d955f2d7b66cd5179eace2f628a7c66277 Mon Sep 17 00:00:00 2001 From: Pauli Nieminen suok...@gmail.com Date: Sun, 5 Jul 2009 18:34:29 +0300 Subject: [PATCH 6/6] libdrm: Add configuration option to enable strict compilation Source is writen for c99 standard so we have to tell compiler about it with -std=c99 if we want strict warnings. Also add -pedantic to list of warning flags. --- configure.ac | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index be2fbbf..a63655e 100644 --- a/configure.ac +++ b/configure.ac @@ -52,6 +52,11 @@ AC_ARG_ENABLE(radeon-experimental-api, [Enable support for radeon's KMS API (default: disabled)]), [RADEON=$enableval], [RADEON=no]) +AC_ARG_ENABLE(strict-compilation, + AS_HELP_STRING([--enable-strict-compilation], + [Enable all warnings from compiler and make them errors (default: disabled)]), + [STRICT_COMPILE=$enableval], [STRICT_COMPILE=no]) + dnl === dnl check compiler flags AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ @@ -93,7 +98,7 @@ MAYBE_WARN=-Wall -Wextra \ -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations \ -Wdeclaration-after-statement -Wold-style-definition \ -Wno-missing-field-initializers -Wno-unused-parameter \ --Wno-attributes -Wno-long-long -Winline +-Wno-attributes -Wno-long-long -Winline -pedantic # invalidate cached value if MAYBE_WARN has changed if test x$libdrm_cv_warn_maybe != x$MAYBE_WARN; then @@ -124,6 +129,10 @@ AC_CACHE_CHECK([for supported warning flags], libdrm_cv_warn_cflags, [ AC_MSG_CHECKING([which warning flags were supported])]) WARN_CFLAGS=$libdrm_cv_warn_cflags +if test x$STRICT_COMPILE = xyes; then + CFLAGS=$CFLAGS $WARN_CLAGS -std=c99 -Werror +fi + if test x$UDEV = xyes; then AC_DEFINE(UDEV, 1, [Have UDEV support]) fi -- 1.6.3.1 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/6] libdrm: Add configuration option to enable strict compilation Also add -pedantic to list of warning flags.
On Sun, Jul 5, 2009 at 6:53 PM, Pauli Nieminensuok...@gmail.com wrote: On Sat, Jul 4, 2009 at 2:37 AM, Pauli Nieminensuok...@gmail.com wrote: This might also require -std=c99 to set c standard correctly. I did use that in my CFLAGS when I tried to compile with -Werror. New version of patch attached to add the -std=c99 if using strict compilation I should learn to type and test everything well before submitting. From fc7f62d955f2d7b66cd5179eace2f628a7c66277 Mon Sep 17 00:00:00 2001 From: Pauli Nieminen suok...@gmail.com Date: Sun, 5 Jul 2009 18:34:29 +0300 Subject: [PATCH 6/6] libdrm: Add configuration option to enable strict compilation Source is writen for c99 standard so we have to tell compiler about it with -std=c99 if we want strict warnings. Also add -pedantic to list of warning flags. --- configure.ac | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index be2fbbf..a63655e 100644 --- a/configure.ac +++ b/configure.ac @@ -52,6 +52,11 @@ AC_ARG_ENABLE(radeon-experimental-api, [Enable support for radeon's KMS API (default: disabled)]), [RADEON=$enableval], [RADEON=no]) +AC_ARG_ENABLE(strict-compilation, + AS_HELP_STRING([--enable-strict-compilation], + [Enable all warnings from compiler and make them errors (default: disabled)]), + [STRICT_COMPILE=$enableval], [STRICT_COMPILE=no]) + dnl === dnl check compiler flags AC_DEFUN([LIBDRM_CC_TRY_FLAG], [ @@ -93,7 +98,7 @@ MAYBE_WARN=-Wall -Wextra \ -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations \ -Wdeclaration-after-statement -Wold-style-definition \ -Wno-missing-field-initializers -Wno-unused-parameter \ --Wno-attributes -Wno-long-long -Winline +-Wno-attributes -Wno-long-long -Winline -pedantic # invalidate cached value if MAYBE_WARN has changed if test x$libdrm_cv_warn_maybe != x$MAYBE_WARN; then @@ -124,6 +129,10 @@ AC_CACHE_CHECK([for supported warning flags], libdrm_cv_warn_cflags, [ AC_MSG_CHECKING([which warning flags were supported])]) WARN_CFLAGS=$libdrm_cv_warn_cflags +if test x$STRICT_COMPILE = xyes; then + CFLAGS=$CFLAGS $WARN_CFLAGS -std=c99 -Werror +fi + if test x$UDEV = xyes; then AC_DEFINE(UDEV, 1, [Have UDEV support]) fi -- 1.6.3.1 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13714] New: i915: display modes not detected with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=13714 Summary: i915: display modes not detected with KMS Product: Drivers Version: 2.5 Kernel Version: 2.6.31-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: m.s.tsir...@gmail.com Regression: No On T500 thinkpad, I enabled KMS on i915, and noticed that only a single mode shows up as enabled for the laptop's screen. Without kms, all display modes are supported. Tested on 2.6.31-rc2, 2.6.30 and 2.6.29.4-167 that ships with Fedora. xrandr output: With kms enabled (i915.modeset=1): Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.1*+ 50.1 DVI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DVI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) Without kms enabled: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1680 x 1680 VGA disconnected (normal left inverted right x axis y axis) VGA disconnected (normal left inverted right x axis y axis) LVDS connected 1280x1024+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.1 + 50.1 1400x1050 74.8 60.0 1280x1024 85.0 75.0 60.0* 1280x960 85.0 60.0 1152x864 75.0 1024x768 85.0 75.0 70.1 60.0 832x62474.6 800x60085.1 72.2 75.0 60.3 56.2 640x48085.0 72.8 75.0 59.9 720x40085.0 640x40085.1 640x35085.1 HDMI-1 disconnected (normal left inverted right x axis y axis) HDMI-2 disconnected (normal left inverted right x axis y axis) $ X -version X.Org X Server 1.6.1.901 (1.6.2 RC 1) Release Date: 2009-5-8 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.1.6.el5 i686 Current Operating System: Linux tuck.tlv.redhat.com 2.6.31-rc2-mst-dbg #4 SMP PREEMPT Sun Jul 5 12:04:15 IDT 2009 x86_64 Kernel command line: root=UUID=4670fcf0-09a8-4011-bf25-6e5e97f263c6 ro i915.modeset=1 Build Date: 18 May 2009 02:47:59PM Build ID: xorg-x11-server 1.6.1.901-1.fc11 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. $lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07) 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection 15:00.0 CardBus bridge:
[Bug 13713] [drm/i915] Possible regression due to commit Change GEM throttling to be 20ms (...)
http://bugzilla.kernel.org/show_bug.cgi?id=13713 Maxim Levitsky maximlevit...@gmail.com changed: What|Removed |Added CC||maximlevit...@gmail.com --- Comment #1 from Maxim Levitsky maximlevit...@gmail.com 2009-07-05 19:04:16 --- I confirm similar findings. 1) many games, especially neverball are very bursty, like you descrive 2) glxgears performance recently dropped from 950 to 750 FPS. I changed the throttling timeout to 5 ms, and neverball no longer bursty, and glxgears back to 950 FPS, and maybe googleearth works again without crashes (it does now, but I am not sure that this change did it) On the other hand increasing the timeout to 300 ms, like I initially did only make this problem much worse. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13713] [drm/i915] Possible regression due to commit Change GEM throttling to be 20ms (...)
http://bugzilla.kernel.org/show_bug.cgi?id=13713 --- Comment #2 from Maxim Levitsky maximlevit...@gmail.com 2009-07-05 19:06:04 --- I also want to note that I couldn't revert this commit, it creates conflicts, and even after a manual merge, still kernel didn't compile I use -git of everything (updated daily) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13294] i915: drm: xorg leaks drm objects massively
http://bugzilla.kernel.org/show_bug.cgi?id=13294 Maxim Levitsky maximlevit...@gmail.com changed: What|Removed |Added CC||maximlevit...@gmail.com --- Comment #10 from Maxim Levitsky maximlevit...@gmail.com 2009-07-05 19:11:25 --- I use i965 + kms + everything -git. The /sys/kernel/debug/dri/0/gem_objects never decreases I mean the number of objects. Or more correctly it does, but only when application that created them is closed. This includes compiz, Xorg, 3d games, and Google earth. It especially bad with GE, in few minutes of use the number of gem objects pitches up, and number of bytes is more that a gigabyte, system swaps, and GE becames very slow. once I close it, everything is freed. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22625] New: glDrawBuffer(GL_FRONT) rendering broken in UXA intel i915
http://bugs.freedesktop.org/show_bug.cgi?id=22625 Summary: glDrawBuffer(GL_FRONT) rendering broken in UXA intel i915 Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: hu...@psfc.mit.edu Created an attachment (id=27402) -- (http://bugs.freedesktop.org/attachment.cgi?id=27402) C-code to illustrate the bug. Trivial GL example. Enabling option AccelMethod UXA causes GL writing to front buffer to appear in the wrong place. The attached code is a minor modification to the standard OpenGL quad.c example. Instead of writing to the back buffer, it writes to the front this illustrates the problem. The writes to the front buffer appear in a region at top left (0,0) which never moves. Under pure metacity window manager, the window that pops up has decorations etc and can be dragged around, but that is not where the drawing occurs. The area drawn resizes in accordance with changes in the window size. But it never moves from the top left. Without UXA enabled, correct behavior is observed. [With metacity, that is. Compiz is another whole mess, that I'm not getting into here!] Fully updated Ubuntu Jaunty x86_64: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-15-server x86_64 Ubuntu Current Operating System: Linux tp400-64 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 Build Date: 09 April 2009 02:11:54AM ... (II) Module intel: vendor=X.Org Foundation compiled for 1.6.0, module version = 2.6.3 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 ... (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset (--) intel(0): Chipset: Mobile Intel® GM45 Express Chipset (--) intel(0): Linear framebuffer at 0xD000 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
