[Bug 23710] [R500] doom3 lockups when starting a new game
http://bugs.freedesktop.org/show_bug.cgi?id=23710 --- Comment #4 from Fabio fabio@libero.it 2009-09-08 01:02:39 PST --- OK, the game can indeed be killed from another box after sshing from it. I also tried the patch attached to bug #22372 comment #8, but it doesn't change anything. Other bugs that may be related to this are: bug #22742, bug #22741. -- 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 23710] [R500] doom3 lockups when starting a new game
http://bugs.freedesktop.org/show_bug.cgi?id=23710 --- Comment #5 from Fabio fabio@libero.it 2009-09-08 01:07:13 PST --- Just want to add that after killing the game without the patch I get this assert: doom.x86: radeon_mipmap_tree.c:117: compute_tex_image_offset: Assertion `lvl-size 0' failed. while when killing it with the patch I get this: doom.x86: radeon_texture.c:874: 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: [PATCH] dri2proto: protocol requests for OML_sync_control and SGI_video_sync
On Sun, 2009-09-06 at 09:46 -0700, Jesse Barnes wrote: On Sun, 06 Sep 2009 12:23:12 +0200 Michel Dänzer mic...@daenzer.net wrote: On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: I've been working on coding up the server and client side of SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with this set of new protocol (against the dri2-swapbuffers branch) to support the new requests. We still need to change the DRI2SwapBuffers request to handle the various OML bits before it gets merged. To summarize: DRI2GetMSCReq - get MSC triple DRI2WaitMSCReq - wait on an MSC count or divisor/remainder DRI2WaitSBCReq - wait on a swap count or all pending swaps Waiting in the X server will make it quite unlikely that the client will be notified within a reasonable timeframe from when vertical blank actually occurs. Won't this jeopardize the usefulness of the functionality? As they're mainly used for throttling drawing, I don't think so. But I also don't see a way to avoid it. In the composited case, compositor interaction will be necessary, and even for non-redirected windows, the client doesn't know which CRTC it's on w/o racing with the server. Waiting in the server doesn't solve the latter problem, does it? The window could move to another CRTC while it's waiting. - compositor interaction; in the compositor case the display server will be incrementing frame count based on compositor drawing rather than vblank events I think that's a bad idea, as it will confuse apps if the compositor misses a frame or renders the app window more than once per frame. It seems to match what people want though; so far we've heard from Soren and Robert and both want to know when the pixels are actually displayed for various apps. W/o compositor interaction I don't see how we can do that. I'm not arguing there should be no protocol between the compositor and clients, but I'm arguing that the frame counter probably isn't appropriate for this. -- 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 23710] [R500] doom3 lockups when starting a new game
http://bugs.freedesktop.org/show_bug.cgi?id=23710 --- Comment #6 from Michel Dänzer mic...@daenzer.net 2009-09-08 01:53:22 PST --- The hang is probably related to the DRI1 lock, and may not happen with DRI2. Not sure anything can be done for DRI1, though this may have been made worse by a recent signal related DRM change which helped for starting a DRI1 enabled X server in gdb. -- 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 20647] display hangs with radeon driver in Xorg 1.6
http://bugs.freedesktop.org/show_bug.cgi?id=20647 414N grsf...@tiscali.it changed: What|Removed |Added CC||grsf...@tiscali.it Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #14 from 414N grsf...@tiscali.it 2009-09-08 02:53:50 PST --- I stumbled upon this resolved bug report searching a solution for my issue not resolved, seeing symptoms so close to mines. I've got an ATI Radeon X800 XT PE on a machine running Slackware64 13.0 (xorg 1.6) using the open-source radeon driver. I enabled EXA acceleration and everything works quite well (even desktop compositing effects in KDE 4), except a few things: - Whenever I run OpenOffice, it hangs the entire X server at the welcome screen as soon as I push the 'Next' button in order to fill in my personal information. This happens with compositing effects enabled or disabled, and even in TWM (so it's not a KDE issue). Tried a few options in xorg.conf and turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). Seems quite strange that OpenOffice makes X hang because of DRI... - Some 3D games run through wine (32 bit, with mesa 32 libs installed correctly) cause the same issue, but not all. Every game I run in SDLMame (3D or 2D) doesn't hang X. I can ssh into the the machine through my laptop, in order to see what's happening. 'top' displays X as a CPU devourer beast. Obviously, no relevant information can be found in Xorg.0.log as soon as the hang occurs. Any suggestions? -- 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 20647] display hangs with radeon driver in Xorg 1.6
http://bugs.freedesktop.org/show_bug.cgi?id=20647 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #15 from Michel Dänzer mic...@daenzer.net 2009-09-08 03:11:19 PST --- (In reply to comment #14) Tried a few options in xorg.conf and turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). So it's definitely not the same problem, please file a separate report. -- 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
[PATCH] drm/radeon: Fix DFS corruption for r100/r200.
Bliting data while some of engines is still running or 2D engine as dirty
cache may cause pixmap or font glyph corruption.
Fix is to wait for 3D engine to be idle. Then we have to also flush 2D engine
in case if cache has outdated data for system memory where we are going to blit.
While it would be better only to flush when necessary it is very hard to know
when it is required. So we do flush every time because it is better to be safe
than sorry.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
drivers/gpu/drm/radeon/r100.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index b6a7472..8becc68 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -431,12 +431,21 @@ int r100_copy_blit(struct radeon_device *rdev,
num_loops = DIV_ROUND_UP(num_pages, 8191);
/* Ask for enough room for blit + flush + fence */
- ndw = 64 + (10 * num_loops);
+ ndw = 70 + (10 * num_loops);
r = radeon_ring_lock(rdev, ndw);
if (r) {
DRM_ERROR(radeon: moving bo (%d) asking for %u dw.\n, r, ndw);
return -EINVAL;
}
+
+ radeon_ring_write(rdev, PACKET0(RADEON_WAIT_UNTIL, 0));
+ radeon_ring_write(rdev,
+ RADEON_WAIT_3D_IDLECLEAN);
+ radeon_ring_write(rdev, PACKET0(RADEON_DSTCACHE_CTLSTAT, 0));
+ radeon_ring_write(rdev, RADEON_RB2D_DC_FLUSH_ALL);
+ radeon_ring_write(rdev, PACKET0(RADEON_WAIT_UNTIL, 0));
+ radeon_ring_write(rdev,
+ RADEON_WAIT_2D_IDLECLEAN);
while (num_pages 0) {
cur_pages = num_pages;
if (cur_pages 8191) {
--
1.6.3.3
--
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 23745] x11-drivers/xf86-video-ati: No DRI and wrong colors for OpenGL (Pegasos II + Radeon 9000)
http://bugs.freedesktop.org/show_bug.cgi?id=23745 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Component|libdrm |DRM/other --- Comment #1 from Michel Dänzer mic...@daenzer.net 2009-09-08 05:58:09 PST --- all colors are wrong if you use OpenGL (Mesa). That's bug 22767. drmGetBusid() calls the kernel module drm via IOCTL DRM_IOCTL_GET_UNIQUE. (see file drm_ioc32.c). So is it a bug in the kernel or libdrm? Yes, the problem is that while the X server has been fixed to properly handle PCI domains 0, drm_get_pci_domain() in the kernel is still hardcoded to 0. Unfortunately that can't be fixed easily, or it will break older X servers. So the fix will probably require some DRM userspace interface versioning magic. -- 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 20647] display hangs with radeon driver in Xorg 1.6
http://bugs.freedesktop.org/show_bug.cgi?id=20647 --- Comment #16 from Alex Deucher ag...@yahoo.com 2009-09-08 07:17:20 PST --- (In reply to comment #14) I stumbled upon this resolved bug report searching a solution for my issue not resolved, seeing symptoms so close to mines. I've got an ATI Radeon X800 XT PE on a machine running Slackware64 13.0 (xorg 1.6) using the open-source radeon driver. I enabled EXA acceleration and everything works quite well (even desktop compositing effects in KDE 4), except a few things: - Whenever I run OpenOffice, it hangs the entire X server at the welcome screen as soon as I push the 'Next' button in order to fill in my personal information. This happens with compositing effects enabled or disabled, and even in TWM (so it's not a KDE issue). Tried a few options in xorg.conf and turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). Seems quite strange that OpenOffice makes X hang because of DRI... Sounds like bug 13176. Please try the patch there in comment 18. -- 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 20647] display hangs with radeon driver in Xorg 1.6
http://bugs.freedesktop.org/show_bug.cgi?id=20647 --- Comment #17 from 414N grsf...@tiscali.it 2009-09-08 08:09:45 PST --- Sounds like bug 13176. Please try the patch there in comment 18. Don't know why I didn't see this before. After the hang up occurs, the X log gets filled with these messages: [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. So, I don't think it's anything like bug #13176. I'm gonna open a new bug report. -- 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 23793] New: OpenOffice and wine cause X hang-ups on radeon X800 XT PE
http://bugs.freedesktop.org/show_bug.cgi?id=23793 Summary: OpenOffice and wine cause X hang-ups on radeon X800 XT PE Product: DRI Version: XOrg 6.7.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: grsf...@tiscali.it Created an attachment (id=29339) -- (http://bugs.freedesktop.org/attachment.cgi?id=29339) Xorg.0.log after hang up I've got an ATI Radeon X800 XT PE on a machine running Slackware64 13.0 (xorg 1.6) using the open-source radeon driver. I enabled EXA acceleration and everything works quite well (even desktop compositing effects in KDE 4), except a few things: - Whenever I run OpenOffice, it hangs the entire X server at the welcome screen as soon as I push the 'Next' button in order to fill in my personal information. This happens with compositing effects enabled or disabled, and even in TWM (so it's not a KDE issue). Tried a few options in xorg.conf and turning off DRI did the trick. Changing AGPMode to 2 didn't (didn't try 1). Seems quite strange that OpenOffice makes X hang because of DRI... After entering my personal information and re-enabling DRI, X hangs as soon as I choose to help or not the development of openoffice.org. - Some 3D games run through wine (32 bit, with mesa 32 libs installed correctly) cause the same issue, but not all. Every game I run in SDLMame (3D or 2D) doesn't hang X. I can ssh into the the machine through my laptop, in order to see what's happening (and reboot/halt it, of course). 'top' displays X as a CPU devourer beast. Looking at Xorg.0.log through my ssh session, I can see a lot of lines like this at the end of the file: [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnqueue: more than six valuator events; dropping. Suggestions? -- 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 20647] display hangs with radeon driver in Xorg 1.6
http://bugs.freedesktop.org/show_bug.cgi?id=20647 --- Comment #18 from 414N grsf...@tiscali.it 2009-09-08 08:33:37 PST --- (In reply to comment #17) I'm gonna open a new bug report. Done. It's bug #23793 -- 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] drm/radeon: Fix DFS corruption for r100/r200.
On Tue, Sep 8, 2009 at 8:26 AM, Pauli Nieminensuok...@gmail.com wrote:
Bliting data while some of engines is still running or 2D engine as dirty
cache may cause pixmap or font glyph corruption.
Fix is to wait for 3D engine to be idle. Then we have to also flush 2D engine
in case if cache has outdated data for system memory where we are going to
blit.
While it would be better only to flush when necessary it is very hard to know
when it is required. So we do flush every time because it is better to be safe
than sorry.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
drivers/gpu/drm/radeon/r100.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index b6a7472..8becc68 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -431,12 +431,21 @@ int r100_copy_blit(struct radeon_device *rdev,
num_loops = DIV_ROUND_UP(num_pages, 8191);
/* Ask for enough room for blit + flush + fence */
- ndw = 64 + (10 * num_loops);
+ ndw = 70 + (10 * num_loops);
r = radeon_ring_lock(rdev, ndw);
if (r) {
DRM_ERROR(radeon: moving bo (%d) asking for %u dw.\n, r,
ndw);
return -EINVAL;
}
+
+ radeon_ring_write(rdev, PACKET0(RADEON_WAIT_UNTIL, 0));
+ radeon_ring_write(rdev,
+ RADEON_WAIT_3D_IDLECLEAN);
You should just be able to set both RADEON_WAIT_3D_IDLECLEAN and
RADEON_WAIT_2D_IDLECLEAN here rather than appending a second packet 0.
+ radeon_ring_write(rdev, PACKET0(RADEON_DSTCACHE_CTLSTAT, 0));
+ radeon_ring_write(rdev, RADEON_RB2D_DC_FLUSH_ALL);
+ radeon_ring_write(rdev, PACKET0(RADEON_WAIT_UNTIL, 0));
+ radeon_ring_write(rdev,
+ RADEON_WAIT_2D_IDLECLEAN);
while (num_pages 0) {
cur_pages = num_pages;
if (cur_pages 8191) {
--
1.6.3.3
--
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
--
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] dri2proto: protocol requests for OML_sync_control and SGI_video_sync
On Tue, 08 Sep 2009 10:37:38 +0200 Michel Dänzer mic...@daenzer.net wrote: On Sun, 2009-09-06 at 09:46 -0700, Jesse Barnes wrote: On Sun, 06 Sep 2009 12:23:12 +0200 Michel Dänzer mic...@daenzer.net wrote: On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: I've been working on coding up the server and client side of SGI_video_sync, OML_sync_control and SGI_swap_control. I came up with this set of new protocol (against the dri2-swapbuffers branch) to support the new requests. We still need to change the DRI2SwapBuffers request to handle the various OML bits before it gets merged. To summarize: DRI2GetMSCReq - get MSC triple DRI2WaitMSCReq - wait on an MSC count or divisor/remainder DRI2WaitSBCReq - wait on a swap count or all pending swaps Waiting in the X server will make it quite unlikely that the client will be notified within a reasonable timeframe from when vertical blank actually occurs. Won't this jeopardize the usefulness of the functionality? As they're mainly used for throttling drawing, I don't think so. But I also don't see a way to avoid it. In the composited case, compositor interaction will be necessary, and even for non-redirected windows, the client doesn't know which CRTC it's on w/o racing with the server. Waiting in the server doesn't solve the latter problem, does it? The window could move to another CRTC while it's waiting. It does make it easier to either ask for a new event or block the cliprect update until we get the event. If we ended up blocking all the time we could just move the wait to the client though. - compositor interaction; in the compositor case the display server will be incrementing frame count based on compositor drawing rather than vblank events I think that's a bad idea, as it will confuse apps if the compositor misses a frame or renders the app window more than once per frame. It seems to match what people want though; so far we've heard from Soren and Robert and both want to know when the pixels are actually displayed for various apps. W/o compositor interaction I don't see how we can do that. I'm not arguing there should be no protocol between the compositor and clients, but I'm arguing that the frame counter probably isn't appropriate for this. It seemed like a natural fit to me since the compositor really is determining the application frame rate in the redirected case. But you're right that it could end up being a variable frequency counter. Existing apps may not handle that very well, I'm not sure. -- Jesse Barnes, Intel Open Source Technology Center -- 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 23793] OpenOffice and wine cause X hang-ups on radeon X800 XT PE
http://bugs.freedesktop.org/show_bug.cgi?id=23793 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex Deucher ag...@yahoo.com 2009-09-08 09:49:52 PST --- *** This bug has been marked as a duplicate of bug 13176 *** -- 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 23793] OpenOffice and wine cause X hang-ups on radeon X800 XT PE
http://bugs.freedesktop.org/show_bug.cgi?id=23793 --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-09-08 08:44:27 PST --- Looks like bug 13176. Does the patch there in comment 18 help? -- 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 23793] OpenOffice and wine cause X hang-ups on radeon X800 XT PE
http://bugs.freedesktop.org/show_bug.cgi?id=23793 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #29339|application/octet-stream|text/plain mime type|| Attachment #29339|0 |1 is patch|| -- 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 23793] OpenOffice and wine cause X hang-ups on radeon X800 XT PE
http://bugs.freedesktop.org/show_bug.cgi?id=23793 --- Comment #2 from 414N grsf...@tiscali.it 2009-09-08 09:40:35 PST --- (In reply to comment #1) Looks like bug 13176. Does the patch there in comment 18 help? Yes, it helps. I forgot to mention my kernel version before: it is 2.6.29.6. OpenOffice doesn't hang X anymore, but 3D wine games still cause the problem, this time showing nothing in Xorg.0.log. -- 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 r6xx with KMS not working
2009/9/8 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothianm...@fireburn.co.uk wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). Pull the latest from the drm-next branch. Alex Just noticed that after Perry pointed out the fix on Phoronix Thanks Will let you know how I get on -- 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 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #4 from Brian Paul brian.e.p...@gmail.com 2009-09-08 15:32:57 PST --- Could you provide more details about the failing cases (maybe run conform with -v 2)? It looks like the failures are related to glCopyPixels(GL_DEPTH) and glDrawPixels(GL_DEPTH_COMPONENT) with pixel transfer ops. I've tested those cases here with other test programs and found that glPixelTransfer(GL_DEPTH_SCALE/BIAS) works properly. -- 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 r6xx with KMS not working
2009/9/8 Mike Lothian m...@fireburn.co.uk: 2009/9/8 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothianm...@fireburn.co.uk wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). Pull the latest from the drm-next branch. Alex Just noticed that after Perry pointed out the fix on Phoronix Thanks Will let you know how I get on The good news is that KMS now works, the bad news is KDM still wont start with compositing. Plain X works and glxgears work as does KDM with compositing off Glxgears says: IRQ's not enabled, falling back to busy waits: 2 1 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. My dmesg says: Unpin not necessary for 88007c9a1600 ! Unpin not necessary for 88006eda6400 ! Unpin not necessary for 88006b14d400 ! I couldn't see anything in my Xorg.0.log file that would explain why KDM keeps rebooting Is there anything else that might be useful? -- 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 r6xx with KMS not working
On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothianm...@fireburn.co.uk wrote: 2009/9/8 Mike Lothian m...@fireburn.co.uk: 2009/9/8 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothianm...@fireburn.co.uk wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). Pull the latest from the drm-next branch. Alex Just noticed that after Perry pointed out the fix on Phoronix Thanks Will let you know how I get on The good news is that KMS now works, the bad news is KDM still wont start with compositing. Plain X works and glxgears work as does KDM with compositing off Glxgears says: IRQ's not enabled, falling back to busy waits: 2 1 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. My dmesg says: Unpin not necessary for 88007c9a1600 ! Unpin not necessary for 88006eda6400 ! Unpin not necessary for 88006b14d400 ! I couldn't see anything in my Xorg.0.log file that would explain why KDM keeps rebooting Is there anything else that might be useful? kde GL compositing doesn't work that well at the moment even without KMS. 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
Radeon r6xx with KMS not working
Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) Unfortunately I don't have any logs of the hard crash even a remote ssh with tail -f /var/log/messages and Xorg.0.log doesn't show anything before making the box unusable My card is: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV730 PRO [Radeon HD 4650] [1002:9498] 01:00.1 Audio device [0403]: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Series] [1002:aa38] This card works fine using a 2.6.30 kernel and the r6xx-r7xx-3d branch All X components are at the latest git Regards Mike dmesg.log.080909.tar.gz Description: GNU Zip compressed data Xorg.0.log.080909.tar.gz Description: GNU Zip compressed 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
Re: Radeon r6xx with KMS not working
2009/9/9 Mike Lothian m...@fireburn.co.uk: I'm reporting a regression from the r6xx-r7xx-3d tree, the new code causes X to restart Probably EXA (already confirmed on some machines) bug. What is your X's backtrace? -- 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
Re: Radeon r6xx with KMS not working
On Tue, Sep 8, 2009 at 8:20 PM, Mike Lothianm...@fireburn.co.uk wrote: 2009/9/9 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothianm...@fireburn.co.uk wrote: 2009/9/8 Mike Lothian m...@fireburn.co.uk: 2009/9/8 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothianm...@fireburn.co.uk wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). Pull the latest from the drm-next branch. Alex Just noticed that after Perry pointed out the fix on Phoronix Thanks Will let you know how I get on The good news is that KMS now works, the bad news is KDM still wont start with compositing. Plain X works and glxgears work as does KDM with compositing off Glxgears says: IRQ's not enabled, falling back to busy waits: 2 1 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. My dmesg says: Unpin not necessary for 88007c9a1600 ! Unpin not necessary for 88006eda6400 ! Unpin not necessary for 88006b14d400 ! I couldn't see anything in my Xorg.0.log file that would explain why KDM keeps rebooting Is there anything else that might be useful? kde GL compositing doesn't work that well at the moment even without KMS. Alex I'm reporting a regression from the r6xx-r7xx-3d tree, the new code causes X to restart It's not a regression as KMS did not work until recently; lots of stuff has problems in dri2 mode with the current r600 3d driver. Or are you saying that the drm-next code with KMS disabled is causing a problem? 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 r6xx with KMS not working
2009/9/9 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 7:17 PM, Mike Lothianm...@fireburn.co.uk wrote: 2009/9/8 Mike Lothian m...@fireburn.co.uk: 2009/9/8 Alex Deucher alexdeuc...@gmail.com: On Tue, Sep 8, 2009 at 6:34 PM, Mike Lothianm...@fireburn.co.uk wrote: Hi When using the new drm-next branch KMS fails (see attached logs) with radeon.modeset=0 passed the computer will hard lockup when KDM is starting (I think this is when the compositing is started) [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-16). [drm:rv770_init] *ERROR* radeon: failled testing IB (-16). Pull the latest from the drm-next branch. Alex Just noticed that after Perry pointed out the fix on Phoronix Thanks Will let you know how I get on The good news is that KMS now works, the bad news is KDM still wont start with compositing. Plain X works and glxgears work as does KDM with compositing off Glxgears says: IRQ's not enabled, falling back to busy waits: 2 1 do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. My dmesg says: Unpin not necessary for 88007c9a1600 ! Unpin not necessary for 88006eda6400 ! Unpin not necessary for 88006b14d400 ! I couldn't see anything in my Xorg.0.log file that would explain why KDM keeps rebooting Is there anything else that might be useful? kde GL compositing doesn't work that well at the moment even without KMS. Alex I'm reporting a regression from the r6xx-r7xx-3d tree, the new code causes X to restart -- 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 23670] [bisected i915 i965] glean case pixelFormats failed
http://bugs.freedesktop.org/show_bug.cgi?id=23670 --- Comment #5 from Shuang He shuang...@intel.com 2009-09-08 22:40:03 PST --- (In reply to comment #4) Could you provide more details about the failing cases (maybe run conform with -v 2)? It looks like the failures are related to glCopyPixels(GL_DEPTH) and glDrawPixels(GL_DEPTH_COMPONENT) with pixel transfer ops. I've tested those cases here with other test programs and found that glPixelTransfer(GL_DEPTH_SCALE/BIAS) works properly. For OGLC/copypix.c, it fails with glDrawPixels(GL_STENCIL_INDEX) and glCopyPixels(GL_STENCIL) -- 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
