<div dir="ltr">Sorry to post in this huge email bunch.<div><br></div><div>I have most probably hit an errata in Freescale T4240 for PPC_DISABLE_THREADS. I'm using Rev2 - T4240. Is this Errata required to be taken care or not? Any quick help is appreciated! </div><div><br></div><div>My issue: I'm running line rate of Traffic to T4240 [10G of traffic on each port of capacity of 10G]; After few hours of running of traffic, My CPU/LMP gets stuck and goes in for Hard reset. When I searched through the code and some open forums, I saw the errata listed above. I'm not sure if that errata works for me or not. I have pasted a snapshot of issue occuring in my system</div><div><br></div><div>============================================</div><div><p class="gmail-MsoListParagraph"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">During hang, with Softlock up enabled, I get prints from smp_many ->
showing ‘every processor is waiting for processor 22’ ; I need to know what
happened to processor 22. The processor number keep changing every time when I run the traffic.<span></span></span></p>
<p class="gmail-MsoListParagraph"><span style="color:rgb(31,73,125);font-family:calibri,sans-serif;font-size:11pt">Processor 22 goes into a deadlock
state with interrupts disabled or it went into a deep idle sleep state is the
issue i feel.</span><br></p>
<p class="gmail-MsoListParagraph"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">If its deep idle state -> a NMI
should have recovered it.<span></span></span></p>
<p class="gmail-MsoListParagraph"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">But if it’s a deadlock issue with
interrupt disabled then I need to know the root cause for the deadlock.<span></span></span></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">root@A@0-1-1:~# [
1602.261011] Current::17 waiting::22 flag::4353 [ 1602.720488] Current::14
waiting::22 flag::3585 [ 1602.756404] Current::15 waiting::22 flag::3841 [
1604.903248] Current::16 waiting::22 flag::4097 [ 1619.400917] Current::14
waiting::22 flag::3585 [ 1619.517870] Current::17 waiting::22 flag::4353 [
1619.749893] Current::15 waiting::22 flag::3841 [ 1619.798453] Current::4
waiting::22 flag::1025 [ 1622.177171] Current::16 waiting::22 flag::4097 [
1622.449412] INFO: rcu_preempt detected stalls on CPUs/tasks: { 22} (detected
by 4, t=21008 jiffies, g=101651, c=101650, q=4713) [ 1622.460951] Task dump for
CPU 22:<span></span></span></i></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">[ 1622.464275]
swapper/22 R running
task 0
0 1 0x00000800<span></span></span></i></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">[ 1622.471355] Call Trace:<span></span></span></i></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">[ 1622.473820] [c0000001f92b78d0]
[000000000000009e] 0x9e (unreliable) [ 1622.480119] [c0000001f92b7960]
[c0000001f92b7aa0] 0xc0000001f92b7aa0 [ 1622.486497] [c0000001f92b79e0]
[c000000000a90275] 0xc000000000a90275 [ 1622.492878] [c0000001f92b7a60]
[c000000000006f64] .do_IRQ+0x184/0x370 [ 1622.499344] [c0000001f92b7b10]
[c00000000001b93c] exc_0x500_common+0xfc/0x100 [ 1622.506539] --- Exception:
501 at 0xc000000000a3e200<span></span></span></i></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">[
1622.506539] LR = .__check_irq_replay+0x68/0x110<span></span></span></i></p>
<p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">[ 1622.516388] [c0000001f92b7e00]
[c0000000000bc590] .cpu_startup_entry+0x1d0/0x350 (unreliable) [ 1622.524950]
[c0000001f92b7ed0] [c000000000a00460] .start_secondary+0x3ec/0x3f4 [
1622.532197] [c0000001f92b7f90] [c00000000000036c]
.start_secondary_prolog+0x10/0x14 [ 1635.237829] Current::3 waiting::5
flag::769 [ 1636.587746] Current::14 waiting::22 flag::3585 [ 1637.082117]
Current::17 waiting::22 flag::4353 [ 1637.224920] Current::4 waiting::22
flag::1025 [ 1637.268789] Current::15 waiting::22 flag::3841 [ 1640.085792]
Current::16 waiting::22 flag::4097 [ 1651.093367] Current::4 waiting::22
flag::1025</span></i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><span></span></span></p><p class="gmail-MsoListParagraph"><i><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">=============================================================</span></i></p><p class="gmail-MsoListParagraph"><font color="#1f497d" face="calibri, sans-serif"><span style="font-size:14.6667px">Regards,</span></font></p><p class="gmail-MsoListParagraph"><font color="#1f497d" face="calibri, sans-serif"><span style="font-size:14.6667px">Kiran</span></font></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 4:40 PM, Arnd Bergmann <span dir="ltr"><<a href="mailto:arnd@arndb.de" target="_blank">arnd@arndb.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:<br>
> > -----Original Message-----<br>
> > From: Arnd Bergmann [mailto:<a href="mailto:arnd@arndb.de">arnd@arndb.de</a>]<br>
> > Sent: Thursday, May 05, 2016 4:32 PM<br>
> > To: <a href="mailto:linuxppc-dev@lists.ozlabs.org">linuxppc-dev@lists.ozlabs.org</a><br>
> > Cc: Yangbo Lu; <a href="mailto:linux-mmc@vger.kernel.org">linux-mmc@vger.kernel.org</a>; <a href="mailto:devicetree@vger.kernel.org">devicetree@vger.kernel.org</a>;<br>
> > <a href="mailto:linux-arm-kernel@lists.infradead.org">linux-arm-kernel@lists.<wbr>infradead.org</a>; <a href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>;<br>
> > <a href="mailto:linux-clk@vger.kernel.org">linux-clk@vger.kernel.org</a>; <a href="mailto:linux-i2c@vger.kernel.org">linux-i2c@vger.kernel.org</a>; iommu@lists.linux-<br>
> > <a href="http://foundation.org" rel="noreferrer" target="_blank">foundation.org</a>; <a href="mailto:netdev@vger.kernel.org">netdev@vger.kernel.org</a>; Mark Rutland;<br>
> > <a href="mailto:ulf.hansson@linaro.org">ulf.hansson@linaro.org</a>; Russell King; Bhupesh Sharma; Joerg Roedel;<br>
> > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil;<br>
> > Kumar Gala; Xiaobo Xie; Qiang Zhao<br>
> > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-<br>
> > R1.0-R2.0<br>
> ><br>
> > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:<br>
> > ><br>
> > > + fsl_guts_init();<br>
> > > + svr = fsl_guts_get_svr();<br>
> > > + if (svr) {<br>
> > > + esdhc->soc_ver = SVR_SOC_VER(svr);<br>
> > > + esdhc->soc_rev = SVR_REV(svr);<br>
> > > + } else {<br>
> > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");<br>
> > > + }<br>
> > > +<br>
> > ><br>
> ><br>
> ><br>
> > Sorry for jumping in again after not participating in the discussion for<br>
> > the past few versions.<br>
> ><br>
> > What happened to my suggestion of making this a platform-independent<br>
> > interface to avoid the link time dependency?<br>
> ><br>
> > Specifically, why not add an exported function to drivers/base/soc.c that<br>
> > uses glob_match() for comparing a string in the device driver to the ID<br>
> > of the SoC that is set by whatever SoC identifying driver the platform<br>
> > has?<br>
><br>
</div></div><span class="">> [Lu Yangbo-B47093] I think this has been discussed in v6.<br>
> You can find Scott's comments about this in below link.<br>
> <a href="https://patchwork.kernel.org/patch/8544501/" rel="noreferrer" target="_blank">https://patchwork.kernel.org/<wbr>patch/8544501/</a><br>
<br>
</span>Ah, thanks for bearing with me and digging this out again. Let me follow<br>
up on Scott's older replies here then:<br>
<br>
> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't<br>
> >> even compile on !PPC. It is things like this that prevent sharing the<br>
> >> driver.<br>
><br>
> The whole point of using the MMIO SVR instead of the PPC SPR is so that<br>
> it will work on ARM... The guts driver should build on any platform as<br>
> long as OF is enabled, and if it doesn't find a node to bind to it will<br>
> return 0 for SVR, and the eSDHC driver will continue (after printing an<br>
> error that should be removed) without the ability to test for errata<br>
> based on SVR.<br>
<br>
It feels like a bad design to have to come up with a different<br>
method for each SoC type here when they all do the same thing<br>
and want to identify some variant of the chip to do device<br>
specific quirks.<br>
<br>
As far as I'm concerned, every driver in drivers/soc that needs to<br>
export a symbol to be used by a device driver is an indication that<br>
we don't have the right set of abstractions yet. There are cases<br>
that are not worth abstracting because the functionality is rather<br>
obscure and only a couple of drivers for one particular chip<br>
ever need it.<br>
<br>
Finding out the version of the SoC does not look like this case.<br>
<br>
> > I think the first four patches take care of building for ARM,<br>
> > but the problem remains if you want to enable COMPILE_TEST as<br>
> > we need for certain automated checking.<br>
><br>
> What specific problem is there with COMPILE_TEST?<br>
<br>
COMPILE_TEST is solvable here and the way it is implemented in this<br>
case (selecting FSL_GUTS from the driver) indeed looks like it works<br>
correctly, but it's still awkward that this means building the<br>
SoC specific ID stuff into the vmlinux binary for any driver that<br>
uses something like that for a particular SoC.<br>
<br>
> >> Dealing with Si revs is a common problem. We should have a<br>
> >> common solution. There is soc_device for this purpose.<br>
> ><br>
> > Exactly. The last time this came up, I think we agreed to implement a<br>
> > helper using glob_match() on the soc_device strings. Unfortunately<br>
> > this hasn't happened then, but I'd still prefer that over yet another<br>
> > vendor-specific way of dealing with the generic issue.<br>
><br>
> soc_device would require encoding the SVR as a string and then decoding<br>
> the string, which is more complicated and error prone than having<br>
> platform-specific code test a platform-specific number.<br>
<br>
You already need to encode it as a string to register the soc_device,<br>
and the driver just needs to pass a glob string, so the only part that<br>
is missing is the generic function that takes the string from the<br>
driver and passes that to glob_match for the soc_device.<br>
<br>
> And when would it get registered on arm64, which doesn't have<br>
> platform code?<br>
<br>
Whenever the soc driver is loaded, as is the case now. The match<br>
function can return -EPROBE_DEFER if no SoC device is registered<br>
yet.<br>
<span class="HOEnZb"><font color="#888888"><br>
Arnd<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Linuxppc-dev mailing list<br>
<a href="mailto:Linuxppc-dev@lists.ozlabs.org">Linuxppc-dev@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" rel="noreferrer" target="_blank">https://lists.ozlabs.org/<wbr>listinfo/linuxppc-dev</a></div></div></blockquote></div><br></div>