Re: [Bisected Regression in 2.6.32.8] i915 with KMS enabled causesmemory corruption when resuming from suspend-to-disk
On 13/03/10 03:05 PM, Rafael J. Wysocki wrote: On Saturday 13 March 2010, M. Vefa Bicakci wrote: Hello, As you can guess from the subject, I have noticed that enabling the KMS feature of the i915 module with any kernel version after 2.6.32.7 causes memory corruption after one resumes from suspend-to-disk. My hardware is a Toshiba Satellite A100, with an Intel graphics card. I am using an up-to-date version of Debian Sid. Here are the lspci entries for my graphics card: === 8 === 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller]) 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) === 8 === I have noticed that after upgrading from 2.6.32.7 to 2.6.32.9, I started to get a lot of segfaults from different programs when I resume from suspend-to-disk. After searching the Internet for this problem, I have seen that some other people also had it, and that it wasn't a new problem either: http://bbs.archlinux.org/viewtopic.php?id=91375 https://bugzilla.redhat.com/show_bug.cgi?id=537494 http://bugzilla.kernel.org/show_bug.cgi?id=13811 Even though some people say that they have had this problem for a long time, I have only noticed it after upgrading to 2.6.32.9. After booting with nomodeset and confirming that the problem doesn't happen with that kernel option, I have determined that the problem was with i915. Then I used the following command to bisect the changes that i915 has seen between 2.6.32.7 and 2.6.32.9: git bisect start v2.6.32.9 v2.6.32.7 -- ./drivers/gpu/drm/ With each iteration in the bisection, I have tried at least 3 cycles of suspend-to-disk and resume operations. I saw that all of the tried versions had memory corruption issues after resume from suspend-to-disk. Then, git told me that the culprit is the first change to i915 after the release 2.6.32.7. So 2.6.32.8 introduced the regression I am experiencing. Here's the git bisect log output: === 8 === # bad: [7f5e918e62cbc9ac27c2f47d3c3dd4b86f67ff0e] Linux 2.6.32.9 # good: [b4bdd73ce865213a5653dc424873e8da37e858cc] Linux 2.6.32.7 git bisect start 'v2.6.32.9' 'v2.6.32.7' '--' './drivers/gpu/drm/' # bad: [192ff23a2206eb5136c779bfed73171a4d214ad6] drm/i915: Add HP nx9020/SamsungSX20S to ACPI LID quirk list git bisect bad 192ff23a2206eb5136c779bfed73171a4d214ad6 # bad: [6240058ce3725f5e708e1c17c3a676217e44ba9b] drm/i915: disable hotplug detect before Ironlake CRT detect git bisect bad 6240058ce3725f5e708e1c17c3a676217e44ba9b # bad: [61d4374b51386dd40c03fd15df5a7f97347de688] drm/i915: Reload hangcheck timer too for Ironlake git bisect bad 61d4374b51386dd40c03fd15df5a7f97347de688 # bad: [d8e0902806c0bd2ccc4f6a267ff52565a3ec933b] drm/i915: Selectively enable self-reclaim git bisect bad d8e0902806c0bd2ccc4f6a267ff52565a3ec933b d8e0902806c0bd2ccc4f6a267ff52565a3ec933b is the first bad commit commit d8e0902806c0bd2ccc4f6a267ff52565a3ec933b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Jan 27 13:36:32 2010 + drm/i915: Selectively enable self-reclaim commit 4bdadb9785696439c6e2b3efe34aa76df1149c83 upstream. Having missed the ENOMEM return via i915_gem_fault(), there are probably other paths that I also missed. By not enabling NORETRY by default these paths can run the shrinker and take memory from the system (but not from our own inactive lists because our shrinker can not run whilst we hold the struct mutex) and this may allow the system to survive a little longer whilst our drivers consume all available memory. References: OOM killer unexpectedly called with kernel 2.6.32 http://bugzilla.kernel.org/show_bug.cgi?id=14933 v2: Pass gfp into page mapping. v3: Use new read_cache_page_gfp() instead of open-coding. ... === 8 === For the record, just to confirm that this commit is actually the culprit, I took a vanilla 2.6.32.9 source tree and reverted only this commit. I am happy to let you know that with this commit reverted, I can no longer reproduce the memory corruption issue. However, as I noted above, some people have had this problem for a longer time. So I am not sure if the commit above causes the bug or if it makes the bug easier to trigger. Finally, I would like to note that this regression is going to be important, because, as you know, Intel's X11 drivers are not going to support mode-setting in user mode starting with version 2.10.0. If there is any help I can provide in fixing this regression, please let me know. I am willing to try patches. If I remember correctly, this has been fixed in the mainline, but I don't remember the exact commit right now. Chris, Jesse, can you please help? Rafael Dear Rafael Wysocki, I am sorry for the
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote: Modularized dri drivers and an SDK enabled mesa tree are available in my personal git repos at http://cgit.freedesktop.org/~libv/ The SDK enabled mesa tree adds to the mesa build system to create shared libraries libmesadri and libmesadricommon. It creates the relevant .pc files and installs the necessary headers include/mesa/ (and updates glcore.h). The patch is about 300 lines each time, and only adjusts the build system. The modularized drivers are fully autotooled and can be built and installed the familiar way once the dependencies are available (currently, libdrm and the dri sdk, and some driver specific libdrms for i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx and unichrome. This work was done for currently 16 versions between mesa 7.0 and the freshly tagged 7.8-rc1, all were extensively and oft repeatedly built through. 5 versions were also run tested (glxinfo, glxgears) for the radeon and unichrome drivers, and the swrast driver was also tested several times. Such a large range of versions was handled to prove the long term feasability of this. This work satisfies my requirements from my TODO: Mesa slide from my fosdem talk, for which the slides are available at: http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$ This only handles the DRI part of things, gallium seems to be more in flux atm, and from what i hear, it should be easier to have modular drivers there. Comments, additions, changes? Thanks, Luc Verhaegen. After giving the mesa3d-dev list the opportunity to have a whole day of deafening silence, maybe the other lists should join in on that fun :p Hey Luc, Wow. This is pretty nifty. Lots of work here, obviously. I do have a couple of questions, though: ~) Did you know about or use the automake branch that Eric and I have had floating around for a while? ~) Do you think it's gonna be tenable to ship the drivers with lots of shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like we might run into the situation we've got right now with the X server and DDX drivers, where it might be easier to move some drivers back in. Also (warning: sore subject!) it reminds me of the mesa/drm tree and the same problems with keeping code in two locations... Maybe that's just me. As far as Gallium goes, I really wouldn't worry about it. From what I can tell, the people that actually care about header stability have been using really specific versions of the interface in their own shipped bundles, and there's far too much mainline work going on right now to really even attempt this kind of splitting. I think there's a total of five branches right now that will change the entire Gallium interface, all getting prepared for merge? Lots of churn. Gallium's all mix'n'match though, so it shouldn't be a big deal further down the road. Sorry for not speaking up sooner; it's finals week and my attention to every single email in my box is rather limited. :3 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 04:27 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
2010/3/17 Rafał Miłecki zaj...@gmail.com:
2010/3/17 Alex Deucher alexdeuc...@gmail.com
Another set of updated patches against drm-radeon-testing:
http://people.freedesktop.org/~agd5f/pm2/
These implement much the remaining pm functionality. So far they are
working well here.
these patches add:
- memory reclocking
- pcie lane changes
- update display watermarks as bandwidth changes
- allow power management with multi-head
- reset power mode on exit
It seems memory reclocking and SIMDs setting is disabled for r6xx with
currently available patches...?
It re-clocks memory (for single head anyway), r600_set_power_state():
/* set memory clock */
if (rdev-asic-set_memory_clock (mclk !=
rdev-pm.current_mclk)) {
radeon_sync_with_vblank(rdev);
radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_memory_clock(rdev, mclk);
radeon_pm_debug_check_in_vbl(rdev, true);
rdev-pm.current_mclk = mclk;
DRM_INFO(Setting: m: %d\n, mclk);
}
The simd stuff is still disabled at the moment.
Whoops, I missed one patch. My mistake.
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] arch/x86: Add array variants for setting memory to wc caching.
On Thu, Mar 18, 2010 at 1:52 AM, Dave Airlie airl...@gmail.com wrote:
On Thu, Mar 18, 2010 at 6:50 AM, Pauli Nieminen suok...@gmail.com wrote:
Setting single memory pages at a time to wc takes a lot time in cache flush.
To
reduce number of cache flush set_pages_array_wc and set_memory_array_wc can
be
used to set multiple pages to WC with single cache flush.
I don't think this is correct, I've cc'ed Suresh and Venki who looked
at this before,
but I think there is an array in the x86 code that stores the state
and it only has a
single bit in it, it needs to be expanded in order to at WC support.
Dave.
This worked for me but there might be some hw specific cases when it
doesn't work. (all page act like wc cached ones when running memcpy
test on gtt bo)
This is only minor improvemnet for corner cases. Pool refills general
don't happen in normal use except for 3D. For others cases number of
pages was fairly static so pool code can avoid refills. Of course
there might be some corner case that I didn't know to test.
Even for them pool refills happened about once a second in average.
But allocation were happening in small bursts so this should avoid
frame rate hit in case of a lot of allocation in very short time.
This improves allocation performance for wc cached pages in drm/ttm.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
arch/x86/include/asm/cacheflush.h | 2 +
arch/x86/mm/pageattr.c | 53
+++-
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/cacheflush.h
b/arch/x86/include/asm/cacheflush.h
index 634c40a..d92d63a 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -139,9 +139,11 @@ int set_memory_np(unsigned long addr, int numpages);
int set_memory_4k(unsigned long addr, int numpages);
int set_memory_array_uc(unsigned long *addr, int addrinarray);
+int set_memory_array_wc(unsigned long *addr, int addrinarray);
int set_memory_array_wb(unsigned long *addr, int addrinarray);
int set_pages_array_uc(struct page **pages, int addrinarray);
+int set_pages_array_wc(struct page **pages, int addrinarray);
int set_pages_array_wb(struct page **pages, int addrinarray);
/*
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index cf07c26..0c98a75 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -997,7 +997,8 @@ out_err:
}
EXPORT_SYMBOL(set_memory_uc);
-int set_memory_array_uc(unsigned long *addr, int addrinarray)
+int _set_memory_array(unsigned long *addr, int addrinarray,
+ unsigned long new_type)
{
int i, j;
int ret;
@@ -1007,13 +1008,19 @@ int set_memory_array_uc(unsigned long *addr, int
addrinarray)
*/
for (i = 0; i addrinarray; i++) {
ret = reserve_memtype(__pa(addr[i]), __pa(addr[i]) +
PAGE_SIZE,
- _PAGE_CACHE_UC_MINUS, NULL);
+ new_type, NULL);
if (ret)
goto out_free;
}
ret = change_page_attr_set(addr, addrinarray,
__pgprot(_PAGE_CACHE_UC_MINUS), 1);
+
+ if (!ret new_type == _PAGE_CACHE_WC)
+ ret = change_page_attr_set_clr(addr, addrinarray,
+ __pgprot(_PAGE_CACHE_WC),
+ __pgprot(_PAGE_CACHE_MASK),
+ 0, CPA_ARRAY, NULL);
if (ret)
goto out_free;
@@ -1025,8 +1032,19 @@ out_free:
return ret;
}
+
+int set_memory_array_uc(unsigned long *addr, int addrinarray)
+{
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_UC_MINUS);
+}
EXPORT_SYMBOL(set_memory_array_uc);
+int set_memory_array_wc(unsigned long *addr, int addrinarray)
+{
+ return _set_memory_array(addr, addrinarray, _PAGE_CACHE_WC);
+}
+EXPORT_SYMBOL(set_memory_array_wc);
+
int _set_memory_wc(unsigned long addr, int numpages)
{
int ret;
@@ -1153,26 +1171,34 @@ int set_pages_uc(struct page *page, int numpages)
}
EXPORT_SYMBOL(set_pages_uc);
-int set_pages_array_uc(struct page **pages, int addrinarray)
+static int _set_pages_array(struct page **pages, int addrinarray,
+ unsigned long new_type)
{
unsigned long start;
unsigned long end;
int i;
int free_idx;
+ int ret;
for (i = 0; i addrinarray; i++) {
if (PageHighMem(pages[i]))
continue;
start = page_to_pfn(pages[i]) PAGE_SHIFT;
end = start + PAGE_SIZE;
- if (reserve_memtype(start, end, _PAGE_CACHE_UC_MINUS, NULL))
+ if (reserve_memtype(start, end, new_type, NULL))
goto err_out;
}
- if
Re: [PATCHES] radeon kms pm patches
Hi, the last days I am testing Alex's pm2-patches with Linus-tree - this report based on patchset as of 17-Mar-2010 22:42 [0]. Unfortunately, I cannot load radeon kernel-module with dynpm=1 (0 = disabled works fine). All testing was done in init-3 in a virtual-console. Looking into the log-files show (a) regression(s). I have prepared patches against Linux-2.6.34-rc1 [1] and also attached logs in [2]. The agdf5-pm2-with-linustree.tar.bz2 tarball contains all data (see [3]). Have fun. Kind Regards, - Sedat - References: -- [0] http://people.freedesktop.org/~agd5f/pm2/ [1] http://files.iniza.org/agdf5-pm2-with-linustree/patches/ [2] http://files.iniza.org/agdf5-pm2-with-linustree/logs/ [3] http://files.iniza.org/agdf5-pm2-with-linustree/archive/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
[1] shows: ... Mar 18 10:07:35 seduxbox kernel: [ 127.005632] [drm:r500_hw_i2c_xfer], i2c write error 0x0002 ... - Sedat - [1] http://files.iniza.org/agdf5-pm2-with-linustree/logs/debug.txt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Return ENODEV if the inode mapping changes
Replace a BUG_ON with an error code in the event that the inode mapping
changes between calls to drm_open. This may happen for instance if udev
is loaded subsequent to the original opening of the device:
[ 644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146!
[ 644.291876] invalid opcode: [#1] SMP
[ 644.291882] last sysfs file: /sys/kernel/uevent_seqnum
[ 644.291888]
[ 644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2
N150/N210/N220 /N150/N210/N220
[ 644.291903] EIP: 0060:[c11c70e3] EFLAGS: 00210283 CPU: 0
[ 644.291912] EIP is at drm_open+0x4b1/0x4e2
[ 644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX:
[ 644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc
[ 644.291929] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80
task.ti=f647a000)
[ 644.291941] Stack:
[ 644.291945] f7bb7400 0080 f6451100 f73176b8 f6479214 f6451100
f73176b8
[ 644.291957] 0 c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800
f647ae54 c1080ac5
[ 644.291969] 0 f7949800 f6451100 f6451100 f73176b8 f6452780
f647ae70 c107d1e6
[ 644.291982] Call Trace:
[ 644.291991] [c11c6c04] ? drm_stub_open+0x8a/0xb8
[ 644.292000] [c1080ac5] ? chrdev_open+0xef/0x106
[ 644.292008] [c107d1e6] ? __dentry_open+0xd4/0x1a6
[ 644.292015] [c107d35b] ? nameidata_to_filp+0x31/0x45
[ 644.292022] [c10809d6] ? chrdev_open+0x0/0x106
[ 644.292030] [c10864e2] ? do_last+0x346/0x423
[ 644.292037] [c108789f] ? do_filp_open+0x190/0x415
[ 644.292046] [c1071eb5] ? handle_mm_fault+0x214/0x710
[ 644.292053] [c107d008] ? do_sys_open+0x4d/0xe9
[ 644.292061] [c1016462] ? do_page_fault+0x211/0x23f
[ 644.292068] [c107d0f0] ? sys_open+0x23/0x2b
[ 644.292075] [c1002650] ? sysenter_do_call+0x12/0x26
[ 644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04
01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 0f 0b
eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0
[ 644.292143] EIP: [c11c70e3] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc
[ 644.292175] ---[ end trace 2ddd476af89a60fa ]---
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fops.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 08d14df..4804872 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -140,14 +140,16 @@ int drm_open(struct inode *inode, struct file *filp)
spin_unlock(dev-count_lock);
}
out:
- mutex_lock(dev-struct_mutex);
- if (minor-type == DRM_MINOR_LEGACY) {
- BUG_ON((dev-dev_mapping != NULL)
- (dev-dev_mapping != inode-i_mapping));
- if (dev-dev_mapping == NULL)
- dev-dev_mapping = inode-i_mapping;
+ if (!retcode) {
+ mutex_lock(dev-struct_mutex);
+ if (minor-type == DRM_MINOR_LEGACY) {
+ if (dev-dev_mapping == NULL)
+ dev-dev_mapping = inode-i_mapping;
+ else if (dev-dev_mapping != inode-i_mapping)
+ retcode = -ENODEV;
+ }
+ mutex_unlock(dev-struct_mutex);
}
- mutex_unlock(dev-struct_mutex);
return retcode;
}
--
1.7.0
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Hi, hereby my new experiences with my RV515. # lspci -nnvv | grep VGA compatible controller 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M52 [Mobility Radeon X1300] [1002:714a] (prog-if 00 [VGA controller]) I applied [PATCH] drm/radeon/kms: add hw_i2c module option from [1] in addition to pm2-patches (see my last email) and rebuild radeon kernel-module: $ cd $build-dir $ make M=drivers/gpu/drm/radeon clean $ apply_patch $ make M=drivers/gpu/drm/radeon We have now a new module-option hw_i2c (0 = disabled, 1 = enabled), This requires to re-generate modules.dep and map files: # depmod Then I rebooted to check new radeon kernel-module. [init-3] # modprobe -r -v radeon # modprobe -v radeon modeset=1 dynpm=1 hw_i2c=1 That is working - no blank screen. But [2] shows also same error when there is a failure (does this error really matter?): ... Mar 18 11:56:40 seduxbox kernel: [ 62.350145] [drm:r500_hw_i2c_xfer], i2c write error 0x0002 ... Reclocking seems to work (see below) - when I start glxgears and let in run a while you see increasing e: X m: Y - closing glxgears results in downclocking. I will check if starting and closing OpenArena (Anholt benchmark) will result in a blank screen (but this was yesterday). Kind Regards, - Sedat - References: -- [1] http://marc.info/?l=dri-develm=126880645519474w=2 [2] http://files.iniza.org/agdf5-pm2-with-linustree/logs/debug_ok.txt - INVESTIGATIONS - [ 2213.179060] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2213.602308] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2213.621661] [drm] Setting: e: 21000 [ 2214.021304] [drm] Requested: e: 32400 m: 13500 p: 16 [ 2214.046572] [drm] Setting: e: 32400 [ 2214.446302] [drm] Requested: e: 39200 m: 3 p: 16 [ 2214.465277] [drm] Setting: e: 39200 [ 2214.465848] [drm] not in vbl for pm change 00020002 at entry [ 2214.468161] [drm] not in vbl for pm change 00020002 at exit [ 2214.468166] [drm] Setting: m: 3 [ 2214.868305] [drm] Requested: e: 39200 m: 3 p: 16 [ 2235.680072] [drm] Requested: e: 32400 m: 13500 p: 16 [ 2235.680281] [drm] Setting: e: 32400 [ 2235.690389] [drm] not in vbl for pm change 00020002 at entry [ 2235.692412] [drm] not in vbl for pm change 00020002 at exit [ 2235.692417] [drm] Setting: m: 13500 [ 2236.092069] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2236.092105] [drm] GUI not idle!!! [ 2236.492071] [drm] Requested: e: 21000 m: 13500 p: 16 [ 2236.492249] [drm] Setting: e: 21000 [ 2237.292060] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2237.292250] [drm] Setting: e: 12900 [ 2237.692070] [drm] Requested: e: 12900 m: 13500 p: 16 [ 2238.092068] [drm] Requested: e: 12900 m: 13500 p: 16 - EOT - -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
Experiences (II) - OpenArena Mostly, I am using radeon Gallium3D driver r300g dri/statetracker. Here I can start openarena (OA) but entering fight-mode closes OA immediately. There seems to be a problem in mesa master GIT branch. commit 9d48a621d2a0e55a76a2cfd0aea3b773e907ed50 llvmpipe: Fix crashes when there is no depth buffer bound. OA is playable with classic mesa (KMS/DRI2). After Anholt's OA benchmark is finished - I get a blank screen. Log-file see [1]. - Sedat - [1] http://files.iniza.org/agdf5-pm2-with-linustree/logs/dmesg_openarena-r300classic.txt -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25315] Mesa demos/gltestperf hard hangs the system
http://bugs.freedesktop.org/show_bug.cgi?id=25315 samit vats hysv...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25011] Terminal window does not filling up the complete desktop screen on rotation in dual monitor mode.
http://bugs.freedesktop.org/show_bug.cgi?id=25011 samit vats hysv...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 samit vats hysv...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from samit vats hysv...@gmail.com 2010-03-18 06:25:50 PST --- (In reply to comment #4) Does this still happen with newer versions of mesa? 7.6.1 or 7.7 or git master? The issue is fixed in the latest Driver build with Mesa version 7.8-devel and Ubuntu-9.10 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24105] System Hangs while Running SpecViewPerf10
http://bugs.freedesktop.org/show_bug.cgi?id=24105 samit vats hysv...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20176] [Wine Application Issue]: X hangs after coming out of game
http://bugs.freedesktop.org/show_bug.cgi?id=20176 samit vats hysv...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27141] piglit glean/vertProg1 core dumps with RV790
http://bugs.freedesktop.org/show_bug.cgi?id=27141 --- Comment #2 from Chris Rankin ranki...@googlemail.com 2010-03-18 07:47:02 PST --- The problem happens when destroying the GLContext: - we call _mesa_free_context_data(), which sets ctx-DrawBuffer = NULL - _mesa_free_context_data() then calls _mesa_free_texture_data() - _mesa_free_texture_data() calls r600DeleteTexture() - r600DeleteTexture() calls radeonFlush() via radeon_firevertices() - radeonFlush() tries to dereference ctx-DrawBuffer, which has just been set to NULL - BANG! Adding a simple (ctx-DrawBuffer != NULL) check to radeonFlush() makes 43 of the vertProg1 piglit tests pass, with 2 failures: Program: RSQ test 2 (reciprocal square root of negative value) Expected color: -1, 0.1, 0.447, 1 Observed color: 0, 0, 0, 0 Program: LIT test 2 (degenerate case: 0 ^ 0 - 1) Expected color: 1, 0.65, 1, 1 Observed color: 1, 0.65098, 0, 1 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26635] [drm-radeon-testing] warning message that can't be true
http://bugs.freedesktop.org/show_bug.cgi?id=26635 Florian Scandella f...@chilicode.com changed: What|Removed |Added CC||f...@chilicode.com --- Comment #1 from Florian Scandella f...@chilicode.com 2010-03-18 08:17:06 PST --- same here ... although using mesa 7.8 branch .. i get this warning with .33 + drm-linus (from 2 weeks ago) too. 03:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850] also, with .33.1 + testing i get lots of reserve failed for wait messages .. maybe this is connected? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRI SDK and modularized drivers.
On Thu, Mar 18, 2010 at 01:28:28AM -0700, Corbin Simpson wrote: On Wed, Mar 17, 2010 at 6:13 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Mar 17, 2010 at 12:28:39AM +0100, Luc Verhaegen wrote: Modularized dri drivers and an SDK enabled mesa tree are available in my personal git repos at http://cgit.freedesktop.org/~libv/ The SDK enabled mesa tree adds to the mesa build system to create shared libraries libmesadri and libmesadricommon. It creates the relevant .pc files and installs the necessary headers include/mesa/ (and updates glcore.h). The patch is about 300 lines each time, and only adjusts the build system. The modularized drivers are fully autotooled and can be built and installed the familiar way once the dependencies are available (currently, libdrm and the dri sdk, and some driver specific libdrms for i9xx and radeon). These drivers are i810, i9xx (i915 and i965), mach64, mga, r128, radeon (also includes r200, r300 and r600), savage, sis, tdfx and unichrome. This work was done for currently 16 versions between mesa 7.0 and the freshly tagged 7.8-rc1, all were extensively and oft repeatedly built through. 5 versions were also run tested (glxinfo, glxgears) for the radeon and unichrome drivers, and the swrast driver was also tested several times. Such a large range of versions was handled to prove the long term feasability of this. This work satisfies my requirements from my TODO: Mesa slide from my fosdem talk, for which the slides are available at: http://people.freedesktop.org/~libv/graphics_driver_stack_(FOSDEM2010_-_slides)$ This only handles the DRI part of things, gallium seems to be more in flux atm, and from what i hear, it should be easier to have modular drivers there. Comments, additions, changes? Thanks, Luc Verhaegen. After giving the mesa3d-dev list the opportunity to have a whole day of deafening silence, maybe the other lists should join in on that fun :p Hey Luc, Wow. This is pretty nifty. Lots of work here, obviously. I do have a couple of questions, though: ~) Did you know about or use the automake branch that Eric and I have had floating around for a while? Nope, didn't know about those, is this in your personal git repos? ~) Do you think it's gonna be tenable to ship the drivers with lots of shared code (i915/i965, radeon/r200/r300/r600) like this? Seems like we might run into the situation we've got right now with the X server and DDX drivers, where it might be easier to move some drivers back in. Also (warning: sore subject!) it reminds me of the mesa/drm tree and the same problems with keeping code in two locations... Maybe that's just me. The goal is to solve the dependency nightmare between the driver specific drm, libdrm, mesa and x parts. The hot and highly volatile interfaces are between the driver specific parts, as of course, developers making changes there only have to update parts of their own driver. So, identify the volatile interfaces, and the more stable interfaces, and then isolate the volatile ones, and then you come to only one conclusion. And currently the really hot interfaces are in the intel and radeon stacks, and without making any changes, we are quickly converging to a situation where the linux kernel, libdrm, xserver and mesa are 1-1 version tied. This means that if you update anything you pretty much have to update most of your installation, a situation no-one wants, and a situation which will be highly detrimental for the linux desktop. It either leads to throw-away installations (where you have to be lucky, or need to have especially backported bits, like in preloads, to be able to get things to work), or no graphics at all. And i am sure that that is not where linux should be headed, especially not when it can be solved this neatly and cleanly. As far as Gallium goes, I really wouldn't worry about it. From what I can tell, the people that actually care about header stability have been using really specific versions of the interface in their own shipped bundles, and there's far too much mainline work going on right now to really even attempt this kind of splitting. I think there's a total of five branches right now that will change the entire Gallium interface, all getting prepared for merge? Lots of churn. Gallium's all mix'n'match though, so it shouldn't be a big deal further down the road. While it probably is not that feasible right now, the people moving those interfaces that much atm should keep future modularization in mind. A nice example: If you disable building gallium (as all the drivers are still in there) and building the dri drivers (also through configure), then you can easily build mesa with libdrm 2.3.0. The xserver, with already modular xf86 drivers has exactly libdrm 2.3.0 in its configure.ac requirements. Surely this is a sign that modularizing the driver bits and posssibly (as it is
Re: [PATCHES] radeon kms pm patches
2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCHES] radeon kms pm patches
W dniu 18 marca 2010 17:40 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/3/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 marca 2010 10:05 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Whoops, I missed one patch. My mistake. I've just applied all patches dated as 17-Mar-2010 22:42 and tested. Now memory reclocking is really enabled, but it causes corruptions for me. Maybe that's the same thing you experienced with dual head? Video is *far* from perfect, but maybe will give you some idea of what do I experience: http://estudent.put.poznan.pl/rafal.milecki/kernel/MOV00225.MP4 The same happened for me before all your patches, when I tried to enable memory reclocking on my own. yeah, the similar to what I saw with dualhead. I guess we are either missing the vblank window or the reclock is taking too much time. I wonder if it would make sense to wait for a vline rather than vblank, say a vline 1/2 or 2/3 of the way down the screen, to give us some buffer time between calling the reclock function and whatever setup it does and the beginning of the actual vblank period. If you suspect too slow resuming reclokcing context you can try tricks from: http://marc.info/?l=linux-kernelm=126730151530139w=2 It's about setting higher priority for reclocking context or switching to busy waiting. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27173] New: r600 wierdness with shaders for blur effect in compiz
http://bugs.freedesktop.org/show_bug.cgi?id=27173 Summary: r600 wierdness with shaders for blur effect in compiz Product: DRI Version: XOrg CVS Platform: x86 (IA32) URL: http://klone.anirev.net/blurwierdness.png OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: revell...@gmail.com When using the r600_dri driver with an AMD Radeon 3650. (identified in Xorg.0.log as. (--) RADEON(0): Chipset: ATI Radeon HD 3600 XT (ChipID = 0x9598) The areas that should be blurred due to alpha consists of some parts of the windows content but twisted in colors and orientation of the content. and in some areas like the pidgin window on the far-left the content is stretched. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27173] r600 wierdness with shaders for blur effect in compiz
http://bugs.freedesktop.org/show_bug.cgi?id=27173 --- Comment #1 from Kristoffer Tangfelt revell...@gmail.com 2010-03-18 10:14:38 PST --- Created an attachment (id=34211) -- (http://bugs.freedesktop.org/attachment.cgi?id=34211) attached file of the wierd rendering. incase the hosted one is unreliable or can't be reached. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27179] New: Slight various between software and r600 results in tri and wave in progs/samples
http://bugs.freedesktop.org/show_bug.cgi?id=27179 Summary: Slight various between software and r600 results in tri and wave in progs/samples Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: kdeko...@yahoo.com Created an attachment (id=34212) -- (http://bugs.freedesktop.org/attachment.cgi?id=34212) software on left, hardware on right I ran the progs/samples/tri and progs/samples/wave mesa examples in software and hardware mode and found a few problems. I have attached and image where software mode is on the left and hardware mode is on the right. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] arch/x86: Add array variants for setting memory to wc caching.
On Thu, Mar 18, 2010 at 9:29 PM, Suresh Siddha suresh.b.sid...@intel.com wrote: On Thu, 2010-03-18 at 02:41 -0700, Pauli Nieminen wrote: On Thu, Mar 18, 2010 at 1:52 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Mar 18, 2010 at 6:50 AM, Pauli Nieminen suok...@gmail.com wrote: Setting single memory pages at a time to wc takes a lot time in cache flush. To reduce number of cache flush set_pages_array_wc and set_memory_array_wc can be used to set multiple pages to WC with single cache flush. I don't think this is correct, I've cc'ed Suresh and Venki who looked at this before, but I think there is an array in the x86 code that stores the state and it only has a single bit in it, it needs to be expanded in order to at WC support. hmm, I thought we had the array variants for the WC already. I don't think there is any explicit reason for not having it. Correcting Venki's address, to see if he has anything to add. + ret = cpa_set_pages_array(pages, addrinarray, + __pgprot(_PAGE_CACHE_UC_MINUS)); + if (!ret new_type == _PAGE_CACHE_WC) + ret = change_page_attr_set_clr(NULL, addrinarray, + __pgprot(_PAGE_CACHE_WC), + __pgprot(_PAGE_CACHE_MASK), + 0, CPA_PAGES_ARRAY, pages); Pauli, Is there any reason for not using cpa_set_pages_array() here aswell? cpa_set_pages_array is setting mask parameter to zero while _set_memory_wc is passing the mask parameter. I didn't look deep enough to the code to know why _set_memory_wc works that way. thanks, suresh -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27141] piglit glean/vertProg1 core dumps with RV790
http://bugs.freedesktop.org/show_bug.cgi?id=27141 --- Comment #3 from Pauli suok...@gmail.com 2010-03-18 12:28:50 PST --- Patches are welcome :) You can send the fix to mesa3d-...@lists.sourceforge.net. git commands format-patch and send-email are very easy tools to send patches to the mailing list. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27141] piglit glean/vertProg1 core dumps with RV790
http://bugs.freedesktop.org/show_bug.cgi?id=27141 --- Comment #4 from Chris Rankin ranki...@googlemail.com 2010-03-18 12:38:07 PST --- (In reply to comment #3) Patches are welcome :) Actually, I would describe this as the cause rather than the fix. I was hoping that someone who understands what the code *should* be doing would step in at this point. Maybe Mesa shouldn't be calling radeonFlush() in the first place here? Or maybe ctx-DrawBuffer shouldn't be unreferenced so early in the clean-up sequence? I have no intention of papering over this bug with an off-hand NULL check at this stage. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27148] Failed assertion in piglit test 'bin/fbo-flushing -auto' with RV790
http://bugs.freedesktop.org/show_bug.cgi?id=27148 --- Comment #1 from Chris Rankin ranki...@googlemail.com 2010-03-18 13:18:17 PST --- This test is failing for r600_dri.so because glCheckFramebufferStatusEXT() is returning GL_FRAMEBUFFER_UNSUPPORTED. The reason that it returns GL_FRAMEBUFFER_UNSUPPORTED is because the radeonIsFormatRenderable() function in radeon_texture.c seems only to understand the following formats: - MESA_FORMAT_Z16 - MESA_FORMAT_S8_Z24 - _dri_texformat_argb - _dri_texformat_rgb565 - _dri_texformat_argb1555 - _dri_texformat_argb This is _considerably_ fewer than the number of formats listed in r300IsFormatRenderable(). For reference, the piglit test needs MESA_FORMAT_RGBA_REV. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27142] piglit glean/pbo -o -v test dumps core
http://bugs.freedesktop.org/show_bug.cgi?id=27142 --- Comment #1 from Chris Rankin ranki...@googlemail.com 2010-03-18 13:38:56 PST --- This test is failing in these following statements from glean/tpbo.cpp: glGenBuffersARB_func(1, pb_pack); glBindBufferARB_func(GL_PIXEL_PACK_BUFFER_ARB, pb_pack[0]); glBufferDataARB_func(GL_PIXEL_PACK_BUFFER_ARB, windowSize * windowSize * 4 * sizeof(GL_UNSIGNED_BYTE), NULL, GL_STREAM_DRAW); glReadPixels(0, 0, windowSize, windowSize, GL_BGRA, GL_UNSIGNED_BYTE, NULL); I am assuming that glReadPixels() is expected to write into a named buffer object rather than a user-supplied buffer, because its final data parameter is NULL. However, r600_dri.so tries to write into the data parameter anyway. Hence BANG. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25179] File radeon_dma.c function radeonReleaseDmaRegions line 348 - Leaking dma buffer object!
http://bugs.freedesktop.org/show_bug.cgi?id=25179 --- Comment #5 from Kai deb...@carbon-project.org 2010-03-18 14:33:43 PST --- With the advent of 2.6.33(.1) I've switched to KMS and since then I can't reproduce this problem anymore (at least not so far). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] arch/x86: Add array variants for setting memory to wc caching.
On Thu, 2010-03-18 at 02:41 -0700, Pauli Nieminen wrote: On Thu, Mar 18, 2010 at 1:52 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Mar 18, 2010 at 6:50 AM, Pauli Nieminen suok...@gmail.com wrote: Setting single memory pages at a time to wc takes a lot time in cache flush. To reduce number of cache flush set_pages_array_wc and set_memory_array_wc can be used to set multiple pages to WC with single cache flush. I don't think this is correct, I've cc'ed Suresh and Venki who looked at this before, but I think there is an array in the x86 code that stores the state and it only has a single bit in it, it needs to be expanded in order to at WC support. hmm, I thought we had the array variants for the WC already. I don't think there is any explicit reason for not having it. Correcting Venki's address, to see if he has anything to add. + ret = cpa_set_pages_array(pages, addrinarray, + __pgprot(_PAGE_CACHE_UC_MINUS)); + if (!ret new_type == _PAGE_CACHE_WC) + ret = change_page_attr_set_clr(NULL, addrinarray, + __pgprot(_PAGE_CACHE_WC), + __pgprot(_PAGE_CACHE_MASK), + 0, CPA_PAGES_ARRAY, pages); Pauli, Is there any reason for not using cpa_set_pages_array() here aswell? thanks, suresh -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27144] piglit glean/depthStencil test core dumps with RV790
http://bugs.freedesktop.org/show_bug.cgi?id=27144
--- Comment #1 from Chris Rankin ranki...@googlemail.com 2010-03-18 16:51:10
PST ---
I don't understand the why on this one, just that the SIGSEGV happens within
the following WRITE_DEPTH macro:
#define WRITE_DEPTH( _x, _y, d )\
do {\
GLuint *_ptr = (GLuint*)r600_ptr_depth( rrb, _x + x_off, _y + y_off );
\
GLuint tmp = *_ptr; \
tmp = 0xff00; \
tmp |= ((d) 0x00ff); \
*_ptr = tmp; \
_ptr = (GLuint*)r600_ptr_stencil(rrb, _x + x_off, _y + y_off);
\
tmp = *_ptr; \
tmp = 0xff00; \
tmp |= ((d) 24) 0xff; \
*_ptr = tmp; \
} while (0)
The exact location seems to be the second line, where the contents of _ptr are
assigned to GLuint tmp. In my particular example, _x = 640, _y = 971 and d = 0
when it explodes.
It might be worth noting that this is an x86_64 machine, although it's
definitely SIGSEGV and not SIGBUS.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] HDMI clean DCE32 support
2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Is there any chance we could get these updates included in the drm-radeon-testing branch? Cheers Mike -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|2 ++
drivers/gpu/drm/radeon/radeon_object.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 72ed251..69585bb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -238,7 +238,9 @@ struct radeon_bo {
struct list_headlist;
/* Protected by tbo.reserved */
u32 placements[3];
+ u32 busy_placements[3];
struct ttm_placementplacement;
+ struct ttm_placementbusy_placement;
struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
unsignedpin_count;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index fc9d00a..3580c75 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -65,15 +65,19 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object
*bo)
void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
{
- u32 c = 0;
+ u32 c = 0, b = 0;
rbo-placement.fpfn = 0;
rbo-placement.lpfn = 0;
rbo-placement.placement = rbo-placements;
- rbo-placement.busy_placement = rbo-placements;
+ rbo-placement.busy_placement = rbo-busy_placements;
if (domain RADEON_GEM_DOMAIN_VRAM)
rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_VRAM;
+ /* add busy placement to TTM if VRAM is only option */
+ if (domain == RADEON_GEM_DOMAIN_VRAM) {
+ rbo-busy_placements[b++] = TTM_PL_MASK_CACHING |
TTM_PL_FLAG_TT;
+ }
if (domain RADEON_GEM_DOMAIN_GTT)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
if (domain RADEON_GEM_DOMAIN_CPU)
@@ -81,7 +85,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo,
u32 domain)
if (!c)
rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo-placement.num_placement = c;
- rbo-placement.num_busy_placement = c;
+ rbo-placement.num_busy_placement = b;
}
int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: don't print error on -ERESTARTSYS.
From: Dave Airlie airl...@redhat.com
We can get this if the user moves the mouse when we are waiting to move
some stuff around in the validate. Don't fail.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_cs.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8d99f70..3346d9e 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -239,7 +239,8 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
}
r = radeon_cs_parser_relocs(parser);
if (r) {
- DRM_ERROR(Failed to parse relocation !\n);
+ if (r != -ERESTARTSYS)
+ DRM_ERROR(Failed to parse relocation %d!\n, r);
radeon_cs_parser_fini(parser, r);
mutex_unlock(rdev-cs_mutex);
return r;
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] HDMI clean DCE32 support
On Fri, Mar 19, 2010 at 10:14 AM, Mike Lothian m...@fireburn.co.uk wrote: 2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Is there any chance we could get these updates included in the drm-radeon-testing branch? Should all be in there for a week or so. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
