This page is here to collect together proceedings from sessions as part of the 'Hardware Compatibility' track at the Natty UDS in Orlando, Florida.

Please add proceedings by doing the following:

• Add a new section with the name of the session.
• Add the outcomes of the session as a collection of bullet points. The goal of the proceedings is to really focus on decided outcomes, so please try to keep them crisp.

Thanks!

Proceedings

ARM power mgmt [Theme - cpufreq]

• Ondemand governor problems
  • doesn't scale quickly enough, especially on IO-bound processes
  • Can't handle cpu bursts well
• Thermal feedback in cpufreq
  • not really the best place to take thermal input
  • cpufreq is just one of the responses to thermal overheating, we could hotplug, restrict idle states, etc. too
  • thermal monitoring should be done and data made available through well-defined interface
  • policy manager might be required - out of scope for this cycle
• Multi-core coordination
  • ondemand governor has knob to allow single thread for all cores
  • Task becomes one of verification
• ACTIONS:
  • ondemand: come up with simple test case to reproduce problem
  • ondemand: try to reproduce on x86 to get more eyeballs
  • thermal: ensure that existing frameworks will export temperature in a standard place
  • multi-core: Verify on multicore platforms that a single thread of ondemand DTRT

ARM power mgmt [Theme - cpuidle]

• Latency measurement infrastructure
  • ftrace tracepoints added to cpuidle path and in the OMAP cpuidle driver

  • Other SoCs can take the patch and test

• Timer wakeups and C-states
  • identify the timer that really woke up the system, other timers that fired on a system that is already active are (slightly) less important
  • needs logging of c-state we are in when timers go off
• SoC state names
  • ARM to get a spec out in May
• menu governor
  • real c-state entered may be different from state requested
  • governor not responsive enough
• ACTION:
  • latency: common context save/restore code from ARM

  • latency: instrument other SoCs based on OMAP work

  • latency: get latency numbers for every cpuidle-enabled platform
  • timers: log c-state information for timers that go off and wakeup system (tracepoints?)
  • SoC state names: deferred based on ARM feedback
  • governor: come up with simple test case to reproduce problem
  • governor: try to reproduce on x86 to get more eyeballs

Handle unusual input devices with aplomb

NOTES:
[ogasawara] Many devices come in interesting form factors, and may have a number of additional hardware buttons (commonly at least send/end), electrostatic panels, etc. Discussion focued on how to find out which buttons etc aren't currently supported, updating existing wiki pages, how to interact with vendors.

ACTIONS:

• [JFo] (hold off for now) CFT to get a poll of unique/unusual buttons and interesting form factors: TODO
• Review/Update Hotkeys and Hotkeys/Troubleshooting wiki page: TODO
• Find some data examples and speak with Keng-Yu (acelan) for the small bits of scripts to parse data: TODO

How to handle the hardware X can't properly autodetect

NOTES:
[jk] RAOF and bryce discussed cases where graphics HW cannot be reliably detected by KMS and/or xorg; most cases fell into either connector detection or invalid/missing EDID. A few proposals presented to update EDID at runtime (probably by making the EDID file in /sys read/write, allowing updates from userspace), but still need to work something out to allow easy updates for other (usually boolean flag) quirking, and do do updates early enough to get KMS working properly during boot. I'll investigate and write up a brief proposal for how we might use the device tree on x86, but it may be overkill to bring the DT infrastructure to x86 for fairly simple quirking.

ACTIONS:

• [apw] investigate whether the EDID etc could become writable at the kernel level:TODO
• [apw] can we move i915 power etc configs to sysfs:TODO
• [raof] investigate extending the gnome-monitors-applet to add extra randr modes:TODO
• [bryceharrington] to find summary of quirks and publish with spec
• [jk-ozlabs] proposal for device tree node specifying the graphics quirks

Kernel Configuration Review

NOTES:
[apw] Usual session reviewing new configs, experimental options, and taking config requests. Also cleanup of discprencies between flavours and adding options to the enforcer.

ACTIONS:

• [jj] investigate CONFIG_INTEL_IDLE and verify if we want this inconsistent on virtual: TODO
• [apw] Add CONFIG_IMA to enforcer: TODO
• [jj] XEN_PCI_PLATFORMDEV (sp?) turned on for all, but test first: TODO
• [apw] CONFIG_IPV6 - add to enforcer: TODO
• [apw] fix up above CONFIG options per notes
• [apw] investigate building in CONFIG_AGP drivers (only 4): TODO
• [cking] investigate setting CONFIG_HZ=1000, allows X to run faster: TODO

