[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae11deb4-abec-f0f9-312d-b11d72bc74cd@nvidia.com>
Date: Tue, 23 Jul 2019 22:39:29 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Robin Murphy <robin.murphy@....com>,
Jose Abreu <Jose.Abreu@...opsys.com>,
Lars Persson <lists@...h.nu>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>
CC: Joao Pinto <Joao.Pinto@...opsys.com>,
Alexandre Torgue <alexandre.torgue@...com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
Chen-Yu Tsai <wens@...e.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
linux-tegra <linux-tegra@...r.kernel.org>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
"David S . Miller" <davem@...emloft.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page
Pool
On 23/07/2019 14:19, Robin Murphy wrote:
...
>>> Do you know if the SMMU interrupts are working correctly? If not, it's
>>> possible that an incorrect address or mapping direction could lead to
>>> the DMA transaction just being silently terminated without any fault
>>> indication, which generally presents as inexplicable weirdness (I've
>>> certainly seen that on another platform with the mix of an unsupported
>>> interrupt controller and an 'imperfect' ethernet driver).
>>
>> If I simply remove the iommu node for the ethernet controller, then I
>> see lots of ...
>>
>> [ 6.296121] arm-smmu 12000000.iommu: Unexpected global fault, this
>> could be serious
>> [ 6.296125] arm-smmu 12000000.iommu: GFSR 0x00000002,
>> GFSYNR0 0x00000000, GFSYNR1 0x00000014, GFSYNR2 0x00000000
>>
>> So I assume that this is triggering the SMMU interrupt correctly.
>
> According to tegra186.dtsi it appears you're using the MMU-500 combined
> interrupt, so if global faults are being delivered then context faults
> *should* also, but I'd be inclined to try a quick hack of the relevant
> stmmac_desc_ops::set_addr callback to write some bogus unmapped address
> just to make sure arm_smmu_context_fault() then screams as expected, and
> we're not missing anything else.
I hacked the driver and forced the address to zero for a test and
in doing so I see ...
[ 10.440072] arm-smmu 12000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1c0011, cbfrsynra=0x14, cb=0
So looks like the interrupts are working AFAICT.
Cheers
Jon
--
nvpublic
Powered by blists - more mailing lists