dri-devel July 2012

dri-devel@lists.freedesktop.org

115 participants
688 discussions

[PATCH 1/2] drm/radeon: add error handling to fence_wait_empty_locked
by Christian König 04 Jul '12

04 Jul '12

Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian König <deathsimple(a)vodafone.de> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> --- drivers/gpu/drm/radeon/radeon.h | 2 +- drivers/gpu/drm/radeon/radeon_fence.c | 33 +++++++++++++++++++++------------ 2 files changed, 22 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 77b4519b..5861ec8 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -239,7 +239,7 @@ void radeon_fence_process(struct radeon_device *rdev, int ring); bool radeon_fence_signaled(struct radeon_fence *fence); int radeon_fence_wait(struct radeon_fence *fence, bool interruptible); int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring); -int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring); +void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring); int radeon_fence_wait_any(struct radeon_device *rdev, struct radeon_fence **fences, bool intr); diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 7b55625..be4e4f3 100644 --- a/drivers/gpu/drm/radeon/radeon_fence.c +++ b/drivers/gpu/drm/radeon/radeon_fence.c @@ -440,14 +440,11 @@ int radeon_fence_wait_any(struct radeon_device *rdev, return 0; } +/* caller must hold ring lock */ int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring) { uint64_t seq; - /* We are not protected by ring lock when reading current seq but - * it's ok as worst case is we return to early while we could have - * wait. - */ seq = atomic64_read(&rdev->fence_drv[ring].last_seq) + 1ULL; if (seq >= rdev->fence_drv[ring].sync_seq[ring]) { /* nothing to wait for, last_seq is @@ -457,15 +454,27 @@ int radeon_fence_wait_next_locked(struct radeon_device *rdev, int ring) return radeon_fence_wait_seq(rdev, seq, ring, false, false); } -int radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring) +/* caller must hold ring lock */ +void radeon_fence_wait_empty_locked(struct radeon_device *rdev, int ring) { - /* We are not protected by ring lock when reading current seq - * but it's ok as wait empty is call from place where no more - * activity can be scheduled so there won't be concurrent access - * to seq value. - */ - return radeon_fence_wait_seq(rdev, rdev->fence_drv[ring].sync_seq[ring], - ring, false, false); + uint64_t seq = rdev->fence_drv[ring].sync_seq[ring]; + + while(1) { + int r; + r = radeon_fence_wait_seq(rdev, seq, ring, false, false); + if (r == -EDEADLK) { + mutex_unlock(&rdev->ring_lock); + r = radeon_gpu_reset(rdev); + mutex_lock(&rdev->ring_lock); + if (!r) + continue; + } + if (r) { + dev_err(rdev->dev, "error waiting for ring to become" + " idle (%d)\n", r); + } + return; + } } struct radeon_fence *radeon_fence_ref(struct radeon_fence *fence) -- 1.7.9.5

3 3

Re: [MMTests] IO metadata on XFS
by Mel Gorman 04 Jul '12

04 Jul '12

Adding dri-devel and a few others because an i915 patch contributed to the regression. On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote: > On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote: > > > It increases the CPU overhead (dirty_inode can be called up to 4 > > > times per write(2) call, IIRC), so with limited numbers of > > > threads/limited CPU power it will result in lower performance. Where > > > you have lots of CPU power, there will be little difference in > > > performance... > > > > When I checked it it could only be called twice, and we'd already > > optimize away the second call. I'd defintively like to track down where > > the performance changes happend, at least to a major version but even > > better to a -rc or git commit. > > > > By all means feel free to run the test yourself and run the bisection :) > > It's rare but on this occasion the test machine is idle so I started an > automated git bisection. As you know the milage with an automated bisect > varies so it may or may not find the right commit. Test machine is sandy so > http://www.csn.ul.ie/~mel/postings/mmtests-20120424/global-dhp__io-metadata… > is the report of interest. The script is doing a full search between v3.3 and > v3.4 for a point where average files/sec for fsmark-single drops below 25000. > I did not limit the search to fs/xfs on the off-chance that it is an > apparently unrelated patch that caused the problem. > It was obvious very quickly that there were two distinct regression so I ran two bisections. One led to a XFS and the other led to an i915 patch that enables RC6 to reduce power usage. [c999a223: xfs: introduce an allocation workqueue] [aa464191: drm/i915: enable plain RC6 on Sandy Bridge by default] gdm was running on the machine so i915 would have been in use. In case it is of interest this is the log of the bisection. Lines beginning with # are notes I made and all other lines are from the bisection script. The second-last column is the files/sec recorded by fsmark. # MARK v3.3..v3.4 Search for BAD files/sec -lt 28000 # BAD 16536 # GOOD 34757 Mon Jul 2 15:46:13 IST 2012 sandy xfsbisect 141124c02059eee9dbc5c86ea797b1ca888e77f7 37454 good Mon Jul 2 15:56:06 IST 2012 sandy xfsbisect 55a320308902f7a0746569ee57eeb3f254e6ed16 25192 bad Mon Jul 2 16:08:34 IST 2012 sandy xfsbisect 281b05392fc2cb26209b4d85abaf4889ab1991f3 38807 good Mon Jul 2 16:18:02 IST 2012 sandy xfsbisect a8364d5555b2030d093cde0f07951628e55454e1 37553 good Mon Jul 2 16:27:22 IST 2012 sandy xfsbisect d2a2fc18d98d8ee2dec1542efc7f47beec256144 36676 good Mon Jul 2 16:36:48 IST 2012 sandy xfsbisect 2e7580b0e75d771d93e24e681031a165b1d31071 37756 good Mon Jul 2 16:46:36 IST 2012 sandy xfsbisect 532bfc851a7475fb6a36c1e953aa395798a7cca7 25416 bad Mon Jul 2 16:56:10 IST 2012 sandy xfsbisect 0c9aac08261512d70d7d4817bd222abca8b6bdd6 38486 good Mon Jul 2 17:05:40 IST 2012 sandy xfsbisect 0fc9d1040313047edf6a39fd4d7c7defdca97c62 37970 good Mon Jul 2 17:16:01 IST 2012 sandy xfsbisect 5a5881cdeec2c019b5c9a307800218ee029f7f61 24493 bad Mon Jul 2 17:21:15 IST 2012 sandy xfsbisect f616137519feb17b849894fcbe634a021d3fa7db 24405 bad Mon Jul 2 17:26:16 IST 2012 sandy xfsbisect 5575acc7807595687288b3bbac15103f2a5462e1 37336 good Mon Jul 2 17:31:25 IST 2012 sandy xfsbisect c999a223c2f0d31c64ef7379814cea1378b2b800 24552 bad Mon Jul 2 17:36:34 IST 2012 sandy xfsbisect 1a1d772433d42aaff7315b3468fef5951604f5c6 36872 good # c999a223c2f0d31c64ef7379814cea1378b2b800 is the first bad commit # [c999a223: xfs: introduce an allocation workqueue] # # MARK c999a223c2f0d31c64ef7379814cea1378b2b800..v3.4 Search for BAD files/sec -lt 20000 # BAD 16536 # GOOD 24552 Mon Jul 2 17:48:39 IST 2012 sandy xfsbisect b2094ef840697bc8ca5d17a83b7e30fad5f1e9fa 37435 good Mon Jul 2 17:58:12 IST 2012 sandy xfsbisect d2a2fc18d98d8ee2dec1542efc7f47beec256144 38303 good Mon Jul 2 18:08:18 IST 2012 sandy xfsbisect 5d32c88f0b94061b3af2e3ade92422407282eb12 16718 bad Mon Jul 2 18:18:02 IST 2012 sandy xfsbisect 2f7fa1be66dce77608330c5eb918d6360b5525f2 24964 good Mon Jul 2 18:24:14 IST 2012 sandy xfsbisect 923f79743c76583ed4684e2c80c8da51a7268af3 24963 good Mon Jul 2 18:33:49 IST 2012 sandy xfsbisect b61c37f57988567c84359645f8202a7c84bc798a 24824 good Mon Jul 2 18:40:20 IST 2012 sandy xfsbisect 20a2a811602b16c42ce88bada3d52712cdfb988b 17155 bad Mon Jul 2 18:50:12 IST 2012 sandy xfsbisect 78fb72f7936c01d5b426c03a691eca082b03f2b9 38494 good Mon Jul 2 19:00:24 IST 2012 sandy xfsbisect e1a7eb08ee097e97e928062a242b0de5b2599a11 25033 good Mon Jul 2 19:10:24 IST 2012 sandy xfsbisect 97effadb65ed08809e1720c8d3ee80b73a93665c 16520 bad Mon Jul 2 19:16:16 IST 2012 sandy xfsbisect 25e341cfc33d94435472983825163e97fe370a6c 16748 bad Mon Jul 2 19:21:52 IST 2012 sandy xfsbisect 7dd4906586274f3945f2aeaaa5a33b451c3b4bba 24957 good Mon Jul 2 19:27:35 IST 2012 sandy xfsbisect aa46419186992e6b8b8010319f0ca7f40a0d13f5 17088 bad Mon Jul 2 19:32:54 IST 2012 sandy xfsbisect 83b7f9ac9126f0532ca34c14e4f0582c565c6b0d 25667 good # aa46419186992e6b8b8010319f0ca7f40a0d13f5 is the first bad commit # [aa464191: drm/i915: enable plain RC6 on Sandy Bridge by default] I tested plain reverts of the patches individually and together and got the following results FS-Mark Single Threaded 3.4.0 3.4.0 3.4.0 3.4.0-vanilla revert-aa464191 revert-c999a223 revert-both Files/s min 14176.40 ( 0.00%) 17830.60 (25.78%) 24186.70 (70.61%) 25108.00 (77.11%) Files/s mean 16783.35 ( 0.00%) 25029.69 (49.13%) 37513.72 (123.52%) 38169.97 (127.43%) Files/s stddev 1007.26 ( 0.00%) 2644.87 (162.58%) 5344.99 (430.65%) 5599.65 (455.93%) Files/s max 18475.40 ( 0.00%) 27966.10 (51.37%) 45564.60 (146.62%) 47918.10 (159.36%) Overhead min 593978.00 ( 0.00%) 386173.00 (34.99%) 253812.00 (57.27%) 247396.00 (58.35%) Overhead mean 637782.80 ( 0.00%) 429229.33 (32.70%) 322868.20 (49.38%) 287141.73 (54.98%) Overhead stddev 72440.72 ( 0.00%) 100056.96 (-38.12%) 175001.08 (-141.58%) 102018.14 (-40.83%) Overhead max 855637.00 ( 0.00%) 753541.00 (11.93%) 880531.00 (-2.91%) 637932.00 (25.44%) MMTests Statistics: duration Sys Time Running Test (seconds) 44.06 32.25 24.19 23.99 User+Sys Time Running Test (seconds) 50.19 36.35 27.24 26.7 Total Elapsed Time (seconds) 59.21 44.76 34.95 34.14 Individually reverting either patch makes a difference to both files/sec and overhead. Reverting both is not as dramatic as reverting each individual patch would indicate but it's still a major improvement. -- Mel Gorman SUSE Labs

4 10

[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook
by bugzilla-daemon＠bugzilla.kernel.org 04 Jul '12

04 Jul '12

https://bugzilla.kernel.org/show_bug.cgi?id=42627 Zhang Rui <rui.zhang(a)intel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Hibernation/Suspend |Video(DRI - non Intel) AssignedTo|power-management_other@kern |drivers_video-dri@kernel-bu |el-bugs.osdl.org |gs.osdl.org Product|Power Management |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

Is drm-radeon-testing broken for anyone else?
by David Witbrodt 03 Jul '12

03 Jul '12

Maybe I'm doing something wrong, but my cloned repo of drm-radeon-testing is giving build errors. What I'm seeing is [...] CC drivers/gpu/drm/radeon/radeon_gem.o drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_create_ioctl’: drivers/gpu/drm/radeon/radeon_gem.c:221:3: error: implicit declaration of function ‘radeon_mutex_lock’ [-Werror=implicit-function-declaration] drivers/gpu/drm/radeon/radeon_gem.c:221:26: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c:222:3: error: implicit declaration of function ‘radeon_mutex_unlock’ [-Werror=implicit-function-declaration] drivers/gpu/drm/radeon/radeon_gem.c:222:28: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_set_domain_ioctl’: drivers/gpu/drm/radeon/radeon_gem.c:268:26: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c:269:28: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ cc1: some warnings being treated as errors make[6]: *** [drivers/gpu/drm/radeon/radeon_gem.o] Error 1 Looking around a bit, I find this commit commit 36ff39c4045ee71cd306f8af5f8c2a1c6e998eba Author: Christian König <deathsimple(a)vodafone.de> Date: Wed May 9 10:07:08 2012 +0200 drm/radeon: replace cs_mutex with vm_mutex v3 replaces radeon_mutex_lock()/radeon_mutex_unlock() with mutex_lock()/mutex_unlock() in most places, eliminating it in others. A more recent commit commit 0a01063d5fd7417175512f0f916629008c0a842e Author: Jerome Glisse <jglisse(a)redhat.com> Date: Wed Jun 27 14:14:21 2012 -0400 drm/radeon: disable any GPU activity after unrecovered lockup v5 introduces this hunk: diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index f28bd4b..74176c5 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -217,6 +217,22 @@ int radeon_gem_create_ioctl(struct drm_device *dev, void *data, uint32_t handle; int r; + /* if in middle of gpu reset wait on the mutex, if reset + * failed don't do anything, otherwise proceed. + */ + if (!rdev->accel_working) { + /* lockup situation wait for cs mutex to be droped */ + radeon_mutex_lock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); + /* we are after a gpu reset */ + if (!rdev->accel_working) { + /* gpu reset failed, don't create anymore GPU + * object + */ + return -EBUSY; + } + } + If it's not just something stupid I've done on my local machine, then it looks like the 0a01063d patch was applied without noticing the changes made in 36ff39c4. (If the problem is really just me, sorry for the spam/ noise.) Dave W.

2 2

[PATCH libdrm] intel: Fix build failure in test_decode.c
by Lauri Kasanen 03 Jul '12

03 Jul '12

Hi list The recently released libdrm 2.4.37 does not compile the Intel part: test_decode.c: In function 'compare_batch': test_decode.c:107: error: implicit declaration of function 'open_memstream' PS: Please CC me. Signed-off-by: Lauri Kasanen <cand(a)gmx.com> --- intel/test_decode.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/intel/test_decode.c b/intel/test_decode.c index c9ab7ad..0fcdf3b 100644 --- a/intel/test_decode.c +++ b/intel/test_decode.c @@ -21,6 +21,8 @@ * IN THE SOFTWARE. */ +#define _GNU_SOURCE + #include <string.h> #include <stdlib.h> #include <stdio.h> -- 1.7.2.1

2 3

Re: [ANNOUNCE] libdrm 2.4.37
by Ben Widawsky 03 Jul '12

03 Jul '12

The link generated by the release script was incorrect. They should be http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.gz http://dri.freedesktop.org/libdrm/libdrm-2.4.37.tar.bz2 On Fri, 29 Jun 2012 11:17:47 -0700 Ben Widawsky <ben(a)bwidawsk.net> wrote: > I botched the 2.3.36 release quite royally. Here is 2.6.37 this time with the > proper context APIs in place. > > Ben Widawsky (2): > intel/context: create/destroy implementation > configure: bump version for release > > Kristian Høgsberg (1): > modetest: Dump bit field names > > git tag: libdrm-2.4.37 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.bz2 > MD5: 9765919c28d4a54887576db3680137cc libdrm-2.4.37.tar.bz2 > SHA1: fa8463e390eee9b589dc369abc4cbe3e4ef16d16 libdrm-2.4.37.tar.bz2 > SHA256: e4ea39a901d4a8e59064f10f413bb037dad7790f7c16a5986e7cc1453b36488f libdrm-2.4.37.tar.bz2 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.37.tar.gz > MD5: 7f762bfa0bdaa7216c926d0dc9629e87 libdrm-2.4.37.tar.gz > SHA1: b086dc3f64570ac9aa9eccd23a1e8156e9038995 libdrm-2.4.37.tar.gz > SHA256: b530d71ff9a7f5252f450a386540fe8512bde033e8283fa6a1bbcd3c62fc91e4 libdrm-2.4.37.tar.gz > > _______________________________________________ > xorg-announce mailing list > xorg-announce(a)lists.x.org > http://lists.x.org/mailman/listinfo/xorg-announce -- Ben Widawsky, Intel Open Source Technology Center

1 0

[PATCH] drm/radeon: add an exclusive lock for GPU reset
by j.glisse＠gmail.com 03 Jul '12

03 Jul '12

From: Jerome Glisse <jglisse(a)redhat.com> GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring that no concurrent reset take place. Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_cs.c | 5 +++++ drivers/gpu/drm/radeon/radeon_device.c | 2 ++ drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++++ 4 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 77b4519b..29d6986 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1446,6 +1446,7 @@ struct radeon_device { struct device *dev; struct drm_device *ddev; struct pci_dev *pdev; + struct rw_semaphore exclusive_lock; /* ASIC */ union radeon_asic_config config; enum radeon_family family; diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index f1b7527..7ee6491 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -499,7 +499,9 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) struct radeon_cs_parser parser; int r; + down_read(&rdev->exclusive_lock); if (!rdev->accel_working) { + up_read(&rdev->exclusive_lock); return -EBUSY; } /* initialize parser */ @@ -512,6 +514,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) if (r) { DRM_ERROR("Failed to initialize parser !\n"); radeon_cs_parser_fini(&parser, r); + up_read(&rdev->exclusive_lock); r = radeon_cs_handle_lockup(rdev, r); return r; } @@ -520,6 +523,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) if (r != -ERESTARTSYS) DRM_ERROR("Failed to parse relocation %d!\n", r); radeon_cs_parser_fini(&parser, r); + up_read(&rdev->exclusive_lock); r = radeon_cs_handle_lockup(rdev, r); return r; } @@ -533,6 +537,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) } out: radeon_cs_parser_fini(&parser, r); + up_read(&rdev->exclusive_lock); r = radeon_cs_handle_lockup(rdev, r); return r; } diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index f654ba8..c8fdb40 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -988,6 +988,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int r; int resched; + down_write(&rdev->exclusive_lock); radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); @@ -1007,6 +1008,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) dev_info(rdev->dev, "GPU reset failed\n"); } + up_write(&rdev->exclusive_lock); return r; } diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index d9b0809..f99db63 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -215,12 +215,14 @@ int radeon_gem_create_ioctl(struct drm_device *dev, void *data, uint32_t handle; int r; + down_read(&rdev->exclusive_lock); /* create a gem object to contain this object in */ args->size = roundup(args->size, PAGE_SIZE); r = radeon_gem_object_create(rdev, args->size, args->alignment, args->initial_domain, false, false, &gobj); if (r) { + up_read(&rdev->exclusive_lock); r = radeon_gem_handle_lockup(rdev, r); return r; } @@ -228,10 +230,12 @@ int radeon_gem_create_ioctl(struct drm_device *dev, void *data, /* drop reference from allocate - handle holds it now */ drm_gem_object_unreference_unlocked(gobj); if (r) { + up_read(&rdev->exclusive_lock); r = radeon_gem_handle_lockup(rdev, r); return r; } args->handle = handle; + up_read(&rdev->exclusive_lock); return 0; } @@ -240,6 +244,7 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data, { /* transition the BO to a domain - * just validate the BO into a certain domain */ + struct radeon_device *rdev = dev->dev_private; struct drm_radeon_gem_set_domain *args = data; struct drm_gem_object *gobj; struct radeon_bo *robj; @@ -255,9 +260,11 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data, } robj = gem_to_radeon_bo(gobj); + down_read(&rdev->exclusive_lock); r = radeon_gem_set_domain(gobj, args->read_domains, args->write_domain); drm_gem_object_unreference_unlocked(gobj); + up_read(&rdev->exclusive_lock); r = radeon_gem_handle_lockup(robj->rdev, r); return r; } -- 1.7.10.2

