* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-15 18:35 [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli
@ 2024-07-24 16:02 ` Jani Nikula
2024-07-24 16:03 ` Jani Nikula
2024-07-24 18:30 ` Imre Deak
2 siblings, 0 replies; 8+ messages in thread
From: Jani Nikula @ 2024-07-24 16:02 UTC (permalink / raw)
To: Francesco Poli, Intel GFX list; +Cc: 1075770
On Mon, 15 Jul 2024, Francesco Poli <invernomuto@paranoici.org> wrote:
> Hi all,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously flooded with call traces
> like the attached snippet (taken from /var/log/kern.log ).
>
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with Linux
> kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
> version 6.9.8 (provided by the distro, Debian testing, as I said), but
> the bug is still reproducible:
>
> $ uname -srvmo
> Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux
>
> I see at least 12 of these call traces just after boot, before even
> starting X (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> I always see these call traces (I mean the bug is always reproducible:
> each time I boot, each time I call xrandr, ...).
>
> They seem to correspond to no actual issue, as far as I can tell,
> but they are flooding the logs with a significant flow of text...
> which is worrying by itself.
>
>
> What's wrong?
> How can I stop this log-filling flood?
> Should I black-list some module, for instance?
>
>
> The outputs of
>
> # lspci -vnn -d :*:0300
>
> and of
>
> # dmidecode
>
> are attached.
> Also, I booted with kernel parameters
> 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
> logged in as root right after the boot.
> The output of
>
> # dmesg
>
> is attached.
>
> Some additional information may be found on the [Debian bug] report I had previously filed.
>
> [Debian bug]: <https://bugs.debian.org/1075770>
>
>
> N.B.:
> Please Cc me and the Debian bug address <1075770@bugs.debian.org>
> on replies, so that the interested parties (including me!) are kept
> in the loop.
> Thanks a lot for your time and for any help you may provide!
Please file i915 bugs at fdo gitlab as described at [1].
BR,
Jani.
[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-15 18:35 [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli
2024-07-24 16:02 ` Jani Nikula
@ 2024-07-24 16:03 ` Jani Nikula
2024-07-24 18:40 ` Imre Deak
2024-07-24 18:30 ` Imre Deak
2 siblings, 1 reply; 8+ messages in thread
From: Jani Nikula @ 2024-07-24 16:03 UTC (permalink / raw)
To: imre.deak, Francesco Poli, Intel GFX list
On Mon, 15 Jul 2024, Francesco Poli <invernomuto@paranoici.org> wrote:
> Hi all,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously flooded with call traces
> like the attached snippet (taken from /var/log/kern.log ).
>
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with Linux
> kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
> version 6.9.8 (provided by the distro, Debian testing, as I said), but
> the bug is still reproducible:
>
> $ uname -srvmo
> Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux
>
> I see at least 12 of these call traces just after boot, before even
> starting X (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> I always see these call traces (I mean the bug is always reproducible:
> each time I boot, each time I call xrandr, ...).
>
> They seem to correspond to no actual issue, as far as I can tell,
> but they are flooding the logs with a significant flow of text...
> which is worrying by itself.
>
>
> What's wrong?
> How can I stop this log-filling flood?
> Should I black-list some module, for instance?
>
>
> The outputs of
>
> # lspci -vnn -d :*:0300
>
> and of
>
> # dmidecode
>
> are attached.
> Also, I booted with kernel parameters
> 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
> logged in as root right after the boot.
> The output of
>
> # dmesg
>
> is attached.
>
> Some additional information may be found on the [Debian bug] report I had previously filed.
>
> [Debian bug]: <https://bugs.debian.org/1075770>
>
>
> N.B.:
> Please Cc me and the Debian bug address <1075770@bugs.debian.org>
> on replies, so that the interested parties (including me!) are kept
> in the loop.
> Thanks a lot for your time and for any help you may provide!
[dropping Debian bug tracker]
Imre, I'm looking at the warnings in intel_tc.c in general, and
adlp_tc_phy_connect() in particular, and I think this is too hard to
parse:
if (!adlp_tc_phy_take_ownership(tc, true) &&
!drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
drm_dbg_kms(&i915->drm, "Port %s: can't take PHY ownership\n",
tc->port_name);
goto out_put_port_power;
}
if (!tc_phy_is_ready(tc) &&
!drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
drm_dbg_kms(&i915->drm, "Port %s: PHY not ready\n",
tc->port_name);
goto out_release_phy;
}
There are warnings in the logs, but they are for tc->mode ==
TC_PORT_LEGACY. Why is that warning duplicated in both if conditions,
and negated?! Too hard for my poor brain to follow. Don't know which one
happened, don't know what's going on.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-24 16:03 ` Jani Nikula
@ 2024-07-24 18:40 ` Imre Deak
0 siblings, 0 replies; 8+ messages in thread
From: Imre Deak @ 2024-07-24 18:40 UTC (permalink / raw)
To: Jani Nikula; +Cc: Francesco Poli, Intel GFX list
On Wed, Jul 24, 2024 at 07:03:51PM +0300, Jani Nikula wrote:
> [...]
> Imre, I'm looking at the warnings in intel_tc.c in general, and
> adlp_tc_phy_connect() in particular, and I think this is too hard to
> parse:
>
> if (!adlp_tc_phy_take_ownership(tc, true) &&
> !drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
> drm_dbg_kms(&i915->drm, "Port %s: can't take PHY ownership\n",
> tc->port_name);
> goto out_put_port_power;
> }
>
> if (!tc_phy_is_ready(tc) &&
> !drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
> drm_dbg_kms(&i915->drm, "Port %s: PHY not ready\n",
> tc->port_name);
> goto out_release_phy;
> }
>
> There are warnings in the logs, but they are for tc->mode ==
> TC_PORT_LEGACY. Why is that warning duplicated in both if conditions,
> and negated?!
The WARNs' conditions are unexpected on legacy ports, but the connect
sequence should not be aborted on those (as there is nothing else that
could use the port/PHY in that case). The debug message could be
printed for legacy ports as well..
> Too hard for my poor brain to follow. Don't know which one
> happened, don't know what's going on.
It's the second 'PHY not ready' check based on the WARN's line number /
kernel version.
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-15 18:35 [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces Francesco Poli
2024-07-24 16:02 ` Jani Nikula
2024-07-24 16:03 ` Jani Nikula
@ 2024-07-24 18:30 ` Imre Deak
2024-07-25 21:59 ` Francesco Poli
2 siblings, 1 reply; 8+ messages in thread
From: Imre Deak @ 2024-07-24 18:30 UTC (permalink / raw)
To: Francesco Poli; +Cc: Intel GFX list, 1075770, Jani Nikula
On Mon, Jul 15, 2024 at 08:35:43PM +0200, Francesco Poli wrote:
> Hi all,
> on a laptop where I installed Debian testing some 6 months ago,
> I noticed that the logs are continuously flooded with call traces
> like the attached snippet (taken from /var/log/kern.log ).
>
> It seems to me that it also used to happen with previous versions
> of the Linux kernel, but I am under the impression that, with Linux
> kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel
> version 6.9.8 (provided by the distro, Debian testing, as I said), but
> the bug is still reproducible:
>
> $ uname -srvmo
> Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux
>
> I see at least 12 of these call traces just after boot, before even
> starting X (with 'startx').
> More of these call traces are sent to the logs after starting X, or
> after invoking 'xrandr', or after locking the X session (with
> XScreenSaver), ...
> I always see these call traces (I mean the bug is always reproducible:
> each time I boot, each time I call xrandr, ...).
>
> They seem to correspond to no actual issue, as far as I can tell,
> but they are flooding the logs with a significant flow of text...
> which is worrying by itself.
>
>
> What's wrong?
> How can I stop this log-filling flood?
> Should I black-list some module, for instance?
>
>
> The outputs of
>
> # lspci -vnn -d :*:0300
>
> and of
>
> # dmidecode
>
> are attached.
> Also, I booted with kernel parameters
> 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and
> logged in as root right after the boot.
> The output of
>
> # dmesg
>
> is attached.
Thanks for the logs. The VBT claims that the laptop has 1 USB-C
and 3 legacy DP connectors (the latter 3 being a bit odd on a laptop,
even if not impossible). The DMI in BIOS says:
DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023
for which I can't find the particular system to check the actual
configuration. Could you point to the laptop vendor/model's page or
describe what are the connectors on it?
Could you check if there is a BIOS upgrade available? Please follow up
on the gitlab issue as Jani suggested.
> Some additional information may be found on the [Debian bug] report I had previously filed.
>
> [Debian bug]: <https://bugs.debian.org/1075770>
>
>
> N.B.:
> Please Cc me and the Debian bug address <1075770@bugs.debian.org>
> on replies, so that the interested parties (including me!) are kept
> in the loop.
> Thanks a lot for your time and for any help you may provide!
>
>
> --
> http://www.inventati.org/frx/
> There's not a second to spare! To the laboratory!
> ..................................................... Francesco Poli .
> GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-24 18:30 ` Imre Deak
@ 2024-07-25 21:59 ` Francesco Poli
2024-07-29 10:19 ` Jani Nikula
0 siblings, 1 reply; 8+ messages in thread
From: Francesco Poli @ 2024-07-25 21:59 UTC (permalink / raw)
To: imre.deak; +Cc: Intel GFX list, 1075770, Jani Nikula
[-- Attachment #1.1: Type: text/plain, Size: 3553 bytes --]
On Wed, 24 Jul 2024 21:30:00 +0300 Imre Deak wrote:
[...]
> Thanks for the logs.
Thanks to you for looking into them!
By the way, I have just upgraded the Linux kernel, but the
issue stays the same:
$ uname -srvmo
Linux 6.9.10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.10-1 (2024-07-19) x86_64 GNU/Linux
> The VBT claims that the laptop has 1 USB-C
which I think it has (and dmidecode seems to see it)...
> and 3 legacy DP connectors (the latter 3 being a bit odd on a laptop,
> even if not impossible).
Do you mean that I should see 3 external DisplayPort connectors?
I really cannot spot them.
I cannot see any set of three identical connectors on the "outer
surface" of the laptop case, actually.
However, the graphics software stack sees them, as confirmed by
the output of 'xrandr' (attached).
Could they be internal (unused) connectors?
Or maybe they are not really present in the hardware, and the Linux
kernel wrongly thinks they are there, because of some bug...?
Could this happen?!?
> The DMI in BIOS says:
>
> DMI: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023
>
> for which I can't find the particular system to check the actual
> configuration. Could you point to the laptop vendor/model's page or
> describe what are the connectors on it?
The label on the bottom of the laptop case says:
MODEL: NL41PU
and
PRODUCT CODE: NL41PU2
According to the same label, the brand should be [Clevo].
[Clevo]: <https://clevo-computer.com/en/>
I bought the laptop from an Italian shop which, among other things,
assembles customized laptops, that can be configured through
a web [configurator] (unfortunately, it seems that the website
is in Italian only...).
[configurator]: <https://syspack.com/configuratoreNotebook.php>
The notebook that I selected (along with other components) is
identified as "Work14 i5-1235U DDR4 M.2 14" FullHD"
The provided description (translated into English by me) is attached.
I think the Clevo NL41PU laptop is the same as the one
described [here].
[here]: <https://laptopwithlinux.com/product/clevo-nl41/>
>
> Could you check if there is a BIOS upgrade available?
Following from the Clevo [support] site, I think I found
the relevant download server [folder], but it seems to me that
there is no upgrade later than "1.07.09 11/17/2023"...
Actually, I cannot even see that version, which is awkward.
Maybe I am misunderstanding something... :-(
Or maybe not: I have also asked the shop about possible BIOS upgrades,
and they replied to me that there are no BIOS upgrades yet for that
model, as far as they can tell.
[support]: <https://clevo-computer.com/en/support-drivers>
[folder]: <https://my.hidrive.com/share/yze8mg-wf8#$/BIOS%20and%20EC%20Firmware/CLEVO/N_Series/NLxxx/NLxxPxx/NL4xPUx>
> Please follow up
> on the gitlab issue as Jani suggested.
I had reported the bug to the Debian BTS (Bug Tracking System), where
I was told to report the bug upstream, by contacting developers/mailing
lists.
Now on this mailing list, I am being told to report the issue on
gitlab.freedesktop.org (which requires to register an account, in order
to report issues)... Having to jump through all these hoops is beginning
to be a little time consuming... :-(
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
[-- Attachment #1.2: xrandr.out.gz --]
[-- Type: application/gzip, Size: 555 bytes --]
[-- Attachment #1.3: work14_description.txt.gz --]
[-- Type: application/gzip, Size: 768 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-25 21:59 ` Francesco Poli
@ 2024-07-29 10:19 ` Jani Nikula
2024-10-29 7:47 ` Francesco Poli
0 siblings, 1 reply; 8+ messages in thread
From: Jani Nikula @ 2024-07-29 10:19 UTC (permalink / raw)
To: Francesco Poli, imre.deak; +Cc: Intel GFX list, 1075770
On Thu, 25 Jul 2024, Francesco Poli <invernomuto@paranoici.org> wrote:
> I had reported the bug to the Debian BTS (Bug Tracking System), where
> I was told to report the bug upstream, by contacting developers/mailing
> lists.
> Now on this mailing list, I am being told to report the issue on
> gitlab.freedesktop.org (which requires to register an account, in order
> to report issues)... Having to jump through all these hoops is beginning
> to be a little time consuming... :-(
There are a number of reasons why email and mailing lists are really bad
for reporting bugs, from our perspective, which is why we've asked
people to report bugs to freedesktop.org bug trackers for about a decade
now.
If the right person doesn't have time to resolve the issue right away,
it'll likely be forgotten on the mailing list. Attachments aren't
welcome on mailing lists, let alone big logs. It's easier to label and
reference issues on a bug tracker. It's easier (yes, for us) to manage
the issues, and the people working on them, on a bug tracker. And so on.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
2024-07-29 10:19 ` Jani Nikula
@ 2024-10-29 7:47 ` Francesco Poli
0 siblings, 0 replies; 8+ messages in thread
From: Francesco Poli @ 2024-10-29 7:47 UTC (permalink / raw)
To: Jani Nikula; +Cc: imre.deak, Intel GFX list, 1075770
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
Control: forwarded -1 https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12246
On Mon, 29 Jul 2024 13:19:06 +0300 Jani Nikula wrote:
[...]
> There are a number of reasons why email and mailing lists are really bad
> for reporting bugs, from our perspective, which is why we've asked
> people to report bugs to freedesktop.org bug trackers for about a decade
> now.
>
> If the right person doesn't have time to resolve the issue right away,
> it'll likely be forgotten on the mailing list. Attachments aren't
> welcome on mailing lists, let alone big logs. It's easier to label and
> reference issues on a bug tracker. It's easier (yes, for us) to manage
> the issues, and the people working on them, on a bug tracker. And so on.
I filed an issue report on the freedesktop.org tracker (however, there
have been no replies yet).
I still experience the bug with:
$ uname -srvmo
Linux 6.11.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.4-1 (2024-10-20) x86_64 GNU/Linux
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread