| Message ID | 1445546140-20513-2-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Oct 22, 2015 at 10:35 PM, <ville.syrjala@linux.intel.com> wrote: > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > index 04ca25b..f3c76ae 100644 > --- a/lib/igt_aux.c > +++ b/lib/igt_aux.c > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > * seems to fare better. We need to investigate what's going on. */ > igt_skip_on_simulation(); > > + /* skip if system doesn't support suspend-to-mem */ > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); For these systems we should instead test the "freeze" mode at least. Or add a pile of new testcases for that one specifically, since we currently have 0 test coverage. Should be a basic/BAT one I guess. -Daniel
On 10/22/2015 01:35 PM, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Do a dry run with rtcwake first to determine if the system even supports > the intended suspend state. If not, skip the test. > > Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > lib/igt_aux.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > index 04ca25b..f3c76ae 100644 > --- a/lib/igt_aux.c > +++ b/lib/igt_aux.c > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > * seems to fare better. We need to investigate what's going on. */ > igt_skip_on_simulation(); > > + /* skip if system doesn't support suspend-to-mem */ > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); > + > ret = system("rtcwake -s 30 -m mem"); > igt_assert_f(ret == 0, > "This failure means that something is wrong with the " > @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) > * seems to fare better. We need to investigate what's going on. */ > igt_skip_on_simulation(); > > + /* skip if system doesn't support suspend-to-disk */ > + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); > + > /* The timeout might need to be adjusted if hibernation takes too long > * or if we have to wait excessively long before resume > */ > Are there reliable alternatives to the rtcwake alarm? Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty hard here)? Jesse
On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote: > On 10/22/2015 01:35 PM, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Do a dry run with rtcwake first to determine if the system even supports > > the intended suspend state. If not, skip the test. > > > > Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > lib/igt_aux.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > > index 04ca25b..f3c76ae 100644 > > --- a/lib/igt_aux.c > > +++ b/lib/igt_aux.c > > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > > * seems to fare better. We need to investigate what's going on. */ > > igt_skip_on_simulation(); > > > > + /* skip if system doesn't support suspend-to-mem */ > > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); > > + > > ret = system("rtcwake -s 30 -m mem"); > > igt_assert_f(ret == 0, > > "This failure means that something is wrong with the " > > @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) > > * seems to fare better. We need to investigate what's going on. */ > > igt_skip_on_simulation(); > > > > + /* skip if system doesn't support suspend-to-disk */ > > + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); > > + > > /* The timeout might need to be adjusted if hibernation takes too long > > * or if we have to wait excessively long before resume > > */ > > > > Are there reliable alternatives to the rtcwake alarm? > Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty hard here)? Depending on what the hardware supports, for hibernate to disk there's ipmi power-on. ipmi-power -h $hostname --stat will show the status of the machine, ipmi-power -h $hostname --on will power it on. Maybe wake-on-lan could be an option too? Kind regards, David
On 10/26/2015 11:58 PM, David Weinehall wrote: > On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote: >> On 10/22/2015 01:35 PM, ville.syrjala@linux.intel.com wrote: >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com> >>> >>> Do a dry run with rtcwake first to determine if the system even supports >>> the intended suspend state. If not, skip the test. >>> >>> Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. >>> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> >>> --- >>> lib/igt_aux.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/lib/igt_aux.c b/lib/igt_aux.c >>> index 04ca25b..f3c76ae 100644 >>> --- a/lib/igt_aux.c >>> +++ b/lib/igt_aux.c >>> @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) >>> * seems to fare better. We need to investigate what's going on. */ >>> igt_skip_on_simulation(); >>> >>> + /* skip if system doesn't support suspend-to-mem */ >>> + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); >>> + >>> ret = system("rtcwake -s 30 -m mem"); >>> igt_assert_f(ret == 0, >>> "This failure means that something is wrong with the " >>> @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) >>> * seems to fare better. We need to investigate what's going on. */ >>> igt_skip_on_simulation(); >>> >>> + /* skip if system doesn't support suspend-to-disk */ >>> + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); >>> + >>> /* The timeout might need to be adjusted if hibernation takes too long >>> * or if we have to wait excessively long before resume >>> */ >>> >> >> Are there reliable alternatives to the rtcwake alarm? >> Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty hard here)? > > Depending on what the hardware supports, for hibernate to disk there's ipmi power-on. > > ipmi-power -h $hostname --stat will show the status of the machine, > ipmi-power -h $hostname --on will power it on. > > Maybe wake-on-lan could be an option too? If there's some way to automate these into the tests, that would be ideal, otherwise including them in the Jenkins setup for platforms that don't have RTC wake would be good so we can get full test coverage. Jesse
On Tue, Oct 27, 2015 at 08:58:17AM +0200, David Weinehall wrote: > On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote: > > On 10/22/2015 01:35 PM, ville.syrjala@linux.intel.com wrote: > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > Do a dry run with rtcwake first to determine if the system even supports > > > the intended suspend state. If not, skip the test. > > > > > > Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > --- > > > lib/igt_aux.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > > > index 04ca25b..f3c76ae 100644 > > > --- a/lib/igt_aux.c > > > +++ b/lib/igt_aux.c > > > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > > > * seems to fare better. We need to investigate what's going on. */ > > > igt_skip_on_simulation(); > > > > > > + /* skip if system doesn't support suspend-to-mem */ > > > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); > > > + > > > ret = system("rtcwake -s 30 -m mem"); > > > igt_assert_f(ret == 0, > > > "This failure means that something is wrong with the " > > > @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) > > > * seems to fare better. We need to investigate what's going on. */ > > > igt_skip_on_simulation(); > > > > > > + /* skip if system doesn't support suspend-to-disk */ > > > + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); > > > + > > > /* The timeout might need to be adjusted if hibernation takes too long > > > * or if we have to wait excessively long before resume > > > */ > > > > > > > Are there reliable alternatives to the rtcwake alarm? > > Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty hard here)? > > Depending on what the hardware supports, for hibernate to disk there's ipmi power-on. > > ipmi-power -h $hostname --stat will show the status of the machine, > ipmi-power -h $hostname --on will power it on. I would have expected to see IPMI only on server platforms. Has it become more widespread at some point?
On Tue, Oct 27, 2015 at 10:02:09AM -0700, Jesse Barnes wrote: > > Depending on what the hardware supports, for hibernate to disk there's ipmi power-on. > > > > ipmi-power -h $hostname --stat will show the status of the machine, > > ipmi-power -h $hostname --on will power it on. > > > > Maybe wake-on-lan could be an option too? > > If there's some way to automate these into the tests, that would be > ideal, otherwise including them in the Jenkins setup for platforms that > don't have RTC wake would be good so we can get full test coverage. I don't think it can buy us full coverage; there are embedded devices that lack RTC, and it's rather rare that they have IPMI support (dunno if they typically have wol support). Devices that have USB host mode could possibly be wakened by simulating an USB HID-device, at least for devices that can be configured to wake on keypress. Other than that though, guess the options are either to hardwire the devices to wake on power-on and do hard power-cycle using a fake-battery (if testing battery powered devices) or a remote controlled power socket. Regards, David
On Tue, Oct 27, 2015 at 07:29:39PM +0200, Ville Syrjälä wrote: > On Tue, Oct 27, 2015 at 08:58:17AM +0200, David Weinehall wrote: > > On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote: > > > On 10/22/2015 01:35 PM, ville.syrjala@linux.intel.com wrote: > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > Do a dry run with rtcwake first to determine if the system even supports > > > > the intended suspend state. If not, skip the test. > > > > > > > > Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3. > > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > --- > > > > lib/igt_aux.c | 6 ++++++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/lib/igt_aux.c b/lib/igt_aux.c > > > > index 04ca25b..f3c76ae 100644 > > > > --- a/lib/igt_aux.c > > > > +++ b/lib/igt_aux.c > > > > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) > > > > * seems to fare better. We need to investigate what's going on. */ > > > > igt_skip_on_simulation(); > > > > > > > > + /* skip if system doesn't support suspend-to-mem */ > > > > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); > > > > + > > > > ret = system("rtcwake -s 30 -m mem"); > > > > igt_assert_f(ret == 0, > > > > "This failure means that something is wrong with the " > > > > @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) > > > > * seems to fare better. We need to investigate what's going on. */ > > > > igt_skip_on_simulation(); > > > > > > > > + /* skip if system doesn't support suspend-to-disk */ > > > > + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); > > > > + > > > > /* The timeout might need to be adjusted if hibernation takes too long > > > > * or if we have to wait excessively long before resume > > > > */ > > > > > > > > > > Are there reliable alternatives to the rtcwake alarm? > > > Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty hard here)? > > > > Depending on what the hardware supports, for hibernate to disk there's ipmi power-on. > > > > ipmi-power -h $hostname --stat will show the status of the machine, > > ipmi-power -h $hostname --on will power it on. > > I would have expected to see IPMI only on server platforms. Has it > become more widespread at some point? I think it's become slightly more common, but you're correct that it's rare (probably almost non-existent) for things like tablets, phones, etc. Regards, David
diff --git a/lib/igt_aux.c b/lib/igt_aux.c index 04ca25b..f3c76ae 100644 --- a/lib/igt_aux.c +++ b/lib/igt_aux.c @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void) * seems to fare better. We need to investigate what's going on. */ igt_skip_on_simulation(); + /* skip if system doesn't support suspend-to-mem */ + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0); + ret = system("rtcwake -s 30 -m mem"); igt_assert_f(ret == 0, "This failure means that something is wrong with the " @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void) * seems to fare better. We need to investigate what's going on. */ igt_skip_on_simulation(); + /* skip if system doesn't support suspend-to-disk */ + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0); + /* The timeout might need to be adjusted if hibernation takes too long * or if we have to wait excessively long before resume */