[sru_sleep_state_test] fails on servers

Do we know the reasons for removal of S3 support from server kernels? maybe if there was a good reason for that, it's not really expected to work, and how much should be testing something that's not officially supported?

Also the sleep test could have a requirement check so that if the kernel doesn't even support the sleep states (mem or disk) we shouldn't get tested. Just like we don't test for i.e. a webcam if the kernel doesn't claim to have found one.

I didn't phrase the last part of the report properly - I was trying to say the same thing you just said! Anyway, yes - this test should be skipped on servers, just have to work out how to do that,

On 07/01/2011 10:32 AM, Brendan Donegan wrote:
> I didn't phrase the last part of the report properly - I was trying to
> say the same thing you just said! Anyway, yes - this test should be
> skipped on servers, just have to work out how to do that,

Just repeating what I'd discussed with Brendan this morning so it's
documented, but I agree.

So, first order is that the S3 support is there in the kernel, but
apparently, none of the servers we test support S3... which is just odd.
  After talking with Colin King and Carlos a bit, it seems that the most
likely cause of this is going to be BIOS.

So FWIW, I checked the kernel config for Natty and the support is there
in the kernel for S3, but it does look more likely that none of the
servers actually support S3 (which could be quite likely).

One way around this failure generation would be to just drop the test
from the server list.

Another would be to have a local job that checks if S3 is supported, and
make the server S3 test dependent on that test.

A third would be to fix checkbox to accept more than just 0 and 1 as
return codes so we can perform job level exception handling (like
0=Pass, 1=Fail, 2=Skip) so that any test that exits with a 2 will end up
marked as skipped rather than Fail.

--
Jeff Lane - Hardware Certification Engineer and Test Tools Developer
Ubuntu Ham: W4KDH
Freenode IRC: bladernr or bladernr_
gpg: 1024D/3A14B2DD 8C88 B076 0DD7 B404 1417 C466 4ABD 3635 3A14 B2DD

Heh, well a *fourth* way around it would be to have a (sys,proc)_resource plugin that collects relevant information from the proc or sys trees. The way to check if the kernel has S3/4 support is to look at /sys/power/state and check if "mem" or "disk" are listed there. Then the test would require that particular resource and just not run if the requirement isn't met.

Do we want to go through the bother of writing a proc/sys resource plugin, or will we just excise the suspend test (and dependant 'after' tests) from the server whitelist? I know which one is more robust in the long run (the plugin), but we'd also need to find time to do it.

I set this as medium since we can safely assume that the suspend test failing on a server is a false positive, since we know they don't support it anyway.

On 08/26/2011 04:37 AM, Brendan Donegan wrote:
> I set this as medium since we can safely assume that the suspend test
> failing on a server is a false positive, since we know they don't
> support it anyway.
>

I'd suggest just excising it from the whitelist, honestly. None of the
servers support it, so writing a plugin for a bunch of systems that
aren't going to work anyway seems a bit overkill at this point.

Maybe if we start getting servers that DO support sleep states and the
OEMs start clamoring for it, we can revisit the plugin idea.

--
Jeff Lane - Hardware Certification Engineer and Test Tools Developer
Ubuntu Ham: W4KDH
Freenode IRC: bladernr or bladernr_
gpg: 1024D/3A14B2DD 8C88 B076 0DD7 B404 1417 C466 4ABD 3635 3A14 B2DD

On 08/26/2011 04:37 AM, Brendan Donegan wrote:
> I set this as medium since we can safely assume that the suspend test
> failing on a server is a false positive, since we know they don't
> support it anyway.
>

I should add that I opened bug 834856 to address removing the
unnecessary tests from the server whitelist.

--
Jeff Lane - Hardware Certification Engineer and Test Tools Developer
Ubuntu Ham: W4KDH
Freenode IRC: bladernr or bladernr_
gpg: 1024D/3A14B2DD 8C88 B076 0DD7 B404 1417 C466 4ABD 3635 3A14 B2DD

A fix still needs to be done for this for SRU testing, since one whitelist is used and I want to avoid another one at all costs. I'll look into the local job solution.

After some tests, I'm having doubts about whether dependencies are even working properly.

Actually it just appears that checkbox doesn't take into account the pass/fail status of a job when resolving the dependency, which I guess is the intended behaviour.

Will have to look into the /proc resource script

Is this still an issue? IIRC, there is now a sleep state resource job and the tests are skipped if mem is not present.

So if that's so, this should be marked fix released.

I think it's fixed.