[bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

[-- Attachment #1.1: Type: text/plain, Size: 2142 bytes --]

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!


-- 
 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: snip_kern.log --]
[-- Type: application/octet-stream, Size: 6194 bytes --]

kernel: ------------[ cut here ]------------
kernel: i915 0000:00:02.0: drm_WARN_ON(tc->mode == TC_PORT_LEGACY)
kernel: WARNING: CPU: 6 PID: 629 at drivers/gpu/drm/i915/display/intel_tc.c:895 adlp_tc_phy_connect+0x18a/0x200 [i915]
kernel: Modules linked in: snd_sof_pci_intel_tgl snd_sof_intel_hda_common nls_ascii nls_cp437 soundwire_intel vfat snd_sof_intel_hda_mlink fat soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_hdac_hda snd_soc_acpi_intel_match soundwire_generic_allocation snd_soc_acpi soundwire_bus snd_soc_avs snd_soc_hda_codec i915(+) snd_hda_ext_core btusb snd_soc_core btrtl btintel snd_compress btbcm intel_uncore_frequency iwlmvm snd_pcm_dmaengine btmtk intel_uncore_frequency_common snd_hda_intel x86_pkg_temp_thermal bluetooth intel_powerclamp snd_intel_dspcfg mac80211 coretemp snd_intel_sdw_acpi snd_usb_audio uvcvideo processor_thermal_device_pci drm_buddy snd_hda_codec processor_thermal_device kvm_intel videobuf2_vmalloc drm_display_helper sha3_generic snd_usbmidi_lib processor_thermal_wt_hint snd_hda_core uvc snd_rawmidi jitterentropy_rng processor_thermal_rfim videobuf2_memops cec libarc4 snd_hwdep kvm snd_seq_device intel_rapl_msr processor_thermal_rapl drbg videobuf2_v4l2
kernel:  rc_core mei_hdcp mei_pxp snd_pcm iwlwifi intel_rapl_common iTCO_wdt ansi_cprng ttm videodev processor_thermal_wt_req snd_timer intel_pmc_bxt intel_pmc_core rapl jc42 processor_thermal_power_floor mei_me iTCO_vendor_support drm_kms_helper videobuf2_common snd ecdh_generic cfg80211 int3403_thermal intel_cstate processor_thermal_mbox int3400_thermal intel_uncore pmt_telemetry intel_hid pcspkr mei ee1004 watchdog i2c_algo_bit ecc mc soundcore rfkill igen6_edac intel_vsec int340x_thermal_zone acpi_thermal_rel joydev pmt_class sparse_keymap acpi_pad ac button evdev hid_multitouch serio_raw efi_pstore configfs nfnetlink efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod nvme nvme_core usbhid t10_pi crc32_pclmul crc32c_intel crc64_rocksoft_generic ghash_clmulni_intel ahci crc64_rocksoft hid_generic r8169 libahci sha512_ssse3 crc_t10dif xhci_pci crct10dif_generic rtsx_pci_sdmmc libata sha512_generic realtek i2c_hid_acpi xhci_hcd crct10dif_pclmul intel_lpss_pci mmc_core
kernel:  sha256_ssse3 scsi_mod mdio_devres i2c_i801 i2c_hid crc64 intel_lpss usbcore psmouse sha1_ssse3 libphy video rtsx_pci i2c_smbus crct10dif_common scsi_common drm idma64 usb_common battery hid wmi aesni_intel crypto_simd cryptd
kernel: CPU: 6 PID: 629 Comm: (udev-worker) Not tainted 6.9.7-amd64 #1  Debian 6.9.7-1
kernel: Hardware name: Notebook NLxxPUx/NLxxPUx, BIOS 1.07.09 11/17/2023
kernel: RIP: 0010:adlp_tc_phy_connect+0x18a/0x200 [i915]
kernel: Code: 4c 8b 77 50 4d 85 f6 75 03 4c 8b 37 e8 7f 33 ec c9 48 c7 c1 50 ec dc c1 4c 89 f2 48 c7 c7 95 fc de c1 48 89 c6 e8 46 8d 6b c9 <0f> 0b 48 8b 03 48 89 df 4c 8b 30 48 8b 43 08 48 8b 00 ff d0 0f 1f
kernel: RSP: 0018:ffffaa58808d3878 EFLAGS: 00010282
kernel: RAX: 0000000000000000 RBX: ffff95ad052d0c00 RCX: 0000000000000027
kernel: RDX: ffff95b06f521708 RSI: 0000000000000001 RDI: ffff95b06f521700
kernel: RBP: ffff95ad21284000 R08: 0000000000000000 R09: 0000000000000003
kernel: R10: ffffaa58808d3708 R11: ffffffff8ceca3a8 R12: 0000000000000018
kernel: R13: 0000000000000001 R14: ffff95ad0252d3a0 R15: ffff95ad21284000
kernel: FS:  00007f5b43aed8c0(0000) GS:ffff95b06f500000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007fb2f3669238 CR3: 000000011426a004 CR4: 0000000000f70ef0
kernel: PKRU: 55555554
kernel: Call Trace:
kernel:  <TASK>
kernel:  ? __warn+0x80/0x120
kernel:  ? adlp_tc_phy_connect+0x18a/0x200 [i915]
kernel:  ? report_bug+0x164/0x190
kernel:  ? prb_read_valid+0x1b/0x30
kernel:  ? handle_bug+0x3c/0x80
kernel:  ? exc_invalid_op+0x17/0x70
kernel:  ? asm_exc_invalid_op+0x1a/0x20
kernel:  ? adlp_tc_phy_connect+0x18a/0x200 [i915]
kernel:  ? adlp_tc_phy_connect+0x18a/0x200 [i915]
kernel:  intel_tc_port_update_mode+0x1e0/0x340 [i915]
kernel:  intel_tc_port_init_mode+0xea/0x1e0 [i915]
kernel:  intel_tc_port_init+0x19b/0x230 [i915]
kernel:  intel_ddi_init+0x986/0x1060 [i915]
kernel:  ? __pfx_intel_ddi_init+0x10/0x10 [i915]
kernel:  intel_bios_for_each_encoder+0x35/0x50 [i915]
kernel:  intel_setup_outputs+0x386/0x8b0 [i915]
kernel:  intel_display_driver_probe_nogem+0x13d/0x220 [i915]
kernel:  i915_driver_probe+0x656/0xbb0 [i915]
kernel:  local_pci_probe+0x42/0xa0
kernel:  pci_device_probe+0xc7/0x240
kernel:  really_probe+0xd3/0x390
kernel:  ? __pfx___driver_attach+0x10/0x10
kernel:  __driver_probe_device+0x78/0x150
kernel:  driver_probe_device+0x1f/0x90
kernel:  __driver_attach+0xd2/0x1c0
kernel:  bus_for_each_dev+0x85/0xd0
kernel:  bus_add_driver+0x112/0x240
kernel:  driver_register+0x59/0x100
kernel:  i915_init+0x22/0xc0 [i915]
kernel:  ? __pfx_i915_init+0x10/0x10 [i915]
kernel:  do_one_initcall+0x58/0x320
kernel:  do_init_module+0x60/0x240
kernel:  init_module_from_file+0x89/0xe0
kernel:  idempotent_init_module+0x120/0x2b0
kernel:  __x64_sys_finit_module+0x5e/0xb0
kernel:  do_syscall_64+0x82/0x190
kernel:  ? syscall_exit_to_user_mode+0x7e/0x210
kernel:  ? do_syscall_64+0x8e/0x190
kernel:  ? flush_tlb_one_kernel+0xe/0x30
kernel:  ? do_kernel_range_flush+0x27/0x40
kernel:  ? __flush_smp_call_function_queue+0x95/0x400
kernel:  ? __irq_exit_rcu+0x38/0xb0
kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
kernel: RIP: 0033:0x7f5b43c969f9
kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 c3 0c 00 f7 d8 64 89 01 48
kernel: RSP: 002b:00007ffec84c4388 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
kernel: RAX: ffffffffffffffda RBX: 000055c17a9248d0 RCX: 00007f5b43c969f9
kernel: RDX: 0000000000000004 RSI: 00007f5b43ae5522 RDI: 000000000000001b
kernel: RBP: 0000000000000004 R08: 00007f5b43d63b20 R09: 000055c17a8d19d0
kernel: R10: 0000000000000040 R11: 0000000000000246 R12: 00007f5b43ae5522
kernel: R13: 0000000000020000 R14: 000055c17a924650 R15: 0000000000000000
kernel:  </TASK>
kernel: ---[ end trace 0000000000000000 ]---

[-- Attachment #1.3: dmesg.out.gz --]
[-- Type: application/gzip, Size: 53224 bytes --]

[-- Attachment #1.4: dmidecode.out.gz --]
[-- Type: application/gzip, Size: 4460 bytes --]

[-- Attachment #1.5: lspci.out.gz --]
[-- Type: application/gzip, Size: 607 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Jani Nikula]

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

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Jani Nikula]

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

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Imre Deak]

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

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Imre Deak]

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

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

[-- 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 --]

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Jani Nikula]

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

Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Francesco Poli]

[-- 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 --]