[Letux-kernel] Lockup inside omap4_prminst_read_inst_reg on OMAP5 uEVM
dave at ds0.me
Mon Aug 17 10:18:49 CEST 2020
On Mon, 2020-08-17 at 09:38 +0300, Tony Lindgren wrote:
> * David Shah <dave at ds0.me> [200816 20:13]:
> > It seems like 'CSWR' idle may never have actually worked properly on
> > the OMAP5...
> > As an experiment, I took the old TI 3.8.y GLSDK kernel,
> > commit 2c871a879dbb4234232126f7075468d5bf0a50e3 and made the following
> > changes:
> > - Enabling CONFIG_CPU_IDLE as this was not in omap2plus_defconfig back
> > then
> > - Disabling all the kernel debugging related config, as these seem to
> > significantly reduce the frequency of lockups
> > - OSWR idle disabled, as this is known broken
> > - Some small patches to get it working with gcc9, none of which
> > touched any power management or idle code.
> > And I saw lockups with an almost identical frequency to 5.6 and 5.7
> > with a similar config; and the same pipeline stalled error reported by
> > CCS when connecting over JTAG. The only difference is the reported PC
> > was a read instruction inside sched_clock rather
> > than omap4_prminst_read_inst_reg.
> > Would be interested to know if there is a backstory here? Could it be
> > related to the bugs that stopped OSWR from working? Is there a glsdk
> > kernel version that I missed where CSWR on the OMAP5 actually works
> > reliably.
> > If anyone wants to try reproducing this; the most important settings
> > are:
> > - CONFIG_CPU_IDLE=y
> > - All kernel debugging settings disabled
> > - CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> > This will usually result in a lockup while idle at a login prompt
> > within a few hours with no other hardware connected. A lockup usually
> > occurs sooner (within 30 minutes) repeatedly wget'ing a 100MB test file
> > in a loop.
> Care to check if this happens with current mainline kernel and sgx
> The reason I'm asking is I used a pi-top with a omap5-igep0050 board as
> a test laptop with the mainline kernel for about two years until I managed
> to break the UART connector on it a few years ago :) I sure had things
> working reliably with no hangs with cpuidle enabled with LPAE. This was
> with the pi-top HDMI panel without sgx.
That's a good idea, I'll try that.
> Also please see if this happens with omap5-uevm too. There pyra related
> DDR self-refresh related hangs should be out of the AFAIK, but still
> worth testing.
Most of my testing so far has been on the the uEVM, due to easier JTAG access.
For some reason that I have not yet identified, the uEVM actually locks up
slightly more frequently than the Pyra.
I wonder if there is some hardware difference going on, I know a few other
people have had good experiences with the IGEP on older mainline kernels too.
More information about the Letux-kernel