From Newsgroup: comp.os.linux.misc

Each of my /var/log/syslog and /var/log/kern.log is over 1GB
today after unplugging two monitors and plugging in two different
monitors.

The hardware is about 5 years old:
- Motherboard: Asus Pro WS X570-ACE
- Processor: AMD Ryzen 7 5800X 8-Core Processor
- GPU: MSI Radeon RX5500XT
- old monitors: 2x Asus VW266H
- new monitors: 2x Asus PA279CV

Software is Devuan Daedalus.

The old monitors were connected to the first two DisplayPort
connectors via (probably no-name) DisplayPort-to-HDMI adapters
and a Kopul HDMI switchers.

The new monitors are connected to the same first two DisplayPort
connectors via PearStone DisplayPort-to-HDMI adapters and the
same Kopul HDMI switchers.

(The switchers let me push a button and see security camera
output on one monitor, then push another button to go back to
computer stuff.)

I had tested the new monitors and adapter cables via the GPU's
third DisplayPort connector, with and without going through the
switcher. All tested out well.

Today, while the machine would have been showing the text console
and not X, I physically installed the new monitors on the
above-desk mounts and plugging everything in. The switchers
showed that there was signal on the input line, but the monitors
stayed in standby mode. About the time I plugging things in,
syslog and kern.log show the following:

