Date: Mon, 07 Oct 2019 23:47:30 +0200 From: Jan Beich <jbeich@FreeBSD.org> To: John Kennedy <warlock@phouka.net> Cc: freebsd-x11@freebsd.org Subject: Re: sway-1.2_1 crashes Message-ID: <wodg-9qj1-wny@FreeBSD.org> In-Reply-To: <20191007165337.GA85696@phouka1.phouka.net> (John Kennedy's message of "Mon, 7 Oct 2019 09:53:37 -0700") References: <20191007165337.GA85696@phouka1.phouka.net>
next in thread | previous in thread | raw e-mail | index | archive | help
John Kennedy <warlock@phouka.net> writes: > I've finally made some progress using wayland (vs X, via sway) and I'm seeing > some crashes. I'm compiling packages myself, so should have the latest. A > sampling of port versions based on what I typically see people ask about: > > sway-1.2_1 > wayland-1.16.0_1 > xwayland-1.19.1_11,1 > xinput-1.6.3 > mesa-dri-18.3.2_7 (should be compiled with llvm80-8.0.1_3) > mesa-libs-18.3.2_2 (should be compiled with llvm80-8.0.1_3) > drm-kmod-g20190710 -> drm-fbsd12.0-kmod-4.16.g20190814 Can you show the version of wlroots package? It's important to rebuild sway after every wlroots update. According to semantic versioning when major version is 0 (zero) "anything MAY change at any time" i.e., ABI may not be backward-compatible even between patch-level releases. > 2019-10-07 09:00:06 - [backend/drm/atomic.c:38] Atomic test failed: Invalid argument Probably benign. I also see this on Intel Skylake GT2 with drm-devel-kmod. > 2019-10-07 09:08:18 - [sway/desktop/transaction.c:464] Unable > to create transaction timer (some imperfect frames might be rendered): > Resource temporarily unavailable Does it disappear if you start as "sway -D txn-wait" or "sway -D noatomic"? > When it fails, it drops back to text mode. It seems to have a combination of > "load: 0.16 is not a controlling termal" (load # seems to vary) and what I > guess is some binary junk written to stdout. They keyboard ends up very > wedged (can't even gets caps-lock to toggle lights, mouse doesn't move the > pointer). Powering off via button gest a graceful shutdown and the output > that I captured, above. Try forcing VT switch via timeout or remotely before starting Sway to restore console to usable state e.g., # Can be run from direct X11 session (xorg-server) $ (sleep 60 && vidcontrol -s 1 </dev/ttyv0) & $ (sleep 90 && pkill sway) & $ env -u DISPLAY sway -d >/tmp/sway.log 2>&1 & Debugging further may require /tmp/sway.log and ~/.sway/config (if exists).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wodg-9qj1-wny>