dmicheck test issues

[Colin Ian King]

On 08/10/15 16:08, Jiri Vohanka wrote:
> Hi Colin,
> 
> I am fine with you making some changes and adding a commit message,
> or if you want I can crate a patch with 'git format-patch' for you.
> I joined the list yesterday and I do not know what are the rules for
> posting patches. If there are some official rules, please let me know.

before sending a patch, if you can check it passes the regression tests,
using:

make check

just to ensure things don't get broken.

patches should follow the fwts coding style (which is basically much
akin to the kernel coding C style). Generally we take "git-format patch"
style patches.  A patch needs to ACKs from reviewers from the fwts team.
 We try to be friendly and succinct in our code reviews.

An archive of patches is always available at:
https://lists.ubuntu.com/archives/fwts-devel/

and one can see the review state of patches at:
http://patchwork.ozlabs.org/project/fwts/list/


There isn't much more to it than that. We probably need to document the
process. I'll mention that in the next fwts engineers meeting.

Thanks for your contribution, I'm glad to see aarch64 is getting some
SMBIOS testing :-)

Colin

> 
> Regards,
> Jiri
> 
> On 10/08/2015 04:47 PM, Colin Ian King wrote:
>> Thank for the patch and test results Jiri, I appreciate the contribution
>> to fwts.
>>
>> If it's OK with you, I'm going to make some minor tweaks to the patch
>> (remove some trailing white spaces) and post it to the list with another
>> patch so the fwts regression tests pass.
>>
>> In future, if you send us patches created using git format-patch then
>> allows us to include the commit message and Signed-off-by.  For this
>> occasion, I'll create one for you if that's OK.
>>
>> Colin
>>
>> On 08/10/15 08:11, Jiri Vohanka wrote:
>>> Hi,
>>>
>>> I am new to the list and I am not sure what is the best procedure if I
>>> want to upstream some changes in the tests.
>>>
>>> I managed to find two issues in the 'dmicheck' test.
>>>
>>> 1)
>>> If 'SMBIOS' tables are not found in 'dmicheck_test2' then the tests for
>>> SMBIOS 3.0 tables are skipped as well.
>>> But the SMBIOS reference specification (version 3.0.0) says in section 5
>>> (Accessing SMBIOS information):
>>> 'An implementation may provide either the 32-bit entry point or the
>>> 64-bit entry point, or both.'.
>>> This bug affected aarch64 systems I worked with since the 32-bit tables
>>> were not provides.
>>>
>>> 2)
>>> As of commit
>>> https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f,
>>>
>>>
>>> the SMBIOS tables are accessible in
>>> /sys/firmware/dmi/tables/smbios_entry_point and
>>> /sys/firmware/dmi/tables/DMI.
>>> This bug affected aarch64 systems I worked with since the access to
>>> SMBIOS tables via /dev/mem
>>> was not allowed if kernel was compiled with 'CONFIG_STRICT_DEVMEM=y'.
>>>
>>> The attached patch includes the following changes:
>>>
>>> - The test 'dmicheck_test2' is split into 'dmicheck_test2' and
>>> 'dmicheck_test3',
>>>    the first one checking SMBIOS table and the second one checking
>>> SMBIOS
>>> 3.0 table.
>>>    Thus, if one of the SMBIOS tables is missing then only one of the
>>> tests is skipped.
>>>
>>> - If the access to SMBIOS tables via /dev/mem fails on UEFI systems then
>>> the tables are loaded
>>>    from /sys/firmware/dmi/tables/.
>>>    If /sys/firmware/dmi/tables/smbios_entry_point begins with '_SM_'
>>> then
>>> the tables from
>>>    /sys/firmware/dmi/tables/ are used as SMBIOS tables.
>>>    If /sys/firmware/dmi/tables/smbios_entry_point begins with '_SM3_'
>>> then the tables from
>>>    /sys/firmware/dmi/tables/ are used as SMBIOS 3.0 tables.
>>>    This change allows access to SMBIOS tables without using /dev/mem on
>>> UEFI systems.
>>>    (The address of SMBIOS entry point structure can be taken form
>>> /sys/firmware/efi/systab
>>>    and the SMBIOS tables can be read from /sys/firmware/dmi/tables/.)
>>>
>>> I tested the patch on:
>>> - aarch64 system (with UEFI) - with 4.2.0 kernel
>>> - x86_64 system without UEFI with access to /dev/mem - Fedora23 with
>>> kernel-4.2.2-300.fc23.x86_64
>>> - x86_64 system with UEFI without acess to /dev/mem - Fedora23 with
>>> kernel-4.2.2-300.fc23.x86_64
>>> - x86 system without UEFI with access to /dev/mem - Fedora23 with
>>> kernel-4.2.2-300.fc23.i686+PAE
>>>
>>> I also attached two logs produced by 'fwts dmicheck'.
>>> The first one is for x86_64 system with UEFI with access to /dev/mem and
>>> the second one is for x86_64 system with UEFI without access to
>>> /dev/mem.
>>>
>>> Regards,
>>> Jiri Vohanka
>>>
>>>
>>> This body part will be downloaded on demand.
>>>
>>