[UEFI arm64] dmidecode test should be enabled and test case modified appropriately.

[Manoj Iyer]

dmidecode works on arm64 system with UEFI firwmare.

For example on the Qualcomm Centriq platform QDF2400 running dmidecode produces the following output.

http://pastebin.ubuntu.com/25140356/

The dmidecode testcase should be updated so that it identifies valid uefi based arm64 platforms and reports the test as pass.

[Michael Reed (mreed8855)]

Here is the output from the test report

Test ID
-Test DMI identification data (servers)

Results
-not supported

Certification status
-unspecified

Comment
-job cannot be started: resource expression 'cpuinfo.platform in ("i386", "x86_64")' evaluates to false

[Jeff Lane  (bladernr)]

I have a couple of ideas to test out and then we'll see where to go from there.

[Paul Larson (pwlars)]

Would it be sufficient to check for /sys/devices/virtual/dmi?

[Jeff Lane  (bladernr)]

THat may work better. Currently, the job simply does a resource check for cpuinfo.platform in ("i386", "x86_64")

Anything else (beyond just adding arm64 to the platforms) would require a resource job instead, which, in the long run, may be the better way to do it.

I tried something like this:

[ -e /sys/devices/virtual/dmi ] && dmitest || echo "DMI unsupported"

But that has the unfortunate side effect of running the OR clause if the AND clause fails, and would result in a false PASS.

[Jeff Lane  (bladernr)]

Yes, that could be better expanded into an if-then-else, I was just looking for the most elegant solution...

[Jeff Lane  (bladernr)]

if [ -e /sys/devices/virtual/dmi/ ]; then dmitest server; else echo UNSUPPORTED; false; fi

works well enough but still has the effect of adding a FAIL to a submission where it really should just be skipped instead.

[Jonathan Cave (jocave)]

Need to bear in mind that we were attempting to preclude any dmi related job from running on dragonboard (arm64). If I remember correctly, this has dmi sysfs entries, but a bug in the kernel causes a hard reboot if anything attempts to parse these.

[Paul Larson (pwlars)]

You might be thinking of https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1591994 which was not dmi related. Or, if there was a dmi related one, it may also be because dmidecode was trying to read directly from a memory location rather than sysfs, because at least today, I don't see any dmi entry in sysfs on my dragonboard:

ubuntu@localhost:~$ ls /sys/devices/virtual/
bdi/ graphics/ misc/ sound/ usbmon/ workqueue/
block/ input/ net/ thermal/ vc/
bluetooth/ mem/ ppp/ tty/ vtconsole/

[Jonathan Cave (jocave)]

Yes sorry, you're probably right. Looks like we need to see if we can do this test in a resource then.

[Jeff Lane  (bladernr)]

Proposed solution adds .supported to the dmi resource and tests for hte presence of /sys/devices/virtual/dmi

If that's present, then dmi.supported = "True" and "False" if not present.

So we coud replace all the arch specific requirements on DMI jobs with

requires: dmi.supported == 'True'

which would cause the job to run anywhere DMI appears to be supported and available, rather than mantaining a list of architectures that are ever changing.

[Jeff Lane  (bladernr)]

Also, anything that has /sys/devices/virtual/dmi and fails (dir not populated, or probing it causes reboots, hangs or other issues) should be a fail and be investigated anyway, so this would catch those cases properly.