3 9

[PATCH] drm/radeon: fix fence related segfault in CS
by Christian König 03 Jul '12

03 Jul '12

Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by: Christian König <deathsimple(a)vodafone.de> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 142f894..17238f4 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -377,7 +377,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev, if (r) { DRM_ERROR("Failed to schedule IB !\n"); } - return 0; + return r; } static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser, -- 1.7.9.5

2 1

[git pull] drm fixes
by Dave Airlie 03 Jul '12

03 Jul '12

Hi Linus, one regression fix, two radeon fixes (one for an oops), and an i915 fix to unload framebuffers earlier. We originally were going to leave the i915 fix until -next, but grub2 in some situations causes vesafb/efifb to be loaded now, and this causes big slowdowns, and I have reports in rawhide I'd like to have fixed. Dave. The following changes since commit 9acc7bde23ebb19a704395f76490685e1513e422: Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2012-06-28 12:38:51 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 9f846a16d213523fbe6daea17e20df6b8ac5a1e5: drm/i915: kick any firmware framebuffers before claiming the gtt (2012-07-03 11:18:48 +0100) ---------------------------------------------------------------- Alex Deucher (1): drm/radeon: fix VM page table setup on SI Daniel Vetter (1): drm/i915: kick any firmware framebuffers before claiming the gtt Jerome Glisse (1): drm/radeon: fix rare segfault Takashi Iwai (1): drm: edid: Don't add inferred modes with higher resolution drivers/gpu/drm/drm_edid.c | 27 ++++++++++++++++++++++--- drivers/gpu/drm/i915/i915_dma.c | 37 +++++++++++++++++++++++++++------- drivers/gpu/drm/radeon/radeon_gart.c | 13 ++++++++++-- drivers/gpu/drm/radeon/radeon_gem.c | 10 +++++---- drivers/gpu/drm/radeon/si.c | 4 ++-- 5 files changed, 73 insertions(+), 18 deletions(-)

