Re: [coreboot] [RFH] Native AMD fam10-15 support
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. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
I will provide logs soon! what do you want exactly? One apparent regression I have noticed is that "sensors" reports CPU power usage at idle is now steady at 101W vs the usual 50W (which used to be 40 before a kernel update) while I am not sure if it is accurate as the cpu temp doesn't reach high levels expected for such wattage it does have one bad effect in that Turbo 2 no longer works...and even before this update with my v4.6 to get Turbo 1 on all cores as AMD advertises I must use "tpc -psmax 1"[1] which brings up the sensors reported TDP to 125W whereas normally it wouldn't work due to maxing out at 115W and 3.35ghz rather than T1 3.5ghz the TDP determining when the CPU enters full turbo 1. I use Turbo 2 to obtain better performance on non-multithreaded games so this is disappointing but I will investigate further. [1] turionpowercontrol, an overclocking software
On 07/12/2018 11:04 PM, Taiidan@gmx.com wrote:
I will provide logs soon! what do you want exactly?
One apparent regression I have noticed is that "sensors" reports CPU power usage at idle is now steady at 101W vs the usual 50W (which used to be 40 before a kernel update) while I am not sure if it is accurate as the cpu temp doesn't reach high levels expected for such wattage it does have one bad effect in that Turbo 2 no longer works...and even before this update with my v4.6 to get Turbo 1 on all cores as AMD advertises I must use "tpc -psmax 1"[1] which brings up the sensors reported TDP to 125W whereas normally it wouldn't work due to maxing out at 115W and 3.35ghz rather than T1 3.5ghz the TDP determining when the CPU enters full turbo 1.
I use Turbo 2 to obtain better performance on non-multithreaded games so this is disappointing but I will investigate further.
[1] turionpowercontrol, an overclocking software
This sounds like CC6 broke. Can you check to see if CC6 is enabled in your NVRAM settings? -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
On Fri, Jul 13, 2018 at 6:44 AM, Timothy Pearson < tpearson@raptorengineering.com> wrote:
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.
Right, with RELOCATABLE_RAMSTAGE=n there is a back-and-forth of low-memory region ramstage occupies on S3 resume path. Also you do not have benefit of executing a copy of ramstage that was cached in RAM already on normal boot path, but have to decompress it again from flash. The low-memory copy is not that big, RAMBASE..RAMTOP is 3 MiB, so this does not explain one minute. Indeed RELOCATABLE_RAMSTAGE=n is already in the minority now and bounce-buffer logic recently had some regressions for loading some payloads. Kyösti
participants (3)
-
Kyösti Mälkki -
Taiidan＠gmx.com -
Timothy Pearson