GPU (APU) name was not correctly parsed

[Po-Hsu Lin]

Found on 201403-14859

It has:
ubuntu@201403-14859:~$ lspci -nn | grep '\[03'
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon APU E2-4000 with R2 Graphics] [1002:9853]

But the name of this APU was not correctly paresed

------------------------[ Test that glxgears works for ]------------------------
ID: 2013.com.canonical.certification::graphics/1_glxgears_
PURPOSE:
    This test tests the basic 3D capabilities of your video card

There is no graphic card name on this job

[Daniel Manrique (roadmr)]

Hello! Could you please attach the udev dump from this system?

udevadm info --export-db > 1343089-dump

then attach the dump file.

With this I can run it through the parser and see the data elements it produces.

Thanks!

[Daniel Manrique (roadmr)]

OK, the GPU/APU has NO product name:

path: /devices/pci0000:00/0000:00:01.0
bus: pci
category: VIDEO
driver: fglrx_pci
product_id: 38995
vendor_id: 4098
subproduct_id: 1623
subvendor_id: 4136
vendor: Advanced Micro Devices, Inc. [AMD/ATI]

At least, checkbox is unable to find the product name in the pci.ids document (/usr/share/misc/pci.ids).

On my 14.04 system, the vendor/product ID does have an entry, so maybe your system is using 12.04 and it doesn't have this entry.

In any case, without updating the pci.ids file (see update-pciids command) there's no way for the parser to identify the product name :(

I have two questions:

1- Even if the test name is incorrect, does it work properly during testing?
2- If you update the PCI IDs and then rerun checkbox, does the test name appear correctly now?

We can try updating the PCI IDs in our preseed, or if this is a mostly cosmetic problem, we can just ignore it. A third option would be for the graphics_card_resource to insert a "no_product_name" element as the product attribute, but I think this would be more confusing.

[Po-Hsu Lin (cypressyew)]

This one is on 14.04

The name from lspci changed after running "sudo update-pciids"
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R2 Graphics] [1002:9853]

To your questions,
1. Yes, it still works like a charm
2. After the pci.ids database was updated, the udevadm output still identical to the one before running update, so checkbox still unable to parse its name.

Although update-pciids does not solve the problem here, but I think it's a good idea to put it in our preseed file.

[Daniel Manrique (roadmr)]

The code to determine the product name looks at the ID_MODEL_FROM_DATABASE attribute of each element. Your card looks like this:

P: /devices/pci0000:00/0000:00:01.0
E: DEVPATH=/devices/pci0000:00/0000:00:01.0
E: DRIVER=fglrx_pci
E: ID_PCI_CLASS_FROM_DATABASE=Display controller
E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller
E: ID_VENDOR_FROM_DATABASE=Advanced Micro Devices, Inc. [AMD/ATI]
E: MODALIAS=pci:v00001002d00009853sv00001028sd00000657bc03sc00i00
E: PCI_CLASS=30000
E: PCI_ID=1002:9853
E: PCI_SLOT_NAME=0000:00:01.0
E: PCI_SUBSYS_ID=1028:0657
E: SUBSYSTEM=pci
E: USEC_INITIALIZED=12842299

