[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #46 from udo --- Booted 3.7.8. -- 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 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #25 from Alex Deucher --- (In reply to comment #24) > Any idea regarding the reason for this behavior? > > P.S. I noted that glxgears renders OK on fullscreen with fglrx->radeon. In > window it's wrong. Unfortunately, I didn't see anything obvious in the dump. Can you try my drm-next branch? http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10 Does that help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/c0308e28/attachment.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #33 from Alex Deucher --- (In reply to comment #32) > Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection > in #28. > > So the bad changeset is > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=35840ab189595b817fa8b1a1df8cc92474a7c38d > > I read that code (out of context: I'm not familiar with Xorg code). It kind > of looked as if things with obvious allocation potential were followed by > asserts to check that the allocation worked. So why are we observing SIGBUS > rather than assertion errors? If allocation failure is possible, even > assertion failure seems harsh (but at least more diagnostic). As per comment 29, the MSAA surface is too big to be mapped by the CPU (the CPU's window into VRAM is only 256 MB). The allocation is successful, but the CPU is not able to map the buffer due to the limited window. You get a sigbus because the mapping fails and the CPU tries to access an address beyond the PCI aperture where vram is mapped. The solution is to either disable MSAA or as per comment 29, use the GPU to initialize the CMASK/HTILE buffers rather than using the CPU. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/14a751ca/attachment.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #35 from D. Hugh Redelmeier --- I finally am trying to set the GART size, as per Alex's comment #12. Without setting it, Xorg0.log reports: [15.054] (II) RADEON(0): mem size init: gart size :1fdef000 vram size: s:2000 visible:1f02 The default GART size is 512MiB, You'd think that would be a good match for the 512MiB video RAM on my card. This output shows that the GART size is reduced by a somewhat odd number (13^2 * 2^12). When I set radeon.gartsize=1024 on the kernel line, Xorg.0.log reports: [14.842] (II) RADEON(0): mem size init: gart size :3fdef000 vram size: s:2000 visible:1f02 Again, the GART size is reduced by the same amount. Wait: according to http://dri.freedesktop.org/wiki/GART/ the GART seems to enable the video card to access the computer's memory, not the other way around. So I don't see how this is relevant: we're getting a crash in a CPU instruction that is trying to access the video card's memory. -- 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 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #32 from D. Hugh Redelmeier --- Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection in #28. So the bad changeset is http://cgit.freedesktop.org/mesa/mesa/commit/?id=35840ab189595b817fa8b1a1df8cc92474a7c38d I read that code (out of context: I'm not familiar with Xorg code). It kind of looked as if things with obvious allocation potential were followed by asserts to check that the allocation worked. So why are we observing SIGBUS rather than assertion errors? If allocation failure is possible, even assertion failure seems harsh (but at least more diagnostic). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/8e7e3d81/attachment.html>
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #24 from Hristo Venev --- Any idea regarding the reason for this behavior? P.S. I noted that glxgears renders OK on fullscreen with fglrx->radeon. In window it's wrong. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/8cbce94e/attachment.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #34 from D. Hugh Redelmeier --- Thanks, Alex, for the clear restatement. Naively, I think of two C/UNIX conventions. For allocations that can either succeed or fail, typically the result is a pointer which is NULL for failure -- eg. malloc(3)). For allocations that can partially succeed, the result is the amount successfully processed (think write(2) which returns the length actually transferred). It seems to me that for allocating address space in the VRAM window (aperture?), success can partial, and anything that deals with that window needs to be aware that accessing some object may require piecewise operations, punctuated by adjustment of the mapping. In other words, this case doesn't sound pathological; it should be handled as a normal case. I'm not saying that comment #29 is wrong. I'm saying that the existing code ought to have been written to handle this case. Clearly one solution is to replace the code as suggested. But fixing the code ought to be feasible too. Are there other lurking bugs where code assumes addressability? I reiterate: I'm not knowledgeable about modern video architectures or about X server architectures. Footnote: Why do I think that VRAM windows cannot always map the whole VRAM? Because video cards now routinely have gigabytes of VRAM and 32-bit address spaces for x86 machines cannot spare enough to allocate for that much VRAM (ignoring PAE). -- 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 63748] GPU Lockup playing urban terror
https://bugs.freedesktop.org/show_bug.cgi?id=63748 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|9.0 Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #1 from Alex Deucher --- Can you bisect mesa to find out what broke it? Also please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/3c0e8030/attachment.html>
[Bug 53111] vgaswitcheroo not working anymore
https://bugzilla.kernel.org/show_bug.cgi?id=53111 Daniel Vetter changed: What|Removed |Added CC||fedevx at yahoo.com --- Comment #12 from Daniel Vetter 2013-04-20 18:21:28 --- *** Bug 55311 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 63762] New: Team fortress 2 intermittently freezes
https://bugs.freedesktop.org/show_bug.cgi?id=63762 Priority: medium Bug ID: 63762 Assignee: dri-devel@lists.freedesktop.org Summary: Team fortress 2 intermittently freezes Severity: normal Classification: Unclassified OS: All Reporter: silpa...@hotmail.com Hardware: Other Status: NEW Version: 9.0 Component: Drivers/Gallium/r600 Product: Mesa Hi all, I have upgraded to Ubuntu 12.10, this is my current conf: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL version string: 2.1 Mesa 9.0.3 OpenGL shading language version string: 1.30 I can play with no problem Team fortress 2 with oficial steam client, but the game has intermittently freezes each 3 seconds (aprox). I have tried to modify the configuration in the game, FS, window, but same results. Maybe Unity was the problem, so I have change to gnome default with no sucess conky is not the problem, so I guess is something wrong in the video driver. system specs: amd athlon x4 640 @ 3ghz ati hd4670 512mb ddr3 4gb ram There is no error message or something during game, just the freezes that make the game unplayable. I have tried to run it on console but I cant because I dont know where steam download the game and the instruction "steam steam://rungameid/440" start the game but with no debug info. any further question just let me know. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #45 from udo --- drm 2.4.44, git for the rest. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/1902bc5d/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #44 from Alexandre Demers --- (In reply to comment #43) > 3.6.11 was OK but also maybe is kinda 'old'. Then try a 3.7 kernel if possible to see if a first bug was introduced there or if it all happened in the 3.8 branch. If I remember correctly, there were some changes about VM in 3.7 and some others about DMA in 3.8. Doing so should allow us to work on one bug/change at a time. Are you using latest mesa, drm and ddx? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/c6659b7d/attachment.html>
[PATCH] drm/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 01:28:53PM +0200, Daniel Vetter wrote: > On Sat, Apr 20, 2013 at 12:11 PM, Chris Wilson > wrote: > > On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote: > >> In > >> > >> commit 9e8944ab564f2e3dde90a518cd32048c58918608 > >> Author: Chris Wilson > >> Date: Thu Nov 15 11:32:17 2012 + > >> > >> drm: Introduce an iterator over holes in the drm_mm range manager > >> > >> helpers and iterators for hole handling have been introduced with some > >> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper > >> which unconditionally tried to compute the size of the very first > >> hole. > >> [snip] > > Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead. > > I've figured I could make the condition more symmetric with the one in > the loop, so that both check ->hole_follows. Your change log didn't explain your intentions to refactor the code, only to avoid the extra BUG_ON... -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 --- Comment #4 from Johannes Hirte --- Also with v2 the same error. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/4b4004be/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #43 from udo --- 3.6.11 was OK but also maybe is kinda 'old'. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/7a5a8580/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #42 from Alexandre Demers --- (In reply to comment #40) > in /etc/environment I have R600_DEBUG=nodma ever since discovering that > setting, i.e.: also now the R6))_DEBUG is set to nodma. > > I did not apply any of your patches over the 3.9.0-rc7 kernel. Your log looks to the one in bug 58354, which is also related to DMA, or bug 59089, which is related to htile/VM. The best thing would be to bisect the kernel between a good known version and the first bad one. Do you have a previous kernel version that was working OK as a good reference? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/ad9ff828/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #41 from Alexandre Demers --- (In reply to comment #40) > in /etc/environment I have R600_DEBUG=nodma ever since discovering that > setting, i.e.: also now the R6))_DEBUG is set to nodma. > > I did not apply any of your patches over the 3.9.0-rc7 kernel. If I was you, I would test without R600_DEBUG=nodma to see if there is any difference between kernels 3.8 and 3.9. I would also try patching 3.9-rc7 with attachment 77608 or attachment. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/a4b58daa/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #40 from udo --- in /etc/environment I have R600_DEBUG=nodma ever since discovering that setting, i.e.: also now the R6))_DEBUG is set to nodma. I did not apply any of your patches over the 3.9.0-rc7 kernel. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/7e03e9a0/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #39 from Alexandre Demers --- (In reply to comment #38) > 3.9.0-rc7 here. > > Just saw this: > > [ 67.568697] Bluetooth: BNEP socket layer initialized > [ 2144.364903] radeon :00:01.0: GPU fault detected: 147 0x0d422602 > [ 2144.364908] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0xD6D4 > [ 2144.364911] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x02026002 > [ 2144.364913] radeon :00:01.0: GPU fault detected: 147 0x0d422602 > [ 2144.364915] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 2144.364918] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x Are you getting the same result with and without R600_DEBUG=nodma (as per bug 62997)? Also, did you try applying patches on top of 3.9-rc7? Just getting some info here to see if anything is making a difference. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/c968d9f8/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #38 from udo --- 3.9.0-rc7 here. Just saw this: [ 67.568697] Bluetooth: BNEP socket layer initialized [ 2144.364903] radeon :00:01.0: GPU fault detected: 147 0x0d422602 [ 2144.364908] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0xD6D4 [ 2144.364911] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02026002 [ 2144.364913] radeon :00:01.0: GPU fault detected: 147 0x0d422602 [ 2144.364915] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 2144.364918] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/a3cd7b18/attachment-0001.html>
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #25 from Alex Deucher --- (In reply to comment #24) > Any idea regarding the reason for this behavior? > > P.S. I noted that glxgears renders OK on fullscreen with fglrx->radeon. In > window it's wrong. Unfortunately, I didn't see anything obvious in the dump. Can you try my drm-next branch? http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10 Does that help? -- 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 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #33 from Alex Deucher --- (In reply to comment #32) > Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection > in #28. > > So the bad changeset is > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=35840ab189595b817fa8b1a1df8cc92474a7c38d > > I read that code (out of context: I'm not familiar with Xorg code). It kind > of looked as if things with obvious allocation potential were followed by > asserts to check that the allocation worked. So why are we observing SIGBUS > rather than assertion errors? If allocation failure is possible, even > assertion failure seems harsh (but at least more diagnostic). As per comment 29, the MSAA surface is too big to be mapped by the CPU (the CPU's window into VRAM is only 256 MB). The allocation is successful, but the CPU is not able to map the buffer due to the limited window. You get a sigbus because the mapping fails and the CPU tries to access an address beyond the PCI aperture where vram is mapped. The solution is to either disable MSAA or as per comment 29, use the GPU to initialize the CMASK/HTILE buffers rather than using the CPU. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #37 from Alexandre Demers --- (In reply to comment #36) > Alex, despite having your 2nd patch in, the box just crashed and rebooted. > I'll revert to your first patch to see if that one still helps. By reading bug 62997 you've reported, you may be hitting more than one bug. I had to report a couple of bugs myself about VM and DMA for Cayman. Could you try kernel 3.9-rc7? I know a couple of patches went in there that could help you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/6b7ce19a/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #36 from udo --- Alex, despite having your 2nd patch in, the box just crashed and rebooted. I'll revert to your first patch to see if that one still helps. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/348fafe5/attachment.html>
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #32 from D. Hugh Redelmeier --- Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection in #28. So the bad changeset is http://cgit.freedesktop.org/mesa/mesa/commit/?id=35840ab189595b817fa8b1a1df8cc92474a7c38d I read that code (out of context: I'm not familiar with Xorg code). It kind of looked as if things with obvious allocation potential were followed by asserts to check that the allocation worked. So why are we observing SIGBUS rather than assertion errors? If allocation failure is possible, even assertion failure seems harsh (but at least more diagnostic). -- 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/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 12:11 PM, Chris Wilson
wrote:
> On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote:
>> In
>>
>> commit 9e8944ab564f2e3dde90a518cd32048c58918608
>> Author: Chris Wilson
>> Date: Thu Nov 15 11:32:17 2012 +
>>
>> drm: Introduce an iterator over holes in the drm_mm range manager
>>
>> helpers and iterators for hole handling have been introduced with some
>> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
>> which unconditionally tried to compute the size of the very first
>> hole.
>>
>> Reported-by: Christopher Harvey
>> Cc: Christopher Harvey
>> Cc: Dave Airlie
>> Cc: Chris Wilson
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_mm.c | 11 ++-
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>> index db1e2d6..a0ba3a1 100644
>> --- a/drivers/gpu/drm/drm_mm.c
>> +++ b/drivers/gpu/drm/drm_mm.c
>> @@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct
>> drm_mm *mm)
>> {
>> struct drm_mm_node *entry;
>> unsigned long total_used = 0, total_free = 0, total = 0;
>> - unsigned long hole_start, hole_end, hole_size;
>> + unsigned long hole_start, hole_end, hole_size = 0;
>>
>> - hole_start = drm_mm_hole_node_start(&mm->head_node);
>> - hole_end = drm_mm_hole_node_end(&mm->head_node);
>
> Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead.
I've figured I could make the condition more symmetric with the one in
the loop, so that both check ->hole_follows.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Christian K?nig changed: What|Removed |Added Attachment #78243|0 |1 is obsolete|| --- Comment #3 from Christian K?nig --- Created attachment 78270 --> https://bugs.freedesktop.org/attachment.cgi?id=78270&action=edit Possible fix v2 Please try this one instead. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/9d81240f/attachment-0001.html>
[Bug 56891] TRAP_VFETCH FAULT in nouveau during highload 3D
https://bugzilla.kernel.org/show_bug.cgi?id=56891 George Shuklin changed: What|Removed |Added Summary|TRAP_VFETCH FAULT |TRAP_VFETCH FAULT in ||nouveau during highload 3D -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 56891] New: TRAP_VFETCH FAULT
https://bugzilla.kernel.org/show_bug.cgi?id=56891 Summary: TRAP_VFETCH FAULT Product: Drivers Version: 2.5 Kernel Version: 3.9-rc7 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: george.shuklin at gmail.com Regression: No nouveau cause unexpected delays and periodic freeze (<0.2s) when rendering complicated 3D scene. Here dmesg during lags (repeat many times): [46444.498018] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46444.498028] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46444.498031] nouveau E[ PGRAPH][:01:00.0] TRAP [46444.498037] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x3f80 [46444.498045] nouveau E[ PFB][:01:00.0] trapped read at 0x00 on channel 0x0001f8eb [el.x86.linux.bi[7941]] PGRAPH/VFETCH/00 reason: PT_NOT_PRESENT [46444.498070] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46444.498082] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46444.498085] nouveau E[ PGRAPH][:01:00.0] TRAP [46444.498092] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x40028f58 [46448.541527] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46448.541537] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46448.541540] nouveau E[ PGRAPH][:01:00.0] TRAP [46448.541545] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x3f80 [46448.541557] nouveau E[ PFB][:01:00.0] trapped read at 0x00 on channel 0x0001f8eb [el.x86.linux.bi[7941]] PGRAPH/VFETCH/00 reason: PT_NOT_PRESENT [46448.541590] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46448.541601] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46448.541605] nouveau E[ PGRAPH][:01:00.0] TRAP [46448.541612] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x But that problem is same with many 3D applications. Was seen at least from 3.2 to 3.9-rc7. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 60879] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #24 from Hristo Venev --- Any idea regarding the reason for this behavior? P.S. I noted that glxgears renders OK on fullscreen with fglrx->radeon. In window it's wrong. -- 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/mm: fix dump table BUG
In
commit 9e8944ab564f2e3dde90a518cd32048c58918608
Author: Chris Wilson
Date: Thu Nov 15 11:32:17 2012 +
drm: Introduce an iterator over holes in the drm_mm range manager
helpers and iterators for hole handling have been introduced with some
debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
which unconditionally tried to compute the size of the very first
hole.
Reported-by: Christopher Harvey
Cc: Christopher Harvey
Cc: Dave Airlie
Cc: Chris Wilson
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index db1e2d6..a0ba3a1 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct drm_mm
*mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, total = 0;
- unsigned long hole_start, hole_end, hole_size;
+ unsigned long hole_start, hole_end, hole_size = 0;
- hole_start = drm_mm_hole_node_start(&mm->head_node);
- hole_end = drm_mm_hole_node_end(&mm->head_node);
- hole_size = hole_end - hole_start;
- if (hole_size)
+ if (mm->head_node.hole_follows) {
+ hole_start = drm_mm_hole_node_start(&mm->head_node);
+ hole_end = drm_mm_hole_node_end(&mm->head_node);
+ hole_size = hole_end - hole_start;
seq_printf(m, "0x%08lx-0x%08lx: 0x%08lx: free\n",
hole_start, hole_end, hole_size);
+ }
total_free += hole_size;
drm_mm_for_each_node(entry, mm) {
--
1.7.10.4
[Bug 63748] GPU Lockup playing urban terror
https://bugs.freedesktop.org/show_bug.cgi?id=63748 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|9.0 Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #1 from Alex Deucher --- Can you bisect mesa to find out what broke it? Also please attach your xorg log and dmesg output. -- 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 53111] vgaswitcheroo not working anymore
https://bugzilla.kernel.org/show_bug.cgi?id=53111 Daniel Vetter changed: What|Removed |Added CC||fed...@yahoo.com --- Comment #12 from Daniel Vetter 2013-04-20 18:21:28 --- *** Bug 55311 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote:
> In
>
> commit 9e8944ab564f2e3dde90a518cd32048c58918608
> Author: Chris Wilson
> Date: Thu Nov 15 11:32:17 2012 +
>
> drm: Introduce an iterator over holes in the drm_mm range manager
>
> helpers and iterators for hole handling have been introduced with some
> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
> which unconditionally tried to compute the size of the very first
> hole.
>
> Reported-by: Christopher Harvey
> Cc: Christopher Harvey
> Cc: Dave Airlie
> Cc: Chris Wilson
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mm.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index db1e2d6..a0ba3a1 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct drm_mm
> *mm)
> {
> struct drm_mm_node *entry;
> unsigned long total_used = 0, total_free = 0, total = 0;
> - unsigned long hole_start, hole_end, hole_size;
> + unsigned long hole_start, hole_end, hole_size = 0;
>
> - hole_start = drm_mm_hole_node_start(&mm->head_node);
> - hole_end = drm_mm_hole_node_end(&mm->head_node);
Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #45 from udo --- drm 2.4.44, git for the rest. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #44 from Alexandre Demers --- (In reply to comment #43) > 3.6.11 was OK but also maybe is kinda 'old'. Then try a 3.7 kernel if possible to see if a first bug was introduced there or if it all happened in the 3.8 branch. If I remember correctly, there were some changes about VM in 3.7 and some others about DMA in 3.8. Doing so should allow us to work on one bug/change at a time. Are you using latest mesa, drm and ddx? -- 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 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 --- Comment #4 from Johannes Hirte --- Also with v2 the same error. -- 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 63632] mesa +r600 llvm = segfault
https://bugs.freedesktop.org/show_bug.cgi?id=63632 --- Comment #3 from Andy Furniss --- (In reply to comment #2) > I can't reproduce this with LLVM r179895 and Mesa > 12eab7cc564a6928197f9b87ded9e368e56976f0 > > Have you done full rebuilds of both projects? Yes, I always do make [dist]clean and git clean -dfx. I have just deleted both trees and re-cloned to be sure, but the segfault is still there. When I was on my working commits moving either llvm or mesa to head while keeping the other on "working" produced the segfault (which is why I didn't do a proper bisect). I always clean and rebuild mesa after llvm has changed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/61341c42/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #43 from udo --- 3.6.11 was OK but also maybe is kinda 'old'. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #42 from Alexandre Demers --- (In reply to comment #40) > in /etc/environment I have R600_DEBUG=nodma ever since discovering that > setting, i.e.: also now the R6))_DEBUG is set to nodma. > > I did not apply any of your patches over the 3.9.0-rc7 kernel. Your log looks to the one in bug 58354, which is also related to DMA, or bug 59089, which is related to htile/VM. The best thing would be to bisect the kernel between a good known version and the first bad one. Do you have a previous kernel version that was working OK as a good reference? -- 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: [PATCH 3/3] drm/exynos: Add device tree support for fimc ipp driver
2013/4/17 Sylwester Nawrocki
> This patch adds OF initialization support for the FIMC driver.
> The binding documentation can be found at Documentation/devicetree/
> bindings/media/samsung-fimc.txt.
>
> The syscon regmap interface is used to serialize access to the
> shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
> FIMC drivers. The DRM driver uses this interface for setting up
> the FIFO data link between FIMD and FIMC IP blocks, while the V4L2
> one for setting up a data link between the camera ISP and FIMC for
> camera capture. The CAMBLK registers are not accessed any more
> through a statically mapped IO. Synchronized access to these
> registers is required for simultaneous operation of the camera
> ISP and the DRM IPP on Exynos4x12.
>
> Exynos4 is going to be a dt-only platform since 3.10, thus the
> driver data and driver_ids static data structures are removed.
>
> Camera input signal polarities are not currently parsed from the
> device tree.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/Kconfig |2 +-
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 101
> +++---
> drivers/gpu/drm/exynos/regs-fimc.h |7 +--
> 3 files changed, 53 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig
> b/drivers/gpu/drm/exynos/Kconfig
> index 406f32a..5c4be2a 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -56,7 +56,7 @@ config DRM_EXYNOS_IPP
>
> config DRM_EXYNOS_FIMC
> bool "Exynos DRM FIMC"
> - depends on DRM_EXYNOS_IPP
> + depends on DRM_EXYNOS_IPP && MFD_SYSCON && OF
> help
> Choose this option if you want to use Exynos FIMC for DRM.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 9bea585..f25801e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -12,11 +12,12 @@
> *
> */
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -140,15 +141,6 @@ struct fimc_capability {
> };
>
> /*
> - * A structure of fimc driver data.
> - *
> - * @parent_clk: name of parent clock.
> - */
> -struct fimc_driverdata {
> - char*parent_clk;
> -};
> -
> -/*
> * A structure of fimc context.
> *
> * @ippdrv: prepare initialization using ippdrv.
> @@ -158,6 +150,7 @@ struct fimc_driverdata {
> * @lock: locking of operations.
> * @clocks: fimc clocks.
> * @clk_frequency: LCLK clock frequency.
> + * @sysreg: handle to SYSREG block regmap.
> * @sc: scaler infomations.
> * @pol: porarity of writeback.
> * @id: fimc id.
> @@ -172,8 +165,8 @@ struct fimc_context {
> struct mutexlock;
> struct clk *clocks[FIMC_CLKS_MAX];
> u32 clk_frequency;
> + struct regmap *sysreg;
> struct fimc_scaler sc;
> - struct fimc_driverdata *ddata;
> struct exynos_drm_ipp_pol pol;
> int id;
> int irq;
> @@ -217,17 +210,13 @@ static void fimc_sw_reset(struct fimc_context *ctx)
> fimc_write(0x0, EXYNOS_CIFCNTSEQ);
> }
>
> -static void fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
> +static int fimc_set_camblk_fimd0_wb(struct fimc_context *ctx)
> {
> - u32 camblk_cfg;
> -
> DRM_DEBUG_KMS("%s\n", __func__);
>
> - camblk_cfg = readl(SYSREG_CAMERA_BLK);
> - camblk_cfg &= ~(SYSREG_FIMD0WB_DEST_MASK);
> - camblk_cfg |= ctx->id << (SYSREG_FIMD0WB_DEST_SHIFT);
> -
> - writel(camblk_cfg, SYSREG_CAMERA_BLK);
> + return regmap_update_bits(ctx->sysreg, SYSREG_CAMERA_BLK,
> + SYSREG_FIMD0WB_DEST_MASK,
> + ctx->id << SYSREG_FIMD0WB_DEST_SHIFT);
> }
>
> static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
> @@ -1628,7 +1617,9 @@ static int fimc_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd)
> fimc_handle_lastend(ctx, true);
>
> /* setup FIMD */
> - fimc_set_camblk_fimd0_wb(ctx);
> + ret = fimc_set_camblk_fimd0_wb(ctx);
> + if (ret < 0)
> + return ret;
>
> set_wb.enable = 1;
> set_wb.refresh = property->refresh_rate;
> @@ -1784,26 +1775,50 @@ e_clk_free:
> return ret;
> }
>
> +static int fimc_parse_dt(struct fimc_context *ctx)
> +{
> + struct device_node *node = ctx->dev->of_node;
> +
> + if (!of_property_read_bool(node, "samsung,lcd-wb"))
> + return -ENODEV;
>
Isn't the above property really needed? This makes the use of write-back
feature to be forced. I think some machines might not need this feature so
their dts files have no that property.
So in this case, drm fimc driver probing will be
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #41 from Alexandre Demers --- (In reply to comment #40) > in /etc/environment I have R600_DEBUG=nodma ever since discovering that > setting, i.e.: also now the R6))_DEBUG is set to nodma. > > I did not apply any of your patches over the 3.9.0-rc7 kernel. If I was you, I would test without R600_DEBUG=nodma to see if there is any difference between kernels 3.8 and 3.9. I would also try patching 3.9-rc7 with attachment 77608 or attachment. -- 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: [PATCH v2 0/3] drm/exynos: Add device tree support for IPP driver
Hi Sylwester,
DRM FIMC driver could be more cleaned up with this patch series. And your
third patch
And just minor issue. The second patch has build warnings like below,
WARNING: static const char * array should probably be static const char *
const
#111: FILE: drivers/gpu/drm/exynos/exynos_drm_fimc.c:89:
+static const char * fimc_clock_names[] = {
ERROR: "foo * bar" should be "foo *bar"
#111: FILE: drivers/gpu/drm/exynos/exynos_drm_fimc.c:89:
This is a minor issue so I can fix them. And as you already know, now drm
fimc driver should be more cleaned up. Your patch set looks good to me but
I'd like to take more opinions from others.
And you can find my comments at the third patch.
Thanks,
Inki Dae
2013/4/17 Sylwester Nawrocki
> Hi Inki,
>
> This small patch series adds device tree support for the DRM FIMC driver.
> The binding documentation can be found in -next at
> Documentation/devicetree/
> bindings/media/samsung-fimc.txt.
> It will make the driver dependent on OF. This patch series is needed in
> 3.10 to ensure simultaneous operation of the DRM FIMC and the camera ISP
> on Exynos4x12.
>
> Changes since v1:
> - removed devm_kfree() that got erroneously re-added in patch 2/3 during
>rebase.
>
> Thanks,
> Sylwester
>
> Sylwester Nawrocki (3):
> drm/exynos: Remove redundant devm_kfree()
> drm/exynos: Rework fimc clocks handling
> drm/exynos: Add device tree support for fimc ipp driver
>
> drivers/gpu/drm/exynos/Kconfig |2 +-
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 264
> --
> drivers/gpu/drm/exynos/regs-fimc.h |7 +-
> 3 files changed, 147 insertions(+), 126 deletions(-)
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #40 from udo --- in /etc/environment I have R600_DEBUG=nodma ever since discovering that setting, i.e.: also now the R6))_DEBUG is set to nodma. I did not apply any of your patches over the 3.9.0-rc7 kernel. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #39 from Alexandre Demers --- (In reply to comment #38) > 3.9.0-rc7 here. > > Just saw this: > > [ 67.568697] Bluetooth: BNEP socket layer initialized > [ 2144.364903] radeon :00:01.0: GPU fault detected: 147 0x0d422602 > [ 2144.364908] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0xD6D4 > [ 2144.364911] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x02026002 > [ 2144.364913] radeon :00:01.0: GPU fault detected: 147 0x0d422602 > [ 2144.364915] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x > [ 2144.364918] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x Are you getting the same result with and without R600_DEBUG=nodma (as per bug 62997)? Also, did you try applying patches on top of 3.9-rc7? Just getting some info here to see if anything is making a difference. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #38 from udo --- 3.9.0-rc7 here. Just saw this: [ 67.568697] Bluetooth: BNEP socket layer initialized [ 2144.364903] radeon :00:01.0: GPU fault detected: 147 0x0d422602 [ 2144.364908] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0xD6D4 [ 2144.364911] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02026002 [ 2144.364913] radeon :00:01.0: GPU fault detected: 147 0x0d422602 [ 2144.364915] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 2144.364918] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x -- 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: [PATCH] drm/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 01:28:53PM +0200, Daniel Vetter wrote: > On Sat, Apr 20, 2013 at 12:11 PM, Chris Wilson > wrote: > > On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote: > >> In > >> > >> commit 9e8944ab564f2e3dde90a518cd32048c58918608 > >> Author: Chris Wilson > >> Date: Thu Nov 15 11:32:17 2012 + > >> > >> drm: Introduce an iterator over holes in the drm_mm range manager > >> > >> helpers and iterators for hole handling have been introduced with some > >> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper > >> which unconditionally tried to compute the size of the very first > >> hole. > >> [snip] > > Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead. > > I've figured I could make the condition more symmetric with the one in > the loop, so that both check ->hole_follows. Your change log didn't explain your intentions to refactor the code, only to avoid the extra BUG_ON... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
2013/4/19 Vikas Sajjan
> Hi Inki Dae and Viresh,
>
> On 8 April 2013 16:41, Viresh Kumar wrote:
>
>> On 8 April 2013 16:37, Vikas Sajjan wrote:
>> > While migrating to common clock framework (CCF), I found that the FIMD
>> clocks
>> > were pulled down by the CCF.
>> > If CCF finds any clock(s) which has NOT been claimed by any of the
>> > drivers, then such clock(s) are PULLed low by CCF.
>> >
>> > Calling clk_prepare() for FIMD clocks fixes the issue.
>> >
>> > This patch also replaces clk_disable() with clk_unprepare() during
>> exit, since
>> > clk_prepare() is called in fimd_probe().
>>
>> I asked you about fixing your commit log too.. It still looks incorrect
>> to me.
>>
>> This patch doesn't have anything to do with CCF pulling clocks down, but
>> calling clk_prepare() before clk_enable() is must now.. that's it..
>> nothing more.
>>
>> what I noticed is the fimd_clock() which in turn calls clk_enable(),
> will only be called if the RUNTIME PM is enabled. So the current patch
> breaks and display won't appear, if we don't enable the RUNTIME PM. So it
> becomes mandatory to enable RUNTIME PM, to FIMD to work.
>
Right, this is our intention.
I am NOT sure whether it is a good idea make FIMD work if and only if
> RUMTIME PM is enabled.
>
Actually, fimd driver had used not only runtime pm interface but also
clk_enable() at fimd_probe(). But this had induced the reference count pair
issue to clock. The issue was that the clock takes two references with
runtime pm. One is by clk_enable and another is by pm_runtime_get_sync().
So we are forcing only using runtime pm interface.
> I guess Mr. Inki Dae can throw more light on this.
> Or else make it like the earlier V1 version where clk_prepare_enable() was
> called in fimd_probe() itself.
>
> > Signed-off-by: Vikas Sajjan
>> > ---
>> > Changes since v3:
>> > - added clk_prepare() in fimd_probe() and clk_unprepare() in
>> fimd_remove()
>> > as suggested by Viresh Kumar
>> > Changes since v2:
>> > - moved clk_prepare_enable() and clk_disable_unprepare() from
>> > fimd_probe() to fimd_clock() as suggested by Inki Dae <
>> inki@samsung.com>
>> > Changes since v1:
>> > - added error checking for clk_prepare_enable() and also
>> replaced
>> > clk_disable() with clk_disable_unprepare() during exit.
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
>> > 1 file changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > index 9537761..aa22370 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device *pdev)
>> > return ret;
>> > }
>> >
>> > + ret = clk_prepare(ctx->bus_clk);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + ret = clk_prepare(ctx->lcd_clk);
>> > + if (ret < 0) {
>> > + clk_unprepare(ctx->bus_clk);
>> > + return ret;
>> > + }
>> > +
>> > ctx->vidcon0 = pdata->vidcon0;
>> > ctx->vidcon1 = pdata->vidcon1;
>> > ctx->default_win = pdata->default_win;
>> > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device *pdev)
>> > if (ctx->suspended)
>> > goto out;
>> >
>> > - clk_disable(ctx->lcd_clk);
>> > - clk_disable(ctx->bus_clk);
>> > + clk_unprepare(ctx->lcd_clk);
>> > + clk_unprepare(ctx->bus_clk);
>>
>> This looks wrong again.. You still need to call clk_disable() to make
>> clk enabled
>> count zero...
>>
>
> Viresh had an suggestion, that the original code had a call
> clk_disable() in fimd_remove(), which is really NOT required as there is NO
> clk_enable() in fimd_probe() and we can right away delete clk_disable()
> from fimd_remove().
>
> And also i think i should be breaking this patch into 2, 1st patch for
> adding clk_prepare_enable() ( if we want remove dependency on RUNTIME PM )
> in fimd_probe() for CCF migration another one for idea of replacing
> clk_disable() with adding clk_disable_unprepare() (since we will be adding
> clk_prepare_enable() in probe ) in fimd_remove() .
>
> Mr. Inki Dae any thoughts on this.
>
>
Sorry for being late. I think clk_prepare/unprepare are nothing to do yet
in case of Exynos but those might be used for in the future so your patch
looks good to me as is.
Applied. :)
Thanks,
Inki Dae
> --
> Thanks and Regards
> Vikas Sajjan
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #35 from udo --- Alex, despite having your 2nd patch in, I found: Apr 17 16:26:07 o2 kernel: [91224.372170] radeon :00:01.0: GPU fault detected: 146 0x0594260c Apr 17 16:26:07 o2 kernel: [91224.372175] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0A59 Apr 17 16:26:07 o2 kernel: [91224.372178] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0402600C Apr 17 16:26:07 o2 kernel: [91224.372181] radeon :00:01.0: GPU fault detected: 146 0x0594260c Apr 17 16:26:07 o2 kernel: [91224.372184] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 17 16:26:07 o2 kernel: [91224.372187] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x Apr 19 17:19:08 o2 kernel: [132471.330610] radeon :00:01.0: GPU fault detected: 147 0x06d37002 Apr 19 17:19:08 o2 kernel: [132471.330614] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x316D Apr 19 17:19:08 o2 kernel: [132471.330617] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03070002 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/b4de59f6/attachment-0001.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #37 from Alexandre Demers --- (In reply to comment #36) > Alex, despite having your 2nd patch in, the box just crashed and rebooted. > I'll revert to your first patch to see if that one still helps. By reading bug 62997 you've reported, you may be hitting more than one bug. I had to report a couple of bugs myself about VM and DMA for Cayman. Could you try kernel 3.9-rc7? I know a couple of patches went in there that could help you. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #36 from udo --- Alex, despite having your 2nd patch in, the box just crashed and rebooted. I'll revert to your first patch to see if that one still helps. -- 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 63632] mesa +r600 llvm = segfault
https://bugs.freedesktop.org/show_bug.cgi?id=63632 --- Comment #2 from Tom Stellard --- I can't reproduce this with LLVM r179895 and Mesa 12eab7cc564a6928197f9b87ded9e368e56976f0 Have you done full rebuilds of both projects? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/41fbbf06/attachment.html>
[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"
https://bugs.freedesktop.org/show_bug.cgi?id=63730 Christian König changed: What|Removed |Added Attachment #78243|0 |1 is obsolete|| --- Comment #3 from Christian König --- Created attachment 78270 --> https://bugs.freedesktop.org/attachment.cgi?id=78270&action=edit Possible fix v2 Please try this one instead. -- 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 56891] TRAP_VFETCH FAULT in nouveau during highload 3D
https://bugzilla.kernel.org/show_bug.cgi?id=56891 George Shuklin changed: What|Removed |Added Summary|TRAP_VFETCH FAULT |TRAP_VFETCH FAULT in ||nouveau during highload 3D -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56891] New: TRAP_VFETCH FAULT
https://bugzilla.kernel.org/show_bug.cgi?id=56891 Summary: TRAP_VFETCH FAULT Product: Drivers Version: 2.5 Kernel Version: 3.9-rc7 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: george.shuk...@gmail.com Regression: No nouveau cause unexpected delays and periodic freeze (<0.2s) when rendering complicated 3D scene. Here dmesg during lags (repeat many times): [46444.498018] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46444.498028] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46444.498031] nouveau E[ PGRAPH][:01:00.0] TRAP [46444.498037] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x3f80 [46444.498045] nouveau E[ PFB][:01:00.0] trapped read at 0x00 on channel 0x0001f8eb [el.x86.linux.bi[7941]] PGRAPH/VFETCH/00 reason: PT_NOT_PRESENT [46444.498070] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46444.498082] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46444.498085] nouveau E[ PGRAPH][:01:00.0] TRAP [46444.498092] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x40028f58 [46448.541527] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46448.541537] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46448.541540] nouveau E[ PGRAPH][:01:00.0] TRAP [46448.541545] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x3f80 [46448.541557] nouveau E[ PFB][:01:00.0] trapped read at 0x00 on channel 0x0001f8eb [el.x86.linux.bi[7941]] PGRAPH/VFETCH/00 reason: PT_NOT_PRESENT [46448.541590] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH FAULT [46448.541601] nouveau E[ PGRAPH][:01:00.0] TRAP_VFETCH 00f0 fe0c [46448.541605] nouveau E[ PGRAPH][:01:00.0] TRAP [46448.541612] nouveau E[ PGRAPH][:01:00.0] ch 4 [0x001f8eb000 el.x86.linux.bi[7941]] subc 5 class 0x8297 mthd 0x0f04 data 0x But that problem is same with many 3D applications. Was seen at least from 3.2 to 3.9-rc7. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63748] New: GPU Lockup playing urban terror
https://bugs.freedesktop.org/show_bug.cgi?id=63748 Priority: medium Bug ID: 63748 Assignee: dri-devel at lists.freedesktop.org Summary: GPU Lockup playing urban terror Severity: major Classification: Unclassified OS: Linux (All) Reporter: dinolib at libero.it Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Playing UrT just few minutes, bring to CPU lockup rescued in some seconds with a softreset. Sometimes the system can't recover from this state. Before Mesa 9 (and relative dri drivers) update never happened. 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series] Kernel 3.7.6 (Chakra linux) Environment: KDE (both OpenGL and XRender) Tested with any kind of radeon power management (dynamic, high and low profile). dmesg log: [646081.016040] radeon :01:05.0: GPU lockup CP stall for more than 1msec [646081.016048] radeon :01:05.0: GPU lockup (waiting for 0x003b66b2 last fence id 0x003b66ac) [646081.017095] radeon :01:05.0: Saved 185 dwords of commands on ring 0. [646081.017099] radeon :01:05.0: GPU softreset [646081.017102] radeon :01:05.0: R_008010_GRBM_STATUS=0xA00024AC [646081.017104] radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 [646081.017106] radeon :01:05.0: R_000E50_SRBM_STATUS=0x2040 [646081.017109] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x0400 [646081.017111] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x00040002 [646081.017114] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x8484 [646081.017116] radeon :01:05.0: R_008680_CP_STAT = 0x80858645 [646081.017122] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x7FEE [646081.032099] radeon :01:05.0: R_008020_GRBM_SOFT_RESET=0x0001 [646081.048074] radeon :01:05.0: R_008010_GRBM_STATUS=0xA0003030 [646081.048077] radeon :01:05.0: R_008014_GRBM_STATUS2=0x0003 [646081.048079] radeon :01:05.0: R_000E50_SRBM_STATUS=0x20008040 [646081.048082] radeon :01:05.0: R_008674_CP_STALLED_STAT1 = 0x [646081.048084] radeon :01:05.0: R_008678_CP_STALLED_STAT2 = 0x [646081.048086] radeon :01:05.0: R_00867C_CP_BUSY_STAT = 0x [646081.048089] radeon :01:05.0: R_008680_CP_STAT = 0x8010 [646081.049090] radeon :01:05.0: GPU reset succeeded, trying to resume [646081.053294] [drm] PCIE GART of 512M enabled (table at 0xC004). [646081.053366] radeon :01:05.0: WB enabled [646081.053370] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8800c884dc00 [646081.053639] radeon :01:05.0: setting latency timer to 64 [646081.085618] [drm] ring test on 0 succeeded in 0 usecs [646081.094844] [drm] ib test on ring 0 succeeded in 0 usecs No errors in Xorg.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130420/8fd463f4/attachment.html>
Re: [PATCH] drm/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 12:11 PM, Chris Wilson wrote:
> On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote:
>> In
>>
>> commit 9e8944ab564f2e3dde90a518cd32048c58918608
>> Author: Chris Wilson
>> Date: Thu Nov 15 11:32:17 2012 +
>>
>> drm: Introduce an iterator over holes in the drm_mm range manager
>>
>> helpers and iterators for hole handling have been introduced with some
>> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
>> which unconditionally tried to compute the size of the very first
>> hole.
>>
>> Reported-by: Christopher Harvey
>> Cc: Christopher Harvey
>> Cc: Dave Airlie
>> Cc: Chris Wilson
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_mm.c | 11 ++-
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>> index db1e2d6..a0ba3a1 100644
>> --- a/drivers/gpu/drm/drm_mm.c
>> +++ b/drivers/gpu/drm/drm_mm.c
>> @@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct
>> drm_mm *mm)
>> {
>> struct drm_mm_node *entry;
>> unsigned long total_used = 0, total_free = 0, total = 0;
>> - unsigned long hole_start, hole_end, hole_size;
>> + unsigned long hole_start, hole_end, hole_size = 0;
>>
>> - hole_start = drm_mm_hole_node_start(&mm->head_node);
>> - hole_end = drm_mm_hole_node_end(&mm->head_node);
>
> Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead.
I've figured I could make the condition more symmetric with the one in
the loop, so that both check ->hole_follows.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: fix dump table BUG
On Sat, Apr 20, 2013 at 12:08:11PM +0200, Daniel Vetter wrote:
> In
>
> commit 9e8944ab564f2e3dde90a518cd32048c58918608
> Author: Chris Wilson
> Date: Thu Nov 15 11:32:17 2012 +
>
> drm: Introduce an iterator over holes in the drm_mm range manager
>
> helpers and iterators for hole handling have been introduced with some
> debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
> which unconditionally tried to compute the size of the very first
> hole.
>
> Reported-by: Christopher Harvey
> Cc: Christopher Harvey
> Cc: Dave Airlie
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mm.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index db1e2d6..a0ba3a1 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct drm_mm
> *mm)
> {
> struct drm_mm_node *entry;
> unsigned long total_used = 0, total_free = 0, total = 0;
> - unsigned long hole_start, hole_end, hole_size;
> + unsigned long hole_start, hole_end, hole_size = 0;
>
> - hole_start = drm_mm_hole_node_start(&mm->head_node);
> - hole_end = drm_mm_hole_node_end(&mm->head_node);
Use __drm_mm_hole_node_start and __drm_mm_hole_node_end instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mm: fix dump table BUG
In
commit 9e8944ab564f2e3dde90a518cd32048c58918608
Author: Chris Wilson
Date: Thu Nov 15 11:32:17 2012 +
drm: Introduce an iterator over holes in the drm_mm range manager
helpers and iterators for hole handling have been introduced with some
debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
which unconditionally tried to compute the size of the very first
hole.
Reported-by: Christopher Harvey
Cc: Christopher Harvey
Cc: Dave Airlie
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index db1e2d6..a0ba3a1 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -759,14 +759,15 @@ int drm_mm_dump_table(struct seq_file *m, struct drm_mm
*mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, total = 0;
- unsigned long hole_start, hole_end, hole_size;
+ unsigned long hole_start, hole_end, hole_size = 0;
- hole_start = drm_mm_hole_node_start(&mm->head_node);
- hole_end = drm_mm_hole_node_end(&mm->head_node);
- hole_size = hole_end - hole_start;
- if (hole_size)
+ if (mm->head_node.hole_follows) {
+ hole_start = drm_mm_hole_node_start(&mm->head_node);
+ hole_end = drm_mm_hole_node_end(&mm->head_node);
+ hole_size = hole_end - hole_start;
seq_printf(m, "0x%08lx-0x%08lx: 0x%08lx: free\n",
hole_start, hole_end, hole_size);
+ }
total_free += hole_size;
drm_mm_for_each_node(entry, mm) {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63632] mesa +r600 llvm = segfault
https://bugs.freedesktop.org/show_bug.cgi?id=63632 --- Comment #3 from Andy Furniss --- (In reply to comment #2) > I can't reproduce this with LLVM r179895 and Mesa > 12eab7cc564a6928197f9b87ded9e368e56976f0 > > Have you done full rebuilds of both projects? Yes, I always do make [dist]clean and git clean -dfx. I have just deleted both trees and re-cloned to be sure, but the segfault is still there. When I was on my working commits moving either llvm or mesa to head while keeping the other on "working" produced the segfault (which is why I didn't do a proper bisect). I always clean and rebuild mesa after llvm has changed. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #35 from udo --- Alex, despite having your 2nd patch in, I found: Apr 17 16:26:07 o2 kernel: [91224.372170] radeon :00:01.0: GPU fault detected: 146 0x0594260c Apr 17 16:26:07 o2 kernel: [91224.372175] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0A59 Apr 17 16:26:07 o2 kernel: [91224.372178] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0402600C Apr 17 16:26:07 o2 kernel: [91224.372181] radeon :00:01.0: GPU fault detected: 146 0x0594260c Apr 17 16:26:07 o2 kernel: [91224.372184] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 17 16:26:07 o2 kernel: [91224.372187] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x Apr 19 17:19:08 o2 kernel: [132471.330610] radeon :00:01.0: GPU fault detected: 147 0x06d37002 Apr 19 17:19:08 o2 kernel: [132471.330614] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x316D Apr 19 17:19:08 o2 kernel: [132471.330617] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03070002 -- 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
UVD status on loongson 3a platform
Am 2013-04-19 10:51, schrieb Chen Jie: > Hi all, > > Recently, the uvd supporting is released, and we've tried it on > loongson 3a platform. > Brief introduction about loongson 3a, it's a MIPS III compatible, 4 > cores processor. > > More details about the platform [1]: > * The Board: RS780E + SB710 chipset, with an AMD radeon HD6570 video > card > * The kernel is 64bits(n64 ABI), and the userland is 32bits(o32 ABI) > * OS: LOonux 3.3.6 [2] + LTP-uvd-installer-20130419.bin [3] > ** kernel: 3.9 + uvd related patches > ** mesa: git master version (d0e9aa) Are you guys interested in OpenCL (on your platform)? OpenCV (one of the basis for digikam for example) has some support for Nvidia and now AMD. It is under development by Institute Of Software Chinese Academy Of Science. AFDS 2012 http://www.youtube.com/watch?v=LhIuSShTO0g Even the next big Gimp version (2.10) should be accelerated by OpenCL through GEGL. Wouldn't it be cool to have OSS OpenCL even for 'smaller' sized gfx cards from AMD? You are a hardware shop so maybe your demand is it AMD worth to have something around? Regards, Dieter PS Here comes something about Nvidia's other collaboration... http://www.h-online.com/open/features/Kernel-comment-Bad-show-NVIDIA-1845899.html > > [1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN) > [2] http://dev.lemote.com/653.html (zh_CN) > [3] http://dev.lemote.com/663.html (zh_CN) > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
