Launchpad Entry: desktop-lucid-xorg-triaging-diagnosis
Created: 2009-11-16
Contributors: BryceHarrington
Packages affected: xorg
Summary
Development of several tools for triaging X.org bugs and diagnosing issues.
Rationale
A lot of bug reports get filed in Ubuntu against X.org, but many do not have the information necessary for investigating the issue. Having better tools will help the bug reporters, testers, and developers to isolate the problem and characterise into a form that enables a fix to be found more swiftly.
Xorg.0.log parser
Basic idea here is to be able to review log files mechanically and pull out interesting information.
Implementation Tasks
- Create python class that provides access to relevant data from the log file
- Driver used
- Error messages and warnings
- Configuration settings
- Modules loaded
- Issues with resolution determination
- Create parsing routine which takes an Xorg.0.log and generates the above structure
- Create launchpadlib tool which uses the above and adds the information to the bug
- Identify "interesting" warnings and errors (i.e. exclude innocuous messages)
- For bugs tagged 'resolution', extract the resolution detection logic and try to identify why it failed
Apport X.org Hook
Implementation Tasks
- In crash handler, experiment if sourceful stack traces would be useful [pitti]
- Integrate freeze handler for -intel bugs
- jbarnes implemented kernel-side support for sending uevents when freezes occur
- mdz has implemented apport hook for this
- Pitti says the uevents are showing up in dmesg when freezes occur; mdz hasn't seen them
- Need to integrate the apport hook into the xorg package
- Need to verify the hook does trigger when the uevents fire
- Need to verify the hook is collecting the information upstream wants
Arsenal
These are a collection of scripts used for various automated bug triaging tasks.
Implementation Tasks
- LP guys say that the auth/credential stuff is now taken care of by launchpadlib itself. Need to investigate this and if it would be worth migrating arsenal to using it.
- LP guys say there is a "heat" parameter exposed in the API. This could be useful for identifying priority bugs.
Failsafe X
These scripts are in your /etc/gdm directory. The interface can be run via /etc/gdm/failsafeXinit and the code is straightforward to hack on. (Patches welcomed!)
Implementation Tasks
- Consider hooking where 'xfix' is currently
- Need to remove the call to 'dexconf' since that no longer does anything useful
- Consider offering a mechanism to file a bug (perhaps apport-symptom?)
- Perhaps Jockey could be hooked in here so people wishing to (re-)install nvidia/fglrx could do so directly.
X Test Plans
http://wiki.ubuntu.com/X/Testing has several testing checklists for testing X. These are written assuming the user is doing the testing manually, but some or all of it might be automatable to some degree. The proprietary driver testing plan is especially important since the proprietary drivers often do not receive adequate testing during the development phase (partly because we simply don't have the rebuild drivers until late in the cycle, and partly because most active developers are on open source drivers since those are available throughout the development period).
Implementation Tasks
- Write a test plan for dual head use case
- Write a test plan for laptop+projector use case
- Complete gamer test plan (perhaps rename to performance test plan?)
- Identify how to exercise these in an organized manner, like in Ara's testing community [QA team]
- Automate some of those tests into checkbox [Marc]
Common Symptoms Guides
http://wiki.ubuntu.com/X/Troubleshooting/ documents several common ways that X can fail, including steps to work around the issues. We'd like to expand this further.
Implementation Plan
- Collect screenshots and/or videos of several common classes of failures, identifying likely causes and components [jbarnes]