Notice the required attribute is not present :( Compare with a Haswell-based GPU (from my laptop):

P: /devices/pci0000:00/0000:00:02.0
E: DEVPATH=/devices/pci0000:00/0000:00:02.0
E: DRIVER=i915
E: ID_MODEL_FROM_DATABASE=Haswell-ULT Integrated Graphics Controller
E: ID_PCI_CLASS_FROM_DATABASE=Display controller
E: ID_PCI_INTERFACE_FROM_DATABASE=VGA controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=VGA compatible controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: MODALIAS=pci:v00008086d00000A16sv00001028sd0000060Abc03sc00i00
E: PCI_CLASS=30000
E: PCI_ID=8086:0A16
E: PCI_SLOT_NAME=0000:00:02.0
E: PCI_SUBSYS_ID=1028:060A
E: SUBSYSTEM=pci
E: USEC_INITIALIZED=66350

the required attribute is present here.

If you updated the pci ids file, then I'm not sure why it's not reporting that information :( Maybe you need to restart the system, but that seems unlikely, particularly since you say it's 14.04, which I know contains the model information in pci.ids (I saw it myself here).

I'll think of another way to create a reasonable identifier for the card, in cases where the model information is not available. I'll leave this bug as Triaged/Medium, since the test is working OK (it's just confusing because it doesn't say the card's model).

[Po-Hsu Lin (cypressyew)]

Added the CDTS project base on our TPM, Chih's opinion.

[Pierre Equoy (pieq)]

I was discussing with Po-Hsu today because we've been experimenting this when certifying devices with dual GPUs. Below is an example using a laptop with Intel+AMD GPUs.

First of all, in the "About This Computer" window, I can see "Graphics Intel® Broadwell" or "Graphics AMD Radeon R7 M265 Series" depending on what GPU has been activated.

lspci gives me a different yet similar output:

$ lspci -nn | grep '\[03'
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09)
04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Opal XT [Radeon R7 M265] [1002:6604] (rev ff)

But when using plainbox, I cannot see the graphic card names:

$ plainbox run -i "2013.com.canonical.certification::graphics_card_resource" --dont-suppress-output
WARNING plainbox.runner: execution_ctrl_list not passed to JobRunner
===============================[ Analyzing Jobs ]===============================
=============================[ Session Statistics ]=============================
This session is about 0.00% complete
Estimated duration cannot be determined for automated jobs.
Estimated duration cannot be determined for manual jobs.
Size of the desired job list: 1
Size of the effective execution plan: 1
===========================[ Running Selected Jobs ]============================
---------------------------[ graphics_card_resource ]---------------------------
ID: 2013.com.canonical.certification::graphics_card_resource
Category: 2013.com.canonical.plainbox::uncategorised
... 8< -------------------------------------------------------------------------
bus: pci
category: VIDEO
driver: i915
index: 1
path: /devices/pci0000:00/0000:00:02.0
product: PCI ID 0x1616
product_id: 5654
subproduct_id: 8726
subvendor_id: 4156
vendor: Intel Corporation
vendor_id: 32902

bus: pci
category: VIDEO
driver: pcieport
index: 2
path: /devices/pci0000:00/0000:00:1c.4/0000:04:00.0
product: PCI ID 0x6604
product_id: 26116
subproduct_id: 32774
subvendor_id: 4156
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
vendor_id: 4098

The output is the same even after updating the PCI IDs with 'sudo update-pciids'.

This results in tests looking like:

- Color depth tests
     Test color depth info for PCI ID 0x1616
     Test color depth info for PCI ID 0x6604
- Compiz support tests
     Test Compiz support for PCI ID 0x1616
     Test Compiz support for PCI ID 0x6604
- Default resolution tests
     Test default resolution for PCI ID 0x1616
     Test default resolution for PCI ID 0x6604
- Default resolution tests
     Test default resolution for PCI ID 0x1616
     Test default resolution for PCI ID 0x6604

That's especially confusing when we have to switch between GPUs! :)
(and yes, I didn't know about the 'lspci -nn | grep '\[03'' command until this morning ;))

Could Checkbox/Plainbox use another method to guess the GPU names? The one used by the "About this computer" window seems to work pretty well (I've never seen it fail although I've tested quite a few devices already).

Thanks!

[Zygmunt Krynicki (zyga)]

I'm marking this as invalid. This is not a bug and we cannot fix it from what I can see.

We should update the certification process to include those new steps:
- check if there are PCI IDs for all the PCI devices present on a new machine
- contribute missing IDs to the upstream repository
- update PCI database as a part of the provisioning process

[Zygmunt Krynicki (zyga)]

I'm sure the bug is invalid now.

The device in question has the following two attributes:
E: PCI_ID=1002:6604
E: PCI_SUBSYS_ID=103C:8006

However there are no corresponding subsystem entries in the PCI database. This causes udev not to return the data that we expected. Some background on the story is here [1]

[1] http://sourceforge.net/p/pciids/mailman/message/28915866/

[Zygmunt Krynicki (zyga)]

The relevant section from the PCI database for vendor 1002 is:

 6606 Mars XTX [Radeon HD 8790M]
  1028 0684 FirePro W4170M

Note that there is no entry for 103C 8006, this is why we have no product name.

[Gabriel Zhi Chen (gabrielzchen)]

I chose 2 configs to test, (201412-16288 and 201408-15470)

 201412-16288: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] + NVIDIA Corporation Device [10de:1347]

 201408-15470: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] + Advanced Micro Devices, Inc. [AMD/ATI] Jet XT [Radeon R5 M240] [1002:6664]

201412-16288:
Set 8086:1616 as the default graphic card, then execute plainbox, the issue does not reproduce.
Set 10de:1347 as the default graphic card, then execute plainbox, the issue does not reproduce.

201408-15470:
Set 8086:1616 as the default graphic card, then execute plainbox, the issue reproduces.
Set 1002:6664 as the default graphic card, then execute plainbox, the issue does not reproduce.