[Bug 92936] Tonga powerplay isssues
https://bugs.freedesktop.org/show_bug.cgi?id=92936 Andy Furniss changed: What|Removed |Added Attachment #120450|0 |1 is obsolete|| --- Comment #5 from Andy Furniss --- Comment on attachment 120450 --> https://bugs.freedesktop.org/attachment.cgi?id=120450 a couple of locks using uvd. Maybe the locks are not a powerplay issue, I managed to lock gst vaapi with powerplay=0 and on drm-next-4.5 will have to investigate more/open a new bug over time. -- 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/20151212/ccc5c21a/attachment.html>
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #10 from Nicolai Hähnle --- Wait, so if the game requires OpenGL 4.3, why does it even start? Did they mess up their version checking? -- 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/20151212/d664543c/attachment.html>
[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions
https://bugs.freedesktop.org/show_bug.cgi?id=92858 --- Comment #13 from Darren D. --- (In reply to Christian König from comment #12) > > In this case I would suggest to just say git bisect bad until you find a > kernel that boots again and then continue till you either have the commit > which causes the radeon problem or the boot problem. > > If it's the radeon problem you find first than we can just continue > analyzing it. > > And if it's the boot lockup problem then please note the commit hash and I > will try to figure out what's going wrong here. This way you should be able > to finally dig up what's the issue with radeon. > > Thanks for sticking with that. Another update: I think I'm either finished or close to finished--shouldn't bisect say which of the revisions is bad once i get down to 0, though? Bisecting: 0 revisions left to test after this (roughly 0 steps) [bdcddf95e82b1c4e370fc1196b1f4f50f775dab4] Backmerge v4.1-rc4 into into drm-next Please see below for output of "git bisect log' listing the commits bisected, following your advice about telling git the non-bootable revisions were bad and moving on until I found one that compiled a bootable kernel. Any bisects that say bad after 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 are marked bad not because of lack of accel, but because they didn't boot up. I was able to locate, however, the next bootable kernel after the 'initial ramdisk" boot failures started. Commit ID 744b058827b3db9a4f6027522dd9c73a208c2d31, and it both booted and had functional accelerated OpenGL on the videocard. git bisect start # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1 git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345 # bad: [d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754] Linux 4.2-rc1 git bisect bad d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754 # good: [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 4570a37169d4b44d316f40b2ccc681dc93fedc7b # bad: [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag 'driver-core-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect bad 8d7804a2f03dbd34940fcb426450c730adf29dae # good: [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 3d9f96d850e4bbfae24dc9aee03033dd77c81596 # bad: [692a59e696afe1a4e777d0e4359325336ab0ad89] drm/amdgpu: remove AMDGPU_CTX_OP_STATE_RUNNING git bisect bad 692a59e696afe1a4e777d0e4359325336ab0ad89 # good: [81663016dbfd53e29d1b5c5ddbc9b12ae1d66474] drm/amdkfd: Add module parameter of send_sigterm git bisect good 81663016dbfd53e29d1b5c5ddbc9b12ae1d66474 # bad: [992839ad64f21ff4e5ed0a71691098ab7cfcb9dc] drm/amdkfd: Add static user-mode queues support git bisect bad 992839ad64f21ff4e5ed0a71691098ab7cfcb9dc # bad: [ff0b187f92f61503c8af67d3dc5e6e91fbe2f9cc] drm/i915: Add a space after ', ' and don't capitalize mid-sentence git bisect bad ff0b187f92f61503c8af67d3dc5e6e91fbe2f9cc # bad: [f3e06f1156f1adf17dc44144ad3b774c2d414e47] drm/i915/gtt: Fix the boundary check for vm area git bisect bad f3e06f1156f1adf17dc44144ad3b774c2d414e47 # good: [744b058827b3db9a4f6027522dd9c73a208c2d31] drm/atomic: remove duplicated assignment of old_plane_state git bisect good 744b058827b3db9a4f6027522dd9c73a208c2d31 # bad: [b6e742f652791919ce5c8e05a1d664bcbc5111a6] drm/i915: Be optimistic about future display engines having 7 WM levels git bisect bad b6e742f652791919ce5c8e05a1d664bcbc5111a6 # good: [91d9f9856f91c82ac6289a0fff65dd12cfa07e34] Merge tag 'drm-amdkfd-next-2015-05-19' of git://people.freedesktop.org/~gabbayo/linux into drm-next git bisect good 91d9f9856f91c82ac6289a0fff65dd12cfa07e34 # bad: [7e35ab88d8ec652803eb2965c00e3ed9967c4f9d] drm/i915: Fix typo in intel_runtime_pm.c git bisect bad 7e35ab88d8ec652803eb2965c00e3ed9967c4f9d # bad: [5e024f31be3734aed0a5ead7002de16029ec3bc1] drm/i915: Remove unused variable from i915_gem_mmap_gtt git bisect bad 5e024f31be3734aed0a5ead7002de16029ec3bc1 -- 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/20151212/5bc7b933/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #91 from Maxim Sheviakov --- (In reply to Tobias Droste from comment #90) > Yes I did. > > And right now it's only working for Stefan (R7 370). > > It's not working for me (R9 270X) and Daniel (R9 270X). Hmm... Seems like the code is useful for 3XX GPUs. Anyway, still no PSU with me, and I will test the changes with my R7 370 from MSI when I get the thingie. We gotta find somebody else with R7 370 and ask to try those patches & firmware. -- 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/20151212/e19e7166/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #90 from Tobias Droste --- Yes I did. And right now it's only working for Stefan (R7 370). It's not working for me (R9 270X) and Daniel (R9 270X). -- 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/20151212/31488cea/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #89 from Maxim Sheviakov --- (In reply to Tobias Droste from comment #88) > Doesn't fix it for me, it still locks up at boot with dpm enabled and the > quirk removed. > > [drm] initializing kernel modesetting (PITCAIRN 0x1002:0x6810 0x174B:0xE271 > 0x00) Have you put the new firmware files to your initramfs/initrd? Check replies above. -- 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/20151212/7baaac1f/attachment.html>
[Bug 91917] linux-firmware.git should carry most recent firmware for SI, CI et al.
https://bugs.freedesktop.org/show_bug.cgi?id=91917 Kai changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kai --- Fixed by 90d3de6378a764c6471d6f158ac022c1f9e5ed22 (<https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit?id=90d3de6378a764c6471d6f158ac022c1f9e5ed22>). 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/20151212/287286ec/attachment-0001.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #34 from John Frei --- Created attachment 120486 --> https://bugs.freedesktop.org/attachment.cgi?id=120486&action=edit dmesg with amdgpu crash -- 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/20151212/92a5582d/attachment.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #33 from John Frei --- I've tried the new stuff by the following steps: -cloning the code from the new_smc branch... -I enabled the "Enable amdgpu support for CIK parts" due to a recommendation on reddit. -compiling and installing the kernel+modules... -I placed the ucode to /lib/firmware/radeon and /lib/firmware/amdgpu -The rebuild of the modules was done by 'sudo dracut -f'. <-- I hope this is the correct command. -Then I rebooted the system with 'rdblacklist=0 amdgpu.enable_scheduler=1'. -I was able to log in and use the system for a short time until the screen went black. (~1min) -BUT: I pressed ALT+CTRL+F4 and 'blindly' typed my login credentials and was able to dump the dmesg output to file (attachment). The number lock could be switched on/off for a few seconds. Even though the screen remained black. -Then I booted with unmodified kernel parameters. -A few seconds after the login screen appeared the screen switched to black. -Unlike the first try with amdgpu I wasn't able to execute a 'dmesg >> file'. The number lock couldn't be switched on/off anymore. -- 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/20151212/44869895/attachment.html>
[PATCH v3 0/9] drm/exynos: new G2D test programs and improvement
Hi Hyungwon, On 30 November 2015 at 04:39, Hyungwon Hwang wrote: > Hello, > > this series mostly touches G2D code. It introduces the following: > > (1) A small performance test application which can be used to measure > the speed of solid color clear operations. Interesting for > benchmarking and plotting colorful graphs (e.g. through > Mathematica). > > (2) g2d_move() which works similar to g2d_copy() but like the C > memmove() properly handles overlapping buffer copies. > Again a test application is present to check that this > indeed does what it should. > > (3) Various small changes. A framebuffer colorformat fix for the > general G2D test application. > > (4) Last but not least a small bump of the Exynos version number. > > Please review and let me know what I should change/improve. > > With best wishes on behalf of Tobias, > Hyungwon Hwang > > Changes since v1: > - Added wording changes suggested by Hyungwon Hwang. > - Added binaries for new test applications to .gitignore. > - Collected r-b and t-b tags. > > Changes since v2: > - Patches for public API changes (g2d_reset, exynos_bo_unmap, drmHandleEvent) > are excluded. > - Definitions which are used internally are moved from public header to source > file > > ps. I've added SOB by me only to the 3 patches I've modified. You can check > easily find the changes by finding SOB by me from the previous series. > > ps2. Firewall in the office blocked this email when I sent the patchset today. > So I resend this email again. > Thanks for the respin ! Just a final call for anyone interested and pointing out that I'll get push the lot in a couple of days (barring any show stoppers) Thanks for the patience guys and continued work. Emil
[PATCH libdrm 01/10] tests: Split helpers into library
Hi Thierry, all, On 9 December 2015 at 17:37, Thierry Reding wrote: > From: Thierry Reding > > Some of the helpers, such as the pattern drawing helpers or the format > lookup helpers, have potential to be reused. Move them into a separate > library to make it easier to share them. > > Acked-by: Laurent Pinchart > Signed-off-by: Thierry Reding > --- > CleanSpec.mk| 1 + > configure.ac| 1 + > tests/Makefile.am | 2 +- > tests/modeprint/Makefile.am | 1 + > tests/modeprint/modeprint.c | 2 +- > tests/modetest/Android.mk | 1 + > tests/modetest/Makefile.am | 8 +- > tests/modetest/buffers.c| 961 > +--- > tests/modetest/buffers.h| 12 +- > tests/modetest/cursor.c | 4 +- > tests/modetest/modetest.c | 25 +- > tests/proptest/Makefile.am | 4 +- > tests/proptest/proptest.c | 3 +- > tests/util/Android.mk | 39 ++ > tests/util/Makefile.am | 13 + > tests/util/Makefile.sources | 6 + > tests/util/common.h | 33 ++ > tests/util/format.c | 120 ++ > tests/util/format.h | 65 +++ > tests/util/pattern.c| 870 +++ > tests/util/pattern.h| 39 ++ > tests/vbltest/Makefile.am | 1 + > tests/vbltest/vbltest.c | 2 +- > 23 files changed, 1223 insertions(+), 990 deletions(-) > create mode 100644 tests/util/Android.mk > create mode 100644 tests/util/Makefile.am > create mode 100644 tests/util/Makefile.sources > create mode 100644 tests/util/common.h > create mode 100644 tests/util/format.c > create mode 100644 tests/util/format.h > create mode 100644 tests/util/pattern.c > create mode 100644 tests/util/pattern.h > As mentioned on IRC, although there might be some minor nitpicks I'd rather the series in those in and fix them later. Mostly to avoid the long gap until you get the chance to respin things, but also to spare Tomi (and others) the need to reinvent them :-) So barring any serious objections, I'd vote for getting these soonish. Perhaps mid next week ? Thanks Emil
[PATCH] intel: merge latest i915_drm.h
On 11 December 2015 at 21:55, Jesse Barnes wrote: > Pick up context flags, softpin, etc. > > Signed-off-by: Jesse Barnes > --- > include/drm/i915_drm.h | 57 > ++ > 1 file changed, 48 insertions(+), 9 deletions(-) > Any objections if we do this (and pretty much every other outdated header) in a single go, as the header cleanups hit Linus' tree ? Dave already has then in drm-next :-) -Emil
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352
--- Comment #11 from Iaroslav Andrusyak ---
(In reply to Jürgen Scholz from comment #10)
> I just tried this, by using:
> ln -s GRID\ Autosport/ GRIDAutosport
> env
> LD_PRELOAD='/usr/$LIB/libstdc++.so.6:/home/juergen/.steam/SteamApps/common/
> GRIDAutosport/lib/x86_64/libtcmalloc_minimal.so' {rest of the usual command
> line here}
>
> I still get an error related to GLSL:
> GridAutosport: ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2342:
> virtual void glsl_to_tgsi_visitor::visit(ir_dereference_variable*):
> Assertion `var->data.location != -1' failed.
works for me only with --disable-debug mesa build
with debug build libtcmalloc_minimal.so does not help
--
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/20151212/63789587/attachment.html>
[PATCH v2 0/2] Improve drm_of_component_probe() and move rockchip to use it
Hi Dave, Am Freitag, 20. November 2015, 14:22:03 schrieb Liviu Dudau: > This is v2 of the patchset trying to make drm_of_component_probe() cope with > finding both local crtc ports and remote encoder ones. Heiko Stübner was > nice enough to test an earlier version that was patched following Russell's > suggestions on rk3288, but I haven't seen any reports from iMX or Armada > users. these 2 patches seem to work nicely now and can probably get applied. Do you want to pick them up, or do you expect Mark to do this and then include them in a pull request? Thanks Heiko
[PATCH] intel: merge latest i915_drm.h
On 12/12/2015 07:16 AM, Emil Velikov wrote: > On 11 December 2015 at 21:55, Jesse Barnes > wrote: >> Pick up context flags, softpin, etc. >> >> Signed-off-by: Jesse Barnes >> --- >> include/drm/i915_drm.h | 57 >> ++ >> 1 file changed, 48 insertions(+), 9 deletions(-) >> > Any objections if we do this (and pretty much every other outdated > header) in a single go, as the header cleanups hit Linus' tree ? > Dave already has then in drm-next :-) No objection here. Feel free to push it with my ack! Thanks, Jesse
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #7 from serge --- Created attachment 120484 --> https://bugs.freedesktop.org/attachment.cgi?id=120484&action=edit crash before the race -- 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/20151212/3752dba7/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #6 from serge --- Created attachment 120483 --> https://bugs.freedesktop.org/attachment.cgi?id=120483&action=edit crash on benchmark -- 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/20151212/27bc2922/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #5 from serge --- Created attachment 120482 --> https://bugs.freedesktop.org/attachment.cgi?id=120482&action=edit crash on launch of the game -- 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/20151212/15af401a/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #4 from serge --- it look like to hapened at shader compiling time. Each time i have a crash there are new shaders in the bin directory of the game. And then after some crash i have all the shaders needed by the game to play the race, but the game is still crashing on benchmark and totally freeze the computer on replay with the cockpit view. i made 3 differents attachements, i hope there is something interesting with them. -- 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/20151212/49be01ba/attachment.html>
[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #9 from Stepan Bakshaev --- apitrace link https://drive.google.com/file/d/0BytXisVUnJ7QV1VONjloamZ0WWs/view?usp=sharing mesa updated to 27d5be0b8fafecefc4f0378ca940cea8c0415715 llvm 255314 -- 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/20151212/dc31e4b5/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352
--- Comment #10 from Jürgen Scholz ---
I just tried this, by using:
ln -s GRID\ Autosport/ GRIDAutosport
env
LD_PRELOAD='/usr/$LIB/libstdc++.so.6:/home/juergen/.steam/SteamApps/common/GRIDAutosport/lib/x86_64/libtcmalloc_minimal.so'
{rest of the usual command line here}
I still get an error related to GLSL:
GridAutosport: ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2342:
virtual void glsl_to_tgsi_visitor::visit(ir_dereference_variable*): Assertion
`var->data.location != -1' failed.
--
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/20151212/6e536c32/attachment-0001.html>
[PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl
On Fri, Dec 11, 2015 at 03:12:26PM -0700, Jonathan Corbet wrote: > On Wed, 25 Nov 2015 18:07:59 +0100 > Daniel Vetter wrote: > > > Unfortunately the entire improved docbook project died at KS in a > > massive bikeshed. So we need to carry this around in drm private trees > > forever :( > > I don't think that's an entirely helpful way to look at things, honestly. > Changing how the docs system works affects a lot of people, they're going > to have input on the matter. > > And I sure hope it hasn't "died". The posting of these patches suggests > that perhaps it has not. Hm, I think I fumbled the cc for the cover letter: http://www.spinics.net/lists/intel-gfx/msg81351.html In short it hasn't died, and 4.5 will have a few thousand more lines of doc already employing asciidoc (and ofc also the other stuff that already landed in 4.4). I just figured there's no way this could get it, and I'd much rather improve the docs themselves than trying to convince core kernel folks that this might be useful. > Anyway, I wanted to say that, my silence notwithstanding, I haven't just > dropped these. I had some hassles to deal with (replacing the entire LWN > server infrastructure, for example) but those are done; I hope to be able > to mess with this stuff a bit in the very near future. > > Have the table-rendering issues that Graham talked about before gotten any > better with the newer scheme? I haven't tackled the table conversion story yet, but one reason for me to switch to asciidoc (besides that Dave thought it was a good idea) was the better table support. I haven't tried, but it /should/ be powerful enough. Another bonus is in-line figures as asciiart that get rendered to png. But haven't done the integration work on that yet either. Anyway things seem to work and I'm happy. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 3/3] drm/radeon: only increment sync_seq when a fence is really emitted
From: Nicolai Hähnle
In the rare situation where the kmalloc fails we're probably screwed anyway,
but let's try to be more robust about it.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/radeon/radeon_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index df09ca7..05815c4 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -130,7 +130,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
struct radeon_fence **fence,
int ring)
{
- u64 seq = ++rdev->fence_drv[ring].sync_seq[ring];
+ u64 seq;
/* we are protected by the ring emission mutex */
*fence = kmalloc(sizeof(struct radeon_fence), GFP_KERNEL);
@@ -138,7 +138,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
return -ENOMEM;
}
(*fence)->rdev = rdev;
- (*fence)->seq = seq;
+ (*fence)->seq = seq = ++rdev->fence_drv[ring].sync_seq[ring];
(*fence)->ring = ring;
(*fence)->is_vm_update = false;
fence_init(&(*fence)->base, &radeon_fence_ops,
--
2.5.0
[PATCH 2/3] drm/radeon: fix typo
From: Nicolai Hähnle Signed-off-by: Nicolai Hähnle --- drivers/gpu/drm/radeon/cik.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 248953d..d93539d 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -4135,7 +4135,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device *rdev, * Emits an DE (drawing engine) or CE (constant engine) IB * on the gfx ring. IBs are usually generated by userspace * acceleration drivers and submitted to the kernel for - * sheduling on the ring. This function schedules the IB + * scheduling on the ring. This function schedules the IB * on the gfx ring for execution by the GPU. */ void cik_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib) -- 2.5.0
[PATCH 1/3] drm/ttm: fix documentation of ttm_bo_reserve
From: Nicolai Hähnle Previously, the comment was inconsistent. EDEADLK is what the ww_mutex mechanism really returns. Signed-off-by: Nicolai Hähnle --- include/drm/ttm/ttm_bo_driver.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 813042c..3d4bf08 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -826,10 +826,10 @@ static inline int __ttm_bo_reserve(struct ttm_buffer_object *bo, * reserved, the validation sequence is checked against the validation * sequence of the process currently reserving the buffer, * and if the current validation sequence is greater than that of the process - * holding the reservation, the function returns -EAGAIN. Otherwise it sleeps + * holding the reservation, the function returns -EDEADLK. Otherwise it sleeps * waiting for the buffer to become unreserved, after which it retries * reserving. - * The caller should, when receiving an -EAGAIN error + * The caller should, when receiving an -EDEADLK error * release all its buffer reservations, wait for @bo to become unreserved, and * then rerun the validation with the same validation sequence. This procedure * will always guarantee that the process with the lowest validation sequence -- 2.5.0
-next trees and my time this cycle
On Thu, Dec 10, 2015 at 10:58 PM, Dave Airlie wrote: > > So since Xmas is coming up and I've got an impending new arrival, I'm > betting this merge window might get a bit haphazard. So I'd like > people to start telling me now via git pull's what they'd like to get > in. So the rest of the world may not have an impending new arrival, but with pretty much everybody doing Christmas break, I don't really foresee opening the merge window immediately after the holidays. I can't reasonably expect people to get ready for the merge window while being drunk on eggnog or whatever. If 4.4 stays on the usual schedule (and there's currently no big reason to think it shouldn't), I'd do the final rc late December, and final release on the Sunday of Jan 3rd. But really, if I want people to be *ready* when the merge window opens, rather than start working on it, I'd better delay the opening of the merge window by at least a week. So right now my tentative plan is to open the 4.5 merge window on Jan 10th. Can't help with your impending new arrival, though. I thought you said you had figured out why that kept happening? Linus
-next trees and my time this cycle
Am Freitag, den 11.12.2015, 17:36 + schrieb Russell King - ARM Linux: > On Fri, Dec 11, 2015 at 05:15:40PM +0100, Daniel Vetter wrote: > > On Fri, Dec 11, 2015 at 10:02:45AM +, Russell King - ARM Linux > > wrote: > > > On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote: > > > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans > > > > for if > > > > people would like these in now, also anything I've missed on > > > > the list. > > > > > > I would definitely like to see etnaviv make it in for the next > > > merge > > > window, but that depends on it being reviewed, and I haven't seen > > > anything from DRM people yet. > > > > > > I've queued up some of the TDA998x and Armada DRM changes (3 and > > > 5 > > > patches respectively) which I'll send you shortly if they haven't > > > already been merged via some other route. > > > > I did look at etnaviv on v1, if all the things I've raised there > > have been > > addressed (and it looks like, but no time for detailed checking): > > I did keep a list of your points, and made sure that we'd addressed > them all.  We went a little further towards the end with your 'flags' > suggestion for several of the ioctls, which I think was a very good > point you raised. > > > Acked-by: Daniel Vetter > > Thanks! > > > For detailed review it would be best to just get some of the new > > big > > submissions to cross review I think. But personally I'd be ok with > > etnaviv going in as is, trusting that you've done plenty of review > > within your group. > > We have had a certain amount of review within our group - Christian > reviewed many of my early patches, and I've reviewed Lucas' patches. > There could have been more review. > > I was rather hoping for some review of the changes since your last > comments, especially with the locking changes.  I'm fairly confident > with the locking changes (which were particularly hairy) as I've been > running them for some time now with lockdep enabled.  The > particularly > "hairy" bit was in etnaviv_gem_get_iova(). > While I didn't review all of your patches in-depth, I think we've got the locking changes pretty well covered. The review I did there wasn't just some "I think this looks okay", but me taking the time to go through all paths I could envision and validating that your locking scheme works for them. Regards, LucasÂ
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352
--- Comment #9 from Vladimir Usikov ---
I have 7950(TAHITI) card and same problem. But i edit fie GridAutosport.sh in
game folder.
#HAS_CATALYST="$(grep fglrx /proc/modules)"
#if [ -n "${HAS_CATALYST}" ]; then
LD_PRELOAD="../lib/x86_64/libtcmalloc_minimal.so:${LD_PRELOAD}"
export LD_PRELOAD
#fi
And this help. No more crash. I test with low and high settings in ingame
benchmark.
--
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/20151212/75b64832/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 --- Comment #2 from Tobias Droste --- Created attachment 120476 --> https://bugs.freedesktop.org/attachment.cgi?id=120476&action=edit Output of R600_DEBUG=vs,gs,ps -- 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/20151212/5594522e/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 --- Comment #1 from Nicolai Hähnle --- Hi Tobias, thanks for the new report. As with bug #92944, could you please provide a log with R600_DEBUG=vs,gs,ps? This will show the segfaulting shader and should allow simple reproduction at least. -- 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/20151212/0bb9695e/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #88 from Tobias Droste --- Doesn't fix it for me, it still locks up at boot with dpm enabled and the quirk removed. [drm] initializing kernel modesetting (PITCAIRN 0x1002:0x6810 0x174B:0xE271 0x00) -- 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/20151212/ae8e2bba/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #8 from Jürgen Scholz --- Created attachment 120475 --> https://bugs.freedesktop.org/attachment.cgi?id=120475&action=edit Fourth console log of GRID Autosport Using the log file feature seems to yield complete shader files (exceeding sizes of 4kB). The attached tar archive includes the console log and the shader files. The relevant parts of the command line: MESA_GLSL=dump,log MESA_SHADER_DUMP_PATH=/tmp/dumps/shader/ ST_DEBUG=tgsi \ LIBGL_DEBUG=verbose MESA_DEBUG=1 \ -- 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/20151212/de625b59/attachment-0001.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #7 from Jürgen Scholz --- Created attachment 120474 --> https://bugs.freedesktop.org/attachment.cgi?id=120474&action=edit Third console log of GRID Autosport Well, that was interesting. I built mesa for amd64 (debuild -b -us -uc -j4) and i386 (debuild -ai386 -b -us -uc -j4 in i386 chroot) with changed version (dch -n) and "confflags += --enable-debug" in debian/rules. The console log has become greatly bigger in size. I hope it has the information you need. The 4k shader size limit can possibly be overcome when logging the files to a directory. I will try that in a few minutes. For completeness the fish commandline: ulimit -c unlimited; env LD_PRELOAD='/usr/$LIB/libstdc++.so.6' DISPLAY=:0 \ PATH="~/.steam/ubuntu12_32/steam-runtime/amd64/bin:~/.steam/ubuntu12_32/steam-runtime/amd64/usr/bin:$PATH" \ LD_LIBRARY_PATH="/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/lib:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/juergen/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib:/home/juergen/.steam/ubuntu12_32:/home/juergen/.steam/ubuntu12_32/panorama:/usr/lib32" \ LANG=C \ MESA_GLSL=dump ST_DEBUG=tgsi \ LIBGL_DEBUG=verbose MESA_DEBUG=1 \ /home/juergen/.steam/SteamApps/common/GRID\ Autosport/bin/GridAutosport 2>| cat - > /home/juergen/gridAutosport_console(date +%Y%m%d-%H%M%S).txt -- 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/20151212/2dede129/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 Tobias Droste changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=93360 -- 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/20151212/99180f6e/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 Tobias Droste changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=92944 -- 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/20151212/55bcc505/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 Bug ID: 93360 Summary: [radeonsi/llvm] Segfault in CS:GO Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: tdroste at gmx.de QA Contact: dri-devel at lists.freedesktop.org Created attachment 120470 --> https://bugs.freedesktop.org/attachment.cgi?id=120470&action=edit Backtrace of the segfault When loading of a level is done in CS:GO and the team selection menu should pop up CS:GO segfaults here: #0 0xf4f2cd2d in llvm::LiveRange::find(llvm::SlotIndex) () from /usr/local/lib/dri/radeonsi_dri.so Hardware: Hawaii PRO [Radeon R9 290] This happens with most recent LLVM SVN and Mesa git, and also with LLVM and Mesa from October. So this seems to be some long standing error in either Mesa or LLVM that is triggered now by a change of CS:GO. -- 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/20151212/c1fceb96/attachment.html>
[Bug 92944] [Fiji/LLVM/RadeonSI] CS:GO segfaults in llvm
https://bugs.freedesktop.org/show_bug.cgi?id=92944 --- Comment #12 from Tobias Droste --- Okaaay... sorry for the noise, I don't have the _same_ problem. My problem is not due to a change in either mesa or llvm but cs go as it seems. I switched to a llvm r251632 (October 29th) and mesa c6b24448b578c4a8ab031923df3ef1e2d865d5bb (also October 29th) and my problems is still there. I'm opening a new bug. -- 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/20151212/a941c0fc/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #87 from Stefan Ott --- Nice, this seems to fix the issue on my ASUS card. -- 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/20151212/3ef0946c/attachment.html>
[PATCH] drm/exynos: atomic check only enabled crtc states
Hi Javier, 2015-12-09 19:51 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 11/27/2015 10:00 AM, Javier Martinez Canillas wrote: >> Hello Andrzej, >> >> On 11/27/2015 03:57 AM, Andrzej Hajda wrote: >>> Since atomic check is called also for disabled crtcs it should skip >>> mode checking as it can be uninitialized. The patch fixes it. >>> >>> Signed-off-by: Andrzej Hajda >>> Suggested-by: Daniel Vetter >>> --- >>> Hi Javier, >>> >>> Could you check with this patch. >>> >> >> The patch fixes the issue I reported. The display mode is correctly set >> with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi: >> >> Tested-by: Javier Martinez Canillas >> > > This patch was never picked but fixes and important > bug introduced in the v4.4 merge window so it should > be sent during the v4.4-rc cycle. Don't worry about that. Thanks, Inki Dae > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
