lspci missing information

dmidge · 2018-03-04 23:43:28

Hi,

I have a question on the reason that I can have incomplete information displayed by lspci -v.
Why do I have this message?

...
07:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: amdgpu
        Kernel modules: amdgpu
...

Why an unknown header? Is this because the linux kernel doesn't provide every drivers?

Thanks!

seth · 2018-03-05 08:45:08

https://bbs.archlinux.org/viewtopic.php?id=221281

"Broken HW" - undervoltage or simply because the device is unpowered (typical in a hybrid graphics szenario)

dmidge · 2018-03-12 02:25:51

Hi Seth,

Thanks for your reply! I was roaming online without understanding what was going on...
I was parsing through the other forum (the one that you linked). It seems the problem was because a hardware was disabled in the bios. But it is not my case (or there is something that I am missing, which is not impossible).

Since I am using a laptop, I assume it can't be a problem of undervoltage. Thus, I assume it is something off.
The hardware seems to be related to my graphic card, an AMD Radeon R7 M440 2GB. But I have a display that is working. So I have to assume that it is something else. Besides, I have, according to lspci :

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev c8)
        Subsystem: Acer Incorporated [ALI] Carrizo [1025:1108]
        Kernel driver in use: amdgpu

Soooo, what is going on? And how to fix my problem?

Thanks again!

seth · 2018-03-12 08:42:26

"Sooooo", this /is/ a hybrid graphics setup...
https://wiki.archlinux.org/index.php/PRIME

Fyi, oc. you can suffer from undervoltage in a notebook - eg. the dedicated GPU may rely on AC and fail on battery only.
However, it's far more likely that the GPU is not initialized because it had not been accessed yet.

dmidge · 2018-03-14 02:32:58

Hi Seth,

Thanks again a lot! I feel dumb, you were right again:

$ xrandr --listproviders                                                                                                                                      :(
Providers: number : 2
Provider 0: id: 0x75 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 3 associated providers: 1 name:AMD Radeon R7 Graphics @ pci:0000:00:01.0
Provider 1: id: 0x3f cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 1 name:AMD Radeon (TM) R7 M340 @ pci:0000:07:00.0

(And sorry for my "Sooo", but I tend to write down a bit weirdly - it could be worth though, you probably wouldn't like to see my comments when I code).

Alright then. I have to understand how to make it work. For some reason, when I tried it by following the tutorial, I had an error.

$ xrandr --setprovideroffloadsink "AMD Radeon R7 Graphics @ pci:0000:00:01.0" "AMD Radeon (TM) R7 M340 @ pci:0000:07:00.0"                                    :(
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  34 (RRSetProviderOffloadSink)
  Value in failed request:  0x75
  Serial number of failed request:  16
  Current serial number in output stream:  17

And thank you also for your side note, I had no idea that some hardware where disabled when on battery. Would it be in that case for a dying battery?

Now that I have a clearer idea to what is going on (thanks to you), I'll dive a bit more in the documentation on hybrid graphic cards, starting with https://wiki.archlinux.org/index.php/Hybrid_graphics.

Thanks again!

dmidge · 2018-03-16 01:53:20

Hi,

I have another question related to the first one.
I followed the tutorial, and I think I managed to make the configuration of PRIME technology work. But when I run "DRI_PRIME=1 lspci -v", I still have the disabled graphic card. I tried to do the same thing by launching "DRI_PRIME=1 blender" and checking if lspci changed its output, but no.
Does it mean that I failed to enabled the GPU?

Thanks.

loqs · 2018-03-16 02:13:43

DRI_PRIME has no meaning to lspci it is only used by mesa see https://cgit.freedesktop.org/mesa/mesa/ … =DRI_PRIME

dmidge · 2018-03-16 23:01:00

Hi loqs,

Ahh, okay, I was not expecting that. Thank you, that's good to know! And I just discovered that OpenCL can completely ignore PRIME. Actually, it seems to be a completely other topic. Although I wonder how we can choose the graphic card in case the designer of the application didn't specify which graphic card it was supposed to work on.

Anyway, how to make sure that if I run blender with the "DRI_PRIME=1", that it is effectively running on the other graphic card? I mean, how to check that I managed to make prime work the way it should? Blender could completely ignore the environment variable, couldn't it? (According to my experience, everything fails on the first try.)

Thanks!

seth · 2018-03-17 07:33:21

loqs wrote:

DRI_PRIME [...] is [...] used by mesa

strings /usr/lib/libGLX_mesa.so | grep DRI_PRIME

You can expect everything that doesn't ship it's own GL implementation to read this, though oc. each and every client may have completely random bugs.
Blender will probably allow to display the GL renderer string (in some about dialog?).

Arch Linux

#1 2018-03-04 23:43:28

lspci missing information

#2 2018-03-05 08:45:08

Re: lspci missing information

#3 2018-03-12 02:25:51

Re: lspci missing information

#4 2018-03-12 08:42:26

Re: lspci missing information

#5 2018-03-14 02:32:58

Re: lspci missing information

#6 2018-03-16 01:53:20

Re: lspci missing information

#7 2018-03-16 02:13:43

Re: lspci missing information

#8 2018-03-16 23:01:00

Re: lspci missing information

#9 2018-03-17 07:33:21

Re: lspci missing information

Board footer