Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-30 Thread Stuart Henderson 
On 2024/10/18 12:48, joshua stein wrote:
> On Fri, 18 Oct 2024 at 13:28:05 +0100, Stuart Henderson wrote:
> > I've not got a test machine running yet, but from observations (I
> > haven't gone through all the logs to verify, those "seconds after start"
> > logs are a pain to correlate with time of day!) it seems to only happen
> > when the monitor is in a dpms power-saving mode. Not sure if that
> > rings any bells..
> 
> As I mentioned earlier, running xrandr or xbacklight makes it print 
> the modelines in Xorg.0.log and if your monitor has a lot of them, 
> it will print a ton.
> 
> nano:~$ wc -l /var/log/Xorg.0.log
>  809 /var/log/Xorg.0.log
> nano:~$ xbacklight -set 80
> nano:~$ wc -l /var/log/Xorg.0.log
>  905 /var/log/Xorg.0.log
> nano:~$ xbacklight -set 20
> nano:~$ wc -l /var/log/Xorg.0.log
> 1021 /var/log/Xorg.0.log
> 
> When the monitor is off, is a screensaver running?  Maybe it's 
> constantly checking xrandr to find new monitors attached?  Or some 
> other thing in mate that is adjusting backlight?

There's no screensaver running.

$ xbacklight
No outputs have backlight property

Same happens with fvwm and xset dpms force off.

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-18 Thread joshua stein 
On Fri, 18 Oct 2024 at 13:28:05 +0100, Stuart Henderson wrote:
> I've not got a test machine running yet, but from observations (I
> haven't gone through all the logs to verify, those "seconds after start"
> logs are a pain to correlate with time of day!) it seems to only happen
> when the monitor is in a dpms power-saving mode. Not sure if that
> rings any bells..

As I mentioned earlier, running xrandr or xbacklight makes it print 
the modelines in Xorg.0.log and if your monitor has a lot of them, 
it will print a ton.

nano:~$ wc -l /var/log/Xorg.0.log
 809 /var/log/Xorg.0.log
nano:~$ xbacklight -set 80
nano:~$ wc -l /var/log/Xorg.0.log
 905 /var/log/Xorg.0.log
nano:~$ xbacklight -set 20
nano:~$ wc -l /var/log/Xorg.0.log
1021 /var/log/Xorg.0.log

When the monitor is off, is a screensaver running?  Maybe it's 
constantly checking xrandr to find new monitors attached?  Or some 
other thing in mate that is adjusting backlight?

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-18 Thread Stuart Henderson 
On 2024/10/14 14:30, Stuart Henderson wrote:
> On 2024/10/08 11:08, Mark Kettenis wrote:
> > > > $ ls -lh /var/log/Xorg.0.log*
> > > > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > > > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > > > 
> > > > hmm, there are loads of modeline dumps:
> > 
> > Probably means there is an issue with hotplug detection.  Could be a
> > dodgy cable, but if it happens on more machines that is unlikely.
> 
> There are two types of machine, running the exact same config /
> software, with the same monitor type. Mostly the newer ones with
> 
> + (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) Graphics 
> (ADL-N)
> + (II) modeset(0): [DRI2]   DRI driver: iris
> 
> which are seeing the problem, but there are still a few older
> ones with
> 
> - (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 
> 4400 (HSW GT2)
> - (II) modeset(0): [DRI2]   DRI driver: crocus
> 
> which aren't running into it.
> 
> I'll get a test machine and have a look at DRMDEBUG for clues there,
> any suggestions for anything else I can look at?

I've not got a test machine running yet, but from observations (I
haven't gone through all the logs to verify, those "seconds after start"
logs are a pain to correlate with time of day!) it seems to only happen
when the monitor is in a dpms power-saving mode. Not sure if that
rings any bells..

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-14 Thread Stuart Henderson 
On 2024/10/08 11:08, Mark Kettenis wrote:
> > > $ ls -lh /var/log/Xorg.0.log*
> > > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > > 
> > > hmm, there are loads of modeline dumps:
> 
> Probably means there is an issue with hotplug detection.  Could be a
> dodgy cable, but if it happens on more machines that is unlikely.

There are two types of machine, running the exact same config /
software, with the same monitor type. Mostly the newer ones with

+ (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) Graphics 
(ADL-N)
+ (II) modeset(0): [DRI2]   DRI driver: iris

which are seeing the problem, but there are still a few older
ones with

