https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #15 from rol...@rptd.ch ---
I've tried now the patching approach. I had to patch in total three files:
src/amd/common/ac_nir_to_llvm.c
src/gallium/auxiliary/gallivm/lp_bld_init.c
src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #16 from rol...@rptd.ch ---
Created attachment 145083
--> https://bugs.freedesktop.org/attachment.cgi?id=145083&action=edit
Linking fail log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #106 from reject5...@naver.com ---
(In reply to magist3r from comment #105)
> (In reply to reject5514 from comment #103)
> > I have this problem on Archlinux 5.2.8-arch1-1-ARCH when connected 2
> > monitors(1920x1080 @ 60Hz) and amdgp
Drop use of deprecated drmP.h header file.
Remove drmP.h includes and add some include headers for function or
struct that used in code.
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 2 +-
drivers/gpu/drm/arm/hdlcd_drv.c | 6 +-
drivers/gpu/drm/arm/malidp_crtc.c | 4 +++-
drivers/gpu/drm/arm
Hi,
On 21-07-19 15:19, Hans de Goede wrote:
For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.
Extensive testing has shown that when the info is correct, the
BGRT image is always exactly centered horizontally (the yoffset vari
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
---
include/linux/dma-fence.h |
Am 17.08.19 um 13:39 schrieb Chris Wilson:
> Rearrange the couple of 32-bit atomics hidden amongst the field of
> pointers that unnecessarily caused the compiler to insert some padding,
> shrinks the size of the base struct dma_fence from 80 to 72 bytes on
> x86-64.
>
> Signed-off-by: Chris Wilson
Quoting Koenig, Christian (2019-08-17 12:42:48)
> Am 17.08.19 um 13:39 schrieb Chris Wilson:
> > Rearrange the couple of 32-bit atomics hidden amongst the field of
> > pointers that unnecessarily caused the compiler to insert some padding,
> > shrinks the size of the base struct dma_fence from 80 t
From: Colin Ian King
Variable val is initialized to a value in a for-loop that is
never read and hence it is redundant. Remove it.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #115 from Tom B ---
I should have noted it earlier, but I had already tried reverting both "golden
values" commits. I've no idea what it does but it didn't fix this crash.
One thing that would be insightful would be logging every ca
https://bugs.freedesktop.org/show_bug.cgi?id=111413
Andre Klapper changed:
What|Removed |Added
Component|IGT |Two
Group|
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1 deleti
The timestamp and the cb_list are mutually exclusive, the cb_list can
only be added to prior to being signaled (and once signaled we drain),
while the timestamp is only valid upon being signaled. Both the
timestamp and the cb_list are only valid while the fence is alive, and
as soon as no reference
Currently dma_fence_signal() tries to avoid the spinlock and only takes
it if absolutely required to walk the callback list. However, to allow
for some users to surreptitiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence,
we always need to
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
Reviewed-by: Christian König
--
In light of recent review slip ups, the absence of a suite of tests for
dma-buf became apparent. Given the current plethora of testing
frameworks, opt for one already in use by Intel's CI and so allow easy
hook up into igt.
We introduce a new module that when loaded will execute the list of
selfte
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel Ve
On Sat, Aug 17, 2019 at 01:21:24PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable val is initialized to a value in a for-loop that is
> never read and hence it is redundant. Remove it.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Thanks. Applied and pu
Am 17.08.19 um 16:47 schrieb Chris Wilson:
> Currently dma_fence_signal() tries to avoid the spinlock and only takes
> it if absolutely required to walk the callback list. However, to allow
> for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signali
Am 17.08.19 um 16:47 schrieb Chris Wilson:
> The timestamp and the cb_list are mutually exclusive, the cb_list can
> only be added to prior to being signaled (and once signaled we drain),
> while the timestamp is only valid upon being signaled. Both the
> timestamp and the cb_list are only valid wh
Currently dma_fence_signal() tries to avoid the spinlock and only takes
it if absolutely required to walk the callback list. However, to allow
for some users to surreptitiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence,
we always need to
> > There are definitely going to be regressions on machines in the field with
> > the
> > in tree drivers by reverting this. I think we should have an answer for
> > all of
> those
> > before this revert is accepted.
> >
> > Regarding systems with Intel+NVIDIA, we'll have to work with partners
> On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote:
> >
> > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher
> wrote:
> > >
> > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote:
> > > >
> > > > On Thu, Aug 15, 2019 at 3:56 PM wrote:
> > > > >
> > > > > > -Original Message-
> > > > >
On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
>
> As said before I don't think these low-level helpers are the
> right API to export, but even if they did you'd just cover a tiny
> subset of the architectures.
Are you thinking instead something like:
void dma_sync_sg_for_{cpu,device}
On Thu, Aug 15, 2019 at 02:03:25PM -0400, Jerome Glisse wrote:
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > > > On Tue, Aug 13, 2019 at 0
Hi all,
I'm getting frequent system crashes (every few hours or so) and it seems
that the nouveau driver is causing the issue (dmesg output below). I see it
with both v5.2.8 and the v4.19 LTS kernel. Sometimes the system
completely freezes and sometimes seemingly just the nouveau driver goes
down.
On Sat, Aug 17, 2019 at 01:31:28PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 05:11:07PM +, Jason Gunthorpe wrote:
> > - if (args->cpages)
> > - migrate_vma_prepare(args);
> > - if (args->cpages)
> > - migrate_vma_unmap(args);
> > + if (!args->cpages)
>
On 2019/8/15 12:26, Matthew Ruffell wrote:
Hi,
amd64 based Huawei servers have problems where the display output of their iBMC
chips is broken, resulting in a "blurry" screen when viewed from their in house
remote kvm-like console.
Example:
https://launchpadlibrarian.net/365907668/creen_pict
On Fri, Aug 16, 2019 at 06:44:48AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 12:43:07AM +, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> >
> > > struct page. In this case any way we can update the
> > > nouveau_dmem_page() to check
On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote:
> On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> >
> > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > > __GFP_DIRECT_RECLAIM..
> > > >
> >
Vlastimil Babka wrote on 8/15/2019 7:32 AM:
Does the issue still happen with rc4? Could you apply the 3 attached
patches (work in progress), configure-enable CONFIG_DEBUG_PAGEALLOC and
CONFIG_PAGE_OWNER and boot kernel with debug_pagealloc=on page_owner=on
parameters? That should print stacktrac
On Wed, Aug 14, 2019 at 09:59:27AM +0200, Christoph Hellwig wrote:
> No one ever checks this flag, and we could easily get that information
> from the page if needed.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Ralph Campbell
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
> inc
> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org On
> Behalf Of Dave Airlie
> Sent: Wednesday, August 14, 2019 5:48 PM
> To: Karol Herbst
> Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung; Ben
> Skeggs; Dave Airlie
> Subject: Re: [Nouveau] [PATCH 1/7] R
On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> So nor HMM nor driver should dereference the struct page (i do not
> think any iommu driver would either),
Er, they do technically deref the struct page:
nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
st
On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
> >
> > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> >
> > > So nor HMM nor driver should dereference the struct page (i do not
> > > think any iommu driver wo
On Fri, Aug 16, 2019 at 02:47:53PM +0200, Vlastimil Babka wrote:
> On 8/15/19 9:13 PM, Petr Vandrovec wrote:
> > [ 18.110985] DMAR: [DMA Write] Request device [07:00.1] fault addr
> > fffe [fault reason 02] Present bit in context entry is clear
>
> Worth reporting as well, not nice regressi
On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> struct page. In this case any way we can update the
> nouveau_dmem_page() to check that page page->pgmap == the
> expected pgmap.
I was also wondering if that is a problem.. just blindly doing a
container_of on the page->pgmap does
On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote:
> hmm_range_fault may return NULL pages because some of pfns are equal to
> HMM_PFN_NONE. This happens randomly under memory pressure. The reason is
> for swapped out page pte path, hmm_vma_handle_pte doesn't update fault
> variable from
On Wed, Aug 14, 2019 at 09:59:18AM +0200, Christoph Hellwig wrote:
> Hi Jérôme, Ben and Jason,
>
> below is a series against the hmm tree which starts revamping the
> migrate_vma functionality. The prime idea is to export three slightly
> lower level functions and thus avoid the need for migrate_
On Fri, Aug 16, 2019 at 06:36:52PM +0200, Daniel Vetter wrote:
> On Fri, Aug 16, 2019 at 4:38 PM Jason Gunthorpe wrote:
> >
> > On Fri, Aug 16, 2019 at 04:11:34PM +0200, Daniel Vetter wrote:
> > > Also, aside from this patch (which is prep for the next) and some
> > > simple reordering conflicts t
On Thu, Aug 15, 2019 at 10:28:21AM +0200, Christian König wrote:
> Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
> > From: Jason Gunthorpe
> >
> > radeon is using a device global hash table to track what mmu_notifiers
> > have been registered on struct mm. This is better served with the new
> > g
On Thu, Aug 15, 2019 at 10:53 AM Christoph Hellwig wrote:
>
> On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> > On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote:
> > >
> > > As said before I don't think these low-level helpers are the
> > > right API to export, but even if th
at 21:33, Deucher, Alexander wrote:
Thanks for finding this! I think the attached patch should fix the issue
and it's much less invasive.
Yes it also fix the issue, please add by tested-by:
Tested-by: Kai-Heng Feng
I took this more or less future proof approach because I think this won’t
> -Original Message-
> From: Takashi Iwai
> Sent: Thursday, August 15, 2019 9:57 AM
> To: Alex Deucher
> Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML;
> dri-devel;
> Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie
> Subject: Re: [Nouveau] [PATCH 1/7
On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote:
> > However, this means we cannot do any processing of ZONE_DEVICE pages
> > outside the driver lock, so eg, doing any DMA map that might rely on
> > MEMORY_DEVICE_PCI_P2PDMA has to be done in the driver lock, which is
> > a bit unfortu
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
>
> mm folks: migrate.c
> -Original Message-
> From: Karol Herbst
> Sent: Thursday, August 15, 2019 9:25 AM
> To: Limonciello, Mario
> Cc: Dave Airlie; LKML; Linux ACPI Mailing List; dri-devel; nouveau; Rafael J .
> Wysocki; Alex Hung; Ben Skeggs; David Airlie
> Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / O
On Wed, Aug 14, 2019 at 09:59:19AM +0200, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of boilerp
On Wed, Aug 14, 2019 at 09:59:28AM +0200, Christoph Hellwig wrote:
> CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper
> devic private memory support. Remove the option and just check for
> CONFIG_DEVICE_PRIVATE instead.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/g
On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote:
> > We can do a get_dev_pagemap inside the page_walk and touch the pgmap,
> > or we can do the 'device mutex && retry' pattern and touch the pgmap
> > in the driver, under that lock.
> >
> > However in all cases the current get_dev_page
Add optional property node 'arm,malidp-arqos-value' for the Mali DP500.
This property describe the ARQoS levels of DP500's QoS signaling.
Signed-off-by: Wen He
---
change in v3:
- correction the describe of the node
Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++
1 fil
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
Done,
Lets see if Dan w
On Thu, Aug 15, 2019 at 10:22:45AM +0200, Linus Walleij wrote:
> On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
>
> > Add support for the avdd33 regulator to the analogix-anx78xx driver.
> > Note that the regulator is currently enabled during driver probe and
> > disabled when the driver is
Vlastimil Babka wrote on 8/16/2019 5:47 AM:
On 8/15/19 9:13 PM, Petr Vandrovec wrote:
With iommu=off disks are visible, but USB keyboard (and other USB
devices) does not work:
I've been told iommu=soft might help.
Thanks. I've rebuilt kernel without IOMMU.
Unfortunately I was not able to r
On Tue, Aug 06, 2019 at 08:15:37PM -0300, Jason Gunthorpe wrote:
> This series is already entangled with patches in the hmm & RDMA tree and
> will require some git topic branches for the RDMA ODP stuff. I intend for
> it to go through the hmm tree.
> Jason Gunthorpe (11):
> mm/mmu_notifiers: hoi
Quoting Koenig, Christian (2019-08-17 16:20:12)
> Am 17.08.19 um 16:47 schrieb Chris Wilson:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 89d96e3e6df6..2c21115b1a37 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -129
Am 17.08.19 um 17:23 schrieb Chris Wilson:
> Currently dma_fence_signal() tries to avoid the spinlock and only takes
> it if absolutely required to walk the callback list. However, to allow
> for some users to surreptitiously insert lazy signal callbacks that
> do not depend on enabling the signali
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #17 from Matt Turner ---
The build failure is in Clover, the OpenCL implementation. If the application
that triggers the huge amount of RAM problem is not using OpenCL, disable
OpenCL in meson configure and try to get past that.
--
The timestamp and the cb_list are mutually exclusive, the cb_list can
only be added to prior to being signaled (and once signaled we drain),
while the timestamp is only valid upon being signaled. Both the
timestamp and the cb_list are only valid while the fence is alive, and
as soon as no reference
Am 17.08.19 um 17:27 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-17 16:20:12)
>> Am 17.08.19 um 16:47 schrieb Chris Wilson:
>>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>>> index 89d96e3e6df6..2c21115b1a37 100644
>>> --- a/drivers/dma-buf/dma-fence.c
>>>
Am 17.08.19 um 17:30 schrieb Chris Wilson:
> The timestamp and the cb_list are mutually exclusive, the cb_list can
> only be added to prior to being signaled (and once signaled we drain),
> while the timestamp is only valid upon being signaled. Both the
> timestamp and the cb_list are only valid wh
On Sat, Aug 17, 2019 at 5:26 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 09:02:49AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> > > > We need to make sure implement
Hi Sidong
On Sat, Aug 17, 2019 at 08:41:15AM +0100, Sidong Yang wrote:
> Drop use of deprecated drmP.h header file.
> Remove drmP.h includes and add some include headers for function or
> struct that used in code.
Thanks for your patch.
We already have a similiar patch in drm-misc-next, that
drop
https://bugs.freedesktop.org/show_bug.cgi?id=111414
Bug ID: 111414
Summary: [REGRESSION] [BISECTED] Segmentation fault in
si_bind_blend_state after removal of the blend state
NULL check
Product: Mesa
Version: git
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #13 from Samantha McVey ---
Created attachment 145085
--> https://bugs.freedesktop.org/attachment.cgi?id=145085&action=edit
amd-staging-drm-net dmesg log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #14 from Samantha McVey ---
Created attachment 145086
--> https://bugs.freedesktop.org/attachment.cgi?id=145086&action=edit
amd-staging-drm-next xorg log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #15 from Samantha McVey ---
I have uploaded my dmesg log and xorg log from amd-staging-drm-next
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #28 from Sebastian ---
There is a new Version of the Radeon Software (ver 19.30 from Aug 12.)
https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-linux
Does the script work for the new version?
--
You are receiving th
From: Dave Airlie
Purelink FX-D120 (DVI over fibre extendeders) drive the HPD line
low on the GPU side when the monitor side device is unplugged
or loses the connection. However the GPU side device seems to cache
EDID in this case. Per DVI spec the HPD line must be driven in order
for EDID to be
https://bugzilla.kernel.org/show_bug.cgi?id=203879
--- Comment #9 from Sam Bazley (sambaz...@fastmail.com) ---
I've realised that I am actually being affected by this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Please disregard my previous comments.
--
You are receiving this mail be
On Tue, Aug 06, 2019 at 03:45:48PM -0700, Rob Clark wrote:
please don't queue this one for stable branches.. it was causing
problems in intel CI
Now dropped, thank you.
--
Thanks,
Sasha
On Wed, Aug 07, 2019 at 08:49:52AM +, David Laight wrote:
From: Sasha Levin
Sent: 06 August 2019 22:33
From: Colin Ian King
[ Upstream commit 1bbbab097a05276e312dd2462791d32b21ceb1ee ]
Currently the retry counter is not being decremented, leading to a
potential infinite spin if the scala
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #20 from Brian Schott ---
The following applies to the graphics corruption seen in Dolphin:
ea5b7de138bb7e9a4e7e4f0c39c4ceb16acae923 is the first bad commit
commit ea5b7de138bb7e9a4e7e4f0c39c4ceb16acae923
Author: Pierre-Eric Pelloux
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andrew Shark changed:
What|Removed |Added
Attachment #144555|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andrew Shark changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|VERIFIED
https://bugs.freedesktop.org/show_bug.cgi?id=111415
Bug ID: 111415
Summary: BUG: kernel NULL pointer dereference - supervisor read
access in kernel mode
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
76 matches
Mail list logo
