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=edit
Linking fail log
--
You are receiving this mail because:
You are the assignee for the
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
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 +++-
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111413
Andre Klapper changed:
What|Removed |Added
Component|IGT |Two
Group|
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
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
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
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
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
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
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
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
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
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
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
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:
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
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 +--
>
> > 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
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
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
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
> -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]
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,
On Fri, Aug 16, 2019 at 11:10:11PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
>
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
> >
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
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
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
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:
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
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
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
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
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
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
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
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
> > @@
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.
--
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
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
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
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
> ---
>
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
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
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
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
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:
> -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 /
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
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
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=edit
amd-staging-drm-net dmesg log
--
You are receiving this mail because:
You are the assignee for the
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=edit
amd-staging-drm-next xorg log
--
You are receiving this mail because:
You are the assignee for the
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
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
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
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
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)
77 matches
Mail list logo
