# Slow X with high CPU use on i7-8700T video with cwm and Eizo EV2730Q screens.



## robroy (Dec 21, 2021)

FreeBSD Buddies,

X is very slow on my new 13.0-RELEASE-p5 amd64 desktop.  It's so slow that Firefox is unusable.

I also see the Xorg process using 70% of one CPU core at idle.

Does anybody have any ideas?

Attached is my Xorg.0.log.  Thanks for taking a gander!

*Hardware*



MakeLenovoModelThinkCentre M920q TinyMTM10RS-000UUSBIOSM1UKT66ACPUIntel Core i7-8700TScreensEizo EV2730Q x 2 (1920x1920)


I'm using drm-fbsd13-kmod-5.4.144.g20211013.

```
root@quack:~ # pciconf -lv | grep -B 4 VGA
vgapci0@pci0:0:2:0:    class=0x030000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x3e92 subvendor=0x17aa subdevice=0x3136
    vendor     = 'Intel Corporation'
    device     = 'CometLake-S GT2 [UHD Graphics 630]'
    class      = display
    subclass   = VGA
```


----------



## robroy (Dec 21, 2021)

More fiddling revealed that the symptom happens only when I'm using x11-wm/cwm!

X behaves normally with both twm and x11-wm/fvwm2.

I'm not even using a fishy .cwmrc file; it happens with the default configuration too.

Maybe cwm is doing something that X (on this computer) doesn't like.  I had perfect results with cwm on a different (nVidia) computer, before.


----------



## robroy (Dec 29, 2021)

Now I've found that this only happens with my Eizo EV2730Q screens, _in combination_ with x11-wm/cwm.



ScreenResolutionResultEizo EV2730Q1920x1920_PROBLEM_HP EliteDisplay E2431920x1080OKDell E1715S1280x1024OK


Running cwm with debugging looks like this.  The bottom four lines are rapidly repeated, forever.


```
% cwm -vvv
debug3: xev_handle_randr: size: 3840/1920
debug3: xev_handle_propertynotify: window: 0x75e
debug3: xev_handle_propertynotify: window: 0x75e
debug3: xev_handle_propertynotify: window: 0x40000c
debug3: xev_handle_propertynotify: window: 0x40000c
debug3: xev_handle_propertynotify: window: 0x75e
debug3: xev_handle_randr: size: 3840/1920
debug3: xev_handle_propertynotify: window: 0x75e
debug3: xev_handle_propertynotify: window: 0x75e
debug3: xev_handle_propertynotify: window: 0x75e
...
```

Meanwhile, xrandr(1) shows:


```
% xrandr    
Screen 0: minimum 320 x 200, current 3840 x 1920, maximum 16384 x 16384
DP-1 connected primary 1920x1920+0+0 (normal left inverted right x axis y axis) 476mm x 476mm
   1920x1920     59.94*+  29.94  
   2048x2048     59.41  
   1920x1200     59.88  
   1920x1080     60.00    60.00    59.94  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94  
   720x400       70.08  
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1920x1920+1920+0 (normal left inverted right x axis y axis) 476mm x 476mm
   1920x1920     59.94*+  29.94  
   2048x2048     59.41  
   1920x1200     59.88  
   1920x1080     60.00    60.00    59.94  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94  
   720x400       70.08  
HDMI-3 disconnected (normal left inverted right x axis y axis)
```

I can't tell whether the problem's in x11-wm/cwm, the X driver (drm-fbsd13-kmod-5.4.144.g20211013), or elsewhere.

'guess I may try a mailing list.

Thanks for taking a gander!


----------



## Phishfry (Dec 29, 2021)

My bet is on the drm module.
It is wacked out on HDMI by CEC handshake and repeatedly looping through the encryption schemas.

Howz that for my best guess.

You isolated it to the monitor and drm does do this encrypted handshake for monitor verification so why not test the theory with scfb? Ditch drm and try barebones.


----------



## Vull (Dec 29, 2021)

Installing x11-drivers/xf86-video-intel might also be worth a try. It works for
	
	



