checkbox-dev team mailing list archive

[Pierre Equoy <pierre.equoy@xxxxxxxxxxxxx>]

On Fri, Apr 24, 2015 at 3:37 AM, Zygmunt Krynicki <
zygmunt.krynicki@xxxxxxxxxxxxx> wrote:

>
>
> W dniu 23.04.2015 o 21:25, Daniel Manrique pisze:
>
>> On Thu, Apr 23, 2015 at 3:17 PM, Zygmunt Krynicki
>> <zygmunt.krynicki@xxxxxxxxxxxxx> wrote:
>>
>>> Hey
>>>
>>> A while ago I talked to Pierre about a bug where we would not see
>>> product name for a certain PCI graphics card. We looked, read, and
>>> searched and realized how the PCI database works. We thought about
>>> adding a local database or about doing something better than just not
>>> working at all.
>>>
>>
>> Just to confirm, the recent hack so that if there's no product name we
>> show the PCI ID, was that helpful at all?
>>
>
> There is an entry for the vendor:device but there's no entry for
> vendor:device subsystem:subvendor. There was no entry in the upstream
> repository.
>

OK, a bit of story here:

We often test relatively new hardware (graphic cards), so they often don't
appear in the pci.ids database. [1] For instance, ChickletW 12 [2] has a
dual AMD+Intel GPU. If I type 'lspci -k', here is what I get for the
graphic cards:

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated
Graphics (rev 09)
    Subsystem: Hewlett-Packard Company *Device 2216*
    Kernel driver in use: i915
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Opal XT [Radeon R7 M265]
    Subsystem: Hewlett-Packard Company *Device 8006*
    Kernel driver in use: fglrx_pci

Running the associated plainbox job leaves me with a very vague result:

$ plainbox run -i
"2013.com.canonical.certification::graphics_card_resource"
--dont-suppress-output
(...)

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: fglrx_pci
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 names that are going to be used through the whole testing process are
"PCI ID 0x1616" and "PCI ID 0x6604". It's better than nothing, but it's
still error-prone. (I know because it happened to me: I was not careful and
in every test it says something like "switch to this card if it's not the
one currently in use", so I mistakenly switched once or twice, it messed up
the test results and I had to restart the tests).

Now, if I edit the subsystems in the pci.ids files and re-run 'lspci -k', I
get this, which is slightly better:

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated
Graphics (rev 09)
    Subsystem: Hewlett-Packard Company *Broadwell-U Integrated Graphics*
    Kernel driver in use: i915
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Opal XT [Radeon R7 M265]
    Subsystem: Hewlett-Packard Company *FirePro M4170*
    Kernel driver in use: fglrx_pci

However, the plainbox job doesn't see this and still provides the same
output:

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: fglrx_pci
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

That said, I hope Zygmunt's lib can be helpful to access the subsystem's
information. I quickly tried libpci using the 'pci-lookup' script but I
couldn't get it to work with a "vendor:product subvendor:subproduct"
configuration.

We should push vendors to update this database but if they don't, we can
also update it ourselves. I will discuss about this with the rest of the
Stella QA team on Monday.


Cheers!



>  The bug number would be useful to see more detail about this :)
>>
>
> Sorry, I was too lazy to look it up. It is
> https://bugs.launchpad.net/plainbox-provider-checkbox/+bug/1343089
>
>  The canonical way to look up those names is through libpci. Since
>>> libpci is written in C and has a simple API I thought about making
>>> some bindings so that we can use that in checkbox.
>>>
>>> And so I did, this is an example program that does vendor or device
>>> name lookup [1, 2, 3]. Note that currently it only works on Python 3.4
>>> as I used the enum module (it doesn't work on Ubuntu 12.04).
>>>
>>> One interesting observation is the ability to query the central server
>>> when a given identifier cannot be found in a local database. You can
>>> use that by setting pci.flag_network = True (or call the pci-lookup
>>> script with --network argument at the end).
>>>
>>
>> Without more data on the bug I can only speculate, but if this
>> happened on a SUT, the solution that looks up stuff on the central
>> server may not work (tm) if the network is down for some reason. In
>> this case you'll still get no product name, which can be an issue if
>> you're running tests locally. If this is about something else, then
>> perhaps I'm wrong :)
>>
>
> There are many possibilities. Libpci can generate phony device names,
> mixed names, can use a local cache, can lookup data over network, etc. It's
> quite flexible.
>
> Personally, I think we should just use the network lookup feature in HEXR.
> This would remove any reason to update PCI database periodically as it
> would always be up-to-date.
>
>  Please tell me what you think.
>>>
>>
>> I think this is awesome! and should be quite useful.
>>
>
> I looked at the API and we can use it to enumerate devices. We can use
> various constants to filter devices (perhaps better than checkbox-support
> currently does). Have a look at this list
>
> http://libpci.readthedocs.org/en/latest/usage.html#module-libpci._macros
>
> Thanks
> ZK
>


[1]: https://pci-ids.ucw.cz/
[2]: https://certification.canonical.com/hardware/201411-16142/

-- 
Pierre Equoy
QA Engineer | Canonical
www.canonical.com | www.ubuntu.com