Hi, * David Shah <dave@xxxxxx> [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 disabled? 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 worth testing. Regards, Tony
