Hi Tony, On Mon, 2020-08-17 at 09:38 +0300, Tony Lindgren wrote: > 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. > 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. > Regards, > > Tony
