https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #67 from Alexandre Demers ---
(In reply to comment #66)
> Pushed:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=4409758a046a47b09cdd339f97afd22107c68f0c
It seems ok over here. Thank you.
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #65 from Alex Deucher ---
After a little more investigation this weekend, I think I found the root cause.
On cayman, 128bpp surfaces require non_disp ordering for hw access to both
linear and tiled surfaces. When we use the 3D engin
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #67 from Alexandre Demers ---
(In reply to comment #66)
> Pushed:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=4409758a046a47b09cdd339f97afd22107c68f0c
It seems ok over here. Thank you.
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #65 from Alex Deucher ---
After a little more investigation this weekend, I think I found the root cause.
On cayman, 128bpp surfaces require non_disp ordering for hw access to both
linear and tiled surfaces. When we use the 3D engin
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #64 from Alexandre Demers ---
(In reply to comment #63)
> Created attachment 76592 [details] [review]
> take 5
>
> After further investigation this seems to be an alignment issue with large
> block sizes on the DMA engine on cayman.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76590|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #64 from Alexandre Demers ---
(In reply to comment #63)
> Created attachment 76592 [details] [review]
> take 5
>
> After further investigation this seems to be an alignment issue with large
> block sizes on the DMA engine on cayman.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #62 from Alex Deucher ---
The way to properly handle T2L or L2T conversions of compressed textures with
the DMA engine is to hack up the formats like we do in the blitter code so that
it looks like a PIPE_FORMAT_R16G16B16A16_UINT or P
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #61 from Alex Deucher ---
(In reply to comment #59)
> Alex, a couple of things changed in your last attachment. You removed the
> L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed
> the binary offset for 28
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76563|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #59 from Alexandre Demers ---
Alex, a couple of things changed in your last attachment. You removed the L2T
part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the
binary offset for 28 (instead of 27). Am I right
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #58 from Anthony Waters ---
That didn't work either, the L2T path is the one that keeps getting executed.
In my case dst_mode is RADEON_SURF_MODE_2D or RADEON_SURF_MODE_1D and src_mode
is RADEON_SURF_MODE_LINEAR_ALIGNED.
I'll see if
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76557|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76590|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #56 from Anthony Waters ---
take 2 didn't work for me, I also tried (non_disp << 28) to (non_disp << 30)
and those didn't fix it either.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next p
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76544|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #62 from Alex Deucher ---
The way to properly handle T2L or L2T conversions of compressed textures with
the DMA engine is to hack up the formats like we do in the blitter code so that
it looks like a PIPE_FORMAT_R16G16B16A16_UINT or P
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #61 from Alex Deucher ---
(In reply to comment #59)
> Alex, a couple of things changed in your last attachment. You removed the
> L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed
> the binary offset for 28
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76563|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #59 from Alexandre Demers ---
Alex, a couple of things changed in your last attachment. You removed the L2T
part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the
binary offset for 28 (instead of 27). Am I right
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #58 from Anthony Waters ---
That didn't work either, the L2T path is the one that keeps getting executed.
In my case dst_mode is RADEON_SURF_MODE_2D or RADEON_SURF_MODE_1D and src_mode
is RADEON_SURF_MODE_LINEAR_ALIGNED.
I'll see if
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76557|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #56 from Anthony Waters ---
take 2 didn't work for me, I also tried (non_disp << 28) to (non_disp << 30)
and those didn't fix it either.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alex Deucher changed:
What|Removed |Added
Attachment #76544|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #54 from Alexandre Demers ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
>
> Good catch! I believe the attached patch should fix the issue.
Since this bug is pretty
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #53 from Alexandre Demers ---
(In reply to comment #50)
> I believe I have the source of the bug, it appears that there is a special
> case for Caymen GPUs that isn't handled in the DMA code path. In
> evergreen_state.c within the me
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #52 from Alexandre Demers ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
>
> Good catch! I believe the attached patch should fix the issue.
I don't know for others,
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #51 from Alex Deucher ---
Created attachment 76544
--> https://bugs.freedesktop.org/attachment.cgi?id=76544&action=edit
set non_disp tiling bit for cayman
Good catch! I believe the attached patch should fix the issue.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #50 from Anthony Waters ---
I believe I have the source of the bug, it appears that there is a special case
for Caymen GPUs that isn't handled in the DMA code path. In evergreen_state.c
within the method evergreen_create_sampler_view
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #54 from Alexandre Demers ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
>
> Good catch! I believe the attached patch should fix the issue.
Since this bug is pretty
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #53 from Alexandre Demers ---
(In reply to comment #50)
> I believe I have the source of the bug, it appears that there is a special
> case for Caymen GPUs that isn't handled in the DMA code path. In
> evergreen_state.c within the me
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #52 from Alexandre Demers ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
>
> Good catch! I believe the attached patch should fix the issue.
I don't know for others,
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #51 from Alex Deucher ---
Created attachment 76544
--> https://bugs.freedesktop.org/attachment.cgi?id=76544&action=edit
set non_disp tiling bit for cayman
Good catch! I believe the attached patch should fix the issue.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #50 from Anthony Waters ---
I believe I have the source of the bug, it appears that there is a special case
for Caymen GPUs that isn't handled in the DMA code path. In evergreen_state.c
within the method evergreen_create_sampler_view
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #49 from Anthony Waters ---
Looked into it a bit more and it appears that when bpp is 16 there is a bad
texture, I'll see if I can figure it out more later on.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #48 from Anthony Waters ---
I looked into this a little bit and the issue appears to be within
evergreen_dma_copy_tile within evergreen_state.c. It looks like when bank_h is
0 it causes the texture to appear bad, but bank_h is allowe
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #47 from Alexandre Demers ---
So I played with libtxc (removed it in fact) and tested some demos again. For
those that were not completely relying on libtxc, I observed the following:
- textures not related to libtxc were displayed co
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #46 from Alexandre Demers ---
(In reply to comment #44)
> I think I have similar issue with Unigine Heaven 3.0 :
>
> http://people.freedesktop.org/~vlj/2.jpg
> http://people.freedesktop.org/~vlj/3.jpg
>
> A webgl demo that h
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #45 from Alex Deucher ---
(In reply to comment #44)
>
> It appeared with Kernel 3.8 too. Kernel 3.7.9 did have this.
The DMA rings are only available on 3.8 kernels.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #44 from vincent ---
I think I have similar issue with Unigine Heaven 3.0 :
http://people.freedesktop.org/~vlj/2.jpg
http://people.freedesktop.org/~vlj/3.jpg
A webgl demo that has the issue too is at http://www.findyourwayto
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #49 from Anthony Waters ---
Looked into it a bit more and it appears that when bpp is 16 there is a bad
texture, I'll see if I can figure it out more later on.
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #48 from Anthony Waters ---
I looked into this a little bit and the issue appears to be within
evergreen_dma_copy_tile within evergreen_state.c. It looks like when bank_h is
0 it causes the texture to appear bad, but bank_h is allowe
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #47 from Alexandre Demers ---
So I played with libtxc (removed it in fact) and tested some demos again. For
those that were not completely relying on libtxc, I observed the following:
- textures not related to libtxc were displayed co
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #46 from Alexandre Demers ---
(In reply to comment #44)
> I think I have similar issue with Unigine Heaven 3.0 :
>
> http://people.freedesktop.org/~vlj/2.jpg
> http://people.freedesktop.org/~vlj/3.jpg
>
> A webgl demo that h
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #45 from Alex Deucher ---
(In reply to comment #44)
>
> It appeared with Kernel 3.8 too. Kernel 3.7.9 did have this.
The DMA rings are only available on 3.8 kernels.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #44 from vincent ---
I think I have similar issue with Unigine Heaven 3.0 :
http://people.freedesktop.org/~vlj/2.jpg
http://people.freedesktop.org/~vlj/3.jpg
A webgl demo that has the issue too is at http://www.findyourwayto
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #43 from Alexandre Demers ---
Still getting this rendering problem with kernel 3.9.0-rc2 and today's mesa
code.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTM
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #43 from Alexandre Demers ---
Still getting this rendering problem with kernel 3.9.0-rc2 and today's mesa
code.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #42 from Alexandre Demers ---
(In reply to comment #41)
> Just as information: I just built 3.9-rc1 and the corruption is still
> present and looking exactly the same.
Same here, tested yesterday.
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #41 from Jakob Nixdorf ---
Just as information: I just built 3.9-rc1 and the corruption is still present
and looking exactly the same.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next par
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #42 from Alexandre Demers ---
(In reply to comment #41)
> Just as information: I just built 3.9-rc1 and the corruption is still
> present and looking exactly the same.
Same here, tested yesterday.
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #41 from Jakob Nixdorf ---
Just as information: I just built 3.9-rc1 and the corruption is still present
and looking exactly the same.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #40 from Alexandre Demers ---
(In reply to comment #39)
> I just started Trine 2 again and took a second picture.
> The corruption is definitely exactly the same.
I agree, same thing over here.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #39 from Jakob Nixdorf ---
I just started Trine 2 again and took a second picture.
The corruption is definitely exactly the same.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part ---
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #38 from Christian K?nig ---
(In reply to comment #37)
> Created attachment 75725 [details]
> Corruption in Trine 2
>
> Yes it looks like some regular 4x4 pattern. I made a screenshoot of the
> Trine 2 startscreen with the corruption
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #37 from Jakob Nixdorf ---
Created attachment 75725
--> https://bugs.freedesktop.org/attachment.cgi?id=75725&action=edit
Corruption in Trine 2
Yes it looks like some regular 4x4 pattern. I made a screenshoot of the Trine 2
startscr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #40 from Alexandre Demers ---
(In reply to comment #39)
> I just started Trine 2 again and took a second picture.
> The corruption is definitely exactly the same.
I agree, same thing over here.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #39 from Jakob Nixdorf ---
I just started Trine 2 again and took a second picture.
The corruption is definitely exactly the same.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #36 from Alexandre Demers ---
This commit seems to have fixed the "GPU fault detected" message
62329d77b8065b5fd41179d6013c8adf6d86cfc7
Author Brian Paul
Author date 2/25/13 8:00 PM
Parent svga: fix comment typos
Child r600g: synchr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #38 from Christian König ---
(In reply to comment #37)
> Created attachment 75725 [details]
> Corruption in Trine 2
>
> Yes it looks like some regular 4x4 pattern. I made a screenshoot of the
> Trine 2 startscreen with the corruption
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #37 from Jakob Nixdorf ---
Created attachment 75725
--> https://bugs.freedesktop.org/attachment.cgi?id=75725&action=edit
Corruption in Trine 2
Yes it looks like some regular 4x4 pattern. I made a screenshoot of the Trine 2
startscr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #36 from Alexandre Demers ---
This commit seems to have fixed the "GPU fault detected" message
62329d77b8065b5fd41179d6013c8adf6d86cfc7
Author Brian Paul
Author date 2/25/13 8:00 PM
Parent svga: fix comment typos
Child r600g: synchr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #35 from Jakob Nixdorf ---
Yes, it seems the dmesg errors are gone. I will try piglit later to confirm
this.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML a
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #34 from Alexandre Demers ---
(In reply to comment #32)
> Created attachment 75658 [details] [review]
> align dma commands to 8 dwords
>
> Does this patch help? You might also try it in combination with this patch:
> http://lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #35 from Jakob Nixdorf ---
Yes, it seems the dmesg errors are gone. I will try piglit later to confirm
this.
--
You are receiving this mail because:
You are the assignee for the bug.
___
d
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #33 from Jakob Nixdorf ---
No, I still get corruption in Trine 2 and on some CS:S textures with this patch
(also in combination with the one you linked).
Should I try all 5 patches in the set you linked or only 3/5 ?
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #32 from Alex Deucher ---
Created attachment 75658
--> https://bugs.freedesktop.org/attachment.cgi?id=75658&action=edit
align dma commands to 8 dwords
Does this patch help? You might also try it in combination with this patch:
htt
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #34 from Alexandre Demers ---
(In reply to comment #32)
> Created attachment 75658 [details] [review]
> align dma commands to 8 dwords
>
> Does this patch help? You might also try it in combination with this patch:
> http://lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #33 from Jakob Nixdorf ---
No, I still get corruption in Trine 2 and on some CS:S textures with this patch
(also in combination with the one you linked).
Should I try all 5 patches in the set you linked or only 3/5 ?
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #31 from Alexandre Demers ---
(In reply to comment #30)
> What do you mean by fixed, this bug or the one you linked?
> Because I still get the same corruptions in Trine 2 and some textures in
> CS:S with the newest git version of mesa
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #32 from Alex Deucher ---
Created attachment 75658
--> https://bugs.freedesktop.org/attachment.cgi?id=75658&action=edit
align dma commands to 8 dwords
Does this patch help? You might also try it in combination with this patch:
htt
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #30 from Jakob Nixdorf ---
What do you mean by fixed, this bug or the one you linked?
Because I still get the same corruptions in Trine 2 and some textures in CS:S
with the newest git version of mesa.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #31 from Alexandre Demers ---
(In reply to comment #30)
> What do you mean by fixed, this bug or the one you linked?
> Because I still get the same corruptions in Trine 2 and some textures in
> CS:S with the newest git version of mesa
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #29 from Alexandre Demers ---
I'm sure the rendering corruption comes from a wrongly set address for Cayman
(not shifted correctly at some point). It reminds me of bug 38173 and its
fixes.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #30 from Jakob Nixdorf ---
What do you mean by fixed, this bug or the one you linked?
Because I still get the same corruptions in Trine 2 and some textures in CS:S
with the newest git version of mesa.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #29 from Alexandre Demers ---
I'm sure the rendering corruption comes from a wrongly set address for Cayman
(not shifted correctly at some point). It reminds me of bug 38173 and its
fixes.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #28 from Jakob Nixdorf ---
The first test to trigger the dmesg output is:
spec/EXT_framebuffer_multisample/accuracy
but it also causes my system to freeze (ssh too), so I have no fail message.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #27 from Tom Stellard ---
(In reply to comment #26)
> Now that I'm back I have a question: is there any simple way to single-step
> through all tests in the r600.tests, or do I have to do it manually ?
When I want to identify which t
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #26 from Jakob Nixdorf ---
Now that I'm back I have a question: is there any simple way to single-step
through all tests in the r600.tests, or do I have to do it manually ?
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #28 from Jakob Nixdorf ---
The first test to trigger the dmesg output is:
spec/EXT_framebuffer_multisample/accuracy
but it also causes my system to freeze (ssh too), so I have no fail message.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #27 from Tom Stellard ---
(In reply to comment #26)
> Now that I'm back I have a question: is there any simple way to single-step
> through all tests in the r600.tests, or do I have to do it manually ?
When I want to identify which t
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #26 from Jakob Nixdorf ---
Now that I'm back I have a question: is there any simple way to single-step
through all tests in the r600.tests, or do I have to do it manually ?
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #25 from Alexandre Demers ---
For the info, I use a now-unavailable demo used to test features for Amnesia
(RendererFeattest). It is no where to be found anymore I think. It is a quick
and progressive test (starting with almost nothin
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #25 from Alexandre Demers ---
For the info, I use a now-unavailable demo used to test features for Amnesia
(RendererFeattest). It is no where to be found anymore I think. It is a quick
and progressive test (starting with almost nothin
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #24 from Jakob Nixdorf ---
(In reply to comment #23)
> Can you identify the a specific piglit test that triggers the fault messages
> and attach the fault messages it generates?
I won't be at my computer for awhile, but I will try as
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #23 from Alex Deucher ---
(In reply to comment #22)
> Ok, I managed to get the dmesg output using piglit and the r600.tests, so I
> think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
Can you identify the a speci
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #24 from Jakob Nixdorf ---
(In reply to comment #23)
> Can you identify the a specific piglit test that triggers the fault messages
> and attach the fault messages it generates?
I won't be at my computer for awhile, but I will try as
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #22 from Jakob Nixdorf ---
Ok, I managed to get the dmesg output using piglit and the r600.tests, so I
think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
But I think the commit I identified (e110c98cae0ceae47db6
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #23 from Alex Deucher ---
(In reply to comment #22)
> Ok, I managed to get the dmesg output using piglit and the r600.tests, so I
> think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
Can you identify the a speci
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #21 from Jakob Nixdorf ---
(In reply to comment #20)
> I ended up with a different commit than yours when bisecting:
> 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
> commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #20 from Alexandre Demers ---
(In reply to comment #18)
> Ok, just finished bisecting, this is the first commit with the dmesg errors:
>
> e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit
> commit e110c98cae0ceae47db6
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #22 from Jakob Nixdorf ---
Ok, I managed to get the dmesg output using piglit and the r600.tests, so I
think this confirms 325422c49449acdd8df1eb2ca8ed81f7696c38cc as culprit.
But I think the commit I identified (e110c98cae0ceae47db6
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #21 from Jakob Nixdorf ---
(In reply to comment #20)
> I ended up with a different commit than yours when bisecting:
> 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit
> commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #19 from Alexandre Demers ---
(In reply to comment #18)
> Ok, just finished bisecting, this is the first commit with the dmesg errors:
>
> e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit
> commit e110c98cae0ceae47db6
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #18 from Jakob Nixdorf ---
Ok, just finished bisecting, this is the first commit with the dmesg errors:
e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit
commit e110c98cae0ceae47db6cf26c08707505ce92479
Author: Alex Deu
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #20 from Alexandre Demers ---
(In reply to comment #18)
> Ok, just finished bisecting, this is the first commit with the dmesg errors:
>
> e110c98cae0ceae47db6cf26c08707505ce92479 is the first bad commit
> commit e110c98cae0ceae47db6
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #17 from Alex Deucher ---
(In reply to comment #15)
> Yes, I will. Should I begin by looking on the kernel's side or on mesa's
> side?
It's most likely a mesa issue.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #16 from Jakob Nixdorf ---
I am currently bisecting mesa to see where the dmesg output starts.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was
1 - 100 of 126 matches
Mail list logo
