Error in lspci command

Hi all, I was just reading the thread: No network connection and out of curiosity I typed the given command:

sudo lspci -nnk | grep -i network -A4

This is what I got:

sudo lspci -nnk | grep -i network -A4
[sudo] password for jan: 
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
02:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616]
        Subsystem: Lenovo Device [17aa:e0c6]
        Kernel driver in use: mt7921e
        Kernel modules: mt7921e
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

Do others who use(d) this command get this as well?

Using sudo is not required for the lspci command.

It is common (and for many commands required) to place all options before the term one is looking for with grep. For your command this change would give
sudo lspci -nnk | grep -i -A4 network

I tested both with and without sudo and no I did not get the error line you show.

My guess is the error is specific to your hardware.

I have the same error on my system:

~ ❯ lspci -nnk > /dev/null
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted

And I have seen it reported a few times before, e.g. I2c_designware AMDI0010:00 or Pcilib: Error reading label, and also outside of Fedora. The only thing in common between these reports I have seen seem to be that the systems have an AMD CPU. Is that also the case for your machine?

Anyway, since I have no issues with my system, so far I have simply ignored the error.

Hi Jeff, I tried your way of writing the command with and without sudo and I keep having the error message.

Hi Barry, that is also what @l-c-g wrote so I guess it is the hardware.

Hi Lars, yes I also have an AMD CPU so that must be the reason for the error message if others have reported it already. Apart from a Bluetooth/wireplumber ( bluetooth-is-broken-on-f43-kde ) issue I also have no issues, as far as I can tell, so I will close this thread now.

Thanks all for the help and the explanation of what it might be.

p.s. One question: which post deserves the honor of giving the solution to this error?

I doubt this is CPU related. I also have AMD hardware and never have seen such errors. It may be something else hardware wise though.

Running lspci |grep 00:08.3 might give you a clue to which device that is.

Also, ls /sys/bus/pci/devices/0000:00:08.3 may show the actual permission of the label file.

I agree, it’s probably not the CPU itself but something related. In my case, the ID is the same as the one Jan reported. And on this Ryzen 7840U laptop, the device is the Phoenix Internal GPP Bridge to Bus [C:A]. That’s also what the user in the second thread had for the same ID.

~ ❯ lspci -vs 00:08.3
00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] (prog-if 00 [Normal decode])
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
        Subsystem: Lenovo Device 50d9
        Flags: bus master, fast devsel, latency 0, IRQ 39, IOMMU group 10
        Bus: primary=00, secondary=66, subordinate=66, sec-latency=0
        I/O behind bridge: [disabled] [32-bit]
        Memory behind bridge: 78800000-78afffff [size=3M] [32-bit]
        Prefetchable memory behind bridge: [disabled] [64-bit]
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

The same error for the same ID in the first thread was for a Krackan Internal PCIe GPP Bridge 0 to Bus C, so the Ryzen 300 mobile APUs.

The common element appears to be the PCIe bridge of a system with an AMD mobile CPU.

Also, it doesn’t appear to be specific to one laptop manufacturer, I just checked it on my own Thinkpad T14 (7840U) and a Framework 13 (Ryzen AI 7 350) and both show the same error, with the same IDs and the Phoenix/Krackan PCIe bridges, respectively.

lspci -s 00:08.3, no need for grep and it gets you the full device info without having to specify “after context” for grep. :wink:

We had investigated this in the first thread I linked, it’s world-readable, same on my system. In the end, we didn’t figure it out, but it seems to be mostly harmless.