checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

Interesting.

Please try some of the lookup options you can use (see pci-lookup
--help for a list). Try using the --refresh-cache and perhaps
--network.
Does libpci show the correct name now?
Does udevadm show the correct name now?

Thanks
ZK

On Mon, Apr 27, 2015 at 4:12 AM, Pierre Equoy
<pierre.equoy@xxxxxxxxxxxxx> wrote:
> Hi Zygmunt!
>
> Thanks for the quick update.
>
> I tried it on the device I used for the graphic cards tests.
>
> u@u-HP-ZBook-15u-G2:~$ ./pci-lookup.py subsystem-device 1002 6604 103c 8006
> vendor-id:   0x1002
> device-id:   0x6604
> subvendor-id:0x103c
> subdevice-id:0x8006
> subsystem-device-name: Opal XT [Radeon R7 M265]
>
> However, last week I requested the subsystem to be included in pci.ids file
> and it was accepted over the weekend [1]
>
> Before running the above command, I ran 'sudo update-pciids' and the
> /usr/share.misc/pci.ids file has been updated to include the graphic card
> (see attached file):
>
> 103c 8006  FirePro M4170
>
> So I'm expecting 'subsystem-device-name' to display 'FirePro M4170'
> instead...
>
> Any idea where the problem could come from?
>
> Thanks!
>
>
> [1]: http://pci-ids.ucw.cz/read/PC/1002/6604/103c8006
>
>
>
>
>
>
> On Fri, Apr 24, 2015 at 7:16 PM, Zygmunt Krynicki
> <zygmunt.krynicki@xxxxxxxxxxxxx> wrote:
>>
>> Hey Pierre.
>>
>> I've just released a new version (0.2) that contains a command to
>> lookup sub-devices. Have a look at it (and at the corresponding,
>> trivial-to-use API). The release changelog can be found on [1]. The
>> package can be installed with "pip3 install --user libpci". Enjoy!
>> Please tell me if you'd like to use Ubuntu packages instead.
>>
>> For a quick example on how it can be used:
>>
>> zyga@g580:~/libpci$ ./pci-lookup subsystem-device 14e4 4727 14e4 0587
>> vendor-id:   0x14e4
>> device-id:   0x4727
>> subvendor-id:0x14e4
>> subdevice-id:0x0587
>> subsystem-device-name: BCM4313 802.11bgn Wireless Network Adapter
>>
>> [1] http://libpci.readthedocs.org/en/latest/history.html#id1
>>
>> Best regards
>> ZK
>>
>> On Fri, Apr 24, 2015 at 9:31 AM, Zygmunt Krynicki
>> <zygmunt.krynicki@xxxxxxxxxxxxx> wrote:
>> > Hey, just a quick update - the four argument version is not
>> > implemented yet. I just didn't finish it yet :-) It's very easy though
>> > (just call lookup4 with four arguments) if you want to try.
>> >
>> > I'll post an update soon.
>> >
>> > On Fri, Apr 24, 2015 at 5:01 AM, Pierre Equoy
>> > <pierre.equoy@xxxxxxxxxxxxx> wrote:
>> >>
>> >>
>> >> 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
>
>
>
>
> --
> Pierre Equoy
> QA Engineer | Canonical
> www.canonical.com | www.ubuntu.com