From: "Thierry Reding" <thierry.reding@gmail.com>
To: "Jon Hunter" <jonathanh@nvidia.com>,
"Diogo Ivo" <diogo.ivo@tecnico.ulisboa.pt>,
"Robin Murphy" <robin.murphy@arm.com>
Cc: "Jason Gunthorpe" <jgg@ziepe.ca>, <vdumpa@nvidia.com>,
<joro@8bytes.org>, <will@kernel.org>, <baolu.lu@linux.intel.com>,
<jsnitsel@redhat.com>, <jroedel@suse.de>,
<linux-tegra@vger.kernel.org>, <iommu@lists.linux.dev>,
<regressions@lists.linux.dev>
Subject: Re: [REGRESSION] Failed buffer allocation in Tegra fbdev
Date: Thu, 29 Feb 2024 17:46:10 +0100 [thread overview]
Message-ID: <CZHPR7BLVDWK.3I71VAJO1OSNZ@gmail.com> (raw)
In-Reply-To: <02a8d225-99cd-4dfe-bf49-b002aaa045d1@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]
On Thu Feb 29, 2024 at 3:50 PM CET, Jon Hunter wrote:
>
> On 24/01/2024 12:56, Diogo Ivo wrote:
>
> ...
>
> >>> I did the tracing and found that the ENOENT is coming from
> >>> sysfs_do_create_link_sd() in the following function call chain:
> >>>
> >>> of_iommu_configure() -> iommu_probe_device() -> __iommu_probe_device() ->
> >>
> >> What's the call path leading up to that? If it's the one from
> >> host1x_device_add() then it's expected and benign - for fiddly reasons,
> >> iommu_probe_device() ends up being called too early, but will soon be run
> >> again in the correct circumstances once we proceed into
> >> host1x_subdev_register()->device_add(). That will have been happening for
> >> years, we just never reported errors in that spot before (and frankly I'm
> >> not convinced it's valuable to have added it now).
> >>
> >> Thanks,
> >> Robin.
> >
> > Yes, it is the one called from host1x_device_add(), so this
> > is solved and only the patch sent above needs to be merged.
>
>
> Sorry for the delay in getting back to this. I have been doing more
> testing and the backtrace I see from this warning is ...
>
> [ 7.001380] drm: iommu configuration for device failed with -ENOENT
> [ 7.001550] CPU: 4 PID: 263 Comm: systemd-udevd Not tainted 6.8.0-rc6-gbbe953beb8b9-dirty #2
> [ 7.001559] Hardware name: NVIDIA Jetson AGX Xavier Developer Kit (DT)
> [ 7.001564] Call trace:
> [ 7.001568] dump_backtrace.part.6+0x84/0xdc
> [ 7.001583] show_stack+0x14/0x1c
> [ 7.001590] dump_stack_lvl+0x48/0x5c
> [ 7.001600] dump_stack+0x14/0x1c
> [ 7.001606] of_dma_configure_id+0x218/0x400
> [ 7.001636] host1x_attach_driver+0x150/0x2d0 [host1x]
> [ 7.001664] host1x_driver_register_full+0x7c/0xdc [host1x]
> [ 7.001711] host1x_drm_init+0x3c/0x1000 [tegra_drm]
> [ 7.001746] do_one_initcall+0x58/0x1c0
> [ 7.001752] do_init_module+0x54/0x1d8
> [ 7.001761] load_module+0x18b8/0x18ec
> [ 7.001770] init_module_from_file+0x8c/0xc8
> [ 7.001777] __arm64_sys_finit_module+0x1c4/0x29c
> [ 7.001784] invoke_syscall+0x40/0xf4
> [ 7.001792] el0_svc_common.constprop.1+0xc4/0xec
> [ 7.001814] do_el0_svc+0x18/0x20
> [ 7.001820] el0_svc+0x28/0x90
> [ 7.001826] el0t_64_sync_handler+0x9c/0xc0
> [ 7.001845] el0t_64_sync+0x160/0x164
>
>
> I could have sworn that this was coming from
> host1x_memory_context_list_init() but that is not the case.
>
> Anyway, we have a test that checks for warnings/errors and this
> is causing that test to fail. Even if this particular instance
> of error is benign we would still like to trap any instances
> that are not. So is there something we can fix here to avoid
> this?
I was wondering why I wasn't seeing this and looking through some of the
code I noticed that I have commented out the of_dma_configure() call in
host1x_device_add() in my local development tree. I probably came across
this at some point while trying to fix something else with the intention
of getting back to it but then never did.
Anyway, let me try to refresh my memory and take a stab at fixing this.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-29 16:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 14:33 [REGRESSION] Failed buffer allocation in Tegra fbdev diogo.ivo
2024-01-23 15:15 ` Jason Gunthorpe
2024-01-23 18:44 ` Diogo Ivo
2024-01-24 10:15 ` Jon Hunter
2024-01-24 10:30 ` Diogo Ivo
2024-01-24 10:36 ` Jon Hunter
2024-01-26 19:51 ` Jason Gunthorpe
2024-01-29 12:07 ` Diogo Ivo
2024-01-24 9:13 ` Diogo Ivo
2024-01-24 10:17 ` Jon Hunter
2024-01-24 11:46 ` Robin Murphy
2024-01-24 12:56 ` Diogo Ivo
2024-02-29 14:50 ` Jon Hunter
2024-02-29 16:46 ` Thierry Reding [this message]
2024-01-24 17:03 ` Jason Gunthorpe
2024-02-08 1:22 ` Robin Murphy
2024-02-08 2:31 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CZHPR7BLVDWK.3I71VAJO1OSNZ@gmail.com \
--to=thierry.reding@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=diogo.ivo@tecnico.ulisboa.pt \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=jsnitsel@redhat.com \
--cc=linux-tegra@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=vdumpa@nvidia.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).