[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DFVDC5NWTOT4.NA2H05V84CWD@kernel.org>
Date: Thu, 22 Jan 2026 20:35:12 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Jon Hunter" <jonathanh@...dia.com>
Cc: "Gui-Dong Han" <hanguidong02@...il.com>, "Marek Szyprowski"
<m.szyprowski@...sung.com>, "Mark Brown" <broonie@...nel.org>,
<gregkh@...uxfoundation.org>, <rafael@...nel.org>,
<linux-kernel@...r.kernel.org>, <baijiaju1990@...il.com>, "Qiu-ji Chen"
<chenqiuji666@...il.com>, <Aishwarya.TCV@....com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v5] driver core: enforce device_lock for
driver_match_device()
On Thu Jan 22, 2026 at 7:58 PM CET, Jon Hunter wrote:
> On 22/01/2026 18:12, Danilo Krummrich wrote:
>> With this diff, if I intentionally create a deadlock condition on my machine, I
>> do see a lockdep splat as expected.
>>
>> Anyways, another option would be to attach a hardware debugger (I assume you
>> have TRACE32 or something available?) and then get a backtrace from the CPU
>> affected of the deadlock.
>
> Unfortunately, these days I don't have such tools available so that's
> not an option.
Hm..slowly running out of options. :)
I remember you previously said that you can still SSH into the machine? If so,
can you please share the the first output of
echo l > /proc/sysrq-trigger
directly after booting?
Subsequently, can you please also run
echo w > /proc/sysrq-trigger
and
echo t > /proc/sysrq-trigger
If the output of the last shows a task in D state, you can also run
cat /proc/$PID/stack
Also, are there any OOT modules loaded?
Thanks,
Danilo
Powered by blists - more mailing lists