On 07/12/2018 10:41 PM, Kyösti Mälkki wrote:
On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson <tpearson@raptorengineering.com mailto:tpearson@raptorengineering.com> wrote:
Good to know, thanks for testing! I've been looking into relocateable ramstage in case suspend was still failing, but if things fell back into place, so to speak, in master we should also look at reactivating REACTS with the suspend tests enabled.
I never suspected RELOCATABLE_RAMSTAGE=n would be a reason for (possible) S3 regressions. The motivation for having RELOCATABLE_RAMSTAGE=y goes beyond the improvement it has on not having to do low-mem backup S3 resume path. I am also wondering how S3 resume path is taking one minute and how that relates to normal boot path time.
Kyösti
My understanding is that without relocateable ramstage, there are additional bounce buffers involved that not only slow things down, but also introduce new code paths that could be responsible for regressions in resume. I think avph on IRC is looking into an initial port of the CAR code for relocateable support, and if things are stable enough in master to reactivate the REACTS tests on the KGPE-D16 that would help him iterate more quickly.