- (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 
4400 (HSW GT2)
- (II) modeset(0): [DRI2]   DRI driver: crocus

which aren't running into it.

I'll get a test machine and have a look at DRMDEBUG for clues there,
any suggestions for anything else I can look at?

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-08 Thread Abel Abraham Camarillo Ojeda 
On Tue, Oct 8, 2024 at 8:07 AM joshua stein  wrote:

> On Tue, 08 Oct 2024 at 11:08:57 +0200, Mark Kettenis wrote:
> > > Date: Tue, 8 Oct 2024 00:59:19 +0100
> > > From: Stuart Henderson 
> > >
> > > On 2024/10/07 14:17, Stuart Henderson wrote:
> > > > On 2024/10/07 14:04, Matthieu Herrb wrote:
> > > > > The only file that Xorg writes to is its log file. Sometimes, when
> > > > > input devices go bad, it can be very verbose.
> > > > >
> > > > > Can you check if any of the Xorg.0.log files are huge ?
> > > >
> > > > yes:
> > > >
> > > > $ ls -lh /var/log/Xorg.0.log*
> > > > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > > > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > > >
> > > > hmm, there are loads of modeline dumps:
> >
> > Probably means there is an issue with hotplug detection.  Could be a
> > dodgy cable, but if it happens on more machines that is unlikely.
>
> I get modeline spam in Xorg.0.log every time I run xrandr or
> "xbacklight -set".
>

May this be related to the X lockups I reported when doing $ xbacklight
-set ... ?

https://marc.info/?l=openbsd-bugs&m=167695780419330&w=2

Sorry, not at my machine right now to test.

regards

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-08 Thread Stuart Henderson 
On 2024/10/08 09:05, joshua stein wrote:
> On Tue, 08 Oct 2024 at 11:08:57 +0200, Mark Kettenis wrote:
> > > Date: Tue, 8 Oct 2024 00:59:19 +0100
> > > From: Stuart Henderson 
> > > 
> > > On 2024/10/07 14:17, Stuart Henderson wrote:
> > > > On 2024/10/07 14:04, Matthieu Herrb wrote:
> > > > > The only file that Xorg writes to is its log file. Sometimes, when
> > > > > input devices go bad, it can be very verbose.
> > > > > 
> > > > > Can you check if any of the Xorg.0.log files are huge ?
> > > > 
> > > > yes:
> > > > 
> > > > $ ls -lh /var/log/Xorg.0.log*
> > > > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > > > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > > > 
> > > > hmm, there are loads of modeline dumps:
> > 
> > Probably means there is an issue with hotplug detection.  Could be a
> > dodgy cable, but if it happens on more machines that is unlikely.
> 
> I get modeline spam in Xorg.0.log every time I run xrandr or 
> "xbacklight -set".

That's more manageable than "every 10 seconds after some delay after the
machine started" :)

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-08 Thread joshua stein 
On Tue, 08 Oct 2024 at 11:08:57 +0200, Mark Kettenis wrote:
> > Date: Tue, 8 Oct 2024 00:59:19 +0100
> > From: Stuart Henderson 
> > 
> > On 2024/10/07 14:17, Stuart Henderson wrote:
> > > On 2024/10/07 14:04, Matthieu Herrb wrote:
> > > > The only file that Xorg writes to is its log file. Sometimes, when
> > > > input devices go bad, it can be very verbose.
> > > > 
> > > > Can you check if any of the Xorg.0.log files are huge ?
> > > 
> > > yes:
> > > 
> > > $ ls -lh /var/log/Xorg.0.log*
> > > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > > 
> > > hmm, there are loads of modeline dumps:
> 
> Probably means there is an issue with hotplug detection.  Could be a
> dodgy cable, but if it happens on more machines that is unlikely.

I get modeline spam in Xorg.0.log every time I run xrandr or 
"xbacklight -set".

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-08 Thread Mark Kettenis 
> Date: Tue, 8 Oct 2024 00:59:19 +0100
> From: Stuart Henderson 
> 
> On 2024/10/07 14:17, Stuart Henderson wrote:
> > On 2024/10/07 14:04, Matthieu Herrb wrote:
> > > The only file that Xorg writes to is its log file. Sometimes, when
> > > input devices go bad, it can be very verbose.
> > > 
> > > Can you check if any of the Xorg.0.log files are huge ?
> > 
> > yes:
> > 
> > $ ls -lh /var/log/Xorg.0.log*
> > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > 
> > hmm, there are loads of modeline dumps:

Probably means there is an issue with hotplug detection.  Could be a
dodgy cable, but if it happens on more machines that is unlikely.

> so, this is common to a bunch of machines, to the extent that some
> have run out of space in /var due to the logs.
> 
> I think I'll build an Xorg hacked up to avoid printing modelines
> to buy me a bit of time for those.
> 
> $ head -1000 /var/log/Xorg.0.log
> [   175.711] (WW) checkDevMem: failed to open /dev/mem and /dev/xf86
>   (Operation not permitted)
>   Check that you have set 'machdep.allowaperture=1'
>   in /etc/sysctl.conf and reboot your machine
>   refer to xf86(4) for details
> [   175.711]  linear framebuffer access unavailable
> [   175.721] (--) Using wscons driver on /dev/ttyC4
> [   175.743]
> X.Org X Server 1.21.1.13
> X Protocol Version 11, Revision 0
> [   175.743] Current Operating System: OpenBSD nuc715-59-205.telebizz.co.uk 
> 7.6 GENERIC.MP#338 amd64
> [   175.743]
> [   175.743] Current version of pixman: 0.42.2
> [   175.743]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [   175.743] Markers: (--) probed, (**) from config file, (==) default 
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [   175.743] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct  7 19:24:44 
> 2024
> [   175.743] (==) Using system config directory 
> "/usr/X11R6/share/X11/xorg.conf.d"
> [   175.744] (==) No Layout section.  Using the first Screen section.
> [   175.744] (==) No screen section available. Using defaults.
> [   175.744] (**) |-->Screen "Default Screen Section" (0)
> [   175.744] (**) |   |-->Monitor ""
> [   175.745] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [   175.745] (**) Allowing byte-swapped clients
> [   175.745] (==) Automatically adding devices
> [   175.745] (==) Automatically enabling devices
> [   175.745] (==) Not automatically adding GPU devices
> [   175.745] (==) Automatically binding GPU devices
> [   175.745] (==) Max clients allowed: 256, resource mask: 0x1f
> [   175.746] (==) FontPath set to:
>   /usr/X11R6/lib/X11/fonts/misc/,
>   /usr/X11R6/lib/X11/fonts/TTF/,
>   /usr/X11R6/lib/X11/fonts/OTF/,
>   /usr/X11R6/lib/X11/fonts/Type1/,
>   /usr/X11R6/lib/X11/fonts/100dpi/,
>   /usr/X11R6/lib/X11/fonts/75dpi/
> [   175.746] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [   175.746] (II) The server relies on wscons to provide the list of input 
> devices.
>   If no devices become available, reconfigure wscons or disable 
> AutoAddDevices.
> [   175.746] (II) Loader magic: 0xa5545d75500
> [   175.746] (II) Module ABI versions:
> [   175.746]  X.Org ANSI C Emulation: 0.4
> [   175.746]  X.Org Video Driver: 25.2
> [   175.746]  X.Org XInput driver : 24.4
> [   175.746]  X.Org Server Extension : 10.0
> [   175.746] (--) PCI:*(0@0:2:0) 8086:46d1:8086:7270 rev 0, Mem @ 
> 0x60/16777216, 0x40/268435456, I/O @ 0x4000/64
> [   175.746] (II) LoadModule: "glx"
> [   175.747] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
> [   175.755] (II) Module glx: vendor="X.Org Foundation"
> [   175.755]  compiled for 1.21.1.13, module version = 1.0.0
> [   175.755]  ABI class: X.Org Server Extension, version 10.0
> [   175.755] (==) Matched modesetting as autoconfigured driver 0
> [   175.755] (==) Assigned the driver to the xf86ConfigLayout
> [   175.755] (II) LoadModule: "modesetting"
> [   175.756] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
> [   175.756] (II) Module modesetting: vendor="X.Org Foundation"
> [   175.756]  compiled for 1.21.1.13, module version = 1.21.1
> [   175.756]  Module class: X.Org Video Driver
> [   175.756]  ABI class: X.Org Video Driver, version 25.2
> [   175.756] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
> [   175.772] (**) modeset(0): claimed PCI slot 0@0:2:0
> [   175.772] (II) modeset(0): using default device
> [   175.773] (II) modeset(0): Creating default Display subsection in Screen 
> section
>   "Default Screen Section" for depth/fbbpp 24/32
> [   175.773] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
> [   175.773] (==) modeset(0): RGB weight 888
> [   175.773] (==) modeset(

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-07 Thread Matthieu Herrb 
On Tue, Oct 08, 2024 at 08:44:05AM +0200, Matthieu Herrb wrote:
> this when I've a bit more time. in the mean time the patch below
> should disable the offending logs.

Oops, old version. The full one is:

Index: hw/xfree86/modes/xf86EdidModes.c
===
RCS file: /local/cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
diff -u -p -r1.20 xf86EdidModes.c
--- hw/xfree86/modes/xf86EdidModes.c11 Nov 2021 09:03:08 -  1.20
+++ hw/xfree86/modes/xf86EdidModes.c8 Oct 2024 06:48:18 -
@@ -1057,9 +1057,10 @@ xf86DDCGetModes(int scrnIndex, xf86MonPt
 int timing_level;
 struct det_modes_parameter p;
 
+#ifdef SPAM_XORG_LOG
 xf86DrvMsg(scrnIndex, X_INFO, "EDID vendor \"%s\", prod id %d\n",
DDC->vendor.name, DDC->vendor.prod_id);
-
+#endif
 quirks = xf86DDCDetectQuirks(scrnIndex, DDC, TRUE);
 
 preferred = PREFERRED_TIMING_MODE(DDC->features.msc);
@@ -1198,6 +1199,7 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
 xf86ForEachDetailedBlock(DDC, handle_detailed_monset, &p);
 
 if (Modes) {
+#ifdef SPAM_XORG_LOG
 /* Print Modes */
 xf86DrvMsg(scrnIndex, X_INFO, "Printing DDC gathered Modelines:\n");
 
@@ -1206,7 +1208,7 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
 xf86PrintModeline(scrnIndex, Mode);
 Mode = Mode->next;
 }
-
+#endif
 /* Do we still need ranges to be filled in? */
 if (!Monitor->nHsync || !Monitor->nVrefresh)
 DDCGuessRangesFromModes(scrnIndex, Monitor, Modes);



-- 
Matthieu Herrb

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-07 Thread Matthieu Herrb 
On Tue, Oct 08, 2024 at 08:12:09AM +0200, Matthieu Herrb wrote:
> 
> I don't know if you're hitting a bug or flaky hardware to trigger this
> event flow (if it happens on more than one machine flaky hardware is
> unlikely)
> 

Looking a bit deeper in  the code, this may be triggered by some
application calling XRRGetCrtcInfo() in a loop. It appears that the X
server will log the known mode lines everytime someone is calling this
X request.

This can be just running 'xrandr' without arguments in a script, or
some application that prefers polling the monitor status for some
reason.

Unfortunatly the stack of functions calls that trigger that logging
makes it hard to only disable the printing in this case. I'll look at
this when I've a bit more time. in the mean time the patch below
should disable the offending logs.

Index: hw/xfree86/modes/xf86EdidModes.c
===
RCS file: /local/cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
diff -u -p -u -r1.20 xf86EdidModes.c
--- hw/xfree86/modes/xf86EdidModes.c11 Nov 2021 09:03:08 -  1.20
+++ hw/xfree86/modes/xf86EdidModes.c8 Oct 2024 06:42:52 -
@@ -1201,12 +1201,13 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
 /* Print Modes */
 xf86DrvMsg(scrnIndex, X_INFO, "Printing DDC gathered Modelines:\n");
 
+#ifdef SPAM_XORG_LOG
 Mode = Modes;
 while (Mode) {
 xf86PrintModeline(scrnIndex, Mode);
 Mode = Mode->next;
 }
-
+#endif
 /* Do we still need ranges to be filled in? */
 if (!Monitor->nHsync || !Monitor->nVrefresh)
 DDCGuessRangesFromModes(scrnIndex, Monitor, Modes);

-- 
Matthieu Herrb

Re: huge Xorg.0.logs [was Re: uvm_fault, Xorg active, ...]

2024-10-07 Thread Matthieu Herrb 
On Tue, Oct 08, 2024 at 12:59:19AM +0100, Stuart Henderson wrote:
> On 2024/10/07 14:17, Stuart Henderson wrote:
> > On 2024/10/07 14:04, Matthieu Herrb wrote:
> > > The only file that Xorg writes to is its log file. Sometimes, when
> > > input devices go bad, it can be very verbose.
> > > 
> > > Can you check if any of the Xorg.0.log files are huge ?
> > 
> > yes:
> > 
> > $ ls -lh /var/log/Xorg.0.log*
> > -rw-r--r--  1 root  wheel  45.6K Oct  7 13:37 /var/log/Xorg.0.log
> > -rw-r--r--  1 root  wheel   433M Oct  3 11:48 /var/log/Xorg.0.log.old
> > 
> > hmm, there are loads of modeline dumps:
> 
> so, this is common to a bunch of machines, to the extent that some
> have run out of space in /var due to the logs.
> 
> I think I'll build an Xorg hacked up to avoid printing modelines
> to buy me a bit of time for those.

That's just hiding the dirt below the carpet :-) but without a better
fix 

If you really have 433M of modeline dumps, then there is something
else wrong. in the modesetting driver afaict monitor
connexion/deconnexion events come from libdrm, which gets them from
the kernel drm driver.

>From your log excerpt it seems to start 9300 seconds or so after the
initial launch of the X server which can also make it difficult to
reproduce. The start of the log file is just normal monitor suspend
and resume every hour or so, probably caused by DPMS and other power
saving mechanisms.

I don't know if you're hitting a bug or flaky hardware to trigger this
event flow (if it happens on more than one machine flaky hardware is
unlikely)

This is probably also slowing down X clients a lot since upon
detection of a monitor a lot of churn happens inside the X server.


-- 
Matthieu Herrb