dri-devel March 2012

dri-devel@lists.freedesktop.org

114 participants
646 discussions

[Bug 4374] [855GM] Incorrect painting in crack-attack
by bugzilla-daemon＠freedesktop.org 03 Mar '12

03 Mar '12

https://bugs.freedesktop.org/show_bug.cgi?id=4374 Eric Anholt <eric(a)anholt.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #20 from Eric Anholt <eric(a)anholt.net> 2012-03-02 17:44:20 PST --- I seem to recall testing this on my 865 about a year ago and seeing … [View More]

1 0

[Bug 45558] New: cannot render on a drawable of size equal the max framebuffer size
by bugzilla-daemon＠freedesktop.org 03 Mar '12

03 Mar '12

https://bugs.freedesktop.org/show_bug.cgi?id=45558 Bug #: 45558 Summary: cannot render on a drawable of size equal the max framebuffer size Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i830 AssignedTo: dri-devel(a)lists.freedesktop.org … [View More]

1 4

[PATCH libdrm] Don't require pciaccess if Intel is disabled
by Matt Turner 02 Mar '12

02 Mar '12

Signed-off-by: Matt Turner <mattst88(a)gmail.com> --- configure.ac | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 97bbcb7..71a596c 100644 --- a/configure.ac +++ b/configure.ac @@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs) AC_SUBST(PTHREADSTUBS_CFLAGS) AC_SUBST(PTHREADSTUBS_LIBS) -PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10]) -AC_SUBST(PCIACCESS_CFLAGS) -AC_SUBST(PCIACCESS_LIBS) - … [View More]

2 1

libdrm and platform devices?
by Sascha Hauer 02 Mar '12

02 Mar '12

Hi All, I have a drm device on the platform bus, similar to the exynos driver. right now libdrm (at least the tests included in libdrm) refuses to open the device because i915, nouveau, radeon and vmwgfx is all they know about. Looking at the libdrm code it is not obvious how to fix this (except for adding "exynos", "mydevice", "myotherdevice" to the module table which seems awkward and not very futureproof). Any hints or thoughts how to proceed here? Thanks Sascha -- Pengutronix e.K. … [View More]

2 3

[Bug 22195] app crashed to desktop with Radeon driver
by bugzilla-daemon＠freedesktop.org 02 Mar '12

02 Mar '12

https://bugs.freedesktop.org/show_bug.cgi?id=22195 dre <andreas.kaim(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

system_nrt_wq, system suspend, and the freezer
by Alan Stern 02 Mar '12

02 Mar '12

Folks: I recently uncovered a bug in the block layer. It uses a workqueue to periodically probe removable drives for media or other state changes, and the workqueue it uses is system_nrt_wq. The bug is that system_nrt_wq is not freezable, so it keeps on running even while the system is in the process of suspending or hibernating. Doing I/O to a suspended drive doesn't work well and in some cases causes nasty problems. Obviously these polls need to stop during a suspend transition. A … [View More]

7 17

[PATCH v2] i915: Add option to bypass vbt table.
by Mathias.Froehlich＠gmx.net 02 Mar '12

02 Mar '12

From: Mathias Fröhlich <Mathias.Froehlich(a)web.de> Add an option to skip reading the mode entries from the vbt bios tables. This change enables the use of displays where the vbt table just contains inappropriate values, but either the vesa defaults or the video=... modes do something sensible with the attached display. Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> Signed-off-by: Mathias Froehlich <Mathias.Froehlich(a)web.de> --- drivers/gpu/drm/i915/… [View More]

4 4

[Bug 45984] New: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
by bugzilla-daemon＠freedesktop.org 02 Mar '12

02 Mar '12

https://bugs.freedesktop.org/show_bug.cgi?id=45984 Bug #: 45984 Summary: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch. Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-… [View More]

1 9

Re: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
by chenhc＠lemote.com 01 Mar '12

01 Mar '12

