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

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

MakeLenovo
ModelThinkCentre M920q Tiny
MTM10RS-000UUS
BIOSM1UKT66A
CPUIntel Core i7-8700T
ScreensEizo EV2730Q x 2 (1920x1920)

I'm using drm-fbsd13-kmod-5.4.144.g20211013.
Code:
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
 

Attachments

  • Xorg.0.log.txt
    583.8 KB · Views: 110
Last edited by a moderator:
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.
 
Now I've found that this only happens with my Eizo EV2730Q screens, in combination with x11-wm/cwm.

ScreenResolutionResult
Eizo EV2730Q1920x1920PROBLEM
HP EliteDisplay E2431920x1080OK
Dell E1715S1280x1024OK

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

Code:
% 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:

Code:
% 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!
 
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.
 
Installing x11-drivers/xf86-video-intel might also be worth a try. It works for
Code:
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.
 
Thanks Phishfry and Vull.

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.

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.

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.

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.
 
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.
 
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:

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

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

Thank you again.
 
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.

Code:
% 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!
 
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.
 
Back
Top