From owner-freebsd-current@freebsd.org Mon Nov 11 09:24:33 2019 Return-Path: Delivered-To: freebsd-current@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 772CD1B0266; Mon, 11 Nov 2019 09:24:33 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47BQSK2cTMz3xZQ; Mon, 11 Nov 2019 09:24:33 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 5202C8661; Mon, 11 Nov 2019 09:24:33 +0000 (UTC) Date: Mon, 11 Nov 2019 09:24:33 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2019-11-10 Message-ID: <20191111092433.GA10830@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 09:24:33 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-11-10 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-04 to 2019-11-10. During this period, we have: * 2331 builds (94.9% (+) passed, 5.1% () failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 267 test runs (92.1% (+) passed, 6.4% (-) unstable, 1.5% () exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 86 doc builds (100% (0) passed) Test case status (on 2019-11-10 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ---------- | ---------- | ------- | ------- | | head/amd64 | 7611 (+2) | 7543 (+2) | 0 (0) | 68 (0) | | head/i386 | 7609 (+23) | 7540 (+28) | 0 (0) | 69 (-5) | | 12-STABLE/amd64 | 7483 (0) | 7435 (-1) | 0 (0) | 48 (+1) | | 12-STABLE/i386 | 7481 (0) | 7426 (-1) | 0 (0) | 55 (+1) | | 11-STABLE/amd64 | 6849 (0) | 6802 (0) | 0 (-) | 47 (0) | | 11-STABLE/i386 | 6847 (0) | 6798 (+34) | 0 (-34) | 49 (0) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191110 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-testing@FreeBSD.org and lwhsu@FreeBSD.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## Fixed tests Tests of i386 netinet6 and netpfil were failing because a bug in scapy, fixed by bz@ and upstreaming at https://github.com/secdev/scapy/pull/2329 * sys.netpfil.pf.forward.v4 (i386 only) * sys.netpfil.pf.forward.v6 (i386 only) * sys.netpfil.pf.set_tos.v4 (i386 only) https://bugs.freebsd.org/239380 * sys.netpfil.common.forward.pf_v4 (i386 only) https://bugs.freebsd.org/240085 * sys.netpfil.common.tos.pf_tos (i386 only) https://bugs.freebsd.org/240086 * sys.netinet6.frag6.* https://bugs.freebsd.org/241493 libexecinfo tests are enabled and found that the tests needs unstripped binary, and also found that we need to enable unwind tables on !amd64. * https://bugs.freebsd.org/241562 failing test case: lib.libexecinfo.backtrace_test.backtrace_fmt_basic ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~18 failing and ~97 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero (new) https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239380 sys.netpfil.pf.forward.{v4,v6} and sys.netpfil.pf.set_tos.v4 fail on i386 * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Mon Nov 11 09:35:45 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Mon Nov 11 10:20:50 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Mon Nov 11 10:45:36 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Mon Nov 11 12:24:02 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Mon Nov 11 12:29:05 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Mon Nov 11 13:24:53 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Tue Nov 12 03:24:00 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Tue Nov 12 17:31:40 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Tue Nov 12 17:51:22 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 00:30:10 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 06:51:03 2019 Return-Path: Delivered-To: freebsd-current@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 33A4417FE3F for ; Wed, 13 Nov 2019 06:51:03 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CZyF5wpxz4cxx for ; Wed, 13 Nov 2019 06:51:01 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573627848; bh=iHYESEIuvsMGk4Ig31/4ixfP2mXeCV8DCEBKqQ8ZPEQ=; h=X-UI-Sender-Class:Date:From:To:Subject; b=YJmRHh+M4BUQ4V3JARc5r+n2WqS6K1jBa0zocZ0BScOq6WXjaFRFGnh3IMITeSwLB DdCbEK3sFk8VIFaLpxQCO8EuuiaSnaJiT6kTD1clVqz7swURdcvtz1qCoge0Aeyexj jpJMAF446D7hTkt3q+5uO8M9MEVgYv2Oc9qB22sE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from freyja ([79.192.161.19]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MS3ir-1iIzqG2uuB-00TTR4 for ; Wed, 13 Nov 2019 07:50:47 +0100 Date: Wed, 13 Nov 2019 07:50:41 +0100 From: "O. Hartmann" To: freebsd-current Subject: r354673: compiler error: error: unable to execute command: Segmentation fault (core dumped) cpp: error: Message-ID: <20191113075036.6f481299@freyja> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yyC4/kfrvdp/HMC/viTIQqkh6AwVwci97fA9CsR72aOYHmzzufH HAV0HvXzGbDQrlG4shNduRBTZAd7f7HkpfHlhaW9zGGaBbPytqkkOe78SI2p7WS4qfpPN3F Zv2K0gA6SddzVdzYJPryR0Gcp9YjlX3sIUCS4Rm5RaYYHQcYnqH3MxsCtPVaj8hiz66cTEC eCwin0TFDTWHGaeBXi77A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:1YvmdUo49XE=:DBQ7uoy2e/8wY76oopCCuj s5Fk1m9/Q++AERR16uyStOr8NPRsa49wQRNcCKbZ/2/PaQRNM3aoBRNQr6TCZ8Qy1ck/eH8D4 eEdkWKUu8u5uOy1Q/JLb3zDdLDZL9GqQdTraoAL3EphCo+Ln4yAOnuhYdQIYwLpHinuDI8+Ei FBfed3fX07yXYIgjgitIR5wxMXPbfRQ00xKBgZKzc0ZK+RHUQ8BfRqRLnLK/FjfjZ4nkqbWVF 4SW9F3SpDAA6/NFU+GBA8NAqEPo0G3Dn2DPnskrHytBU9pFXUp5Nuo8at/hdPY8pC9vy3h6Tl rUDx7ycTc8YgC7EohyDZXyLPFjSNNvbPfvAvSEaKL14YSZ0loPby6YHLLRWv7Bd8A+LxYicgR nm18OFuj8BAE2R6mEnIjSjJFKwo1gecyY4+XYGfr+js+Wjzb2Z6POde0BmrwkUQuio58jAy02 KSm71WFt8t+jymd+e0HVglrISsgTsFNsr0pvGoVXS3PGoEOP8jX3DFqmrjlm/gUcVEo4UeW1o Y4quZFJjINa47WHMvn1pD5GO/p4IsJWAPRF8lwUL/nqRt0YY+UZSQsN24FKJrWxEkpKtigPVj ipPF0VdqPHPC2aOTnw0B09fUaPEa1/8FUo7xf5SkiFhNog/5S7TuTnPS8GCRr8c8x6xre07MC ArSDGmw53l54zYQ3dH4LsnvLeRE2aV5MGoKIiLOSI4bTKRS7Ms2lFwo27ueF6CeWRM1Jx/CXu bx423QvSBSgVo5IMbhT6EHSiul7jRsn2pMtZZUOCqK/0GlrdpWPCNkNZ+18b1HiuwcgvYodre BTZqwYQRPGoWz8P4hjHT1CTpu90h2DI4dYWyX/vqjwyvSRvgUSqM6SarhmANc8durqf48NsI5 ngdbwlW4EIWe4xR76nbBbtXIqa2NEty13TGHUvzVQpk78JptUO3/dZKWpPmxdMrAFW89SkAqf i03oWMy9fwhshjEHdTfVweY4HYV6uBgSDzcmbw7VHwtyd4LvIY4tQ4caueXb2Bp12MNsQRrQ1 mnGmRKGT3SFA5FkI2fJR2Treqcisels7V20vQdEXgjcqhtLDni+8wV1qr6PPoF4ajRejcqT5i rXO/jR3ge5BwZ7H3DgwkrRo08daHGAkZoziCaDnvcVQcJCSdoGGTKWPRLR1KmQEQffazYxQhJ LZKq9YnvKYFoaJ4dWs0WTPOZQcCtV6uEJcQP7T/fDXMTTvF4htUYIUARJL+w+/RCqfzQkVwyH f0S0jUBfZCWaHImJaqByMdWL1o5YYahchqADHOSDswOO+HS7HqWwbKb+TgaA= X-Rspamd-Queue-Id: 47CZyF5wpxz4cxx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=YJmRHh+M; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.15.15) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.17)[ip: (-6.84), ipnet: 212.227.0.0/16(-1.28), asn: 8560(2.30), country: DE(-0.01)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[19.161.192.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 06:51:03 -0000 Trying to buildworld and/or buildkernel fails after upgrading 13-CURRENT t= oday to FreeBSD 13.0-CURRENT #25 r354673: Wed Nov 13 06:47:48 CET 2019 amd64. After a "make -j8 cleanworld cleandir" (trying to circumvent the problem) = I still face the ccp error shown below rendering the system impossible to co= mpile a world or kernel! Below you'll finde /etc/src.conf (we compile with -O3 and CPUTYPE=3Dnative= ), additionally you'll find the initial dmesg part showing the CPU type. The box is relatively new and a real troublemaker under FreeBSD at the mom= ent, as jails stopping/starting seem to trigger reprudicable crashes, but that = is an other story. How to fix this desaster? Thanks in advance and kind regards, oh [...] =2D------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims =2D------------------------------------------------------------- cd /usr/src; INSTALL=3D"sh /usr/src/tools/install.sh" TOOLS_PREFIX=3D/usr/obj/usr/src/amd64.amd64/tmp PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/a= md64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:= /sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=3D/usr/obj/usr/src/amd64.amd64/tmp MAKEFLAGS=3D"-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc1 DES= TDIR=3D OBJTOP=3D'/usr/obj/usr/src/amd64.amd64/tmp/obj-tools' OBJROOT=3D'${OBJTO= P}/' MAKEOBJDIRPREFIX=3D BOOTSTRAPPING=3D1300056 BWPHASE=3Dlegacy SSP_CFLAGS= =3D MK_HTML=3Dno NO_LINT=3Dyes MK_MAN=3Dno -DNO_PIC MK_PROFILE=3Dno -DNO_SHAR= ED -DNO_CPU_CFLAGS MK_WARNS=3Dno MK_CTF=3Dno MK_CLANG_EXTRAS=3Dno MK_CLANG_F= ULL=3Dno MK_LLDB=3Dno MK_RETPOLINE=3Dno MK_TESTS=3Dno MK_INCLUDES=3Dyes MK_LLVM_TA= RGET_ALL=3Dno legacy [Creating objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools...] =3D= =3D=3D> tools/build (obj,includes,all,install) [Creating objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/tools/build...] sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/sys/sys/nv= .h /usr/src/sys/sys/cnv.h /usr/src/sys/sys/dnv.h /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include/sys/ sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/libcasper/services/cap_fileargs/cap_fileargs.h /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include/casper/ cc -O2 -pipe = -O3 -DNDEBUG -MD -MF.depend.dummy.o -MTdummy.o -std=3Dgnu99 -Wno-format-zero-= length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include= -c /usr/src/tools/build/dummy.c -o dummy.o building static egacy library ar -= crD libegacy.a `NM=3D'nm' NMFLAGS=3D'' lorder dummy.o | tsort -q` ranlib -D libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib/ mkdir -p /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin /usr/obj/usr/src/amd64.amd64/tmp/legacy/lib/casper /usr/obj/usr/src/amd64.amd64/tmp/legacy/lib/geom /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include/casper /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include/private/zstd /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib ln -sfn bin /usr/obj/usr/src/amd64.amd64/tmp/legacy/sbin ln -sfn ../bin /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin ln -sfn ../bin /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin mkdir -p "/usr/obj/usr/src/amd64.amd64/tmp/legacy//usr/include/sys" mkdir -p "/usr/obj/usr/src/amd64.amd64/tmp/legacy//usr/include/casper" =3D=3D=3D> l= ib/libnv (obj,includes,all,install) [Creating objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libnv...] cc -O2 -pipe -O3 -I/usr/src/lib/libnv -DNDEBUG -MD -MF.depend.cnvlist.o -MTcnvlist.o -std= =3Dgnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c /usr/src/sys/contrib/libnv/cnvlist.c -o cnvlist.o Stack dump: 0. Prog= ram arguments: /usr/bin/cpp -cc1 -triple x86_64-unknown-freebsd13.0 -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name cnvlist.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=3Dgdb -coverage-not= es-file /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libnv/cnvlist.gcno -resourc= e-dir /usr/lib/clang/9.0.0 -dependency-file .depend.cnvlist.o -sys-header-deps -= MT cnvlist.o -I /usr/src/lib/libnv -D NDEBUG -I /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -O3 -Wno-format-zero-l= ength -std=3Dgnu99 -fdebug-compilation-dir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libnv -ferror-limit 19 -fmessage-length 313 -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o cnvlist.o= -x c /usr/src/sys/contrib/libnv/cnvlist.c 1. parser at end of file 2= . Code generation #0 0x00000000036a3fce (/usr/bin/cpp+0x36a3fce) #1 0x00000000036a1e8a (/usr/bin/cpp+0x36a1e8a) #2 0x00000000036a4976 (/usr/bin/cpp+0x36a4976) #3 0x00000008048707d0 (/lib/libthr.so.3+0x147d0) = cpp: error: unable to execute command: Segmentation fault (core dumped) cpp: er= ror: clang frontend command failed due to signal (use -v to see invocation) Fre= eBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on LLVM 9.0.0) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/= bin cpp: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preproce= ssed source, and associated run script. cpp: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cpp: note: diagnostic msg: /tmp/cnvlist-e82baa.c cpp: note: diagnostic msg: /tmp/cnvlist-e82baa.sh cpp: note: diagnostic msg: ******************** *** Error code 254 Stop. make[3]: stopped in /usr/src/lib/libnv *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src [...] [... /etc/src.conf ...] # CPUTYPE?=3D native # CFLAGS+=3D -O3 COPTFLAGS+=3D -O3 # WITH_CLANG_EXTRAS=3D YES WITH_LLDB=3D YES #WITH_BSD_GREP=3D YES # WITH_OFED=3D YES WITH_NAND=3D YES #WITH_CTF=3D YES # WITH_BEARSSL=3D YES # WITH_SVN=3D YES # WITH_SORT_THREADS=3D YES # MALLOC_PRODUCTION=3D YES # WITHOUT_ASSERT_DEBUG=3D YES WITHOUT_DEBUG_FILES=3D YES WITHOUT_TESTS=3D YES # WITHOUT_REPRODUCIBLE_BUILD=3D YES # # mitigation for CVE-2017-5715 in the kernel build #WITH_RETPOLINE=3D YES # KERNCONF=3D GENERIC-NODEBUG #KERNCONF=3D GENERIC KERNCONFDIR=3D /etc/config/amd64/kernel_conf # PORTS_MODULES=3D #PORTS_MODULES+=3Demulators/virtualbox-ose-kmod #PORTS_MODULES+=3Demulators/virtualbox-ose-additions [...] =2D--<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #25 r354673: Wed Nov 13 06:47:48 CET 2019 root@sb211:/usr/obj/usr/src/amd64.amd64/sys/SB211 amd64 FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based o= n LLVM 9.0.0) VT(efifb): resolution 1280x1024 CPU microcode: updated from 0x5000029 to 0x500002c CPU: Intel(R) Xeon(R) Gold 5217 CPU @ 3.00GHz (2993.05-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x50657 Family=3D0x6 Model=3D0x55 Stepp= ing=3D7 Features=3D0xbfebfbff Features2=3D0x7ffefbff AMD Features=3D0x2c100800 AMD Features2=3D0x121 Structured Extended Features=3D0xd39ffffb Structured Extended Features2=3D0x808 Structured Extended Features3=3D0xbc000400 XSAVE Features=3D0xf IA32_ARCH_CAPS=3D0xab VT-= x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, perform= ance statistics real memory =3D 68719476736 (65536 MB) avail memory =3D 66361274368 (63287 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. Security policy loaded: MAC/ntpd (mac_ntpd) ioapic0 irqs 0-23 ioapic1 irqs 24-31 ioapic2 irqs 32-39 ioapic3 irqs 40-47 ioapic4 irqs 48-55 Launching APs: 1 6 11 9 10 13 2 7 15 8 5 14 3 4 12 Timecounter "TSC-low" frequency 1496526241 Hz quality 1000 random: entropy device external interface kbd0 at kbdmux0 000.000077 [4336] netmap_init netmap: loaded module nexus0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s aesni0: cryptosoft0: acpi0: acpi0: Power Button (fixed) cpu0: numa-domain 0 on acpi0 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 24000000 Hz quality 950 Event timer "HPET" frequency 24000000 Hz quality 350 Event timer "HPET1" frequency 24000000 Hz quality 340 Event timer "HPET2" frequency 24000000 Hz quality 340 Event timer "HPET3" frequency 24000000 Hz quality 340 Event timer "HPET4" frequency 24000000 Hz quality 340 Event timer "HPET5" frequency 24000000 Hz quality 340 Event timer "HPET6" frequency 24000000 Hz quality 340 Event timer "HPET7" frequency 24000000 Hz quality 340 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 acpi_syscontainer0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff numa-domain 0 on acpi0 pci0: numa-domain 0 on pcib0 ioat0: mem 0x78ffff2c000-0x78ffff2ffff at device 4.0 numa-domai= n 0 on pci0 ioat0: Capabilities: f0006f1 ioat1: mem 0x78ffff28000-0x78ffff2bfff at device 4.1 numa-domai= n 0 on pci0 ioat1: Capabilities: f0006f1 ioat2: mem 0x78ffff24000-0x78ffff27fff at device 4.2 numa-domai= n 0 on pci0 ioat2: Capabilities: f0004f1 ioat3: mem 0x78ffff20000-0x78ffff23fff at device 4.3 numa-domai= n 0 on pci0 ioat3: Capabilities: f0004f1 ioat4: mem 0x78ffff1c000-0x78ffff1ffff at device 4.4 numa-domai= n 0 on pci0 ioat4: Capabilities: f0004f1 ioat5: mem 0x78ffff18000-0x78ffff1bfff at device 4.5 numa-domai= n 0 on pci0 ioat5: Capabilities: f0004f1 ioat6: mem 0x78ffff14000-0x78ffff17fff at device 4.6 numa-domai= n 0 on pci0 ioat6: Capabilities: f0004f1 ioat7: mem 0x78ffff10000-0x78ffff13fff at device 4.7 numa-domai= n 0 on pci0 ioat7: Capabilities: f0004f1 = pci0: at device 8.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no dri= ver attached) ahci0: port 0x3070-0x3077,0x3060-0x3063,0x3020-0x303f mem 0xaac06000-0xaac07fff,0xaac09000-0xaac090ff,0xaab80000-0xaabfffff at devic= e 17.5 numa-domain 0 on pci0 ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahc= ich1: at channel 1 on ahci0 ahciem0: on ahci0 xhci0: mem bridge> 0x78ffff00000-0x78ffff0ffff at device 20.0 numa-domain 0 on pci0 x= hci0: bridge> 32 bytes context size, 64-bit DMA usbus0 numa-domain 0 on xhci0 us= bus0: bridge> 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (= no bridge> driver attached) pci0: at device 22.1 (no driver bridge> attached) pci0: at device 22.4 (no driver attached) bridge> ahci1: port bridge> 0x3050-0x3057,0x3040-0x3043,0x3000-0x301f mem bridge> 0xaac04000-0xaac05fff,0xaac08000-0xaac080ff,0xaab00000-0xaab7ffff = at bridge> device 23.0 numa-domain 0 on pci0 ahci1: AHCI v1.31 with 8 6Gbps ports, Port Multiplier not supported From owner-freebsd-current@freebsd.org Wed Nov 13 08:11:11 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 14:30:25 2019 Return-Path: Delivered-To: freebsd-current@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 9050D1B2252 for ; Wed, 13 Nov 2019 14:30:25 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (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 47Cn8J4zz1z45Zm for ; Wed, 13 Nov 2019 14:30:24 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f171.google.com with SMTP id e9so2779170ljp.13 for ; Wed, 13 Nov 2019 06:30:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=pr/whjAg0MattsVV2AMvGFcjvVHqIH8pW+O/OuMymlg=; b=a8H5KZa8b05DWTDW0BGh//nSaYLxydQ+MikIyPgCpZBdKDxcAAvVwRvluVsEfZg2BE dOBpWVO/FUw4jxhBg0eUAoKEA2Ve2o2kuD+W5pC1WQxp+wWQenAhrqsDSz9s4HdEu0Lu OayrKpScf0LCm3g1q3c12acpodQvA7eaba0V5nclWW68fobxraCjCZTBF2Qu4xghqjh0 +50TNwUCe8Kjj2vEGE9tZ/Ce2HsrpgFnBcmvKTH9dqTjv9pzLM1Bb8O7/k/GndoZcSv4 f9+wxF/1F2TY8QY52w+tj8NI9QAU9rWSMx1AQx5jnd9aJJuG7zZ1wnV9UaRWNlLe0NCT Z1hg== X-Gm-Message-State: APjAAAVrlOhdsKFB6IVio2YzFA/Q94h8JysDSEvHseSPIANaWpVcX1qu /y9JJEXK4Kt//mzb5oSeEhyr45gsTnM= X-Google-Smtp-Source: APXvYqwwHnwPwG/8ZBGRA4/j9T8FMPnmjiDjF8gQaDgkZIh6Hy9y74ukgjZuELTfV/qFwiCfu0Ft2w== X-Received: by 2002:a2e:89c6:: with SMTP id c6mr2873844ljk.113.1573655421560; Wed, 13 Nov 2019 06:30:21 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id z21sm1454751lfg.0.2019.11.13.06.30.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 06:30:20 -0800 (PST) To: FreeBSD Current From: Andriy Gapon Subject: possible bug in devstat_selectdevs() Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Wed, 13 Nov 2019 16:30:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47Cn8J4zz1z45Zm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-3.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.12)[ip: (-0.36), ipnet: 209.85.128.0/17(-3.19), asn: 15169(-1.99), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[171.208.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[171.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 14:30:25 -0000 I wonder if anyone remembers devstat code enough to help me or, at least, to sanity check my line of thinking. I am looking at a crash that happened in devstat_selectdevs(num_selections=27, numdevs=25). At the time of the crash there was some reconfiguration of logical volumes on a RAID controller, so "disks" were coming and going. The first relevant block of code in the function is: /* * In this case, we have selected devices before, but the device * list has changed since we last selected devices, so we need to * either enlarge or reduce the size of the device selection list. */ } else if (*num_selections != numdevs) { *dev_select = (struct device_selection *)reallocf(*dev_select, numdevs * sizeof(struct device_selection)); *select_generation = current_generation; init_selections = 1; So, dev_select array is realloc-ed to have space for numdevs elements. Then we have this: if (((init_selected_var != 0) || (init_selections != 0) || (perf_select != 0)) && (changed == 0)){ old_dev_select = (struct device_selection *)malloc( *num_selections * sizeof(struct device_selection)); if (old_dev_select == NULL) { snprintf(devstat_errbuf, sizeof(devstat_errbuf), "%s: Cannot allocate memory for selection list backup", __func__); return(-1); } old_num_selections = *num_selections; ==> bcopy(*dev_select, old_dev_select, sizeof(struct device_selection) * *num_selections); } The crash happened in the bcopy() call. So, we are trying to copy num_selections (I omit pointer dereferencing) elements from the dev_select array. But in the previous block we resized the array to numdevs and in this case numdevs is less than num_selections. The code is quite unfamiliar to me. My first instinct is to just clamp the copy size, but I am not sure if that would be the right thing. Maybe realloc of dev_select should be done after bcopy-ing out of the array? Or maybe it's okay to realloc only if the size is going up? Any help is appreciated. Thank you very much in advance! -- Andriy Gapon From owner-freebsd-current@freebsd.org Wed Nov 13 14:52:14 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 15:24:37 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 17:49:41 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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-current@freebsd.org Wed Nov 13 18:01:12 2019 Return-Path: Delivered-To: freebsd-current@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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current 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