Re: FYI: new X server in -current, among other X things
On Mon, 2022-07-18 at 21:23 -0400, David H. Gutteridge wrote: > On Mon, 2022-07-18 at 07:17 +1000, matthew green wrote: > > > can you post the whole Xorg.0.log somewhere? most of > > > my i915 systems have become non-functional the last few > > > years, but i have one system to test. > > > > unfortunately, my system (kaby lake, GT 630) seems to work > > fine with xorg-server 21.1.4 for me. > > This seems isolated to the modesetting driver. If I use intel instead, > then there are no issues. I've opened PR xsrc/56934 to track this. With mrg@'s commit to fix this[1], I can now start an X session without issue with the modesetting driver, and things generally work. I do see what seems like a separate, much more minor regression where rendering is incomplete (this doesn't occur with the intel driver, only modesetting), e.g., the mouse pointer gets garbled when I move it between windows. No idea where the trouble would be here. Anyway, thanks to rjs@ and mrg@ for fixing this! Regards, Dave 1. http://mail-index.netbsd.org/source-changes/2022/07/21/msg139935.html
Re: FYI: new X server in -current, among other X things
On Sun, 2022-07-17 at 00:28 -0400, David H. Gutteridge wrote: > Separately, libX11 added a feature called "thread safety constructor" > which we have enabled. It can cause hangs with X11 clients that aren't > coded safely. This did include xfce4-settings from Xfce until the > version I pushed to pkgsrc a couple of days ago (4.16.3). I believe > LXDE is also affected, but haven't had time to deal with it yet. Not > sure about any other DEs or X clients. (I'm not able to test at the > moment, of course.) LXDE has a basically identical code block (copied from Xfce, even the "xfce" function names are retained) to the one that was causing deadlocks when Xfce starts, though it's used for other purposes. I was not able to reproduce any hangs with that LXDE component, though. I'm not aware of anything else adversely affected by the libX11 change, but I guess we'll see. Regards, Dave
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2022.07.22.21.51.08 mrg src/external/gpl3/gcc/lib/libstdc++-v3/Makefile,v 1.53 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.07.html#2022.07.22.21.51.08
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2022.07.22.21.28.32.
An extract from the build.sh output follows:
=> @_makedirtarget() { dir="$1"; shift; target="$1"; shift; case
"${dir}" in /*)this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib" ;; *) this="lib/${dir}/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /tmp/build/2022.07.22.21.28.32-i386/tools/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget . dependall-libpam
dependall-libukfs
${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/install-/}
=> @_makedirtarget() { dir="$1"; shift; target="$1"; shift; case
"${dir}" in /*)this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib" ;; *) this="lib/${dir}/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /tmp/build/2022.07.22.21.28.32-i386/tools/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget . install-libpam
install-libukfs
${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/dependall-/}
=> @_makedirtarget() { dir="$1"; shift; target="$1"; shift; case
"${dir}" in /*)this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib" ;; *) this="lib/${dir}/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /tmp/build/2022.07.22.21.28.32-i386/tools/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget .
dependall-../external/bsd/pam-u2f/lib dependall-libp2k
dependall-../sys/rump/dev/lib dependall-../sys/rump/fs/lib
dependall-../sys/rump/kern/lib dependall-../sys/rump/net/lib dependall-lua
${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/install-/}
=> @_makedirtarget() { dir="$1"; shift; target="$1"; shift; case
"${dir}" in /*)this="${dir}/"; real="${dir}" ;; .) this="lib/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib" ;; *) this="lib/${dir}/";
real="/tmp/build/2022.07.22.21.28.32-i386/src/lib/${dir}" ;; esac;
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd
"${real}" && /tmp/build/2022.07.22.21.28.32-i386/tools/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget .
install-../external/bsd/pam-u2f/lib install-libp2k install-../sys/rump/dev/lib
install-../sys/rump/fs/lib install-../sys/rump/kern/lib
install-../sys/rump/net/lib install-lua
*** [build_install] Error code 1
nbmake[4]: stopped in /tmp/build/2022.07.22.21.28.32-i386/src/lib
1 error
nbmake[4]: stopped in /tmp/build/2022.07.22.21.28.32-i386/src/lib
nbmake[3]: stopped in /tmp/build/2022.07.22.21.28.32-i386/src
nbmake[2]: stopped in /tmp/build/2022.07.22.21.28.32-i386/src
nbmake[1]: stopped in /tmp/build/2022.07.22.21.28.32-i386/src
nbmake: stopped in /tmp/build/2022.07.22.21.28.32-i386/src
ERROR: Failed to make release
Between the last successful build and the failed build, a total of 379
revisions were committed, by the following developer:
mrg
The first of these commits was made on CVS date 2022.07.22.21.10.26,
and the last on 2022.07.22.21.28.32.
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2022.07.html#2022.07.22.21.28.32
Re: i915 observations (UXA attempt)
Hi Robert NetBSD/amd64 -current ~2 days ago Frank On 07/22/22 11:40, Robert Swindells wrote: Frank Kardel wrote: Sadly no luck here. I blindly used X -configure, removed references to the NVIDIA card, set Option "AccelMethod" "UXA" and started kdm. When startingI was greeted with: [89.357] (II) IGLX: Loaded and initialized swrast [89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [89.357] (II) Initializing extension XFree86-VidModeExtension [89.358] (II) Initializing extension XFree86-DGA [89.358] (II) Initializing extension XFree86-DRI [89.358] (II) Initializing extension DRI2 [89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=8388608, must be greater than 8294400, but less than 4194304 [89.361] (EE) and in my simple world is it hard to provide a solution for 8294400 < X < 4194304. The 4194304 number is derived from the AGP aperture size. Is this on NetBSD/amd64 or NetBSD/i386?
Re: i915 observations (UXA attempt)
Frank Kardel wrote: >Sadly no luck here. I blindly used X -configure, removed references to >the NVIDIA card, > >set Option "AccelMethod" "UXA" and started kdm. > >When startingI was greeted with: > >[89.357] (II) IGLX: Loaded and initialized swrast >[89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >[89.357] (II) Initializing extension XFree86-VidModeExtension >[89.358] (II) Initializing extension XFree86-DGA >[89.358] (II) Initializing extension XFree86-DRI >[89.358] (II) Initializing extension DRI2 >[89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer >object does not match constraints: size=8388608, must be greater than >8294400, but less than 4194304 >[89.361] (EE) > >and in my simple world is it hard to provide a solution for 8294400 < X >< 4194304. The 4194304 number is derived from the AGP aperture size. Is this on NetBSD/amd64 or NetBSD/i386?
Re: i915 observations (UXA attempt)
Hi John ! Sadly no luck here. I blindly used X -configure, removed references to the NVIDIA card, set Option "AccelMethod" "UXA" and started kdm. When startingI was greeted with: [89.357] (II) IGLX: Loaded and initialized swrast [89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [89.357] (II) Initializing extension XFree86-VidModeExtension [89.358] (II) Initializing extension XFree86-DGA [89.358] (II) Initializing extension XFree86-DRI [89.358] (II) Initializing extension DRI2 [89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=8388608, must be greater than 8294400, but less than 4194304 [89.361] (EE) and in my simple world is it hard to provide a solution for 8294400 < X < 4194304. Did I miss something in the configuration? Configuration, log and dmesg -v -x is attached. Frank UXA.tar.gz Description: application/gzip
