Launchpad Entry: hardware-kernel-n-firmware-test-suite-enhancements
While the first 4 months of development of the Firmware Test Suite provided a reasonable first-cut of the tool, there are some short comings and features need to be enhanced to make the tool even better at identifying BIOS/firmware issues.
Some work items were not included in Ubuntu 10.10 Maverick which have been postponed to 11.04:
- create basic bios tracking working/broken features against vendor, version
- look at identifying ACPI 'errors' in the kernel log and report them: via apport
- identify and push extra diagnostics patches for s/r etc to mainline + ubuntu kernel 'bios testing PPA' as appropriate
And some feature requests for 11.04 are as follows:
- Bootable USB stick should be text only rather than boot to full desktop to support server H/W.
- Deeper semantic analysis of ACPI tables: use tools like acpiexec to inspect common ACPI AML Methods, sanity check common ACPI table fields and better inspection of AML code - syntaxcheck test is a little too shallow
- Deeper inspection of SMBIOS tables, using dmidecode is a too shallow.
- Put table driven inspection/scanning of kernel logs into a standardized data format that can be used by Python tools for possible integration into apport.
- Classify test in BIOS, ACPI and UEFI specific tests
- Look at including any available UEFI tests
- Improve the iasl warning/error message scanning "syntaxcheck"
This should not have any impact on the release notes.
Need to target fwts on the server side, so build bootable image without the need for a desktop.
Need deeper sets of tests on ACPI AML bytecode paths to automatically pick up deeper issues that normally require expertise to eyeball AML bytecode.
Need to extend the test suite to cater for new uEFI firmware.
Need to re-use the kernel log scanning regexs in Python tools, so it's a good idea to load these regex's from a standardised config file format rather than hard code it into fwts.
Can re-use code from acpica.
You can have subsections that better describe specific parts of the issue.
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.