[Bug 29901] New: [r300g] Programs crash with segfault
https://bugs.freedesktop.org/show_bug.cgi?id=29901 Summary: [r300g] Programs crash with segfault Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: n...@privat.dk In the last week a lot of my program crash with a segfault (OpenSceneGraph, Blender 2.5.3, Make Human etc.). Other program with gallium works ok. They all crash the same way and here are my (gdb) bt: Program received signal SIGSEGV, Segmentation fault. #0 0x7fffe52fd130 in r300_emit_aos_swtcl (r300=0xfceb40, indexed=0 '\000') at r300_emit.c:847 #1 0x7fffe52fec13 in r300_render_draw_arrays (render=0xb01750, start=, count=4) at r300_render.c:834 #2 0x7fffe54bb52b in draw_pt_emit_linear (emit=, vert_info=, prim_info=0x7fff9930) at draw/draw_pt_emit.c:265 #3 0x7fffe54ba49e in emit (middle=0xa69800, fetch_info=0x7fff9960, prim_info=0x7fff9930) at draw/draw_pt_fetch_shade_pipeline_llvm.c:200 #4 llvm_pipeline_generic (middle=0xa69800, fetch_info=0x7fff9960, prim_info=0x7fff9930) at draw/draw_pt_fetch_shade_pipeline_llvm.c:288 #5 0x7fffe54ba5a4 in llvm_middle_end_linear_run (middle=0xc7, start=, count=4, prim_flags=201) at draw/draw_pt_fetch_shade_pipeline_llvm.c:348 #6 0x7fffe5479981 in vsplit_segment_simple_linear (frontend=0xff60c0, start=368, count=4) at draw/draw_pt_vsplit_tmp.h:229 #7 vsplit_run_linear (frontend=0xff60c0, start=368, count=4) at draw/draw_split_tmp.h:61 #8 0x7fffe5475ba5 in draw_pt_arrays (draw=0xfe1570, info=0x7fffa170) at draw/draw_pt.c:113 #9 draw_vbo (draw=0xfe1570, info=0x7fffa170) at draw/draw_pt.c:398 #10 0x7fffe52ffc86 in r300_swtcl_draw_vbo (pipe=0xfceb40, info=0x7fffa170) at r300_render.c:687 #11 0x7fffe5430b8b in st_draw_vbo (ctx=, arrays=, prims=, nr_prims=, ib=0x0, index_bounds_valid=, min_index=0, max_index=511) at state_tracker/st_draw.c:722 #12 0x7fffe5454588 in vbo_save_playback_vertex_list (ctx=0x100cc20, data=0xe178b0) at vbo/vbo_save_draw.c:287 #13 0x7fffe5340d7a in ext_opcode_execute (ctx=0x100cc20, list=) at main/dlist.c:533 #14 execute_list (ctx=0x100cc20, list=) at main/dlist.c:6883 #15 0x7fffe5343922 in _mesa_CallList (list=3) at main/dlist.c:8140 My system: Radeon 1250x (rs600), ubuntu maverick 10.10 64 bit, running mesa from xorg-edgers fresh X crack (mesa from 30/8/2010). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau X lockup on 36-rc (regression from 2.6.35)
On Mon, 2010-08-30 at 21:54 +0200, Johannes Berg wrote: > > >> Sure, try 5a5608adff833bad37c56278b6194c5b0a5b36bf. > > > > > > An actual url would help ... What is "the nouveau kernel tree"? > > > > > Ah sorry, git://anongit.freedesktop.org/nouveau/linux-2.6. > > Ah, freedesktop, was looking on git.kernel.org. Thanks, I'll install the > kernel now and let you know how it fares when I boot it in the morning. Seems to have fixed the problem, I've been running with this for the past couple of hours without any problems. Thanks! johannes ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27407] The new MESA degrades performance on RS690M and x1270 graphs chip.
https://bugs.freedesktop.org/show_bug.cgi?id=27407 --- Comment #3 from dE 2010-08-31 06:14:49 PDT --- Where can I get this? r300g or 300g doesn't yield any search results in portage. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #26 from Da Fox 2010-08-31 06:37:02 PDT --- (In reply to comment #25) > I got it. > Since the last kernels were all bad ones, progress was made a bit faster. > > # > 32b3c2abaf8c61c80a8b02071c73f05252122ffe is the first bad commit > commit 32b3c2abaf8c61c80a8b02071c73f05252122ffe > Author: Jerome Glisse > Date: Fri Feb 26 19:14:12 2010 + > > drm/radeon/kms: initialize set_surface_reg reg for rs600 asic > > rs600 asic was missing set_surface_reg callback leading to > oops. > > Signed-off-by: Jerome Glisse > Signed-off-by: Dave Airlie > > :04 04 f46b151d49ec9023ce01cded50fda4c52db311cb > 4e640582f7f3b07ed9994422432580070565692e M drivers > Interesting, that is almost the same as what I found, but not exactly. Which repository did you use for bi-secting? I used dave airlie's (airlied) drm, with what was then the drm-next branch. I don't know if that would make a difference though. I don't know how/if git preserves history across merges in different branches, i.e. if you used linuz's tree, would you see the whole history or only the merge points? The reason I am wondering is because to me it seems 32b3c2abaf8c61c80a8b02071c73f05252122ffe is just after 2 merge points, one of which includes the commits I pointed out in my initial comment. (if I understand the gitk listing correctly at least). Also to me 32b3c2abaf8c61c80a8b02071c73f05252122ffe seems unlikely as the culprit, since it modifies something in the rs600 code, and hence should not have any effect on our r3xx cards. Could you possibly see if the following three (consecutive) commits are in your tree too, and test them? 7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 - drm: Add generic multipart buffer. d594e46ace22afa1621254f6f669e65430048153 - drm/radeon/kms: simplify memory controller setup V2 44ca7478d46aaad488d916f7262253e000ee60f9 - drm/radeon: Add asic hook for dma copy to r200 cards. For me 44ca7478d46aaad488d916f7262253e000ee60f9 seems to be the last stable commit (I've been testing it again today, and it didn't freeze so far), whereas I've noted 7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 down as freezing. My notes also say I could not test d594e46ace22afa1621254f6f669e65430048153 for some reason. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27407] The new MESA degrades performance on RS690M and x1270 graphs chip.
https://bugs.freedesktop.org/show_bug.cgi?id=27407 --- Comment #4 from Nicolas Kaiser 2010-08-31 07:06:56 PDT --- (In reply to comment #3) > Where can I get this? r300g or 300g doesn't yield any search results in > portage. With x11 overlay, something like the below? emerge eselect-mesa eselect mesa list Now you should see r300 classic and gallium, and be able to switch between them: eselect mesa set r300 gallium eselect mesa set r300 classic -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #27 from Lukas Schneiderbauer 2010-08-31 09:21:07 PDT --- (In reply to comment #26) > Which repository did you use for bi-secting? Linus' Tree > I don't know how/if git preserves history across merges in > different branches, i.e. if you used linuz's tree, would you see the whole > history or only the merge points? I don't know. I'm not very familiar with git. > Also to me > 32b3c2abaf8c61c80a8b02071c73f05252122ffe seems unlikely as the culprit, since > it modifies something in the rs600 code, and hence should not have any effect > on our r3xx cards. I completely agree. I will rollback a view versions and try "good"-versions again. > Could you possibly see if the following three (consecutive) commits are in > your tree too, and test them? I'd like, as soon as I find out, how to checkout these specific versions. ;) What we need is a damn trigger to this bug. Without reproducibility trying to catch the right commit is a pure matter of luck and very frustrating. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #28 from Da Fox 2010-08-31 13:04:34 PDT --- (In reply to comment #27) > (In reply to comment #26) > > Could you possibly see if the following three (consecutive) commits are in > > your tree too, and test them? > I'd like, as soon as I find out, how to checkout these specific versions. ;) Try something like 'git checkout ' to checkout a specific revision. It will complain if the commit does not exist or if there is something else which prevents the checkout (locally modified files for example). Incase they have a diffent sha1 id in your tree you can try looking for them using 'gitk' (the git repository browser). Since the kernel is so big you may want to limit how far back gitk should show history, try gitk --since=01-01-2010. You can either try to jump directly to the commit by entering a sha1 id into the 'SHA1 ID' box, or by typing a commit message into the 'Find' box. Beware that by default the search is case-sensitive. > What we need is a damn trigger to this bug. Without reproducibility trying to > catch the right commit is a pure matter of luck and very frustrating. I feel your pain, I've also mis-identified an 'unstable' commit as 'stable', which means the whole rest of the bisecting process (which takes a lot of time) is wasted. What triggers the freeze for me most of the time though is opening firefox (with a lot of windows and tabs from my previous browsing session). I do this as soon as I've logged in and my desktop environment has finished loading. On a side note, for those earlier commits (such as 44ca7478d46aaad488d916f7262253e000ee60f9, which I've been testing again during the day), do you also find that the system becomes very slow? As in there is a high CPU usage, but not caused by any running program? I've seen this again today, where top reports all programs using only a small amount of cpu (a grand total of 8% or so), and yet my CPU usage was almost 50%. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #29 from Lukas Schneiderbauer
2010-08-31 13:19:44 PDT ---
Thanks for the help.
I managed to compile and boot the kernel with
7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 as head.
('uname -r' reports "2.6.33-00035-gaa71fa3")
3,5 hours up and so far no freeze.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29913] New: [regression glsl r300g] Heroes of Newerth slowdown after glsl2 merge
https://bugs.freedesktop.org/show_bug.cgi?id=29913 Summary: [regression glsl r300g] Heroes of Newerth slowdown after glsl2 merge Product: Mesa Version: git Platform: Other URL: http://www.heroesofnewerth.com/download.php OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se The game Heroes of Newerth (reproducible in the menu with the client) is slow as molasses after the glsl2 merge. Both the game itself, and normal procedures in X while the game is running (e.g. moving windows around) is noticeably laggy. CPU usage is still low, so I guess something is keeping the GPU busy? This bug have not been bisected, only confirmed by trying the commit immediately before the merge (15a3b42e) which is fine, and the commit with the glsl2 merge (6c03c57) where the problem is apparent. This is most likely the same slowdown I noticed in the game Savage 2 (bug 28517) but I'm filing this separately to be sure. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: fd686668289258ffaf6b81057545e50612aac6a8 -- xserver: 1.8.99.904 (1.9.0 RC 5) -- mesa: 99f3c9caa39fbe9dfa7561c919202395720e9472 -- drm: b61e81a191d3a5c269c5f7c40199aebc9ebc034c -- kernel: 2.6.35 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/r6xx+: use new style fencing (v2)
On r6xx+ a newer fence mechanism was implemented to replace
the old wait_until plus scratch regs setup. A single EOP event
will flush the destination caches, write a fence value, and generate
an interrupt. This is the recommended fence mechanism on r6xx+ asics.
This requires my previous writeback patch.
v2: fix typo that enabled event fence checking on all asics
rather than just r6xx+.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |1 +
drivers/gpu/drm/radeon/r600.c | 41 ---
drivers/gpu/drm/radeon/r600d.h | 21
drivers/gpu/drm/radeon/radeon.h|2 +
drivers/gpu/drm/radeon/radeon_device.c |8 +-
drivers/gpu/drm/radeon/radeon_fence.c |6 -
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 6fe8ca5..8a88a0e 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2399,6 +2399,7 @@ restart_ih:
break;
case 181: /* CP EOP event */
DRM_DEBUG("IH: CP EOP\n");
+ radeon_fence_process(rdev);
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: CP EOP\n");
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ff78265..160948f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2282,21 +2282,31 @@ int r600_ring_test(struct radeon_device *rdev)
void r600_fence_ring_emit(struct radeon_device *rdev,
struct radeon_fence *fence)
{
- /* Also consider EVENT_WRITE_EOP. it handles the interrupts +
timestamps + events */
-
- radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
- radeon_ring_write(rdev, CACHE_FLUSH_AND_INV_EVENT);
- /* wait for 3D idle clean */
- radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
- radeon_ring_write(rdev, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET) >>
2);
- radeon_ring_write(rdev, WAIT_3D_IDLE_bit | WAIT_3D_IDLECLEAN_bit);
- /* Emit fence sequence & fire IRQ */
- radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
- radeon_ring_write(rdev, ((rdev->fence_drv.scratch_reg -
PACKET3_SET_CONFIG_REG_OFFSET) >> 2));
- radeon_ring_write(rdev, fence->seq);
- /* CP_INTERRUPT packet 3 no longer exists, use packet 0 */
- radeon_ring_write(rdev, PACKET0(CP_INT_STATUS, 0));
- radeon_ring_write(rdev, RB_INT_STAT);
+ if (rdev->wb.use_event) {
+ u64 addr = rdev->wb.gpu_addr + R600_WB_EVENT_OFFSET +
+ (u64)(rdev->fence_drv.scratch_reg -
rdev->scratch.reg_base);
+ /* EVENT_WRITE_EOP - flush caches, send int */
+ radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
+ radeon_ring_write(rdev,
EVENT_TYPE(CACHE_FLUSH_AND_INV_EVENT_TS) | EVENT_INDEX(5));
+ radeon_ring_write(rdev, addr & 0x);
+ radeon_ring_write(rdev, (upper_32_bits(addr) & 0xff) |
DATA_SEL(1) | INT_SEL(2));
+ radeon_ring_write(rdev, fence->seq);
+ radeon_ring_write(rdev, 0);
+ } else {
+ radeon_ring_write(rdev, PACKET3(PACKET3_EVENT_WRITE, 0));
+ radeon_ring_write(rdev, EVENT_TYPE(CACHE_FLUSH_AND_INV_EVENT) |
EVENT_INDEX(0));
+ /* wait for 3D idle clean */
+ radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+ radeon_ring_write(rdev, (WAIT_UNTIL -
PACKET3_SET_CONFIG_REG_OFFSET) >> 2);
+ radeon_ring_write(rdev, WAIT_3D_IDLE_bit |
WAIT_3D_IDLECLEAN_bit);
+ /* Emit fence sequence & fire IRQ */
+ radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+ radeon_ring_write(rdev, ((rdev->fence_drv.scratch_reg -
PACKET3_SET_CONFIG_REG_OFFSET) >> 2));
+ radeon_ring_write(rdev, fence->seq);
+ /* CP_INTERRUPT packet 3 no longer exists, use packet 0 */
+ radeon_ring_write(rdev, PACKET0(CP_INT_STATUS, 0));
+ radeon_ring_write(rdev, RB_INT_STAT);
+ }
}
int r600_copy_blit(struct radeon_device *rdev,
@@ -3389,6 +3399,7 @@ restart_ih:
break;
case 181: /* CP EOP event */
DRM_DEBUG("IH: CP EOP\n");
+ radeon_fence_process(rdev);
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: CP EOP\n");
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 858a192..966a793 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -474,6 +474,7 @@
#defineVGT_VERTEX_REUSE_BLOCK_CNTL 0x28C58
#define
[Bug 29901] New: [r300g] Programs crash with segfault
https://bugs.freedesktop.org/show_bug.cgi?id=29901 Summary: [r300g] Programs crash with segfault Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ncl at privat.dk In the last week a lot of my program crash with a segfault (OpenSceneGraph, Blender 2.5.3, Make Human etc.). Other program with gallium works ok. They all crash the same way and here are my (gdb) bt: Program received signal SIGSEGV, Segmentation fault. #0 0x7fffe52fd130 in r300_emit_aos_swtcl (r300=0xfceb40, indexed=0 '\000') at r300_emit.c:847 #1 0x7fffe52fec13 in r300_render_draw_arrays (render=0xb01750, start=, count=4) at r300_render.c:834 #2 0x7fffe54bb52b in draw_pt_emit_linear (emit=, vert_info=, prim_info=0x7fff9930) at draw/draw_pt_emit.c:265 #3 0x7fffe54ba49e in emit (middle=0xa69800, fetch_info=0x7fff9960, prim_info=0x7fff9930) at draw/draw_pt_fetch_shade_pipeline_llvm.c:200 #4 llvm_pipeline_generic (middle=0xa69800, fetch_info=0x7fff9960, prim_info=0x7fff9930) at draw/draw_pt_fetch_shade_pipeline_llvm.c:288 #5 0x7fffe54ba5a4 in llvm_middle_end_linear_run (middle=0xc7, start=, count=4, prim_flags=201) at draw/draw_pt_fetch_shade_pipeline_llvm.c:348 #6 0x7fffe5479981 in vsplit_segment_simple_linear (frontend=0xff60c0, start=368, count=4) at draw/draw_pt_vsplit_tmp.h:229 #7 vsplit_run_linear (frontend=0xff60c0, start=368, count=4) at draw/draw_split_tmp.h:61 #8 0x7fffe5475ba5 in draw_pt_arrays (draw=0xfe1570, info=0x7fffa170) at draw/draw_pt.c:113 #9 draw_vbo (draw=0xfe1570, info=0x7fffa170) at draw/draw_pt.c:398 #10 0x7fffe52ffc86 in r300_swtcl_draw_vbo (pipe=0xfceb40, info=0x7fffa170) at r300_render.c:687 #11 0x7fffe5430b8b in st_draw_vbo (ctx=, arrays=, prims=, nr_prims=, ib=0x0, index_bounds_valid=, min_index=0, max_index=511) at state_tracker/st_draw.c:722 #12 0x7fffe5454588 in vbo_save_playback_vertex_list (ctx=0x100cc20, data=0xe178b0) at vbo/vbo_save_draw.c:287 #13 0x7fffe5340d7a in ext_opcode_execute (ctx=0x100cc20, list=) at main/dlist.c:533 #14 execute_list (ctx=0x100cc20, list=) at main/dlist.c:6883 #15 0x7fffe5343922 in _mesa_CallList (list=3) at main/dlist.c:8140 My system: Radeon 1250x (rs600), ubuntu maverick 10.10 64 bit, running mesa from xorg-edgers fresh X crack (mesa from 30/8/2010). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
nouveau X lockup on 36-rc (regression from 2.6.35)
On Mon, 2010-08-30 at 21:54 +0200, Johannes Berg wrote: > > >> Sure, try 5a5608adff833bad37c56278b6194c5b0a5b36bf. > > > > > > An actual url would help ... What is "the nouveau kernel tree"? > > > > > Ah sorry, git://anongit.freedesktop.org/nouveau/linux-2.6. > > Ah, freedesktop, was looking on git.kernel.org. Thanks, I'll install the > kernel now and let you know how it fares when I boot it in the morning. Seems to have fixed the problem, I've been running with this for the past couple of hours without any problems. Thanks! johannes
[Bug 27407] The new MESA degrades performance on RS690M and x1270 graphs chip.
https://bugs.freedesktop.org/show_bug.cgi?id=27407 --- Comment #3 from dE 2010-08-31 06:14:49 PDT --- Where can I get this? r300g or 300g doesn't yield any search results in portage. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #26 from Da Fox 2010-08-31 06:37:02 PDT --- (In reply to comment #25) > I got it. > Since the last kernels were all bad ones, progress was made a bit faster. > > # > 32b3c2abaf8c61c80a8b02071c73f05252122ffe is the first bad commit > commit 32b3c2abaf8c61c80a8b02071c73f05252122ffe > Author: Jerome Glisse > Date: Fri Feb 26 19:14:12 2010 + > > drm/radeon/kms: initialize set_surface_reg reg for rs600 asic > > rs600 asic was missing set_surface_reg callback leading to > oops. > > Signed-off-by: Jerome Glisse > Signed-off-by: Dave Airlie > > :04 04 f46b151d49ec9023ce01cded50fda4c52db311cb > 4e640582f7f3b07ed9994422432580070565692e M drivers > Interesting, that is almost the same as what I found, but not exactly. Which repository did you use for bi-secting? I used dave airlie's (airlied) drm, with what was then the drm-next branch. I don't know if that would make a difference though. I don't know how/if git preserves history across merges in different branches, i.e. if you used linuz's tree, would you see the whole history or only the merge points? The reason I am wondering is because to me it seems 32b3c2abaf8c61c80a8b02071c73f05252122ffe is just after 2 merge points, one of which includes the commits I pointed out in my initial comment. (if I understand the gitk listing correctly at least). Also to me 32b3c2abaf8c61c80a8b02071c73f05252122ffe seems unlikely as the culprit, since it modifies something in the rs600 code, and hence should not have any effect on our r3xx cards. Could you possibly see if the following three (consecutive) commits are in your tree too, and test them? 7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 - drm: Add generic multipart buffer. d594e46ace22afa1621254f6f669e65430048153 - drm/radeon/kms: simplify memory controller setup V2 44ca7478d46aaad488d916f7262253e000ee60f9 - drm/radeon: Add asic hook for dma copy to r200 cards. For me 44ca7478d46aaad488d916f7262253e000ee60f9 seems to be the last stable commit (I've been testing it again today, and it didn't freeze so far), whereas I've noted 7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 down as freezing. My notes also say I could not test d594e46ace22afa1621254f6f669e65430048153 for some reason. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27407] The new MESA degrades performance on RS690M and x1270 graphs chip.
https://bugs.freedesktop.org/show_bug.cgi?id=27407 --- Comment #4 from Nicolas Kaiser 2010-08-31 07:06:56 PDT --- (In reply to comment #3) > Where can I get this? r300g or 300g doesn't yield any search results in > portage. With x11 overlay, something like the below? emerge eselect-mesa eselect mesa list Now you should see r300 classic and gallium, and be able to switch between them: eselect mesa set r300 gallium eselect mesa set r300 classic -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #27 from Lukas Schneiderbauer 2010-08-31 09:21:07 PDT --- (In reply to comment #26) > Which repository did you use for bi-secting? Linus' Tree > I don't know how/if git preserves history across merges in > different branches, i.e. if you used linuz's tree, would you see the whole > history or only the merge points? I don't know. I'm not very familiar with git. > Also to me > 32b3c2abaf8c61c80a8b02071c73f05252122ffe seems unlikely as the culprit, since > it modifies something in the rs600 code, and hence should not have any effect > on our r3xx cards. I completely agree. I will rollback a view versions and try "good"-versions again. > Could you possibly see if the following three (consecutive) commits are in > your tree too, and test them? I'd like, as soon as I find out, how to checkout these specific versions. ;) What we need is a damn trigger to this bug. Without reproducibility trying to catch the right commit is a pure matter of luck and very frustrating. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #28 from Da Fox 2010-08-31 13:04:34 PDT --- (In reply to comment #27) > (In reply to comment #26) > > Could you possibly see if the following three (consecutive) commits are in > > your tree too, and test them? > I'd like, as soon as I find out, how to checkout these specific versions. ;) Try something like 'git checkout ' to checkout a specific revision. It will complain if the commit does not exist or if there is something else which prevents the checkout (locally modified files for example). Incase they have a diffent sha1 id in your tree you can try looking for them using 'gitk' (the git repository browser). Since the kernel is so big you may want to limit how far back gitk should show history, try gitk --since=01-01-2010. You can either try to jump directly to the commit by entering a sha1 id into the 'SHA1 ID' box, or by typing a commit message into the 'Find' box. Beware that by default the search is case-sensitive. > What we need is a damn trigger to this bug. Without reproducibility trying to > catch the right commit is a pure matter of luck and very frustrating. I feel your pain, I've also mis-identified an 'unstable' commit as 'stable', which means the whole rest of the bisecting process (which takes a lot of time) is wasted. What triggers the freeze for me most of the time though is opening firefox (with a lot of windows and tabs from my previous browsing session). I do this as soon as I've logged in and my desktop environment has finished loading. On a side note, for those earlier commits (such as 44ca7478d46aaad488d916f7262253e000ee60f9, which I've been testing again during the day), do you also find that the system becomes very slow? As in there is a high CPU usage, but not caused by any running program? I've seen this again today, where top reports all programs using only a small amount of cpu (a grand total of 8% or so), and yet my CPU usage was almost 50%. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28402] Kernel 2.6.34 freezes randomly
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #29 from Lukas Schneiderbauer
2010-08-31 13:19:44 PDT ---
Thanks for the help.
I managed to compile and boot the kernel with
7a9f0dd9c49425e2b0e39ada4757bc7a38c84873 as head.
('uname -r' reports "2.6.33-00035-gaa71fa3")
3,5 hours up and so far no freeze.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 29913] New: [regression glsl r300g] Heroes of Newerth slowdown after glsl2 merge
https://bugs.freedesktop.org/show_bug.cgi?id=29913 Summary: [regression glsl r300g] Heroes of Newerth slowdown after glsl2 merge Product: Mesa Version: git Platform: Other URL: http://www.heroesofnewerth.com/download.php OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se The game Heroes of Newerth (reproducible in the menu with the client) is slow as molasses after the glsl2 merge. Both the game itself, and normal procedures in X while the game is running (e.g. moving windows around) is noticeably laggy. CPU usage is still low, so I guess something is keeping the GPU busy? This bug have not been bisected, only confirmed by trying the commit immediately before the merge (15a3b42e) which is fine, and the commit with the glsl2 merge (6c03c57) where the problem is apparent. This is most likely the same slowdown I noticed in the game Savage 2 (bug 28517) but I'm filing this separately to be sure. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: fd686668289258ffaf6b81057545e50612aac6a8 -- xserver: 1.8.99.904 (1.9.0 RC 5) -- mesa: 99f3c9caa39fbe9dfa7561c919202395720e9472 -- drm: b61e81a191d3a5c269c5f7c40199aebc9ebc034c -- kernel: 2.6.35 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