```
vgapci0@pci0:0:2:0:    class=0x030000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f31 subvendor=0x103c subdevice=0x8023
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Graphics & Display'
    class      = display
    subclass   = VGA
```
... on an HP Stream notebook. It seems to work okay but I haven't tested it extensively because of unrelated problems (with the wireless) on this super-cheap notebook computer.

Edited to add: This swaps out the more generic "modeset" or modesetting video driver (per your Xorg.0.log) in favor of the "intel" video driver. If this doesn't work out you can always uninstall the xf86-video-intel package after giving it a try.


----------



## Phishfry (Dec 29, 2021)

My bad those are DisplayPort connected monitors.
Still swap video drivers is first. drm is trouble alot.


----------



## robroy (Dec 29, 2021)

Thanks Phishfry and Vull.



Phishfry said:


> My bet is on the drm module.
> It is wacked out on HDMI by CEC handshake and repeatedly looping through the encryption schemas.
> 
> Howz that for my best guess.
> ...



With scfb everything's fine!

The only problem's that the video output's mirrored on both screens; I guess scfb doesn't support multiple, independent displays.



Vull said:


> Installing x11-drivers/xf86-video-intel might also be worth a try.



Thanks.  I switched to this driver (and verified that it replaced modeset), and the symptom there's actually the same as DRM/modeset.



Phishfry said:


> My bad those are DisplayPort connected monitors.
> Still swap video drivers is first. drm is trouble alot.



The two Eizo screens are attached with DisplayPort.

So, I'm back up and running for the moment with fvwm instead of cwm.

Thanks again to both of you.


----------



## Phishfry (Dec 30, 2021)

robroy said:


> I guess scfb doesn't support multiple, independent displays.


That is possible.
But the real reason for trying that is to isolate the problem.

So what I would suggest is trying different versions of the drm driver.
If you are using quarterly packages maybe try latest for newer drm driver.


----------



## robroy (Dec 30, 2021)

Thanks for your help Phishfry.

I re-installed all packages from the latest instead of quarterly branch.

Many versions remain the same (including `drm-kmod-g20190710_1` and `drm-fbsd13-kmod-5.4.144.g20211013`), but a few are newer:



QuarterlyLatestxorg-server-1.20.11_3,1xorg-server-1.20.13,1libdrm-2.4.107_1,1libdrm-2.4.109,1


The symptom's the same with these newer packages, though.

Thank you again.


----------



## grahamperrin@ (Jan 1, 2022)

FreeBSD bug 260807 – graphics/drm-{fbsd13,current,devel}-kmod: Update for drm-kmod lkpi 5.7


----------



## robroy (Jun 18, 2022)

I eyeballed this again while upgrading to 13.1-RELEASE last night.

With 13.1-RELEASE, `xorg-server-1.20.14,1`, `libdrm-2.4.110,1` and `drm-fbsd13-kmod-5.4.144.g20220223` I saw no change in the symptom.

I also tried compiling cwm 7.1 from source and saw no change (the port is still on 6.7).

Finally I disabled the `xev_handle_randr()` call in xevents.c, re-compiled and bingo--cwm runs well; the symptom's gone.


```
% diff xevents.c xevents.c.orig
488,489c488,489
<               if ((e.type - Conf.xrandr_event_base) == RRScreenChangeNotify);
<                       /* xev_handle_randr(&e); */
---
>               if ((e.type - Conf.xrandr_event_base) == RRScreenChangeNotify)
>                       xev_handle_randr(&e);
```

I suspect that gone too may be cwm's ability to respond to dynamic screen changes through RandR (like screens being removed or plugged in while X is running).  I haven't tested that yet.

But I'm very happy to be back on cwm!


----------



## Phishfry (Jun 18, 2022)

So it was the debug3 messages repeating that caused a high load?


----------



## robroy (Jun 22, 2022)

Phishfry said:


> So it was the debug3 messages repeating that caused a high load?



Thanks Phishfry.

It didn't seem like the debug messages themselves caused the load, although they did tip me off to that `xev_handle_randr()` function being called in an infinite loop.

The load seemed like one CPU core hammering away with the X-related consequences of `xev_handle_randr()` running over and over again.  It seemed like cwm was using RandR to essentially ask, non-stop, "what screens do I have, now?"

I'll mail cwm's maintainer to see if he or she has any thoughts on this.


----------

