Kernel Team Hardware Database

Use Cases

1. Linking hardware profiles (more specifically devices and drivers) to bug reports.

• The majority of the kernel team's use case revolves around the ability to tie a profile (specifically a device/driver) to a bug report. It helps prioritize bugs and day to day triaging.

2. Be able to search on hardware vendor and product.

• I want to examine all bugs tagged "suspend" and determine which hardware vendor and model (eg. system.hardware.vendor="Dell Inc." and system.hardware.product="Inspiron 1420") each bug is being reported against. This will help to determine possible duplicate bugs and ensure they are duped to one master bug.

3. Run device statistics on the following devices.

• It would be interesting to see which chipsets are in heaviest use amongst Ubuntu users. Take a look at http://qa.ubuntu.com/reports/ogasawara/tmp/intel-devices.html. I think we can do better.

4. Restrict hwdb searches to just a bug *reporters* profile.

• I just want to search for bugs that have a reporter with the specified hw. I don't care about the subscribers of the bug since some people subscribe to bug just to monitor a bug but don't have the affected hw. Also, many times people have the same symptom of a bug but in reality they don't have the same hw so it's a different bug.

5. Restrict hwdb searches to just the bug *subscribers*.

• I can take a known hw specific bug and find subscribers who need to open a new bug because they have different hardware. Otherwise they just end up spamming the bug with unrelated comments and making it more difficult for developers and triagers to follow the relevant issue.

6. Restrict hwdb searches to a specific package a bug was filed against.

• A person may have submitted a hw profile but I only want to see bugs they reported against the "linux" kernel source package that the profile may be related to. I don't necessarily want to know about bugs they filed against say xorg for example.

7. Intermixing search options.

• I'd like to search for all subscribers of a bug 359392 which have the i965 graphics controller [8086:2a02]. Or I'd like to search for all bugs tagged "suspend" whose bug reporter has a graphics card which uses the nvidiafb driver.

8. Need to be able to expire profiles.

• Bug reporter's hw has died.

9. Find the top 10 drivers with the most bugs assigned against them in the last 30 days.

10. Find machines which have bugs on a release.

• What systems are running karmic and have issues.

11. Which machines have which hardware.

• Find all vendor/products with a particular audio codec, wireless nic, video processor, etc.

12. Which users have particular hardware.

• Be able to perform the previous query and then have it tell you which users have that hardware.

Data Sources

• Launchpad bug reports. Most bugs have logs attached by the bug submitter. Hardware information from these logs will be used to populate the HWDB. We will only be looking at the information submitted by the original bug submitter. The following logs will be used:
  • lspci (sudo lspci -vvv)
  • lsusb (sudo lsusb)
  • lshw (sudo lshw -xml -numeric)
  • Apport creates the bug description from dmi information, the bug description will be parsed to extract any desired information.
  • It may be possible to go from a bug report, back to the submitters account where they may have submitted HW profile information (lshw) via checkbox.

• The hardware certification database: (https://certification.canonical.com/home)

• Hardware testing sessions at Linux expos and conventions and by locos.
• Looking at LP bug: 338772
  • udevadm info --export-db

  • grep -r . /sys/class/dmi/id/ 2>/dev/null

  • devkit-disks --dump
  • devkit-power --dump
  • Looks like some major changes have occured with the HW submission that checkbox performs. I'm curious if this should also be done by apport and attached to the bug.
• Pull the HW profiles that users have submitted to launchpad.

Implementation Details

One of the main complaints with the HW data in launchpad is getting it back out to perform queries on. Since we will be using CouchDB as the datastore this should be much easier.

• Developers will be able to replicate the data to their own CouchDB databases on their local systems if they wish to do so.
• The python interface to CouchDB provides full access to all of the data in the database without have to do API work such as happens with Launchpad.
• Queries can be easily written which run on the database server.

I've already talked to Pete Graner about the desire to locate hardware in the London DC. The purpose of this would be to have a system with better connectivity to Launchpad.

Performance is a major concern. It doesn't do any good to have a HWDB that takes a long time to get information out of. Launchpad has this problem today, this HWDB must be much better.

Issues

1. Keeping the related bug information up-to-date is going to be a challenge. We don't want to have to constantly poll all the launchpad bugs to see if things have changed. I think hooking into the email notifications would be a good idea.