FirePro W600 does not work with more than 4 monitors,
After 5th monitor attached X acting very slow.
Or if I call drmModeSetCrtc function 5 times one time for each of the monitors, it failing out
Andrey
https://bugs.freedesktop.org/show_bug.cgi?id=79649
Priority: medium
Bug ID: 79649
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [PATCH RFC] r300/compiler: recursive look for
RC_OPCODE_S**
Severity: normal
Classification: Unclassified
OS: All
Reporter: david.heidelberger(a)ixit.cz
Hardware: Other
Status: NEW
Version: git
Component: Drivers/…
[View More]Gallium/r300
Product: Mesa
Created attachment 100416
--> https://bugs.freedesktop.org/attachment.cgi?id=100416&action=edit
0001-r300-compiler-recursive-look-for-RC_OPCODE_S.patch
Get rid of error "Failed to build loop info" by fixing failure in cases
like
4: SGE temp[2].x, temp[0].xxxx, const[0].wwww;
5: CMP temp[1].x, -temp[2].xxxx, const[0].zzzz, temp[1].xxxx;
6: IF temp[1].xxxx;
On RS690
- fixes piglit glean "do-loop with continue and break"
- changes error from Failed to build loop info ->
Not a native swizzle: 00000e89
r300_fragprog_emit.c::begin_tex(): Too many texture indirections
for "discard statement in for loop"
- hide Failed to build loop info for
"precision log2", "while-loop with continue",
"for-loop with continue" and return "1 1 1 1" insted of "0 0 0 1"
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=83731
Bug ID: 83731
Summary: dpm still not working on radeon TURKS 1002:6840
Product: Drivers
Version: 2.5
Kernel Version: 3.17-rc
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
…
[View More]Reporter: giancarlo.formicuccia(a)gmail.com
Regression: No
Created attachment 149011
--> https://bugzilla.kernel.org/attachment.cgi?id=149011&action=edit
kernel messages with dpm enabled
Now that dpm is enabled by default on TURKS cards, I'd like to give another try
to get it working on my card.
Booting a 3.17-rc3 kernel results in a blank screen; the computer is not locked
up, I still can ssh into the machine and grab the kernel messages.
lspci reports:
01:00.0 0300: 1002:6840 (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel driver in use: radeon
Kernel modules: radeon
01:00.1 0403: 1002:aa90 (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: snd_hda_intel
Loading the radeon module with dpm=0 works without problems.
Note that dpm *did* work correctly until 3.13 kernels (using dpm=1); then it
broke during the 3.14 delopement cycle. I bisected the bad commit in
6c7bccea390853bdec5b76fe31fc50f3b36f75d5
drm/radeon/pm: move pm handling into the asic specific code
and reported the problem on the dri-devel ml, without luck.
My guess is that something changed during the initialization of the card which
is confusing this GPU, but I was unable to identify the problem by myself.
Attached the kernel messages after loading the radeon module on 3.17-rc3.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
From: Michel Dänzer <michel.daenzer(a)amd.com>
The radeon driver uses placement range restrictions for several reasons,
in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
during a page fault.
Without this change, TTM could evict other BOs while trying to satisfy
the requested placement, even if the evicted BOs were outside of the
requested placement range. Doing so didn't free up any space in the
requested placement range, so the (potentially high) eviction cost was
…
[View More]incurred for no benefit.
Nominating for stable because radeon driver changes in 3.17 made this
much more noticeable than before.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662
Cc: stable(a)vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com>
---
drivers/gpu/drm/ttm/ttm_bo.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8f5cec6..407fa2d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -709,6 +709,7 @@ out:
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
+ const struct ttm_place *place,
bool interruptible,
bool no_wait_gpu)
{
@@ -720,8 +721,21 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
list_for_each_entry(bo, &man->lru, lru) {
ret = __ttm_bo_reserve(bo, false, true, false, NULL);
- if (!ret)
+ if (!ret) {
+ if (place && (place->fpfn || place->lpfn)) {
+ /* Don't evict this BO if it's outside of the
+ * requested placement range
+ */
+ if (place->fpfn >= (bo->mem.start + bo->mem.size) ||
+ (place->lpfn && place->lpfn <= bo->mem.start)) {
+ __ttm_bo_unreserve(bo);
+ ret = -EBUSY;
+ continue;
+ }
+ }
+
break;
+ }
}
if (ret) {
@@ -782,7 +796,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
return ret;
if (mem->mm_node)
break;
- ret = ttm_mem_evict_first(bdev, mem_type,
+ ret = ttm_mem_evict_first(bdev, mem_type, place,
interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1233,7 +1247,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
while (!list_empty(&man->lru)) {
spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, mem_type, false, false);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
if (ret) {
if (allow_errors) {
return ret;
--
2.1.1
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=86181
Bug ID: 86181
Summary: Timeout setting UVD clocks
Product: Drivers
Version: 2.5
Kernel Version: 3.16.3-2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: sterfield(a)gmail.…
[View More]com
Regression: No
Created attachment 153551
--> https://bugzilla.kernel.org/attachment.cgi?id=153551&action=edit
full dmesg
Hi,
I've bought recently a MSI R7 265 (lspci attached), and use it in build under
Debian testing.
I've tried to configure it in order to have H264 hardware decoding, but UVD
failed at boot time (dmesg attached).
I've tried to boot with dpm=0, the problem is still here.
As one user had problem with maybe overheating
(https://bugzilla.kernel.org/show_bug.cgi?id=60858), I changed the thermal
paste on my graphic card, but the problem persists.
I've dumped some registers, as it seems to be interesting :
root@steambox:~# radeontool regmatch 0x0718
0x0718 0x00000023 (35)
root@steambox:~# radeontool regmatch 0x071c
0x071c 0xc080001c (-1065353188)
root@steambox:~# radeontool regmatch 0x0720
0x0720 0x3168680e (828925966)
Thanks for your help !
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]