On Mon, 15 Jul 2024, Francesco Poli <invernomuto@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> > 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