2026-01-12T12:00:37.370890-08:00 one kernel: [180281.980042] [drm:retrieve_link_
cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed. 2026-01-12T12:00:38.627964-08:00 one kernel: [180283.233347] ------------[ cut h
ere ]------------
2026-01-12T12:00:38.627976-08:00 one kernel: [180283.234095] WARNING: CPU: 7 PID
: 13497 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3076 dc_update_pla
nes_and_stream+0x342/0x880 [amdgpu]

then lists of kernel modules, register dumps, stack traces
and etc.

then a ton of these:

2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !

at a rate of about 980 per second for a total of about 6,803,402
lines and just over 1GB of text in each file. Thankfully, a
clean reboot of the machine accomplished via a thin-client
machine, the GPU, switchers, and monitors signed a peace treaty
and are now happily working together.

Has anyone else seen anything similar to that?

Thanks.
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 1/12/26 23:57, Robert Riches wrote:

Each of my /var/log/syslog and /var/log/kern.log is over 1GB
today after unplugging two monitors and plugging in two different
monitors.

The hardware is about 5 years old:
- Motherboard: Asus Pro WS X570-ACE
- Processor: AMD Ryzen 7 5800X 8-Core Processor
- GPU: MSI Radeon RX5500XT
- old monitors: 2x Asus VW266H
- new monitors: 2x Asus PA279CV

Software is Devuan Daedalus.

The old monitors were connected to the first two DisplayPort
connectors via (probably no-name) DisplayPort-to-HDMI adapters
and a Kopul HDMI switchers.

The new monitors are connected to the same first two DisplayPort
connectors via PearStone DisplayPort-to-HDMI adapters and the
same Kopul HDMI switchers.

(The switchers let me push a button and see security camera
output on one monitor, then push another button to go back to
computer stuff.)

I had tested the new monitors and adapter cables via the GPU's
third DisplayPort connector, with and without going through the
switcher. All tested out well.

Today, while the machine would have been showing the text console
and not X, I physically installed the new monitors on the
above-desk mounts and plugging everything in. The switchers
showed that there was signal on the input line, but the monitors
stayed in standby mode. About the time I plugging things in,
syslog and kern.log show the following:

2026-01-12T12:00:37.370890-08:00 one kernel: [180281.980042] [drm:retrieve_link_
cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed. 2026-01-12T12:00:38.627964-08:00 one kernel: [180283.233347] ------------[ cut h
ere ]------------
2026-01-12T12:00:38.627976-08:00 one kernel: [180283.234095] WARNING: CPU: 7 PID
: 13497 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3076 dc_update_pla
nes_and_stream+0x342/0x880 [amdgpu]

then lists of kernel modules, register dumps, stack traces
and etc.

then a ton of these:

2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165] [drm:dc_add_plane_to_context [amdgpu]] *ERROR* Head pipe not found for stream_state 000000000268a75b !

at a rate of about 980 per second for a total of about 6,803,402
lines and just over 1GB of text in each file. Thankfully, a
clean reboot of the machine accomplished via a thin-client
machine, the GPU, switchers, and monitors signed a peace treaty
and are now happily working together.

Has anyone else seen anything similar to that?

Thanks.

Ummm ... minor errors CAN produce HUGE log files.

You can either do a LOT of research OR just write
a root crontab script that nukes "older" logs.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

W dniu 13.01.2026 o-a06:32, c186282 pisze:

-a You can either do a LOT of research OR just write
-a a root crontab script that nukes "older" logs.

There are better options:
1. Separate /var partition, and
2. Setup logrotate: <https://linux.die.net/man/8/logrotate>

Then logs will newer exceed /var partition size limit, and in the case
of flood logs rest of OS will be not affected.

Logrotate should automatically delete older logs. Even in the case of
flood logs.
--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, PolskaEfc|Efc#, EUEfc-Efc|;
tel.: +48-609-170-742, najlepiej w godz.: 5:15-5:55 lub 17:15-17:55; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Tue, 13 Jan 2026 08:09:56 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:

Logrotate should automatically delete older logs. Even in the case of
flood logs.

systemd deals with this sort of thing a lot better.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-01-13 09:16, Lawrence DrCOOliveiro wrote:

On Tue, 13 Jan 2026 08:09:56 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:

Logrotate should automatically delete older logs. Even in the case of
flood logs.

systemd deals with this sort of thing a lot better.

Not really.

For example, in my machine I use leafnode as an nntp proxy server to
Usenet. It is very verbose, and floods the logs. With syslog, I put them
in a different file and rotate them faster, keeping only warning or
emergency level for longer.

With systemd I can do nothing. The entire verborrea of nntp is kept, and
the total is either rotated faster, or grow huge faster.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-01-13 05:57, Robert Riches wrote:

then a ton of these:

2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640] [drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909] [drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found for stream_state 000000000268a75b !
2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165] [drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found for stream_state 000000000268a75b !

Repeated entries should have been detected and filtered, with a line
like "1000 of these".
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-01-13, Lawrence DrCOOliveiro wrote:

On Tue, 13 Jan 2026 08:09:56 +0100, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:

Logrotate should automatically delete older logs. Even in the case of
flood logs.

systemd deals with this sort of thing a lot better.

Really? Care to elaborate? I'd think both would deal with it in some way
once configured to do so. Why are you elevating systemd on this regard?
What's the killer feature there that logrotate and compatible syslog implementations don't have?
--
Nuno Silva
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On 2026-01-13, Carlos E.R. wrote:

On 2026-01-13 05:57, Robert Riches wrote:

then a ton of these:

2026-01-12T12:00:38.754724-08:00 one kernel: [180283.364640]
[drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found
for stream_state 000000000268a75b !
2026-01-12T12:00:38.758717-08:00 one kernel: [180283.365909]
[drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found
for stream_state 000000000268a75b !
2026-01-12T12:00:38.758720-08:00 one kernel: [180283.367165]
[drm:dc_add_plane_to_context [amdgpu]]*ERROR* Head pipe not found
for stream_state 000000000268a75b !

Repeated entries should have been detected and filtered, with a line
like "1000 of these".

That, if present, ought to be configurable, because the timestamps are information too.
--
Nuno Silva
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Tue, 13 Jan 2026 11:22:55 +0100, Carlos E.R. wrote:

For example, in my machine I use leafnode as an nntp proxy server to
Usenet. It is very verbose, and floods the logs. With syslog, I put
them in a different file and rotate them faster, keeping only
warning or emergency level for longer.

With systemd I can do nothing. The entire verborrea of nntp is kept,
and the total is either rotated faster, or grow huge faster.

<https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html>

See the options for overall rate-limiting and log size limits,
rotation control, retention time, filtering by log level ... and of
course forwarding to syslog and other legacy places.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.misc

On Tue, 13 Jan 2026 11:24:11 +0100, Carlos E.R. wrote:

Repeated entries should have been detected and filtered, with a line
like "1000 of these".

systemd does that by default.
--- Synchronet 3.21a-Linux NewsLink 1.2