Kernel Natty Bug Handling

NOTES:
[pgraner] The prime focus of this session was to focus the kernel bug triage policies and procedures, so that the information generated will put forth the most critical bugs in front of the kernel team. The session also touched on kernel wiki docs, automated scripts etc.

ACTIONS

• [jeremyfoshee] to develop process for handling, validation & closure, and document in the wiki

• [jeremyfoshee] produce summary report with the priority bugs from each stakeholder
• [jeremyfoshee] to drive existing bugs with patches list to zero and keep it there
• [jeremyfoshee] look at kerneloops reports to better detect duplicates
• [jeremyfoshee] look at documentation for kernel testing (installation etc), test and update
• [bdmurray] work with QA and community to dog food wiki docs
• [kamal] to clean up / merge kernel wiki docs about how to change a grub entry: "Kernel boot params for newbies"
• [pgraner] schedule a stackexchange session with Jorge this week
• [jeremyfoshee] look at primary arsenal message for applicability to flavour (not appropriate for arm)
• [jeremyfoshee] update apport-hooks verbage
• [jeremyfoshee] look at arsenal flow and document
• [canonical-kernel-team] ensure we have documentation/scripting(?) for git bisect'ing an issue

ARM power mgmt [Theme - Multicore]

NOTES:

• Hotplug
  • core hotplug feature needs to be implemented and made available thru userspace interface
  • The decision to hotplug is left to policy now
    • several approaches - scheduler and cpuidle coordination

ACTIONS:

• hotplug: get hotplug working on relevant partner platforms
• hotplug: pull out common code

BSP Investigations

NOTES:

• Aim is to assist silicon vendors in making their BSPs more upstreamable.
• Discussed outcomes of previous reviews and how to improve the process for the future.
• Public review/feedback process seen as a positive thing by vendor engineers.
• A review process will be defined to improve quality and consistency of reviews.
• Aim for incremental review of vendor BSP releases over the next cycle.
• Aim to incorporate useful review feedback in linux/Documentation to help developers.

ACTIONS:
Assignees TBD except as noted.

• Create a tool collecting statistics around BSP git trees, running checkpatch, diffstat etc.
• Document the BSP review process
• Do some BSP reviews for:
  • Freescale: i.mx BSP releases monthly; we should try to review each of them
  • ST-Ericsson: no official BSP release, could push for a code drop every month and review that
    • Currently two trees, but will be one generic base tree in the future and it should be the one we review
  • ARM: upstreaming patches continuously, not necessary for Linaro, already a lot of coverage
    • [dmart] to check with Peter Pearse whether there's interest in an ARM u-boot review
  • TI: 2 BSPs internally, one Android and non-Android, for OMAP3 and OMAP4, on omapzoom; monthly release; at most one kernel version behind.
  • Samsung: 1 BSP, mainstream now. Review process is work directly with mainline - probably no review needed? u-boot would need a review though

Review of the Stable Maintenance Process

NOTES:

Design

The stable kernel team will change to a regular two-week release cadence. The cycle is two weeks long, and repeats every two weeks, with the exception of holidays, UDS weeks, and other considerations. An attempt will be made to sync the schedule with the needs of the Ubuntu platform schedule and Linaro release schedule.

Non-CVE Patches

