[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #7 from rem11_1...@yahoo.fr 2009-11-23 00:14:08 PST --- Ok, now it seems I have the latest change but same result : scourge: radeon_mipmap_tree.c:438: migrate_image_to_miptree: Assertion `srclvl-size == dstlvl-size' failed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [radeon-drm] kms resolution wrong with kernel 2.6.32rc8-git1
On Sun, Nov 22, 2009 at 6:00 AM, Andreas Radke a.ra...@arcor.de wrote: radeon kms worked well with my X200m/R300 card in kernel 31 series and now I tried 32rc8-git1 and resolution detection fails: It detects the resolution of your panel (1280x800) fine. It's also detecting the tv-out port as connected which has a mode of 800x600. Does your card have a tv-out port? If so, is it connected? Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [radeon-drm] kms resolution wrong with kernel 2.6.32rc8-git1
On Mon, 23 Nov 2009, Alex Deucher wrote: On Sun, Nov 22, 2009 at 6:00 AM, Andreas Radke a.ra...@arcor.de wrote: radeon kms worked well with my X200m/R300 card in kernel 31 series and now I tried 32rc8-git1 and resolution detection fails: It detects the resolution of your panel (1280x800) fine. It's also detecting the tv-out port as connected which has a mode of 800x600. Does your card have a tv-out port? If so, is it connected? Alex The laptop has a tv connector but there's nothing connected. This reminds me trouble with nouveau driver on my desktop and wrong detected tv connector. We solved it over the last few weeks. maybe it's not related. It happened on the desktop after they pulled new drm code some weeks ago. It's not yet fixed for all nvidia cards but mine is. The code is already in nouveau git. Maybe you know if it's caused by the same change in drm code. -Andy -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24837] Broken ring info in debugfs
http://bugs.freedesktop.org/show_bug.cgi?id=24837 Jerome Glisse gli...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jerome Glisse gli...@freedesktop.org 2009-11-23 02:49:58 PST --- I believe the patch is upstream now -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24832] kmemleak detected leaks
http://bugs.freedesktop.org/show_bug.cgi?id=24832 Jerome Glisse gli...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Jerome Glisse gli...@freedesktop.org 2009-11-23 02:50:21 PST --- These are false positive. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 --- Comment #4 from Rafał Miłecki zaj...@gmail.com 2009-11-23 04:00:16 PST --- I generated compilation fixing patch with: git show 7118db870091d4c9c2465e79f361ff0ed36d1f90 r600.align.for.mipmap.tree.changes.patch git checkout 93eb2ab8c395f81e40fa298d78805bb2c777f891 patch -p1 r600.align.for.mipmap.tree.changes.patch make clean make -j 4 su -c 'make install' [compiles fine, openarena doesn't start] [openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed.] git checkout ad83aeccdc54beecf25f217e2dd24c8edf6d6767 patch -p1 r600.align.for.mipmap.tree.changes.patch make clean make -j 4 su -c 'make install' [compiles fine, openarena doesn't start] [openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed.] git checkout 23ec7c457483aae1e0d399e9b570f1860c27c780 patch -p1 r600.align.for.mipmap.tree.changes.patch make clean make -j 4 su -c 'make install' [compiles fine, openarena doesn't start] [openarena: radeon_mipmap_tree.c:423: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed.] git checkout afe84fa698eae3e035e967589f0a8d55f6a83698 patch -p1 r600.align.for.mipmap.tree.changes.patch make clean make -j 4 su -c 'make install' [compiles fine, openarena doesn't start] [openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed.] So as expected all the commits are broken for me. I guess it's that new mipmap tree work that causes problem, right? Can I test anything else? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 --- Comment #5 from Rafał Miłecki zaj...@gmail.com 2009-11-23 04:48:23 PST --- Last changes in Mesa improved my situation somehow. With (older) commit 2b07b640619ac68344276ba0557ea46b2cbc3f26 I can not start openarena. With (newer) commit c3c8c40cab193e0aa0f1a42bff7b0d726df8cf9f I can start openarena (menu), can not start play (3D world). Always the same message: openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon modeset=1 agpmode=-1 does not work in 2.6.32-rc8
On Mon, 2009-11-23 at 14:18 +0100, Christian Hartmann wrote: Hello, I just wanted to disable agpmode and have set in the /etc/modules radeon modeset=0 agpmode=-1 running update-initramfs and rebooting. But I am wondering, cause AGP is still enabled. Is that really correct? Without KMS, the AGP mode needs to be configured in xorg.conf. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. I'm probably not the best person to make those change, but I can try to fix that up if nobody else are up for it. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [radeon-drm] kms resolution wrong with kernel 2.6.32rc8-git1
On Mon, Nov 23, 2009 at 4:03 AM, Andreas Radke a.ra...@arcor.de wrote: On Mon, 23 Nov 2009, Alex Deucher wrote: On Sun, Nov 22, 2009 at 6:00 AM, Andreas Radke a.ra...@arcor.de wrote: radeon kms worked well with my X200m/R300 card in kernel 31 series and now I tried 32rc8-git1 and resolution detection fails: It detects the resolution of your panel (1280x800) fine. It's also detecting the tv-out port as connected which has a mode of 800x600. Does your card have a tv-out port? If so, is it connected? Alex The laptop has a tv connector but there's nothing connected. This reminds me trouble with nouveau driver on my desktop and wrong detected tv connector. We solved it over the last few weeks. maybe it's not related. It happened on the desktop after they pulled new drm code some weeks ago. It's not yet fixed for all nvidia cards but mine is. The code is already in nouveau git. Maybe you know if it's caused by the same change in drm code. I don't think it's related. The difference in your case is that the previous code did not have tv-out support and the newer code does. Load detection on the tv-dac is unreliable in some cases which can result in false positives. We may end up needing to disable it by default in some cases. Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add HDP flushing for all GPUs.
On Sun, Nov 22, 2009 at 9:01 PM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
rendercheck under kms on r600s was failing due to HDP flushing not happening.
This adds HDP flushing to the object wait function for r100-r700 families.
rendercheck passes basic tests on r600 with this change.
Signed-off-by: Dave Airlie airl...@redhat.com
Acked-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/r100.c | 8
drivers/gpu/drm/radeon/r600.c | 4
drivers/gpu/drm/radeon/r600d.h | 1 +
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_asic.h | 12
drivers/gpu/drm/radeon/radeon_object.c | 1 +
6 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f0f2fbe..677fd72 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1589,6 +1589,14 @@ void r100_gpu_init(struct radeon_device *rdev)
r100_hdp_reset(rdev);
}
+void r100_hdp_flush(struct radeon_device *rdev)
+{
+ u32 tmp;
+ tmp = RREG32(RADEON_HOST_PATH_CNTL);
+ tmp |= RADEON_HDP_READ_BUFFER_INVALIDATE;
+ WREG32(RADEON_HOST_PATH_CNTL, tmp);
+}
+
void r100_hdp_reset(struct radeon_device *rdev)
{
uint32_t tmp;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 8d6bc12..ce421b6 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1101,6 +1101,10 @@ void r600_pciep_wreg(struct radeon_device *rdev, u32
reg, u32 v)
(void)RREG32(PCIE_PORT_DATA);
}
+void r600_hdp_flush(struct radeon_device *rdev)
+{
+ WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1);
+}
/*
* CP Ring
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index b99f45d..f33433d 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -673,4 +673,5 @@
#define S_000E60_SOFT_RESET_TSC(x) (((x) 1)
16)
#define S_000E60_SOFT_RESET_VMC(x) (((x) 1)
17)
+#define R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL 0x5480
#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 27c8b38..9783220 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -638,6 +638,7 @@ struct radeon_asic {
uint32_t offset, uint32_t obj_size);
int (*clear_surface_reg)(struct radeon_device *rdev, int reg);
void (*bandwidth_update)(struct radeon_device *rdev);
+ void (*hdp_flush)(struct radeon_device *rdev);
};
/*
@@ -969,6 +970,7 @@ static inline void radeon_ring_write(struct radeon_device
*rdev, uint32_t v)
#define radeon_set_surface_reg(rdev, r, f, p, o, s)
((rdev)-asic-set_surface_reg((rdev), (r), (f), (p), (o), (s)))
#define radeon_clear_surface_reg(rdev, r)
((rdev)-asic-clear_surface_reg((rdev), (r)))
#define radeon_bandwidth_update(rdev) (rdev)-asic-bandwidth_update((rdev))
+#define radeon_hdp_flush(rdev) (rdev)-asic-hdp_flush((rdev))
/* Common functions */
extern int radeon_gart_table_vram_pin(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 94991ed..c84a15a 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -75,6 +75,7 @@ int r100_clear_surface_reg(struct radeon_device *rdev, int
reg);
void r100_bandwidth_update(struct radeon_device *rdev);
void r100_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib);
int r100_ring_test(struct radeon_device *rdev);
+void r100_hdp_flush(struct radeon_device *rdev);
static struct radeon_asic r100_asic = {
.init = r100_init,
@@ -105,6 +106,7 @@ static struct radeon_asic r100_asic = {
.set_surface_reg = r100_set_surface_reg,
.clear_surface_reg = r100_clear_surface_reg,
.bandwidth_update = r100_bandwidth_update,
+ .hdp_flush = r100_hdp_flush,
};
@@ -159,6 +161,7 @@ static struct radeon_asic r300_asic = {
.set_surface_reg = r100_set_surface_reg,
.clear_surface_reg = r100_clear_surface_reg,
.bandwidth_update = r100_bandwidth_update,
+ .hdp_flush = r100_hdp_flush,
};
/*
@@ -197,6 +200,7 @@ static struct radeon_asic r420_asic = {
.set_surface_reg = r100_set_surface_reg,
.clear_surface_reg = r100_clear_surface_reg,
.bandwidth_update = r100_bandwidth_update,
+ .hdp_flush = r100_hdp_flush,
};
@@ -240,6 +244,7 @@ static struct radeon_asic rs400_asic = {
.set_surface_reg = r100_set_surface_reg,
.clear_surface_reg = r100_clear_surface_reg,
.bandwidth_update = r100_bandwidth_update,
+ .hdp_flush = r100_hdp_flush,
};
@@ -285,6 +290,7 @@ static
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: radeon, kernel = 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen
On Fri, Nov 20, 2009 at 7:21 PM, Viktor Malyarchuk mal...@gmail.com wrote: Hi Alex, I never used git bisect before but willing to try. Which git tree should I use? Usually I just download mainline source from kernel.org and patch it with last snapshot, so no git information there. I use git to build libdrm, mesa and xf86-video-ati. You'll need to clone a kernel git tree to use bisect. Since your known good and bad points are based on Linus' tree, I would suggest starting with that. See the git-bisect man page for how to use it. Basically you specify good and bad points on the tree and git bisects the commits in between. You try those commits and mark them as good or bad until you find the problematic one. Alex Best, Viktor On Friday 20 November 2009 10:16:44 am Alex Deucher wrote: On Fri, Nov 20, 2009 at 5:45 AM, Viktor Malyarchuk mal...@gmail.com wrote: Dear David, thank you and all the developers involved for your outstanding DRM/KMS work. There is a problem that was introduced in 2.6.32-rc6-git5. SUMMARY any mode switch on MacBookPro2,2 is delayed by 130 seconds of black screen. REPORT Every time I try to change mode (change resolution, add/remove second monitor) screen go black for 130 seconds before change will take effect. System is not locked as I can ssh into it. The same happen during boot time: 130 seconds of black screen before switching to native mode. Radeon module is compiled into the kernel. There is no messages in dmesg during that delay. System look locked but dutifully going back to boot process after 130 s. KEYWORDS Radeon, DRM, KMS KERNEL VERSION /proc/version Linux version 2.6.32-rc8 (r...@malyarchuk-mactel) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Thu Nov 19 20:46:58 CST 2009 KERNEL .config file Please, see attachment config-2.6.32-rc8 LAST KERNEL that work fine 2.6.32-rc6-git4 Any chance you could use git bisect and track down the problematic commit? Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/23 Michel Dänzer mic...@daenzer.net: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Oh, only radeon_drm.h is in the kernel, so only that should be in include/drm. The other radeon_*.h files live in radeon/. I guess accidentally copied over the userspace headers when I populated the include/drm directory initially. Should be cleaned up now. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
libdrm headers (Re: RFC: libdrm repo)
On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? -- Pekka Paalanen http://www.iki.fi/pq/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 11:43 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Oh, only radeon_drm.h is in the kernel, so only that should be in include/drm. The other radeon_*.h files live in radeon/. I guess accidentally copied over the userspace headers when I populated the include/drm directory initially. Should be cleaned up now. Thanks Kristian. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #11 from Lukas Weber laochai...@web.de 2009-11-23 10:46:22 PST --- In the new version, the assertion is gone but it still crashes. $ wine th11.exe [...] drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. $ dmesg | tail -n2 [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #12 from Lukas Weber laochai...@web.de 2009-11-23 10:48:55 PST --- Created an attachment (id=31415) -- (http://bugs.freedesktop.org/attachment.cgi?id=31415) Full output of wine before the crash. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, 2009-11-23 at 12:13 -0500, Kristian Høgsberg wrote: On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. So, I was completely shocked when I was alerted on irc that libdrm no longer builds on FreeBSD. It appears that you totally whacked drm.h which is a common file shared and installed by all platforms, which has has all of the conditionals ripped from it and now blindly includes only linux bits. I have not yet determined if other such damage has occurred, but any of the includes that came from shared-core and are required for the build or that get installed should not have been mucked with. WTF? robert. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] drm/modes: Fall back to 1024x768 instead of 800x600
This matches the X server's fallback modes when using RANDR 1.2.
See also: http://bugzilla.redhat.com/538761
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe4e1d..c5bd50c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -109,7 +109,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = (*connector_funcs-get_modes)(connector);
if (!count) {
- count = drm_add_modes_noedid(connector, 800, 600);
+ count = drm_add_modes_noedid(connector, 1024, 768);
if (!count)
return 0;
}
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] drm/modes: Limit fallback modes to 60Hz
See also: http://bugzilla.redhat.com/514600
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..dd95edf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct drm_connector *connector,
ptr-vdisplay vdisplay)
continue;
}
+ if (drm_mode_vrefresh(ptr) 61)
+ continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
drm_mode_probed_add(connector, mode);
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] drm/edid: Retry EDID fetch up to four times
This matches the X server's retry logic. Note that we'll only retry if
we get a DDC response but fail validation; legitimately disconnected
outputs will bomb out early.
See also: http://bugzilla.redhat.com/532957
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd95edf..2820082 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -133,9 +133,6 @@ static bool edid_is_valid(struct edid *edid)
DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
goto bad;
}
- if (edid-revision 4)
- DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
-
for (i = 0; i EDID_LENGTH; i++)
csum += raw_edid[i];
if (csum) {
@@ -143,6 +140,9 @@ static bool edid_is_valid(struct edid *edid)
goto bad;
}
+ if (edid-revision 4)
+ DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
+
return 1;
bad:
@@ -1060,19 +1060,19 @@ static int drm_ddc_read_edid(struct drm_connector
*connector,
struct i2c_adapter *adapter,
char *buf, int len)
{
- int ret;
+ int i;
- ret = drm_do_probe_ddc_edid(adapter, buf, len);
- if (ret != 0) {
- goto end;
- }
- if (!edid_is_valid((struct edid *)buf)) {
- dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
-drm_get_connector_name(connector));
- ret = -1;
+ for (i = 0; i 4; i++) {
+ if (drm_do_probe_ddc_edid(adapter, buf, len))
+ return -1;
+ if (edid_is_valid((struct edid *)buf))
+ return 0;
}
-end:
- return ret;
+
+ /* repeated checksum failures; warn, but carry on */
+ dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
+drm_get_connector_name(connector));
+ return -1;
}
/**
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] drm/edid: Fix up partially corrupted headers
We'll still fail the block if it fails the EDID checksum though.
See also: http://bugzilla.redhat.com/534120
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2820082..bdea313 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -123,16 +123,21 @@ static const u8 edid_header[] = {
*/
static bool edid_is_valid(struct edid *edid)
{
- int i;
+ int i, score = 0;
u8 csum = 0;
u8 *raw_edid = (u8 *)edid;
- if (memcmp(edid-header, edid_header, sizeof(edid_header)))
- goto bad;
- if (edid-version != 1) {
- DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
+ for (i = 0; i sizeof(edid_header); i++)
+ if (raw_edid[i] == edid_header[i])
+ score++;
+
+ if (score == 8) ;
+ else if (score = 6) {
+ DRM_DEBUG(Fixing EDID header, your hardware may be failing\n);
+ memcpy(raw_edid, edid_header, sizeof(edid_header));
+ } else
goto bad;
- }
+
for (i = 0; i EDID_LENGTH; i++)
csum += raw_edid[i];
if (csum) {
@@ -140,6 +145,11 @@ static bool edid_is_valid(struct edid *edid)
goto bad;
}
+ if (edid-version != 1) {
+ DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
+ goto bad;
+ }
+
if (edid-revision 4)
DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18212] Crash inside r300MapTexture()
http://bugs.freedesktop.org/show_bug.cgi?id=18212 Owen Taylor otay...@redhat.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Owen Taylor otay...@redhat.com 2009-11-23 11:25:35 PST --- This was a one-off crash I happened to get a good backtrace for, not something I was hitting reliably. If you say it's fixed, it's probably fixed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/4] drm/modes: Limit fallback modes to 60Hz
2009/11/23 Adam Jackson a...@redhat.com:
See also: http://bugzilla.redhat.com/514600
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..dd95edf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct drm_connector
*connector,
ptr-vdisplay vdisplay)
continue;
}
+ if (drm_mode_vrefresh(ptr) 61)
+ continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
drm_mode_probed_add(connector, mode);
Did you use 61 on purpose?
Is that typo ( 60, or = 61) or do you expect modes like 60.1Hz we
want to survive?
--
Rafał
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25114] [R600] Nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
http://bugs.freedesktop.org/show_bug.cgi?id=25114 --- Comment #5 from darkbasic darkbas...@gmail.com 2009-11-23 12:02:45 PST --- Yes, it works. But I have *lots* of problems with kde4 desktop effects now :-( I also upgraded to the latest 2.6.32-rc8-git + drm-next git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25114] [R600] Nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
http://bugs.freedesktop.org/show_bug.cgi?id=25114 --- Comment #6 from darkbasic darkbas...@gmail.com 2009-11-23 12:09:21 PST --- If you were talking about the warnings they still remain! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #8 from Maciej Cencora m.cenc...@gmail.com 2009-11-23 13:09:28 PST --- Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25177] [r6xx][RV635] mipmap crash with secondlife
http://bugs.freedesktop.org/show_bug.cgi?id=25177 --- Comment #6 from Maciej Cencora m.cenc...@gmail.com 2009-11-23 13:10:17 PST --- Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23122] mipmap_comp_tests will cause radeon_validate_texture error
http://bugs.freedesktop.org/show_bug.cgi?id=23122 --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-23 13:11:05 PST --- Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 --- Comment #11 from Maciej Cencora m.cenc...@gmail.com 2009-11-23 13:11:51 PST --- Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 Rafał Miłecki zaj...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Rafał Miłecki zaj...@gmail.com 2009-11-23 13:18:22 PST --- Fixed in 960464e42dce138fde11c379ce7744bc4be14aa2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25248] New: Machinarium crashes with current git radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=25248
Summary: Machinarium crashes with current git radeon driver
Product: DRI
Version: DRI CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: p...@kantaka.co.uk
Created an attachment (id=31422)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31422)
Output of valgrind
With git drm-radeon-testing merged into the latest 2.6.32 prerelease git
libdrm and mesa, Machinarium (demo available here:
http://machinarium.net/demo/) crashes on startup. It's an Adobe Flash 10
binary.
Running the binary under valgrind reveals that the crash occurs here:
==30198== Invalid read of size 4
==30198==at 0xA8CC209: radeonFlush (radeon_common.c:1131)
==30198==by 0xA8C7628: r600DeleteTexture (radeon_cmdbuf.h:118)
==30198==by 0xA94FE29: _mesa_free_texture_data (texstate.c:799)
==30198==by 0xA8E8C27: _mesa_free_context_data (context.c:977)
==30198==by 0xA8E8DF5: _mesa_destroy_context (context.c:1039)
==30198==by 0xA8CAD5D: radeonDestroyContext (radeon_common_context.c:328)
==30198==by 0xA8A2DB6: driDestroyContext (dri_util.c:545)
==30198==by 0xA8582A8: dri2DestroyContext (dri2_glx.c:95)
==30198==by 0xA832345: DestroyContext (glxcmds.c:556)
and dropping into gdb reveals that the DrawBuffer is 0x0 in the context (ctx):
(gdb) l
1126radeon-dma.flush( ctx );
1127
1128if (radeon-cmdbuf.cs-cdw)
1129rcommonFlushCmdBuf(radeon, __FUNCTION__);
1130
1131if ((ctx-DrawBuffer-Name == 0) radeon-front_buffer_dirty)
{
1132__DRIscreen *const screen =
radeon-radeonScreen-driScreen;
1133
1134if (screen-dri2.loader
(screen-dri2.loader-base.version = 2)
1135 (screen-dri2.loader-flushFrontBuffer !=
NULL)) {
(gdb) p ctx
$5 = (GLcontext *) 0xa571460
(gdb) p ctx-DrawBuffer
$6 = (GLframebuffer *) 0x0
Now, this could be an Abobe bug: there are a stack of other errors from
valgrind (attached), but it seems that mesa isn't being defensive enough here
regardless. The game runs fine with LIGL_ALWAYS_SOFTWARE=1 set.
Happy to do any debugging on request, although the Machinarium demo is freely
available. (The above comes from the full game, I haven't tried the demo yet.)
NB. Is DRI/Radeon the right place for this? I'll resubmit if not.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've pulled the most required patches from the optional pull that you didn't take from last week. Granted this means the F12 kernel has now got a bunch of patches that should be in 2.6.32 but will have to wait for 2.6.33, distros thinking of packaging radeon kms do take note. Dave. drivers/gpu/drm/drm_edid.c |6 ++ drivers/gpu/drm/drm_fb_helper.c|6 +++--- drivers/gpu/drm/drm_gem.c |2 +- drivers/gpu/drm/drm_mm.c |9 + drivers/gpu/drm/radeon/atom.c |1 + drivers/gpu/drm/radeon/radeon.h|1 + drivers/gpu/drm/radeon/radeon_agp.c| 12 drivers/gpu/drm/radeon/radeon_connectors.c | 16 drivers/gpu/drm/radeon/radeon_device.c |2 ++ drivers/gpu/drm/radeon/rv515.c |9 - 10 files changed, 51 insertions(+), 13 deletions(-) commit 5349ef3127c77075ff70b2014f17ae0fbcaaf199 Author: Clemens Ladisch clem...@ladisch.de Date: Wed Nov 4 09:42:52 2009 +0100 drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch clem...@ladisch.de Tested-by: Paulius Zaleckas paulius.zalec...@gmail.com Cc: sta...@kernel.org Signed-off-by: Dave Airlie airl...@redhat.com commit 79cc304f3e2fda202242036326afb2aeca486156 Author: Jeremy Fitzhardinge jer...@goop.org Date: Tue Nov 17 14:08:54 2009 -0800 drm: make sure page protections are updated after changing vm_flags Some architectures compute -vm_page_prot depending on -vm_flags, so we need to update the protections after adjusting the flags. AFAIK this only affects running X under Xen; without this patch you get lots of coloured blobs on the screen, or maybe a complete lockup. Or anything really. But that still depends on lots of out-of-tree stuff, so I don't think there are any consequences for anyone else. But it is wrong in principle. Reported-by: Jan Beulich jbeul...@novell.com Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com commit f82f5f3ac4de6c6b872fcbb3dec97f368e78ff58 Author: Jerome Glisse jgli...@redhat.com Date: Thu Nov 12 14:13:53 2009 +0100 drm/radeon/kms: Report vga connector is connected according to ddc_probe On broken EDID we were reporting vga connector to be disconnected even if ddc probe did found a monitor. This patch report that the connector is connected on such case. This allow drm to add a fail safe mode (800x600 at the time of this patch) thus user can boot and later add a mode which match its monitor capabilities. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit a698cf34ea867efef12fc29dd63d443f0c71a53c Author: Jerome Glisse jgli...@redhat.com Date: Fri Nov 13 20:56:58 2009 +0100 drm: mm always protect change to unused_nodes with unused_lock spinlock unused_nodes modification needs to be protected by unused_lock spinlock. Here is an example of an usage where there is no such protection without this patch. Process 1: 1-drm_mm_pre_get(this function modify unused_nodes list) 2-spin_lock(spinlock protecting mm struct) 3-drm_mm_put_block(this function might modify unused_nodes list but doesn't protect modification with unused_lock) 4-spin_unlock(spinlock protecting mm struct) Process2: 1-drm_mm_pre_get(this function modify unused_nodes list) At this point Process1 Process2 might both be doing modification to unused_nodes list. This patch add unused_lock protection into drm_mm_put_block to avoid such issue. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 0beb81ab45c67de4b3aa85faad604cff8ed133a8 Author: Jerome Glisse jgli...@redhat.com Date: Fri Nov 13 20:56:35 2009 +0100 drm/radeon/kms: Disable TV load detect on RS400,RC410,RS480 RS400,RC410,RS480 chipset seems to report a lot of false positive with load detect on TV output. We haven't yet found a way to make load detect reliable on those chipset, thus just disable it for TV output. Would avoid user to experience
Re: intel, KMS, suspend2ram resume, screen black
This time with syslog.gz attached. On Di, 24 Nov 2009, preining wrote: (please Cc) I am running 2.6.32-rc8 with KMS on Debian/sid: xserver-xorg: 7.4+4 video-intel: 2.9.0-1 Suspend to RAM and resume works without any problems, but the one that the screen remains dark. I can switch to a console, can log in there, can shutdown the computer, all fine, but the sscreen is completely black. In addition, I have the impression that resume is immediately followed by a suspend call. Before swithcing to KMS susepnd/resume worked, so I assume that this is a KMS issue. I attach a log (syslog) of the cycle from initial suspend to the manual shutdown. Please let me know if I can help debug that in a way. Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `You'd better be prepared for the jump into hyperspace. It's unpleasently like being drunk.' `What's so unpleasent about being drunk?' `You ask a glass of water.' --- Arthur getting ready for his first jump into hyperspace. --- Douglas Adams, The Hitchhikers Guide to the Galaxy syslog.gz Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
intel, KMS, suspend2ram resume, screen black
Dear all, (please Cc) I am running 2.6.32-rc8 with KMS on Debian/sid: xserver-xorg: 7.4+4 video-intel: 2.9.0-1 Suspend to RAM and resume works without any problems, but the one that the screen remains dark. I can switch to a console, can log in there, can shutdown the computer, all fine, but the sscreen is completely black. In addition, I have the impression that resume is immediately followed by a suspend call. Before swithcing to KMS susepnd/resume worked, so I assume that this is a KMS issue. I attach a log (syslog) of the cycle from initial suspend to the manual shutdown. Please let me know if I can help debug that in a way. Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LUDLOW (n.) A wad of newspaper, folded tablenapkin or lump of cardboard put under a wobbly table or chair to make it stand-up straight. It is perhaps not widely known that air-ace Sir Douglas Bader used to get about on an enormous pair of ludlows before he had his artificial legs fitted. --- Douglas Adams, The Meaning of Liff -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added CC||ai...@cisco.com --- Comment #12 from Michel Dänzer mic...@daenzer.net 2009-11-23 23:40:51 PST --- *** Bug 25251 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #13 from Michel Dänzer mic...@daenzer.net 2009-11-23 23:43:18 PST --- Please always include the one-line summary along with Git commit IDs, so humans can make sense of them. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
