Displaying 20 results from an estimated 300 matches similar to: "[PATCH] drm: nouveau: use larger buffer in nvif_vmm_map"
2017 Nov 28
2
[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)
This is a false positive, but I wonder if it is really necessary to put
the assignment in the conditional test expression.
julia
---------- Forwarded message ----------
Date: Tue, 28 Nov 2017 13:23:36 +0800
From: kbuild test robot <fengguang.wu at intel.com>
To: kbuild at 01.org
Cc: Julia Lawall <julia.lawall at lip6.fr>
Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci
2017 Nov 28
0
[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)
Hi julia,
I think it would be better to extract the assignment out of the if
clause. Then you'll get something like this:
memory = ...;
if (IS_ERR(memory)) {
....
}
so, to answer your question: no, it isn't necessary.
On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall <julia.lawall at lip6.fr> wrote:
> This is a false positive, but I wonder if it is really necessary to put
> the
2019 May 17
4
drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks
Hello,
5.1.0-next-20190517
I'm looking at quite a lot of kmemleak reports coming from
drm/nouveau/core/memory, all of which are:
unreferenced object 0xffff8deec27c4ac0 (size 16):
comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
2008 Jan 17
1
Under DTrace USDT and PID, kernel''s microstat accounting doesn''t work in this situation, doesn''t it?
Does anyone has any ideas about this problem?
2008/1/15, ?? TaoJie <eulertao at gmail.com>:
>
> Hi all:
>
> I''m working on revealing system performance now.
> My testing program is an infinite loop. Inside the loop, it will do some
> mathematical opertaions and call function callee(), then go to the next
> loop.
> I install a alarm(30) in the program. It
2018 Mar 10
17
[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
From: Jérôme Glisse <jglisse at redhat.com>
(mm is cced just to allow exposure of device driver work without ccing
a long list of peoples. I do not think there is anything usefull to
discuss from mm point of view but i might be wrong, so just for the
curious :)).
git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00
2019 Oct 09
3
[Bug 111940] New: frequent timeout warnings during normal operation
https://bugs.freedesktop.org/show_bug.cgi?id=111940
Bug ID: 111940
Summary: frequent timeout warnings during normal operation
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: not set
Component: Driver/nouveau
2019 May 17
0
drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks
On (05/17/19 15:13), Sergey Senozhatsky wrote:
> 5.1.0-next-20190517
>
> I'm looking at quite a lot of kmemleak reports coming from
> drm/nouveau/core/memory, all of which are:
>
> unreferenced object 0xffff8deec27c4ac0 (size 16):
> comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s)
> hex dump (first 16 bytes):
> 00 00
2019 Sep 10
1
[Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote:
> On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding <thierry.reding at gmail.com> wrote:
> >
> > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann <kraxel at redhat.com> wrote:
> > > >
> > > > Hi,
> > > >
2019 Feb 23
0
[Bug 101220] [NV137/GP107] xorg-server-1.19.3 crashes when trying to enable HDMI output
https://bugs.freedesktop.org/show_bug.cgi?id=101220
--- Comment #19 from Pacho Ramos <pachoramos1 at gmail.com> ---
Any news on this? I still need to run with noaccel with kernel 4.19.25,
otherwise system ends up getting hung after showing this errors:
feb 23 17:21:08 dell-2017 kernel: ------------[ cut here ]------------
feb 23 17:21:08 dell-2017 kernel: nouveau 0000:01:00.0: timeout
feb
2019 Sep 27
5
[Bug 111843] New: Resume fails after suspend with nouveau and Gtx 1050 ti
https://bugs.freedesktop.org/show_bug.cgi?id=111843
Bug ID: 111843
Summary: Resume fails after suspend with nouveau and Gtx 1050
ti
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: not set
Priority: not set
Component: Driver/nouveau
2018 Sep 03
4
[Bug 107818] New: linux-4.18.5 every boot some drivers errors
https://bugs.freedesktop.org/show_bug.cgi?id=107818
Bug ID: 107818
Summary: linux-4.18.5 every boot some drivers errors
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
Assignee: nouveau at
2023 Feb 04
1
[PATCH] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
More arrays (and arguments) for dcpd were set to 16, when it looks like
DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen
with GCC 13:
../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp':
../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned char[16][0]' is partly outside array bounds of 'u8[15]' {aka
2023 May 22
0
[PATCH 6.3 004/364] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
From: Kees Cook <keescook at chromium.org>
[ Upstream commit 25feda6fbd0cfefcb69308fb20d4d4815a107c5e ]
More arrays (and arguments) for dcpd were set to 16, when it looks like
DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen
with GCC 13:
../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp':
../include/linux/fortify-string.h:57:33:
2019 Nov 08
0
[PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h
In preparation for allowing architectures to define their own
implementation of the 'READ_ONCE()' macro, move the generic
'{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
and into a new 'rwonce.h' header under 'asm-generic'.
Signed-off-by: Will Deacon <will at kernel.org>
---
include/asm-generic/Kbuild | 1 +
2018 Jan 25
0
[PATCH net-next 11/12] tools/virtio: copy READ/WRITE_ONCE
This is to make ptr_ring test build again.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
tools/virtio/ringtest/main.h | 57 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/tools/virtio/ringtest/main.h b/tools/virtio/ringtest/main.h
index 5706e07..593a328 100644
--- a/tools/virtio/ringtest/main.h
+++ b/tools/virtio/ringtest/main.h
@@
2018 Apr 03
2
nouveau TRAP_M2MF still there on G98
Hi!
In commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0:
> drm/nouveau/mmu: ALIGN_DOWN correct variable
>
> Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round
> for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN,
> but erroneously applied ALIGN_DOWN to a different variable (addr) and left
> intended variable (tail) not
2019 Apr 26
2
[RFC][clang/llvm] Allow efficient implementation of libc's memory functions in C/C++
*TL;DR:*
Defining memory functions in C / C++ results in a chicken and egg problem.
Clang can mutate the code into semantically equivalent calls to libc. None
of `-fno-builtin-memcpy`, `-ffreestanding` nor `-nostdlib` provide a
satisfactory answer to the problem.
*Goal*
Create libc's memory functions (aka `memcpy`, `memset`, `memcmp`, ...) in
C++ to benefit from compiler's knowledge and
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote:
>> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote:
>
>>> What are use cases for such primitive that won't be OK with "read once
>>> _and_ atomically"?
>>
>> I have none to hand.
>
> Whatever triggers the
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote:
>> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote:
>
>>> What are use cases for such primitive that won't be OK with "read once
>>> _and_ atomically"?
>>
>> I have none to hand.
>
> Whatever triggers the
2019 Nov 11
1
[PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h
On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger
<borntraeger at de.ibm.com> wrote:
> On 08.11.19 20:57, Arnd Bergmann wrote:
> > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote:
> >>
> >> In preparation for allowing architectures to define their own
> >> implementation of the 'READ_ONCE()' macro, move the generic