Add support for dmidecode on ARM hardware

[Marc Tardif]

ARM hardware does not have DMI information, so some scripts should be fixed to support this hardware. For example, the scripts memory_compare and check_is_laptop assume the command works. First, we should check whether the dmidecode command can actually be installed on ARM hardware. If so, then the scripts should support its behavior when it is installed but doesn't work. For example, commands like lspci might just segfault. If not, then perhaps the jobs could potentially be updated to require package.name == 'dmidecode'.

[Jeff Lane  (bladernr)]

Yep, the absense of dmi info on ARM hardware is a problem (it's possible that there will be some DMI analogue on production level ARM server systems, but that's just a rumor I heard on the internets).

Marking this as a wishlist item for now because it won't make it to Precise and we still don't have "real" ARM hardware to develop/test this on. There's a very good chance that an actual ARM server will be a lot more capable than the panda/beagle/i.MX53 boards we've all been playing with.

[Patola (patola)]

Any news on that? We're now on 2013 and we have plenty of ARM hardware running Ubuntu, from tablets like Nexus 7 to ubuntu phone, also including CuBox, ODROID X / U / X2 / U2 and even USB sticks like the UG802 and MK802 III. And they still lack dmidecode or a working lshw / lspci...

[xlynx (xlynx)]

lshw is working fine on the BCM2708 (raspi). I wouldn't expect lspci to work since the there is no PCI bus. I suppose the same may go for DMI support.

[Zygmunt Krynicki (zyga)]

Hi

I wonder why do we even keep this bug open? ARM has no dmi so there is nothing to decode. This is not the solution you are looking for

[Jeff Lane  (bladernr)]

bump... since dmi info and dmidecode are not available, we need to sort out how to get the same data from other tools on ARM hardware and adjust accordingly.

[Brendan Donegan (brendan-donegan)]

I think this bug needs to be broken down in to sub-problems. E.g. the cert site using dmi information to create certain device, the memory_info scripts use of dmidecode, the use of form factor to determine if the system is a laptop.

[Jeff Lane  (bladernr)]

I agree... the use of DMI info is too wide-spread for this to be a simple task on a user story, this one really needs to be a user story on its own, or perhaps a couple stories.

To get this rolling, the following scripts all make calls to dmidecode to get info to execute:
accelerometer_test (uses dmidecode to get vendor and compare to known working accelerometers)
alsa_info (uses dmidecode to get system info (vendor, BIOS version, etc)
check_is_laptop (checks dmi type 3 for determining if system is a laptop chassis type)
dmi_resource (passes output to the DmidecodeParser in checkbox/parsers)
fwts_test (the batch test list includes dmi_decode which is not present on the armhf build)
memory_compare (used to determine installed Physical RAM and compare to visible system RAM)
virt_check (uses to determine installed physical RAM (NOT System Visible RAM))

Of those, the ones that are valid for this bug (server applicable tests) are dmi_resource, memory_compare and virt_check and fwts_test.

[Jeff Lane  (bladernr)]

So we need to sort out the following:

dmi_resource - what data is collected? How is it used (in the submission, on the cert site, by other tests as constraints for running jobs)

fwts_test - what happens to the run if this fails to execute? Nothing? Does it inadvertently cause a false fail?

memory_compare - is there another way on ARM systems to get the amount of physical RAM available to a SoC?

virt_check - answering the issue for memory_compare will also answer this one, I think.,

[Jeff Lane  (bladernr)]

fwts is take care of... I have a branch that should account for everything that is returned by FWTS as "Aborted" and all the messages about aborted tests appear in stderr, which don't show up if the script returns a passing code.

Also, the rest of the missing fwts tests are handled by other bugs

[Brendan Donegan (brendan-donegan)]

So then we have:

https://bugs.launchpad.net/checkbox/+bug/1184661 - memory_compare fixing and will also take care of virt check incidentally

dmi_resource is marked as being covered by this bug, but I don't think it's a suitable tracker so I may file a different one. Echoing what was said before though I don't think we can replace this directly, so we need to find out how it is used by the cert site and work on that.

[Brendan Donegan (brendan-donegan)]

This is a meta-bug. Now that we have seperate bugs open for each test being affected by this issue I think we can call this Invalid.

[gaara (yoggic)]

I'm trying to check the RAM clock speed for an Odroid XU4, but:
$ sudo dmidecode -t memory
# dmidecode 3.0
Scanning /dev/mem for entry point.
Erreur du bus (core dumped)

If it can help...