Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #220614 > unrolled thread

Issue with i915 PSR module option

Back to article view | Back to linux.debian.user

Contents

  Issue with i915 PSR module option l0f4r0@tuta.io - 2020-03-28 17:50 +0100
    Re: Issue with i915 PSR module option Reco <recoverym4n@enotuniq.net> - 2020-03-28 18:00 +0100
      Re: Issue with i915 PSR module option didier gaumet <didier.gaumet@gmail.com> - 2020-03-28 18:10 +0100
        Re: Issue with i915 PSR module option l0f4r0@tuta.io - 2020-03-28 19:30 +0100
          Re: Issue with i915 PSR module option Reco <recoverym4n@enotuniq.net> - 2020-03-28 19:40 +0100
            Re: Issue with i915 PSR module option l0f4r0@tuta.io - 2020-03-28 21:10 +0100
              Re: Issue with i915 PSR module option Reco <recoverym4n@enotuniq.net> - 2020-03-28 21:20 +0100
                Re: Issue with i915 PSR module option l0f4r0@tuta.io - 2020-03-28 23:00 +0100
                  Re: Issue with i915 PSR module option Reco <recoverym4n@enotuniq.net> - 2020-03-29 09:10 +0200
                    Re: Issue with i915 PSR module option l0f4r0@tuta.io - 2020-03-30 18:40 +0200
          Re: Issue with i915 PSR module option didier gaumet <didier.gaumet@gmail.com> - 2020-03-28 21:00 +0100

#220614 — Issue with i915 PSR module option

Hi,

I'm on Buster.
Could somebody explain me please why my i915 PSR option doesn't seem to be taken into account after reboot (still -1 instead of 0):

$ sudo modinfo i915 | grep -i psr
parm:           enable_psr:Enable PSR (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int)

$ ls -l /etc/modprobe.d/i915.conf
-rw-r--r-- 1 root root 26 mars  28 17:09 /etc/modprobe.d/i915.conf

$ sudo cat /etc/modprobe.d/i915.conf
options i915 enable_psr=0

$ sudo cat /sys/module/i915/parameters/enable_psr
-1

Thank you in advance :)
l0f4r0

[toc] | [next] | [standalone]

#220616

	Hi.

On Sat, Mar 28, 2020 at 05:43:01PM +0100, l0f4r0@tuta.io wrote:
> Hi,
> 
> I'm on Buster.
> Could somebody explain me please why my i915 PSR option doesn't seem to be taken into account after reboot (still -1 instead of 0):
> 
> $ sudo modinfo i915 | grep -i psr
> parm:           enable_psr:Enable PSR (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int)
> 
> $ ls -l /etc/modprobe.d/i915.conf
> -rw-r--r-- 1 root root 26 mars  28 17:09 /etc/modprobe.d/i915.conf
> 
> $ sudo cat /etc/modprobe.d/i915.conf
> options i915 enable_psr=0
> 
> $ sudo cat /sys/module/i915/parameters/enable_psr
> -1

Probably because your /etc/modprobe.d/i915.conf did not get included in
initrd. "i915" usually gets loaded before root filesystem is loaded, so
your file does not get any effect.
Execute "update-initramfs -k all -u", check the presence of i915.conf in
initrd (lsinitrams), reboot and check it one more time.

Reco

[toc] | [prev] | [next] | [standalone]

#220617

and enable_psr must be set to 1, not 0

[toc] | [prev] | [next] | [standalone]

#220624

Hi Reco, Didier,

28 mars 2020 à 17:55 de recoverym4n@enotuniq.net:

> Probably because your /etc/modprobe.d/i915.conf did not get included in
> initrd. "i915" usually gets loaded before root filesystem is loaded, so
> your file does not get any effect.
> Execute "update-initramfs -k all -u", check the presence of i915.conf in
> initrd (lsinitrams), reboot and check it one more time.
>
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-0.bpo.2-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915

$ lsinitramfs /boot/initrd.img-5.4.0-0.bpo.2-amd64 | grep -i i915
etc/modprobe.d/i915.conf
usr/lib/firmware/i915
usr/lib/firmware/i915/bxt_dmc_ver1_07.bin
usr/lib/firmware/i915/bxt_guc_33.0.0.bin
usr/lib/firmware/i915/cnl_dmc_ver1_07.bin
usr/lib/firmware/i915/glk_dmc_ver1_04.bin
usr/lib/firmware/i915/glk_guc_33.0.0.bin
usr/lib/firmware/i915/glk_huc_ver03_01_2893.bin
usr/lib/firmware/i915/icl_guc_33.0.0.bin
usr/lib/firmware/i915/icl_huc_ver8_4_3238.bin
usr/lib/firmware/i915/kbl_dmc_ver1_04.bin
usr/lib/firmware/i915/kbl_guc_33.0.0.bin
usr/lib/firmware/i915/kbl_huc_ver02_00_1810.bin
usr/lib/firmware/i915/skl_dmc_ver1_27.bin
usr/lib/firmware/i915/skl_guc_33.0.0.bin
usr/lib/firmware/i915/skl_huc_ver01_07_1398.bin
usr/lib/modules/5.4.0-0.bpo.2-amd64/kernel/drivers/gpu/drm/i915
usr/lib/modules/5.4.0-0.bpo.2-amd64/kernel/drivers/gpu/drm/i915/i915.ko

