dmicheck test issues

[Jiri Vohanka]

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.

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.
>>
>