[Letux-kernel] Lockup inside omap4_prminst_read_inst_reg on OMAP5 uEVM
tony at atomide.com
Mon Aug 17 08:38:35 CEST 2020
* 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
> - Enabling CONFIG_CPU_IDLE as this was not in omap2plus_defconfig back
> - 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
> If anyone wants to try reproducing this; the most important settings
> - 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.
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
More information about the Letux-kernel