On Mon, 2024-04-29 at 17:30 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> TWIMC, there is another report about this in this thread (sadly some of
> its post did not make it to lore):
>
> https://lore.kernel.org/all/162ef3c0-1d7b-4220-a21f-b0008657f...@redhat.com/
>
> Ciao,
On Sun, 2024-04-28 at 11:52 -0400, Lyude Paul wrote:
> But we can't get a page pointer from an allocation made by
> dma_alloc_coherent() - but we can from vmalloc(). I'll fix the patch
> explanation in the next version, I have to send out another version
> anyhow since I realized that patch #2
On Fri, 2024-04-26 at 11:41 -0400, Lyude Paul wrote:
> We hit this because when initializing firmware of type
> NVKM_FIRMWARE_IMG_DMA we allocate coherent memory and then attempt to
> include that coherent memory in a scatterlist.
I'm sure this patch is a good one, and I will try to test it
On Mon, 2024-04-08 at 16:42 +1000, Dave Airlie wrote:
> This reverts:
> nouveau/gsp: don't check devinit disable on GSP.
> and applies a further fix.
>
> It turns out the open gpu driver, checks this register, but only for
> display.
>
> Match that behaviour and only disable displays on turings.
On Tue, 2024-03-26 at 15:51 +0100, Arnd Bergmann wrote:
> Calling a function through an incompatible pointer type causes breaks
> kcfi, so clang warns about the assignment:
>
...
> +static void of_fini(void *p)
> +{
> + return kfree(p);
> +}
> +
I don't know anything about kfci, but
On Mon, 2024-03-11 at 17:20 +1000, Dave Airlie wrote:
> Later attempts to refault the bo won't happen and the whole
> GPU does to lunch. I think Christian's refactoring of this
Typo: I think you meant "goes to lunch".
On Wed, 2024-03-06 at 02:14 +0800, kernel test robot wrote:
> > |-- drivers-gpu-drm-nouveau-nvkm-subdev-gsp-r535.c:warning:Function-
> > parameter-or-struct-member-gsp-not-described-in-nvkm_gsp_radix3_sg
Could someone please apply
On Sun, Mar 3, 2024 at 4:46 AM Duoming Zhou wrote:
>
> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
> the physical memory has run out. As a result, if we dereference
> src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
> will happen.
>
> This patch uses stack
On Fri, Mar 1, 2024 at 2:23 AM Sid Pranjale
wrote:
>
> Nouveau deallocates a few buffers post GPU init which are required for GPU
> suspend/resume to function correctly.
> This is likely not as big an issue on systems where the NVGPU is the only
> GPU, but on multi-GPU set ups it leads to a
On Mon, 2024-02-19 at 10:32 +0100, Danilo Krummrich wrote:
Looks like I spoke too soon, I just hit the problem with the drm-next tree.
Did you apply the patch to drm-next?
Ugh, you're right. I don't how I got confused, but I could have sworn that I
saw your two patches in drm-next, but they
On Fri, 2024-02-02 at 17:14 +, Timur Tabi wrote:
> On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote:
> > nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> > their corresponding *_fini() counterpart. This can lead to
> > nouveau_sched_fini()
On Tue, 2024-02-13 at 16:43 +0100, Danilo Krummrich wrote:
> > +struct registry_list_entry {
> > + struct list_head list;
>
> Nit: 'head' or 'entry' might be more suitable.
Will fix in v4.
>
> > + size_t name_len;
> > + u32 type;
>
> I prefer to represent type as enum or use a define
On Tue, 2024-02-13 at 17:57 +0100, Danilo Krummrich wrote:
+ struct debugfs_blob_wrapper blob_init;
+ struct debugfs_blob_wrapper blob_intr;
+ struct debugfs_blob_wrapper blob_rm;
+ struct debugfs_blob_wrapper blob_pmu;
+ struct dentry *debugfs_logging_dir;
I
are ignored.
Signed-off-by: Timur Tabi
---
v3: reworked r535_gsp_libos_debugfs_init, rebased for drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 12 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 215 +-
2 files changed, 223 insertions(+), 4 deletions(-)
diff --git
.
The name and format of NVreg_RegistryDwords is the same as used by
the Nvidia driver, to maintain compatibility.
Signed-off-by: Timur Tabi
---
v3: rebased to drm-next
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 6 +
.../gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 279 --
2
Two patches that were previosly posted, but now updated for drm-next.
Timur Tabi (2):
[v3] nouveau: add command-line GSP-RM registry support
[v3] drm/nouveau: expose GSP-RM logging buffers via debugfs
.../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 18 +
.../gpu/drm/nouveau/nvkm/subdev/gsp
On Fri, 2024-02-02 at 01:05 +0100, Danilo Krummrich wrote:
> nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call
> their corresponding *_fini() counterpart. This can lead to
> nouveau_sched_fini() being called without struct nouveau_sched ever
> being initialized in the first
On Thu, Dec 21, 2023, 10:33 PM Dave Airlie wrote:
> This should let the upper layers retry as needed on EAGAIN.
>
> There may be other values we will care about in the future, but
> this covers our present needs.
>
> Signed-off-by: Dave Airlie
>
> +static int
>
On Mon, 2023-12-11 at 08:53 -0500, Sasha Levin wrote:
> This is a hack around a bug exposed with the GSP code, I'm not sure
> what is happening exactly, but it appears some of our flushes don't
> result in proper tlb invalidation for out BAR2 and we get a BAR2
> fault from GSP and it all dies.
Do
On Tue, 2023-12-05 at 12:01 +1000, Dave Airlie wrote:
> These can happen in normal operations esp with auxch transactions.
>
> Gets rid of
> nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073 ctrl cmd:0x00731341
> failed: 0x
> in logs.
Is this something you want me to look into?
On Tue, 2023-12-05 at 10:01 +1000, Dave Airlie wrote:
> The current code prints a message when we get a callback we don't
> handle, this silences those, but maybe I should just silence them.
How about this:
In r535_gsp_msg_recv():
if (ntfy->fn && (ntfy->fn == msg->function)) {
On Tue, 2023-12-05 at 08:55 +1000, Dave Airlie wrote:
> +static int
> +r535_gsp_msg_ucode_libos_print(void *priv, u32 fn, void *repv, u32 repc)
> +{
> + /* work out what we should do here. */
> + return 0;
> +}
This is part of my logrm debugfs patch. It contains the printf log from a
On Mon, 2023-12-04 at 09:51 +0100, Gert Vanhaerents wrote:
> OK i will report it to nvidia. But with the nouveau drivers it's also not
> working. Are you sure it's not a kernel problem?
> Because according to systemd it would be a kernel problem. (personaly i am
> also thinking it's a driver
On Sat, 2023-12-02 at 09:13 -0800, Marc MERLIN wrote:
> [ 3.184525] nouveau: unknown parameter 'modset' ignored
For starters, you misspelled "modeset"
On Sat, 2023-12-02 at 20:18 +0700, Bagas Sanjaya wrote:
>
> > When i install the proprietary Nvidia drivers, i have the following:
> >
> > [MASTER] pci::08:00.0
> > │ ├─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0
> > │ │ [MASTER] drm:card0
> > │
On Thu, 2023-11-30 at 22:58 +0800, kernel test robot wrote:
> If you fix the issue in a separate patch/commit (i.e. not just a new
> version of
> the same patch/commit), kindly add following tags
> > Reported-by: kernel test robot
> > Closes:
On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> rpc->size = sizeof(*rpc);
> - rpc->numEntries = 1;
> - rpc->entries[0].nameOffset = offsetof(typeof(*rpc), entries[1]);
> - rpc->entries[0].type = 1;
> - rpc->entries[0].data = 0;
> -
: Dan Carpenter
Nice catch!
Reviewed-by: Timur Tabi
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
> As I already mentioned for Timur's patch [2], I'd prefer to get a fix
> upstream
> (meaning [1] in this case). Of course, that's probably more up to Timur to
> tell
> if this will work out.
Don't count on it.
Even if I did change [0]
On Thu, 2023-11-16 at 12:11 -0600, Gustavo A. R. Silva wrote:
typedef struct PACKED_REGISTRY_TABLE
{
-NvU32 size;
-NvU32 numEntries;
-PACKED_REGISTRY_ENTRY entries[0];
+ NvU32 size;
+ NvU32
On Wed, 2023-11-08 at 00:52 +0100, Danilo Krummrich wrote:
> On 11/8/23 00:47, Timur Tabi wrote:
> > Change PACKED_REGISTRY_TABLE so that its last member is a variable-
> > length
> > array instead of a zero-length array. UBSAN treats zero-length arrays
&g
u/gsp: move to 535.113.01")
Signed-off-by: Timur Tabi
---
.../include/nvrm/535.113.01/nvidia/generated/g_os_nvoc.h| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/generated/g_os_nvoc.h
b/drivers/gpu/drm/nouveau/
On Wed, 2023-11-08 at 04:54 +1000, Dave Airlie wrote:
yes that is probably the right answer for this, if we want to reuse
the structs that we get from the nvidia driver.
ok, I'll submit a patch.
On Tue, 2023-10-31 at 15:18 +1000, Dave Airlie wrote:
+ strings = (char *)>entries[NV_GSP_REG_NUM_ENTRIES];
I get a UBSAN index-out-of-bounds error on boot at this line.
[ 17.765746] nouveau :65:00.0: gsp: cmdq: wptr 1
[ 17.765748]
On Wed, 2023-11-01 at 05:29 +1000, Dave Airlie wrote:
> >
> > static const struct nv_gsp_registry_entries r535_registry_entries[] = {
> > { "RMSecBusResetEnable", 1 },
> > { "RMForcePcieConfigSave", 1 },
> > };
> >
> > #define NV_GSP_REG_NUM_ENTRIES
On Tue, Oct 31, 2023 at 12:20 AM Dave Airlie wrote:
> +#define NV_GSP_REG_NUM_ENTRIES 2
> +
> +static const struct nv_gsp_registry_entries
> r535_registry_entries[NV_GSP_REG_NUM_ENTRIES] = {
> + { "RMSecBusResetEnable", 1 },
> + { "RMForcePcieConfigSave", 1 },
> +};
How about :
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> +static int
> +gt215_sor_bl_set(struct nvkm_ior *ior, int lvl)
> +{
> + struct nvkm_device *device = ior->disp->engine.subdev.device;
> + const u32 soff = nv50_ior_base(ior);
> + u32 div, val;
> +
> + div =
do a thorough review, but I did look over the patches and provided
some feedback.
So, for what it's worth,
Reviewed-by: Timur Tabi
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> + /*
> + * FIXME: This is a hack to workaround the
> following
> + * issues:
> + *
> + *
>
On Tue, 2023-09-19 at 17:56 -0400, Lyude Paul wrote:
> + NVIF_CONN_VGA,
> + NVIF_CONN_TV,
> + NVIF_CONN_DVI_I,
> + NVIF_CONN_DVI_D,
> + NVIF_CONN_LVDS,
> +
On Tue, Mar 7, 2023 at 2:28 AM Thomas Zimmermann wrote:
> > So after module_init is finished, mode_option_buf[] no longer exists?
>
> Does the __init attribute on a function affect the static variables in
> that function?
That is an excellent question.
On Mon, Mar 6, 2023 at 10:01 AM Thomas Zimmermann wrote:
>
> Assume that the driver does not own the option string or its substrings
> and hence duplicate the option string for the video mode. The driver only
> parses the option string once as part of module initialization, so use
> a static
On Sun, Sep 4, 2022 at 4:48 PM Jim Cromie wrote:
>
> These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
> respectively, replace those with drm_dbg_##cat invocations.
>
> this results in new class'd prdbg callsites:
>
> :#> grep nouveau /proc/dynamic_debug/control | grep class | wc
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on >cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
___
dri-devel mail
e, but I'm going to
have to assume that you know what you're doing.
Acked-by: Timur Tabi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
assignments.
[1]https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
Acked-by: Timur Tabi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman
On 05/16/2018 01:23 PM, Sinan Kaya wrote:
+ win_start = window->res->start - window->offset;
Can you guarantee that window->res->start is always >= window->offset?
+ win_size = window->res->end - window->res->start + 1;
Use resource_size() instead.
--
Qualcomm
Markus Elfring<elfr...@users.sourceforge.net>
Acked-by: Timur Tabi <ti...@tabi.org>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
48 matches
Mail list logo
