From owner-freebsd-x11@freebsd.org Sun Nov 10 05:35:32 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 468391AA8E6 for ; Sun, 10 Nov 2019 05:35:32 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 479jQX0K82z4Zr6 for ; Sun, 10 Nov 2019 05:35:32 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.nyi.freebsd.org (Postfix) id 092021AA8E5; Sun, 10 Nov 2019 05:35:32 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08E541AA8E4 for ; Sun, 10 Nov 2019 05:35:32 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 479jQW4VJWz4Zr4; Sun, 10 Nov 2019 05:35:31 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id E89913071D; Sun, 10 Nov 2019 05:35:30 +0000 (UTC) Date: Sun, 10 Nov 2019 05:35:29 +0000 From: Mark Linimon To: x11@FreeBSD.org Cc: linimon@FreeBSD.org Subject: [linimon@FreeBSD.org: svn commit: r517175 - head/devel/libclc] Message-ID: <20191110053529.GA22404@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 479jQW4VJWz4Zr4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-1.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.990,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; IP_SCORE(-0.26)[ip: (0.02), ipnet: 18.220.0.0/14(0.12), asn: 16509(-1.37), country: US(-0.05)]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 05:35:32 -0000 FYI mcl ----- Forwarded message from Mark Linimon ----- Date: Sun, 10 Nov 2019 05:33:45 +0000 (UTC) From: Mark Linimon To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r517175 - head/devel/libclc Author: linimon Date: Sun Nov 10 05:33:45 2019 New Revision: 517175 URL: https://svnweb.freebsd.org/changeset/ports/517175 Log: Mark BROKEN on powerpc64. This port has been failing to build since 20180919 and I have not yet been able to fix it. Approved by: portmgr (tier-2 blanket) Modified: head/devel/libclc/Makefile Modified: head/devel/libclc/Makefile ============================================================================== --- head/devel/libclc/Makefile Sun Nov 10 04:59:34 2019 (r517174) +++ head/devel/libclc/Makefile Sun Nov 10 05:33:45 2019 (r517175) @@ -14,6 +14,8 @@ LICENSE_NAME= LLVM Release License LICENSE_FILE= ${WRKSRC}/LICENSE.TXT LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept +BROKEN_powerpc64= fails to compile: /usr/local/llvm80/include/llvm-c/DataTypes.h:28:10: fatal error: 'cmath' file not found + BUILD_DEPENDS= llvm${LLVM_DEFAULT}>=4.0:devel/llvm${LLVM_DEFAULT} \ libedit>=0:devel/libedit ----- End forwarded message ----- From owner-freebsd-x11@freebsd.org Sun Nov 10 20:29:33 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C18591796A7 for ; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47B5G54mK4z4LXg for ; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A18A51796A5; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A01E71796A4 for ; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5G53Vjwz4LXf for ; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5BCC1473F for ; Sun, 10 Nov 2019 20:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAKTXaQ004723 for ; Sun, 10 Nov 2019 20:29:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAKTX22004722 for x11@FreeBSD.org; Sun, 10 Nov 2019 20:29:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 237650] graphics/wayland: update to 1.17 Date: Sun, 10 Nov 2019 20:29:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 20:29:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237650 --- Comment #11 from Jan Beich --- Hmm, I can't reproduce comment 7 and comment 8 anymore. No one else confirm= ed, so those could either be due to a -CURRENT bump, fixed by a dependency upda= te, intermittent (e.g., related to libepoll-shim), specific to old kms-drm vers= ions or a pilot error (optimizations, partial upgrade, etc). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Sun Nov 10 20:40:37 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C501B17A90C for ; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47B5Vs4mz6z4M15 for ; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A3F6617A90B; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A3C1817A909 for ; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5Vs3q0xz4M14 for ; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 67A764920 for ; Sun, 10 Nov 2019 20:40:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAKeb2h030972 for ; Sun, 10 Nov 2019 20:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAKebS8030971 for x11@FreeBSD.org; Sun, 10 Nov 2019 20:40:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241821] x11-servers/xwayland: hardware acceleration no longer works on -CURRENT Date: Sun, 10 Nov 2019 20:40:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: trasz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 20:40:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241821 --- Comment #6 from Edward Tomasz Napierala --- Wait, so it=E2=80=99s broken even when /dev/shm doesn=E2=80=99t actually ex= ist, due to being hidden with devfs ruleset? That=E2=80=99s... interesting. Do you know why sway=E2=80=99s mouse cursor doesn=E2=80=99t move, by any ch= ance? Is there some how to on how to setup it in FreeBSD? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Sun Nov 10 21:00:18 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 16CD917CDA2 for ; Sun, 10 Nov 2019 21:00:18 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47B5xY6mPgz4MrF for ; Sun, 10 Nov 2019 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id E82C817CD9E; Sun, 10 Nov 2019 21:00:17 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E7F4417CD9D for ; Sun, 10 Nov 2019 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5xY5y6Wz4MrC for ; Sun, 10 Nov 2019 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B0D064CC0 for ; Sun, 10 Nov 2019 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAL0Hoe079063 for ; Sun, 10 Nov 2019 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAL0HwN079061 for x11@FreeBSD.org; Sun, 10 Nov 2019 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201911102100.xAAL0HwN079061@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: x11@FreeBSD.org Subject: Problem reports for x11@FreeBSD.org that need special attention Date: Sun, 10 Nov 2019 21:00:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 21:00:18 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 220444 | x11-servers/xorg-server crashes on attempt to pla Open | 233652 | lang/beignet: Set DEPRECATED Open | 233740 | x11/pixman: LLD relocation errors on armv7 Open | 240153 | x11/libinput: Update to 1.14.1 Open | 223014 | graphics/mesa-dri: enable NEON and AltiVec Open | 240153 | x11/libinput: Update to 1.14.1 In Progress | 240964 | devel/libmtdev needs run_depends on evdev-proto New | 231694 | graphics/mesa-dri: uninstall error with portupgra 8 problems total for which you should take action. From owner-freebsd-x11@freebsd.org Sun Nov 10 21:37:50 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE9551A9638 for ; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47B6mt5fNSz4QG5 for ; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BF9491A9637; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BE52D1A9636 for ; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B6mt4bfkz4QG3 for ; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7E6EB54D2 for ; Sun, 10 Nov 2019 21:37:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAALbo91006307 for ; Sun, 10 Nov 2019 21:37:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAALbo2u006306 for x11@FreeBSD.org; Sun, 10 Nov 2019 21:37:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241821] x11-servers/xwayland: hardware acceleration no longer works on -CURRENT Date: Sun, 10 Nov 2019 21:37:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 21:37:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241821 --- Comment #7 from Jan Beich --- (In reply to Edward Tomasz Napierala from comment #6) > Do you know why sway=E2=80=99s mouse cursor doesn=E2=80=99t move, by any = chance? Do you see POINTER_MOTION events when running "libinput debug-events" and moving mouse before starting Sway? If not check /dev/input/* permissions th= en restart moused(8) or set kern.evdev.rcpt_mask=3D12 to get non-multiplexed e= vents. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Sun Nov 10 22:09:27 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 79AE01AC9BE for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47B7TM2jYnz4SBH for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 5D00C1AC9BD; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CC5A1AC9BC for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B7TM1mH6z4SBG for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 20DD05A6A for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAM9Rcx081449 for ; Sun, 10 Nov 2019 22:09:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAM9R90081446 for x11@FreeBSD.org; Sun, 10 Nov 2019 22:09:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: maintainer-feedback requested: [Bug 241867] x11/libinput: document common quirks Date: Sun, 10 Nov 2019 22:09:26 +0000 X-Bugzilla-Type: request X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? Message-ID: In-Reply-To: References: X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 22:09:27 -0000 Bugzilla Automation has asked freebsd-x11 mailing li= st for maintainer-feedback: Bug 241867: x11/libinput: document common quirks https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241867 --- Description --- libinput is a common entry point for running Wayland- and some KMS-based compositors. As FreeBSD defaults are not adjusted for the average user how = to get started is confusing. For one, running x11-wm/sway doesn't require extra steps compared to any ot= her Wayland compositor. From owner-freebsd-x11@freebsd.org Sun Nov 10 22:09:27 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BD4C41AC9C3 for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47B7TM4Vwkz4SBK for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 9AA481AC9C1; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A6911AC9C0 for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B7TM3gK1z4SBJ for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 616435A6B for ; Sun, 10 Nov 2019 22:09:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAM9ROA081459 for ; Sun, 10 Nov 2019 22:09:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAM9R28081458 for x11@FreeBSD.org; Sun, 10 Nov 2019 22:09:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241867] x11/libinput: document common quirks Date: Sun, 10 Nov 2019 22:09:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 22:09:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241867 Bug ID: 241867 Summary: x11/libinput: document common quirks Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Keywords: needs-qa Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: x11@FreeBSD.org Reporter: jbeich@FreeBSD.org Flags: maintainer-feedback?(x11@FreeBSD.org) Assignee: x11@FreeBSD.org Created attachment 209044 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D209044&action= =3Dedit v0 (non-verbose) libinput is a common entry point for running Wayland- and some KMS-based compositors. As FreeBSD defaults are not adjusted for the average user how = to get started is confusing. For one, running x11-wm/sway doesn't require extra steps compared to any ot= her Wayland compositor. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Sun Nov 10 22:40:32 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5EC721AF97B for ; Sun, 10 Nov 2019 22:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47B89D1vh3z4TYy for ; Sun, 10 Nov 2019 22:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3FA581AF97A; Sun, 10 Nov 2019 22:40:32 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F6921AF979 for ; Sun, 10 Nov 2019 22:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47B89D0w04z4TYx for ; Sun, 10 Nov 2019 22:40:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F2F8E5FC5 for ; Sun, 10 Nov 2019 22:40:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAAMeVWA077660 for ; Sun, 10 Nov 2019 22:40:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAAMeVhH077659 for x11@FreeBSD.org; Sun, 10 Nov 2019 22:40:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241867] x11/libinput: document common quirks Date: Sun, 10 Nov 2019 22:40:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 22:40:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241867 --- Comment #1 from Jan Beich --- Comment on attachment 209044 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D209044 v0 (non-verbose) > - For arrow keys to work export XKB_DEFAULT_RULES=3Devdev via environ(7) "setxkbmap -rules evdev" in xf86-input-libinput case. Compositor-specific w= ay to do the same would be "input * xkb_rules evdev" in ~/.sway/config or Opti= on "XkbRules" "evdev" in xorg.conf(5). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Mon Nov 11 09:35:45 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD8471B0961; Mon, 11 Nov 2019 09:35:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BQjD6r0Jz3yN4; Mon, 11 Nov 2019 09:35:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4F1F426025D; Mon, 11 Nov 2019 10:35:36 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu To: sgk@troutmask.apl.washington.edu, Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> Date: Mon, 11 Nov 2019 10:34:23 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191108220935.GA856@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47BQjD6r0Jz3yN4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.15)[ip: (-9.33), ipnet: 88.99.0.0/16(-4.73), asn: 24940(-1.66), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 09:35:45 -0000 Hi, Can you open the radeonkms.ko in gdb83 from ports and type: l *(radeon_gem_busy_ioctl+0x30) --HPS From owner-freebsd-x11@freebsd.org Mon Nov 11 10:20:50 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 27F561B1696; Mon, 11 Nov 2019 10:20:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BRjF46gvz41Bm; Mon, 11 Nov 2019 10:20:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E7D2C260246; Mon, 11 Nov 2019 11:20:47 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu From: Hans Petter Selasky To: sgk@troutmask.apl.washington.edu, Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> Message-ID: Date: Mon, 11 Nov 2019 11:19:27 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> Content-Type: multipart/mixed; boundary="------------9550642D4F1527555A0B45D9" Content-Language: en-US X-Rspamd-Queue-Id: 47BRjF46gvz41Bm X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; FROM_HAS_DN(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.15)[ip: (-9.33), ipnet: 88.99.0.0/16(-4.73), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 10:20:50 -0000 This is a multi-part message in MIME format. --------------9550642D4F1527555A0B45D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2019-11-11 10:34, Hans Petter Selasky wrote: > Hi, > > Can you open the radeonkms.ko in gdb83 from ports and type: > > l *(radeon_gem_busy_ioctl+0x30) > Hi, I suspect there is a memory race in the seqlock framework. Can you try the attached patch and re-build? Is this issue easily reproducible? --HPS --------------9550642D4F1527555A0B45D9 Content-Type: text/x-patch; charset=UTF-8; name="seqlock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="seqlock.diff" diff --git a/linuxkpi/gplv2/include/linux/reservation.h b/linuxkpi/gplv2/include/linux/reservation.h index b975f792c..0ce922a0e 100644 --- a/linuxkpi/gplv2/include/linux/reservation.h +++ b/linuxkpi/gplv2/include/linux/reservation.h @@ -94,7 +94,7 @@ reservation_object_init(struct reservation_object *obj) { ww_mutex_init(&obj->lock, &reservation_ww_class); - __seqcount_init(&obj->seq, reservation_seqcount_string, &reservation_seqcount_class); + seqcount_init(&obj->seq); RCU_INIT_POINTER(obj->fence, NULL); RCU_INIT_POINTER(obj->fence_excl, NULL); obj->staged = NULL; diff --git a/linuxkpi/gplv2/include/linux/seqlock.h b/linuxkpi/gplv2/include/linux/seqlock.h index e86351810..940bd8e90 100644 --- a/linuxkpi/gplv2/include/linux/seqlock.h +++ b/linuxkpi/gplv2/include/linux/seqlock.h @@ -1,410 +1,149 @@ #ifndef __LINUX_SEQLOCK_H -#define __LINUX_SEQLOCK_H -/* - * Reader/writer consistent mechanism without starving writers. This type of - * lock for data where the reader wants a consistent set of information - * and is willing to retry if the information changes. There are two types - * of readers: - * 1. Sequence readers which never block a writer but they may have to retry - * if a writer is in progress by detecting change in sequence number. - * Writers do not wait for a sequence reader. - * 2. Locking readers which will wait if a writer or another locking reader - * is in progress. A locking reader in progress will also block a writer - * from going forward. Unlike the regular rwlock, the read lock here is - * exclusive so that only one locking reader can get it. - * - * This is not as cache friendly as brlock. Also, this may not work well - * for data that contains pointers, because any writer could - * invalidate a pointer that a reader was following. - * - * Expected non-blocking reader usage: - * do { - * seq = read_seqbegin(&foo); - * ... - * } while (read_seqretry(&foo, seq)); - * - * - * On non-SMP the spin locks disappear but the writer still needs - * to increment the sequence variables because an interrupt routine could - * change the state of the data. - * - * Based on x86_64 vsyscall gettimeofday - * by Keith Owens and Andrea Arcangeli - */ +#define __LINUX_SEQLOCK_H #include #include -#include #include #include +#include #include - -/* - * Version using sequence counter only. - * This can be used when code has its own mutex protecting the - * updating starting before the write_seqcountbeqin() and ending - * after the write_seqcount_end(). - */ typedef struct seqcount { - unsigned sequence; -#ifdef CONFIG_DEBUG_LOCK_ALLOC - struct lockdep_map dep_map; -#endif + volatile unsigned sequence; } seqcount_t; - -#define lockdep_init_map(a, b, c, d) - -static inline void __seqcount_init(seqcount_t *s, const char *name, - struct lock_class_key *key) +static inline void +seqcount_init(seqcount_t *s) { - /* - * Make sure we are not reinitializing a held lock: - */ - lockdep_init_map(&s->dep_map, name, key, 0); s->sequence = 0; } -#ifdef CONFIG_DEBUG_LOCK_ALLOC -# define SEQCOUNT_DEP_MAP_INIT(lockname) \ - .dep_map = { .name = #lockname } \ - -# define seqcount_init(s) \ - do { \ - static struct lock_class_key __key; \ - __seqcount_init((s), #s, &__key); \ - } while (0) +#define __seqcount_init(a,b,c) \ + seqcount_init(a) -static inline void seqcount_lockdep_reader_access(seqcount_t *s) -{ - seqcount_t *l = (seqcount_t *)s; - unsigned long flags; - - local_irq_save(flags); - seqcount_acquire_read(&l->dep_map, 0, 0, _RET_IP_); - seqcount_release(&l->dep_map, 1, _RET_IP_); - local_irq_restore(flags); +#define SEQCNT_ZERO(lockname) { \ + .sequence = 0 \ } -#else -# define SEQCOUNT_DEP_MAP_INIT(lockname) -# define seqcount_init(s) __seqcount_init(s, NULL, NULL) -# define seqcount_lockdep_reader_access(x) -#endif - -#define SEQCNT_ZERO(lockname) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(lockname)} - - -/** - * __read_seqcount_begin - begin a seq-read critical section (without barrier) - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * __read_seqcount_begin is like read_seqcount_begin, but has no smp_rmb() - * barrier. Callers should ensure that smp_rmb() or equivalent ordering is - * provided before actually loading any of the variables that are to be - * protected in this critical section. - * - * Use carefully, only in critical code, and comment how the barrier is - * provided. - */ -static inline unsigned __read_seqcount_begin(seqcount_t *s) +static inline unsigned +__read_seqcount_begin(seqcount_t *s) { unsigned ret; repeat: - ret = READ_ONCE(s->sequence); + ret = s->sequence; if (unlikely(ret & 1)) { cpu_relax(); goto repeat; } - return ret; + return (ret); } -/** - * raw_read_seqcount - Read the raw seqcount - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_read_seqcount opens a read critical section of the given - * seqcount without any lockdep checking and without checking or - * masking the LSB. Calling code is responsible for handling that. - */ -static inline unsigned raw_read_seqcount(seqcount_t *s) +static inline unsigned +raw_read_seqcount(seqcount_t *s) { - unsigned ret = READ_ONCE(s->sequence); + unsigned ret = s->sequence; + smp_rmb(); - return ret; + return (ret); } -/** - * raw_read_seqcount_begin - start seq-read critical section w/o lockdep - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_read_seqcount_begin opens a read critical section of the given - * seqcount, but without any lockdep checking. Validity of the critical - * section is tested by checking read_seqcount_retry function. - */ -static inline unsigned raw_read_seqcount_begin(seqcount_t *s) +static inline unsigned +raw_read_seqcount_begin(seqcount_t *s) { unsigned ret = __read_seqcount_begin(s); + smp_rmb(); - return ret; -} - -/** - * read_seqcount_begin - begin a seq-read critical section - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * read_seqcount_begin opens a read critical section of the given seqcount. - * Validity of the critical section is tested by checking read_seqcount_retry - * function. - */ -static inline unsigned read_seqcount_begin(seqcount_t *s) -{ - seqcount_lockdep_reader_access(s); - return raw_read_seqcount_begin(s); -} - -/** - * raw_seqcount_begin - begin a seq-read critical section - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_seqcount_begin opens a read critical section of the given seqcount. - * Validity of the critical section is tested by checking read_seqcount_retry - * function. - * - * Unlike read_seqcount_begin(), this function will not wait for the count - * to stabilize. If a writer is active when we begin, we will fail the - * read_seqcount_retry() instead of stabilizing at the beginning of the - * critical section. - */ -static inline unsigned raw_seqcount_begin(seqcount_t *s) -{ - unsigned ret = READ_ONCE(s->sequence); - smp_rmb(); - return ret & ~1; -} - -/** - * __read_seqcount_retry - end a seq-read critical section (without barrier) - * @s: pointer to seqcount_t - * @start: count, from read_seqcount_begin - * Returns: 1 if retry is required, else 0 - * - * __read_seqcount_retry is like read_seqcount_retry, but has no smp_rmb() - * barrier. Callers should ensure that smp_rmb() or equivalent ordering is - * provided before actually loading any of the variables that are to be - * protected in this critical section. - * - * Use carefully, only in critical code, and comment how the barrier is - * provided. - */ -static inline int __read_seqcount_retry(seqcount_t *s, unsigned start) -{ - return unlikely(s->sequence != start); -} - -/** - * read_seqcount_retry - end a seq-read critical section - * @s: pointer to seqcount_t - * @start: count, from read_seqcount_begin - * Returns: 1 if retry is required, else 0 - * - * read_seqcount_retry closes a read critical section of the given seqcount. - * If the critical section was invalid, it must be ignored (and typically - * retried). - */ -static inline int read_seqcount_retry(seqcount_t *s, unsigned start) + return (ret); +} + +static inline +unsigned +read_seqcount_begin(seqcount_t *s) { + return (raw_read_seqcount_begin(s)); +} + +static inline unsigned +raw_seqcount_begin(seqcount_t *s) +{ + unsigned ret = s->sequence; + smp_rmb(); - return __read_seqcount_retry(s, start); + return (ret & ~1); } +static inline int +__read_seqcount_retry(seqcount_t *s, unsigned start) +{ + return (unlikely(s->sequence != start)); +} +static inline int +read_seqcount_retry(seqcount_t *s, unsigned start) +{ + smp_rmb(); + return (__read_seqcount_retry(s, start)); +} + +static inline void +raw_write_seqcount_begin(seqcount_t *s) +{ + atomic_add_int(&s->sequence, 1); + smp_wmb(); +} -static inline void raw_write_seqcount_begin(seqcount_t *s) +static inline void +raw_write_seqcount_end(seqcount_t *s) { - s->sequence++; smp_wmb(); + atomic_add_int(&s->sequence, 1); } -static inline void raw_write_seqcount_end(seqcount_t *s) +static inline void +raw_write_seqcount_barrier(seqcount_t *s) { + atomic_add_int(&s->sequence, 1); smp_wmb(); - s->sequence++; -} - -/** - * raw_write_seqcount_barrier - do a seq write barrier - * @s: pointer to seqcount_t - * - * This can be used to provide an ordering guarantee instead of the - * usual consistency guarantee. It is one wmb cheaper, because we can - * collapse the two back-to-back wmb()s. - * - * seqcount_t seq; - * bool X = true, Y = false; - * - * void read(void) - * { - * bool x, y; - * - * do { - * int s = read_seqcount_begin(&seq); - * - * x = X; y = Y; - * - * } while (read_seqcount_retry(&seq, s)); - * - * BUG_ON(!x && !y); - * } - * - * void write(void) - * { - * Y = true; - * - * raw_write_seqcount_barrier(seq); - * - * X = false; - * } - */ -static inline void raw_write_seqcount_barrier(seqcount_t *s) -{ - s->sequence++; + atomic_add_int(&s->sequence, 1); +} + +static inline int +raw_read_seqcount_latch(seqcount_t *s) +{ + return (s->sequence); +} + +static inline void +raw_write_seqcount_latch(seqcount_t *s) +{ smp_wmb(); - s->sequence++; -} - -static inline int raw_read_seqcount_latch(seqcount_t *s) -{ - return lockless_dereference(s->sequence); -} - -/** - * raw_write_seqcount_latch - redirect readers to even/odd copy - * @s: pointer to seqcount_t - * - * The latch technique is a multiversion concurrency control method that allows - * queries during non-atomic modifications. If you can guarantee queries never - * interrupt the modification -- e.g. the concurrency is strictly between CPUs - * -- you most likely do not need this. - * - * Where the traditional RCU/lockless data structures rely on atomic - * modifications to ensure queries observe either the old or the new state the - * latch allows the same for non-atomic updates. The trade-off is doubling the - * cost of storage; we have to maintain two copies of the entire data - * structure. - * - * Very simply put: we first modify one copy and then the other. This ensures - * there is always one copy in a stable state, ready to give us an answer. - * - * The basic form is a data structure like: - * - * struct latch_struct { - * seqcount_t seq; - * struct data_struct data[2]; - * }; - * - * Where a modification, which is assumed to be externally serialized, does the - * following: - * - * void latch_modify(struct latch_struct *latch, ...) - * { - * smp_wmb(); <- Ensure that the last data[1] update is visible - * latch->seq++; - * smp_wmb(); <- Ensure that the seqcount update is visible - * - * modify(latch->data[0], ...); - * - * smp_wmb(); <- Ensure that the data[0] update is visible - * latch->seq++; - * smp_wmb(); <- Ensure that the seqcount update is visible - * - * modify(latch->data[1], ...); - * } - * - * The query will have a form like: - * - * struct entry *latch_query(struct latch_struct *latch, ...) - * { - * struct entry *entry; - * unsigned seq, idx; - * - * do { - * seq = lockless_dereference(latch->seq); - * - * idx = seq & 0x01; - * entry = data_query(latch->data[idx], ...); - * - * smp_rmb(); - * } while (seq != latch->seq); - * - * return entry; - * } - * - * So during the modification, queries are first redirected to data[1]. Then we - * modify data[0]. When that is complete, we redirect queries back to data[0] - * and we can modify data[1]. - * - * NOTE: The non-requirement for atomic modifications does _NOT_ include - * the publishing of new entries in the case where data is a dynamic - * data structure. - * - * An iteration might start in data[0] and get suspended long enough - * to miss an entire modification sequence, once it resumes it might - * observe the new entry. - * - * NOTE: When data is a dynamic data structure; one should use regular RCU - * patterns to manage the lifetimes of the objects within. - */ -static inline void raw_write_seqcount_latch(seqcount_t *s) -{ - smp_wmb(); /* prior stores before incrementing "sequence" */ - s->sequence++; - smp_wmb(); /* increment "sequence" before following stores */ -} - -/* - * Sequence counter only version assumes that callers are using their - * own mutexing. - */ -static inline void write_seqcount_begin_nested(seqcount_t *s, int subclass) + atomic_add_int(&s->sequence, 1); +} + +static inline void +write_seqcount_begin_nested(seqcount_t *s, int subclass) { raw_write_seqcount_begin(s); -#ifdef CONFIG_DEBUG_LOCK_ALLOC - seqcount_acquire(&s->dep_map, subclass, 0, _RET_IP_); -#endif } -static inline void write_seqcount_begin(seqcount_t *s) +static inline void +write_seqcount_begin(seqcount_t *s) { write_seqcount_begin_nested(s, 0); } -static inline void write_seqcount_end(seqcount_t *s) +static inline void +write_seqcount_end(seqcount_t *s) { -#ifdef CONFIG_DEBUG_LOCK_ALLOC - seqcount_release(&s->dep_map, 1, _RET_IP_); -#endif raw_write_seqcount_end(s); } -/** - * write_seqcount_invalidate - invalidate in-progress read-side seq operations - * @s: pointer to seqcount_t - * - * After write_seqcount_invalidate, no read-side seq operations will complete - * successfully and see data older than this. - */ -static inline void write_seqcount_invalidate(seqcount_t *s) +static inline void +write_seqcount_invalidate(seqcount_t *s) { smp_wmb(); - s->sequence+=2; + atomic_add_int(&s->sequence, 2); } typedef struct { @@ -412,89 +151,87 @@ typedef struct { spinlock_t lock; } seqlock_t; -/* - * These macros triggered gcc-3.x compile-time problems. We think these are - * OK now. Be cautious. - */ -#define __SEQLOCK_UNLOCKED(lockname) \ +#define __SEQLOCK_UNLOCKED(lockname) \ { \ .seqcount = SEQCNT_ZERO(lockname), \ .lock = __SPIN_LOCK_UNLOCKED(lockname) \ } -#define seqlock_init(x) \ +#define seqlock_init(x) \ do { \ seqcount_init(&(x)->seqcount); \ spin_lock_init(&(x)->lock); \ } while (0) -#define DEFINE_SEQLOCK(x) \ - seqlock_t x = __SEQLOCK_UNLOCKED(x) +#define DEFINE_SEQLOCK(x) \ + seqlock_t x = __SEQLOCK_UNLOCKED(x) -/* - * Read side functions for starting and finalizing a read side section. - */ -static inline unsigned read_seqbegin(seqlock_t *sl) + +static inline unsigned +read_seqbegin(seqlock_t *sl) { - return read_seqcount_begin(&sl->seqcount); + return (read_seqcount_begin(&sl->seqcount)); } -static inline unsigned read_seqretry(seqlock_t *sl, unsigned start) +static inline unsigned +read_seqretry(seqlock_t *sl, unsigned start) { - return read_seqcount_retry(&sl->seqcount, start); + return (read_seqcount_retry(&sl->seqcount, start)); } -/* - * Lock out other writers and update the count. - * Acts like a normal spin_lock/unlock. - * Don't need preempt_disable() because that is in the spin_lock already. - */ -static inline void write_seqlock(seqlock_t *sl) +static inline void +write_seqlock(seqlock_t *sl) { spin_lock(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock(seqlock_t *sl) +static inline void +write_sequnlock(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock(&sl->lock); } -static inline void write_seqlock_bh(seqlock_t *sl) +static inline void +write_seqlock_bh(seqlock_t *sl) { spin_lock_bh(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock_bh(seqlock_t *sl) +static inline void +write_sequnlock_bh(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock_bh(&sl->lock); } -static inline void write_seqlock_irq(seqlock_t *sl) +static inline void +write_seqlock_irq(seqlock_t *sl) { spin_lock_irq(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock_irq(seqlock_t *sl) +static inline void +write_sequnlock_irq(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock_irq(&sl->lock); } -static inline unsigned long __write_seqlock_irqsave(seqlock_t *sl) +static inline unsigned long +__write_seqlock_irqsave(seqlock_t *sl) { unsigned long flags; spin_lock_irqsave(&sl->lock, flags); write_seqcount_begin(&sl->seqcount); - return flags; + return (flags); } -#define write_seqlock_irqsave(lock, flags) \ +#define write_seqlock_irqsave(lock, flags) \ do { flags = __write_seqlock_irqsave(lock); } while (0) static inline void @@ -504,79 +241,74 @@ write_sequnlock_irqrestore(seqlock_t *sl, unsigned long flags) spin_unlock_irqrestore(&sl->lock, flags); } -/* - * A locking reader exclusively locks out other writers and locking readers, - * but doesn't update the sequence number. Acts like a normal spin_lock/unlock. - * Don't need preempt_disable() because that is in the spin_lock already. - */ -static inline void read_seqlock_excl(seqlock_t *sl) +static inline void +read_seqlock_excl(seqlock_t *sl) { spin_lock(&sl->lock); } -static inline void read_sequnlock_excl(seqlock_t *sl) +static inline void +read_sequnlock_excl(seqlock_t *sl) { spin_unlock(&sl->lock); } -/** - * read_seqbegin_or_lock - begin a sequence number check or locking block - * @lock: sequence lock - * @seq : sequence number to be checked - * - * First try it once optimistically without taking the lock. If that fails, - * take the lock. The sequence number is also used as a marker for deciding - * whether to be a reader (even) or writer (odd). - * N.B. seq must be initialized to an even number to begin with. - */ -static inline void read_seqbegin_or_lock(seqlock_t *lock, int *seq) +static inline void +read_seqbegin_or_lock(seqlock_t *lock, int *seq) { - if (!(*seq & 1)) /* Even */ + if (!(*seq & 1)) /* Even */ *seq = read_seqbegin(lock); - else /* Odd */ + else /* Odd */ read_seqlock_excl(lock); } -static inline int need_seqretry(seqlock_t *lock, int seq) +static inline int +need_seqretry(seqlock_t *lock, int seq) { - return !(seq & 1) && read_seqretry(lock, seq); + return (!(seq & 1) && read_seqretry(lock, seq)); } -static inline void done_seqretry(seqlock_t *lock, int seq) +static inline void +done_seqretry(seqlock_t *lock, int seq) { if (seq & 1) read_sequnlock_excl(lock); } -static inline void read_seqlock_excl_bh(seqlock_t *sl) +static inline void +read_seqlock_excl_bh(seqlock_t *sl) { spin_lock_bh(&sl->lock); } -static inline void read_sequnlock_excl_bh(seqlock_t *sl) +static inline void +read_sequnlock_excl_bh(seqlock_t *sl) { spin_unlock_bh(&sl->lock); } -static inline void read_seqlock_excl_irq(seqlock_t *sl) +static inline void +read_seqlock_excl_irq(seqlock_t *sl) { spin_lock_irq(&sl->lock); } -static inline void read_sequnlock_excl_irq(seqlock_t *sl) +static inline void +read_sequnlock_excl_irq(seqlock_t *sl) { spin_unlock_irq(&sl->lock); } -static inline unsigned long __read_seqlock_excl_irqsave(seqlock_t *sl) +static inline unsigned long +__read_seqlock_excl_irqsave(seqlock_t *sl) { unsigned long flags; spin_lock_irqsave(&sl->lock, flags); - return flags; + return (flags); } -#define read_seqlock_excl_irqsave(lock, flags) \ +#define read_seqlock_excl_irqsave(lock, flags) \ do { flags = __read_seqlock_excl_irqsave(lock); } while (0) static inline void @@ -590,12 +322,11 @@ read_seqbegin_or_lock_irqsave(seqlock_t *lock, int *seq) { unsigned long flags = 0; - if (!(*seq & 1)) /* Even */ + if (!(*seq & 1)) /* Even */ *seq = read_seqbegin(lock); - else /* Odd */ + else /* Odd */ read_seqlock_excl_irqsave(lock, flags); - - return flags; + return (flags); } static inline void @@ -604,4 +335,5 @@ done_seqretry_irqrestore(seqlock_t *lock, int seq, unsigned long flags) if (seq & 1) read_sequnlock_excl_irqrestore(lock, flags); } -#endif /* __LINUX_SEQLOCK_H */ + +#endif /* __LINUX_SEQLOCK_H */ --------------9550642D4F1527555A0B45D9-- From owner-freebsd-x11@freebsd.org Mon Nov 11 10:45:36 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 88DE91B1E36; Mon, 11 Nov 2019 10:45:36 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BSFq45p5z42PM; Mon, 11 Nov 2019 10:45:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0FD93260404; Mon, 11 Nov 2019 11:45:32 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu From: Hans Petter Selasky To: sgk@troutmask.apl.washington.edu, Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> Message-ID: <3e11232b-e2a6-9169-adb0-da0e94523b39@selasky.org> Date: Mon, 11 Nov 2019 11:44:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------548D5A39F27368510CB30DAE" Content-Language: en-US X-Rspamd-Queue-Id: 47BSFq45p5z42PM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.15)[ip: (-9.33), ipnet: 88.99.0.0/16(-4.73), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 10:45:36 -0000 This is a multi-part message in MIME format. --------------548D5A39F27368510CB30DAE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Seems like we can optimise away one more write memory barrier. If you are building from ports, simply: cd work/kms-drm* cat seqlock.diff | patch -p1 --HPS --------------548D5A39F27368510CB30DAE Content-Type: text/x-patch; charset=UTF-8; name="seqlock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="seqlock.diff" diff --git a/linuxkpi/gplv2/include/linux/reservation.h b/linuxkpi/gplv2/include/linux/reservation.h index b975f792c..0ce922a0e 100644 --- a/linuxkpi/gplv2/include/linux/reservation.h +++ b/linuxkpi/gplv2/include/linux/reservation.h @@ -94,7 +94,7 @@ reservation_object_init(struct reservation_object *obj) { ww_mutex_init(&obj->lock, &reservation_ww_class); - __seqcount_init(&obj->seq, reservation_seqcount_string, &reservation_seqcount_class); + seqcount_init(&obj->seq); RCU_INIT_POINTER(obj->fence, NULL); RCU_INIT_POINTER(obj->fence_excl, NULL); obj->staged = NULL; diff --git a/linuxkpi/gplv2/include/linux/seqlock.h b/linuxkpi/gplv2/include/linux/seqlock.h index e86351810..115ad5e68 100644 --- a/linuxkpi/gplv2/include/linux/seqlock.h +++ b/linuxkpi/gplv2/include/linux/seqlock.h @@ -1,410 +1,148 @@ #ifndef __LINUX_SEQLOCK_H -#define __LINUX_SEQLOCK_H -/* - * Reader/writer consistent mechanism without starving writers. This type of - * lock for data where the reader wants a consistent set of information - * and is willing to retry if the information changes. There are two types - * of readers: - * 1. Sequence readers which never block a writer but they may have to retry - * if a writer is in progress by detecting change in sequence number. - * Writers do not wait for a sequence reader. - * 2. Locking readers which will wait if a writer or another locking reader - * is in progress. A locking reader in progress will also block a writer - * from going forward. Unlike the regular rwlock, the read lock here is - * exclusive so that only one locking reader can get it. - * - * This is not as cache friendly as brlock. Also, this may not work well - * for data that contains pointers, because any writer could - * invalidate a pointer that a reader was following. - * - * Expected non-blocking reader usage: - * do { - * seq = read_seqbegin(&foo); - * ... - * } while (read_seqretry(&foo, seq)); - * - * - * On non-SMP the spin locks disappear but the writer still needs - * to increment the sequence variables because an interrupt routine could - * change the state of the data. - * - * Based on x86_64 vsyscall gettimeofday - * by Keith Owens and Andrea Arcangeli - */ +#define __LINUX_SEQLOCK_H #include #include -#include #include #include +#include #include - -/* - * Version using sequence counter only. - * This can be used when code has its own mutex protecting the - * updating starting before the write_seqcountbeqin() and ending - * after the write_seqcount_end(). - */ typedef struct seqcount { - unsigned sequence; -#ifdef CONFIG_DEBUG_LOCK_ALLOC - struct lockdep_map dep_map; -#endif + volatile unsigned sequence; } seqcount_t; - -#define lockdep_init_map(a, b, c, d) - -static inline void __seqcount_init(seqcount_t *s, const char *name, - struct lock_class_key *key) +static inline void +seqcount_init(seqcount_t *s) { - /* - * Make sure we are not reinitializing a held lock: - */ - lockdep_init_map(&s->dep_map, name, key, 0); s->sequence = 0; } -#ifdef CONFIG_DEBUG_LOCK_ALLOC -# define SEQCOUNT_DEP_MAP_INIT(lockname) \ - .dep_map = { .name = #lockname } \ - -# define seqcount_init(s) \ - do { \ - static struct lock_class_key __key; \ - __seqcount_init((s), #s, &__key); \ - } while (0) +#define __seqcount_init(a,b,c) \ + seqcount_init(a) -static inline void seqcount_lockdep_reader_access(seqcount_t *s) -{ - seqcount_t *l = (seqcount_t *)s; - unsigned long flags; - - local_irq_save(flags); - seqcount_acquire_read(&l->dep_map, 0, 0, _RET_IP_); - seqcount_release(&l->dep_map, 1, _RET_IP_); - local_irq_restore(flags); +#define SEQCNT_ZERO(lockname) { \ + .sequence = 0 \ } -#else -# define SEQCOUNT_DEP_MAP_INIT(lockname) -# define seqcount_init(s) __seqcount_init(s, NULL, NULL) -# define seqcount_lockdep_reader_access(x) -#endif - -#define SEQCNT_ZERO(lockname) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(lockname)} - - -/** - * __read_seqcount_begin - begin a seq-read critical section (without barrier) - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * __read_seqcount_begin is like read_seqcount_begin, but has no smp_rmb() - * barrier. Callers should ensure that smp_rmb() or equivalent ordering is - * provided before actually loading any of the variables that are to be - * protected in this critical section. - * - * Use carefully, only in critical code, and comment how the barrier is - * provided. - */ -static inline unsigned __read_seqcount_begin(seqcount_t *s) +static inline unsigned +__read_seqcount_begin(seqcount_t *s) { unsigned ret; repeat: - ret = READ_ONCE(s->sequence); + ret = s->sequence; if (unlikely(ret & 1)) { cpu_relax(); goto repeat; } - return ret; + return (ret); } -/** - * raw_read_seqcount - Read the raw seqcount - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_read_seqcount opens a read critical section of the given - * seqcount without any lockdep checking and without checking or - * masking the LSB. Calling code is responsible for handling that. - */ -static inline unsigned raw_read_seqcount(seqcount_t *s) +static inline unsigned +raw_read_seqcount(seqcount_t *s) { - unsigned ret = READ_ONCE(s->sequence); + unsigned ret = s->sequence; + smp_rmb(); - return ret; + return (ret); } -/** - * raw_read_seqcount_begin - start seq-read critical section w/o lockdep - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_read_seqcount_begin opens a read critical section of the given - * seqcount, but without any lockdep checking. Validity of the critical - * section is tested by checking read_seqcount_retry function. - */ -static inline unsigned raw_read_seqcount_begin(seqcount_t *s) +static inline unsigned +raw_read_seqcount_begin(seqcount_t *s) { unsigned ret = __read_seqcount_begin(s); + smp_rmb(); - return ret; -} - -/** - * read_seqcount_begin - begin a seq-read critical section - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * read_seqcount_begin opens a read critical section of the given seqcount. - * Validity of the critical section is tested by checking read_seqcount_retry - * function. - */ -static inline unsigned read_seqcount_begin(seqcount_t *s) -{ - seqcount_lockdep_reader_access(s); - return raw_read_seqcount_begin(s); -} - -/** - * raw_seqcount_begin - begin a seq-read critical section - * @s: pointer to seqcount_t - * Returns: count to be passed to read_seqcount_retry - * - * raw_seqcount_begin opens a read critical section of the given seqcount. - * Validity of the critical section is tested by checking read_seqcount_retry - * function. - * - * Unlike read_seqcount_begin(), this function will not wait for the count - * to stabilize. If a writer is active when we begin, we will fail the - * read_seqcount_retry() instead of stabilizing at the beginning of the - * critical section. - */ -static inline unsigned raw_seqcount_begin(seqcount_t *s) -{ - unsigned ret = READ_ONCE(s->sequence); - smp_rmb(); - return ret & ~1; -} - -/** - * __read_seqcount_retry - end a seq-read critical section (without barrier) - * @s: pointer to seqcount_t - * @start: count, from read_seqcount_begin - * Returns: 1 if retry is required, else 0 - * - * __read_seqcount_retry is like read_seqcount_retry, but has no smp_rmb() - * barrier. Callers should ensure that smp_rmb() or equivalent ordering is - * provided before actually loading any of the variables that are to be - * protected in this critical section. - * - * Use carefully, only in critical code, and comment how the barrier is - * provided. - */ -static inline int __read_seqcount_retry(seqcount_t *s, unsigned start) -{ - return unlikely(s->sequence != start); -} - -/** - * read_seqcount_retry - end a seq-read critical section - * @s: pointer to seqcount_t - * @start: count, from read_seqcount_begin - * Returns: 1 if retry is required, else 0 - * - * read_seqcount_retry closes a read critical section of the given seqcount. - * If the critical section was invalid, it must be ignored (and typically - * retried). - */ -static inline int read_seqcount_retry(seqcount_t *s, unsigned start) + return (ret); +} + +static inline +unsigned +read_seqcount_begin(seqcount_t *s) { + return (raw_read_seqcount_begin(s)); +} + +static inline unsigned +raw_seqcount_begin(seqcount_t *s) +{ + unsigned ret = s->sequence; + smp_rmb(); - return __read_seqcount_retry(s, start); + return (ret & ~1); } +static inline int +__read_seqcount_retry(seqcount_t *s, unsigned start) +{ + return (unlikely(s->sequence != start)); +} +static inline int +read_seqcount_retry(seqcount_t *s, unsigned start) +{ + smp_rmb(); + return (__read_seqcount_retry(s, start)); +} + +static inline void +raw_write_seqcount_begin(seqcount_t *s) +{ + atomic_add_int(&s->sequence, 1); +} -static inline void raw_write_seqcount_begin(seqcount_t *s) +static inline void +raw_write_seqcount_end(seqcount_t *s) { - s->sequence++; smp_wmb(); + atomic_add_int(&s->sequence, 1); } -static inline void raw_write_seqcount_end(seqcount_t *s) +static inline void +raw_write_seqcount_barrier(seqcount_t *s) { + atomic_add_int(&s->sequence, 1); smp_wmb(); - s->sequence++; -} - -/** - * raw_write_seqcount_barrier - do a seq write barrier - * @s: pointer to seqcount_t - * - * This can be used to provide an ordering guarantee instead of the - * usual consistency guarantee. It is one wmb cheaper, because we can - * collapse the two back-to-back wmb()s. - * - * seqcount_t seq; - * bool X = true, Y = false; - * - * void read(void) - * { - * bool x, y; - * - * do { - * int s = read_seqcount_begin(&seq); - * - * x = X; y = Y; - * - * } while (read_seqcount_retry(&seq, s)); - * - * BUG_ON(!x && !y); - * } - * - * void write(void) - * { - * Y = true; - * - * raw_write_seqcount_barrier(seq); - * - * X = false; - * } - */ -static inline void raw_write_seqcount_barrier(seqcount_t *s) -{ - s->sequence++; + atomic_add_int(&s->sequence, 1); +} + +static inline int +raw_read_seqcount_latch(seqcount_t *s) +{ + return (s->sequence); +} + +static inline void +raw_write_seqcount_latch(seqcount_t *s) +{ smp_wmb(); - s->sequence++; -} - -static inline int raw_read_seqcount_latch(seqcount_t *s) -{ - return lockless_dereference(s->sequence); -} - -/** - * raw_write_seqcount_latch - redirect readers to even/odd copy - * @s: pointer to seqcount_t - * - * The latch technique is a multiversion concurrency control method that allows - * queries during non-atomic modifications. If you can guarantee queries never - * interrupt the modification -- e.g. the concurrency is strictly between CPUs - * -- you most likely do not need this. - * - * Where the traditional RCU/lockless data structures rely on atomic - * modifications to ensure queries observe either the old or the new state the - * latch allows the same for non-atomic updates. The trade-off is doubling the - * cost of storage; we have to maintain two copies of the entire data - * structure. - * - * Very simply put: we first modify one copy and then the other. This ensures - * there is always one copy in a stable state, ready to give us an answer. - * - * The basic form is a data structure like: - * - * struct latch_struct { - * seqcount_t seq; - * struct data_struct data[2]; - * }; - * - * Where a modification, which is assumed to be externally serialized, does the - * following: - * - * void latch_modify(struct latch_struct *latch, ...) - * { - * smp_wmb(); <- Ensure that the last data[1] update is visible - * latch->seq++; - * smp_wmb(); <- Ensure that the seqcount update is visible - * - * modify(latch->data[0], ...); - * - * smp_wmb(); <- Ensure that the data[0] update is visible - * latch->seq++; - * smp_wmb(); <- Ensure that the seqcount update is visible - * - * modify(latch->data[1], ...); - * } - * - * The query will have a form like: - * - * struct entry *latch_query(struct latch_struct *latch, ...) - * { - * struct entry *entry; - * unsigned seq, idx; - * - * do { - * seq = lockless_dereference(latch->seq); - * - * idx = seq & 0x01; - * entry = data_query(latch->data[idx], ...); - * - * smp_rmb(); - * } while (seq != latch->seq); - * - * return entry; - * } - * - * So during the modification, queries are first redirected to data[1]. Then we - * modify data[0]. When that is complete, we redirect queries back to data[0] - * and we can modify data[1]. - * - * NOTE: The non-requirement for atomic modifications does _NOT_ include - * the publishing of new entries in the case where data is a dynamic - * data structure. - * - * An iteration might start in data[0] and get suspended long enough - * to miss an entire modification sequence, once it resumes it might - * observe the new entry. - * - * NOTE: When data is a dynamic data structure; one should use regular RCU - * patterns to manage the lifetimes of the objects within. - */ -static inline void raw_write_seqcount_latch(seqcount_t *s) -{ - smp_wmb(); /* prior stores before incrementing "sequence" */ - s->sequence++; - smp_wmb(); /* increment "sequence" before following stores */ -} - -/* - * Sequence counter only version assumes that callers are using their - * own mutexing. - */ -static inline void write_seqcount_begin_nested(seqcount_t *s, int subclass) + atomic_add_int(&s->sequence, 1); +} + +static inline void +write_seqcount_begin_nested(seqcount_t *s, int subclass) { raw_write_seqcount_begin(s); -#ifdef CONFIG_DEBUG_LOCK_ALLOC - seqcount_acquire(&s->dep_map, subclass, 0, _RET_IP_); -#endif } -static inline void write_seqcount_begin(seqcount_t *s) +static inline void +write_seqcount_begin(seqcount_t *s) { write_seqcount_begin_nested(s, 0); } -static inline void write_seqcount_end(seqcount_t *s) +static inline void +write_seqcount_end(seqcount_t *s) { -#ifdef CONFIG_DEBUG_LOCK_ALLOC - seqcount_release(&s->dep_map, 1, _RET_IP_); -#endif raw_write_seqcount_end(s); } -/** - * write_seqcount_invalidate - invalidate in-progress read-side seq operations - * @s: pointer to seqcount_t - * - * After write_seqcount_invalidate, no read-side seq operations will complete - * successfully and see data older than this. - */ -static inline void write_seqcount_invalidate(seqcount_t *s) +static inline void +write_seqcount_invalidate(seqcount_t *s) { smp_wmb(); - s->sequence+=2; + atomic_add_int(&s->sequence, 2); } typedef struct { @@ -412,89 +150,87 @@ typedef struct { spinlock_t lock; } seqlock_t; -/* - * These macros triggered gcc-3.x compile-time problems. We think these are - * OK now. Be cautious. - */ -#define __SEQLOCK_UNLOCKED(lockname) \ +#define __SEQLOCK_UNLOCKED(lockname) \ { \ .seqcount = SEQCNT_ZERO(lockname), \ .lock = __SPIN_LOCK_UNLOCKED(lockname) \ } -#define seqlock_init(x) \ +#define seqlock_init(x) \ do { \ seqcount_init(&(x)->seqcount); \ spin_lock_init(&(x)->lock); \ } while (0) -#define DEFINE_SEQLOCK(x) \ - seqlock_t x = __SEQLOCK_UNLOCKED(x) +#define DEFINE_SEQLOCK(x) \ + seqlock_t x = __SEQLOCK_UNLOCKED(x) + -/* - * Read side functions for starting and finalizing a read side section. - */ -static inline unsigned read_seqbegin(seqlock_t *sl) +static inline unsigned +read_seqbegin(seqlock_t *sl) { - return read_seqcount_begin(&sl->seqcount); + return (read_seqcount_begin(&sl->seqcount)); } -static inline unsigned read_seqretry(seqlock_t *sl, unsigned start) +static inline unsigned +read_seqretry(seqlock_t *sl, unsigned start) { - return read_seqcount_retry(&sl->seqcount, start); + return (read_seqcount_retry(&sl->seqcount, start)); } -/* - * Lock out other writers and update the count. - * Acts like a normal spin_lock/unlock. - * Don't need preempt_disable() because that is in the spin_lock already. - */ -static inline void write_seqlock(seqlock_t *sl) +static inline void +write_seqlock(seqlock_t *sl) { spin_lock(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock(seqlock_t *sl) +static inline void +write_sequnlock(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock(&sl->lock); } -static inline void write_seqlock_bh(seqlock_t *sl) +static inline void +write_seqlock_bh(seqlock_t *sl) { spin_lock_bh(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock_bh(seqlock_t *sl) +static inline void +write_sequnlock_bh(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock_bh(&sl->lock); } -static inline void write_seqlock_irq(seqlock_t *sl) +static inline void +write_seqlock_irq(seqlock_t *sl) { spin_lock_irq(&sl->lock); write_seqcount_begin(&sl->seqcount); } -static inline void write_sequnlock_irq(seqlock_t *sl) +static inline void +write_sequnlock_irq(seqlock_t *sl) { write_seqcount_end(&sl->seqcount); spin_unlock_irq(&sl->lock); } -static inline unsigned long __write_seqlock_irqsave(seqlock_t *sl) +static inline unsigned long +__write_seqlock_irqsave(seqlock_t *sl) { unsigned long flags; spin_lock_irqsave(&sl->lock, flags); write_seqcount_begin(&sl->seqcount); - return flags; + return (flags); } -#define write_seqlock_irqsave(lock, flags) \ +#define write_seqlock_irqsave(lock, flags) \ do { flags = __write_seqlock_irqsave(lock); } while (0) static inline void @@ -504,79 +240,74 @@ write_sequnlock_irqrestore(seqlock_t *sl, unsigned long flags) spin_unlock_irqrestore(&sl->lock, flags); } -/* - * A locking reader exclusively locks out other writers and locking readers, - * but doesn't update the sequence number. Acts like a normal spin_lock/unlock. - * Don't need preempt_disable() because that is in the spin_lock already. - */ -static inline void read_seqlock_excl(seqlock_t *sl) +static inline void +read_seqlock_excl(seqlock_t *sl) { spin_lock(&sl->lock); } -static inline void read_sequnlock_excl(seqlock_t *sl) +static inline void +read_sequnlock_excl(seqlock_t *sl) { spin_unlock(&sl->lock); } -/** - * read_seqbegin_or_lock - begin a sequence number check or locking block - * @lock: sequence lock - * @seq : sequence number to be checked - * - * First try it once optimistically without taking the lock. If that fails, - * take the lock. The sequence number is also used as a marker for deciding - * whether to be a reader (even) or writer (odd). - * N.B. seq must be initialized to an even number to begin with. - */ -static inline void read_seqbegin_or_lock(seqlock_t *lock, int *seq) +static inline void +read_seqbegin_or_lock(seqlock_t *lock, int *seq) { - if (!(*seq & 1)) /* Even */ + if (!(*seq & 1)) /* Even */ *seq = read_seqbegin(lock); - else /* Odd */ + else /* Odd */ read_seqlock_excl(lock); } -static inline int need_seqretry(seqlock_t *lock, int seq) +static inline int +need_seqretry(seqlock_t *lock, int seq) { - return !(seq & 1) && read_seqretry(lock, seq); + return (!(seq & 1) && read_seqretry(lock, seq)); } -static inline void done_seqretry(seqlock_t *lock, int seq) +static inline void +done_seqretry(seqlock_t *lock, int seq) { if (seq & 1) read_sequnlock_excl(lock); } -static inline void read_seqlock_excl_bh(seqlock_t *sl) +static inline void +read_seqlock_excl_bh(seqlock_t *sl) { spin_lock_bh(&sl->lock); } -static inline void read_sequnlock_excl_bh(seqlock_t *sl) +static inline void +read_sequnlock_excl_bh(seqlock_t *sl) { spin_unlock_bh(&sl->lock); } -static inline void read_seqlock_excl_irq(seqlock_t *sl) +static inline void +read_seqlock_excl_irq(seqlock_t *sl) { spin_lock_irq(&sl->lock); } -static inline void read_sequnlock_excl_irq(seqlock_t *sl) +static inline void +read_sequnlock_excl_irq(seqlock_t *sl) { spin_unlock_irq(&sl->lock); } -static inline unsigned long __read_seqlock_excl_irqsave(seqlock_t *sl) +static inline unsigned long +__read_seqlock_excl_irqsave(seqlock_t *sl) { unsigned long flags; spin_lock_irqsave(&sl->lock, flags); - return flags; + return (flags); } -#define read_seqlock_excl_irqsave(lock, flags) \ +#define read_seqlock_excl_irqsave(lock, flags) \ do { flags = __read_seqlock_excl_irqsave(lock); } while (0) static inline void @@ -590,12 +321,11 @@ read_seqbegin_or_lock_irqsave(seqlock_t *lock, int *seq) { unsigned long flags = 0; - if (!(*seq & 1)) /* Even */ + if (!(*seq & 1)) /* Even */ *seq = read_seqbegin(lock); - else /* Odd */ + else /* Odd */ read_seqlock_excl_irqsave(lock, flags); - - return flags; + return (flags); } static inline void @@ -604,4 +334,5 @@ done_seqretry_irqrestore(seqlock_t *lock, int seq, unsigned long flags) if (seq & 1) read_sequnlock_excl_irqrestore(lock, flags); } -#endif /* __LINUX_SEQLOCK_H */ + +#endif /* __LINUX_SEQLOCK_H */ --------------548D5A39F27368510CB30DAE-- From owner-freebsd-x11@freebsd.org Mon Nov 11 12:24:02 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36DD41B4574; Mon, 11 Nov 2019 12:24:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BVRP2wYKz46ps; Mon, 11 Nov 2019 12:24:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B84122602EF; Mon, 11 Nov 2019 13:23:52 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu From: Hans Petter Selasky To: sgk@troutmask.apl.washington.edu, Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <3e11232b-e2a6-9169-adb0-da0e94523b39@selasky.org> Message-ID: <64e980fa-aa9b-e656-92a1-110d9cbf9059@selasky.org> Date: Mon, 11 Nov 2019 13:22:09 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <3e11232b-e2a6-9169-adb0-da0e94523b39@selasky.org> Content-Type: multipart/mixed; boundary="------------6EF61D4E1FC5F777863650FE" Content-Language: en-US X-Rspamd-Queue-Id: 47BVRP2wYKz46ps X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.62)[ip: (-9.16), ipnet: 2a01:4f8::/29(-2.26), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 12:24:02 -0000 This is a multi-part message in MIME format. --------------6EF61D4E1FC5F777863650FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2019-11-11 11:44, Hans Petter Selasky wrote: > Seems like we can optimise away one more write memory barrier. > > If you are building from ports, simply: > > cd work/kms-drm* > cat seqlock.diff | patch -p1 > Hi, Here is one more debug patch you can try. See if you get that print added in the patch in dmesg. --HPS --------------6EF61D4E1FC5F777863650FE Content-Type: text/x-patch; charset=UTF-8; name="kdb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kdb.diff" diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c index a6e0a16ae..0697d70f4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c @@ -31,6 +31,8 @@ #include "amdgpu_vm.h" #include "amdgpu_amdkfd.h" +#include + /* Special VM and GART address alignment needed for VI pre-Fiji due to * a HW bug. */ @@ -236,6 +238,12 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo, *ef_count = 0; } + if (resv != NULL && + (struct thread *)SX_OWNER(resv->lock.base.sx.sx_lock) != curthread) { + printf("Called unlocked\n"); + kdb_backtrace(); + } + old = reservation_object_get_list(resv); if (!old) return 0; --------------6EF61D4E1FC5F777863650FE-- From owner-freebsd-x11@freebsd.org Mon Nov 11 12:29:05 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 513851B477B; Mon, 11 Nov 2019 12:29:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BVYD2jtqz473n; Mon, 11 Nov 2019 12:29:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id xABCSojx070757 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Nov 2019 14:28:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua xABCSojx070757 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id xABCSoQr070756; Mon, 11 Nov 2019 14:28:50 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Nov 2019 14:28:50 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: sgk@troutmask.apl.washington.edu, Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191111122850.GO2707@kib.kiev.ua> References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <3e11232b-e2a6-9169-adb0-da0e94523b39@selasky.org> <64e980fa-aa9b-e656-92a1-110d9cbf9059@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64e980fa-aa9b-e656-92a1-110d9cbf9059@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 47BVYD2jtqz473n X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-2.66), ipnet: 2001:470::/32(-4.62), asn: 6939(-3.49), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 12:29:05 -0000 On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote: > On 2019-11-11 11:44, Hans Petter Selasky wrote: > > Seems like we can optimise away one more write memory barrier. > > > > If you are building from ports, simply: > > > > cd work/kms-drm* > > cat seqlock.diff | patch -p1 > > > > Hi, > > Here is one more debug patch you can try. See if you get that print > added in the patch in dmesg. > > --HPS > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > index a6e0a16ae..0697d70f4 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > @@ -31,6 +31,8 @@ > #include "amdgpu_vm.h" > #include "amdgpu_amdkfd.h" > > +#include > + > /* Special VM and GART address alignment needed for VI pre-Fiji due to > * a HW bug. > */ > @@ -236,6 +238,12 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo, > *ef_count = 0; > } > > + if (resv != NULL && > + (struct thread *)SX_OWNER(resv->lock.base.sx.sx_lock) != curthread) { This is really should be spelled as sx_xlocked(). > + printf("Called unlocked\n"); > + kdb_backtrace(); > + } > + > old = reservation_object_get_list(resv); > if (!old) > return 0; > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-x11@freebsd.org Mon Nov 11 13:24:53 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 79AEE1B5813; Mon, 11 Nov 2019 13:24:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BWnc4yWFz49tH; Mon, 11 Nov 2019 13:24:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9EDB0260108; Mon, 11 Nov 2019 14:24:49 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu To: sgk@troutmask.apl.washington.edu, Mark Johnston Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <6596a17a-5ee7-196c-f141-6efda054bcbe@selasky.org> Date: Mon, 11 Nov 2019 14:22:55 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191108220935.GA856@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47BWnc4yWFz49tH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.15)[ip: (-9.33), ipnet: 88.99.0.0/16(-4.73), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 13:24:53 -0000 On 2019-11-08 23:09, Steve Kargl wrote: > Here's 'procstat -kk' for the stuck process with the long line wrapped. Can you run this command a couple of times and see if the backtrace changes? --HPS From owner-freebsd-x11@freebsd.org Mon Nov 11 16:09:38 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A4701B8B9C for ; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47BbRk2kz5z4L6r for ; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 5DF921B8B9B; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5DBBE1B8B9A for ; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47BbRk1sGDz4L6q for ; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2498819CBF for ; Mon, 11 Nov 2019 16:09:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xABG9c9A067415 for ; Mon, 11 Nov 2019 16:09:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xABG9coN067413 for x11@FreeBSD.org; Mon, 11 Nov 2019 16:09:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 236003] x11-drivers/xf86-video-intel: update to 2019-07-10 snapshot and refactor Date: Mon, 11 Nov 2019 16:09:37 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch, patch-ready X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: javashin1986@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 16:09:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236003 --- Comment #22 from JavaShin --- fetch -qo /tmp/intel-ddx-SNA-Fix.diff 'https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D208834' patch -Efsp1 -i /tmp/intel-ddx-SNA-Fix.diff -d /usr/ports cd /usr/ports/x11-drivers/xf86-video-intel ; make deinstall reinstall clean --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Mon Nov 11 19:23:41 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 17C0C1BC8AE for ; Mon, 11 Nov 2019 19:23:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47Bglc6tqFz4Ys0 for ; Mon, 11 Nov 2019 19:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EC6EE1BC8AC; Mon, 11 Nov 2019 19:23:40 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC3551BC8AB for ; Mon, 11 Nov 2019 19:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Bglc5pK5z4Yry for ; Mon, 11 Nov 2019 19:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 942121C158 for ; Mon, 11 Nov 2019 19:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xABJNe0v019966 for ; Mon, 11 Nov 2019 19:23:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xABJNel9019962 for x11@FreeBSD.org; Mon, 11 Nov 2019 19:23:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 236003] x11-drivers/xf86-video-intel: update to 2019-07-10 snapshot and refactor Date: Mon, 11 Nov 2019 19:23:40 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: patch, patch-ready X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: shuriku@shurik.kiev.ua X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 19:23:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236003 --- Comment #23 from Alexandr Krivulya --- There is a black screen with mouse cursor at center on my Thinkpad T470p wi= th SNA enabled. With UXA all works fine, but sddm is starting about one minute. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-x11@freebsd.org Mon Nov 11 21:07:46 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3848E1BEB5C for ; Mon, 11 Nov 2019 21:07:46 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Bk3j2sPcz4gKv for ; Mon, 11 Nov 2019 21:07:45 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from duke.nomadlogic.org (76-214-71-45.lightspeed.irvnca.sbcglobal.net [76.214.71.45]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id fc181d3f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 11 Nov 2019 21:07:38 +0000 (UTC) Subject: Re: drm-fbsd11.2-kmod on 12 To: freebsd-x11@freebsd.org References: <20191103231435.GH86455@over-yonder.net> <3231b40d-1041-10d2-f062-eda237e07a02@freebsd.org> <20191106230916.GI86455@over-yonder.net> <77bac16b-0438-b7ed-0c44-fadc230e55f8@freebsd.org> <20191107220050.GA3169@over-yonder.net> <87da494d-207e-269c-f608-c6266c274384@freebsd.org> <20191109205008.GD3169@over-yonder.net> From: Pete Wright Message-ID: <8e42e75a-e4d6-b049-bd02-0d980167fb09@nomadlogic.org> Date: Mon, 11 Nov 2019 13:07:38 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191109205008.GD3169@over-yonder.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 47Bk3j2sPcz4gKv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-4.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-x11@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[nomadlogic.org]; IP_SCORE(-2.63)[ip: (-9.26), ipnet: 174.136.96.0/20(-3.54), asn: 25795(-0.31), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 21:07:46 -0000 On 11/9/19 12:50 PM, Matthew D. Fuller wrote: > On Fri, Nov 08, 2019 at 09:46:43AM +0100 I heard the voice of > Niclas Zeising, and lo! it spake thus: >> I don't know if it is simple or not. The code is there, if you can >> get it running on 12.1 without breaking 11.3, then, by all means do >> it. > FWIW, just cherrypicking back 9e308e6a707bc29 (adding pcpu.h to one > file) from the 4.16-12.0 branch sufficed to get it building and > basically running. I also pulled back 324a27a734733 (DRM_SYSCTL_PRINT > locking) and 148d05832cc12 (enable MSI) since they seemed like good > things. Apart from a little trivial conflict resolution on the > latter, it all Just Happened. > > In a solid 5 minutes of running it and testing a little video playing > (on the system where 4.16 is stable aside from the videos), it hasn't > blown up yet. I'll see if something happens over the next few days. > > This is helpful information, if not done already can you please file a GitHub issue for this?  This will help us make sure the problem and solution you found don't get lost. Cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-x11@freebsd.org Tue Nov 12 03:24:00 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEEE51C6E50; Tue, 12 Nov 2019 03:24:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47BtPq48W7z42DS; Tue, 12 Nov 2019 03:23:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xAC3NpxK065877 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Nov 2019 19:23:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xAC3NpXr065876; Mon, 11 Nov 2019 19:23:51 -0800 (PST) (envelope-from sgk) Date: Mon, 11 Nov 2019 19:23:51 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191112032351.GA65855@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6596a17a-5ee7-196c-f141-6efda054bcbe@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6596a17a-5ee7-196c-f141-6efda054bcbe@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47BtPq48W7z42DS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.23 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.91)[-0.905,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 03:24:00 -0000 On Mon, Nov 11, 2019 at 02:22:55PM +0100, Hans Petter Selasky wrote: > On 2019-11-08 23:09, Steve Kargl wrote: > > Here's 'procstat -kk' for the stuck process with the long line wrapped. > > Can you run this command a couple of times and see if the backtrace changes? > > --HPS I was AFK for a few days. I'll try all your suggestions tomorrow. The two lock ups occurred while using chrome to watch/listen to youtube and using libreoffice to prepare a presentation. I'll see if I can reproduce the issue. -- Steve From owner-freebsd-x11@freebsd.org Tue Nov 12 14:27:50 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C67741AF1CE for ; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47C97p4wcbz4c77 for ; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A72031AF1CD; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6E2E1AF1CC for ; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47C97p3yRCz4c75 for ; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 66E2BFFB for ; Tue, 12 Nov 2019 14:27:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xACERoi8051121 for ; Tue, 12 Nov 2019 14:27:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xACERob0051120 for x11@FreeBSD.org; Tue, 12 Nov 2019 14:27:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241348] [PATCH] devel/evdev-proto: add joystick.h Date: Tue, 12 Nov 2019 14:27:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 14:27:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241348 --- Comment #5 from rozhuk.im@gmail.com --- Should I update patch to increment devel/libevdev and devel/py-evdev portrevision? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-x11@freebsd.org Tue Nov 12 17:31:40 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6E52A1B35C3; Tue, 12 Nov 2019 17:31:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CFCv1x14z3KNT; Tue, 12 Nov 2019 17:31:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xACHVaYt069366 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Nov 2019 09:31:36 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xACHVaEQ069365; Tue, 12 Nov 2019 09:31:36 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2019 09:31:36 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191112173136.GA69344@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47CFCv1x14z3KNT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.93)[-0.934,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 17:31:40 -0000 On Mon, Nov 11, 2019 at 10:34:23AM +0100, Hans Petter Selasky wrote: > Hi, > > Can you open the radeonkms.ko in gdb83 from ports and type: > > l *(radeon_gem_busy_ioctl+0x30) > % /boot/modules/radeonkms.ko (gdb) l *(radeon_gem_busy_ioctl+0x30) 0xa12b0 is in radeon_gem_busy_ioctl (/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453). 448 /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c: No such file or directory. (gdb) -- Steve From owner-freebsd-x11@freebsd.org Tue Nov 12 17:51:22 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E5BF41B3B6E; Tue, 12 Nov 2019 17:51:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47CFfd5wt9z3LNX; Tue, 12 Nov 2019 17:51:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4AD7E260246; Tue, 12 Nov 2019 18:51:12 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu To: sgk@troutmask.apl.washington.edu Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> Date: Tue, 12 Nov 2019 18:48:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191112173136.GA69344@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47CFfd5wt9z3LNX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.62)[ip: (-9.16), ipnet: 2a01:4f8::/29(-2.27), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 17:51:23 -0000 On 2019-11-12 18:31, Steve Kargl wrote: >> Can you open the radeonkms.ko in gdb83 from ports and type: >> >> l *(radeon_gem_busy_ioctl+0x30) >> > % /boot/modules/radeonkms.ko > (gdb) l *(radeon_gem_busy_ioctl+0x30) > 0xa12b0 is in radeon_gem_busy_ioctl (/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453). > 448 /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c: No such file or directory. > (gdb) Like expected. --HPS From owner-freebsd-x11@freebsd.org Tue Nov 12 23:42:13 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 941BA1BEB03 for ; Tue, 12 Nov 2019 23:42:13 +0000 (UTC) (envelope-from chrisfromgreece@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CPRT3SB0z4H9W for ; Tue, 12 Nov 2019 23:42:13 +0000 (UTC) (envelope-from chrisfromgreece@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id c22so32208wmd.1 for ; Tue, 12 Nov 2019 15:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sDpjbI57ZafsxCMzMH5lSEuVB+qQtEj1RxA+xk0ZtTE=; b=s/mKlaGVz3w7hpbnR0adxCbPItGt8xIqkkfnyEzMhCOMvCq5rb4Koy7czVYrnWNEza O97s1hqitXazyFB3AEsLLWav49TnYoHE3gyqv6I8rN23spy+AGxZeY+teOrvhe4ghpZD 4+6Gu3ciZnvJLP4cKzLUIC3zqlxV8XqJMn51/ycsRudRLtSKCumdbs9w6GZvTe/DhiQK iFSnomCNSjZY2q+I5SjWLRXJDnf1UcKHW85yD2vyQhu+Ko4rnBwg0QAYUPA/xOVNjLbl 5Ppdo8eQYq6cowsPCYxE/kYtkQx424srAXNubiokiOYpdj/jjb2ynxNew9VDz1Q1o6Pl ok3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sDpjbI57ZafsxCMzMH5lSEuVB+qQtEj1RxA+xk0ZtTE=; b=kLM71WtLSwHFU7rvwFOHkmwg272lEmWyF31cNew1DwzIvGBuZx8DSQbrkW9iSfdgWD qcqlod9zzwQr4wKPp8LEaJV3EY36kUmS5h00tj7FC3pfYL9ynrTAuFDO/a8Oun97DiBj XaXe00MfHgHt5S1rBd76aMA+8QmEuf5N9C68S1MTG33IhM41Zufd7KqpTy/Vlm6QRTdf C8BFEfjn6RRm7osDU2k2ga9qWvooPLg658iPecb7JxZPQv/yAWHtQZ9NzpOHdYqqfCvV jYbJZmuaVeri1IB/7E1OSS9Pz6VmTKTMzreWS+d/OX4shfvN57re/FcTEA/upZsB9fYu 3GsQ== X-Gm-Message-State: APjAAAU93rZpp3u3S1ElKo6a2TaWxEvsKZ/cgmyVxl0yFIymLbXrI5dz Ri1RR0hNLEACMUHVuH7oYyHRLbcvcTjwuManzUUhqq6H X-Google-Smtp-Source: APXvYqwVcxhmpaws78dUsd0ZRkbCbS2uqAPYhVWTpWPAVhEv9vkGZcok5jl3/rPY1opMSeyic5yENlLnSMDG6PjOGEw= X-Received: by 2002:a1c:f20c:: with SMTP id s12mr32088wmc.37.1573602131093; Tue, 12 Nov 2019 15:42:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?zqfPgc6uz4PPhM6/z4IgzqTPjM67zrfPgg==?= Date: Wed, 13 Nov 2019 01:42:00 +0200 Message-ID: Subject: Please can you check if you can launch and use Olive video editor ? To: freebsd-x11@freebsd.org X-Rspamd-Queue-Id: 47CPRT3SB0z4H9W X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 23:42:13 -0000 > > I have tried and failed using shotcut/kdenlive with gpu acceleration > enabled it crashes immediately after you insert a video file. > I don't know why does this happens to you too? Can you install olive video editor ? i get some dependencies messages , it requires older libraries??? If you want more freebsd coverage on the media and youtube freebsd devs should give some attention to problems with these three popular and high performance video editors. I mean customizing i3 or dwm is cool and use it as a server but actually using a video editor makes freebsd more like a desktop operating system. From owner-freebsd-x11@freebsd.org Wed Nov 13 00:30:10 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0306178124; Wed, 13 Nov 2019 00:30:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CQVn6YXkz4KHv; Wed, 13 Nov 2019 00:30:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xAD0U72t004607 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Nov 2019 16:30:07 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xAD0U60e002898; Tue, 12 Nov 2019 16:30:06 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2019 16:30:01 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191113003001.GA94074@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47CQVn6YXkz4KHv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 00:30:10 -0000 On Tue, Nov 12, 2019 at 06:48:22PM +0100, Hans Petter Selasky wrote: > On 2019-11-12 18:31, Steve Kargl wrote: > >> Can you open the radeonkms.ko in gdb83 from ports and type: > >> > >> l *(radeon_gem_busy_ioctl+0x30) > >> > > % /boot/modules/radeonkms.ko > > (gdb) l *(radeon_gem_busy_ioctl+0x30) > > 0xa12b0 is in radeon_gem_busy_ioctl (/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453). > > 448 /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c: No such file or directory. > > (gdb) > > Like expected. > I installed the 2nd seqlock.diff, rebuilt drm-current-kmod-4.16.g20191023, rebooting, and have been pounding on the system with workloads that are similar to what the system was doing during the lockups. So far, I cannot ge the system lock-up. Looks like your patch fixes (or at least helps). Thanks for taking a look at the problem. -- Steve From owner-freebsd-x11@freebsd.org Wed Nov 13 08:11:11 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C5631AA1E8; Wed, 13 Nov 2019 08:11:11 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Cckj3zy9z3DqB; Wed, 13 Nov 2019 08:11:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EEF11260072; Wed, 13 Nov 2019 09:10:59 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu To: sgk@troutmask.apl.washington.edu Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> <20191113003001.GA94074@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <1de2773b-3f54-472b-65a1-0f1c297aab60@selasky.org> Date: Wed, 13 Nov 2019 09:10:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191113003001.GA94074@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47Cckj3zy9z3DqB X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.15)[ip: (-9.33), ipnet: 88.99.0.0/16(-4.73), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 08:11:11 -0000 On 2019-11-13 01:30, Steve Kargl wrote: > On Tue, Nov 12, 2019 at 06:48:22PM +0100, Hans Petter Selasky wrote: >> On 2019-11-12 18:31, Steve Kargl wrote: >>>> Can you open the radeonkms.ko in gdb83 from ports and type: >>>> >>>> l *(radeon_gem_busy_ioctl+0x30) >>>> >>> % /boot/modules/radeonkms.ko >>> (gdb) l *(radeon_gem_busy_ioctl+0x30) >>> 0xa12b0 is in radeon_gem_busy_ioctl (/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c:453). >>> 448 /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/radeon_gem.c: No such file or directory. >>> (gdb) >> >> Like expected. >> > > I installed the 2nd seqlock.diff, rebuilt drm-current-kmod-4.16.g20191023, > rebooting, and have been pounding on the system with workloads that are > similar to what the system was doing during the lockups. So far, I > cannot ge the system lock-up. Looks like your patch fixes (or at > least helps). Thanks for taking a look at the problem. > Can you apply the kdb.diff on top and check dmesg for prints? --HPS From owner-freebsd-x11@freebsd.org Wed Nov 13 14:52:14 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 477521B2A8D; Wed, 13 Nov 2019 14:52:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CndS6WG3z47B9; Wed, 13 Nov 2019 14:52:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xADEq4ZS003681 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Nov 2019 06:52:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xADEq4Hj003680; Wed, 13 Nov 2019 06:52:04 -0800 (PST) (envelope-from sgk) Date: Wed, 13 Nov 2019 06:52:04 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191113145204.GA3650@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> <20191113003001.GA94074@troutmask.apl.washington.edu> <1de2773b-3f54-472b-65a1-0f1c297aab60@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1de2773b-3f54-472b-65a1-0f1c297aab60@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47CndS6WG3z47B9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.31 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.99)[-0.986,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 14:52:14 -0000 On Wed, Nov 13, 2019 at 09:10:06AM +0100, Hans Petter Selasky wrote: > On 2019-11-13 01:30, Steve Kargl wrote: > > > > I installed the 2nd seqlock.diff, rebuilt drm-current-kmod-4.16.g20191023, > > rebooting, and have been pounding on the system with workloads that are > > similar to what the system was doing during the lockups. So far, I > > cannot ge the system lock-up. Looks like your patch fixes (or at > > least helps). Thanks for taking a look at the problem. > > > > Can you apply the kdb.diff on top and check dmesg for prints? > I could not find the amdgpu_amdkfd_gpuvm.c file when I went looking. Is it autogenerated? I also spoke too soon. I got a panic after my reply above. Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 15 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xfffffe00b460e188 frame pointer = 0x28:0xfffffe00b460e1c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 877 (X:rcs0) trap number = 12 panic: page fault cpuid = 5 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b460dde0 vpanic() at vpanic+0x17e/frame 0xfffffe00b460de40 panic() at panic+0x43/frame 0xfffffe00b460dea0 trap_fatal() at trap_fatal+0x388/frame 0xfffffe00b460df10 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00b460df80 trap() at trap+0x288/frame 0xfffffe00b460e0b0 calltrap() at calltrap+0x8/frame 0xfffffe00b460e0b0 --- trap 0xc, rip = 0, rsp = 0xfffffe00b460e188, rbp = 0xfffffe00b460e1c0 --- ??() at 0/frame 0xfffffe00b460e1c0 radeon_cs_ioctl() at radeon_cs_ioctl+0xa0b/frame 0xfffffe00b460e640 drm_ioctl_kernel() at drm_ioctl_kernel+0xf1/frame 0xfffffe00b460e680 drm_ioctl() at drm_ioctl+0x279/frame 0xfffffe00b460e770 linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfffffe00b460e7d0 kern_ioctl() at kern_ioctl+0x284/frame 0xfffffe00b460e840 sys_ioctl() at sys_ioctl+0x157/frame 0xfffffe00b460e910 amd64_syscall() at amd64_syscall+0x273/frame 0xfffffe00b460ea30 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00b460ea30 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x200cc6bfa, rsp = 0x7fffbfffde98, rbp = 0x7fffbfffdec0 --- Uptime: 5h9m5s Dumping 1472 out of 16327 MB:..2%..11%..21%..31%..41%..52%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 warning: Source file is more recent than executable. 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392 #2 0xffffffff805de452 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:479 #3 0xffffffff805de8a6 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:908 #4 0xffffffff805de6c3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:835 #5 0xffffffff808b0d58 in trap_fatal (frame=0xfffffe00b460e0c0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:925 #6 0xffffffff808b0daf in trap_pfault (frame=0xfffffe00b460e0c0, usermode=, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:743 #7 0xffffffff808b0468 in trap (frame=0xfffffe00b460e0c0) at /usr/src/sys/amd64/amd64/trap.c:407 #8 #9 0x0000000000000000 in ?? () #10 0xffffffff817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xfffff80061eeb248) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:720 #11 radeon_ttm_tt_set_userptr (ttm=0xfffff80061eeb248, addr=1, flags=2147483647) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:804 #12 0xffffffff817adc9b in radeon_is_px (dev=0xfffff8017fe84e00) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_device.c:156 #13 0xffffffff818a9e81 in drm_ioctl_kernel (linux_file=, func=0xfffffe00b460e428, kdata=0xfffffe00b31eb000, flags=1521620552) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_ioctl.c:760 #14 0xffffffff818aa129 in drm_ioctl (filp=0xfffff80061198e00, cmd=, arg=65536) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_ioctl.c:856 #15 0xffffffff807c8098 in linux_file_ioctl_sub (fp=, filp=, fop=, cmd=, data=, td=) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965 #16 linux_file_ioctl (fp=, cmd=, data=, cred=, td=0xfffff800612c0000) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558 #17 0xffffffff8063ed34 in fo_ioctl (fp=, com=3223348326, data=0x7fffffff, active_cred=0xfffffe001f7e6250, td=0xfffff800612c0000) at /usr/src/sys/sys/file.h:340 #18 kern_ioctl (td=, fd=9, com=3223348326, data=0x7fffffff ) at /usr/src/sys/kern/sys_generic.c:801 #19 0xffffffff8063ea37 in sys_ioctl (td=0xfffff800612c0000, uap=0xfffff800612c03c8) at /usr/src/sys/kern/sys_generic.c:709 #20 0xffffffff808b1783 in syscallenter (td=0xfffff800612c0000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144 #21 amd64_syscall (td=0xfffff800612c0000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1162 #22 -- Steve From owner-freebsd-x11@freebsd.org Wed Nov 13 15:24:37 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 21B691B3AB4; Wed, 13 Nov 2019 15:24:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47CpLr1w7lz48tP; Wed, 13 Nov 2019 15:24:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AFE28260072; Wed, 13 Nov 2019 16:24:32 +0100 (CET) Subject: Re: unkillable process consuming 100% cpu To: sgk@troutmask.apl.washington.edu Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> <20191113003001.GA94074@troutmask.apl.washington.edu> <1de2773b-3f54-472b-65a1-0f1c297aab60@selasky.org> <20191113145204.GA3650@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <7e12007d-bc50-0d2a-89af-21ab30259272@selasky.org> Date: Wed, 13 Nov 2019 16:22:19 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191113145204.GA3650@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47CpLr1w7lz48tP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.62)[ip: (-9.17), ipnet: 2a01:4f8::/29(-2.28), asn: 24940(-1.65), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 15:24:37 -0000 On 2019-11-13 15:52, Steve Kargl wrote: > at /usr/src/sys/amd64/amd64/trap.c:743 > #7 0xffffffff808b0468 in trap (frame=0xfffffe00b460e0c0) > at /usr/src/sys/amd64/amd64/trap.c:407 > #8 > #9 0x0000000000000000 in ?? () > #10 0xffffffff817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xfffff80061eeb248) > at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:720 > #11 radeon_ttm_tt_set_userptr (ttm=0xfffff80061eeb248, addr=1, > flags=2147483647) Hi, I don't see any function call here. Can you try to double check the backtrace? Which version of FreeBSD is this? --HPS From owner-freebsd-x11@freebsd.org Wed Nov 13 16:50:22 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 57A631B5B00 for ; Wed, 13 Nov 2019 16:50:22 +0000 (UTC) (envelope-from msg20191113105008@savoryexperiments.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47CrFp170Rz4FmS for ; Wed, 13 Nov 2019 16:50:22 +0000 (UTC) (envelope-from msg20191113105008@savoryexperiments.com) Received: by mailman.nyi.freebsd.org (Postfix) id 2683E1B5AFF; Wed, 13 Nov 2019 16:50:22 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 264861B5AFE for ; Wed, 13 Nov 2019 16:50:22 +0000 (UTC) (envelope-from msg20191113105008@savoryexperiments.com) Received: from hikh.introtime.com (hikh.introtime.com [67.205.167.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47CrFm70HQz4FmR for ; Wed, 13 Nov 2019 16:50:20 +0000 (UTC) (envelope-from msg20191113105008@savoryexperiments.com) Received: from [70.118.67.34] (helo=[192.168.5.33]) by hikh.introtime.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1iUvqQ-0007Rk-7X for x11@FreeBSD.org; Wed, 13 Nov 2019 09:50:14 -0700 To: x11@FreeBSD.org From: eBay-message.2019November-eBay-usercontact-noreply20191113105008@savoryexperiments.com Subject: (54ID)1 new unread (system) message! Message-ID: 20191113105008-1153d2c1ddbe55381eb1076a6b3aadb0@savoryexperiments.com Date: Wed, 13 Nov 2019 16:50:08 GMT X-Rspamd-Queue-Id: 47CrFm70HQz4FmR X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of msg20191113105008@savoryexperiments.com does not designate 67.205.167.226 as permitted sender) smtp.mailfrom=msg20191113105008@savoryexperiments.com X-Spamd-Result: default: False [4.97 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.98)[ipnet: 67.205.160.0/20(3.04), asn: 14061(1.91), country: US(-0.05)]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.989,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998,0]; FROM_NO_DN(0.00)[]; MIME_HTML_ONLY(0.20)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FORGED_SENDER(0.30)[eBay-message.2019November-eBay-usercontact-noreply20191113105008@savoryexperiments.com,msg20191113105008@savoryexperiments.com]; DMARC_NA(0.00)[savoryexperiments.com]; R_DKIM_NA(0.00)[]; MID_MISSING_BRACKETS(0.50)[]; ASN(0.00)[asn:14061, ipnet:67.205.160.0/20, country:US]; HAS_DATA_URI(0.00)[]; FROM_NEQ_ENVFROM(0.00)[eBay-message.2019November-eBay-usercontact-noreply20191113105008@savoryexperiments.com,msg20191113105008@savoryexperiments.com]; RCVD_COUNT_TWO(0.00)[2] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 16:50:22 -0000 From owner-freebsd-x11@freebsd.org Wed Nov 13 17:49:41 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A2AC1B6C4A; Wed, 13 Nov 2019 17:49:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CsZD0CbMz4JGn; Wed, 13 Nov 2019 17:49:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xADHnbkR004491 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Nov 2019 09:49:37 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xADHnbx0004490; Wed, 13 Nov 2019 09:49:37 -0800 (PST) (envelope-from sgk) Date: Wed, 13 Nov 2019 09:49:37 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191113174937.GA4315@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <20191112173136.GA69344@troutmask.apl.washington.edu> <0961307a-8b14-8240-0466-6bb4edf52788@selasky.org> <20191113003001.GA94074@troutmask.apl.washington.edu> <1de2773b-3f54-472b-65a1-0f1c297aab60@selasky.org> <20191113145204.GA3650@troutmask.apl.washington.edu> <7e12007d-bc50-0d2a-89af-21ab30259272@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e12007d-bc50-0d2a-89af-21ab30259272@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47CsZD0CbMz4JGn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.98)[-0.976,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 17:49:41 -0000 On Wed, Nov 13, 2019 at 04:22:19PM +0100, Hans Petter Selasky wrote: > On 2019-11-13 15:52, Steve Kargl wrote: > > at /usr/src/sys/amd64/amd64/trap.c:743 > > #7 0xffffffff808b0468 in trap (frame=0xfffffe00b460e0c0) > > at /usr/src/sys/amd64/amd64/trap.c:407 > > #8 > > #9 0x0000000000000000 in ?? () > > #10 0xffffffff817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xfffff80061eeb248) > > at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:720 > > #11 radeon_ttm_tt_set_userptr (ttm=0xfffff80061eeb248, addr=1, > > flags=2147483647) > > Hi, > > I don't see any function call here. Can you try to double check the > backtrace? > > Which version of FreeBSD is this? > % uname -a (trimmed) FreeBSD 13.0-CURRENT r353571 % kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.2 % bt ... #7 0xffffffff808b0468 in trap (frame=0xfffffe00b460e0c0) at /usr/src/sys/amd64/amd64/trap.c:407 #8 #9 0x0000000000000000 in ?? () #10 0xffffffff817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xfffff80061eeb248) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:720 #11 radeon_ttm_tt_set_userptr (ttm=0xfffff80061eeb248, addr=1, flags=2147483647) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_ttm.c:804 #12 0xffffffff817adc9b in radeon_is_px (dev=0xfffff8017fe84e00) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_device.c:156 Looking at radeon_ttm.c, line 720 is the if-stmt in this function static struct radeon_ttm_tt *radeon_ttm_tt_to_gtt(struct ttm_tt *ttm) { if (!ttm || ttm->func != &radeon_backend_func) return NULL; return (struct radeon_ttm_tt *)ttm; } (kgdb) p ttm->func $2 = (struct ttm_backend_func *) 0x2310000 (kgdb) p &radeon_backend_func $4 = (struct ttm_backend_func *) 0xffffffff8186d870 AFAIK, 0x2310000 is not a valid address. (kgdb) p *ttm $5 = {bdev = 0xffffffff819021ef, func = 0x2310000, dummy_read_page = 0x0, pages = 0xfffff800612c0000, page_flags = 2173789980, num_pages = 0, sg = 0x0, glob = 0x2a, swap_storage = 0xfffff8017fe84e00, caching_state = (unknown: 145613312), state = (tt_unbound | tt_unpopulated | unknown: 4294965248)} Moving to frame 12 suggests that the stack is corrupt (whether by the dump or the crash I don't know) (kgdb) frame 12 #12 0xffffffff817adc9b in radeon_is_px (dev=0xfffff8017fe84e00) at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/radeon/radeon_device.c:156 156 if (rdev->flags & RADEON_IS_PX) (kgdb) p *dev Cannot access memory at address 0xfffff8017fe84e00 (kgdb) p rdev $25 = (struct radeon_device *) 0x0 -- Steve From owner-freebsd-x11@freebsd.org Wed Nov 13 18:01:12 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFE371B6FC6; Wed, 13 Nov 2019 18:01:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CsqW5Hwsz4Jx0; Wed, 13 Nov 2019 18:01:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xADI19pa010474 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Nov 2019 10:01:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xADI18m0010473; Wed, 13 Nov 2019 10:01:08 -0800 (PST) (envelope-from sgk) Date: Wed, 13 Nov 2019 10:01:08 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: Mark Johnston , freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: unkillable process consuming 100% cpu Message-ID: <20191113180108.GA10448@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191107202919.GA4565@troutmask.apl.washington.edu> <20191107203223.GF16978@raichu> <20191108220935.GA856@troutmask.apl.washington.edu> <6a4e5993-623a-ebaa-8180-e11c7d48e706@selasky.org> <3e11232b-e2a6-9169-adb0-da0e94523b39@selasky.org> <64e980fa-aa9b-e656-92a1-110d9cbf9059@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64e980fa-aa9b-e656-92a1-110d9cbf9059@selasky.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47CsqW5Hwsz4Jx0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.29 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_HAM_MEDIUM(-0.97)[-0.973,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.22)[ip: (0.06), ipnet: 128.95.0.0/16(-0.29), asn: 73(-0.83), country: US(-0.05)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 18:01:12 -0000 On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote: > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > index a6e0a16ae..0697d70f4 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c Are you using ports/graphics/drm-devel-kmod? This file does not exist in drm-current-kmod. > @@ -236,6 +238,12 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo, Using 'nm *.ko | grep eviction_fence' in /boot/modules shows that none of the modules contain amdgpu_amdkfd_remove_eviction_fence(). -- Steve From owner-freebsd-x11@freebsd.org Thu Nov 14 07:15:45 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31F251C77E5 for ; Thu, 14 Nov 2019 07:15:45 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47DCSK0RsWz40yd for ; Thu, 14 Nov 2019 07:15:45 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0C7C11C77E1; Thu, 14 Nov 2019 07:15:45 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0AA381C77E0 for ; Thu, 14 Nov 2019 07:15:45 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47DCSJ6T1Rz40yK for ; Thu, 14 Nov 2019 07:15:44 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: from portscout.nyi.freebsd.org (portscout.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BA50224C0B for ; Thu, 14 Nov 2019 07:15:44 +0000 (UTC) (envelope-from portscout@FreeBSD.org) Received: (from portscout@localhost) by portscout.nyi.freebsd.org (8.15.2/8.15.2/Submit) id xAE7FiSt029946; Thu, 14 Nov 2019 07:15:44 GMT (envelope-from portscout@FreeBSD.org) Message-Id: <201911140715.xAE7FiSt029946@portscout.nyi.freebsd.org> X-Authentication-Warning: portscout.nyi.freebsd.org: portscout set sender to portscout@FreeBSD.org using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Date: Thu, 14 Nov 2019 07:15:44 +0000 From: portscout@FreeBSD.org To: x11@freebsd.org Subject: FreeBSD ports you maintain which are out of date X-Mailer: portscout/0.8.1 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 07:15:45 -0000 Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/x11@freebsd.org.html Port | Current version | New version ------------------------------------------------+-----------------+------------ graphics/mesa-dri | 18.3.2 | 19.2.4 ------------------------------------------------+-----------------+------------ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by: portscout! From owner-freebsd-x11@freebsd.org Sat Nov 16 06:11:13 2019 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA3A91BBF6C for ; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47FPwx3Gk5z41J2 for ; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 7042C1BBF64; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6DEC81BBF63 for ; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47FPwx1yp5z41Hx for ; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2728A25213 for ; Sat, 16 Nov 2019 06:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAG6BDtV007725 for ; Sat, 16 Nov 2019 06:11:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAG6BDG4007716 for x11@FreeBSD.org; Sat, 16 Nov 2019 06:11:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 241348] [PATCH] devel/evdev-proto: add joystick.h Date: Sat, 16 Nov 2019 06:11:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: tobik@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 06:11:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241348 --- Comment #6 from Tobias Kortkamp --- (In reply to rozhuk.im from comment #5) Yes and let's request an exp-run afterwards to make it happen this year. --=20 You are receiving this mail because: You are the assignee for the bug.=