similar to: [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL

Hi Fr?d?ric, It appears Ben made his own version of this patch (probably based on the one you added to the kernel bz), and it's already upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2 Cheers, -ilia On Thu, Feb 20, 2020 at 12:19 PM Fr?d?ric Pierret <frederic.pierret at qubes-os.org>

Dear Ben Skeggs, Please find attached a patch solving a blocking issue I encountered: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the

On Wed, Jan 29, 2020 at 05:22:13PM +0100, Fr?d?ric Pierret wrote: > Dear Ben Skeggs, > > Please find attached a patch solving a blocking issue I encountered: > https://bugzilla.kernel.org/show_bug.cgi?id=206299 > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the

Hi, Is anything missing here? How can I get this merged? Best regards, Fr?d?ric Pierret On 2020-02-08 20:43, Fr?d?ric Pierret wrote: > Pointer to structure array is assumed not NULL by default. It has > the consequence to raise a kernel panic when it's not the case. > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd'

From: Colin Ian King <colin.king at canonical.com> The constant values being shifted are 32 bit integers and may potentially overflow on the shift. Avoid this potential overflow by making them unsigned long long values before the shift. Detected by CoverityScan, CID#1469383, 1469400 ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king at

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

Hello Ben Skeggs, The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts" from May 8, 2018, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:169 nv50_disp_chan_intr() warn: should '65537 << chan->chid.user' be a 64 bit type?

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Ian Romanick reported a kernel crash that implicated this path in a null pointer jump, which means that one of the function pointers had been nulled out. Not sure if a race there would explain it, but maybe. There is also questionable ramht usage in channv50 and various disp code. If you think this is a

We get 2 warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] In fact, these functions are declared in

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous

We get some warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous prototype for 'nv50_grctx_fill' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1:

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM

MSI interrupts appear to not work for nv46 based cards. Change the mc subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is identical to the nv44 mc code except that it does not use msi (it does not define a msi_rearm callback). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435 Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

On Thu, Feb 2, 2017 at 5:09 PM, Phil Turmel <philip at turmel.org> wrote: > On 02/02/2017 05:01 PM, Ilia Mirkin wrote: > >> Note that a lot of this stuff has been redone for kernel 4.10 to >> conform to atomic modesetting. I wouldn't be surprised if that >> jiggers things around enough to fix your issue. But perhaps not. >> Worth a shot. [As an aside, this