[reboot]

$ sudo cat /sys/module/i915/parameters/enable_psr

0

=> Thank you :)
I suppose I'm expected now to download my potential missing firmwares for module i915 from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 and move them to /lib/firmware/i915?
Why aren't they distributed via traditional Debian packages?
28 mars 2020 à 18:00 de didier.gaumet@gmail.com:

> and enable_psr must be set to 1, not 0
>
I set it up to 0 because I have frequent err/3 on journalctl like the following:
kernel: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=38584 end=38585) time 167 us, min 1073, max 1079, scanline start 1070, end 1080

Some Internet resources seem to indicate PSR could be involved.
Do you think I'm gonna have more issues with PSR deactivated than left at value -1?If you have any advice, feel free :)

Thank you.Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#220625

On Sat, Mar 28, 2020 at 07:22:41PM +0100, l0f4r0@tuta.io wrote:
> Hi Reco, Didier,
...
> $ sudo cat /sys/module/i915/parameters/enable_psr
> 0
> 
> => Thank you :)

You're welcome.

> I suppose I'm expected now to download my potential missing firmwares
> for module i915
> from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 and
> move them to /lib/firmware/i915?

Depends on your card. Intel GPU Gen 6 (Skylake, 2015) and higher usually
require it. Anything older works happily without any firmware.

And it's preferred to install "firmware-misc-nonfree" package ([1])to
random downloads from Internet.


> Why aren't they distributed via traditional Debian packages?

They are, but they aren't in main archive (non-libre, no source code).

Reco

[1] https://packages.debian.org/buster/firmware-misc-nonfree

[toc] | [prev] | [next] | [standalone]

#220634

Reco,

28 mars 2020 à 19:32 de recoverym4n@enotuniq.net:

>
>
>> I suppose I'm expected now to download my potential missing firmwares
>> for module i915
>> from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 and
>> move them to /lib/firmware/i915?
>>
>
> Depends on your card. Intel GPU Gen 6 (Skylake, 2015) and higher usually
> require it. Anything older works happily without any firmware.
>
Ok, I have a Kaby Lake so a bit more recent than Sky Lake.
Isn't it strange that update-initramfs tells me that some firmwares not corresponding to my processor generation could be missing? Doesn't the tool compare firmwares with actual hardware used?

W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 

> And it's preferred to install "firmware-misc-nonfree" package ([1])to
> random downloads from Internet.
>
Actually, I had already installed firmware-misc-nonfree:

$ apt policy firmware-misc-nonfree
firmware-misc-nonfree:
  Installé : 20190717-2~bpo10+1
  Candidat : 20190717-2~bpo10+1
Table de version :
*** 20190717-2~bpo10+1 100
        100 http://deb.debian.org/debian buster-backports/non-free amd64 Packages
        100 /var/lib/dpkg/status
     20190114-2 500
        500 http://deb.debian.org/debian buster/non-free amd64 Packages

28 mars 2020 à 19:32 de recoverym4n@enotuniq.net:

> On Sat, Mar 28, 2020 at 07:22:41PM +0100, > l0f4r0@tuta.io>  wrote:
>
>> Why aren't they distributed via traditional Debian packages?
>>
>
> They are, but they aren't in main archive (non-libre, no source code).
>
My apt sources.list includes main, contrib and non-free.
I don't find the firmwares in Debian packages, only a bxt_huc old one:
$ apt-file search icl_dmc_ver
$ apt-file search tgl_dmc_ver
$ apt-file search bxt_huc_ver
firmware-misc-nonfree: /lib/firmware/i915/bxt_huc_ver01_07_1398.bin 

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#220635