• Stable Upstream Patches
  • Stable updates from upstream (GregKH's repos) will be accepted without testing of individual functionality.
• Other Patches
  • No patch will be accepted for a bug if we on't have the hardware to test it or high confidence that it will be tested by the community. At the end of the first week of baking in -proposed, if these patches have not been verified as fixing the specific bugs the patch will be reverted.

CVE Patches

• Non-Critical
  • Non-critical CVE patches will be applied directly to the master branch of the effected git repository and will be part of the next -proposed upload. A special -security upload will not be required for these patches.
• Critical
  • Critical CVE patches will be applied to the master branch of the effected git repository and will be uploaded as a -security release which will be released imediately.

Testing

• There are 3 types of required testing: certification, regression and bug specific. The testing of a -proposed kernel must be completed within 14 working days begining when the upload has been accepted to the -proposed pocket.

• Certification is the responsibility of the Platform Services, certification QA team.
• Regression testing is the responsibility of the Platform QA team.
• Bug specific testing is the responsibility of the originating bug author.

Implementation

• The SRU policy will be amended to indicate that changes will only be considered if we have the hardware and resources to test the fix, or a very high confidence that the bug reporter will test the proposed release.
• Kernel stable updates will follow a two week cycle
• At the beginning of the cycle, bug fixes, upstream stable patches, and non-embargoed security fixes will be applied, and the kernel uploaded to proposed.
• At the end of the first week, any bug fixes which have not been verified as fixed by the reporter or by internal testing will have the patches reverted, and the associated bugs closed as "wontfix".
• During the second week, certification and regression testing will be performed to insure that the kernel is functional. Minimum testing will insure that the kernels boots, networking operates, X starts (for workstations), and updates can be performed. Certification tests will not include the entire set of manually executed tests, but will include an automated set of tests. Testing will be a joint effort by the QA and certification teams.
• Cert and QA will begin testing the kernels currently in proposed next week (1 Nov, 2010) and report on the amount of effort and resources required to perform testing. These results will be used to evaluate the resources required to test all expected variants of released kernels.
• Proposed releases will be tracked with a tracking bug opened by the stable kernel team, and linked via an entry in the changelog. This bug will be assigned to the QA team (or a launchpad team - TBD), and tracked on the kernel bug dashboard. The bug will be set to verified when all QA and Cert testing has passed.
• We need to decide which systems will be tested. Should it be most common, or some subset? It will include at least one virtual environment.
• Security kernels which are critical or embargoed will also receive the same tests required for proposed kernels.

For more information: https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyStableProcessReview

ACTIONS:

• [sconklin] boiler plate text for bug closure on failure to verify
• [canonical-kernel-team] look at arsenal scripts to nag the users
• [skaet][sconklin] workout the sru schedule with respect linaro and platform
• [sconklin] provide a document that describes the process, bug tracking, and which tests are being performed, etc
• [jfo] make sure that the bugs that we are sending for this are on the dashboard
• [pitti] ensure verification bug update indicates that this is going to be pulled
• [sconklin] process to add the bug to the changelog manually during release process.
• [marjo] QA team - define a mechanism to assign the proposed upload tracking bug to them and track results
• [victor] QA team - provide a description of what testing they provide, and an idea of the number of hours required to run those

• [leann] provide info from HWDB http://reports.qa.ubuntu.com/reports/ogasawara/hwdb/system-stats-popular-20101019.html

• [action] Victor to investigate which systems are "common" for cert testing
• [cert-team] blueprint for cert-team

Enhancements to the firmware test suite

NOTES:
This session was to discuss the Firmware Test Suite where its at today and what needs to be done in the Natty Cycle to enhance the Test Suite.

ACTIONS:

• ACPI datastructures will be investigated and reported on based on the spec as to potential 'errors' in the tables
• ACPI bytecode Methods run in userspace to determine if there are any unexpected results for sanity checking. For example, S3/S4 errors, brightness controls can be tested in this way
• Some ACPI methods may be able to be checked offline for "insane content" (i.e. required methods which are totally empty, or methods which claim to return a value but don't actually contain any return statement at all) [kamal]
• FWTS feature idea: "--post-resume-hook" to make FWTS run an arbitrary script after resume to allow easy repetition testing of bad things that happen after suspend-resume [kamal]
• SMBIOS tables will be extracted and checked thoroughly for possible errors - drop using dmidecode for this task
• Investigate uEFI testing
  • what is available?
  • what is additionally possible (runtime services?)
• The intention is to test UEFI, but there has been no completed investigation as yet on how to accomplish this.
• Review of bugs we curently have to see if there are any UEFI issues
• Improve the AML syntax check test - very basic based on errors, investigate logs parsing, expand and give diagnosis/workaround
• Kernel Log - currently hardcode table driven, put data in json formatted data file, so can be re-used by Python tools
• Default the -p progress indicator to be on, add -q quiet flag to run silently.
• Add post-test hook calls to run scripts after S3, S4 cycles.
• Create a basic BIOS tracking working/broken features against vendor, version
• Identify and push extra diagnostics patches for s/r to mainline + ubuntu kernel 'BIOS testing PPA' as appropriate

Flexibility in support for different touchscreens/hardware configurations

NOTES:

ACTIONS:

• Outcome
• Outcome
• Outcome

Handling of Deviations from Standard Kernels

NOTES:

Discussions on how to maintain kernels which have backported subsystems. The main issue is documenting these deviations, both the subsystem (paths) and related version. Much of this information is already available on Kernel/Dev/KernelDriverDeviations. Resolved to include this information in tree in a machine readable form and provide tooling to check patches for deviations. Further resolved to track upstream stable for these deviated subsystems until such time as upstream stable support ends. Maintenance of the 2.6.32drm33 tree will be taken as an official upstream version for the purposes of stable updates in Lucid and updates to this tree will be further publicised.

ACTIONS:

• [stefan-bader-canonical] document the why for each version deviant driver
• [canonical-kernel-team] stable tool to detect when a directory of patches are touching a deviant piece
• [canonical-kernel-team] document within the source tree a debian/deviant.versions type information
• [stefan-bader-canonical] contact gregkh to see if we can use stable-review

Root filesystem on flash storage

NOTES:

• A Linaro release should be customized to deploy to a 128M flash system. The optimal system will avoid excessive interaction with the flash. The Versatile Express will be used as a reference platform - 128M NOR flash. Use the jffs2 filesystem (logfs should be investigated). UBFS for NAND. A deploy mechanism needs to be developed or at least specified. Optimize cache write settings.

ACTIONS:

• [mwaddel] linaro-media-create changes
• [mwaddel] Board specific info - ethaddr, serialnum, etc.
• [mwaddel] Determine rootfs accesses
  • Use write logging on current system
• [martinbogo] Investigation on different filesystems
  • suitability for NAND and NOR
  • performance, mount time
  • wear characteristics
• [mwaddel] Determine current shipped file system for VExpress

ARM Kernel Standard Architecture

NOTES:

ACTIONS:

• Will add remaining NEON bits
• Investigation of NEON memcpy in the kernel
• Extend SMP on UP for Thumb 2
• Fix and benchmark HIGHMEM
• Switch all our kernels to Thumb 2
• (Maybe) Kprobes and dynamic ftrace for Thumb 2
• (Maybe) Thumb 2 u-boot

ARM Kernel Device Tree

NOTES:

ACTIONS:

• Merge existing DT support in linux-linaro and ongoing work by Grant Likely and Jeremy Kerr
• Extend imx51 and Samsung v210 support, merge OMAP3/OMAP4 support from Grant; produce demos out of these

ARM power mgmt - Policy management

NOTES:

• Existing framework (Thermal, CPU Freq, Hotplug) do function as designed to.
• But they are not able to meet all requirements (cpuidle + peripheral power states)
• should application be controlling policies?
  • what kind of applications be allowed to control policies?
  • privileged applications on android can block suspend
• Inputs:
  • Thermal
  • applications
  • policy
  • pm qos
    • dma_latency is available from userspace
  • governors
• Knobs: interfaces available today
  • hotplug
  • cpuidle
  • cpufreq
• Is all necessary information available for userspace to drive policy?
  • pm qos params:
    • I/O related param for ddr, interconnect
  • cpuidle
    • can we restrict number of states from userspace?
  • can we restrict existing governors states?

ACTIONS:

• No actions for 11.05
• Several people will start conversations in upstreams (kernel, middleware) around these areas

Kernel Version and Flavours

NOTES:
Natty Kernel Version: Likely 2.6.38 (final decision to be made right around Christmas) Advantage of 2.6.38 for linaro is an extra month to submit patches etc.

• Natty Kernel Flavours
  • omap3 has been dropped at the moment in Natty, follow up investigation needed (see action)
  • possibility to have multiple ARM flavours
  • Do we want to consider supporting a flavour for 64bit kernels on 32-bit userspace; seems there's no compelling reason so the answer is NO
  • low-latency, is this also needed to be officially supported?; answer is NO and continue having this be a community supported flavour.

ACTIONS:

• [] look at QEMU and determine if the versatile flavour is needed
• [] follow up on omap3 discussion and record actual commitment from linaro
• [jk] determine if we really need 3 powerpc flavours (powerpc, powerpc-smp, powerpc64-smp)
• [] pull back in ports meta package into our main kernel infrastructure to simplify maintenance
• [apw] write a skeleton document for outside consumers to reference for migrating from older versions/flavours
• [] document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)?

Improved support for touchpads and mixed devices

NOTES:

ACTIONS:

• Outcome
• Outcome
• Outcome

Hardware compatibility testing for Unity

NOTES:

Discussions of using Frame Buffer Object Architecture for testing of Unity. Mesa is already tested using piglet though there are a lot of failures and this would need cleaning up. Discussions on the application-from-hell which will be used to trigger feature testing.

ACTIONS:

• A1 - jay/macslow - add a test for FBO & TFP; check if there is are many systems that would support only the latter and not the former

• A1 - macslow - get infomation about reliable query mechanism in GL to obtain

available video-memory

• A1 - deliver 1st cut of detection-module to platform (jay/macslow)
• A1 - deliver 1st cut of application-from-hell to platform (jason)

• A1 / didrocks - provide apport support (note: see with njpatel & bryce for advices)

Automated Tests for Proposed Kernels

NOTES:

This session was merged with and formed the second session of Review of the Stable Maintenance Process. All outcomes and resolutions are documented under that session.

Kernel Device Tree

NOTES:

ACTIONS:

• Outcome
• Outcome
• Outcome

Ubuntu Kernel Delta Review

NOTES:

Ubuntu Drivers

• AUFS - still investigating a union mounts solution. still need to keep aufs for natty.
• LIRC - Dropped, use the driver in staging
• dm-raid4-5 - keep for natty
• iscsitarget - see action below
• rtl8192se - see action below
• fsam7400 - keep for natty, but review if still needed
• omnibook - keep for natty, but review if still needed
• rfkill - keep for natty, but review if still needed
• ndiswrapper - see action below
• compcache - see action below

Ubuntu Patches (not for upstream)

• Obviously keep these

Ubuntu Patches (for review)

• Review wiki page and if you are an owner of a patch(es) review if it should be sent upstream

ACTIONS:

• [smb] talk to server team if we still need to maintain iscsitarget as ubuntu driver or can we drop it and just use the DKMS package
• [canonical-kernel-team] is the rtl8192se in staging, ie can we drop maintaining as an ubuntu driver
• [canonical-kernel-team] fsam7400, omnibook, rfkill - review if still needed
• [canonical-kernel-team] investigate DKMS ndiswrapper package. Can we get rid of ubuntu driver.
• [canonical-kernel-team] compcache, think we can drop this but first speak with foundations

• [canonical-kernel-team] Add back AppArmor compatability patch (see link below)

  • http://kernel.org/pub/linux/security/apparmor/apparmor-2.6.36-patches.tgz

• [canonical-kernel-team] Review ubuntu patches for upstream submission
• [apw/ogasawara] Add action items for specific owners to review their patches which should go upstream
• [jk] Look at Arjan's patches to see if they should go upstream
• [apw] After everyone's updated the wiki with comments regarding the patches which they own, clean up the git tree to match (eg drop or keep patches)
• [jk] Review and report back to platform if there are any specific OEM patches or drivers which we need to carry

ST-E Demo and Developer Discussion

NOTES:

ACTIONS:

• Outcome
• Outcome
• Outcome

ARM power mgmt [Theme - tools]

NOTES:

The goal is to track and improve power management. Focus on planning to make a new power debug tool going further than powertop. Some additional clocks are not yet available in debugfs which will need to be fixed to enable this tool.

ACTIONS:

• Export and test the clock write access feature on a platform (vincent-guittot on ST-E platform ?). then see if it's useful and it should be deployed on other platform
• powertop hints aren't that useful, can be covered by powerdebug

Should Ubuntu provide a hardfloat-enabled ARM port? Should Linaro?

NOTES:

The performance improvements available from switching from softfloat to hardfloat are in the 30-35% range for floating point applications. Moving to hardfloat will necessitate a new ports architecture for Ubuntu. The concensus from this session was that this is a compelling direction, expect an armhf port to bootstrap in the Natty cycle with it likely to be releasing images in OO.

ACTIONS:

• dpkg
  • allocate a new architecture name in dpkg
  • triplet needs to be changed to arm-linux-gnueabi
  • vorlon to check whether buxy would be interested in doing the armhf support in dpkg as well
• add support for armhf in lintian
• markos to ask upstream: runtime linker path needs to be changed to have a different one between armel and armhf
• markos to send patch to doko to enable linaro patches when targetting armhf
• davidm to build and supply at least 6 new buildds (expected at least 8 weeks from today)
• confirm funding for the people/resources