linux-kernel - Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c3a2767b-5f2e-4a9e-a700-713e542d9214@nvidia.com>
Date: Fri, 19 Dec 2025 11:05:42 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Thierry Reding
 <thierry.reding@...il.com>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling


On 18/12/2025 21:20, Aaron Kling wrote:

...

> Turns out, this is actually semi-operable. There's a blocklist in the
> cpufreq-dt driver that includes all tegra archs <= t234 except for
> t186 and t194. If I add t194 to that list, then the log lines go away.
> However, it does not fix the nfs boot issue. I was finally able to
> replicate it by setting up my own nfs rootfs. This series does not
> affect it though, fwiw, it's the dt series that triggers this. Before
> it, nfsroot boots as expected. After it, the reported issue happens.
> After adding t194 to the cpufreq-dt blocklist, the issue still
> happens. But... if I add "blacklist=cpufreq-dt" to the kernel
> bootargs, nfs works again. I don't get this.
> 
> So, summary:
> * Adding opp tables to the cpu nodes causes cpufreq-dt to try to
> handle cpufreq for the soc
> * Adding tegra194 to the cpufreq-dt-platdev blocklist stops log
> messages about the attempt
> * However, it still affects the ethernet driver, causing watchdog
> timeouts and adapter resets
> * Blacklisting the cpufreq-dt driver entirely prevents the issue
> 
> I'm not sure what to make of this. Anyone have thoughts? I will send a
> patch separately to add t186 and t194 to the cpufreq-dt-platdev block
> list as this needs to happen in any case.

Great glad you see the same and thanks for the summary.

Have you looked at what the CPU and EMC frequencies are doing? I still 
don't understand the connection to the ethernet driver.

Have you tried setting the performance governor for CPUFREQ to see if 
that works? That would tell us if the CPU speed is related.

Jon

-- 
nvpublic