On Sat, Mar 28, 2020 at 09:05:16PM +0100, l0f4r0@tuta.io wrote:
> >> I suppose I'm expected now to download my potential missing firmwares
> >> for module i915
> >> from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 and
> >> move them to /lib/firmware/i915?
> >
> > Depends on your card. Intel GPU Gen 6 (Skylake, 2015) and higher usually
> > require it. Anything older works happily without any firmware.
> >
> Ok, I have a Kaby Lake so a bit more recent than Sky Lake.
> Isn't it strange that update-initramfs tells me that some firmwares
> not corresponding to my processor generation could be missing? Doesn't
> the tool compare firmwares with actual hardware used?
> 
> W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module i915
> W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module i915
> W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 

I apply the following approach to it - if it works - it does not need
firmware blobs. Even if update-initramfs may thinks it will be useful to
include those, because it merely looks at "firmware" section of "modinfo
i915" output in this case.

If dmesg tells you your current kernel tries to load those firmware
pieces and fails, and you experience some missing functionality (X won't
start, OpenGL fails to work, VAAPI fails you) - then firmware's probably
needed.


> > They are, but they aren't in main archive (non-libre, no source code).
> >
> My apt sources.list includes main, contrib and non-free.
> I don't find the firmwares in Debian packages, only a bxt_huc old one:
> $ apt-file search icl_dmc_ver
> $ apt-file search tgl_dmc_ver
> $ apt-file search bxt_huc_ver

Even experimental does not have those.

Reco

[toc] | [prev] | [next] | [standalone]

#220638

Reco,

28 mars 2020 à 21:15 de recoverym4n@enotuniq.net:

> I apply the following approach to it - if it works - it does not need
> firmware blobs. Even if update-initramfs may thinks it will be useful to
> include those, because it merely looks at "firmware" section of "modinfo
> i915" output in this case.
>
Indeed, it looks like modinfo i915 output ;)
Maybe I'm too maniac but I just don't like so much getting warnings after a command...^^

> If dmesg tells you your current kernel tries to load those firmware
> pieces and fails, and you experience some missing functionality (X won't
> start, OpenGL fails to work, VAAPI fails you) - then firmware's probably
> needed.
>
No error on journalctl -kb
I'm loading i915/kbl_dmc_ver1_04.bin

>
>
>> > They are, but they aren't in main archive (non-libre, no source code).
>> >
>> My apt sources.list includes main, contrib and non-free.
>> I don't find the firmwares in Debian packages, only a bxt_huc old one:
>> $ apt-file search icl_dmc_ver
>> $ apt-file search tgl_dmc_ver
>> $ apt-file search bxt_huc_ver
>>
>
> Even experimental does not have those.
>
So blobs are not systematically packaged on Debian.
Then if I'm not wrong, I need to bookmark https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ so I can pick up any missing firmware?

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#220651

	Hi.

On Sat, Mar 28, 2020 at 10:51:05PM +0100, l0f4r0@tuta.io wrote:
> >> > They are, but they aren't in main archive (non-libre, no source code).
> >> >
> >> My apt sources.list includes main, contrib and non-free.
> >> I don't find the firmwares in Debian packages, only a bxt_huc old one:
> >> $ apt-file search icl_dmc_ver
> >> $ apt-file search tgl_dmc_ver
> >> $ apt-file search bxt_huc_ver
> >>
> >
> > Even experimental does not have those.
> >
> So blobs are not systematically packaged on Debian.

Rather, nobody's complaining they are missing them.

> Then if I'm not wrong, I need to
> bookmark https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ so
> I can pick up any missing firmware?

I'd file a bug report against firmware-linux-nonfree.
After all, they put in in the kernel tree for *something*.

Reco

[toc] | [prev] | [next] | [standalone]

#220698

Hi,

29 mars 2020 à 09:09 de recoverym4n@enotuniq.net:

> I'd file a bug report against firmware-linux-nonfree.
> After all, they put in in the kernel tree for *something*.
>
I've just sent an mail to debian-kernel@lists.debian.org. We'll see then...
Thank you Reco!

Best regards,
l0f4r0

[toc] | [prev] | [next] | [standalone]

#220633

Le 28/03/2020 à 19:22, l0f4r0@tuta.io a écrit :
[...]
> 28 mars 2020 à 18:00 de didier.gaumet@gmail.com:
> 
>> and enable_psr must be set to 1, not 0
>>
> I set it up to 0 because I have frequent err/3 on journalctl like the following:
> kernel: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=38584 end=38585) time 167 us, min 1073, max 1079, scanline start 1070, end 1080
> 
> Some Internet resources seem to indicate PSR could be involved.
> Do you think I'm gonna have more issues with PSR deactivated than left at value -1?If you have any advice, feel free :)
> 
> Thank you.Best regards,
> l0f4r0

My mistake: sorry, I was thinking you wanted to enable PSR :-)
I have absolutely no idea what kind of trouble deactivating PSR could
make appear

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web