1 0

[Bug 51594] New: opengl does not work with radeon 9600
by bugzilla-daemon＠freedesktop.org 03 Jul '12

03 Jul '12

https://bugs.freedesktop.org/show_bug.cgi?id=51594 Bug #: 51594 Summary: opengl does not work with radeon 9600 Classification: Unclassified Product: DRI Version: XOrg CVS Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: kevinbanjo(a)gmail.com I appear to be having this bug with a 15" powerbook g4 1.67ghz runnning mintppc 9.3 attempting to run sauerbraten https://bugs.freedesktop.org/show_bug.cgi?id=26496 X.Org X Server 1.7.7 mesa 7.7.1-5 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 (RV350 4E50) 20090101 AGP 4x PowerPC/Altivec TCL OpenGL version string: 1.5 Mesa 7.7.1 OpenGL extensions: GL_EXT_compiled_vertex_array, GL_EXT_texture_env_add, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_provoking_vertex, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_array_bgra, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays 8 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x68 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x69 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x6a 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x6b 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x6c 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x5f 32 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 Ncon 8 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x60 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x61 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x62 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x63 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x64 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x65 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x66 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x67 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow ---------------------------------- xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 10707000 X.Org version: 1.7.7 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x2000005, revert to Parent number of extensions: 28 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-DRI XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1280x854 pixels (338x225 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x6e depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0x7a003c ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 8 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x22 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x68 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x69 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6a class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6b class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x6c class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x5f class: TrueColor depth: 32 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2012