Using list_move() instead of list_del() + list_add() in nv40.c.
Reported-by: Hulk Robot
Signed-off-by: Baokun Li
---
V1->V2:
CC mailist
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv40.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Using list_move() instead of list_del() + list_add() in base.c.
Reported-by: Hulk Robot
Signed-off-by: Baokun Li
---
V1->V2:
CC mailist
drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Using list_move() instead of list_del() + list_add() in nv44.c.
Reported-by: Hulk Robot
Signed-off-by: Baokun Li
---
V1->V2:
CC mailist
drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Using list_move() instead of list_del() + list_add() in base.c.
Reported-by: Hulk Robot
Signed-off-by: Baokun Li
---
V1->V2:
CC mailist
drivers/gpu/drm/nouveau/nvkm/engine/sw/base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Wed, Jun 09, 2021 at 07:38:04PM +1000, Alistair Popple wrote:
> On Wednesday, 9 June 2021 4:33:52 AM AEST Peter Xu wrote:
> > On Mon, Jun 07, 2021 at 05:58:52PM +1000, Alistair Popple wrote:
> >
> > [...]
> >
> > > +static bool page_make_device_exclusive_one(struct page *page,
> > > +
On Thursday, 10 June 2021 2:05:06 AM AEST Peter Xu wrote:
> On Wed, Jun 09, 2021 at 07:38:04PM +1000, Alistair Popple wrote:
> > On Wednesday, 9 June 2021 4:33:52 AM AEST Peter Xu wrote:
> > > On Mon, Jun 07, 2021 at 05:58:52PM +1000, Alistair Popple wrote:
[...]
> > For thp this means we could
On Wednesday 09 June 2021 11:21:05 Christian König wrote:
> Am 09.06.21 um 09:10 schrieb Ondrej Zary:
> > On Wednesday 09 June 2021, Christian König wrote:
> >> Am 09.06.21 um 08:57 schrieb Ondrej Zary:
> >>> [SNIP]
> Thanks for the heads up. So the problem with my patch is already fixed,
>
Yeah, exactly that's the root cause of the problem.
GEM objects are the base class for TTM BOs for quite a while now.
So we at least need to initialize them or otherwise at least the size of
the object is not available.
Going to send a fix in a few minutes.
Thanks,
Christian.
Am 09.06.21
Good point, but I think that is unrelated.
My suspicion is rather that nouveau is not initializing the underlying
GEM object for internal allocations.
So what happens is the same as on VMWGFX that TTM doesn't know anything
about the size to of the BO resulting in a kmalloc() with a random
Hi Mikko,
strange sounds like Nouveau was somehow also using the GEM workaround
for VMWGFX as well.
But -12 means -ENOMEM which doesn't fits into the picture.
I will try with a G710, but if that doesn't yields anything I need some
more input from you.
Thanks for the report,
Christian.
On 6/9/21 8:29 PM, Christian König wrote:
TTMs buffer objects are based on GEM objects for quite a while
and rely on initializing those fields before initializing the TTM BO.
Noveau now doesn't init the GEM object for internally allocated BOs,
Nouveau
so make sure that we at least
TTMs buffer objects are based on GEM objects for quite a while
and rely on initializing those fields before initializing the TTM BO.
Noveau now doesn't init the GEM object for internally allocated BOs,
so make sure that we at least initialize some necessary fields.
Signed-off-by: Christian König
GEM init happens here:
https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/nouveau_gem.c#n221
Note the bo alloc / gem init / bo init dance.
I don't think there is a GEM object for internal allocations at all --
we just allocate bo's directly and that's it. Perhaps you meant
Christian - potentially relevant is that Tegra doesn't have VRAM at
all -- all GTT (or GART or whatever it's called nowadays). No
fake/stolen VRAM.
Cheers,
-ilia
On Wed, Jun 9, 2021 at 10:18 AM Christian König
wrote:
>
> Hi Mikko,
>
> strange sounds like Nouveau was somehow also using the
Hi,
I'm observing nouveau not initializing recently on linux-next on my
Tegra186 Jetson TX2 board. Specifically it looks like BO allocation is
failing when initializing the sync subsystem:
[ 21.858149] nouveau 1700.gpu: DRM: failed to initialise sync
subsystem, -28
I have been
Am 09.06.21 um 09:10 schrieb Ondrej Zary:
On Wednesday 09 June 2021, Christian König wrote:
Am 09.06.21 um 08:57 schrieb Ondrej Zary:
[SNIP]
Thanks for the heads up. So the problem with my patch is already fixed,
isn't it?
The NULL pointer dereference in nouveau_bo_wr16 introduced in
Am 09.06.21 um 08:57 schrieb Ondrej Zary:
[SNIP]
Thanks for the heads up. So the problem with my patch is already fixed,
isn't it?
The NULL pointer dereference in nouveau_bo_wr16 introduced in
141b15e59175aa174ca1f7596188bd15a7ca17ba was fixed by
aea656b0d05ec5b8ed5beb2f94c4dd42ea834e9d.
Am 08.06.21 um 23:59 schrieb Ondrej Zary:
On Tuesday 08 June 2021 22:01:56 Ondrej Zary wrote:
On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote:
On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote:
On Saturday 05 June 2021 23:34:23 Ondrej
On Wednesday, 9 June 2021 4:33:52 AM AEST Peter Xu wrote:
> On Mon, Jun 07, 2021 at 05:58:52PM +1000, Alistair Popple wrote:
>
> [...]
>
> > +static bool page_make_device_exclusive_one(struct page *page,
> > + struct vm_area_struct *vma, unsigned long address, void *priv)
> > +{
> >
On Wednesday 09 June 2021, Christian König wrote:
> Am 09.06.21 um 08:57 schrieb Ondrej Zary:
> > [SNIP]
> >> Thanks for the heads up. So the problem with my patch is already fixed,
> >> isn't it?
> > The NULL pointer dereference in nouveau_bo_wr16 introduced in
> >
On Wednesday 09 June 2021, Christian König wrote:
> Am 08.06.21 um 23:59 schrieb Ondrej Zary:
> > On Tuesday 08 June 2021 22:01:56 Ondrej Zary wrote:
> >> On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote:
> >>> On Monday 07 June 2021 22:58:43 Ondrej Zary wrote:
> On Sunday 06 June 2021
21 matches
Mail list logo
