Between creation and queueing of a job, you need to prevent any other
job from being created and queued. Otherwise the scheduler's fences
may be signaled out of seqno order.
v2: move mutex unlock to the error label.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM
On 2018-06-06 01:03 PM, Michel Dänzer wrote:
On 2018-06-06 06:01 PM, Michel Dänzer wrote:
On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
From: "Leo (Sunpeng) Li"
This ended up being different enough from v2 to warrant a new patchset. Per
Michel's suggestions, there have been various
On 2018-06-06 06:01 PM, Michel Dänzer wrote:
> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
>> From: "Leo (Sunpeng) Li"
>>
>> This ended up being different enough from v2 to warrant a new patchset. Per
>> Michel's suggestions, there have been various optimizations and cleanups.
>> Here's
Hi Leo,
On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> This ended up being different enough from v2 to warrant a new patchset. Per
> Michel's suggestions, there have been various optimizations and cleanups.
> Here's what's changed:
>
> * Cache DRM color
Just a gentle ping.
Daniel, Chris and all the other usual suspects for infrastructure stuff:
What do you think about that?
The cleanup patches are rather obvious correct, but #3 could result in
some fallout.
I really think it is the right thing in the long term.
Regards,
Christian.
Am
NAK as well. mem->mm_node can't be NULL on a correctly allocated BO.
You are running into a BO corruption here and trying to work around by
mitigating the effect and not fixing the root problem.
Regards,
Christian.
Am 06.06.2018 um 11:25 schrieb Pratik Vishwakarma:
Fixes NULL pointer
NAK, when bo->tbo.resv is NULL then the BO is corrupted (or already
released).
Please find the root cause of that corruption or freed memory access
instead of adding such crude workarounds.
Regards,
Christian.
Am 06.06.2018 um 11:25 schrieb Pratik Vishwakarma:
Fixes null pointer access in
Fixes null pointer access in ww_mutex_lock
where lock->base is NULL
Crash dump is as follows:
Call Trace:
ww_mutex_lock+0x3a/0x8e
amdgpu_bo_reserve+0x40/0x87
amdgpu_device_suspend+0xf4/0x210
pci_pm_suspend+0x12a/0x1a5
? pci_dev_driver+0x36/0x36
dpm_run_callback+0x59/0xbf
Fixes NULL pointer dereference in amdgpu_ttm_copy_mem_to_mem
BUG: unable to handle kernel NULL pointer dereference at 0010
IP: amdgpu_ttm_copy_mem_to_mem+0x85/0x40c
Workqueue: events_unbound async_run_entry_fn
Call Trace:
? _raw_spin_unlock+0xe/0x20
? ttm_check_swapping+0x4e/0x72
?
This patch series resolves crashes observed during S3 entry.
First patch removes the cursor BO hack which causes crashes
mentioned in patches 2 and 3. Patches 2 and 3 add NULL
checks to prevent crashing the system.
Pratik Vishwakarma (3):
drm/amd/display: Remove cursor hack for S3
cursor_bo operations cause crash during S3 entry.
On cursor movement between displays during S3 cycles
the system crashes on S3 entry.
These crashes are no more seen with this patch applied.
Also as per the comment just above the code that this
patch removes
"IN 4.10 kernel this code should be
Am Dienstag, den 05.06.2018, 13:02 -0400 schrieb Andrey Grodzovsky:
> Everything in the flush code path (i.e. waiting for SW queue
> to become empty) names with *_flush()
> and everything in the release code path names *_fini()
>
> This patch also effect the amdgpu and etnaviv drivers which
> use
Am 06.06.2018 um 10:46 schrieb Lucas Stach:
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
Between creation and queueing of a job, you need to prevent any other
job from being created and queued. Otherwise the scheduler's fences
may be signaled out of seqno order.
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> Between creation and queueing of a job, you need to prevent any other
> job from being created and queued. Otherwise the scheduler's fences
> may be signaled out of seqno order.
>
> > Signed-off-by: Eric Anholt
> Fixes:
Am 06.06.2018 um 09:03 schrieb Michel Dänzer:
On 2018-06-05 07:02 PM, Andrey Grodzovsky wrote:
Everything in the flush code path (i.e. waiting for SW queue
to become empty) names with *_flush()
and everything in the release code path names *_fini()
This patch also effect the amdgpu and etnaviv
Am 05.06.2018 um 16:44 schrieb Borislav Petkov:
Hi guys,
X just froze here ontop of 4.17-rc7+ tip/master (kernel is from last
week) with the splat at the end.
Box is a x470 chipset with Ryzen 2700X.
GPU gets detected as
[7.440971] [drm] radeon kernel modesetting enabled.
[7.441220]
On Tue, Jun 05, 2018 at 04:44:04PM +0200, Borislav Petkov wrote:
> Hi guys,
>
> X just froze here ontop of 4.17-rc7+ tip/master (kernel is from last
> week) with the splat at the end.
>
> Box is a x470 chipset with Ryzen 2700X.
>
> GPU gets detected as
>
> [7.440971] [drm] radeon kernel
Hi guys,
X just froze here ontop of 4.17-rc7+ tip/master (kernel is from last
week) with the splat at the end.
Box is a x470 chipset with Ryzen 2700X.
GPU gets detected as
[7.440971] [drm] radeon kernel modesetting enabled.
[7.441220] [drm] initializing kernel modesetting (RV635
On 2018-06-05 07:02 PM, Andrey Grodzovsky wrote:
> Everything in the flush code path (i.e. waiting for SW queue
> to become empty) names with *_flush()
> and everything in the release code path names *_fini()
>
> This patch also effect the amdgpu and etnaviv drivers which
> use those functions.
>
Reviewed-by: Rex Zhu
Best Regards
Rex
From: amd-gfx on behalf of Evan Quan
Sent: Wednesday, June 6, 2018 1:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH] drm/amd/powerplay: fix wrong clock adjust sequence
The clocks
20 matches
Mail list logo
