13:19 alien_lappy: I have a lenovo laptop and i think it has an intel chipset and an nvidia chipset; but i'm using the intel, is there a way to not load nouveau as it has issues with suspend for me (and reduce battery drain)? in the X.org log, the only reference i found to nouveau was drm; should i just blacklist nouveau driver? or do i disable one of the DRI devices somehow? or does this require X config to disable that?
13:22 tiredchiku[d]: you can blacklist nouveau to not load it, yeah
13:23 karolherbst: alien_lappy: disabling nouveau does stop it from getting powered down unless you enable that feature via a udev fule
13:23 karolherbst: *rule
13:24 karolherbst: so unless you run into issues, it's probably for the best to just keep it loaded
13:43 alien_lappy: oh, so on bootup the device gets powered down by nouveau if unused?
13:43 karolherbst: correct
13:43 karolherbst: however
13:43 alien_lappy: but the problem is, i get issues when trying suspend to disk
13:43 karolherbst: random applications might think it's a good idea to use it anyway
13:44 karolherbst: (and power it up)
13:44 karolherbst: random as in.. electron based apps like to do that
13:44 alien_lappy: ic
13:44 alien_lappy: should i disable a device instead of blacklisting nouveau?
13:44 karolherbst: ohhh.. so system suspend causes bugs for you?
13:45 alien_lappy: i was doing suspend to disk and it didn't want to and i had abunch of nouveau error lines
13:45 karolherbst: I see
13:45 karolherbst: you could file a bug here: https://gitlab.freedesktop.org/drm/nouveau/-/issues
13:45 alien_lappy: since i wasn't using it, i thought to disable it
13:45 karolherbst: but in order to solve your issue, you can blacklist nouveau
13:45 karolherbst: and
13:45 karolherbst: have a file /etc/udev/rules.d/99-all-runpm-on.rules
13:46 karolherbst: with
13:46 karolherbst: SUBSYSTEM=="pci", TEST=="power/control", ATTR{power/control}="auto"
13:46 karolherbst: this would enable the powering down unused pci device features on all your pci devices
13:46 karolherbst: (if supported by the drivers)
13:46 karolherbst: but devies without a driver will gets turned off when it's handled by the firmware (which it is for GPUs)
13:47 karolherbst: if everything works, executing "lspci" should give you a significant delay as it powers up the gpu
13:47 alien_lappy: do you think it would conflict with the wifi when it's rfkilled?
13:47 karolherbst: no idea
13:47 alien_lappy: oh, lspci powers it up?
13:47 karolherbst: for silly reasons, but yeah
13:48 alien_lappy: is there a way to manually power it down?
13:48 karolherbst: no
13:48 karolherbst: it gets powered down automatically after a few seconds
13:48 alien_lappy: oh, ok
13:48 alien_lappy: since nouveau would be blacklisted
13:48 alien_lappy: got it
13:48 alien_lappy: thanks a lot for the info
13:48 karolherbst: the udev rule is the critical part here
13:49 karolherbst: each sysfs device has this "power/control" file which enables/disables this feature
13:49 alien_lappy: does power/control refer to an executable?
13:49 karolherbst: you could also just do it for the nvidia GPU + the PCIe root port it's connected on
13:49 alien_lappy: oh, like that
13:49 karolherbst: /sys/bus/pci/devices/*/power/control
13:49 alien_lappy: it writes to the pci sysfs file
13:49 karolherbst: and there is power/status to say if the device is active or not
13:50 karolherbst: $ grep . /sys/bus/pci/devices/*/power/runtime_status
13:50 alien_lappy: i would have to match the vendor and model presumably
13:51 karolherbst: yeah
13:51 alien_lappy: in the udev rule file
13:51 karolherbst: yeah, or just do it for everything and enjoy life if it doesn't cause issues :D
13:51 karolherbst: that's what I've done
13:51 alien_lappy: haha
13:55 alien_lappy: karolherbst: oh, i noticed the lspci also listed nvidiafb as a module, i'll probably have to blacklist that one too?
13:55 karolherbst: that won't load
13:59 alien_lappy: i have SUBSYSTEM=="pci", ATTRS{idVendor}=="10de", ATTRS{idProduct}=="25a2", TEST=="power/control", ATTR{power/control}="auto" ; is that ok?
13:59 karolherbst: it might be, it might not be. You'd have to check what's the root port of the GPU and also make sure that one has power/control set to auto
14:00 karolherbst: like.. on my laptop the GPU is at 0001:00.0, but connected to 0000:01.0
14:00 karolherbst: you also have to do it for all subdevices of the GPU
14:00 karolherbst: e.g. the audio card
14:00 karolherbst: which might be at 0001:00.1
14:01 alien_lappy: ok
14:02 alien_lappy: what do you mean "connected to"?
14:03 karolherbst: lspci -t
14:03 karolherbst: the output ain't the greatest, but...
14:03 karolherbst: there is a hierachy in place
14:04 karolherbst: +-01.0-[01]--+-00.0
14:04 karolherbst: that means device 01.0 serves bus [01] and has a device at 01:00.0
14:04 karolherbst: there is also a -[0000:00]- at the top
14:04 karolherbst: which then means 0000:01.0 is the device above
14:05 karolherbst: but anyway..
14:05 karolherbst: there is an easier way to check
14:05 karolherbst: ls -lah /sys/bus/pci/devices/
14:05 karolherbst: 0000:01:00.0 ⇒ ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
14:05 karolherbst: 0000:01:00.1 ⇒ ../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1
14:05 karolherbst: the symlink points to the entire hierachy
14:06 alien_lappy: right, i think i have the same thing here
14:06 alien_lappy:           +-01.0-[01]--+-00.0
14:06 alien_lappy:           |            \-00.1
14:06 karolherbst: yeah, looks like it
14:06 karolherbst: it's the most common config
14:07 karolherbst: but I've seen exceptions
14:10 alien_lappy: so, i need to do this 3 times? for the 01.0 , the gpu and the audio ?
14:11 karolherbst: yep
14:13 alien_lappy: thx, i'll have to reboot and see if it still works :-)
14:27 alien_lappy: it seemed to work fine and starts up faster too (could be placebo)
14:37 alien_lappy: placebo: it seems the module is loaded in the dracut initrd :-( , i have to remove it from the initrd
14:42 alien_lappy: ok, i did omit-drivers with dracut so the initrd does not have nouveau, but now the plymouth stopped working, i guess it used the nouveau driver? it's a bit annoying, but good enough
14:43 alien_lappy: maybe i should've added the udev rule to the initrd as well?
14:45 karolherbst: not sure why omit-drivers would cause that...
15:58 alien_lappy: i can only think that either: dracut itself sees it as a dependency and stops plymouth, or plymouth has some odd code to init the gpu's and fails when the gpu fails?
15:58 karolherbst: yeah... though it shouldn't if the main GPU loads?
15:58 karolherbst: maybe it has to do with external connectors
22:45 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30703
22:46 HdkR: Woo MME
22:51 gfxstrand[d]: Not just MME. Unit-tested MME!
22:56 gfxstrand[d]: I should probably run this MR on Maxwell, too
23:15 marysaka[d]: Amazing <a:ferrisBongo:498944916286603265>