On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
On Fri, Jun 15, 2018 at 8:58 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
On Thu, Jun 14, 2018 at 4:38 AM, qtux mail@qtux.eu wrote: Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is within the latter period, I do not quite see how S3 support could have worked with that commit on kgpe-d16. Or maybe this feature was never retested once it was rebased and upstreamed. Nor can I see how it could have worked for any commit in 4.6
I just tested S3 again and it worked fine on my v4.6 D16.
Please state the commit hash of the source tree you built and booted from, we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I will also investigate things myself if S3 doesn't work...
On 06/20/2018 03:39 PM, Taiidan@gmx.com wrote:
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
On Fri, Jun 15, 2018 at 8:58 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
On Thu, Jun 14, 2018 at 4:38 AM, qtux mail@qtux.eu wrote: Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is within the latter period, I do not quite see how S3 support could have worked with that commit on kgpe-d16. Or maybe this feature was never retested once it was rebased and upstreamed. Nor can I see how it could have worked for any commit in 4.6
I just tested S3 again and it worked fine on my v4.6 D16.
Please state the commit hash of the source tree you built and booted from, we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I will also investigate things myself if S3 doesn't work...
If you can isolate the commit I have time blocked off this week to work on bringing the D16 back up to date...
Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 06/20/2018 03:39 PM, Taiidan@gmx.com wrote:
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
On Fri, Jun 15, 2018 at 8:58 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
On Thu, Jun 14, 2018 at 4:38 AM, qtux mail@qtux.eu wrote: Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is within the latter period, I do not quite see how S3 support could have worked with that commit on kgpe-d16. Or maybe this feature was never retested once it was rebased and upstreamed. Nor can I see how it could have worked for any commit in 4.6
I just tested S3 again and it worked fine on my v4.6 D16.
Please state the commit hash of the source tree you built and booted from, we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I will also investigate things myself if S3 doesn't work...
Just wanted to follow up on the bisect offer for this....I'm back in the D16 code for a different reason and if there's a general commit range where the issue started, I'm happy to investigate.
Thanks!
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
On 06/27/2018 05:17 PM, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 06/20/2018 03:39 PM, Taiidan@gmx.com wrote:
On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
On Fri, Jun 15, 2018 at 8:58 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
On Thu, Jun 14, 2018 at 4:38 AM, qtux mail@qtux.eu wrote: Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is within the latter period, I do not quite see how S3 support could have worked with that commit on kgpe-d16. Or maybe this feature was never retested once it was rebased and upstreamed. Nor can I see how it could have worked for any commit in 4.6
I just tested S3 again and it worked fine on my v4.6 D16.
Please state the commit hash of the source tree you built and booted from, we don't literally have such tag as "v4.6".
I was using the coreboot-4.6.tar.xz from the coreboot download page which is why I didn't include the hash.
[ 0.000000] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
Repeat tests with current master.
Thanks, I will have info for you by the end of the this weekend and I will also investigate things myself if S3 doesn't work...
Just wanted to follow up on the bisect offer for this....I'm back in the D16 code for a different reason and if there's a general commit range where the issue started, I'm happy to investigate.
I got the flu so I had to put this off for a little while, I will start next week.
Sorry! and thanks!
Hi guys!
I have just tested my KGPE-D16's suspend a few times with the latest master and it works fine - takes around a minute to get back to my linux terminal.
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.
On 07/12/2018 09:40 PM, Taiidan@gmx.com wrote:
Hi guys!
I have just tested my KGPE-D16's suspend a few times with the latest master and it works fine - takes around a minute to get back to my linux terminal.
On Fri, Jul 13, 2018 at 5:41 AM, Timothy Pearson < 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
On Fri, Jul 13, 2018 at 5:40 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
Hi guys!
I have just tested my KGPE-D16's suspend a few times with the latest master and it works fine - takes around a minute to get back to my linux terminal.
Thanks
And logs please.
My previous mails had some pointers to commits which I believe had regressions and fixes. I would like to know if those were accurate.
Kyösti
-
Kyösti Mälkki -
Taiidan＠gmx.com -
Timothy Pearson