similar to: [BUG] nouveau lockdep splat

On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > full distro KVM's. > > Could you please check !RT with the `threadirqs' command line option? I > don't think RT is doing here anything different (except for

On Fri, 23 Oct 2020 14:07:13 +0200 Mike Galbraith wrote: > On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > > full distro KVM's. > > > > Could you please check !RT with the `threadirqs'

On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote: > +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range *range, > + u64 *ioctl_addr) > { > unsigned long i, npages; > > + /* > + * The ioctl_addr prepared here is passed through nvif_object_ioctl() > + * to an eventual DMA map on some call chain like: > + *

On Wed, Apr 22, 2020 at 08:03:29AM +0200, Christoph Hellwig wrote: > > > On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote: > > +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range *range, > > + u64 *ioctl_addr) > > { > > unsigned long i, npages; > > > > + /* > > + * The ioctl_addr prepared here is

On 5/1/20 11:20 AM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Presumably the intent here was that hmm_range_fault() could put the data > into some HW specific format and thus avoid some work. However, nothing > actually does that, and it isn't clear how anything actually could do that > as hmm_range_fault() provides CPU addresses which

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:

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

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

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

Hi there, Could someone please comment on the following hard-lock (*). Staring at the code, I see `nvkm_rd32` calls are enclosed in a timeout detection, except one. drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c#L171 ... nvkm_msec(device, 2000, if (!(nvkm_rd32(device, 0x100c80) & 0x00000001)) break; ); ... Would it make sense to also enclose this in the do/while loop ? Full ref: *

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

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

From: Jason Gunthorpe <jgg at mellanox.com> Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must be DMA mapped. Perhaps there is some special HW that does not need

From: Jason Gunthorpe <jgg at mellanox.com> Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must be DMA mapped. Perhaps there is some special HW that does not need

[+Philip Yang] Am 2020-04-21 um 8:21 p.m. schrieb Jason Gunthorpe: > From: Jason Gunthorpe <jgg at mellanox.com> > > Presumably the intent here was that hmm_range_fault() could put the data > into some HW specific format and thus avoid some work. However, nothing > actually does that, and it isn't clear how anything actually could do that > as hmm_range_fault()

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason to get the invalidate_range_start() callback via an indirection through hmm_mirror, just register a normal notifier directly. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc: Ralph Campbell <rcampbell at nvidia.com> Signed-off-by: Jason Gunthorpe

Jeff Layton <jlayton at poochiereds.net> writes: > In the latest Fedora rawhide kernel in the repos, I'm seeing the > following oops when mounting xfs. rc2-ish kernels seem to be fine: > > [ 64.669633] ------------[ cut here ]------------ > [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! Hmm, that's: BUG_ON(req->nr_phys_segments + 2 >

In the latest Fedora rawhide kernel in the repos, I'm seeing the following oops when mounting xfs. rc2-ish kernels seem to be fine: [ 64.669633] ------------[ cut here ]------------ [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

In the latest Fedora rawhide kernel in the repos, I'm seeing the following oops when mounting xfs. rc2-ish kernels seem to be fine: [ 64.669633] ------------[ cut here ]------------ [ 64.670008] kernel BUG at drivers/block/virtio_blk.c:172! [ 64.670008] invalid opcode: 0000 [#1] SMP [ 64.670008] Modules linked in: xfs libcrc32c snd_hda_codec_generic snd_hda_intel snd_hda_controller

On Tue, Nov 11, 2014 at 11:42 PM, Dongsu Park <dongsu.park at profitbricks.com> wrote: > Hi Ming, > > On 11.11.2014 08:56, Ming Lei wrote: >> On Tue, Nov 11, 2014 at 7:31 AM, Jens Axboe <axboe at kernel.dk> wrote: >> > Known, I'm afraid, Ming is looking into it. > > Actually I had also tried to reproduce this bug, without success. > But today I