[Bug 70651] New: cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)
https://bugzilla.kernel.org/show_bug.cgi?id=70651 Bug ID: 70651 Summary: cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m) Product: Drivers Version: 2.5 Kernel Version: 3.13.3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: sjh+bugzillakernel at sanjioh.org Regression: No Created attachment 126301 --> https://bugzilla.kernel.org/attachment.cgi?id=126301&action=edit 3.13.3 dmesg hi, I'm using a notebook with intel ivy bridge + amd radeon 7730m hybrid graphics. With the latest stable kernel (3.13.3) I can't echo (low, high, auto) to /sys/class/drm/card0/device/power_dpm_force_performance_level: root at darkstar:~# echo "high"> /sys/class/drm/card0/device/power_dpm_force_performance_level -bash: echo: write error: Invalid argument root at darkstar:~# echo "low" /sys/class/drm/card0/device/power_dpm_force_performance_level low /sys/class/drm/card0/device/power_dpm_force_performance_level root at darkstar:~# echo "auto" /sys/class/drm/card0/device/power_dpm_force_performance_level auto /sys/class/drm/card0/device/power_dpm_force_performance_level I cannot say it's a regression since I haven't tried previous kernels. I can echo "battery", "performance" or "balanced" to /sys/class/drm/card0/device/power_dpm_state Some other info: root at darkstar:~# cat /sys/class/drm/card0/device/power_dpm_force_performance_level auto root at darkstar:~# lspci|grep VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: AMD/ATI [Advanced Micro Devices, Inc.] Chelsea LP [Radeon HD 7730M] (rev ff) root at darkstar:~# cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :DynOff::01:00.0 1:IGD:+:Pwr::00:02.0 root at darkstar:~# for i in /sys/class/drm/card0/device/power/*; do echo "$i: $(cat $i)"; done /sys/class/drm/card0/device/power/autosuspend_delay_ms: 5000 /sys/class/drm/card0/device/power/control: auto /sys/class/drm/card0/device/power/runtime_active_time: 33415 /sys/class/drm/card0/device/power/runtime_status: suspended /sys/class/drm/card0/device/power/runtime_suspended_time: 934700 /sys/class/drm/card0/device/power/wakeup: disabled /sys/class/drm/card0/device/power/wakeup_abort_count: /sys/class/drm/card0/device/power/wakeup_active: /sys/class/drm/card0/device/power/wakeup_active_count: /sys/class/drm/card0/device/power/wakeup_count: /sys/class/drm/card0/device/power/wakeup_expire_count: /sys/class/drm/card0/device/power/wakeup_last_time_ms: /sys/class/drm/card0/device/power/wakeup_max_time_ms: /sys/class/drm/card0/device/power/wakeup_total_time_ms: root at darkstar:~# cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 575000 kHz current engine clock: 210280 kHz default memory clock: 90 kHz current memory clock: 00 kHz voltage: 825 mV PCIE lanes: 16 (This last output is different from the ones I've seen around) Am I missing something? dmesg attached Thanks -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #7 from Nick Tenney --- Created attachment 94142 --> https://bugs.freedesktop.org/attachment.cgi?id=94142&action=edit Diablo III Valgrind output Thanks Ilia, that did the trick! I just grabbed the first few minutes of game play in Valgrind up until it started encountering the error that was popping previously. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/a16df0f8/attachment.html>
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 Victor Zhang changed: What|Removed |Added CC||victzhang at gmail.com --- Comment #21 from Victor Zhang --- I am having exactly the same issue on Ubuntu 13.10 (kernel 3.11.0-15-generic). My GPU is HD3450 (R620 LE). Apart form the random hang issue, sometimes the kernel crashes during "modprobe radeon". I have to disable dpm for now. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #8 from Ilia Mirkin --- (In reply to comment #7) > Created attachment 94142 [details] > Diablo III Valgrind output > > Thanks Ilia, that did the trick! I just grabbed the first few minutes of > game play in Valgrind up until it started encountering the error that was > popping previously. I'm not a radeon guy, just a drive-by commenter, but I'm going to go ahead and guess that this output is going to be of little use to anyone debugging :( A trace with symbols in r600_dri would be much more useful. With what you provided, we just know that the memory is allocated with malloc and calloc... which is of little surprise. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/189e7d5b/attachment-0001.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #21 from Jos? Su?rez --- Same as comment 20 but with radeonsi (HD 7870). In fact the game runs beautifully now (and really smooth). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/672f0940/attachment.html>
[PATCH] drm/nouveau/bios: fix INDEX_ADDRESS_LATCHED trace printout
Having a \n in the middle of a format string means that the next line
doesn't get the prefixes unlike every other line printed by the trace.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
index de201ba..126651b 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
@@ -845,9 +845,8 @@ init_idx_addr_latched(struct nvbios_init *init)
u32 data = nv_ro32(bios, init->offset + 13);
u8 count = nv_ro08(bios, init->offset + 17);
- trace("INDEX_ADDRESS_LATCHED\t"
- "R[0x%06x] : R[0x%06x]\n\tCTRL &= 0x%08x |= 0x%08x\n",
- creg, dreg, mask, data);
+ trace("INDEX_ADDRESS_LATCHED\tR[0x%06x] : R[0x%06x]\n", creg, dreg);
+ trace("\tCTRL &= 0x%08x |= 0x%08x\n", mask, data);
init->offset += 18;
while (count--) {
--
1.8.3.2
[Bug 70651] cannot write to power_dpm_force_performance_level: invalid argument (radeon 7730m)
https://bugzilla.kernel.org/show_bug.cgi?id=70651 --- Comment #1 from Fabio Sangiovanni --- Sorry, there was obviously an error in the echo commands reported in the previous comment. Actual relevant result is: root at darkstar:~# echo "high"> /sys/class/drm/card0/device/power_dpm_force_performance_level -bash: echo: write error: Invalid argument root at darkstar:~# echo "low"> /sys/class/drm/card0/device/power_dpm_force_performance_level -bash: echo: write error: Invalid argument root at darkstar:~# echo "auto"> /sys/class/drm/card0/device/power_dpm_force_performance_level -bash: echo: write error: Invalid argument -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/nouveau: fix TTM_PL_TT memtype on pre-nv50
op 16-02-14 05:27, Ilia Mirkin schreef:
> Commit a55409066 ("drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU
> access") made it possible to work with tiled memory. However
> mem->mm_node is not a nouveau_mem for AGP-using pre-NV50 cards, but a
> drm_mm_node, as created by the ttm_bo_manager_func. As such, extend the
> untiled check to explicitly include all pre-nv50 cards.
>
> Reported-by: Ronald
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74613
> Signed-off-by: Ilia Mirkin
> ---
>
> Hmmm... this seems like a really fragile semantic, I wonder if more
> mem->mm_node usages have to be audited. But this one's quick and easy. I'd
> rather see something a little more solid around dealing with these
> differences, but not sure how without reading all the ttm gunk. Perhaps just
> make sure it's always a nouveau_mem by wrapping the ttm_bo_manager logic?
>
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 488686d..4aed171 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1249,7 +1249,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> - if (!node->memtype)
> + if (nv_device(drm->device)->card_type < NV_50 || !node->memtype)
> /* untiled */
> break;
> /* fallthrough, tiled memory */
Acked-by: Maarten Lankhorst
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #22 from Krzysztof A. Sobiecki --- (In reply to comment #20) > I can confirm fixed rendering on r600g with this: > https://bugs.freedesktop.org/show_bug.cgi?id=71870#c25 It fixed the problem, will make a patch for it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/3a767b91/attachment.html>
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #4 from MirceaKitsune --- I updated Mesa to latest GIT and tried this again last night (Kokua viewer 3.6.12 x64). The result was even more catastrophic: As soon the world was to begin rendering, the screen turned black and the monitor went in standby mode. The numlock / capslock leds on the keyboard also stopped toggling. I had to power off the computer to restart. This likely means a Kernel panic happened, so the problem is probably really bad. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/cb1a21c3/attachment.html>
[Bug 74784] Strange artifacts when rendering trees in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=74784 Bruno Jim?nez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Bruno Jim?nez --- With mesa at commit 6d1cecb (Friday evening) this problem is fixed. Thanks! P.D: Maybe it was related to the hyperz problem of r600g drivers, as I am using a revision that is after this commit http://cgit.freedesktop.org/mesa/mesa/commit/?id=01e637114914453451becc0dc8afe60faff48d84 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/9d1e4af0/attachment-0001.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #23 from Jos? Su?rez --- I'm not sure why but the glsl workaround makes my X server crash everytime it starts (dies before it starts properly). I had not noticed until now when I restarted the PC because the test I reported in comment 21 did not involve restarting the X server (I just updated the mesa packages and launched the game without restarting the X server). In the backtrace log I see the radeon driver and the glamor libraries as the source of the problem: [ 1757.414] (EE) [ 1757.414] (EE) Backtrace: [ 1757.414] (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x7f8870012fdd] [ 1757.414] (EE) 1: /usr/bin/X (0x7f886fe7+0x1a6d49) [0x7f8870016d49] [ 1757.414] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f886ef5+0xfbb0) [0x7f886ef5fbb0] [ 1757.414] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x1865b3) [0x7f88690c65b3] [ 1757.414] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x186739) [0x7f88690c6739] [ 1757.414] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x1db03f) [0x7f886911b03f] [ 1757.414] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x1db15b) [0x7f886911b15b] [ 1757.414] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x22c868) [0x7f886916c868] [ 1757.414] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0x1f53d0) [0x7f88691353d0] [ 1757.414] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7f8868f4+0xdd61a) [0x7f886901d61a] [ 1757.414] (EE) 10: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (0x7f886bf68000+0x708b) [0x7f886bf6f08b] [ 1757.414] (EE) 11: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (0x7f886bf68000+0x8225) [0x7f886bf70225] [ 1757.414] (EE) 12: /usr/lib/x86_64-linux-gnu/libglamor.so.0 (glamor_init+0x32d) [0x7f886bf6bddd] [ 1757.414] (EE) 13: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0x4c0be) [0x7f8869a840be] [ 1757.414] (EE) 14: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0xc078) [0x7f8869a44078] [ 1757.414] (EE) 15: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f8869a38000+0x465ea) [0x7f8869a7e5ea] [ 1757.414] (EE) 16: /usr/bin/X (AddScreen+0x71) [0x7f886fec54d1] [ 1757.414] (EE) 17: /usr/bin/X (InitOutput+0x3f8) [0x7f886ff05d88] [ 1757.414] (EE) 18: /usr/bin/X (0x7f886fe7+0x445cb) [0x7f886feb45cb] [ 1757.414] (EE) 19: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f886db71de5] [ 1757.414] (EE) 20: /usr/bin/X (0x7f886fe7+0x44aff) [0x7f886feb4aff] [ 1757.414] (EE) [ 1757.414] (EE) Segmentation fault at address 0x0 [ 1757.414] (EE) Fatal server error: [ 1757.414] (EE) Caught signal 11 (Segmentation fault). Server aborting [ 1757.415] (EE) [ 1757.415] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1757.415] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 1757.415] (EE) [ 1757.419] (EE) Server terminated with error (1). Closing log file. Xorg is 1.14.5-1ubuntu2~saucy1 (i.e. updated, unmodified Ubuntu saucy packages). I am using KDE's Kwin as the compositor (4.11.5-0ubuntu0.1). A build of the same mesa source without the workaround allows the X server to start properly. Since noone reporting here seems to be using radeonsi and/or glamor (and noone has reported any problem yet), I suppose this could be related to glamor, upon which the radeonsi is dependant for 2D. Is this affecting anyone else? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/0d892bbc/attachment.html>
[Bug 69301] no screen on update from 3.12.0
https://bugzilla.kernel.org/show_bug.cgi?id=69301 --- Comment #19 from Jan Outhuis --- I think this bug can be closed. Since the Xorg radeon_si driver does not yet support dpm, the only solution to this problem for now is to simply put radeon.dpm=0 on the kernel command line. On Thu, 2014-01-23 at 14:44 +, bugzilla-daemon at bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=69301 > > Bug ID: 69301 >Summary: no screen on update from 3.12.0 >Product: Drivers >Version: 2.5 > Kernel Version: 3.13.0 > Hardware: x86-64 > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Video(DRI - non Intel) > Assignee: drivers_video-dri at kernel-bugs.osdl.org > Reporter: jouthuis at dds.nl > Regression: No > > 3.13.0 hangs on video initialisation for my Radeon HD7750 card. It worked on > 3.12.0 and previous on 3.11.4. > > After upgrading to 3.13.0, the bootprocess doesn't get past the > video-initialisation and leaves me with a black screen and dead keyboard. > > I'm running Debian testing on 64bit architecture. > -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73067] RV770 - screen flicker with radeon.dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=73067 --- Comment #13 from Benjamin Bellec --- Alex, I saw you disabled RV770 mclk switching to kernel 3.13.3 and 3.12.11. Thank you, it's now much more comfortable (tested with Fedora 19 kernel 3.12.11). Anyway, do you plan to add your patch to kernel 3.10 too? It's a long-term release and will be used by RHEL7. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/866fb39b/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #24 from Mike Lothian --- Created attachment 94159 --> https://bugs.freedesktop.org/attachment.cgi?id=94159&action=edit Patch for ignoring macros starting with __ The c file is generated by the src/glsl/glcpp/glcpp-parse.y file - this patch might make things easier for those building from scratch - you might need to make sure the c file is regenerated -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/9ef17a59/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #25 from Jos? Su?rez --- I had removed too much code (see https://bugs.freedesktop.org/show_bug.cgi?id=71870#c32). Now its working properly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/8b130493/attachment.html>
GeForce 6100 (NV4E) & nouveau regression in 3.12
2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
> On Mon, Feb 10, 2014 at 3:05 PM, Rafa? Mi?ecki wrote:
>> 2014-02-10 20:06 GMT+01:00 Ilia Mirkin :
>>> There was also an issue with libdrm_nouveau for pre-nv50 chips, when
>>> compiled with gcc-4.8 some time back... fixed in... 2.4.48 or so?
>>
>> I use openSUSE 12.2 (x86_64) which provides gcc 4.7.1 and
>> libdrm_nouveau1-2.4.33-2.3.2.x86_64. I assume libdrm_nouveau was
>> compiled using that 4.7.1.
>
> Hmmm... the nouveau drm rewrite went into 2.4.34... I guess you're
> using pretty old userspace in general, since everything depends on the
> post-rewrite libdrm_nouveau. Of course it definitely sounds like a
> kernel issue, but I can't help but wonder if this is a non-issue with
> later userspace.
>
> So there are basically 2 things left to do, in order of time-consuming-ness:
>
> (a) try a live{cd,usb} (e.g. arch, or something else that has recent
> software), and see if the issue is still present there.
I've tried Fedora 20 booted from USB. It suffers from the same issue.
It's based on kernel 3.11.10, but I'm sure it has more up to date
userspace.
> (b) bisect. you can (almost) definitely restrict the bisect to
> drivers/gpu/drm/nouveau. if you have additional computational power, i
> would recommend looking into distcc for speeding up the compiles. it
> may be interesting to also try 3.6.x since 3.7 received a pretty big
> rewrite. but a git bisect is a lot more direct in figuring these
> things out :)
Bisecting nouveau between 3.10 and 3.11 is a real pain.
Ben introduced booting regression with commit:
commit dceef5d87cc01358cc1434416f3272e2ddc3d97a
Author: Ben Skeggs
Date: Mon Mar 4 13:01:21 2013 +1000
drm/nouveau/fb: initialise vram controller as pfb sub-object
I had to first bisect fix for that regression which appeared to be:
commit 6284bf41b97fb36ed96b664a3c23b6dc3661f5f9
Author: Ilia Mirkin
Date: Fri Aug 9 17:25:54 2013 -0400
drm/nouveau/fb: fix null derefs in nv49 and nv4e init
Unfortunately meanwhile another init regression was introduced with:
commit 0108bc808107b97e101b15af9705729626be6447
Author: Maarten Lankhorst
Date: Sun Jul 7 10:40:19 2013 +0200
drm/nouveau: do not allow negative sizes for now
And I had to find fix for that which was:
commit 35095f7529bb6abdfc956e7a41ca6957520b70a7
Author: Maarten Lankhorst
Date: Sat Jul 27 10:17:12 2013 +0200
drm/nouveau: fix size check for cards without vm
Then I finally was able to test every commit between 3.10 and 3.11
without skipping 90% of them.
--
Rafa?
GeForce 6100 (NV4E) & nouveau regression in 3.12
2014-02-11 11:41 GMT+01:00 Ilia Mirkin : > (b) bisect. you can (almost) definitely restrict the bisect to > drivers/gpu/drm/nouveau. if you have additional computational power, i > would recommend looking into distcc for speeding up the compiles. it > may be interesting to also try 3.6.x since 3.7 received a pretty big > rewrite. but a git bisect is a lot more direct in figuring these > things out :) > > After I watched your video, it definitely brought back memories of > another bug or perhaps email on this list a while back (definitely > within the past year), but unfortunately I can't quite place it :( I've finally bisected between 3.10 and 3.11: 78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f Author: Ben Skeggs Date: Wed Aug 21 11:30:36 2013 +1000 drm/nv04/disp: fix framebuffer pin refcounting I've booted that commit and one commit older few times. Every time I booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the earlier commit), it was OK. Ben: any idea why this commit caused regression for my hardware? From the commit message I assume it was supposed to affect some ancient nv04 hardware only. Did it accidentally touch my nv4e path code maybe? -- Rafa?
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 --- Comment #9 from Nick Tenney --- Thanks for the help so far! I am happy to keep on debugging with more specificity, but will need some help as I'm still pretty new with this stuff. Let me know if there is anything I can provide to help shine light on this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/b19a6733/attachment.html>
[Bug 75011] Performance drop since git-6d1cecb with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 --- Comment #2 from Tom Guder --- I confirm this. Thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/2e4a3bb1/attachment.html>
[Bug 75011] Performance drop since git-6d1cecb with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 Tom Guder changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/a1b7683b/attachment.html>
GeForce 6100 (NV4E) & nouveau regression in 3.12
On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote: > 2014-02-11 11:41 GMT+01:00 Ilia Mirkin : >> (b) bisect. you can (almost) definitely restrict the bisect to >> drivers/gpu/drm/nouveau. if you have additional computational power, i >> would recommend looking into distcc for speeding up the compiles. it >> may be interesting to also try 3.6.x since 3.7 received a pretty big >> rewrite. but a git bisect is a lot more direct in figuring these >> things out :) >> >> After I watched your video, it definitely brought back memories of >> another bug or perhaps email on this list a while back (definitely >> within the past year), but unfortunately I can't quite place it :( > > I've finally bisected between 3.10 and 3.11: > > 78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit > commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f > Author: Ben Skeggs > Date: Wed Aug 21 11:30:36 2013 +1000 > > drm/nv04/disp: fix framebuffer pin refcounting > > I've booted that commit and one commit older few times. Every time I > booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the > earlier commit), it was OK. But I bet if you restart X, you get a backtrace, right? > > Ben: any idea why this commit caused regression for my hardware? From > the commit message I assume it was supposed to affect some ancient > nv04 hardware only. Did it accidentally touch my nv4e path code maybe? All pre-nv50 hardware (including your nv4e) use this path. -ilia
GeForce 6100 (NV4E) & nouveau regression in 3.12
2014-02-16 19:55 GMT+01:00 Ilia Mirkin : > On Sun, Feb 16, 2014 at 10:17 AM, Rafa? Mi?ecki wrote: >> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin : >>> (b) bisect. you can (almost) definitely restrict the bisect to >>> drivers/gpu/drm/nouveau. if you have additional computational power, i >>> would recommend looking into distcc for speeding up the compiles. it >>> may be interesting to also try 3.6.x since 3.7 received a pretty big >>> rewrite. but a git bisect is a lot more direct in figuring these >>> things out :) >>> >>> After I watched your video, it definitely brought back memories of >>> another bug or perhaps email on this list a while back (definitely >>> within the past year), but unfortunately I can't quite place it :( >> >> I've finally bisected between 3.10 and 3.11: >> >> 78ae0ad403daf11cf63da86923d2b5dbeda3af8f is the first bad commit >> commit 78ae0ad403daf11cf63da86923d2b5dbeda3af8f >> Author: Ben Skeggs >> Date: Wed Aug 21 11:30:36 2013 +1000 >> >> drm/nv04/disp: fix framebuffer pin refcounting >> >> I've booted that commit and one commit older few times. Every time I >> booted 78ae0ad I got corruption. Every time I booted 6ff8c76 (it's the >> earlier commit), it was OK. > > But I bet if you restart X, you get a backtrace, right? That's right. 78ae0ad: Corruptions 6ff8c76: WARNING: at drivers/gpu/drm/nouveau/nouveau_bo.c:151 nouveau_bo_del_ttm+0x80/0x90 [nouveau]() (after quiting X by "init 3") -- Rafa?
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #22 from Marco --- Tried yesterday mesa git: latest commit 1020d8937ef52725cc5adafc12465f6332815. Now without xorg.conf and with xorg.conf.d with: Section "Module" Load "dri2" Load "glamoregl" EndSection Xorg start without any problem. marco at albireo:~/src/mesa.git$ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD KABINI OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-1020d89) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-1020d89) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: But... what about my second GPU? I was hoping to use it with DRI_PRIME but: xrandr --listproviders shows only Providers: number : 1 Provider 0: id: 0x54 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 3 associated providers: 0 name:radeon And what about render nodes? Will I be able to use second GPU as a render node? Or this hybrid AMD GPU is considered as one and not two GPU? For what concern this bug, You can now close it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/59c15074/attachment.html>
[PATCH] drm/nouveau: fix TTM_PL_TT memtype on pre-nv50
2014-02-16 5:27 GMT+01:00 Ilia Mirkin :
> Commit a55409066 ("drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU
> access") made it possible to work with tiled memory. However
> mem->mm_node is not a nouveau_mem for AGP-using pre-NV50 cards, but a
> drm_mm_node, as created by the ttm_bo_manager_func. As such, extend the
> untiled check to explicitly include all pre-nv50 cards.
>
> Reported-by: Ronald
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74613
> Signed-off-by: Ilia Mirkin
> ---
Tested-by: Ronald Uitermark
> Hmmm... this seems like a really fragile semantic, I wonder if more
> mem->mm_node usages have to be audited. But this one's quick and easy. I'd
> rather see something a little more solid around dealing with these
> differences, but not sure how without reading all the ttm gunk. Perhaps just
> make sure it's always a nouveau_mem by wrapping the ttm_bo_manager logic?
>
> drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 488686d..4aed171 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1249,7 +1249,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> - if (!node->memtype)
> + if (nv_device(drm->device)->card_type < NV_50 ||
> !node->memtype)
> /* untiled */
> break;
> /* fallthrough, tiled memory */
> --
> 1.8.3.2
>
[Bug 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #23 from Marco --- Created attachment 94179 --> https://bugs.freedesktop.org/attachment.cgi?id=94179&action=edit Latest xorg.log without xorg.conf -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/a580250e/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #196 from Paul Bodenbenner --- I don't need the patch anymore. Probably it's because of switching to the git packages of mesa and xorg. Also using 3.14rc2 kernel now. Booting and suspending works great with this uptodate packages! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140216/fe1728fc/attachment.html>
[PATCH] drm/tilcdc: Defer probe if no encoders/connectors found
Hi,
On Wed, Dec 18, 2013 at 02:56:01PM +0100, Markus Pargmann wrote:
> At the moment this driver fails to load if no encoders/connectors were
> found. In case other drivers that register encoders/connectors
> (tilcdc_panel) are defered it would be better to check for
> encoders/connectors later again. This patch replaces the returncode
> -ENXIO with -EPROBE_DEFER to get a working setup even if tilcdc_panel
> probes after tilcdc.
>
Ping. Anything I need to change?
Regards,
Markus
> Signed-off-by: Markus Pargmann
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 116da19..217303c 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -84,7 +84,7 @@ static int modeset_init(struct drm_device *dev)
> if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
> /* oh nos! */
> dev_err(dev->dev, "no encoders/connectors found\n");
> - return -ENXIO;
> + return -EPROBE_DEFER;
> }
>
> dev->mode_config.min_width = 0;
> --
> 1.8.5.1
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
