Hello, on a laptop where I installed Debian testing some 6 months ago, I noticed that the logs are continuously filled 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/6.9.7-1, it got worse. I see 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), ... They seem to correspond to no actual issue, as far as I can tell, but they are filling the logs with a significant flow of text... which is worrying by itself. What's wrong? How can I stop this log-filling flood?
Hi Francesco, We discussed your case in the last kernel-team meeting and came to the conclusion that if possible you report your issue upstream and keep us here in the loop about progressm. I was not clear though if you need some guidance to do so. The get the correct contact addresses for reporting the issue you can use the get_maintainers.pl script in the upstream source. I would suggest to approach the following people: $ ./scripts/get_maintainer.pl drivers/gpu/drm/i915/display/intel_tc.c Jani Nikula <jani.nikula@linux.intel.com> (supporter:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS) Rodrigo Vivi <rodrigo.vivi@intel.com> (supporter:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS) Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (supporter:INTEL DRM I915 DRIVER (Meteor Lake, DG2 and old...) Tvrtko Ursulin <tursulin@ursulin.net> (supporter:INTEL DRM I915 DRIVER (Meteor Lake, DG2 and old...) David Airlie <airlied@gmail.com> (maintainer:DRM DRIVERS) Daniel Vetter <daniel@ffwll.ch> (maintainer:DRM DRIVERS) intel-gfx@lists.freedesktop.org (open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS) intel-xe@lists.freedesktop.org (open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS) dri-devel@lists.freedesktop.org (open list:DRM DRIVERS) linux-kernel@vger.kernel.org (open list) Regards, Salvatore
On Sat, 13 Jul 2024 15:04:49 +0200 Salvatore Bonaccorso wrote: [...] [...] Wouldn't it be so much easier, if you just forward my bug report upstream?
Hi, You are directly affected and we cannot reproduce the issue on our own, so we gave you guidance on where exactly to report it. If you directly report it you get the direct interaction with upstream, as you might be the only one providing additional feedback on question. But sure if you do not want to report it, I can forward to the maintainers with similar effect, just let me know if you prefer to not write on your own to upstream. Regards, Salvatore
On Sat, 13 Jul 2024 20:56:08 +0200 Salvatore Bonaccorso wrote: [...] [...] OK, I'll try, but, depending on which feedback I am asked to provide, I could need some help from you.
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
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.
On Wed, 24 Jul 2024 21:30:00 +0300 Imre Deak wrote: [...] 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 which I think it has (and dmidecode seems to see it)... 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 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/> 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> 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.
On Mon, 29 Jul 2024 13:19:06 +0300 Jani Nikula wrote: [...] 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
This is actually really easy to reproduce. Any N100 or N97 cpu will also have this bug. I cannot recompile the kernel to test the latest drm-tip though, but if someone else on this mailing list can, we would appreciate it if you would post your findings on the gitlab bug https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12246 Either that or maybe suggest a PPA Ubuntu kernel repo that has a newer version of drm-tip that we can test Cheers Angelo