NetBSD Problem Report #58318

From rhialto@falu.nl  Thu Jun  6 19:55:17 2024
Return-Path: <rhialto@falu.nl>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 498761A9238
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  6 Jun 2024 19:55:17 +0000 (UTC)
Message-Id: <ZmIUGwhtq6q-RxOB@falu.nl>
Date: Thu, 6 Jun 2024 21:55:07 +0200
From: Rhialto <rhialto@falu.nl>
Reply-To: Rhialto <rhialto@falu.nl>
To: gnats-bugs@NetBSD.org
Subject: Slow/incremental updating of Firefox menu entries
X-Send-Pr-Version: 3.95

>Number:         58318
>Category:       xsrc
>Synopsis:       Slow/incremental updating of Firefox menu entries
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 06 20:00:00 +0000 2024
>Last-Modified:  Fri Aug 09 20:40:01 +0000 2024
>Originator:     Rhialto
>Release:        NetBSD 10.0
>Organization:
>Environment:
	<The following information is extracted from your kernel. Please>
	<append output of "ldd", "ident" where relevant (multiple lines).>
System: NetBSD murthe.falu.nl 10.0 NetBSD 10.0 (GENERIC) #0: Sat May 18 22:55:37 CEST 2024 rhialto@murthe.falu.nl:/mnt/scratch/scratch/tmp/xcrash/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
        This is using Intel integrated graphics, and the modesetting driver
        for X.
	Start Firefox (I used version 123.0.1 from pkgsrc stable branch).
	Click on one of the menus in the menu bar. A menu drops open.
	Move the mouse down along the menu items.
	The item under the mouse is supposed to be highlighted by
	inverting the colours.

	However the pixels are not updated immediately. It happens
	incrementally over the course of sometimes several seconds. It
	is like the data is written into some kind of cache which isn't
	copied to its final destination immediately, but only as parts
	of it get pushed out because of evictions. 

	I saw the same effect on different machines with different
	generations of Intel graphics (several years in between).

	Running xcompmgr is partially a workaround for this.
	But it is clearly not a full fix:
	xpdf4 doesn't work with it (probably a bug in xpdf4, but still).
	Other cases of caches not being pushed do still happen.
	I have a case where really strange things are rendered while just
	resizing an xterm with text in it. (video available on request)

	Originally I thought that fixing a similar effect with updating
	mouse cursors (PR xsrc/58307) would automatically fix this
	problem, but apparently this is not the case.

>How-To-Repeat:
	as above.
>Fix:
	Not yet known.

	For diagnostics, here is a list of unique ioctls that the X
	server issues while logging in from xdm and then going through
	the above scenario.

   817    510 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR,)
   817    817 X        CALL  ioctl(0x15,TIOCGETA,)
   817    817 X        CALL  ioctl(0x15,WSMOUSEIO_SETVERSION,)
   817    817 X        CALL  ioctl(0xe,KDGETLED,)
   817    817 X        CALL  ioctl(0xe,KDSETMODE,)
   817    817 X        CALL  ioctl(0xe,KDSKBMODE,)
   817    817 X        CALL  ioctl(0xe,TIOCFLUSH,)
   817    817 X        CALL  ioctl(0xe,TIOCSETA,)
   817    817 X        CALL  ioctl(0xe,VT_ACTIVATE,)
   817    817 X        CALL  ioctl(0xe,VT_RELDISP,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_AUTH_MAGIC,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_CRTC_GET_SEQUENCE,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_DROP_MASTER,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_GEM_CLOSE,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_GEM_FLINK,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CREATEPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR2,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_DESTROYPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_DIRTYFB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETCONNECTOR,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETRESOURCES,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_LIST_LESSEES,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_OBJ_SETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_SETCRTC,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_SETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_RADEON_CP_RESUME,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_RADEON_GEM_OP,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_SET_MASTER,)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x5d,0x20),)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x5f,0xc),)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x69,0x40),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x57,0x8),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x5b,0x10),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x5e,0x28),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x61,0x10),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x66,0xc),)

	I suppose that the names with RADEON are about ioctl numbers
	that have multiple names.

>Audit-Trail:
From: Rhialto <rhialto@falu.nl>
To: gnats-bugs@netbsd.org
Cc: Rhialto <rhialto@falu.nl>
Subject: Re: xsrc/58318: Slow/incremental updating of Firefox menu entries
Date: Thu, 6 Jun 2024 22:22:36 +0200

 _IOWR('d',0x57,0x8),)	0x17	DRM_I915_GEM_BUSY	
 _IOWR('d',0x5b,0x10),)	0x1b	DRM_I915_GEM_CREATE
 _IOW('d',0x5d,0x20),)	0x1d	DRM_I915_GEM_PWRITE
 _IOWR('d',0x5e,0x28),)	0x1e	DRM_I915_GEM_MMAP
 _IOW('d',0x5f,0xc),)	0x1f	DRM_I915_GEM_SET_DOMAIN	
 _IOWR('d',0x61,0x10),)	0x21	DRM_I915_GEM_SET_TILING
 _IOWR('d',0x66,0xc),)	0x26	DRM_I915_GEM_MADVISE
 _IOW('d',0x69,0x40),)	0x29	DRM_I915_GEM_EXECBUFFER2 or DRM_I915_GEM_EXECBUFFER2_WR

 RADEON_CP_RESUME	0x18	DRM_I915_GEM_THROTTLE
 RADEON_GEM_OP		0x2c	DRM_I915_GEM_WAIT

From: Rhialto <rhialto@falu.nl>
To: gnats-bugs@netbsd.org
Cc: Rhialto <rhialto@falu.nl>
Subject: Re: xsrc/58318: Slow/incremental updating of Firefox menu entries
Date: Tue, 11 Jun 2024 20:53:55 +0200

 I tried a crude hack with reducing "uncached" memory to "write combined"
 for a very un-precise set of cases: change pgprot_t ttm_io_prot(uint32_t
 caching_flags, pgprot_t tmp).

 However it didn't make any visible difference. I think that from this we
 can conclude that more subtle variations of a change here will not be a
 cure either.

 This was my change:

 --- usr/src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo_util.c.orig	2024-06-11 18:31:46.463037658 +0200
 +++ usr/src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo_util.c	2024-06-11 18:32:10.000825945 +0200
 @@ -606,7 +606,7 @@
  {
  	/* Cached mappings need no adjustment */
  	if (caching_flags & TTM_PL_FLAG_CACHED)
 -		return tmp;
 +		return tmp | PMAP_WRITE_COMBINE;

  #ifdef __NetBSD__
  	tmp &= ~PMAP_CACHE_MASK;

From: Rhialto <rhialto@falu.nl>
To: gnats-bugs@netbsd.org
Cc: xsrc-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	Rhialto <rhialto@falu.nl>
Subject: Re: xsrc/58318: Slow/incremental updating of Firefox menu entries
Date: Fri, 9 Aug 2024 22:38:27 +0200

 I updated my test box to -current as of yesterday, 10.99.11.
 This includes major updates to X from the recent weeks.

 With this version, the scenario doesn't reproduce the problem.
 That makes the issue rather moot, unless somebody wants to somehow find
 out which change made the difference.

>Unformatted:
 	<Please check that the above is correct for the bug being reported,>
 	<and append source date of snapshot, if applicable (one line).>

Home	PR Database Search