Status update: In r600.c I found for RS780, num_*_threads are like this: sq_thread_resource_mgmt = (NUM_PS_THREADS(79) | NUM_VS_THREADS(78) | NUM_GS_THREADS(4) | NUM_ES_THREADS(31)); But in documents, each of them should be a multiple of 4. And in r600_blit_kms.c， they are 136, 48, 4, 4. I want to know why 79, 78, 4 and 31 are use here. Huacai Chen > On Wed, … [View More]2012-02-29 at 12:49 +0800, chenhc(a)lemote.com wrote: >> > On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote: >> >> 在 2012年2月17日下午5:27，Chen Jie <chenj(a)lemote.com> 写道： >> >> >> One good way to test gart is to go over GPU gart table and write a >> >> >> dword using the GPU at end of each page something like 0xCAFEDEAD >> >> >> or somevalue that is unlikely to be already set. And then go over >> >> >> all the page and check that GPU write succeed. Abusing the scratch >> >> >> register write back feature is the easiest way to try that. >> >> > I'm planning to add a GART table check procedure when resume, which >> >> > will go over GPU gart table: >> >> > 1. read(backup) a dword at end of each GPU page >> >> > 2. write a mark by GPU and check it >> >> > 3. restore the original dword >> >> Attachment validateGART.patch do the job: >> >> * It current only works for mips64 platform. >> >> * To use it, apply all_in_vram.patch first, which will allocate CP >> >> ring, ih, ib in VRAM and hard code no_wb=1. >> >> >> >> The gart test routine will be invoked in r600_resume. We've tried it, >> >> and find that when lockup happened the gart table was good before >> >> userspace restarting. The related dmesg follows: >> >> [ 1521.820312] [drm] r600_gart_table_validate(): Validate GART Table >> >> at 9000000040040000, 32768 entries, Dummy >> >> Page[0x000000000e004000-0x000000000e007fff] >> >> [ 1522.019531] [drm] r600_gart_table_validate(): Sweep 32768 >> >> entries(valid=8544, invalid=24224, total=32768). >> >> ... >> >> [ 1531.156250] PM: resume of devices complete after 9396.588 msecs >> >> [ 1532.152343] Restarting tasks ... done. >> >> [ 1544.468750] radeon 0000:01:05.0: GPU lockup CP stall for more than >> >> 10003msec >> >> [ 1544.472656] ------------[ cut here ]------------ >> >> [ 1544.480468] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:243 >> >> radeon_fence_wait+0x25c/0x314() >> >> [ 1544.488281] GPU lockup (waiting for 0x0002136B last fence id >> >> 0x0002136A) >> >> ... >> >> [ 1544.886718] radeon 0000:01:05.0: Wait for MC idle timedout ! >> >> [ 1545.046875] radeon 0000:01:05.0: Wait for MC idle timedout ! >> >> [ 1545.062500] radeon 0000:01:05.0: WB disabled >> >> [ 1545.097656] [drm] ring test succeeded in 0 usecs >> >> [ 1545.105468] [drm] ib test succeeded in 0 usecs >> >> [ 1545.109375] [drm] Enabling audio support >> >> [ 1545.113281] [drm] r600_gart_table_validate(): Validate GART Table >> >> at 9000000040040000, 32768 entries, Dummy >> >> Page[0x000000000e004000-0x000000000e007fff] >> >> [ 1545.125000] [drm:r600_gart_table_validate] *ERROR* Iter=0: >> >> unexpected value 0x745aaad1(expect 0xDEADBEEF) >> >> entry=0x000000000e008067, orignal=0x745aaad1 >> >> ... >> >> /* System blocked here. */ >> >> >> >> Any idea? >> > >> > I know lockup are frustrating, my only idea is the memory controller >> > is lockup because of some failing pci <-> system ram transaction. >> > >> >> >> >> BTW, we find the following in r600_pcie_gart_enable() >> >> (drivers/gpu/drm/radeon/r600.c): >> >> WREG32(VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR, >> >> (u32)(rdev->dummy_page.addr >> 12)); >> >> >> >> On our platform, PAGE_SIZE is 16K, does it have any problem? >> > >> > No this should be handled properly. >> > >> >> Also in radeon_gart_unbind() and radeon_gart_restore(), the logic >> >> should change to: >> >> for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++, t++) { >> >> radeon_gart_set_page(rdev, t, page_base); >> >> - page_base += RADEON_GPU_PAGE_SIZE; >> >> + if (page_base != rdev->dummy_page.addr) >> >> + page_base += RADEON_GPU_PAGE_SIZE; >> >> } >> >> ??? >> > >> > No need to do so, dummy page will be 16K too, so it's fine. >> Really? When CPU page is 16K and GPU page is 4k, suppose the dummy page >> is 0x8e004000, then there are four types of address in GART:0x8e004000, >> 0x8e005000, 0x8e006000, 0x8e007000. The value which written in >> VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR is 0x8e004 (0x8e004000<<12). I >> don't know how VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR works, but I >> think 0x8e005000, 0x8e006000 and 0x8e007000 cannot be handled correctly. > > When radeon_gart_unbind initialize the gart entry to point to the dummy > page it's just to have something safe in the GART table. > > VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR is the page address used when > there is a fault happening. It's like a sandbox for the mc. It doesn't > conflict in anyway to have gart table entry to point to same page. > > Cheers, > Jerome > > [View Less]

2 1

[PATCH] drm: edid: Add bounds checking to CEA 18 byte descriptor parsing
by ville.syrjala＠linux.intel.com 01 Mar '12

01 Mar '12

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Make sure we don't access beyond the extension block when parsing CEA detailed timing descriptors. Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7ee7be1..0194d4a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -516,6 +… [View More]

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2012