From owner-freebsd-current@freebsd.org Sun Aug 16 14:45:01 2020 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 52D903BD8DD for ; Sun, 16 Aug 2020 14:45:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV0MH18yGz4RXZ for ; Sun, 16 Aug 2020 14:44:58 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1k7Ju0-00086i-HG for freebsd-current@freebsd.org; Sun, 16 Aug 2020 16:44:53 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org Date: Sun, 16 Aug 2020 16:44:51 +0200 Subject: dma fails to connect (error:1408F10B:SSL routines:ssl3_get_record:wrong version number) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.4 X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, BAYES_50, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF autolearn=disabled version=3.4.2 X-Scan-Signature: a8ecdd0179e5342c74548fafd5461917 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597589101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=3oSUlC2tFBFzOSv2smU3rNxmI4SpPfa9ga9hzBv0+Ts=; b=PfigI5tCfAd0qVvYsyZ7mzGITyRVePn+7gC5U9XHbW4nl+CCcyiyf7jVA7wcLVLBhayqvx kXnP6A2fLOm/K36mxUldcYif2IGxqRKYpbq9Jy4//PfaS2q7RPQHDuhzJ6jbuv1oVA90xQ 2/EJAldhqWeZhQfScDubMpbhxpT3vRccK4UioxlD1kXZzmL7eXhG3ORIZpXVSlojDrZ10x 99TixnKnxMzaX6xzsE0dz0bPHm6tHk1kAhRri3A0xHKqQj3wUoKyIbO4wI8ypGGriinx+p d9qfNK6eH26b6PQfFa5q4wE/AhIFPoz/Y/21nXPTJcU3dMyK+Xdog5pMCR2JQQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597589101; a=rsa-sha256; cv=none; b=HXL723htHzDBKYMsulI7wXkuSkgySK94f+NvnKYv8QGoBNNiXt86peofNxLGdMfDEiRhg/ nQmDifWLZilB6RlQalkvbqnaoYGAujbg8q19MzMrhXSX+hyDO/q+0wyCxa9PKn0J3ZwxhY Yy+Ixb/euCzJqqDaqV7vv8r0XbITTNgFz2r+6hWnN4W+e+IASHs5w9lIJUOI9WHSC53OlU IBNqE9nGBgQNxnfunjMdJlGKI3JHct2wobvnH/IVVoJq1QJVQM2YUKCQhOtH0MWgMH7k1R Umrxi1FCfB4vkQXUqLKPhCKIOoDPLi00+fJzRjvjsYnAZ4edtqeuAZxiIfLjkw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=Os7DxnBw; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Rspamd-Queue-Id: 4BV0MH18yGz4RXZ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[195.190.28.88:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.974]; DMARC_NA(0.00)[klop.ws]; DKIM_TRACE(0.00)[klop.ws:+]; NEURAL_HAM_SHORT(-0.70)[-0.703]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 14:45:01 -0000 Hi, I have uname -UK -> 1300101 1300101 in my laptop. This uses libexec/dma as mail agent. I have 2 jails running uname -U -> 1300101 and 1300104. All dma configs are the same. In all 1300101 versions dma can deliver mail to my smarthost. On 1300104 I get: Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: trying remote delivery to smtp.greenhost.nl [213.108.110.112] pref 0 Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: SSL_client_method Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: remote delivery deferred: SSL handshake failed fatally: error:1408F10B:SSL routines:ssl3_get_record:wrong version number Any thoughts on this? bisecting this will take me hours and hours of compilation Regards, Ronald. From owner-freebsd-current@freebsd.org Sun Aug 16 15:17:43 2020 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 85F303BEFC0 for ; Sun, 16 Aug 2020 15:17:43 +0000 (UTC) (envelope-from "") Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.posteo.de", Issuer "StartCom Class 3 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV1522MTjz4TYZ for ; Sun, 16 Aug 2020 15:17:42 +0000 (UTC) (envelope-from "") Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id B8B3A160060 for ; Sun, 16 Aug 2020 17:17:39 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BV14y4yG4z6tmV for ; Sun, 16 Aug 2020 17:17:38 +0200 (CEST) From: Walter von Entferndt To: freebsd-current@freebsd.org Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images Date: Sun, 16 Aug 2020 17:16:38 +0200 Message-ID: <9004644.RH3biPoPvx@t450s.local.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597591062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k0dFIBzBXLxJBxx5bXGFvwXdWAKUbT+aY8VMnsr097o=; b=ypVMWoWcFnTkMALe74gGnWZ/l9wd89+Je7XDWXTNXuA3pdqpsXlBmK35UPzhzjC5T2dBvO kCH6fhk7YMOvlC3VNdzYF4a4TJpOFLj9LlyRwO4zwzrD0WxTPBgWbIu2Ck0jezPppo1/m0 gB5OTNVLcydOxbOiV2g2vNd2dkweD2Bunr5GEHfAYB7gPVanNdkDgYe/VVuBUhY5uKqLUt mEDZSysFEjJaBTMRtRqsagdLwZsparRaQI4dfdi/Mtk+YXoXpLAtzgi6yCh1ZNNJSKQwVM S/H/DjY9meR3apYzX61pd37UWxj+JYvzd8Q/Kc9h8jU79zkGAz/3zssw/3CbEQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597591062; a=rsa-sha256; cv=none; b=yOrGuyKwJJ6kAPZM4vUyQ23Q+yf9hY/br6YUD9i1ZoIrnTsTzFst3PKIljLDOKjxGjfzfn ktn6RX+l47FU0cj5+GuqR4FJUh21T0U8yZi0viEaiROCKYTz5uVnBNC64+wOFAC80Ky1lR 0beilKIxX/04qosih3PPq4PlJFJvUkkGuycXfUvwfUPt25qF11Ki9tI21d1K9ji197tHng RiS1q7Zplla9aiT9pHp5QK6XNWpKiJM5a/VA0TI+184Q0m31HbyUdZnEtIUHjDPczHUsb8 E4j60Jg4xPEeQQms1Rb7AP4n+NS5YdnCC3Zl52fNr4TqEl7EcLdmvHtgVaNSIA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of mout01.posteo.de has no SPF policy when checking 185.67.36.141) smtp.helo=mout01.posteo.de X-Rspamd-Queue-Id: 4BV1522MTjz4TYZ X-Spamd-Bar: - X-Spamd-Result: default: False [-1.78 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.911]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; ARC_SIGNED(0.00)[i=1]; RCVD_IN_DNSWL_MED(-0.20)[185.67.36.141:from]; NEURAL_HAM_SHORT(-0.47)[-0.472]; NEURAL_HAM_MEDIUM(-0.70)[-0.698]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8495, ipnet:185.67.36.0/23, country:DE]; FROM_NEQ_ENVFROM(0.00)[walter.von.entferndt@posteo.net,]; CTE_CASE(0.50)[]; DMARC_POLICY_SOFTFAIL(0.10)[posteo.net : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 15:17:43 -0000 At Sonntag, 16. August 2020, 14:00:00 CEST, Matthew Macy wrote: > Yes, this appears to have been going on for at least the last week. > The FreeBSD infrastructure directly available to developers appears to > be unreliable for serving large files. Individuals with accounts on > freefall have been able to scp the files. It's possible that we may > just end up sharing images more widely by way of releng generated > images after commit. I'll see if there's an alternative for the last > week of the CFT. Why not use torrent as a workaround? -- =|o) "Stell' Dir vor es geht und keiner kriegt's hin." (Wolfgang Neuss) From owner-freebsd-current@freebsd.org Sun Aug 16 15:28:46 2020 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 F09953BF881 for ; Sun, 16 Aug 2020 15:28:46 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BV1Kn6lwSz4V4j for ; Sun, 16 Aug 2020 15:28:45 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id c15so12457359wrs.11 for ; Sun, 16 Aug 2020 08:28:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BdjwoCBCtTITHKlx4B7CwgvKpbtuotyZo2Xy5q8LwHs=; b=i4cOVjN2l1PIX5nKl/E++2BqnNjqrJdkx6iZrW5TSFfIDMsln01DxSS+pb2mtevwuF KRNsY/h0YsfkIlo90/Gb3qAW4q4t5VGALtKQaYIpisZKdfg6t/XpiNR65N42PYBm6voX ww1BMOc6rNzp43ryHFbP6dW+dP+0SWKnKnM/JTjIQ7xEqvcyUMRTJLDL33shHPUL6B2d j4cUVtgeQtmmFm9lXPSvj2OBq4PI5pudqQGFlr37MzcKPTM6UdPFW0VpQ0U6iKj7Zm1D 7hLU4nbaUPPP47QHup6z3W0mUk4Gof2/sf3ckal+wvm60J4oRzvU5K6g7R9UUjrPZFi0 cCEg== X-Gm-Message-State: AOAM532E1pvrCglP7JgnycL/sXzmaZS8F5pDsz0/oreKGhKtgO1kMRlA RueIOfngvWaco3zzAqtiFkQOxXblHQ9/Tri2ascxUsNKbBdsgg== X-Google-Smtp-Source: ABdhPJxh+uLKl/d+w9gTQIP7F3oHgHF4aYkslKSOboLGazIg25/8EarY/XAISIbjlhJoT4VzJ9LBDVQSso4ar8vtx8I= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr11089555wrp.412.1597591724044; Sun, 16 Aug 2020 08:28:44 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> In-Reply-To: From: Alexandre Levy Date: Sun, 16 Aug 2020 16:28:33 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597591726; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BdjwoCBCtTITHKlx4B7CwgvKpbtuotyZo2Xy5q8LwHs=; b=C4GKVyIte0QE01UCRgdco4QKsSqrJt0Tv6Sq7BoGZRc9gENrDI2qDnmPpzdkj7Fm7rEfdj Q6VG87Yiesg4P4ymqBQAdrXwXtv5gzwEjifxhkl3HVcfcPC/knqxPF382EFwOqTEQk3jcf PGPu7r2WwoTkE3bJ2KtWV4Xmp/KWwxwtfFaro1N/Pcjg7+qbquCecxm5HhonT6WzKSK9uI BpAq7VVgDw2pT1sHFEgTAek5b16MYUm/HXXpM2hoXWyEH8Ef7hNksfzA0TFU5e2vf82Jvz euc0xuyOTy4PmBC/Tbe1pVWzRf40LweurEjsn/1PH8R997nQ8evDlNMI03m8CA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597591726; a=rsa-sha256; cv=none; b=wVn+IdAMrl8W2QSt7RiXlQRmPa3KWA7QTgegylNCW42DcvMUozhI3mjxgJARodR+LVkJk/ BoG4YjM6bb/3ezBlNY8OyfEX+7o0vkqR9ac6rQ3Qz88/gXUt9++s2GKigE+0HU1SRtXgDi 1iLlSfXU1FiY6CUcBgzXeRUBzAsI90gkCPlZYRuZFCEVEAgridWhx0dCO1AwpxQsuQJcue zk9/OGqPBQNUGp+0vHkc2+tlWg12SkECe9RGaTrt97oPzzxETS85dOvVcW9uGZEEhV35st RQAglMOkJT7l3m2IIqGlMaX/N+HHzITGma2rm7L4Rhfmd9jR9w+2Fwhe9RlyOA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=T/YcAG33; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::444 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Rspamd-Queue-Id: 4BV1Kn6lwSz4V4j X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.051]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_LONG(-1.02)[-1.020]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::444:from]; NEURAL_HAM_SHORT(-1.05)[-1.046]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 15:28:47 -0000 Hi, I looked at the crash dump and the code more closely: #18 0xffffffff82be1c5f in i915_gem_fault (dummy=3D, vmf=3D) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/gem/i915_gem_mman.c:367 (kgdb) p area->vm_obj->lock $43 =3D {lock_object =3D {lo_name =3D 0xffffffff8112c767 "vm object", lo_fl= ags =3D 627245056, lo_data =3D 0, lo_witness =3D 0xfffff8045f575800}, rw_lock =3D 18446741878623409920} So vm_obj is not NULL and has a rw_lock member Now at intel_freebsd.c:193 (frame #17) the driver calls vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL). 'm' is the page grabbed from vm_obj of the calling frame. The panic occurs in kern_rwlock.c:270 in frame #15 when calling rw_wowner(rwlock2rw(c)) so something goes wrong either in rw_wowner or in rwlock2rw. Looking at rwlock2rw() : /* * Return the rwlock address when the lock cookie address is provided. * This functionality assumes that struct rwlock* have a member named rw_lock. */ #define rwlock2rw(c) (__containerof(c, struct rwlock, rw_lock)) I think this one is just extracting out the rw_lock member of the passed in struct. However I don't understand what the cookie address is about due to my lack of knowledge on kernel locking concepts. So maybe something is wrong with the cookie or the rw_lock value itself. Looking at rw_wowner() : /* * Return a pointer to the owning thread if the lock is write-locked or * NULL if the lock is unlocked or read-locked. */ #define lv_rw_wowner(v) \ ((v) & RW_LOCK_READ ? NULL : \ (struct thread *)RW_OWNER((v))) #define rw_wowner(rw) lv_rw_wowner(RW_READ_VALUE(rw)) I don't think that one could cause a panic but again I'm not experienced enough to be sure, it seems this either returns the thread that owns the lock or NULL if no thread owns it. The is also the fact that the driver calls vm_page_busy_acquire with the VM_ALLOC_WAITFAIL flag which is defined in vm_page.h as : #define VM_ALLOC_WAITFAIL 0x0010 /* (acf) Sleep and return error */ Could this be the reason of the panic as in we try to lock, then cannot and eventually just return an error without retrying ? There is the flag VM_ALLOC_WAITOK that says /* (acf) Sleep and retry */. Should I try to patch intel_freebsd.c to use this flag instead ? Thanks. Le sam. 15 ao=C3=BBt 2020 =C3=A0 20:35, Alexandre Levy = a =C3=A9crit : > Hi, > > I could finally generate a crash dump even with a black screen, I had to > guess I was in the crash handler and I type "dump" and enter which worked= . > The driver logs "[drm] Cannot find any crtc or sizes" which I guess is th= e > reason why I couldn't see anything on my screen. > > Back to the initial problem, I could start a kgdb session, loaded the > i915kms.ko symbols and here are the results : > > (kgdb) bt > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 > #2 0xffffffff8049c26a in db_dump (dummy=3D, > dummy2=3D, dummy3=3D, dummy4=3D) a= t > /usr/src/sys/ddb/db_command.c:575 > #3 0xffffffff8049c02c in db_command (last_cmdp=3D, > cmd_table=3D, dopager=3D1) at /usr/src/sys/ddb/db_command.= c:482 > #4 0xffffffff8049bd9d in db_command_loop () at > /usr/src/sys/ddb/db_command.c:535 > #5 0xffffffff8049f048 in db_trap (type=3D, code=3D out>) at /usr/src/sys/ddb/db_main.c:270 > #6 0xffffffff80c1b374 in kdb_trap (type=3D3, code=3D0, tf=3D) at > /usr/src/sys/kern/subr_kdb.c:699 > #7 0xffffffff8100ca98 in trap (frame=3D0xfffffe00d7567300) at > /usr/src/sys/amd64/amd64/trap.c:576 > #8 > #9 kdb_enter (why=3D0xffffffff811d5de0 "panic", msg=3D) a= t > /usr/src/sys/kern/subr_kdb.c:486 > #10 0xffffffff80bd00be in vpanic (fmt=3D, ap=3D) > at /usr/src/sys/kern/kern_shutdown.c:902 > #11 0xffffffff80bcfe53 in panic (fmt=3D0xffffffff81c8c7c8 > "\b\214\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:83= 9 > #12 0xffffffff8100cee7 in trap_fatal (frame=3D0xfffffe00d7567600, eva=3D0= ) at > /usr/src/sys/amd64/amd64/trap.c:915 > #13 0xffffffff8100c360 in trap (frame=3D0xfffffe00d7567600) at > /usr/src/sys/amd64/amd64/trap.c:212 > #14 > #15 _rw_wowned (c=3D0x2659c92217d5aa52) at > /usr/src/sys/kern/kern_rwlock.c:270 > #16 0xffffffff80ec23ed in vm_page_busy_acquire (m=3D0xfffffe00040ff9e8, > allocflags=3D16) at /usr/src/sys/vm/vm_page.c:884 > #17 0xffffffff82b4e980 in remap_io_mapping (vma=3D0xfffff80315148300, > addr=3D, pfn=3D, size=3D, > iomap=3D) > at > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/d= rm/i915/intel_freebsd.c:193 > #18 0xffffffff82be1c5f in i915_gem_fault (dummy=3D, > vmf=3D) > at > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/d= rm/i915/gem/i915_gem_mman.c:367 > #19 0xffffffff82cb5ddf in linux_cdev_pager_populate > (vm_obj=3D0xfffff80368501420, pidx=3D, fault_type=3D out>, max_prot=3D, > first=3D0xfffffe00d7567868, last=3D0xfffffe00d7567888) at > /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:554 > #20 0xffffffff80ea9e8f in vm_pager_populate (object=3D0x2659c92217d5aa52, > pidx=3D18446741874754451944, fault_type=3D0, max_prot=3D0 '\000', > first=3D, last=3D) > at /usr/src/sys/vm/vm_pager.h:172 > #21 vm_fault_populate (fs=3D) at > /usr/src/sys/vm/vm_fault.c:444 > #22 vm_fault_allocate (fs=3D) at > /usr/src/sys/vm/vm_fault.c:1028 > #23 vm_fault (map=3D, vaddr=3D, > fault_type=3D, fault_flags=3D, m_hold=3D out>) at /usr/src/sys/vm/vm_fault.c:1338 > #24 0xffffffff80ea98ee in vm_fault_trap (map=3D0xfffffe00c0f539e8, > vaddr=3D, fault_type=3D, fault_flags=3D0, > signo=3D0xfffffe00d7567ac4, > ucode=3D0xfffffe00d7567ac0) at /usr/src/sys/vm/vm_fault.c:585 > #25 0xffffffff8100d0de in trap_pfault (frame=3D0xfffffe00d7567b00, > usermode=3D, signo=3D, ucode=3D0xffffffff81= d1de80 > ) > at /usr/src/sys/amd64/amd64/trap.c:817 > #26 0xffffffff8100c72c in trap (frame=3D0xfffffe00d7567b00) at > /usr/src/sys/amd64/amd64/trap.c:340 > #27 > #28 0x000000080296659a in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffffbf38 > (kgdb) list *0xffffffff82be1c5f > 0xffffffff82be1c5f is in i915_gem_fault > (/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/= drm/i915/gem/i915_gem_mman.c:367). > 362 ret =3D i915_vma_pin_fence(vma); > 363 if (ret) > 364 goto err_unpin; > 365 > 366 /* Finally, remap it using the new GTT offset */ > 367 ret =3D remap_io_mapping(area, > 368 area->vm_start + > (vma->ggtt_view.partial.offset << PAGE_SHIFT), > 369 (ggtt->gmadr.start + > vma->node.start) >> PAGE_SHIFT, > 370 min_t(u64, vma->size, area->vm_end > - area->vm_start), > 371 &ggtt->iomap); > (kgdb) list *0xffffffff82b4e980 > 0xffffffff82b4e980 is in remap_io_mapping > (/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/= drm/i915/intel_freebsd.c:193). > 188 pidx++, pa +=3D PAGE_SIZE) { > 189 retry: > 190 m =3D vm_page_grab(vm_obj, pidx, VM_ALLOC_NOCREAT= ); > 191 if (m =3D=3D NULL) { > 192 m =3D PHYS_TO_VM_PAGE(pa); > 193 if (!vm_page_busy_acquire(m, > VM_ALLOC_WAITFAIL)) > 194 goto retry; > 195 if (vm_page_insert(m, vm_obj, pidx)) { > 196 vm_page_xunbusy(m); > 197 VM_OBJECT_WUNLOCK(vm_obj); > (kgdb) list *0xffffffff80ec23ed > 0xffffffff80ec23ed is in vm_page_busy_acquire > (/usr/src/sys/vm/vm_page.c:884). > 879 if (vm_page_tryacquire(m, allocflags)) > 880 return (true); > 881 if ((allocflags & VM_ALLOC_NOWAIT) !=3D 0) > 882 return (false); > 883 if (obj !=3D NULL) > 884 locked =3D VM_OBJECT_WOWNED(obj); > 885 else > 886 locked =3D false; > 887 MPASS(locked || vm_page_wired(m)); > 888 if (_vm_page_busy_sleep(obj, m, m->pindex, > "vmpba", allocflags, > > It seems like the problem occured when calling vm_page_busy_acquire(m, > VM_ALLOC_WAITFAIL) where m might be a NULL pointer ? I am very new to > kernel debugging so not sure where to go from there. > > Thanks. > > Le lun. 10 ao=C3=BBt 2020 =C3=A0 12:04, Hans Petter Selasky a > =C3=A9crit : > >> Hi, >> >> On 2020-08-10 12:59, Alexandre Levy wrote: >> > Looking at the code, the error happens during the call to >> VM_OBJECT_WLOCK >> > (memory page locking for write ?) in the intel_freebsd.c (see [1] >> below). >> > I'm out for a few days but I'll try to dig more into it when I'm back >> next >> > weekend although I have no experience in the drm-devel-kmod codebase. = In >> > the meantime if you have any suggestions on debugging this further I'm >> > happy to follow them. >> >> The problem is likely that the vm_obj is NULL. >> >> I think I recall that this function is special and can only be called >> from a certain context, unlike in Linux. Will need the full backtrace >> with line numbers in order to debug this. >> >> --HPS >> > From owner-freebsd-current@freebsd.org Sun Aug 16 15:42:26 2020 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 07B033BFC04 for ; Sun, 16 Aug 2020 15:42:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670076.outbound.protection.outlook.com [40.107.67.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV1dY0Vn4z4W05 for ; Sun, 16 Aug 2020 15:42:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XuigoIM/rnQPJ1bNs4IqnYNuAvpBo7SKJEswnUVL3u0G4ZN4Hc3iQmLTaEHp5GPP8d5Q1gvUmYG6gsyy7s6W4V+jCZ/O4OK8FwidGOiMZYI9bw3Zw0jR9oHQ1vnWvegRRwBOyAQ0LMSrp0GIbcMEg1vmt8QV6iLluGph5PCTPhBy1WwZx9ZbIG2XBw4MIrRXJKiPgVBP+5A/s4exvuO6K+bWUseJAL10CW3xXDWJzRKcLerZt2Yu/oNCOgjk6wDf9F4AUSKdfo4OYfr4uABm9faxM3XpkDy6pky2M65QI8DWVqsghf1m4MLpRC0bc0uG0r8GnMrf5hrt4u5YvUOiGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y+Mj0yX8Md8yV487PU6wzIxBIA6VlRwCxGAWs2Yza/Q=; b=ND8YkOxGkCJbTh3RsJvLS/5pz/ATkO7JqwkU9R4foS5NHx7Od6i9jyIQvYz1hJfnGhqLyFg3DHzToac9+L5B51l+hmdkZZBlmI/Ak4dvTyJDR3czGLWoomXov1VqmC/dI61HbTPeMEnwj3L2O+g0gQQ7OPSElsBMo38pYRd7T2Njgn7lCNtRaky7lB9yDc1NP7WmA14Aot9K2rdp50udEnT7uAhJwW5+XCmvfMAV/an0qrxr9iluc2KYYArZChVa3yeYGPUXhYL3sMcqrtvlzRVFRMwloUy9lMIms7VKbnyJEz1R/MJBAu7iDqEM7bG/MQiGOepfuz1zzwQID1Ab5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:38::14) by YQXPR01MB3847.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:42::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.15; Sun, 16 Aug 2020 15:42:23 +0000 Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::e89a:a655:91ca:4e63]) by QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::e89a:a655:91ca:4e63%5]) with mapi id 15.20.3283.027; Sun, 16 Aug 2020 15:42:14 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: review of a change to sosend_generic() Thread-Topic: review of a change to sosend_generic() Thread-Index: AQHWc+NHhMoQj2hArkGRO65PT+taLQ== Date: Sun, 16 Aug 2020 15:42:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82113675-84be-44a0-9281-08d841faf316 x-ms-traffictypediagnostic: YQXPR01MB3847: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 208+k3VLbkKEP3R2d2RflA4vVQ6e3p9z/Onx6XrwqqahAuFNa8LMEjEoHab8vqBLvM85MeVs/U2h/iVAvzDF8CJQseIzdbSkwPTft4k0X+lO4iSgvPZzE5cGUBDJ1+0WZSvvm+mcJunpB99QREQpUdU+FdNkYqCxn3340erRREWnUbiQ4l+40DddakGZkI7FifhzJesh+jJNZYoPNFPNUHxDVegOFXeFoWygJLujam7yvRxkyBxcokg3TEtyos5qcek3xD14SODX5Vx9v/lgrL6dERWpW0uKin6u3U8XzqF631HiKB5RRFqhel+BkePZztldPBk0pd1iiId7PbZpNL/BedH927smJ2Ri5+zmYVmfkbth8dwDjk33ToVAAxrg x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39850400004)(346002)(376002)(366004)(136003)(9686003)(52536014)(8936002)(33656002)(6916009)(91956017)(66946007)(76116006)(66556008)(66446008)(478600001)(66476007)(64756008)(71200400001)(8676002)(55016002)(2906002)(7696005)(83380400001)(6506007)(786003)(316002)(86362001)(186003)(5660300002)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LPvv2zAVZnk9Q+sddkjWDuj6gE323EcvGZrAhlRCyPjVL5FMxIOgNIMXlIfUyBXiBKpAyT0nnBjhOnVz98+qzbpaGhcezVZ0oQxge1E1F/rHUBULdIU7uFN+s6yRvivPqBDwRb0FHlWuIFagE9AVJdmNB+vx7treJZkdnpumGOyG8LUFTwFXFQpLtF8KEcaJ378he1aghCnjQrTP5ubUKoTWadBXWGvGdRBPF9ivpJmMlbl16o6fAAOAtSw+K3Eksr41GReAP11bqJrBGXy59JeK99oP2Ie7Z5m0OV64iRs7n16bbQDJKLQnBL4pmZu2/a8fXItk9lbxTx1nkoSw4QPYsEwRlTSnt/21APRQ7Muy7gGqXAlzaz/wqT2GAXH+vrLlktB6/zDI2ZJz196kUMossCqCts44gPKRIvmls8FbwJACYUWypCzT/8tx3+U1uVHKiW0Sm7nKt/e43oyyO67zx/TLx9w2N+ZHM54z0rMcN4L6A5A4+bOT5K52axczVUAzWCFsAvIyIbEXZsfwd1jOXg5YumtaPnLlT83ePnqGFdDYJtXe2RUZykp9d0Cm/Dbkhia79z7/GX9r/8S8PSwR4N6N1uEFfTe2RmOjFjXQ6vAWraWiWgTBI2KN5QUYAQIA5PgGttlE0zjIHEie/nFC/X4jFiQXrpLV1VK5qHWidj+3QS/SXyF6x+NzRw42e64CCbWuaE7pp0+FyhYKow== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 82113675-84be-44a0-9281-08d841faf316 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2020 15:42:14.8117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7dRZFen7ezVZN2/KC3KxGGZUHeVAk8FRlMUSRgsaBBfH7d5V6doRbnDaBgGqBkvJ1F+TVt6nTbMXcM9VJE0c9A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3847 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597592545; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=Y+Mj0yX8Md8yV487PU6wzIxBIA6VlRwCxGAWs2Yza/Q=; b=UIVONiMjLKL2CqMqOf9rsnbUh/kBYbuBhpypqvt7Z8ATUxXVxhMm1FwnVErjDUBq8EThk6 4hgsh4/wDhzxLe5fqditTYb10m0T3EFGxKeZr8Oc3UEkAjFGs7l3g6XsKla6CevknlR9Se xXV+mFmlsgtrG3+gQFIl0d4vCb2bwfcAWEPWXngTa5isedIPUVE+n4L1gE5CtkC/mVeYV0 phoGdwEy+IB/4LxRKS7I0diWlBR6xq72Qy41ijsOZc7hNV788pR2OdV5svDOlpO+gdjydU YMgO1XF3fpXT4bxh1SjXa31BqvyDlDocT8QOc+yH2jRI8YER2lV9wyUzGh+SHQ== ARC-Seal: i=2; s=dkim; d=freebsd.org; t=1597592545; a=rsa-sha256; cv=pass; b=xCvVpnqKWGkYZ8CYQuiECZ3wJtKe4sg+Eecu1apwfQvYzqa4xFZIR+mlxmKzwitlXZdGsF n2urzNl4OcntgM67gnswlfecudgVD/jAhqaVu/wAx8pKpmxfKP5/BfZmwMLlzmO6l8giEh v8r6m2Hg5OSXqclPDMYkjeDb2R72OLSoVI9p9tEdqzrN5gJ0HTVDLlWSO/i52Y49VQGeGi j9mhfjSKJSWHxQs4pX+57eEG8to+Sjw92BRVgNqE5kTmxO9O2Q9J37brLIf63LXfdozCHX JjciUT6sqOLMspLnoV+JfCYToGNgrTfajnNt3Mj7kMt4MfZmz6kEBvVLFuF9Tg== ARC-Authentication-Results: i=2; freebsd.org; dkim=none (message not signed) header.d=none; freebsd.org; dmarc=none action=none header.from=uoguelph.ca; X-Rspamd-Queue-Id: 4BV1dY0Vn4z4W05 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.74 / 15.00]; NEURAL_HAM_MEDIUM(-1.02)[-1.024]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=2]; DMARC_NA(0.00)[uoguelph.ca]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-1.24)[-1.243]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.76:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.973]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.76:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 15:42:26 -0000 Hi,=0A= =0A= I put D25923 up on phabricator a little while ago.=0A= I clicked on a couple of people that I thought might like to=0A= review it.=0A= =0A= However, if anyone else would like to review it, please do so.=0A= The review is as much about the concept as the actual implementation.=0A= =0A= Thanks, rick=0A= =0A= Here is the description of it...=0A= The kernel RPC cannot process non-application data records when=0A= using TLS. It must to an upcall to a userspace daemon that will=0A= call SSL_read() to process them.=0A= =0A= This patch adds a new flag called MSG_TLSAPPDATA that the kernel=0A= RPC can use to tell sorecieve() to return ENXIO instead of a non-applicat= ion=0A= data record, when that is what is at the top of the receive queue.=0A= =0A= The code could use any error return that is not normally returned by=0A= soreceive(). If some other errno is preferred, that can easily be changed= .=0A= =0A= I also put the code in #ifdef KERN_TLS/#endif, although it will build wit= hout=0A= that, so that it is recognized as only useful when KERN_TLS is enabled.= =0A= =0A= The alternative to doing this is to have the kernel RPC re-queue the=0A= non-application data message after receiving it, but that seems more=0A= complicated and might introduce message ordering issues when there=0A= are multiple non-application data records one after another.=0A= =0A= I do not know what, if any, changes will be required to support TLS1.3.= =0A= From owner-freebsd-current@freebsd.org Sun Aug 16 17:20:06 2020 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 29AA43C19A3 for ; Sun, 16 Aug 2020 17:20:06 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV3pF17bxz4Zh6 for ; Sun, 16 Aug 2020 17:20:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 752172606EA; Sun, 16 Aug 2020 19:19:57 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> From: Hans Petter Selasky Message-ID: <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> Date: Sun, 16 Aug 2020 19:19:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597598405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q1Z5wN0ZgVp2v4etw8weTDW++Jogi3/fBfn5kXskagI=; b=rn3UYm2zFCJ81o/OTK/dVZHcAhjP58tMaabHNoBDH0PjBZhDCxXGtr+BckiQoKD/+mW+yb LfTK5WLOFY8kPJrz9Jn8q8KlDQx1G2qCqMmC6HnUUgm5ZbmwJvk8dFNamwaJOrrShneZlU I83Ri5pWgmiPFNjabnpeoSjMiPQtFERj+nHsg3dtW2QG+sYujQ6EThuZZajvOwy2XTSEP5 O69VJ0D4YjkRoy4wHv7EotEjTkSNVNTVUTKBMjcysBJq1aWxmOY/oXmhth3Gp44hAodTpO CnFJs3aZ8uUf3sjMSfNsLBff9DNFu5XThd1fX0qu3XbUNMOGmUgJBkP+AKX+Wg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597598405; a=rsa-sha256; cv=none; b=ShWuJ9xPnK4ob7zR/8mcXoa+AoiCsgS11R0Ku/vTAzA0nb/MGs2VjEFXuf5t+SI5PhakWX Bwvge1x03EonGHCL0sjH8ddC2tOGLzK2QcsfzyJVqiHKaFLmeRMJS0wQykBPHPUq6P7s5F qMe5JKfH42AlhYBNu4MHSoyjpXqURdTl+dUlgIeN8PsoHIf3FXat3mM6hwItHq76PIs7cg Svzh4SFEfI4b0SMe++oY3cfozTlF5+MizNV+TJCZKhLkKI9G3duPBffKEtmDNy691LcEQc w0BqR8kPCKXgOCTFW0QgIvUm+gLKULga1/R6IpqsUSE+OT+P0GhmYew34PzxYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=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-Rspamd-Queue-Id: 4BV3pF17bxz4Zh6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-0.98)[-0.975]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.44)[-0.438]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; FREEMAIL_TO(0.00)[gmail.com]; 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 17:20:06 -0000 On 2020-08-16 17:28, Alexandre Levy wrote: > Now at intel_freebsd.c:193 (frame #17) the driver calls > vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL). 'm' is the page grabbed from > vm_obj of the calling frame. Can you check if "m" is NULL at this point? --HPS From owner-freebsd-current@freebsd.org Sun Aug 16 18:50:00 2020 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 0BAD03C380F for ; Sun, 16 Aug 2020 18:50:00 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV5ny39Z0z3RQj for ; Sun, 16 Aug 2020 18:49:58 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07GInr31019718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 16 Aug 2020 14:49:56 -0400 Date: Sun, 16 Aug 2020 11:49:52 -0700 From: Benjamin Kaduk To: Ronald Klop Cc: freebsd-current@freebsd.org Subject: Re: dma fails to connect (error:1408F10B:SSL routines:ssl3_get_record:wrong version number) Message-ID: <20200816184952.GZ92412@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597603799; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bE1e/RF3Qq7iUaXVM1WEV6gzN9JVI5su1uUSwzgdacg=; b=vOvCTYqfhCeGRbjmmtqfTLSJ7XiPBlNQPjNCP0JATmKKQDcBbKl6NM7wnkeImjzKdZ+OgN lRkcxWwSDyjoOjekmvor2J5CgbFOPBGsx4YL/NCUHr6W1nhz5C/WRBFs2UMGTOaMKpQ/V2 VX8RA8bVIFYNOM9HBdXj+dOZzFUYOW3QtzeLNq8Tx9e1th3dX8x4M1lvVD7B9Q7FnyPxgM NOQuSHrSH9CoNVzhNsoJ7T1tqwzyalKrQsfJvpq19L9JvIkpL4XlwCRM/rT+N6+Boyic4e jtpEHQPqXmZpmYGd+UQ8hqYDb5IT+yo56L2Ar2VjY62j5d0ve+1vqRk5OvD/vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597603799; a=rsa-sha256; cv=none; b=CYtB1ZutuZLOtRCz8jMovhocPVO3Mjqn2tZJGGqGoHX2MkkBxiHon0fupXHXyBtmHOw0GF 18kSTxReBmgvEEcG4AHhPqEsWkXyoVFGGpX7cES3hJg7rG+buvtdqHkIT4JJF6eLDcyNoM JIy40EvUg8o8cQn+gltezF/vfEOjSopb0loL/yEMmJOErHMJ4aK4c3X5MZBTfVG7TCPSP8 JS7yQv3Vtj5hvJjHV+6EmmWtnXlHfweKw7BbWi4NkwAAXsJS+EfW4bBllBEq5XZbfX5cxo N2750oB9G5Qp4pSN/kK8dLihKmzqyZro16uBR1fh8jvr6Xd0VEJ8xUrJCCrPEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Rspamd-Queue-Id: 4BV5ny39Z0z3RQj X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.051]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-0.99)[-0.987]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[mit.edu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.876]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_VERYGOOD(0.00)[18.9.28.11:from]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 18:50:00 -0000 On Sun, Aug 16, 2020 at 04:44:51PM +0200, Ronald Klop wrote: > Hi, > > I have uname -UK -> 1300101 1300101 in my laptop. This uses libexec/dma as > mail agent. > I have 2 jails running uname -U -> 1300101 and 1300104. All dma configs > are the same. > > In all 1300101 versions dma can deliver mail to my smarthost. On 1300104 I > get: > > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: trying remote > delivery to smtp.greenhost.nl [213.108.110.112] pref 0 > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: > SSL_client_method > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: remote delivery > deferred: SSL handshake failed fatally: error:1408F10B:SSL > routines:ssl3_get_record:wrong version number > > Any thoughts on this? > bisecting this will take me hours and hours of compilation IMO bisecting is not the fastest approach. "ssl3_get_record:wrong version number" sometimes means "you tried to speak TLS to an endpoint that's doing plaintext", but if it reflects an actual TLS version mismatch, a packet capture should make it clear quite quickly. Note that openssl upstream has been gradually ratcheting the default settings towards a more-secure state, so if your peer is only using TLS 1.0/1.1, non-AEAD ciphers, etc., a local upgrade might result in a failure to communicate with the default settings. -Ben From owner-freebsd-current@freebsd.org Sun Aug 16 18:52:11 2020 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 960363C3857 for ; Sun, 16 Aug 2020 18:52:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BV5rT1JCDz3RhJ for ; Sun, 16 Aug 2020 18:52:09 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1k7NlF-0007cC-UX for freebsd-current@freebsd.org; Sun, 16 Aug 2020 20:52:07 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-current@freebsd.org Subject: (solved) Re: dma fails to connect (error:1408F10B:SSL routines:ssl3_get_record:wrong version number) References: Date: Sun, 16 Aug 2020 20:52:04 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.4 X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, BAYES_50, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF autolearn=disabled version=3.4.2 X-Scan-Signature: 12f61b0c8dc8dcc8c992b8e1fde77987 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597603930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=S5gQsrpMUkcLQlZa7PrVYk8vOM/aRUrEtHz8Xg1L5bo=; b=n9XTLjcnYdeaA/IKmJXdEZb3B6wgrmHw9OOJV7A3bhEI6f7wYhhdFREYD24jdLiEi0K3Nu ZJs+HAktJq8OtOw+rvb0GJUeXQg78iqX3DSvjdMUZj0X3nKtAbMyrHA+PS5Xk7TKZuYe6K 7xpMW1eYQ8WtYEGeVWxqML2oaSa1o0pffw8HZ8nsoeY43gD2u1aj4tHXAXb67cx58Q2o1x nNsJA+YcWKjM+3oJV1xyVpEGQkS2WgHETQaRTHXEUS3FB3YF42rTzFbXbdr0YiwBu5CXke SLmcO5IvSO5l9VL8lo+5zjqIxz/ug8q2+s4DoQvI/2imVkiBnmrO2Iu402wqXg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597603930; a=rsa-sha256; cv=none; b=bEFXxOwkIuORFo+iBBIxfO38JzVC8UDPmNPuk/N08U07JgXulrSkmmnzv/acEl7HqcL8dl KAZqIZPoLahpkETWkT8E6cQKYBbtFwOqypnlYq8PLA0+4Ou5IkP/NLMsK++hghg3GjPRut M27UnrGpLZO2jH6tPYexiZJ/tW+bCwScwiFG3js3Qg4LO66QoQ8yCuH1AbehVSUEMq2PUa WQaIp1tCVuQAt/SRwxpyA90/XGL5mPsuWPBrVMy7HeP5ieYb5QX5oQHy3l0hI7Id2cmic6 1Lk86QLpBmoN7aPQq2YhyuCIdp+xQKAhEqRWY9MGmnn9twIfUq9iKLX9hasPxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=OaqKNaTd; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Rspamd-Queue-Id: 4BV5rT1JCDz3RhJ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[195.190.28.88:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.974]; DMARC_NA(0.00)[klop.ws]; DKIM_TRACE(0.00)[klop.ws:+]; NEURAL_HAM_SHORT(-0.28)[-0.281]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 18:52:11 -0000 On Sun, 16 Aug 2020 16:44:51 +0200, Ronald Klop wrote: > Hi, > > I have uname -UK -> 1300101 1300101 in my laptop. This uses libexec/dma > as mail agent. > I have 2 jails running uname -U -> 1300101 and 1300104. All dma configs > are the same. > > In all 1300101 versions dma can deliver mail to my smarthost. On 1300104 > I get: > > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: trying remote > delivery to smtp.greenhost.nl [213.108.110.112] pref 0 > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: > SSL_client_method > Aug 16 16:29:00 freebsd13_py3 dma[385ba.800e480a0][52169]: remote > delivery deferred: SSL handshake failed fatally: error:1408F10B:SSL > routines:ssl3_get_record:wrong version number > > Any thoughts on this? > bisecting this will take me hours and hours of compilation > > Regards, > Ronald. I found the cause of the error with ngrep. My jail has an underscore in the name and the SMTP EHLO command complained about it. But the error handling in dma does not handle this error properly if STARTTLS is enabled, so communication with the server goes wrong which results in STARTTLS getting weird results later on. I proposed a fix upstream and will rename my jail to not contain an underscore in the hostname. https://github.com/corecode/dma/pull/87 Computers and all the time consuming little bugs. Arrgh. Ronald. From owner-freebsd-current@freebsd.org Sun Aug 16 20:23:21 2020 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 47E503C519F for ; Sun, 16 Aug 2020 20:23:21 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BV7sg6LQhz3WKY for ; Sun, 16 Aug 2020 20:23:19 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id x5so11692464wmi.2 for ; Sun, 16 Aug 2020 13:23:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xhZd/0cWFEMM1H7MnCCemvAGF4VVSqmtXNAnouH9ju8=; b=j6yWmutmHL3u2Hxbpqw2LguMin0OuaUGE4CQcQXcNE57qqJ1StIdtBneZh4kQ+Ghn1 dyEdBPXYeY7wsQ0egScgmwn+X0CcfMcFV18SOaEiFvG380fbk0wNgsBev3mUj020nxVU tCOhRRZnqlEyF9zRsskMRjVYDHnuksL/VZ5y3/jJ3o6hPTI1IAIaBGzsToOTbkNkb0SG ZQk6Rd60N4nuJp2O3CXkcqy6FGa+eF+z5aMRCIoPoyw9bI1I4cbgB5UBpund1y/PFpT3 Q28EL+XINaFdHHeC5oEkpazXtb36BGUGt7ckcOb3WQym59o9r+FurmmU2/rDNT9FyLuC JzFw== X-Gm-Message-State: AOAM533sWrlYCZDgoVDhqBL/cKnxsSOGI0TVLpXYsOWt8qD3fJCbNWUG DX8jlPPIGJqczdMLxJxFWzm24Y+IsN2T8ZPaAo4= X-Google-Smtp-Source: ABdhPJyMcPtU5eGfzQJ5A3VrDwciC7PpMGXyGilRZPCHqPNRPtdK4N3hpoHYhJXT/isrp2czrfjzn1S0i2LhVqoAM+M= X-Received: by 2002:a1c:4104:: with SMTP id o4mr11858591wma.101.1597609396911; Sun, 16 Aug 2020 13:23:16 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> In-Reply-To: <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> From: Alexandre Levy Date: Sun, 16 Aug 2020 21:23:05 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597609400; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xhZd/0cWFEMM1H7MnCCemvAGF4VVSqmtXNAnouH9ju8=; b=ZQdOFTwI1KWXdsNZ+A/aXbIb6s20svOq5yviRtE7z3ZDub6qxcEidt/WLLjYVCKJZl6Sy0 K6OQxn90pjgM5ixPgzX+zIK3T0tgjBN4zHrG1EL+zeoVX2oNiKKio5zm/luiJBUPS7XlkL d09L1p3qfn/VfS+bHc90iS9YPlzND4TiZgQcfLqzsDbu539Tqqlyk34/eZgTpOBSFYGbq4 8JRf/1r/HQ4SYAbKalGJosawZLikLDjXI+dbYEQi6AwKfsSGNRsMquSBbLwedTGCwTghOO mh2h4OlmvUytqH05cGjPxvB5eYgwqn39RUn8Er3uc4HFmHj0sCZUIJm0bgy09A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597609400; a=rsa-sha256; cv=none; b=STMGce6i6ccwfOKY7VSTSBhw8EtLhejkxkvP/bApapLgeKZITJJlWZ82ZqXQ9syp15Ocr2 IZEs73eSpio7Ye5ymMKYX6kmZGr1m1SU0vVrE+Mz3UUJ1b2xjv7qzmSr3GR9ZYnNC2s/40 qHww6/UjzQZfIFv6u1BHlf31f+6HLcqbnqO6PEQxMqsAvAmOd/R3pVH1OA6Y0Oz3dCmzpv cZdtfR4Mc+MmxAfvB/4SI83nm7SM3RHZKl+hXyJDN7Kk8qS/i7kMjnxiaO2irHrh2QI5aT ZzFOPXX0cOBJEwajerP9gbcZbsoaNJtEFKKaoeq9BwQD837xMvwq97Y2OxQZZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=f2pqGtge; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::343 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Rspamd-Queue-Id: 4BV7sg6LQhz3WKY X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.050]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_SIGNED(0.00)[i=1]; NEURAL_HAM_LONG(-1.02)[-1.021]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::343:from]; NEURAL_HAM_SHORT(-0.63)[-0.633]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sun, 16 Aug 2020 20:23:21 -0000 "m" is not NULL : (kgdb) frame 16 #16 0xffffffff80ec23ed in vm_page_busy_acquire (m=3D0xfffffe00040ff9e8, allocflags=3D16) at /usr/src/sys/vm/vm_page.c:884 (kgdb) p *m $2 =3D {plinks =3D {q =3D {tqe_next =3D 0x578491b51dd60510, tqe_prev =3D 0xd78c11bd9dde8518}, s =3D {ss =3D {sle_next =3D 0x578491b51dd60510}}, memg= uard =3D {p =3D 6306325585301210384, v =3D 15531808720989095192}, uma =3D {slab =3D 0x578491b51dd60510, zo= ne =3D 0xd78c11bd9dde8518}}, listq =3D {tqe_next =3D 0xd78c11bd9dde8518, tqe_prev = =3D 0x265bc92017d7aa38}, object =3D 0x2659c92217d5aa3a, pindex =3D 2758957463725517354, phys_addr = =3D 2758957463725517354, md =3D {pv_list =3D {tqh_first =3D 0x2e49c1321fc5a22a, tqh_last =3D 0x3e4bd1300fc7b228}, pv_gen =3D 265794104, pat_mode =3D 1046204704}, ref_count =3D 257405624= , busy_lock =3D 1054593440, a =3D {{flags =3D 4757, queue =3D 48 '0', act_cou= nt =3D 134 '\206'}, _bits =3D 2251297429}, order =3D 98 'b', pool =3D 204 '\314', flags =3D 75 'K', oflags =3D 105 '= i', psind =3D -107 '\225', segind =3D 18 '\022', valid =3D 48 '0', dirty =3D 13= 4 '\206'} I had to recompile drm-devel-kmod with make WITH_DEBUG=3Dyes DEBUG_FLAGS=3D= "-g -O0" because "m" was optimized out. I then started a kgdb session with the same crash dump than before, loaded the module symbols with add-kld /boot/modules/i915kms.ko and I now have a different backtrace from frames #17 to #28. Also the panic doesn't occur when I plug a screen to the HDMI port (which now works for some reason...) and I can see the frame #17 is now the following : #17 0xffffffff82b4e980 in intel_plane_can_remap (plane_state=3D0xfffff80315148300) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/display/intel_display.c:2583 and used to be : #17 0xffffffff82b4e980 in remap_io_mapping (vma=3D0xfffff80315148300, addr=3D, pfn=3D, size=3D, iomap=3D) I don't understand why the backtrace changed although the crash dump is the same as before. Any suggestions ? Le dim. 16 ao=C3=BBt 2020 =C3=A0 18:19, Hans Petter Selasky a =C3=A9crit : > On 2020-08-16 17:28, Alexandre Levy wrote: > > Now at intel_freebsd.c:193 (frame #17) the driver calls > > vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL). 'm' is the page grabbed fro= m > > vm_obj of the calling frame. > > Can you check if "m" is NULL at this point? > > --HPS > From owner-freebsd-current@freebsd.org Mon Aug 17 08:03:04 2020 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 787AF3AA1EC for ; Mon, 17 Aug 2020 08:03:04 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVRP32Wd8z4Lh3 for ; Mon, 17 Aug 2020 08:03:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5C3A82602CF; Mon, 17 Aug 2020 10:03:01 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> From: Hans Petter Selasky Message-ID: Date: Mon, 17 Aug 2020 10:02:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597651383; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UQnuXkOVYoDL/JvZ1R0/Zzn1yW5FNKMKkU+S3eFsuo8=; b=WgW9nPBdkeFbhsRnPFFhtTt8tcx48xasNvjbxHCR+QbA8ZIz3GR8duXtSwJUXb8fR2Tj4r 2LEBxO1mmx3pbrn2YVNoxAPgKLGscCxM9ZiUBDsDFSEtvT6OPy5pSpoM6rE0P1NDmzgap9 y5H70NWIuMG/gXu9YyMLOmi3CP5Nj+/uaxgd9FlH3l4Yf+bn0TZQ/PHpTJ7pvP98oJjrEr ra2VQPe4UKgHoo0GO7h0m6PUiSQbOPm+LOEHHdqMm73o73JexDLGSUxmaNyCmYlcaWwBfM zRUuR/0c/tn6oV/1BVcZdka9/7JV6CZmesEqORud7DWUnzFzEHg73F0kRN5Vqw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597651383; a=rsa-sha256; cv=none; b=X4QKsc7fkEfUBefG8hddNz6q2yR8cWiZez40YckRjrqq7piRrTUVdDFZV1svdOkqMC1f9D H2Txc4/VFSTt18PU1Iwa7XFSDYvcQYyy+CvR7s1I/Q8+M4fZ9XxfR0FB4podnF4RnyWHuC p0/fncbUQnZjkTGCFGKX6jLT/irCKmtYwFJ/hBUPIWydPJ0ut3Lwl67u530uvJX4Hd5Fnx SWLaUzqmShQjw4px1KjohRaliphjBeYrg7z+bXe1sTVfOVTSL1d5hMv+9tZ0KYD9mjNHS4 eviutb5M2y5a2M5q/hjcXSogwiObIv1kAqvugI0pjXXUn6xr2fzJxc29ibTaRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=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-Rspamd-Queue-Id: 4BVRP32Wd8z4Lh3 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.20)[-0.200]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.03)[-1.026]; FREEMAIL_TO(0.00)[gmail.com]; 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 08:03:04 -0000 On 2020-08-16 22:23, Alexandre Levy wrote: > (kgdb) p *m > $2 = {plinks = {q = {tqe_next = 0x578491b51dd60510, tqe_prev = > 0xd78c11bd9dde8518}, s = {ss = {sle_next = 0x578491b51dd60510}}, memguard = > {p = 6306325585301210384, > v = 15531808720989095192}, uma = {slab = 0x578491b51dd60510, zone = > 0xd78c11bd9dde8518}}, listq = {tqe_next = 0xd78c11bd9dde8518, tqe_prev = > 0x265bc92017d7aa38}, > object = 0x2659c92217d5aa3a, pindex = 2758957463725517354, phys_addr = > 2758957463725517354, md = {pv_list = {tqh_first = 0x2e49c1321fc5a22a, > tqh_last = 0x3e4bd1300fc7b228}, > pv_gen = 265794104, pat_mode = 1046204704}, ref_count = 257405624, > busy_lock = 1054593440, a = {{flags = 4757, queue = 48 '0', act_count = 134 > '\206'}, _bits = 2251297429}, > order = 98 'b', pool = 204 '\314', flags = 75 'K', oflags = 105 'i', > psind = -107 '\225', segind = 18 '\022', valid = 48 '0', dirty = 134 '\206'} This "m" structure looks freed. It looks like a use after free issue. Can you enter this in GDB: set print pretty on Then dump some more structures you can get hold of? --HPS From owner-freebsd-current@freebsd.org Mon Aug 17 08:46:22 2020 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 D32693ABE6E; Mon, 17 Aug 2020 08:46:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVSLz1cZ9z4PZH; Mon, 17 Aug 2020 08:46:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 13e3ea02 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 17 Aug 2020 08:46:09 +0000 (UTC) Date: Mon, 17 Aug 2020 10:46:08 +0200 From: Emmanuel Vadot To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: DRM Project report (week of August 10) Message-Id: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597653982; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=MuSiw7hwRy8VIDzQ7TYDtKCdixFci0W6hLTiSZI0Ez8=; b=vlV1tUwCmBNdsYm5VHJ7K/2mbyWBXAEL8Vn3l4i20NRv0kdDo+Y0CBRYk5msofmGNENzxK YRBZpp9+WOIl20KC4ztdS/TjaO/ehBxBmNJrASGYrLR+jyR6KkKgUiH3QDNqshJfPU8PFD +iVbeknr+IihGAWWlPa/DkQqEI0VlznESA4mWpqiUQ8L0Di3ui1GMnGV1Ly+T0L/5r70Le hbZnUFqsBsXKbVf0b6V1TxlbWmPj9kkVIU6x5LfJy9xVOjfVF3wHxzsMJuBARlGYXrnLII VTTpQ7N0j5y8lVdIJ8aaOd1iZy+jWVOV/HzoJXdsKIZP7UZ71c+IkeAPTTddtg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597653982; a=rsa-sha256; cv=none; b=Goa/sm+mRtv2AMDVM6JcTYpLkc99HF64Khkr//HFp1KFJMpIs2u1GHdchu9YVXqvovpTIr 9i81v1nPpMmeNXr3coMpn24+Z/IsDH2UsMbGcgArwOF+Mn9kE10pE5L0O/LO7eZ+2ufcpj nRkAC1x8lXpJpNSgUYe9OrZS0N+rqi7GxC/7+r7YW7urHv8hfNc6Ra2OKux2BBXfdJHNzA rz4anyWydVDQhBZF7W4xyMoL15NEUsBpKlRsK+ycRGTyX6HXtXmoUx+X2hogi4CmsHepSf yjsM6D2AV7100WSBMfA+e4JqurGtkoTTW2lbr5u70wYEbC7oDiZEr2SK9DdjfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=pXf3lB8d; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Rspamd-Queue-Id: 4BVSLz1cZ9z4PZH X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.01)[-1.010]; NEURAL_HAM_MEDIUM(-1.05)[-1.051]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.37)[-0.374]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 08:46:22 -0000 Hello, 5.4 was finilly reached ! For AMD users it means that Navi12/14, Arctarus and Renoir should work. For Intel users it means that TigerLake should work too. No ports update for now as I want to give current users a bit of time to update their base (as the ports needs recent addition to base linuxkpi) but if you have a current >= 364233 you can test directly the master branch of https://github.com/freebsd/drm-kmod/ I plan to commit the port update at the end of the week, and probably at the end of the month we will switch drm-current-kmod to 5.4. It's now time to do 2 main things : - Update stable/12 so it have all the needed code to run 5.4 - Remove the remaining GPLv2 code to start thinking of import into base. I'll also start producing some usb image so people could test latest current with 5.4 on their machine and starts reporting bug soon (this is needed for making 5.4 default on 13-CURRENT and later 12.2). All this work is under sponsorship from the FreeBSD Foundation. -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Mon Aug 17 09:39:34 2020 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 E788D3AD722 for ; Mon, 17 Aug 2020 09:39:34 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BVTXP5kwwz4Skf for ; Mon, 17 Aug 2020 09:39:33 +0000 (UTC) (envelope-from a13xlevy@gmail.com) Received: by mail-wr1-x444.google.com with SMTP id 88so14293876wrh.3 for ; Mon, 17 Aug 2020 02:39:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=njOXHXSmxytb+ad8FkxG6KFvvZ4u0yFzaDb+Ag5mdfM=; b=NuCRt2EsXf91aJPegkIjkFsod6upLlvPtZMIDTWxndQtT6xdzk8K/i/JzGLUgV0m5N Hh1gfUDSohKC1g0sAxVZIlxf+Afq7edN2GQs8HWtRCDHqAACPBVNWU3FjltjYPe6c7ym H1Xni/DmvkfbhXRCd6XaQvjLGtwp7bn+luiVouk8lXE5XloaS8ul6medT/JUndfC+YjJ fZPHNF7SFwKp41BgP4ONIMgHobLecgfzp4YBU/QMz/9sRS1+ugQ9W9LzN8GOo02og9Wr BbHNmDQ9xfZmMqlxhYDXyrc4uvzXGQD0FcN5IdK/BuzqxsX0ggeLKOhL2fNUit7DMrw4 FdOg== X-Gm-Message-State: AOAM5302AZFitDWkAZIORKYZThQbi1hx/RIpOwBBZ6JkZKQQMMNPx+td S4xHmY8cFdrIfjjvVBSSBdhoHQZNpsIxccMG3DAB3AGS6t1OlQ== X-Google-Smtp-Source: ABdhPJzdYn0D/g7xWybHnQGplziHE96E6TXqcTY8PaX3DtCkPfGMzNEY4asxagb/ozUw3TtODhsGDh9uUSYZeIsowmo= X-Received: by 2002:a5d:6589:: with SMTP id q9mr1373423wru.383.1597657172176; Mon, 17 Aug 2020 02:39:32 -0700 (PDT) MIME-Version: 1.0 References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> In-Reply-To: From: Alexandre Levy Date: Mon, 17 Aug 2020 10:39:20 +0100 Message-ID: Subject: Re: Kernel crash during video transcoding To: Hans Petter Selasky Cc: freebsd-current@freebsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597657174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=njOXHXSmxytb+ad8FkxG6KFvvZ4u0yFzaDb+Ag5mdfM=; b=jNABeryHIQuBI1pJBcUs4G5ihsKALwwArcUSFurY79ZDpMTm2sRbKctmMtd8HuXhwgZkk5 1Nf3rHMFVqeZurx98GX6+08rgNfHMiceya3I8ADlu5lIhfsjuVMuImB3/mp1jWjSPNcFis 7eWSHyaQyrsATiDI8177KSCUT0HQSxulcp4CT7e6KFi5DH1pbLeQXrQaZX4XsqgluHz0wf 6V5BbPFYy/xzHTiyeRgaf6sHnW7wUNWDqemkXLLM1S6sNem+eWpPdWnYrhrW/7YjEShgyW XB0fLpT68bc6k2afnCOTMgr1b0vDCxSsP5ng8D/Db9KbEZOiyNNHZnx3crR/SQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597657174; a=rsa-sha256; cv=none; b=ItF18HeTzd3O+O8jEU/3XeoBu2uqQZCtiG9tLAoupagazSctKjWxNtJc4FByo3DwFKFlop 1CKUZ+DCU3exekwvtvj9SK0tEdUX9TNUuANIgTbL3/pO8VkhiSnaL5VtSRu5NoQ+YYqXZP d33u3Ozc3qI8suRa8sbd/6l70XVnZeFjpf97wnAPMKzMC7RlsM/jvNb7o5eA88qatdgXva Au76UIkt4eVPOz21R/pTKIA5CcciwoeB9D96tHQrvGTt+Slz2u1qmpaL3flgDzrP1SrNdb 5gVgRWcRLXW506Dse37TvBtQ2Ihd8yNx/2duLmTR0UZOv2YHfVfBdJRIVr6ERQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Vy6gQQPQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of a13xlevy@gmail.com designates 2a00:1450:4864:20::444 as permitted sender) smtp.mailfrom=a13xlevy@gmail.com X-Rspamd-Queue-Id: 4BVTXP5kwwz4Skf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.048]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_SIGNED(0.00)[i=1]; NEURAL_SPAM_SHORT(0.18)[0.180]; NEURAL_HAM_LONG(-1.02)[-1.019]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::444:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 09:39:35 -0000 For reference, below is the backtrace then further down I printed the structures I could access : #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff8049c26a in db_dump (dummy=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff8049c02c in db_command (last_cmdp=3D, cmd_table=3D, dopager=3D1) at /usr/src/sys/ddb/db_command.c:= 482 #4 0xffffffff8049bd9d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff8049f048 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80c1b374 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:699 #7 0xffffffff8100ca98 in trap (frame=3D0xfffffe00d7567300) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=3D0xffffffff811d5de0 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:486 #10 0xffffffff80bd00be in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:902 #11 0xffffffff80bcfe53 in panic (fmt=3D0xffffffff81c8c7c8 "\b\214\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:839 #12 0xffffffff8100cee7 in trap_fatal (frame=3D0xfffffe00d7567600, eva=3D0) = at /usr/src/sys/amd64/amd64/trap.c:915 #13 0xffffffff8100c360 in trap (frame=3D0xfffffe00d7567600) at /usr/src/sys/amd64/amd64/trap.c:212 #14 #15 _rw_wowned (c=3D0x2659c92217d5aa52) at /usr/src/sys/kern/kern_rwlock.c:= 270 #16 0xffffffff80ec23ed in vm_page_busy_acquire (m=3D0xfffffe00040ff9e8, allocflags=3D16) at /usr/src/sys/vm/vm_page.c:884 #17 0xffffffff82b4e980 in intel_plane_can_remap (plane_state=3D0xfffff80315148300) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/display/intel_display.c:2583 #18 0xffffffff82be1c5f in skl_ddb_get_pipe_allocation_limits (dev_priv=3D0x= 0, cstate=3D0x1, total_data_rate=3D18446735292251509792, ddb=3D0xfffff80368501= 438, alloc=3D0xfffff80315148300, num_active=3D0xfffffe00eb0b6c58) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/intel_pm.c:3928 #19 0xffffffff82cb5ddf in ?? () at /usr/src/sys/compat/linuxkpi/common/include/linux/kref.h:68 from /boot/modules/i915kms.ko #20 0xffffffff80ea9e8f in vm_pager_populate (object=3D0x2659c92217d5aa52, pidx=3D18446741874754451944, fault_type=3D0, max_prot=3D0 '\000', first=3D, last=3D) at /usr/src/sys/vm/vm_pager.h:172 #21 vm_fault_populate (fs=3D) at /usr/src/sys/vm/vm_fault.c:= 444 #22 vm_fault_allocate (fs=3D) at /usr/src/sys/vm/vm_fault.c:1028 #23 vm_fault (map=3D, vaddr=3D, fault_type=3D, fault_flags=3D, m_hold=3D) at /usr/src/sys/vm/vm_fault.c:1338 #24 0xffffffff80ea98ee in vm_fault_trap (map=3D0xfffffe00c0f539e8, vaddr=3D, fault_type=3D, fault_flags=3D0, signo=3D0xfffffe00d7567ac4, ucode=3D0xfffffe00d7567ac0) at /usr/src/sys/vm/vm_fault.c:585 #25 0xffffffff8100d0de in trap_pfault (frame=3D0xfffffe00d7567b00, usermode=3D, signo=3D, ucode=3D0xffffffff81d1= de80 ) at /usr/src/sys/amd64/amd64/trap.c:817 #26 0xffffffff8100c72c in trap (frame=3D0xfffffe00d7567b00) at /usr/src/sys/amd64/amd64/trap.c:340 #27 #28 0x000000080296659a in ?? () (kgdb) frame 24 (kgdb) p *map $35 =3D { header =3D { left =3D 0xfffff802b72c4060, right =3D 0xfffff803681965a0, start =3D 140737488355328, end =3D 4096, next_read =3D 0, max_free =3D 0, object =3D { vm_object =3D 0x0, sub_map =3D 0x0 }, offset =3D 0, eflags =3D 524288, protection =3D 0 '\000', max_protection =3D 0 '\000', inheritance =3D 0 '\000', read_ahead =3D 0 '\000', wired_count =3D 0, cred =3D 0x0, wiring_thread =3D 0x0 }, lock =3D { lock_object =3D { lo_name =3D 0xffffffff81183cec "vm map (user)", lo_flags =3D 36896768, lo_data =3D 0, lo_witness =3D 0xfffff8045f575780 }, sx_lock =3D 1 }, system_mtx =3D { lock_object =3D { lo_name =3D 0xffffffff81136b96 "vm map (system)", lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0xfffff8045f575580 }, mtx_lock =3D 0 }, nentries =3D 172, size =3D 199905280, timestamp =3D 792, needs_wakeup =3D 0 '\000', system_map =3D 0 '\000', flags =3D 0 '\000', root =3D 0xfffff803686b1c00, pmap =3D 0xfffffe00c0f53b08, anon_loc =3D 34366283776, busy =3D 0 } (kgdb) frame 15 #15 _rw_wowned (c=3D0x2659c92217d5aa52) at /usr/src/sys/kern/kern_rwlock.c:= 270 270 return (rw_wowner(rwlock2rw(c)) =3D=3D curthread); (kgdb) p/x c $14 =3D 0x2659c92217d5aa52 (kgdb) up #16 0xffffffff80ec23ed in vm_page_busy_acquire (m=3D0xfffffe00040ff9e8, allocflags=3D16) at /usr/src/sys/vm/vm_page.c:884 884 locked =3D VM_OBJECT_WOWNED(obj); (kgdb) p *m $16 =3D { plinks =3D { q =3D { tqe_next =3D 0x578491b51dd60510, tqe_prev =3D 0xd78c11bd9dde8518 }, s =3D { ss =3D { sle_next =3D 0x578491b51dd60510 } }, memguard =3D { p =3D 6306325585301210384, v =3D 15531808720989095192 }, uma =3D { slab =3D 0x578491b51dd60510, zone =3D 0xd78c11bd9dde8518 } }, listq =3D { tqe_next =3D 0xd78c11bd9dde8518, tqe_prev =3D 0x265bc92017d7aa38 }, object =3D 0x2659c92217d5aa3a, pindex =3D 2758957463725517354, phys_addr =3D 2758957463725517354, md =3D { pv_list =3D { tqh_first =3D 0x2e49c1321fc5a22a, tqh_last =3D 0x3e4bd1300fc7b228 }, pv_gen =3D 265794104, pat_mode =3D 1046204704 }, ref_count =3D 257405624, busy_lock =3D 1054593440, a =3D { { flags =3D 4757, queue =3D 48 '0', act_count =3D 134 '\206' }, _bits =3D 2251297429 }, order =3D 98 'b', pool =3D 204 '\314', flags =3D 75 'K', oflags =3D 105 'i', psind =3D -107 '\225', segind =3D 18 '\022', valid =3D 48 '0', dirty =3D 134 '\206' } (kgdb) up #17 0xffffffff82b4e980 in intel_plane_can_remap (plane_state=3D0xfffff80315148300) at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm= /i915/display/intel_display.c:2583 2583 if (plane->id =3D=3D PLANE_CURSOR) (kgdb) p *plane_state $18 =3D { base =3D { plane =3D 0x0, crtc =3D 0x300000, fb =3D 0x100000, fence =3D 0x1b, crtc_x =3D 104451, crtc_y =3D 0, crtc_w =3D 734353152, crtc_h =3D 4294965248, src_x =3D 3949985792, src_y =3D 4294966784, src_h =3D 2193719064, src_w =3D 4294967295, alpha =3D 30720, pixel_blend_mode =3D 64271, rotation =3D 4294965250, zpos =3D 0, normalized_zpos =3D 0, color_encoding =3D DRM_COLOR_YCBCR_BT601, color_range =3D DRM_COLOR_YCBCR_LIMITED_RANGE, fb_damage_clips =3D 0x0, src =3D { x1 =3D 0, y1 =3D 0, x2 =3D 353665888, y2 =3D -2045 }, dst =3D { x1 =3D 1750078496, y1 =3D -2045, x2 =3D 0, y2 =3D 0 }, visible =3D false, commit =3D 0xffffffff82cc3370 , state =3D 0x0 }, view =3D { type =3D I915_GGTT_VIEW_NORMAL, { partial =3D { offset =3D 0, size =3D 0 }, rotated =3D { plane =3D {{ width =3D 0, height =3D 0, stride =3D 0, offset =3D 0 }, { width =3D 0, height =3D 0, stride =3D 0, offset =3D 0 }} }, remapped =3D { plane =3D {{ width =3D 0, height =3D 0, stride =3D 0, offset =3D 0 }, { width =3D 0, height =3D 0, stride =3D 0, offset =3D 0 }}, unused_mbz =3D 0 } } }, vma =3D 0x0, flags =3D 0, color_plane =3D {{ offset =3D 0, stride =3D 0, x =3D 0, y =3D 0 }, { offset =3D 0, stride =3D 0, x =3D 0, y =3D 0 }}, ctl =3D 0, color_ctl =3D 0, scaler_id =3D 0, linked_plane =3D 0xfffff80315148500, slave =3D 353665024, ckey =3D { plane_id =3D 4294965251, min_value =3D 3735929054, channel_mask =3D 3735929054, max_value =3D 3735929054, flags =3D 3735928833 } } (kgdb) p *plane_state->linked_plane $19 =3D { base =3D { dev =3D 0xfffff802f50d3910, head =3D { next =3D 0xfffff80315148400, prev =3D 0xdeadc0dedeadc0de }, name =3D 0xdeadc001deadc0de , mutex =3D { mutex =3D { base =3D { sx =3D { lock_object =3D { lo_name =3D 0x28274 , lo_flags =3D 5, lo_data =3D 0, lo_witness =3D 0x60 }, sx_lock =3D 3907697 } }, condvar =3D { cv_description =3D 0x0, cv_waiters =3D 50644 }, ctx =3D 0x3336663265336563 }, head =3D { next =3D 0x6433633439633264, prev =3D 0x3131623462353561 } }, base =3D { id =3D 912548663, type =3D 825506101, properties =3D 0x61632e3436656c2d, refcount =3D { refcount =3D { counter =3D 761620579 } }, free_cb =3D 0xdeadc0dedead004b }, possible_crtcs =3D 3735929054, format_types =3D 0xdeadc0dedeadc0de, format_count =3D 3735929054, format_default =3D 222, modifiers =3D 0xdeadc0dedeadc0de, modifier_count =3D 3735929054, crtc =3D 0xdeadc0dedeadc0de, fb =3D 0xdeadc0dedeadc0de, old_fb =3D 0xdeadc0dedeadc0de, funcs =3D 0xdeadc0dedeadc0de, properties =3D { count =3D -559038242, properties =3D {0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de, 0xffffffff825f20c0 , 0xdeadc0dedeadc0de }, values =3D {16045693110842147038 , 18446744071601856704, 16045693110842147038 } }, type =3D (DRM_PLANE_TYPE_CURSOR | unknown: 3735929052), index =3D 3735929054, helper_private =3D 0xdeadc0dedeadc0de, state =3D 0xdeadc0dedeadc0de, alpha_property =3D 0xdeadc0dedeadc0de, zpos_property =3D 0xdeadc0dedeadc0de, rotation_property =3D 0xdeadc0dedeadc0de, blend_mode_property =3D 0xdeadc0dedeadc0de, color_encoding_property =3D 0xdeadc0dedeadc0de, color_range_property =3D 0xdeadc0dedeadc0de }, i9xx_plane =3D (PLANE_C | unknown: 3735929052), id =3D 3735929054, pipe =3D -559038242, has_fbc =3D 222, has_ccs =3D 192, frontbuffer_bit =3D 3735929054, cursor =3D { base =3D 3735929054, cntl =3D 3735929054, size =3D 3735929054 }, max_stride =3D 0xdeadc0dedeadc0de, update_plane =3D 0xdeadc0dedeadc0de, update_slave =3D 0xdeadc0dedeadc0de, disable_plane =3D 0xdeadc0dedeadc0de, get_hw_state =3D 0xdeadc0dedeadc0de, check_plane =3D 0xdeadc0dedeadc0de } Le lun. 17 ao=C3=BBt 2020 =C3=A0 09:03, Hans Petter Selasky a =C3=A9crit : > On 2020-08-16 22:23, Alexandre Levy wrote: > > (kgdb) p *m > > $2 =3D {plinks =3D {q =3D {tqe_next =3D 0x578491b51dd60510, tqe_prev = =3D > > 0xd78c11bd9dde8518}, s =3D {ss =3D {sle_next =3D 0x578491b51dd60510}}, > memguard =3D > > {p =3D 6306325585301210384, > > v =3D 15531808720989095192}, uma =3D {slab =3D 0x578491b51dd6051= 0, zone > =3D > > 0xd78c11bd9dde8518}}, listq =3D {tqe_next =3D 0xd78c11bd9dde8518, tqe_p= rev =3D > > 0x265bc92017d7aa38}, > > object =3D 0x2659c92217d5aa3a, pindex =3D 2758957463725517354, phys_= addr =3D > > 2758957463725517354, md =3D {pv_list =3D {tqh_first =3D 0x2e49c1321fc5a= 22a, > > tqh_last =3D 0x3e4bd1300fc7b228}, > > pv_gen =3D 265794104, pat_mode =3D 1046204704}, ref_count =3D 2574= 05624, > > busy_lock =3D 1054593440, a =3D {{flags =3D 4757, queue =3D 48 '0', act= _count =3D > 134 > > '\206'}, _bits =3D 2251297429}, > > order =3D 98 'b', pool =3D 204 '\314', flags =3D 75 'K', oflags =3D = 105 'i', > > psind =3D -107 '\225', segind =3D 18 '\022', valid =3D 48 '0', dirty = =3D 134 > '\206'} > > This "m" structure looks freed. > > It looks like a use after free issue. > > Can you enter this in GDB: > > set print pretty on > > Then dump some more structures you can get hold of? > > --HPS > From owner-freebsd-current@freebsd.org Mon Aug 17 13:42:24 2020 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 4F2DE3B2F93 for ; Mon, 17 Aug 2020 13:42:24 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVZwb0JN7z3T0S for ; Mon, 17 Aug 2020 13:42:22 +0000 (UTC) (envelope-from ohartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from freyja ([79.192.165.151]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MC30P-1jy4Th1vsz-00CO6c for ; Mon, 17 Aug 2020 15:42:20 +0200 Date: Mon, 17 Aug 2020 15:42:12 +0200 From: "O. Hartmann" To: freebsd-current Subject: ld: error: duplicate symbol: Message-ID: <20200817154208.42d25b89@freyja> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:wCa0KkxGT12saeBWtIEndDUFU9i55+kx/ADsZkkOjBO+Pazg1w6 QyzzRHbkBoDGIe8LSFLGsNrc8G4TpgbxpyLZj9BZt+Kgl4eFCydEo2FrJI3+A4BSVlHwEHp 9ZDUHn9wB/YTyAwqM2a/55lBfkj968tBDOaOuQiUheVQhftayzoxuGP5pUB3pB3a7dQK+Nu R3dgb9CsOBkoqgSm60lRA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ajvbgP2Mhek=:XTVIr3tGLA4bNGxs4lELsO 4BA0aMnmHaMM7MQph7CkR69Y+JX6m2zIw3UvCyOGxdfuVQb3C1jZNwSTCSFC9qcKMkBB1+ksB 0jZcaEQ1IytSdSQTQznzPwH1kobTRGn1nXrO79+UahMmv5K5B4vS2PdpXnOa2pa+s5548yxJQ 8Eru4SPeuS5/FaNgPFjprjsgstQe2CrqXo2VU8g/xrpzAy27HJJ91UW9nFRcL0Wre/S7/mOQi XQb9ZJJpFYwp0wXhnTBhwcxuuhOBmh2tTauBuR7QYCJUHZ5q51RJ/pOCdmxHW0l8Bo4tKfTy7 IjbZL20TJQxQV0h/IeFnUgx+fIlecjdouAkVF38IWIJ9FVFbPNK4ALCSpaOtOXiw7lrdGvRcU idqWk0TE9H7bscW4zA6UkgYIlFHu2r3JBGOViy5F+G0ynvQQPFNoYWU0pawlUh2eaDnZf/ECr tVhVLmfe/p7Er525lTBx5F4aRQKliaDLfWHPw2N7D90fq/gDKsTpph2M80sAane3zPfzY8dl6 mkCHW17sTi+PIfVQ+N7/g0Fv7F+PX6NhiZRPGi6prJcSkLD01bIwekL0nGjEeMMYvfBwN1xpB vxENNisocK85xGigpgaKntjkbIes84W++FX+w6e9PR0O36w8mIEDzdhCeLmq/JBjQCk4FbCi+ isPZ4fFwKDJLWGy/QofJ1BXZLRqFILL9YrzUzd4XAnfe4bbLTUJhzDnbe41huEgmY4aL43aU3 /rLUM5eX1RD1ibab0JKs21g/1KlDkMJVazYwiU4L2nqZqWOfFkrtp8yHnsYnaB3c4LYuBssIS 8zyoG9D0Pl0lU9KG6wbyqt3ncVb0Iv/rJCe35KkMDLh6Cc+yxLQpKmpIPjhmf2FddINAwXNyG 6+CaCSQDjlb7ZZjCgFrFZLZLRiu05FrYh5QKE84DVnYp+Anw/4JaVZlvUywEES+XyvYyBsDLm j5ULq6wcil9+xvVgqg8ACwLqoyYQdgTu22j6dQ4KebduhDELu1IgajrABOkFa4jslBT9t/TIp MHARAeCNILOL9wP56ZOTL0xENIo5yMYVCy5ubU3Bh+LVZU4aIwZnqZrKoqE6kr5WxGxGwgPY+ B6UsDy9RW5TIFXKpoi7DSdRcMrQ9oNFBp7JrAaUHP0ahqhd6K+wj1cTUTg0CptC/XXDAoGJho vDgRTdEJLUVo9sfw7RjOuGkK1zOm9bQIA92DOxgGtY9WMoQXZf5ZCZoJ50G2oqAhaLL9nr+gQ 8UX4LbB1i8PRFFS3qEKwI9T0inF/wRMEGkj4lPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597671743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=TBy6xSN5ue1uuSOfktbnLxuVAv7fPIqZrbnrAsJ+4qw=; b=rXVTEZ+O9ylcx5Z5uaxXDKQPLCae7Jqdm44ytOUEmIx4NlpLqIBIOEBgcSv2iFI0UuCoV+ +cszW0OAJ/31fg28/ZTJiBB4sUeGv3c6MIozN2k6owEPdvUA1cGhcv8974dE68nv0xmCyX uW9hlVg9l0OAiH/oKJlfk8xyEjpgMDy1PvzKLK4Ww6EW3c6UYAQqmqb0Bza7SYlc5TgRaC p4M7aUFDr26nWRadxa8a2qQIodI0YqZdVzhC+7zjzFVcNveApYv+Tgk9E/J2Khgz63hRGF PTal09RjUuadq5FyxZUACylwmQqMHdYjyGRyjPJGJ3OlRt+j4cLuSmSD2V/eOQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597671743; a=rsa-sha256; cv=none; b=k5IePcCKYgxfKGxueOx0JbXWvB3urg+sfnXVk2Hy4hVbFqbiNsF3A04splEV1FAYP0Xd9p QaW2sArri8jTjqDgUaCiD8uho9YrpdMIP6FBeF23NW5YT6vn2UhX1n81lMzDk0jhnvILjA b1AmtIGJYflGgAbPRWuy7wHGqBYPop8PrXQFH8OgVmF+7P2AeSxJQwZt5qXxtSdoaHHh8e CayYhJCmhiT/9Sa1d5bw1xoDiNQ6dEHlfoRWDfhVU+gIhlCfFMBJm8hKizE1AomqO1z7mj ThvLEFM4CWhFXdsCBmpgyrC3nh6VRI6hDRn8HfB3neYFBffCqukEbglLoGdlrQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=C8AFzqB0; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.17.21) smtp.mailfrom=ohartmann@walstatt.org X-Rspamd-Queue-Id: 4BVZwb0JN7z3T0S X-Spamd-Bar: - X-Spamd-Result: default: False [-1.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.21:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.74)[-0.743]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_SIGNED(0.00)[i=1]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[79.192.165.151:received]; DMARC_NA(0.00)[walstatt.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_HAM_SHORT(-0.23)[-0.231]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.21:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 13:42:24 -0000 On CURRENT 9not necessarily most recent with LLVM11, but since noon of tod= ay it is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) = I'm faced with some very sticky and nasty micompilations in several essential ports, for instance ports-mgmt/pkg devel/libunwind devel/binutils In most cases somewhere in the (parallel) build the process fails with the= error ld: error: duplicate symbol: xxxxxxxx As a result, several ports or even the rebuild of the whole installed port= s fail to compile/recompile. Compiling port devel/binutils, for example, fails with this error message = from linker: [...] cc -DHAVE_CONFIG_H -I. -I. -I./../include -I./../elfcpp -DLOCALEDIR=3D"\"/usr/local/share/locale\"" -DBINDIR=3D"\"/usr/local/bin\"= " -DTOOLBINDIR=3D"\"/usr/local/x86_64-portbld-freebsd13.0/bin\"" -DTOOLLIBDIR=3D"\"/usr/local/x86_64-portbld-freebsd13.0/lib\"" -isystem /usr/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wsha= dow -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 -frandom-seed=3Dmremap.o -pt= hread -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -MT mremap.o -MD -MP -MF .deps/mremap.Tpo -c -o mrem= ap.o mremap.c mv -f .deps/yyscript.Tpo .deps/yyscript.Po libtool: link: cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -fstack-protector-strong -o coffdump coffdump.o coffgrok.o bucomm.o versio= n.o filemode.o /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib ../bfd/.libs/libbfd.a -L/usr/local/lib -lz ../libiberty/libiberty.a mv -f .deps/mremap.Tpo .deps/mremap.Po ld: error: duplicate symbol: program_name >>> defined at coffdump.c >>> coffdump.o:(program_name) >>> defined at bucomm.c >>> bucomm.o:(.bss+0x0) What is going wrong here? Thanks in advance oh From owner-freebsd-current@freebsd.org Mon Aug 17 14:56:24 2020 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 5C17E3B45F3; Mon, 17 Aug 2020 14:56:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BVcYz3sjDz3XbD; Mon, 17 Aug 2020 14:56:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id g14so17981533iom.0; Mon, 17 Aug 2020 07:56:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/8u6yha/+pWlpr/PCtJmzLBV3IbriCkHe8Y7OB7HLPk=; b=tJhC2oMEYscL+gG8bA6msCEG8+L5bXz2LIk/kOLGdDy/WUTeReZQJbpaEl2Dfo7f+e 1tnh6fl+MO/5W/KIiJ/6rhIcnQb1nkD0x7O5AJvc2PW6e9qoEVwZMyIIM5Hzb5KVFKM2 zHUHYTJgdV0+XNgg8G1GfdP0mboKWeM9gRCSPNJFC1MPloPTh57uBKYPAJ75LqCr6n6u lemPvtcZxLdLbeR0CbOQ0FAx/mgDm5WeGcXhYu/rRUMp+3Ju8magCrvRUMgkmbEMzrlm eWxvMYaN/yY+rNVKN8hmlLa3PUeQN8cmX8gwrh0s0wDrqhz0/CnUyR2sW1z+TiYPQyiO JRMw== X-Gm-Message-State: AOAM532SkmgwrQEHYU3eFkS89NG2fERgLc1558vGTGH0zT6MWf93Rb6A tkvwjwHHTyBn3tHIc10I1KdGxmdx1bKTDtiRhftTox4/l7o= X-Google-Smtp-Source: ABdhPJwWs3wineVotNiutax9fOKyx2Vp/fX5sMus1puJWVUXuzyN0xKWCRllDrZa3MNIvvZJFKjg/Z1URq5tF+0dbfs= X-Received: by 2002:a5d:8a04:: with SMTP id w4mr12648645iod.15.1597676182392; Mon, 17 Aug 2020 07:56:22 -0700 (PDT) MIME-Version: 1.0 References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> In-Reply-To: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> From: Ed Maste Date: Mon, 17 Aug 2020 10:56:08 -0400 Message-ID: Subject: Re: DRM Project report (week of August 10) To: Emmanuel Vadot Cc: FreeBSD Current , freebsd-x11@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597676183; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/8u6yha/+pWlpr/PCtJmzLBV3IbriCkHe8Y7OB7HLPk=; b=D041CyN03qIrJNphaxHMosTOV9nvHcH9fABEcvfEam0DPJrmGO3Me2HqIpJlAU+HnW3kHH VsSIROgfEc726/Uz8noulaJJca63+BfH6kblNPyY9ktIDfshP4Y/yjdxto3W+ofdGcp6NI A2d5LX13r6U5KBCOpATovS92ZNQKPFakSL/l64eum10PmBEvfVD/dGC42YK1D9K/t0sIEp 12smPifPXRcUlca2alY+uYCOq9/MM7Li56v/0Ln/R4/YuzeokcZZGuMdL9eW/olH46ubpk 2GSTVqMhZ7pSmH1FOA1wgS5g4QmfX7vE2ZQyvTRm4qZ8kIHWjD2/b8K3qgzoeA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597676183; a=rsa-sha256; cv=none; b=popBHhzB1WtOqKHRUdBI640Wu2+2Mgr9FAheMaZC4WRb99sJzpnLzTyC6gTKonfIRBRi+4 GRqlyopaX9+YCZFKiL2p/oU3i/yApaWNd/9IkzJFds207t4qHhIZ9hg1Le7oybS3lMHuHl yF6/w/A1I9pP8SRG6u6AcQpUEM8vLT7XbKWLe9fszcUm+sdiJJgoNG0yaq1t98NT4/yDbr EbA2vaqdaFX6ImpvdiAKdGEdASp1OrSBSdXdAtkgoxpVygDKfwjWT8PNyePVB79zIMN0+t tYYQE1TmLWP4viLMSgdT0XmReZJgRntk7ltZaXPKrikcyVBqwYmT73zbSZY6dA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Rspamd-Queue-Id: 4BVcYz3sjDz3XbD X-Spamd-Bar: - X-Spamd-Result: default: False [-1.97 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.81)[-0.811]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.22)[-0.216]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 14:56:24 -0000 On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot wrote: > > - Remove the remaining GPLv2 code to start thinking of import into > base. How much GPLv2 code do we have left now? From owner-freebsd-current@freebsd.org Mon Aug 17 15:48:14 2020 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 B1BFD3B5A5C; Mon, 17 Aug 2020 15:48:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVdjm6grfz3bkF; Mon, 17 Aug 2020 15:48:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 9c82604f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 17 Aug 2020 15:48:09 +0000 (UTC) Date: Mon, 17 Aug 2020 17:48:08 +0200 From: Emmanuel Vadot To: Ed Maste Cc: FreeBSD Current , freebsd-x11@freebsd.org Subject: Re: DRM Project report (week of August 10) Message-Id: <20200817174808.a4ec90d06b684f5d5867b505@bidouilliste.com> In-Reply-To: References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597679293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eAcSbGEYrGVq0w1hRv7BSBkMJFFfl5pDCNA2oVrtba8=; b=RKtSHGxJd+/tLmay6vKLAkR9G3SwuRz69Y3kgZXABJrPxUScGD4nWQieIH3Q8oxaHiAyOp ow+PIP3xE4NvCcJ5BMUTClXsGjgbSghY51BjvSaDyelGfw4L/lPomfyRDs+6+HyYuC4F63 gpq+KsQwJ50uHM29oApEcdWuRLoMLNTjt91wlmqNoaNHlU3aH/xfdTct+oK4EF3IYVwdsH RT0gPsj1LpPuMIcHFfWFP86l9RcV0BeCeWVxqTSC6k92vwL2CG7KGlAdZ91ykJmC427cqo Cf9hlyp73/8USDUrk3VIkxX+LXWZaBT1jOXXVv4Z8/Hj7m1wUfuTwyqBkoo8xw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597679293; a=rsa-sha256; cv=none; b=Lr+ghTvx4wteXo91S8NrNy4ReEkAD85CGtr1lER1JJOFOgWkhctvavQv5QPQUdGWnAQFm2 I8cVS/lwHLOH4sgl4Djvwq3ej+RI++lh8adGk3Ar7gWzNf7z32WlWnoPIb8HAaK7HRG8h/ YSyHu6BgE9YPySC1NaH2CBS/GqDK6GabRcjrcQ5S68ljiJFMuFYVvpLapmnj5i0I/YUP/k 9N5z9loJ+pnJV1jByKQL/9wGGyN1dRF5D4BNdN20FDhiDdGJNLyVxlU2VBloCLEjahFz/X 1+Bw063Rb0+WpmNLWMiSD2LQ0PIAYDtgi77/HUMCTgFBmA/+eZnwd3ozMcNb8A== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=a0gmT+KZ; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Rspamd-Queue-Id: 4BVdjm6grfz3bkF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_SIGNED(0.00)[i=1]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.032]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.91)[-0.908]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 15:48:14 -0000 On Mon, 17 Aug 2020 10:56:08 -0400 Ed Maste wrote: > On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot wrote: > > > > - Remove the remaining GPLv2 code to start thinking of import into > > base. > > How much GPLv2 code do we have left now? ~50% of what's in https://github.com/freebsd/drm-kmod/tree/5.4-cleanup-lkpi/linuxkpi/gplv2/src + the includes + all the dma-buf. I have some dma-buf in my drmbase branch for arm that will help. > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Mon Aug 17 18:17:04 2020 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 565413B8C64; Mon, 17 Aug 2020 18:17:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVj1W1TR5z4384; Mon, 17 Aug 2020 18:17:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.160] (cpe-23-243-161-111.socal.res.rr.com [23.243.161.111]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 8b08d5d3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 17 Aug 2020 18:16:56 +0000 (UTC) Subject: Re: DRM Project report (week of August 10) To: Emmanuel Vadot , freebsd-current@freebsd.org, freebsd-x11@freebsd.org References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> From: Pete Wright Message-ID: Date: Mon, 17 Aug 2020 11:16:56 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597688223; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GODx2K4YPOtOd22Ye3fX1RD2ZlhfBZ0pyyMfRteufmY=; b=Vq7Q4KhDY85YVgx318OM62lU4ONfz+/CfTbNQaGd5wX+o8fcjHkQE8oYYfSxcznAN3Aczr xb2+QLQWKExgCYomtUub8Dz+TAIaP8v+F0+knUtZHo0+Eae5GLgi9ZHjSU8zkCk89FWwJR E3ekBW0uUh3p0I7jCeowdUic3UrWdnDMODmx7h5egy+vZoj1o0Pj3m0EgNoKF9tG2jNQ0E q7Pl6j6L3BmGHVPwzEHZVhIXd+PhDiWcgoA8FyeaLcQ22ky/VYHhBuE1SQB+6tW8DPULZi ZDRKr029YtrnWkEHvIlLpFELtEJGOYhyKzDZi1mYQLYvWVUAgUbbgPFXBJZuMw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597688223; a=rsa-sha256; cv=none; b=JmbIqmsQW5g9lCoLAg2QcalxQs/22Kj7V6RSktvoZLMzyBxtjAjCr12bfJxN8RuRYp5Kiy /GCPuSMsrlogyq/SOuo4YGqCfq0jujpdbpn7bcV4Fdk5c6UKbG1mDZ+pwfAUqhdkpCkYmO paHKqN7futccQHKxvSpmoEQQlD0N5xq9pftD2LmcywvbZgQHlC9C6Y9x4CE9HsjaKdEnFM TkNJCs1tWXPw9tNPblJd5MHypdjghsm0Fgjyd9Nvc/FJDwwW3BoVtpLuDpjZQ4iI5dCEQP kvlsV3PVtjjxp1Kag3hM0FuGJjB2N1R18jywEKp6XBkmz7hd341sJ17OCt9/Ng== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Rspamd-Queue-Id: 4BVj1W1TR5z4384 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.58 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ARC_SIGNED(0.00)[i=1]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-0.99)[-0.988]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.27)[-0.274]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[23.243.161.111:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 18:17:04 -0000 On 8/17/20 1:46 AM, Emmanuel Vadot wrote: > Hello, > > 5.4 was finilly reached ! > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > For Intel users it means that TigerLake should work too. > > No ports update for now as I want to give current users a bit of time > to update their base (as the ports needs recent addition to > base linuxkpi) but if you have a current >= 364233 you can test > directly the master branch of https://github.com/freebsd/drm-kmod/ > > I plan to commit the port update at the end of the week, and probably > at the end of the month we will switch drm-current-kmod to 5.4. thanks Manu!  would it make sense to make this version available in graphics/drm-devel-kmod now to make it easier to test for people who update world/kernel more frequently? -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Mon Aug 17 18:44:43 2020 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 BC17E3B97A8; Mon, 17 Aug 2020 18:44:43 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BVjdR4fkDz44lB; Mon, 17 Aug 2020 18:44:43 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 88070156F9; Mon, 17 Aug 2020 18:44:43 +0000 (UTC) From: Jan Beich To: Emmanuel Vadot Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: DRM Project report (week of August 10) References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> Date: Mon, 17 Aug 2020 20:44:38 +0200 In-Reply-To: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> (Emmanuel Vadot's message of "Mon, 17 Aug 2020 10:46:08 +0200") Message-ID: <4kp1-5cyx-wny@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 18:44:43 -0000 Emmanuel Vadot writes: > Hello, > > 5.4 was finilly reached ! > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > For Intel users it means that TigerLake should work too. > > No ports update for now as I want to give current users a bit of time > to update their base (as the ports needs recent addition to > base linuxkpi) but if you have a current >= 364233 you can test > directly the master branch of https://github.com/freebsd/drm-kmod/ > > I plan to commit the port update at the end of the week, and probably > at the end of the month we will switch drm-current-kmod to 5.4. > > It's now time to do 2 main things : > - Update stable/12 so it have all the needed code to run 5.4 > - Remove the remaining GPLv2 code to start thinking of import into > base. Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS) doesn't require more LinuxKPI changes? For example, when drm-v5.0 was the latest I've played with grafting linux-4.19.y only to discover some commits had to be reverted due to missing LinuxKPI bits. From owner-freebsd-current@freebsd.org Mon Aug 17 19:50:02 2020 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 2BCC83BAB08 for ; Mon, 17 Aug 2020 19:50:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVl4p0QFwz48l8; Mon, 17 Aug 2020 19:50:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id D235A22AFB; Mon, 17 Aug 2020 19:50:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::a4a4:6252:6b98:209] (unknown [IPv6:2001:470:7a58:0:a4a4:6252:6b98:209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6F2FB63940; Mon, 17 Aug 2020 21:49:59 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1529C6A4-08C1-49E7-AD79-13FCD66B077C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: ld: error: duplicate symbol: Date: Mon, 17 Aug 2020 21:49:52 +0200 In-Reply-To: <20200817154208.42d25b89@freyja> Cc: freebsd-current To: "O. Hartmann" References: <20200817154208.42d25b89@freyja> X-Mailer: Apple Mail (2.3445.104.15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 19:50:02 -0000 --Apple-Mail=_1529C6A4-08C1-49E7-AD79-13FCD66B077C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Aug 2020, at 15:42, O. Hartmann wrote: >=20 > On CURRENT 9not necessarily most recent with LLVM11, but since noon of = today it > is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 = amd64) I'm > faced with some very sticky and nasty micompilations in several = essential > ports, for instance >=20 > ports-mgmt/pkg > devel/libunwind > devel/binutils >=20 > In most cases somewhere in the (parallel) build the process fails with = the error >=20 > ld: error: duplicate symbol: xxxxxxxx This is because clang 11 (and gcc 10) now default to -fno-common. The rationale is explained pretty well in = : "GCC currently defaults to -fcommon. As discussed in the PR, this is an = ancient C feature which is not conforming with the latest C standards. On many = targets this means global variable accesses have a codesize and performance = penalty. This applies to C code only, C++ code is not affected by -fcommon. It = is about time to change the default." A quick fix is to add CFLAGS+=3D-fcommon to your make.conf, but that is rather a big hammer. It is better to add it to just the ports that show problems due to duplicated symbols. And ideally, those duplicated symbols should be patched out of the ports. For example, ports-mgmt/pkg already has such a patch: = https://github.com/freebsd/pkg/commit/7fbde60c4af4a1a07db7c5c36efbb2a495f7= b1a4 but I have no idea why it is not yet in the ports tree. -Dimitry --Apple-Mail=_1529C6A4-08C1-49E7-AD79-13FCD66B077C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXzrfYAAKCRCwXqMKLiCW o088AJwKKg9W9U6t6218YUAfeAHJD9rxDgCgnRZOpfw2fx0vWI3SBSJfpD64W/Q= =GhpO -----END PGP SIGNATURE----- --Apple-Mail=_1529C6A4-08C1-49E7-AD79-13FCD66B077C-- From owner-freebsd-current@freebsd.org Mon Aug 17 21:18:58 2020 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 AD8843BC7C5 for ; Mon, 17 Aug 2020 21:18:58 +0000 (UTC) (envelope-from moridin@mm.st) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BVn3Q2rPPz4HhX for ; Mon, 17 Aug 2020 21:18:58 +0000 (UTC) (envelope-from moridin@mm.st) Received: by mailman.nyi.freebsd.org (Postfix) id 5FAE83BC8B0; Mon, 17 Aug 2020 21:18:58 +0000 (UTC) Delivered-To: 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 5F7383BC993 for ; Mon, 17 Aug 2020 21:18:58 +0000 (UTC) (envelope-from moridin@mm.st) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVn3N6Gbxz4HbZ for ; Mon, 17 Aug 2020 21:18:56 +0000 (UTC) (envelope-from moridin@mm.st) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C402CC5C for ; Mon, 17 Aug 2020 17:18:54 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 17 Aug 2020 17:18:54 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtgedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpehmohhrihguihhnsehmmhdrshhtnecuggftrfgrthhtvghrnhep fffffeehiefhieehgfeiledtjeevfedtgfelueduieejuddvudffjeeuvddvkedvnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhorhhiughi nhesmhhmrdhsth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 014B36680078; Mon, 17 Aug 2020 17:18:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786 Mime-Version: 1.0 Message-Id: <45283d79-b061-4c8e-b788-8145b9c694a6@www.fastmail.com> Date: Tue, 18 Aug 2020 00:18:33 +0300 From: moridin@mm.st To: current@freebsd.org Subject: =?UTF-8?Q?"panic:_malloc(M=5FWAITOK)_in_non-sleepable_context"_when_inse?= =?UTF-8?Q?rting_usb_stick?= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597699137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: dkim-signature; bh=LSzborQZuN9dYCvyKEZwGw2hqrlmQv2LecJB61TBPXQ=; b=id8EiqHeomjwHKf9mWb+D78mFnkdtxIEE6b0RS7oeEZd92TZH8YRo/LHh6VeG0ywrynzHY SqpI6s8b4NjS4bP6XDkbJqIwKnPzU1b9YATPo/gAuAPmBveS0LTTQKNFliTNwh09UMPEKZ Qx/QlVKbLsAcJmtUlv9BwSGFsOEh/xnAGzo+y23Be3nDbdnqwm1Qof8/R5psvts9Lga1IB kGuC/qOEfgEkgEKa/QPWR1FLFKX7aNTLPrMBmlPH6LQ6AFcUV8gLgcWYOlJoxUlD3tLX4U Mmu6UhcGBZmK66iKkddU6uq7fUHD4/vEOQMmS0VGk52jNCQhNj+wvlQ3sKEutQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597699137; a=rsa-sha256; cv=none; b=k2pfNKqyP9FX8xQ+Yx0+bOP+dTJGkQ9ZQsGaAuw8cJw8c5YeT0A29hjtArDusOfg0CxyAd Xzwo0zReFA/TCvJOwAfEiG3ITmtlL430yC1QdkrbQsq3amNbFlhQSiXmBcaJppuDKgIJj2 RoEnbqVowoNyWpQ/otLqViS+Q1byCukJGh0bPVhmc9mzQsj2uAW38mCIjH46r/oldYpXL5 5KV6WNxjYMXwMVtoB8xOxEDa+1QqFdG2OeZJoH2RBZLGRQkhq70RHxZAf+FR5PQHtBJk5T fYjs9zKePakGkTCm3ukO20zlABPuHkvTBqJFSl9bIOW0gSpWccY8iePyzCAiOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=mm.st header.s=fm1 header.b=Nij6GArI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=kXVSNL0/; spf=pass (mx1.freebsd.org: domain of moridin@mm.st designates 64.147.123.24 as permitted sender) smtp.mailfrom=moridin@mm.st X-Rspamd-Queue-Id: 4BVn3N6Gbxz4HbZ X-Spamd-Bar: - X-Spamd-Result: default: False [-1.23 / 15.00]; XM_UA_NO_VERSION(0.01)[]; FREEMAIL_FROM(0.00)[mm.st]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[mm.st:+,messagingengine.com:+]; DMARC_POLICY_ALLOW(-0.50)[mm.st,none]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_SHORT(-0.30)[-0.300]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[mm.st]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; R_DKIM_ALLOW(-0.20)[mm.st:s=fm1,messagingengine.com:s=fm3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.038]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[64.147.123.24:from]; MID_RHS_WWW(0.50)[] Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 17 Aug 2020 21:18:58 -0000 r364323, previously I think it was just a warning from witness. Happens both on boot with stick already inserted, and when inserting the stick in booted system. Looks like my swap partition is no longer big enough for dump, translating from screen: umass0 numa-domain 0 on uhub4 umass0:2:0: Attached to scbus2 panic: malloc(M_WAITOK) in non-sleepable context vpanic() panic() malloc() disk_alloc() daregister() cam_periph_alloc() daasync() xpt_async_process_dev() xpt_async_process() xpt_done_process() xpt_done_td() fork_exit() fork_trampoline() From owner-freebsd-current@freebsd.org Tue Aug 18 03:35:08 2020 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 263203AC103; Tue, 18 Aug 2020 03:35:08 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BVxPR1nQLz4dhJ; Tue, 18 Aug 2020 03:35:07 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-io1-xd42.google.com with SMTP id h4so19821731ioe.5; Mon, 17 Aug 2020 20:35:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IU6Eu8WSwa2dkl5CqY95Rc6xYw35FiXaRB2bxXVFJlU=; b=AJzDVLnv6UJ3PIhEtz77Y69vldRynS2cDb8UXps67+SSRekfQ5dytFvNwmKKBThEUg pP0me/ppjyioYyqWrr8eBT1vVf6LIi86AxNCu8YmXssFTc+kfPyAeA4HgfEOaICON9k6 +LNA+zbqOV7jyCitR6Pu6kFSGYIB7p8vHcuv/35APymQDJmqJaDC/KQHGO2ahtO3X8Q9 4n3ZokpXbDdolm00ogIdlEJjm/Wv5glZfgmIeKF4fxPWVBm+cE1zlY6ztwEcBrnokMfs iXDRAiE3lX/xfjBZ6IXJeozybvD6qKXMOPeKv4gbXGW23TuUVlKJnJuODrMOLE3oGuUZ v4qA== X-Gm-Message-State: AOAM530JSu18I9L35RKP7yWFamgdmAnQZ14/gSN4V5o+D+cYSFFdBjwJ PzbdgLGcqGvFb97vMM5gg1HURFJ628LCBYcnyHvoorLzD3BrDg== X-Google-Smtp-Source: ABdhPJwR6kqBXMXXGgeG5n/43q7jteYhKbiZ6fnSXPY6nR3dWnTKDK26bNZIG6QcYmnPSn/fmCFezKn/WFJU8ZiRrdU= X-Received: by 2002:a05:6602:1616:: with SMTP id x22mr14977102iow.65.1597721704493; Mon, 17 Aug 2020 20:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9f16:0:0:0:0:0 with HTTP; Mon, 17 Aug 2020 20:35:03 -0700 (PDT) In-Reply-To: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> From: grarpamp Date: Mon, 17 Aug 2020 23:35:03 -0400 Message-ID: Subject: Re: DRM Project report (week of August 10) To: freebsd-x11@freebsd.org Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597721707; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IU6Eu8WSwa2dkl5CqY95Rc6xYw35FiXaRB2bxXVFJlU=; b=Ou975CSf2Z+l2tCW3AFyvANyQKpfkQr4bQpvKSMx2DZiPAoSeRZth3WzyqLifd/1v0PFDi QaSZnV55YzuRdLSZQYSs8VK72hGLc2FHQ1+EB64wCqHEpuGiBWLcKng+fHTFu5W1lPrbDP Pc5aXQdMx2TMj9aAYCyz18ixzDxuORNxxmxZZRmeTasfz2YJ2N7/cH2wpwCmogl2G3y+bX q7BK830Me7rAsl1aoKHKCpjGHEzHkGUF0b1huPf1uYcoPh2ha3UJG2EUBBU2Z5X0mbWycn 0ERxcmTsbzB1YBLapk723txyG6F8WNsHyX3XDO/zMVA9nawIjp/p6Dmi6z26mQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597721707; a=rsa-sha256; cv=none; b=g4E9riT86W0VNkue+Gnfco9EWCezDKVNnpTn6VgGhXJZNuQ8oAWIgifngvwcejSUFYNllp 8jR6MdEyFD7lvRi+BssVZpp1mMK7E7Os7pPqafuao59w3MRuNSvMtRBsFoeJIO8mNl9EKO mQv7bbL3cMJKqUGgAHALREyjKVkQjyFOSKt2At2ublShOi5Bg/Op5fnkgvBiulUYNB3z4n FwuFXSa06VZ0DyqnDdmtEiM7JTS4eFccAmrYb2Nsh0Cgp5wUUwzoNMS/2OrJuJNbFSWW5x UA4e8RjHrAMP+XNRjMlvZNB/0Q+mOHBV2LYCt+JmocxWc7LJBTXYB68K3oakNA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=BjbWGJcm; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::d42 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Rspamd-Queue-Id: 4BVxPR1nQLz4dhJ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.985]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=1]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.03)[-1.030]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d42:from]; NEURAL_HAM_SHORT(-0.15)[-0.155]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 03:35:08 -0000 Thanks go to all the ongoing teams working the things like gpgpu / compute, and graphics, whether on-cpu-die or on-pci-card. And even some things like BSD on Pinephone too. https://www.pine64.org/pinephone From owner-freebsd-current@freebsd.org Tue Aug 18 04:42:55 2020 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 B0CBF3ADE2C for ; Tue, 18 Aug 2020 04:42:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVyvf3N5Bz4j2s for ; Tue, 18 Aug 2020 04:42:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: i9qatKIVM1msp9JqfB6uriQXXIUIqzx4wboKZkLdmv0XBiuJmH62hvKrfLAK5mj 8eHiYNuSbN9PLq1BSLc9JesGY4F6nBkIv63fhJsC4rbxAHbgoBs2F_0kyT_yD_QQOj.tGQokki2v Ywr_wXFHa.62w.7AOEHwHX8TvXPQ2VueixBEtyVwzZq7peTV7s7NhuT_d3dSaoxzH4zyWCVCftDq GcwOTZh6aFZBWKLL.gPcHo9ATE96gxy5cKXkDKtbQM.ZAcAuz.2ohqYuuxGiahh71lOINzCmWQEa IVc_8PPfFL1.hZrOuNOz.SzJymFot3M0EDpbCBzc83822LC710bXAfp0Bz7W9ycBtc2UxElwdlOL 3NO8Ye5aePI58tC4HSjGsUhKhNS_EznIkLSy0_XiCIS03fgv807iiD1kAFwT7zYxPaXaUneQzn8J pcT3fwGPlHNkDua2lJb69zm494SPKiF3JJA8N5zSL0GTDM0sbmKjwiBbkeH_tShp2zlJ2utGKV_Q MKLi1gFYHwF3KicXwXc_p.XsUu8p_78jKg3JkJZV6eLAHpOH0bu4ZIReQ94q2dJaVyHMfrOOEX4r KMScUhWZrAr_QGA_7IgV3ye.YfsBcfVg3ih3o1EYTjYtszyRW46mbFHMIhTBWtNRbTrTJ.S6XBK2 jhjc5Br61Ds5SvTu4BogrCu.svr.PON_3zddJ8dybpOHCnDkTi_VUwryLOo4RNvMJeRcV_wEpcgl eF91Gp8sEDUiBUxdW3T4sQT0MF68SW07BBsYmf7IQZr0NGTV0XZEgSe2eu6DyHu5gNPfPQtHuOHU Ek7B2tLY26iEl1nGIuE46L5iEuh1JMiplx.f6q4lmEsrczwUBOEQ20i5ssPeGBA61FjqC1httw1V bTcDMwuO2Lccm4QEgMvmsnODJY6ZnZCmuOC4phqy7zI.YmUwXm9RE.pqvsrsW_ZuknZqBAcHMtPk g79UAMjkK2YFYcEmVMfBo6lCsXUq8J3vWRRQiTKUh.CJJM6_W_2eIDozSNktUTh1nJg9.sdJ1hCW kTXF6JI7nR2RTiyQMqBs4hXVPedMXiNqENTY0LNdkiyiy7LYRUtmkFnSERqKgNHy0re_Xacazw99 E3zd8YsUZ.sm62s32f2Eh4137c8gA6TMl.D1uuPNtBu7eAiGwes8qTYKTJrsNTRixuPmTl7aBQMK ffhchPhYQjGQHznOOAccGpEvynABVu.bDt.os4m_dP0GJUdLyzEw8OqGoZOzVofw0ulIexCq2NAv 4ZFvDeomdxB68KOBBt4vEmrRpzsYjeMBq7rtYz2y4RZZU3XwiFNxFgZ9VQyDr6y23zrIGArxbOo9 6uPdAqWipC85nobHJb7iqdxz0cQGhtlO_fab.shEonFS0ZDcTfQrXKloRj.Sq0dnp5C4voGPCwAQ ImAfXaVWd4U4mMZEv7lBUbFbrm0AJGte9ZpM7xIWMqY_oUwVg31YrQJoNmTUHbx8AJuSQ0Qm_j71 vi1.ULMDmFr4RafzaBEhFJJll_ac- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Aug 2020 04:42:52 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 61024815e016ada32ed3a8b144d8a283; Tue, 18 Aug 2020 04:42:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: CPU_FFS, its ffsl use, and the need for including if using "ISO" compiler modes Message-Id: <5C4EB8F3-F184-4FC0-82CD-4A0B8CFCAF9D@yahoo.com> Date: Mon, 17 Aug 2020 21:42:49 -0700 To: FreeBSD Current , FreeBSD Toolchain X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <5C4EB8F3-F184-4FC0-82CD-4A0B8CFCAF9D.ref@yahoo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597725775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: references:references:dkim-signature; bh=9ombrryWbh9/52rLI5hXm6gsymlyrhbwdizZ4LNevd0=; b=Ss758tNsbwxY8mevwpj3EV2CuPLL8h44V1s5nA8jiBrMc3P96esnDmg0trf1/gr4BfNPyM JJ+uLGArs0tKbdbCY1YK02GDmoAT42vIcs6iKjSxaLq9hG1264wuVdVoGcya1i5W/dBI+U bNTiCoHbtwOwDWKuunJshM9eI2T8ryxSQQG3tRfuGbAquYIbKjgIp1vN4dJhOmfMYLp1TC nfPWK3IxrUHOHlDeYl6gpGI3z+EhYE8IjG3jhkqE97FBnsdWkQnJBoJNo+ncLc2WRNeeWa aSoNGVx5+/oacUkOSpp+XAuDvn0j0zzotoaaQvteTBycjZ+dKziso1GimgilWQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597725775; a=rsa-sha256; cv=none; b=IkWXDFeiZ3cIVICxIYZWRJ3rmUjIEuW+bzm+k5UJkUBGOCn+aF8lpGK7SFLe3KqGzRWv9+ 1fmqBNNKJ6e4oVqFwbcVefzauajpX3EXTQAd0l5Y3uAK+2rT9itQJtCXJb7v3Nd/LJOE5c r9KDXnaHd05HYmRRypocGT7w9Ut6dzwjw7XxvSa0f0RbjtnDs/91xfUzPhSMnKHbQsQY2K GMggVbnBcZZwBchiJzqqC8MdZ/pMPN6aFxt7V19Tffr7JYc7oJ2UM/qI9iqxLk2ux59mse xf1e0fbyPeCv78ALIpDsy2QM9NnKoLo9HjF5+RH/I1iCech4Tjse6GvcLtMRjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=A+0a76ky; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Rspamd-Queue-Id: 4BVyvf3N5Bz4j2s X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.21 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; ARC_SIGNED(0.00)[i=1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.74)[-0.744]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.986]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 04:42:55 -0000 In a aarch64 head -r363590 context with g++9 from ports in use (so ffsl is only compiler-defined outside strict ISO modes) . . . I got a compile failure for using CPU_FFS because ffsl "was not declared". My code was being compiled via -std=c++17 . (Other than enabling one feature, it is not system specific code overall.) Well, it turns out that /usr/include/sys/bitset.h is indirectly used by /usr/include/sys/cpuset.h and bitset.h has use of ffsl in BIT_FFS but bitset.h does nothing to cause use of a: #include to pick up the FreeBSD's libc declaration of the ffsl routine. (There are other "bit string" routines with similar issues.) Nor does "man 2 cpuset" or /usr/include/sys/cpuset.h or /usr/include/sys/bitset.h explicitly suggest the potential need for including to declare things used by the header files that are mentioned in those places. I'll note that g++10 did not object before this change. But I had reason to also build using g++9 . [Compiling the -updated code with g++10 did not complain. Nor did linking the results complain.] Note: The c++17 code involved is not part of a FreeBSD port. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Aug 18 08:25:21 2020 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 7F3C83B3679; Tue, 18 Aug 2020 08:25:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW3rH1fwCz4vdy; Tue, 18 Aug 2020 08:25:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 1b7b8dba (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 18 Aug 2020 08:25:11 +0000 (UTC) Date: Tue, 18 Aug 2020 10:25:10 +0200 From: Emmanuel Vadot To: Jan Beich Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: DRM Project report (week of August 10) Message-Id: <20200818102510.483dabc30639d4d7b20ed17e@bidouilliste.com> In-Reply-To: <4kp1-5cyx-wny@FreeBSD.org> References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> <4kp1-5cyx-wny@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BW3rH1fwCz4vdy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 08:25:21 -0000 On Mon, 17 Aug 2020 20:44:38 +0200 Jan Beich wrote: > Emmanuel Vadot writes: > > > Hello, > > > > 5.4 was finilly reached ! > > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > > For Intel users it means that TigerLake should work too. > > > > No ports update for now as I want to give current users a bit of time > > to update their base (as the ports needs recent addition to > > base linuxkpi) but if you have a current >= 364233 you can test > > directly the master branch of https://github.com/freebsd/drm-kmod/ > > > > I plan to commit the port update at the end of the week, and probably > > at the end of the month we will switch drm-current-kmod to 5.4. > > > > It's now time to do 2 main things : > > - Update stable/12 so it have all the needed code to run 5.4 > > - Remove the remaining GPLv2 code to start thinking of import into > > base. > > Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS) > doesn't require more LinuxKPI changes? For example, when drm-v5.0 was > the latest I've played with grafting linux-4.19.y only to discover > some commits had to be reverted due to missing LinuxKPI bits. Not yet, but those bits could be added in the ports for 12.2 if they are needed anyway. -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Aug 18 10:10:19 2020 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 237693B6B23; Tue, 18 Aug 2020 10:10:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW69K5bTJz3Z6D; Tue, 18 Aug 2020 10:10:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 484532b4 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 18 Aug 2020 10:10:05 +0000 (UTC) Date: Tue, 18 Aug 2020 12:10:05 +0200 From: Emmanuel Vadot To: Jan Beich Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: DRM Project report (week of August 10) Message-Id: <20200818121005.580e821200e21f7ac97484d5@bidouilliste.com> In-Reply-To: <20200818102510.483dabc30639d4d7b20ed17e@bidouilliste.com> References: <20200817104608.d29dc8834ccc93c18b884a29@bidouilliste.com> <4kp1-5cyx-wny@FreeBSD.org> <20200818102510.483dabc30639d4d7b20ed17e@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BW69K5bTJz3Z6D X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[manu]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-x11] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 10:10:19 -0000 On Tue, 18 Aug 2020 10:25:10 +0200 Emmanuel Vadot wrote: > On Mon, 17 Aug 2020 20:44:38 +0200 > Jan Beich wrote: > > > Emmanuel Vadot writes: > > > > > Hello, > > > > > > 5.4 was finilly reached ! > > > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > > > For Intel users it means that TigerLake should work too. > > > > > > No ports update for now as I want to give current users a bit of time > > > to update their base (as the ports needs recent addition to > > > base linuxkpi) but if you have a current >= 364233 you can test > > > directly the master branch of https://github.com/freebsd/drm-kmod/ > > > > > > I plan to commit the port update at the end of the week, and probably > > > at the end of the month we will switch drm-current-kmod to 5.4. > > > > > > It's now time to do 2 main things : > > > - Update stable/12 so it have all the needed code to run 5.4 > > > - Remove the remaining GPLv2 code to start thinking of import into > > > base. > > > > Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS) > > doesn't require more LinuxKPI changes? For example, when drm-v5.0 was > > the latest I've played with grafting linux-4.19.y only to discover > > some commits had to be reverted due to missing LinuxKPI bits. > > Not yet, but those bits could be added in the ports for 12.2 if they > are needed anyway. > I did a quick test and only two commits needs to be back-out to have v5.4.58 : https://github.com/torvalds/linux/commit/f14f27b1663269a81ed62d3961fe70250a1a0623 https://github.com/torvalds/linux/commit/873a95e0d59ac06901ae261dda0b7165ffd002b8 I'll look at what's really needed in a few days. I've pushed a 5.4-lts branch https://github.com/freebsd/drm-kmod/tree/5.4-lts This has not been tested yet (just compiled). -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Aug 18 12:13:23 2020 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 B57573B9D97 for ; Tue, 18 Aug 2020 12:13:23 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW8vQ46Xdz3yBT; Tue, 18 Aug 2020 12:13:22 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([77.183.29.206]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N5mKP-1kiQxI2e9z-017EVL; Tue, 18 Aug 2020 14:13:19 +0200 Date: Tue, 18 Aug 2020 14:13:11 +0200 From: "Hartmann, O." To: Dimitry Andric Cc: "O. Hartmann" , freebsd-current Subject: Re: ld: error: duplicate symbol: Message-ID: <20200818141311.557eff8b@hermann.fritz.box> In-Reply-To: References: <20200817154208.42d25b89@freyja> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/V+KXbExAILuTz3WJu219sIv"; protocol="application/pgp-signature" X-Provags-ID: V03:K1:U+0hmJ2fgMJ2V5fRW5NGLDG8dd5ytW0Evba8LiNWoutoF3D0l/6 SUAlQ9r0r4udLE9zu6RWXQUtdYVzbuaExWfM+9/hafzi7b0eDPYj/3eHZqY0uAkAZxDnw/c IPZJOlJL2Rd0Xj6xAP3mJlNDCtv6I7osCRZ5cPPOoApjy0nr8Gql/lND7gkk5ga5o+r8yla hz1jTU1wHnh+4s/RJszkg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:m5c8BwQ+yeM=:V7kDinPfEdJGd9rHgJ3b4W l21B3WQoJbRXClKlWqkPx2RFjOS0du4PO/2FMH0fdhzMEOtIb0VTizIl3/Zw3g7IfgkPDoZr+ Ep4Fq2dCcXRXSe5hW1VE0sY5DnaR4ksDWdR/tTtecehF1jVK0TYMcxfl4SLoPbNeojZrD1f6Z mDBbX7NJAv8TiFFB0aZQXUfLfYyT33HYUUE4Np7jlcnfkOL0fIWg7Kjo/7TFrAilZLWM8OZ9h htbddAI610fEiUbSz51npTY4R62d3y1WxnzD/5OiBj6L6PLpZy4fLiM+yYCrbPXFj9pDTMcPB jnf6Fy3tcpr6IlskH5SGr5FYSEKVkszCz6Krz2vXtMaZ7kfZux8pqruIxe0+G9/IA3Y1Aay6A X8J6GXtNvQnnc3pSglN4/NCUBHHMuL+eY1tvsbvP4ZIZvCLRXCZw1tyznWqkUtkb+h/vjkNZZ MENQdVPfK0r9vUtxuLJuaYY9eTLnDJsrIZ7rDlNO7osUeojt9mG3K8tNY6yjxa3AIVrGpNQ2e WezsMZNPsBsjQYKB9PDvVwzAvWeEsiqQSQhcN74QCtBPRUlRy7mPJGdLvnMxDnwpKDuLbG7of XTFEoIoOXNd7cSvXYa/X9e1jifKzWuk3AncP0NRo1Vf7kOYoX1UuwGLSBC/FFmPr/mC176ilb HXrOrFs6YKshBeY+zxihu+0BfcbiKyKRk72PxAaR8O9ks2rMJ7LWnlANBl1gaKQl6o3Zq+Gw7 SO6Of2MtBRSTDfxAUZ23dfsQJMgRGPk79quf4ZHVipCtrJLilGwBshY3NkBPLvUUdpRxSqBoc SypU0kOzF7N++FfOn9VPoet+PJyxNKHwSFJ5RhSK3SFJf69/TkHH2ILE+Et+6EAYfHg65t9da T8Up3clmRuKdyToSTP6yXlhH1Bnn6HpDvgHQt5n2tT8s79MI9vk+lRE7llvwRG/Vd/hINPITh 5siWQMCHMrplL8hp3cCgdiGow8TXBSl6U0nQLx7ECBsTbiiQqqiQX98/pPqUy4xupPrwYGpaV QYesJfBMpGJWbkKC8WSAiXGxv0JFdS2c/eCEPH0b5Y0VUyZzNKUQgXoDJfSAakRZTG1/UHjEv Ehj/SBISHRWIMuQFLO4Ua36mQm8Cr+Y1NWj4NZJksQTo2JXRoB1oYiVJH9MVyYAKud2UKltbx Oj2kGRLTQjEdsMsp8HM01IxtNjsDzNTbtKpAMB4xtqTq1S8f4ZtEttVrrwGqrJhyy/IQ8Ocrc 6LVSbyfiPBQ7IropLNMjLQvO809L/BfnYoCE15Q== X-Rspamd-Queue-Id: 4BW8vQ46Xdz3yBT X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; HAS_ORG_HEADER(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RECEIVED_SPAMHAUS_PBL(0.00)[77.183.29.206:received]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 12:13:23 -0000 --Sig_/V+KXbExAILuTz3WJu219sIv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Aug 2020 21:49:52 +0200 Dimitry Andric wrote: > On 17 Aug 2020, at 15:42, O. Hartmann wrote: > >=20 > > On CURRENT 9not necessarily most recent with LLVM11, but since noon > > of today it is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 > > 14:39:06 CEST 2020 amd64) I'm faced with some very sticky and nasty > > micompilations in several essential ports, for instance > >=20 > > ports-mgmt/pkg > > devel/libunwind > > devel/binutils > >=20 > > In most cases somewhere in the (parallel) build the process fails > > with the error > >=20 > > ld: error: duplicate symbol: xxxxxxxx =20 >=20 > This is because clang 11 (and gcc 10) now default to -fno-common. The > rationale is explained pretty well in > : >=20 > "GCC currently defaults to -fcommon. As discussed in the PR, this is > an ancient C feature which is not conforming with the latest C > standards. On many targets this means global variable accesses have > a codesize and performance penalty. This applies to C code only, C++ > code is not affected by -fcommon. It is about time to change the > default." >=20 > A quick fix is to add CFLAGS+=3D-fcommon to your make.conf, but that is > rather a big hammer. It is better to add it to just the ports that > show problems due to duplicated symbols. And ideally, those duplicated > symbols should be patched out of the ports. >=20 > For example, ports-mgmt/pkg already has such a patch: > https://github.com/freebsd/pkg/commit/7fbde60c4af4a1a07db7c5c36efbb2a495f= 7b1a4 > but I have no idea why it is not yet in the ports tree. >=20 > -Dimitry >=20 Thank you for the fast response and thorough explanation. oh --Sig_/V+KXbExAILuTz3WJu219sIv Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXzvF1wAKCRA4N1ZZPba5 R/fvAQDdYX8jrecBjnld3L7/Tb9oeEGkkQtahR+YFLqGiq5IoQD/fgWDuzPNKaY1 OZA+Lo2D5wcs3D6WEgJbKpotXr0zYAo= =65HO -----END PGP SIGNATURE----- --Sig_/V+KXbExAILuTz3WJu219sIv-- From owner-freebsd-current@freebsd.org Tue Aug 18 12:19:29 2020 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 C9CB23BA0CC for ; Tue, 18 Aug 2020 12:19:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW92R72qbz3yf6; Tue, 18 Aug 2020 12:19:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from amy (feu30-1-82-242-59-241.fbx.proxad.net [82.242.59.241]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6e9005a8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 18 Aug 2020 12:19:22 +0000 (UTC) Date: Tue, 18 Aug 2020 14:19:21 +0200 From: Emmanuel Vadot To: Dimitry Andric Cc: "O. Hartmann" , freebsd-current Subject: Re: ld: error: duplicate symbol: Message-Id: <20200818141921.33fd8e03586789de0cdd913d@bidouilliste.com> In-Reply-To: References: <20200817154208.42d25b89@freyja> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BW92R72qbz3yf6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 12:19:29 -0000 On Mon, 17 Aug 2020 21:49:52 +0200 Dimitry Andric wrote: > On 17 Aug 2020, at 15:42, O. Hartmann wrote: > > > > On CURRENT 9not necessarily most recent with LLVM11, but since noon of today it > > is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) I'm > > faced with some very sticky and nasty micompilations in several essential > > ports, for instance > > > > ports-mgmt/pkg > > devel/libunwind > > devel/binutils > > > > In most cases somewhere in the (parallel) build the process fails with the error > > > > ld: error: duplicate symbol: xxxxxxxx > > This is because clang 11 (and gcc 10) now default to -fno-common. The > rationale is explained pretty well in > : > > "GCC currently defaults to -fcommon. As discussed in the PR, this is an ancient > C feature which is not conforming with the latest C standards. On many targets > this means global variable accesses have a codesize and performance penalty. > This applies to C code only, C++ code is not affected by -fcommon. It is about > time to change the default." > > A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is > rather a big hammer. It is better to add it to just the ports that show > problems due to duplicated symbols. And ideally, those duplicated > symbols should be patched out of the ports. > > For example, ports-mgmt/pkg already has such a patch: > https://github.com/freebsd/pkg/commit/7fbde60c4af4a1a07db7c5c36efbb2a495f7b1a4 > but I have no idea why it is not yet in the ports tree. I was sure it was at least in pkg-devel but no, I guess I forgot to update svn. It's now unbroke in both pkg and pkg-devel. > -Dimitry > -- Emmanuel Vadot From owner-freebsd-current@freebsd.org Tue Aug 18 12:44:28 2020 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 E191A3BAC99 for ; Tue, 18 Aug 2020 12:44:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BW9bJ5684z4100 for ; Tue, 18 Aug 2020 12:44:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id AD21C3BAC97; Tue, 18 Aug 2020 12:44:28 +0000 (UTC) Delivered-To: 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 ACED43BAC96 for ; Tue, 18 Aug 2020 12:44:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW9bH2YfFz419b for ; Tue, 18 Aug 2020 12:44:27 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 07ICiJ7U026011 for ; Tue, 18 Aug 2020 12:44:19 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 07ICiJxS026010 for current@freebsd.org; Tue, 18 Aug 2020 05:44:19 -0700 (PDT) (envelope-from david) Date: Tue, 18 Aug 2020 05:44:19 -0700 From: David Wolfskill To: current@freebsd.org Subject: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818124419.GO1394@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mgiPvHqStUXOBTSF" Content-Disposition: inline X-Rspamd-Queue-Id: 4BW9bH2YfFz419b X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.56 / 15.00]; HAS_REPLYTO(0.00)[current@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.04)[-0.042]; DMARC_NA(0.00)[catwhisker.org]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; MAILMAN_DEST(0.00)[current]; REPLYTO_EQ_TO_ADDR(5.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 12:44:28 -0000 --mgiPvHqStUXOBTSF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just did a src update from r364296 -> r364341 on amd64 on my bild machine (laptop is still working -- it built firefox earlier, which takes some time). On initial reboot, the build machine panicked: umass0: SCSI over Bulk-Only; quirks =3D 0x4000 umass0:6:0: Attached to scbus6 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? panic: malloc(M_WAITOK) in non-sleepable context cpuid =3D 1 time =3D 20 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8218d= 440 vpanic() at vpanic+0x182/frame 0xffffffff8218d490 panic() at panic+0x43/frame 0xffffffff8218d4f0 malloc() at malloc+0x20c/frame 0xffffffff8218d540 devfs_alloc() at devfs_alloc+0x28/frame 0xffffffff8218d570 make_dev_sv() at make_dev_sv+0x97/frame 0xffffffff8218d600 make_dev_s() at make_dev_s+0x3b/frame 0xffffffff8218d660 passregister() at passregister+0x3e7/frame 0xffffffff8218d8b0 cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xffffffff8218d980 passasync() at passasync+0x5c/frame 0xffffffff8218d9c0 xpt_async_process_dev() at xpt_async_process_dev+0x152/frame 0xffffffff8218= da10 xpt_async_process() at xpt_async_process+0x334/frame 0xffffffff8218db20 xpt_done_process() at xpt_done_process+0x3a3/frame 0xffffffff8218db60 xpt_done_td() at xpt_done_td+0xf5/frame 0xffffffff8218dbb0 fork_exit() at fork_exit+0x80/frame 0xffffffff8218dbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffffff8218dbf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic [ thread pid 16 tid 100068 ] Stopped at kdb_enter+0x37: movq $0,0x10b70f6(%rip) db>=20 So -- it's at the debugger prompt; given sufficient hints, I'm happy to poke at it & report back. Yesterday's (r364296) verbose dmesg.boot is at http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt (in case that's useful). Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump is either ignorant of how to govern or is refusing to do so. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --mgiPvHqStUXOBTSF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl87zSNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcmgAwgA1kQvl/vuEcKNunvqutvNPv2s/gNPUm7cOoDFkKcJPBhfVnhteBW2IZaz D/8PIWkTdivYxg7OErBJKQMdrlt69VdzzT+5XkogRFg+39tlgu2/+6xdjOSLsXLX 3NgZoeZLKCFGIfZyLY53PM61f7UFUwbLUSlYZEYeWekvVAi2v5VYIxiM6TUnjVr0 S1CBFDH99AKFu5TscZXiJMGRH4flCla+XoXiHtuLLJyU51enj2dUvFgomIPZNYkB ayKuKLo3A4XzhHeQoVeCDl5Eac2+u1ZmY/nurDnrnwtSJVCJrKo/PzQjzFlaYPD8 dhL0YemksGPhTnAeF75UZd2zSnJTBw== =7Frk -----END PGP SIGNATURE----- --mgiPvHqStUXOBTSF-- From owner-freebsd-current@freebsd.org Tue Aug 18 12:48:52 2020 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 478223BB01B for ; Tue, 18 Aug 2020 12:48:52 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BW9hM5vfBz41VZ for ; Tue, 18 Aug 2020 12:48:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id CAAF63BAF36; Tue, 18 Aug 2020 12:48:51 +0000 (UTC) Delivered-To: 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 CA76B3BAFD0 for ; Tue, 18 Aug 2020 12:48:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BW9hM3clCz41Xw for ; Tue, 18 Aug 2020 12:48:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id y3so18172719wrl.4 for ; Tue, 18 Aug 2020 05:48:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Y89dL52vpxTOrpJqPTAy94AUqrBl8FXi7nfhp2QS0jg=; b=FkzKIdmN451lc5Oc/I9bTQ+TUiJWJ/WOdLZfvycA2Jpd499W5kIr5MeyC8zoRfqw87 s+8h/fyiCM1Uz0tu3t7Y1CqoYclAqwt9T2zHP9horHqvp2f6Myp5LoE5CS/Kqj8LH7Nn HrN5t4gpQBl46Hav/i7VJtqPLKGE2LGGtXVavYaQ05Lyygp+7oDkwdcKj2okNCGFQxN+ B7D8FiIoQo0ObunE8dOrgMi79Kb86Zu2ZJpZMT9xodhaP0C0wqWLDK7JPcE+SXit3ndI cb0Tap6tN+Mr5Ik8Z6bteeInw+sRnvG1ISZe0OHde4lLtIGBvvH10VY3U1NoRY3r2Emr b6mw== X-Gm-Message-State: AOAM530oXnWjIS4G3EMWjC39tMwshb0NaKDYYnQzjUiYeUO94OISbA2p qBBFT3SqGDzmO+e8cLnZTIiZOTPT8cdU+Cqc3Ambu1fT X-Google-Smtp-Source: ABdhPJx0ZgtmPfSAkj1UhRduAvDiTRJ0GEKPUTrE8fhDe7xdI+bvwpXIxgwJUpPxwqn/WqSEI3ia/m0Pya/B9beqars= X-Received: by 2002:adf:f8d0:: with SMTP id f16mr21408745wrq.66.1597754928839; Tue, 18 Aug 2020 05:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 05:48:47 -0700 (PDT) In-Reply-To: <20200818124419.GO1394@albert.catwhisker.org> References: <20200818124419.GO1394@albert.catwhisker.org> From: Mateusz Guzik Date: Tue, 18 Aug 2020 14:48:47 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 To: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BW9hM3clCz41Xw X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 12:48:52 -0000 see https://reviews.freebsd.org/D26027 On 8/18/20, David Wolfskill wrote: > Just did a src update from r364296 -> r364341 on amd64 on my bild > machine (laptop is still working -- it built firefox earlier, which > takes some time). On initial reboot, the build machine panicked: > > umass0: SCSI over Bulk-Only; quirks = 0x4000 > umass0:6:0: Attached to scbus6 > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > panic: malloc(M_WAITOK) in non-sleepable context > cpuid = 1 > time = 20 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffffff8218d440 > vpanic() at vpanic+0x182/frame 0xffffffff8218d490 > panic() at panic+0x43/frame 0xffffffff8218d4f0 > malloc() at malloc+0x20c/frame 0xffffffff8218d540 > devfs_alloc() at devfs_alloc+0x28/frame 0xffffffff8218d570 > make_dev_sv() at make_dev_sv+0x97/frame 0xffffffff8218d600 > make_dev_s() at make_dev_s+0x3b/frame 0xffffffff8218d660 > passregister() at passregister+0x3e7/frame 0xffffffff8218d8b0 > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xffffffff8218d980 > passasync() at passasync+0x5c/frame 0xffffffff8218d9c0 > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > 0xffffffff8218da10 > xpt_async_process() at xpt_async_process+0x334/frame 0xffffffff8218db20 > xpt_done_process() at xpt_done_process+0x3a3/frame 0xffffffff8218db60 > xpt_done_td() at xpt_done_td+0xf5/frame 0xffffffff8218dbb0 > fork_exit() at fork_exit+0x80/frame 0xffffffff8218dbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffffff8218dbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 16 tid 100068 ] > Stopped at kdb_enter+0x37: movq $0,0x10b70f6(%rip) > db> > > > So -- it's at the debugger prompt; given sufficient hints, I'm happy > to poke at it & report back. > > Yesterday's (r364296) verbose dmesg.boot is at > http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt > (in case that's useful). > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Donald Trump is either ignorant of how to govern or is refusing to do so. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 12:58:28 2020 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 5026E3BAD35 for ; Tue, 18 Aug 2020 12:58:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BW9vS0pdVz41rx for ; Tue, 18 Aug 2020 12:58:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1BB553BAD33; Tue, 18 Aug 2020 12:58:28 +0000 (UTC) Delivered-To: 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 1B7CA3BB05F for ; Tue, 18 Aug 2020 12:58:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BW9vR026Nz41ml for ; Tue, 18 Aug 2020 12:58:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 07ICwPmJ027561; Tue, 18 Aug 2020 12:58:25 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 07ICwPMP027560; Tue, 18 Aug 2020 05:58:25 -0700 (PDT) (envelope-from david) Date: Tue, 18 Aug 2020 05:58:25 -0700 From: David Wolfskill To: Mateusz Guzik Cc: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818125825.GP1394@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Mateusz Guzik References: <20200818124419.GO1394@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xP4xvRzdEG0QZ+Pj" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4BW9vR026Nz41ml X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.59 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; SIGNED_PGP(-2.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.19)[-0.186]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 12:58:28 -0000 --xP4xvRzdEG0QZ+Pj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 02:48:47PM +0200, Mateusz Guzik wrote: > see https://reviews.freebsd.org/D26027 > .... Right; I was just reviewing the list of updated files and noted src/sys/kern/kern_malloc.c, and its svn log showed: ------------------------------------------------------------------------ r364310 | glebius | 2020-08-17 08:37:08 -0700 (Mon, 17 Aug 2020) | 8 lines With INVARIANTS panic immediately if M_WAITOK is requested in a non-sleepable context. Previously only _sleep() would panic. This will catch misuse of M_WAITOK at development stage rather than at stress load stage. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D26027 ------------------------------------------------------------------------ And if we were still going in to the office, I'd discuss it with Gleb. :-) But in the mean time: I'm not a committer; I didn't cause the error. Seems I can't try running head now with a GENERIC kernel. Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump is either ignorant of how to govern or is refusing to do so. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --xP4xvRzdEG0QZ+Pj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl870HFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcnT8QgAkVRRNjyVakVRitID8d9WSEvKJcRZx9ICemFxZFuvHthIJzrwvRSZ7aq/ dh2/JnYXOFcxV5WMexASAtdcHgkziUddxJe5vhPoaV6jXiocYQTdGyOZEeLphKhU k6rW+5SlqLdP2kqFIR2tFF3pkkNuNfhjdAWKY/RwRpFcOEG4bQ6U+9tV9T7Ktj/3 Nlef9tpYhLaDraYjRgiEQL1q8AE6jQ5hrSG3NOO8PnfdUlzqkYB9o/cbJn0s/fyX B46OwFbIsKQR5eKrF+NLwNpI+1HDrP6rYHAox7zb/lHTvk5fnnZh0bevwZ07080v kPp0kdhZqw623gX9prBxbd9ni/NRgg== =OxMD -----END PGP SIGNATURE----- --xP4xvRzdEG0QZ+Pj-- From owner-freebsd-current@freebsd.org Tue Aug 18 13:24:56 2020 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 13AE93BBEB9 for ; Tue, 18 Aug 2020 13:24:56 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWBTz5Jg9z43T9 for ; Tue, 18 Aug 2020 13:24:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id B62C23BBB6B; Tue, 18 Aug 2020 13:24:55 +0000 (UTC) Delivered-To: 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 B5F683BBB6A for ; Tue, 18 Aug 2020 13:24:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWBTz1NZvz43Bt for ; Tue, 18 Aug 2020 13:24:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id p20so18287224wrf.0 for ; Tue, 18 Aug 2020 06:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=j+g2yLiDZzLtm3YyuS9aN0Tew9axnqKmg3j6ZnMnecY=; b=SqiGfoSXSt8qeDatxpZnwwAcCl4vTBFOciIBx6nKTSzo5JaBxK69zWKwn6ADeDN+P+ yqdPMWzte/x9LJW0SPocazRdFdDZCRYa1FxPucsYhie7Tn88od0fPN57uRl5RFRHdPeK zyWa1gCi8ouKt8E2ViHExt1ne86UGM5YLnlB7lxxF1ckfO2/6paV5ZKKiQZBpGOd3QUX Jua1PetJrzBmUQCvpFEQJjPPYxub4yqH7Qde12wPJ2saclPPkMKWYakBUjRVuqTpdLxR i9aTSevDddFDSsVhcaMJ24VUFlAMm6Z+BPoYfXNwA01pA4kS+9p/YVw90O0/h5JKO6Gs 8BTQ== X-Gm-Message-State: AOAM530hz7JO6rxJOswssj6qEV4dZ0f+nhQxQEm0/zqeaQJLpiVXNrzh jxDal7iHXPYSln78b1z+EZ8T1Dv8IkTckup60T1jfSF2 X-Google-Smtp-Source: ABdhPJxEptuEK+L/qx5vvve13rrEm6VZp7Xgub5v19NQl+Y9JnQZAIKv7a1ifIWUY6xCUpug59yt5Y7HqYNm/GPY3MY= X-Received: by 2002:adf:e94c:: with SMTP id m12mr20304458wrn.109.1597757093672; Tue, 18 Aug 2020 06:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 06:24:52 -0700 (PDT) In-Reply-To: <20200818125825.GP1394@albert.catwhisker.org> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> From: Mateusz Guzik Date: Tue, 18 Aug 2020 15:24:52 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 To: current@freebsd.org, Mateusz Guzik Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWBTz1NZvz43Bt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:24:56 -0000 Try this: diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c index 46eb1c4347c..7b94ca7b880 100644 --- a/sys/kern/kern_malloc.c +++ b/sys/kern/kern_malloc.c @@ -618,8 +618,8 @@ void * unsigned long osize = size; #endif - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), - ("malloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) != 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); #ifdef MALLOC_DEBUG va = NULL; diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c index 37d78354200..2e1267ec02f 100644 --- a/sys/vm/uma_core.c +++ b/sys/vm/uma_core.c @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int flags) uma_cache_bucket_t bucket; uma_cache_t cache; - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), - ("uma_zalloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) != 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option */ random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); On 8/18/20, David Wolfskill wrote: > On Tue, Aug 18, 2020 at 02:48:47PM +0200, Mateusz Guzik wrote: >> see https://reviews.freebsd.org/D26027 >> .... > > Right; I was just reviewing the list of updated files and noted > src/sys/kern/kern_malloc.c, and its svn log showed: > > ------------------------------------------------------------------------ > r364310 | glebius | 2020-08-17 08:37:08 -0700 (Mon, 17 Aug 2020) | 8 > lines > > With INVARIANTS panic immediately if M_WAITOK is requested in a > non-sleepable context. Previously only _sleep() would panic. > This will catch misuse of M_WAITOK at development stage rather > than at stress load stage. > > Reviewed by: markj > Differential Revision: https://reviews.freebsd.org/D26027 > > ------------------------------------------------------------------------ > > And if we were still going in to the office, I'd discuss it with Gleb. :-) > > But in the mean time: I'm not a committer; I didn't cause the error. > Seems I can't try running head now with a GENERIC kernel. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Donald Trump is either ignorant of how to govern or is refusing to do so. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 13:29:04 2020 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 842173BC09E for ; Tue, 18 Aug 2020 13:29:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWBZm2Mc0z43rv for ; Tue, 18 Aug 2020 13:29:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 4F6863BBEFB; Tue, 18 Aug 2020 13:29:04 +0000 (UTC) Delivered-To: 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 4F2753BC09D for ; Tue, 18 Aug 2020 13:29:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWBZl4FFVz43gm for ; Tue, 18 Aug 2020 13:29:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 07IDT2lF029022; Tue, 18 Aug 2020 13:29:02 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 07IDT202029021; Tue, 18 Aug 2020 06:29:02 -0700 (PDT) (envelope-from david) Date: Tue, 18 Aug 2020 06:29:02 -0700 From: David Wolfskill To: Mateusz Guzik Cc: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818132902.GQ1394@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Mateusz Guzik References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iRy0ocDzxpWaNtI5" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4BWBZl4FFVz43gm X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.58 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; SIGNED_PGP(-2.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.18)[-0.182]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:29:04 -0000 --iRy0ocDzxpWaNtI5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: > Try this: > [replacing new KASSERT() with WITNESS_WARN()...]=20 > .... Thanks; on it. Should take care of it, I think. Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump is either ignorant of how to govern or is refusing to do so. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --iRy0ocDzxpWaNtI5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl87151fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcn4+Qf9F5sC6i7BsEAhQKprrJLI5zHWlHJmb2zGRd+DASE4mRlaHK/zCeaAFgCL AgQ0BmG9UvcfgXmuUaPYhZw1UDFYu7WcDRbp3bEwRFUYpiDxMB6LF3xmncWNHBoG zJCio3pfsPbRPVawm2Qrl2bsAtCzYdM49pT1x9lG73ClA9nKtxkrldquGe/08eDJ nGKigCVXe2ZgodRcbfbRjPS2q1OlMeeafqFXmmNyJSqMNe1A/3mq+Z+b63lO9P20 CS29qwi4ii0obhDTuqjR9rzD70yFeTmsOmO310cMhh8j531b24t4JtouUdvSBsZy A6sSAMac/U8IztRaDkzWKNp21NVfwA== =36kL -----END PGP SIGNATURE----- --iRy0ocDzxpWaNtI5-- From owner-freebsd-current@freebsd.org Tue Aug 18 13:31:46 2020 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 1C8AD3BC323 for ; Tue, 18 Aug 2020 13:31:46 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWBds5zhjz43tZ for ; Tue, 18 Aug 2020 13:31:45 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id CD4F83BC322; Tue, 18 Aug 2020 13:31:45 +0000 (UTC) Delivered-To: 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 CD1833BBF6D for ; Tue, 18 Aug 2020 13:31:45 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWBdr24Wtz43yT for ; Tue, 18 Aug 2020 13:31:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id r15so8372147wrp.13 for ; Tue, 18 Aug 2020 06:31:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2ZrgkiViSkN+TN6XpTEOoJ24pV3o/VfAW5+h84khaAQ=; b=Hgvm0U6F/Tzr9lCpm8C2W5ImRMZuBXcSW+3GBwJA5Q03MBiVrI3m+TikGxqjrCJPuM uFnTQfW2La4nYC4vWozA5u4OvJ7rIBa/gLAG5ibmeApnukJlGlvYbgQRRaW313RVcsra M9jYKlTb+TFp0SKM5Pxz4R0Cnm6SgeeZ4CS2A0TA9Mu7rSOAP9bZ+fiRCY3zvaJ31uYl qTOUx6d/eiElxTg7l+ckc0gdlA9Vg3hddvZO8rkVJjJs0xVudk/dC+jPVxr58bMlw8b2 SyfI4D2N7OqycqI/rw9+4lEGDitx9zaztHVkrmG6Bn2HcB4JBtNd9h3ST7a36SpDXbtV 60Bw== X-Gm-Message-State: AOAM531ydoNJ/RUGGlzmdG3r9bq5QW0NMvo/b63xBarXodIH4bHtd3c8 OQGMR35bbqMlR1IKjSgz6MLv5n5y3EXtSU1c5X0= X-Google-Smtp-Source: ABdhPJxWOKktHrjdsRDp0WA09BgmJ6l8K0xqh1gsnvPjCVOPlmwXnJkqlyzFawVovy1sfIXHdN9K/myGcok8vVVa6lE= X-Received: by 2002:adf:f8d0:: with SMTP id f16mr21591777wrq.66.1597757502703; Tue, 18 Aug 2020 06:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 06:31:41 -0700 (PDT) In-Reply-To: <45283d79-b061-4c8e-b788-8145b9c694a6@www.fastmail.com> References: <45283d79-b061-4c8e-b788-8145b9c694a6@www.fastmail.com> From: Mateusz Guzik Date: Tue, 18 Aug 2020 15:31:41 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" when inserting usb stick To: moridin@mm.st Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWBdr24Wtz43yT X-Spamd-Bar: / X-Spamd-Result: default: False [-0.71 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.29)[0.293]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::441:from]; FREEMAIL_TO(0.00)[mm.st]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:31:46 -0000 Hello, this sould take care of it (in that it will print the warning, but not panic the box): diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c index 46eb1c4347c..7b94ca7b880 100644 --- a/sys/kern/kern_malloc.c +++ b/sys/kern/kern_malloc.c @@ -618,8 +618,8 @@ void * unsigned long osize = size; #endif - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), - ("malloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) != 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); #ifdef MALLOC_DEBUG va = NULL; diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c index 37d78354200..2e1267ec02f 100644 --- a/sys/vm/uma_core.c +++ b/sys/vm/uma_core.c @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int flags) uma_cache_bucket_t bucket; uma_cache_t cache; - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), - ("uma_zalloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) != 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option */ random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); On 8/17/20, moridin@mm.st wrote: > r364323, previously I think it was just a warning from witness. Happens > both on boot with stick already inserted, and when inserting the stick in > booted system. > > Looks like my swap partition is no longer big enough for dump, translating > from screen: > > umass0 numa-domain 0 on uhub4 > umass0:2:0: Attached to scbus2 > panic: malloc(M_WAITOK) in non-sleepable context > > vpanic() > panic() > malloc() > disk_alloc() > daregister() > cam_periph_alloc() > daasync() > xpt_async_process_dev() > xpt_async_process() > xpt_done_process() > xpt_done_td() > fork_exit() > fork_trampoline() > _______________________________________________ > 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" > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 13:37:53 2020 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 1AD313BC745 for ; Tue, 18 Aug 2020 13:37:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWBmw5Xwcz44mf for ; Tue, 18 Aug 2020 13:37:52 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id BE4133BC744; Tue, 18 Aug 2020 13:37:52 +0000 (UTC) Delivered-To: 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 BE0E13BBFF7 for ; Tue, 18 Aug 2020 13:37:52 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWBmw4YG2z44tt for ; Tue, 18 Aug 2020 13:37:52 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id r4so18273775wrx.9 for ; Tue, 18 Aug 2020 06:37:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=E8t3ancdYw185rzyN7TDxVEPNZJSPW2bf4W66AS2Jk8=; b=rMKrVrXgeja58uZqj0x1D294H+9VcxA4RDVZbQOvG3UPu0k/md7qJqq7p71RT2kbbs Njcy5WlzEBRVFJ2b9kh4B2Igr2da+WDX//TT9SnB3k7uskqGTOkBnXoolgCHADrHZLdX eHVTRYnocOEYEKTez57rWRqBtSAmgbmD/5tCXOriVzy3KAo1KC9pefnVPr6g8XXzMyXF XUM3OAuXAjdfrpWe9exi08xt5RDEC4nnjmzL8ky/hEU8W6loYfT4XOdWAWc9u7SMG4W8 wVgzhEEXzfrZgS6cRRGAtoCRHJrhCYSM5PcbEz0LwvDvo06l5CWXzCwU8JP4ixCddS9w KUVQ== X-Gm-Message-State: AOAM5336XbHI9y6csCd5OCDKZToeSMMR9rmtlrJ62T1+N1373wgMPglh 7Wz907aWGRmkRCPqlFRzfUeP4vi8oNHliReC+zasNe4N X-Google-Smtp-Source: ABdhPJwYU+GLjDFu03lploNWNDAlSx+XWlIR5TxG1i81jO/ZORv3zOkksYNshZ4mQv3MBeH1p/laZET1hb1JJqygKlg= X-Received: by 2002:adf:e94c:: with SMTP id m12mr20355474wrn.109.1597757871123; Tue, 18 Aug 2020 06:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 06:37:50 -0700 (PDT) In-Reply-To: <20200818132902.GQ1394@albert.catwhisker.org> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> <20200818132902.GQ1394@albert.catwhisker.org> From: Mateusz Guzik Date: Tue, 18 Aug 2020 15:37:50 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 To: current@freebsd.org, Mateusz Guzik Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWBmw4YG2z44tt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:37:53 -0000 So the previous patch should just print a warning. Does this take care of the problem in general? I don't have means to test the patch. diff --git a/sys/cam/scsi/scsi_pass.c b/sys/cam/scsi/scsi_pass.c index b299fbddd84..c6d6a5da403 100644 --- a/sys/cam/scsi/scsi_pass.c +++ b/sys/cam/scsi/scsi_pass.c @@ -652,6 +652,7 @@ passregister(struct cam_periph *periph, void *arg) args.mda_gid = GID_OPERATOR; args.mda_mode = 0600; args.mda_si_drv1 = periph; + args.mda_flags = MAKEDEV_NOWAIT; error = make_dev_s(&args, &softc->dev, "%s%d", periph->periph_name, periph->unit_number); if (error != 0) { On 8/18/20, David Wolfskill wrote: > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> Try this: >> [replacing new KASSERT() with WITNESS_WARN()...] >> .... > > Thanks; on it. Should take care of it, I think. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Donald Trump is either ignorant of how to govern or is refusing to do so. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 13:49:09 2020 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 69AA93BCBBF for ; Tue, 18 Aug 2020 13:49:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWC1x1MKxz45DS for ; Tue, 18 Aug 2020 13:49:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 2EACC3BCBBE; Tue, 18 Aug 2020 13:49:09 +0000 (UTC) Delivered-To: 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 2E7353BCC49 for ; Tue, 18 Aug 2020 13:49:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWC1v5Q2Rz45Vn for ; Tue, 18 Aug 2020 13:49:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x843.google.com with SMTP id h21so15093094qtp.11 for ; Tue, 18 Aug 2020 06:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=SQeASj8bDHt5R3W899mCyccOaslhXtSFBfIVLc81yKE=; b=f+s9qUNuSeV7WBMSWOz9zmXRL1BoMwpdjNY5aadHBfdy4k0oDTMh9HDjK6PHsUju+X M9/oNuZmH4qopnT/TOIa44As8xB6BXmIoBg6+3wdtRZi32YXqknkXkrD0WfoBXbzfn+N E+GyC9+3CpFbo9+mfbKou5IQGh/o+Bs05GAz1jaJr/geOWcW8QAlIvPS1L35WQVM/J7l YujmoTz6Arb66sHsSBEKfOD2SJ0bijBqT2Mwan5i9KcbzcGG4j1aZpjpkHtWGXBoE67a bEcYm77Lex/TWM5N2vCtPbuDgVvsyyzP+kX+TW4Dt5NQ6/3WDa7BKZLuz9+vfxmBrhhe XRNQ== X-Gm-Message-State: AOAM530S/AFHLPMiYCs3qRMVJWAZM7WKPIVo6CTtoxZPefHe5EN5Zkh1 WO//D/OCN8WSkdq5+eli3IE= X-Google-Smtp-Source: ABdhPJweKLpwvT1L8I2yGU6qx+dHeMY7ciB+0iUhgH8Tm2LpIfoJt89aEZc6WFLUWFXv0mLN9nJNLw== X-Received: by 2002:ac8:4511:: with SMTP id q17mr17671552qtn.117.1597758546295; Tue, 18 Aug 2020 06:49:06 -0700 (PDT) Received: from raichu (toroon0560w-lp130-08-67-71-176-35.dsl.bell.ca. [67.71.176.35]) by smtp.gmail.com with ESMTPSA id a21sm20618203qkg.54.2020.08.18.06.49.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2020 06:49:05 -0700 (PDT) Sender: Mark Johnston Date: Tue, 18 Aug 2020 09:49:00 -0400 From: Mark Johnston To: Mateusz Guzik Cc: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818134900.GA28906@raichu> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4BWC1v5Q2Rz45Vn X-Spamd-Bar: / X-Spamd-Result: default: False [0.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_SHORT(0.12)[0.119]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::843:from]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:49:09 -0000 On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: > Try this: > > diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c > index 46eb1c4347c..7b94ca7b880 100644 > --- a/sys/kern/kern_malloc.c > +++ b/sys/kern/kern_malloc.c > @@ -618,8 +618,8 @@ void * > unsigned long osize = size; > #endif > > - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), > - ("malloc(M_WAITOK) in non-sleepable context")); > + if ((flags & M_WAITOK) != 0) > + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); > > #ifdef MALLOC_DEBUG > va = NULL; > diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c > index 37d78354200..2e1267ec02f 100644 > --- a/sys/vm/uma_core.c > +++ b/sys/vm/uma_core.c > @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int flags) > uma_cache_bucket_t bucket; > uma_cache_t cache; > > - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), > - ("uma_zalloc(M_WAITOK) in non-sleepable context")); > + if ((flags & M_WAITOK) != 0) > + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); > > /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option */ > random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); Doesn't it only print a warning if non-sleepable locks are held? THREAD_CAN_SLEEP() catches other cases, like epoch sections and worker threads that are not allowed to sleep (CAM doneq threads in this case). Otherwise uma_zalloc_debug() already checks with WITNESS. I'm inclined to simply revert the commit for now. Alternately, disk_alloc() could be modified to handle M_NOWAIT/M_WAITOK flags, and that could be used in daregister() and other CAM periph drivers. daregister() already uses M_NOWAIT to allocate the driver softc itself. diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c index d648d511b1a2..d940e7db24e0 100644 --- a/sys/cam/scsi/scsi_da.c +++ b/sys/cam/scsi/scsi_da.c @@ -2767,18 +2767,23 @@ daregister(struct cam_periph *periph, void *arg) return(CAM_REQ_CMP_ERR); } - softc = (struct da_softc *)malloc(sizeof(*softc), M_DEVBUF, - M_NOWAIT|M_ZERO); - + softc = malloc(sizeof(*softc), M_DEVBUF, M_NOWAIT | M_ZERO); if (softc == NULL) { printf("daregister: Unable to probe new device. " "Unable to allocate softc\n"); return(CAM_REQ_CMP_ERR); } + softc->disk = disk_alloc_flags(M_NOWAIT); + if (softc->disk == NULL) { + printf("daregister: Unable to probe new device. " + "Unable to allocate disk structure\n"); + return (CAM_REQ_CMP_ERR); + } if (cam_iosched_init(&softc->cam_iosched, periph) != 0) { printf("daregister: Unable to probe new device. " "Unable to allocate iosched memory\n"); + disk_destroy(softc->disk); free(softc, M_DEVBUF); return(CAM_REQ_CMP_ERR); } @@ -2898,7 +2903,6 @@ daregister(struct cam_periph *periph, void *arg) /* * Register this media as a disk. */ - softc->disk = disk_alloc(); softc->disk->d_devstat = devstat_new_entry(periph->periph_name, periph->unit_number, 0, DEVSTAT_BS_UNAVAILABLE, diff --git a/sys/geom/geom_disk.c b/sys/geom/geom_disk.c index eaba770828d0..c07494ab4ec0 100644 --- a/sys/geom/geom_disk.c +++ b/sys/geom/geom_disk.c @@ -850,15 +850,22 @@ g_disk_ident_adjust(char *ident, size_t size) } struct disk * -disk_alloc(void) +disk_alloc_flags(int mflag) { struct disk *dp; - dp = g_malloc(sizeof(struct disk), M_WAITOK | M_ZERO); - LIST_INIT(&dp->d_aliases); + dp = g_malloc(sizeof(struct disk), mflag | M_ZERO); + if (dp != NULL) + LIST_INIT(&dp->d_aliases); return (dp); } +struct disk * +disk_alloc(void) +{ + return (disk_alloc_flags(M_WAITOK)); +} + void disk_create(struct disk *dp, int version) { diff --git a/sys/geom/geom_disk.h b/sys/geom/geom_disk.h index 8e2282a09a3a..794ce2cc38bd 100644 --- a/sys/geom/geom_disk.h +++ b/sys/geom/geom_disk.h @@ -137,6 +137,7 @@ struct disk { #define DISKFLAG_WRITE_PROTECT 0x0100 struct disk *disk_alloc(void); +struct disk *disk_alloc_flags(int mflag); void disk_create(struct disk *disk, int version); void disk_destroy(struct disk *disk); void disk_gone(struct disk *disk); From owner-freebsd-current@freebsd.org Tue Aug 18 13:55:19 2020 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 E03A53BD18A for ; Tue, 18 Aug 2020 13:55:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWC9353tlz464Y for ; Tue, 18 Aug 2020 13:55:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id AC0623BCF4B; Tue, 18 Aug 2020 13:55:19 +0000 (UTC) Delivered-To: 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 ABCE33BCE64 for ; Tue, 18 Aug 2020 13:55:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWC930LHTz45vH; Tue, 18 Aug 2020 13:55:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x441.google.com with SMTP id f1so18385919wro.2; Tue, 18 Aug 2020 06:55:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5JbnFtOPXPUjiDtfS9oDMCq/mxcYSSaf2BpIMzPtY9g=; b=WOS8OoF6J5wB8rv3wBN5rwigI63Yfg6Pf3eAd99ZQbLvGWFXELctV+kyQOVjc1GoCB uFGrPh7U6TrKffaAQy/KC5v0dLqeA3EIzmb/jaodMWzPQMoOZHTwQXey2zU+bAIX4mcy rjaGM0VkkX2GIfZ2PbMK41CX468zh6xJZDccCIaKS0MRcsM2l+++IIhGEl3cb9inyv9U 2CeG3dsG0s9OX/A9TyySHndN/4K2sx8BgadZGYDCxo+PeW38RXsa5RWWv0k1GX1o0QJz ieRP0JMGe83AVRBUP9EvkvuUcbbRuYTUG42wQBaPrvbG7mcNkY8SLMWbwH2Igkj6pmlO PKHg== X-Gm-Message-State: AOAM533DUWxVaxM3nBS6e6px+gAv/dVEEcydyK98utV92ZUN9pNTu9nV 57pnncTcgYHgiPYsoo0xtUgL6NAHmV60wP9I9nKYqzoT X-Google-Smtp-Source: ABdhPJzx5gHWffdw8MAFmP5nBetXDoGaXMzER5SGKsIBMTEeIKAMMvEzH5qBPSHYVLBPQa19IBDAV3tFRlkN0YDpLJA= X-Received: by 2002:adf:e94c:: with SMTP id m12mr20424602wrn.109.1597758916384; Tue, 18 Aug 2020 06:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 06:55:15 -0700 (PDT) In-Reply-To: <20200818134900.GA28906@raichu> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> <20200818134900.GA28906@raichu> From: Mateusz Guzik Date: Tue, 18 Aug 2020 15:55:15 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 To: Mark Johnston Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWC930LHTz45vH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 13:55:19 -0000 On 8/18/20, Mark Johnston wrote: > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> Try this: >> >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c >> index 46eb1c4347c..7b94ca7b880 100644 >> --- a/sys/kern/kern_malloc.c >> +++ b/sys/kern/kern_malloc.c >> @@ -618,8 +618,8 @@ void * >> unsigned long osize = size; >> #endif >> >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), >> - ("malloc(M_WAITOK) in non-sleepable context")); >> + if ((flags & M_WAITOK) != 0) >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, >> __func__); >> >> #ifdef MALLOC_DEBUG >> va = NULL; >> diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c >> index 37d78354200..2e1267ec02f 100644 >> --- a/sys/vm/uma_core.c >> +++ b/sys/vm/uma_core.c >> @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int >> flags) >> uma_cache_bucket_t bucket; >> uma_cache_t cache; >> >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), >> - ("uma_zalloc(M_WAITOK) in non-sleepable context")); >> + if ((flags & M_WAITOK) != 0) >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, >> __func__); >> >> /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option >> */ >> random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); > > Doesn't it only print a warning if non-sleepable locks are held? > THREAD_CAN_SLEEP() catches other cases, like epoch sections and worker > threads that are not allowed to sleep (CAM doneq threads in this case). > Otherwise uma_zalloc_debug() already checks with WITNESS. > > I'm inclined to simply revert the commit for now. Alternately, > disk_alloc() could be modified to handle M_NOWAIT/M_WAITOK flags, and > that could be used in daregister() and other CAM periph drivers. > daregister() already uses M_NOWAIT to allocate the driver softc itself. > If WITNESS_WARN(.., WARN_SLEEPOK) does not check for all possible blockers for going off CPU that's a bug. I do support reverting the patch for now until the dust settles. I don't propose the above hack as the final fix. As for the culrpit at hand, given the backtrace: devfs_alloc() at devfs_alloc+0x28/frame 0xffffffff8218d570 make_dev_sv() at make_dev_sv+0x97/frame 0xffffffff8218d600 make_dev_s() at make_dev_s+0x3b/frame 0xffffffff8218d660 passregister() at passregister+0x3e7/frame 0xffffffff8218d8b0 I think this is missing wait flags, resulting in M_WAITOK later, i.e.: diff --git a/sys/cam/scsi/scsi_pass.c b/sys/cam/scsi/scsi_pass.c index b299fbddd84..c6d6a5da403 100644 --- a/sys/cam/scsi/scsi_pass.c +++ b/sys/cam/scsi/scsi_pass.c @@ -652,6 +652,7 @@ passregister(struct cam_periph *periph, void *arg) args.mda_gid = GID_OPERATOR; args.mda_mode = 0600; args.mda_si_drv1 = periph; + args.mda_flags = MAKEDEV_NOWAIT; error = make_dev_s(&args, &softc->dev, "%s%d", periph->periph_name, periph->unit_number); if (error != 0) { > diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c > index d648d511b1a2..d940e7db24e0 100644 > --- a/sys/cam/scsi/scsi_da.c > +++ b/sys/cam/scsi/scsi_da.c > @@ -2767,18 +2767,23 @@ daregister(struct cam_periph *periph, void *arg) > return(CAM_REQ_CMP_ERR); > } > > - softc = (struct da_softc *)malloc(sizeof(*softc), M_DEVBUF, > - M_NOWAIT|M_ZERO); > - > + softc = malloc(sizeof(*softc), M_DEVBUF, M_NOWAIT | M_ZERO); > if (softc == NULL) { > printf("daregister: Unable to probe new device. " > "Unable to allocate softc\n"); > return(CAM_REQ_CMP_ERR); > } > + softc->disk = disk_alloc_flags(M_NOWAIT); > + if (softc->disk == NULL) { > + printf("daregister: Unable to probe new device. " > + "Unable to allocate disk structure\n"); > + return (CAM_REQ_CMP_ERR); > + } > > if (cam_iosched_init(&softc->cam_iosched, periph) != 0) { > printf("daregister: Unable to probe new device. " > "Unable to allocate iosched memory\n"); > + disk_destroy(softc->disk); > free(softc, M_DEVBUF); > return(CAM_REQ_CMP_ERR); > } > @@ -2898,7 +2903,6 @@ daregister(struct cam_periph *periph, void *arg) > /* > * Register this media as a disk. > */ > - softc->disk = disk_alloc(); > softc->disk->d_devstat = devstat_new_entry(periph->periph_name, > periph->unit_number, 0, > DEVSTAT_BS_UNAVAILABLE, > diff --git a/sys/geom/geom_disk.c b/sys/geom/geom_disk.c > index eaba770828d0..c07494ab4ec0 100644 > --- a/sys/geom/geom_disk.c > +++ b/sys/geom/geom_disk.c > @@ -850,15 +850,22 @@ g_disk_ident_adjust(char *ident, size_t size) > } > > struct disk * > -disk_alloc(void) > +disk_alloc_flags(int mflag) > { > struct disk *dp; > > - dp = g_malloc(sizeof(struct disk), M_WAITOK | M_ZERO); > - LIST_INIT(&dp->d_aliases); > + dp = g_malloc(sizeof(struct disk), mflag | M_ZERO); > + if (dp != NULL) > + LIST_INIT(&dp->d_aliases); > return (dp); > } > > +struct disk * > +disk_alloc(void) > +{ > + return (disk_alloc_flags(M_WAITOK)); > +} > + > void > disk_create(struct disk *dp, int version) > { > diff --git a/sys/geom/geom_disk.h b/sys/geom/geom_disk.h > index 8e2282a09a3a..794ce2cc38bd 100644 > --- a/sys/geom/geom_disk.h > +++ b/sys/geom/geom_disk.h > @@ -137,6 +137,7 @@ struct disk { > #define DISKFLAG_WRITE_PROTECT 0x0100 > > struct disk *disk_alloc(void); > +struct disk *disk_alloc_flags(int mflag); > void disk_create(struct disk *disk, int version); > void disk_destroy(struct disk *disk); > void disk_gone(struct disk *disk); > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 14:04:24 2020 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 BBCA43BD2F4 for ; Tue, 18 Aug 2020 14:04:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWCMX3h78z46cZ for ; Tue, 18 Aug 2020 14:04:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 7E7013BD2F3; Tue, 18 Aug 2020 14:04:24 +0000 (UTC) Delivered-To: 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 7E3433BD474 for ; Tue, 18 Aug 2020 14:04:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWCMW5j4Fz46Ln for ; Tue, 18 Aug 2020 14:04:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x744.google.com with SMTP id j187so18279155qke.11 for ; Tue, 18 Aug 2020 07:04:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=rfOGAUSEH0p+ZzB6b6meRDo8eTtRmAhJ29W+wu7MNsQ=; b=HQ1qgRB7R8JILJSaSFDrk85u2OcKKdlIcqllFlQtnqGpBtdyHJDoEemGGgM9G7Jybo uXfRHpWfUOtxUZbnMygQ0r7TNxn2zAEd9wD7orcBOLWjjUYiSdwRR4GLXxOWdTB2BgDQ azjrqna5Et1VV3yzfMyx0CRFl10of82XMHMMq1QJRTvBD4ru8cJp1eyPHxhCAfFrLu4P I030ljk6yV34g/2kVhVslHaANGMPipFHWZrIueRXBHYzgXz8oWSLu18HvdFKlpwNiK8E d/GFsn4y34+ofdHVHlQjzDJJYpbFHQ/5oYnjgK8fmtkbYzi97i5BasBCVcgcRuOagJn8 s5FA== X-Gm-Message-State: AOAM5301kmf6/ngpkLxZqsW/t2RiSCqNqGKHGbY18fvjrkGQpAxpvGLh jpyNw/5XN4VmaEZANpgvtHaE6QRKJ2w= X-Google-Smtp-Source: ABdhPJwmAhRnpP24l+JUWTurbOm6eipOEvWcRA4bt5izlrUpneg51uuc08hueUOi6aYjL7XqDaJ8AA== X-Received: by 2002:a05:620a:1a:: with SMTP id j26mr17576259qki.183.1597759461902; Tue, 18 Aug 2020 07:04:21 -0700 (PDT) Received: from raichu (toroon0560w-lp130-08-67-71-176-35.dsl.bell.ca. [67.71.176.35]) by smtp.gmail.com with ESMTPSA id a8sm21963954qth.69.2020.08.18.07.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2020 07:04:21 -0700 (PDT) Sender: Mark Johnston Date: Tue, 18 Aug 2020 10:04:19 -0400 From: Mark Johnston To: Mateusz Guzik Cc: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818140419.GB28906@raichu> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> <20200818134900.GA28906@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4BWCMW5j4Fz46Ln X-Spamd-Bar: / X-Spamd-Result: default: False [-0.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::744:from]; NEURAL_HAM_SHORT(-0.47)[-0.473]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 14:04:24 -0000 On Tue, Aug 18, 2020 at 03:55:15PM +0200, Mateusz Guzik wrote: > On 8/18/20, Mark Johnston wrote: > > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: > >> Try this: > >> > >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c > >> index 46eb1c4347c..7b94ca7b880 100644 > >> --- a/sys/kern/kern_malloc.c > >> +++ b/sys/kern/kern_malloc.c > >> @@ -618,8 +618,8 @@ void * > >> unsigned long osize = size; > >> #endif > >> > >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), > >> - ("malloc(M_WAITOK) in non-sleepable context")); > >> + if ((flags & M_WAITOK) != 0) > >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, > >> __func__); > >> > >> #ifdef MALLOC_DEBUG > >> va = NULL; > >> diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c > >> index 37d78354200..2e1267ec02f 100644 > >> --- a/sys/vm/uma_core.c > >> +++ b/sys/vm/uma_core.c > >> @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int > >> flags) > >> uma_cache_bucket_t bucket; > >> uma_cache_t cache; > >> > >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), > >> - ("uma_zalloc(M_WAITOK) in non-sleepable context")); > >> + if ((flags & M_WAITOK) != 0) > >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, > >> __func__); > >> > >> /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option > >> */ > >> random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); > > > > Doesn't it only print a warning if non-sleepable locks are held? > > THREAD_CAN_SLEEP() catches other cases, like epoch sections and worker > > threads that are not allowed to sleep (CAM doneq threads in this case). > > Otherwise uma_zalloc_debug() already checks with WITNESS. > > > > I'm inclined to simply revert the commit for now. Alternately, > > disk_alloc() could be modified to handle M_NOWAIT/M_WAITOK flags, and > > that could be used in daregister() and other CAM periph drivers. > > daregister() already uses M_NOWAIT to allocate the driver softc itself. > > > > If WITNESS_WARN(.., WARN_SLEEPOK) does not check for all possible > blockers for going off CPU that's a bug. I do support reverting the > patch for now until the dust settles. I don't propose the above hack > as the final fix. Well, IMO the bug is that we have no subroutine to perform all of these checks (which includes those done by WITNESS_WARN(..., WARN_SLEEPOK)). WITNESS' responsibilities are more narrow. I just meant that your patch effectively reverts Gleb's commit. > As for the culrpit at hand, given the backtrace: > devfs_alloc() at devfs_alloc+0x28/frame 0xffffffff8218d570 > make_dev_sv() at make_dev_sv+0x97/frame 0xffffffff8218d600 > make_dev_s() at make_dev_s+0x3b/frame 0xffffffff8218d660 > passregister() at passregister+0x3e7/frame 0xffffffff8218d8b0 > > I think this is missing wait flags, resulting in M_WAITOK later, i.e.: Ah, I was looking at a different report. All the more reason to revert for now. From owner-freebsd-current@freebsd.org Tue Aug 18 14:13:33 2020 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 9D9D43BD94C for ; Tue, 18 Aug 2020 14:13:33 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWCZ536r8z47Xg for ; Tue, 18 Aug 2020 14:13:33 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 6B0223BDC13; Tue, 18 Aug 2020 14:13:33 +0000 (UTC) Delivered-To: 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 6ACCF3BD8CB for ; Tue, 18 Aug 2020 14:13:33 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWCZ46h7Wz479q; Tue, 18 Aug 2020 14:13:32 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id 3so17160763wmi.1; Tue, 18 Aug 2020 07:13:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IwwtP5GQJ1+n0mFq8KScVIL2H3LzucYzG6bE8xIfLUA=; b=Dfo5PKBovXcyxA0bOWg7IAbhxnmuIqRp585puJefBfeKJG+SViG4FcQ7SMCYvP4gP4 4IxTnj6oQObQYXl7O4+MXGlRO72GxWO5tpHcQl1YExo6jiIMpkNA5pXToZLYlYUTJyMx 1cTcJcOnbqPdy3d2kglBaSpJ+jk7dymptTxBl0Iecnw8UGBmwaZPjhhcKOY8Dzum89zA BYpIqJBabnh6Epk2bnDhJrri4tD8hsHgxRl06CYCxLLQsiQ85dExGlBemomWfwt7qtSb ZpbnjCTZLnHyhMp8mABzFIxGzfR2+1B4wATAjmZXaXAdydpLXGLkNHZjgCF4Sqz+rKgG 8GuA== X-Gm-Message-State: AOAM532BPN6slAS1r02/wkkeryd7Dv5ubLe/W9+mq01EkAzJ5q3WklGu oCSN04HxC1Y/xENH1BdyM8bZz7IgkrxM8jx48F7HQjXl X-Google-Smtp-Source: ABdhPJxTkbX4yO5LHpEWmITSxvAOZaSZCce+ZaYGwRMHjjcoJAm8WKV0mqt7e0tMB+VFaoV84Nd0+HFTcgUpl9IrcXY= X-Received: by 2002:a7b:cb98:: with SMTP id m24mr179375wmi.10.1597760011082; Tue, 18 Aug 2020 07:13:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:614c:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 07:13:30 -0700 (PDT) In-Reply-To: <20200818140419.GB28906@raichu> References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> <20200818134900.GA28906@raichu> <20200818140419.GB28906@raichu> From: Mateusz Guzik Date: Tue, 18 Aug 2020 16:13:30 +0200 Message-ID: Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 To: Mark Johnston Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWCZ46h7Wz479q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 14:13:33 -0000 On 8/18/20, Mark Johnston wrote: > On Tue, Aug 18, 2020 at 03:55:15PM +0200, Mateusz Guzik wrote: >> On 8/18/20, Mark Johnston wrote: >> > On Tue, Aug 18, 2020 at 03:24:52PM +0200, Mateusz Guzik wrote: >> >> Try this: >> >> >> >> diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c >> >> index 46eb1c4347c..7b94ca7b880 100644 >> >> --- a/sys/kern/kern_malloc.c >> >> +++ b/sys/kern/kern_malloc.c >> >> @@ -618,8 +618,8 @@ void * >> >> unsigned long osize = size; >> >> #endif >> >> >> >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), >> >> - ("malloc(M_WAITOK) in non-sleepable context")); >> >> + if ((flags & M_WAITOK) != 0) >> >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, >> >> __func__); >> >> >> >> #ifdef MALLOC_DEBUG >> >> va = NULL; >> >> diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c >> >> index 37d78354200..2e1267ec02f 100644 >> >> --- a/sys/vm/uma_core.c >> >> +++ b/sys/vm/uma_core.c >> >> @@ -3355,8 +3355,8 @@ uma_zalloc_arg(uma_zone_t zone, void *udata, int >> >> flags) >> >> uma_cache_bucket_t bucket; >> >> uma_cache_t cache; >> >> >> >> - KASSERT((flags & M_WAITOK) == 0 || THREAD_CAN_SLEEP(), >> >> - ("uma_zalloc(M_WAITOK) in non-sleepable context")); >> >> + if ((flags & M_WAITOK) != 0) >> >> + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, >> >> __func__); >> >> >> >> /* Enable entropy collection for RANDOM_ENABLE_UMA kernel >> >> option >> >> */ >> >> random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); >> > >> > Doesn't it only print a warning if non-sleepable locks are held? >> > THREAD_CAN_SLEEP() catches other cases, like epoch sections and worker >> > threads that are not allowed to sleep (CAM doneq threads in this case). >> > Otherwise uma_zalloc_debug() already checks with WITNESS. >> > >> > I'm inclined to simply revert the commit for now. Alternately, >> > disk_alloc() could be modified to handle M_NOWAIT/M_WAITOK flags, and >> > that could be used in daregister() and other CAM periph drivers. >> > daregister() already uses M_NOWAIT to allocate the driver softc itself. >> > >> >> If WITNESS_WARN(.., WARN_SLEEPOK) does not check for all possible >> blockers for going off CPU that's a bug. I do support reverting the >> patch for now until the dust settles. I don't propose the above hack >> as the final fix. > > Well, IMO the bug is that we have no subroutine to perform all of these > checks (which includes those done by WITNESS_WARN(..., WARN_SLEEPOK)). > WITNESS' responsibilities are more narrow. I just meant that your patch > effectively reverts Gleb's commit. > not exactly, as it still adds something for malloc. I argued for a dedicated routine to perform all the relevant checks. Note a dedicated routine instead of a handrolled call to witness/panic/whatever can also report the exact blockers (if it knows them), in this case what lock was taken and where. I would not mind any extras (e.g., critnest). >> As for the culrpit at hand, given the backtrace: >> devfs_alloc() at devfs_alloc+0x28/frame 0xffffffff8218d570 >> make_dev_sv() at make_dev_sv+0x97/frame 0xffffffff8218d600 >> make_dev_s() at make_dev_s+0x3b/frame 0xffffffff8218d660 >> passregister() at passregister+0x3e7/frame 0xffffffff8218d8b0 >> >> I think this is missing wait flags, resulting in M_WAITOK later, i.e.: > > Ah, I was looking at a different report. All the more reason to revert > for now. > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Tue Aug 18 15:08:48 2020 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 5823A3BECBC for ; Tue, 18 Aug 2020 15:08:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWDnr0rzGz4Cvq for ; Tue, 18 Aug 2020 15:08:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1B8D43BECBB; Tue, 18 Aug 2020 15:08:48 +0000 (UTC) Delivered-To: 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 1B4E43BEE89 for ; Tue, 18 Aug 2020 15:08:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWDnp4fFPz4CcB for ; Tue, 18 Aug 2020 15:08:46 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 07IF8iR3030373; Tue, 18 Aug 2020 15:08:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 07IF8iDt030372; Tue, 18 Aug 2020 08:08:44 -0700 (PDT) (envelope-from david) Date: Tue, 18 Aug 2020 08:08:44 -0700 From: David Wolfskill To: Mateusz Guzik Cc: current@freebsd.org Subject: Re: "panic: malloc(M_WAITOK) in non-sleepable context" after r364296 -> r364341 Message-ID: <20200818150844.GR1394@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Mateusz Guzik References: <20200818124419.GO1394@albert.catwhisker.org> <20200818125825.GP1394@albert.catwhisker.org> <20200818132902.GQ1394@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w/cbcIkiD1zHilas" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4BWDnp4fFPz4CcB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; SIGNED_PGP(-2.00)[]; DMARC_NA(0.00)[catwhisker.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.01)[-1.008]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 15:08:48 -0000 --w/cbcIkiD1zHilas Content-Type: multipart/mixed; boundary="Aq6vH1t1JS3Uc7g3" Content-Disposition: inline --Aq6vH1t1JS3Uc7g3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 03:37:50PM +0200, Mateusz Guzik wrote: > So the previous patch should just print a warning. >=20 > Does this take care of the problem in general? I don't have means to > test the patch. > .... Sorry for the delay, but finished patching & rebuilding, and (essentially), yes. (The difference is that I replaced all 3 of the KASSERT()s from r364310 with the WITNESS_WARN() constructs, rather than only 2.) FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #1004 r3= 64296M/364296: Mon Aug 17 06:04:40 PDT 2020 root@freebeast.catwhisker.o= rg:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300109 1300109 FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #1006 r3= 64341M/364341: Tue Aug 18 06:59:10 PDT 2020 root@freebeast.catwhisker.o= rg:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300110 1300110 Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump is either ignorant of how to govern or is refusing to do so. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Aq6vH1t1JS3Uc7g3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: quoted-printable Index: sys/kern/kern_malloc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_malloc.c (revision 364341) +++ sys/kern/kern_malloc.c (working copy) @@ -618,8 +618,8 @@ unsigned long osize =3D size; #endif =20 - KASSERT((flags & M_WAITOK) =3D=3D 0 || THREAD_CAN_SLEEP(), - ("malloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) !=3D 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); =20 #ifdef MALLOC_DEBUG va =3D NULL; Index: sys/vm/uma_core.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/vm/uma_core.c (revision 364341) +++ sys/vm/uma_core.c (working copy) @@ -3328,8 +3328,8 @@ uma_cache_bucket_t bucket; uma_cache_t cache; =20 - KASSERT((flags & M_WAITOK) =3D=3D 0 || THREAD_CAN_SLEEP(), - ("uma_zalloc_smr(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) !=3D 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); =20 #ifdef UMA_ZALLOC_DEBUG void *item; @@ -3355,8 +3355,8 @@ uma_cache_bucket_t bucket; uma_cache_t cache; =20 - KASSERT((flags & M_WAITOK) =3D=3D 0 || THREAD_CAN_SLEEP(), - ("uma_zalloc(M_WAITOK) in non-sleepable context")); + if ((flags & M_WAITOK) !=3D 0) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); =20 /* Enable entropy collection for RANDOM_ENABLE_UMA kernel option */ random_harvest_fast_uma(&zone, sizeof(zone), RANDOM_UMA); --Aq6vH1t1JS3Uc7g3-- --w/cbcIkiD1zHilas Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl877vxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PclbjQf7BLuygQt/oo7HXOy9FxquzsE4HQOjAxESlzdmfZQrGfkjj5e0sGfkQc2N Ld3ULkRINunhN47gqGNwWHA+ZTGTTtoH0HqwJSpGL/W/Vi7C1MPEcWxmwvx7BmFS cp7R8o3W/TWA8gW81lyPip2ik9Q8CrPSVK8iz+R4a6wUeTQyXwjwpJnBnmcQg+lJ kpfrYGmi3L9Lg/HKx9VGDJWG/kUN+g8/L94iKQ5rVlkvWy41j8Cc2ZF0x68PXV88 tKyfVNBG2VGaSEKRHQaibGT7Zl2M3PwWGvXMpcskxX8qxhPYLy4Al/YxRProYuXp J6YhuRIq5bwc/BMXsRMvi9aOZRlE7g== =2C9k -----END PGP SIGNATURE----- --w/cbcIkiD1zHilas-- From owner-freebsd-current@freebsd.org Tue Aug 18 20:19:30 2020 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 AA4F53C6035 for ; Tue, 18 Aug 2020 20:19:30 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWMhK5lgVz4bY5 for ; Tue, 18 Aug 2020 20:19:29 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id A3E202D5E5 for ; Tue, 18 Aug 2020 16:19:19 -0400 (EDT) To: FreeBSD Current From: Michael Butler Subject: kldref: too many segments on kernel build Message-ID: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> Date: Tue, 18 Aug 2020 16:19:18 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Language: en-NZ Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWMhK5lgVz4bY5 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.08)[-0.077]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 20:19:30 -0000 Any thoughts as to why this is happening when I build a (custom) kernel? kldxref: /boot/kernel/kernel: too many segments imb From owner-freebsd-current@freebsd.org Tue Aug 18 20:45:53 2020 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 9076F3C6971 for ; Tue, 18 Aug 2020 20:45:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BWNGn2lSRz4dG0 for ; Tue, 18 Aug 2020 20:45:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 5B4373C6E8B; Tue, 18 Aug 2020 20:45:53 +0000 (UTC) Delivered-To: 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 59AD33C6CA5; Tue, 18 Aug 2020 20:45:53 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWNGl74N0z4dNL; Tue, 18 Aug 2020 20:45:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 07IKjg5A084740 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 Aug 2020 23:45:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 07IKjg5A084740 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 07IKjg8U084739; Tue, 18 Aug 2020 23:45:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Aug 2020 23:45:42 +0300 From: Konstantin Belousov To: arch@freebsd.org, current@freebsd.org Subject: Process group orphaning fixes Message-ID: <20200818204542.GR2551@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BWNGl74N0z4dNL X-Spamd-Bar: / X-Spamd-Result: default: False [0.87 / 15.00]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.87)[0.868]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MAILMAN_DEST(0.00)[arch,current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 18 Aug 2020 20:45:53 -0000 I fixed several issues in our handling of the process group job control state, biggest of which was uncovered by the reaping facility. The bugs demostrate itself and underflow (and probably overflow) of pgrp->pg_jobc, that was reported as panics with added and then removed asserts. Feel free to participate in review at https://reviews.freebsd.org/D26116. See the review summary for more detailed description of the bugs and the patch itself. Targeted tests were narrowed down by Peter Holm, who also tested the proposed patch. From owner-freebsd-current@freebsd.org Wed Aug 19 01:22:04 2020 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 1A5FD3AD50A for ; Wed, 19 Aug 2020 01:22:04 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWVPQ6GJqz3y1y for ; Wed, 19 Aug 2020 01:22:02 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-io1-xd42.google.com with SMTP id z6so23134874iow.6 for ; Tue, 18 Aug 2020 18:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ii5nwrnyGtKq6hD9tzTSScn97OQOcHBTFSQAj2JEK10=; b=qei5uDYToBQOtI4dL4t6V3D9Kg4FsUa2z2ZXoR1QnDj1IGeWq6cwLfRDjxtJPuJEP8 cQU6iLez2qEF9zllj+m/744KuXZNGcS7Rl0LP4K99MV1R++kS7In9RdmPDuCK1Y/DpVc btj7ZEOxFSXGIQ0tVDTdtLeACb7eWpVBgiIWH0XOfmfvEbp5wN+Zy0lZ7m8KVTNbgFjA 48CdY5i1GHETfFt/IV3EaENrOvKdW1KlQqvn5tYizUfJeT+R68e7ULE1LmvG7LhJcWCE r3tQEFqluNklUlshoKUcv0XrmA4fEglL3TN7Z/FRjVn543mduUvSuleDPGA6ReppuWZ8 bk/Q== X-Gm-Message-State: AOAM533m4lM+vXmeMR2RL56SJ7txwL2BuJM15WROwPxDxI9VFAl3Pkjg MWKzxN6kDWaOwIIqHbxL+H3jnL+Et5umSWE166NnnHzC3tVP/g== X-Google-Smtp-Source: ABdhPJyZZZCUs4PgVJfTlnGlAUHv9DDnR/VmF4/vYsWFvIwrtkn8FZE6PEu5w+rKpm+jq2WRiiVXDeWlhlkuOwpqLG4= X-Received: by 2002:a05:6638:2595:: with SMTP id s21mr21341317jat.12.1597800121314; Tue, 18 Aug 2020 18:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:6107:0:0:0:0:0 with HTTP; Tue, 18 Aug 2020 18:22:00 -0700 (PDT) From: "Lizbeth Mutterhunt, Ph.D" Date: Wed, 19 Aug 2020 03:22:00 +0200 Message-ID: Subject: funny thing with the drm0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWVPQ6GJqz3y1y X-Spamd-Bar: - X-Spamd-Result: default: False [-1.45 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d42:from]; NEURAL_HAM_SHORT(-0.45)[-0.454]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 01:22:04 -0000 After having had some near-death-experiences in Greece I'm back to my screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) But this is the experience with my Dell Vostro on 13 current: After finally recompiling the kernel with the drm-module inside and the trick of injecting the device IWNFW I get a *nice* message a bootup: Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 20060810 Aug 19 02:51:10 current kernel: drmn0: on vgapci0 Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics device = 2048M Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. Graphics performance may suffer. Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 Aug 19 02:51:10 current kernel: iicbus0: on iicbb_nostop0 addr 0x1 Aug 19 02:51:10 current kernel: iic0: on iicbus0 Aug 19 02:51:10 current kernel: iicbus1: on intel_gmbus0 Aug 19 02:51:10 current kernel: iic1: on iicbus1 Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 Aug 19 02:51:10 current kernel: iicbus2: on iicbb_nostop1 addr 0x12 Aug 19 02:51:10 current kernel: iic2: on iicbus2 Aug 19 02:51:10 current kernel: iicbus3: on intel_gmbus1 Aug 19 02:51:10 current kernel: iic3: on iicbus3 Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 Aug 19 02:51:10 current kernel: iicbus4: on iicbb_nostop2 addr 0x12 Aug 19 02:51:10 current kernel: iic4: on iicbus4 Aug 19 02:51:10 current kernel: iicbus5: on intel_gmbus2 Aug 19 02:51:10 current kernel: iic5: on iicbus5 Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 Aug 19 02:51:10 current kernel: iicbus6: on iicbb_nostop3 addr 0x12 Aug 19 02:51:10 current kernel: iic6: on iicbus6 Aug 19 02:51:10 current kernel: iicbus7: on intel_gmbus3 Aug 19 02:51:10 current kernel: iic7: on iicbus7 Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 Aug 19 02:51:10 current kernel: iicbus8: on iicbb_nostop4 addr 0x12 Aug 19 02:51:10 current kernel: iic8: on iicbus8 Aug 19 02:51:10 current kernel: iicbus9: on intel_gmbus4 Aug 19 02:51:10 current kernel: iic9: on iicbus9 Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 Aug 19 02:51:10 current kernel: iicbus10: on iicbb_nostop5 addr 0x12 And furthermore: Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.201> Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise vblank timestamp query. Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious range 0xe0000000-0xf0000000 Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode from tunables: Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode from tunables: Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get mode from tunables: Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.HDMI-A-1 Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode from tunables: Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode Aug 19 02:51:10 current kernel: fbd0 on drmn0 Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked and may be deleted before> Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new "fb". ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 so far so good, quality of text in grafics 1368x1024 is perfectly initialized. but now, when starting xinit or lightdm or sddm or whatever I get a kernel panic: Dump header from device: /dev/ada0p4 Architecture: i386 Architecture Version: 4 Dump Length: 97792 Blocksize: 512 Compression: none Dumptime: 2020-08-19 02:49:00 +0200 Hostname: current Magic: FreeBSD Text Dump Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 CEST 2020 root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ /usr/src/sys/vm/vm> Dump Parity: 2773167169 Bounds: 1 Dump Status: good /var/crash/vmcore.0 not found First thing I think is kern options: options WITNESS_SKIPSPIN options WITNESS I disabled device HYPERV but this can't be the reason, kern is being compiled with clang. To disable WITNESS would be one way I think but this can't be the yellw of the egg, isn't it? Another thing but I guess having nothing to do with bug above is on rather the end of startup: Aug 19 02:51:10 current savecore[1209]: reboot after panic: vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ /usr/src/sys/vm/vm_page.c:1609 Aug 19 02:51:10 current savecore[1209]: writing core to /var/crash/textdump.tar.1 Aug 19 02:51:10 current kernel: linsysfs: Aug 19 02:51:10 current kernel: Device busy Aug 19 02:51:10 current kernel: lock order reversal: Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1008 Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1019 Aug 19 02:51:10 current kernel: lock order devfs -> ufs established at: Aug 19 02:51:10 current kernel: #0 0x1027cd5 at witness_checkorder+0x3c5 Aug 19 02:51:10 current kernel: #1 0xf9cca0 at lockmgr_lock_flags+0x140 Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 Aug 19 02:51:10 current kernel: #12 0xffc0340e at __stop_set_sysinit_set+0xd0a4199e Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: Aug 19 02:51:10 current kernel: #0 0x1028360 at witness_checkorder+0xa50 Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 Aug 19 02:51:10 current kernel: #9 0xffc033f9 at __stop_set_sysinit_set+0xd0a41989 any ideas? Miranda does someone know how to fix it? Miranda From owner-freebsd-current@freebsd.org Wed Aug 19 04:19:24 2020 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 793A53B0C75 for ; Wed, 19 Aug 2020 04:19:24 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWZL13JLnz483T for ; Wed, 19 Aug 2020 04:19:21 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ed1-x52d.google.com with SMTP id l23so16971635edv.11 for ; Tue, 18 Aug 2020 21:19:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3OcN9TPbUsMpQ1dnjzxkXzQpoDiF7jtzkatfZ2ZP/pk=; b=JeFKRDTY5/nQicAP1D0DA9uqCAj/wuKrYECOr+xXgVNaOtHTsW/7k7tHV67LpxIOpt kW0R5OAiTbhmaqvuq7tdhJUR39EHLi5gf/LcLDywGAuH8lnsL1sOrBjRFWBYMqY+nH/W VM8zFLfk+b+j03z6SyYVDZlIfDPKve2oCVQYvqTEHEswlxquKlcTbmobnYRH2YHvmM6a aREIezWSPOJp6aIUtnvWl8AthMlzVrfvSLxbvTImT3WjcJS/B/tAk0YsaFlmT9ZTHzg0 WjZOId/fSqxLvDVQx3a3/0W9wcqicqLnENHGULWKelKd8UCPcLckaOkZ6R2PcYPLdP+l 9/vw== X-Gm-Message-State: AOAM533CoBWAw26uGMu5yK6mC9hZ527Dxhk+ni3qzJW10ufJO2dvFIqW NNNdkRsas98g/swPVG2uc9laYmIBILA4qUirGIsH4IoZhAw= X-Google-Smtp-Source: ABdhPJxkkVgMaWlwIrV0xShRWvbjCL0SA8AOcg6IJbnn9siyJXdkUEgPLdtqv/SHYutLtcfAXMlCi9JBKosq+ynONO4= X-Received: by 2002:a05:6402:33a:: with SMTP id q26mr24160774edw.8.1597810759116; Tue, 18 Aug 2020 21:19:19 -0700 (PDT) MIME-Version: 1.0 References: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> In-Reply-To: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> From: Dustin Marquess Date: Tue, 18 Aug 2020 23:19:08 -0500 Message-ID: Subject: Re: kldref: too many segments on kernel build To: Michael Butler Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWZL13JLnz483T X-Spamd-Bar: - X-Spamd-Result: default: False [-1.55 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from]; NEURAL_HAM_SHORT(-0.55)[-0.549]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 04:19:24 -0000 On Tue, Aug 18, 2020 at 3:19 PM Michael Butler wrote: > > Any thoughts as to why this is happening when I build a (custom) kernel? > > kldxref: /boot/kernel/kernel: too many segments I'm seeing this too. I haven't tried actually booting the kernel because of this. -Dustin From owner-freebsd-current@freebsd.org Wed Aug 19 07:30:01 2020 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 734CF3B4870 for ; Wed, 19 Aug 2020 07:30:01 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWfZ00RQvz4Kj0 for ; Wed, 19 Aug 2020 07:29:59 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x342.google.com with SMTP id k20so1125095wmi.5 for ; Wed, 19 Aug 2020 00:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=zuhOn1CU5xBkSyKtZaZKdVRY8cerGdjxuNY7Q4D9V2c=; b=pgl/mKNTMXaYp2SdyJ2YRYYWfuD3Oe36Lr9KDKAGC1llzjkQw3uEBMXbsqSDls2rgM pESegi0zfG7yfEU7LpX3qvhIDoNLkdP7UeG76TsEodkKGAG8sXDv63pv41dHHeORp4NT tQqTGLhm8e14LiyUJblQwLLUv07PlACQ0YAwNZWQx48AGKMQ4mW15BgZm/Tcq9W2D8aU 0mM0hwmtWCY/g5I9ZZXiTOwN1xTcCXmxdYElZxO6vra/6fm7jWlETwwihn7QGdf09n9j ghScVTxnoSuZbYb0YHPPgynA7Z/MsCpb6njeV2Mr9B2TvkL+QvdMaUT2k3IG8ElcJM0i KQcw== X-Gm-Message-State: AOAM531dqdwmJK5vD3NCyYQMxgse72qK3Fhy3wgmAyqpc3YpuhnMoXET 2d1Kg/GF7QW/jEepaY1GmUA= X-Google-Smtp-Source: ABdhPJzLxCCLSyLHmooR2M0VOjTQDO4p5Eye6scKZb0l8eLBlxiMhUGh7GNgEHfTSX9hbv09tug+KQ== X-Received: by 2002:a1c:5581:: with SMTP id j123mr3611417wmb.11.1597822198440; Wed, 19 Aug 2020 00:29:58 -0700 (PDT) Received: from ernst.home (pd9e23482.dip0.t-ipconnect.de. [217.226.52.130]) by smtp.gmail.com with ESMTPSA id b8sm38710938wrv.4.2020.08.19.00.29.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 00:29:57 -0700 (PDT) Date: Wed, 19 Aug 2020 09:29:56 +0200 From: Gary Jennejohn To: Dustin Marquess Cc: Michael Butler , FreeBSD Current Subject: Re: kldref: too many segments on kernel build Message-ID: <20200819092956.17656747@ernst.home> In-Reply-To: References: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BWfZ00RQvz4Kj0 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.89 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[217.226.52.130:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.11)[0.111]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::342:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 07:30:01 -0000 On Tue, 18 Aug 2020 23:19:08 -0500 Dustin Marquess wrote: > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. > Same here, but I was able to boot the kernel (installed to /boot/test) with no errors. But Xorg fails to start. That may not be related to the kldxref error itself but is perhaps due to other changes in the kernel which cause the Nvidia driver to fail at startup. I'm not willing to rebuild the Nvidia driver to test my hypothesis. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Aug 19 07:32:53 2020 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 DA32C3B4E65 for ; Wed, 19 Aug 2020 07:32:53 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWfdK3sWTz4LN6 for ; Wed, 19 Aug 2020 07:32:53 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:8108:5ab5:4ce3:914d] (unknown [IPv6:2a02:8109:1140:c3d:8108:5ab5:4ce3:914d]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id BC6B2721E282E; Wed, 19 Aug 2020 09:32:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: kldref: too many segments on kernel build From: Michael Tuexen In-Reply-To: Date: Wed, 19 Aug 2020 09:32:47 +0200 Cc: Michael Butler , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> To: Dustin Marquess X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4BWfdK3sWTz4LN6 X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 07:32:53 -0000 > On 19. Aug 2020, at 06:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: >> >> Any thoughts as to why this is happening when I build a (custom) kernel? >> >> kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. I also see this... The kernel boots just fine. Best regards Michael > > -Dustin > _______________________________________________ > 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 Wed Aug 19 07:43:38 2020 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 C09123B5C08 for ; Wed, 19 Aug 2020 07:43:38 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWfsj4DP2z4MWg for ; Wed, 19 Aug 2020 07:43:37 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lj1-x22c.google.com with SMTP id v12so24292419ljc.10 for ; Wed, 19 Aug 2020 00:43:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=17uzKgRr1ajxn3fHK7guo7XHTAlf3SkiEOkNt632oRQ=; b=f8Zsly7CdiGJoYMAtybqywjtDSI6Jfb4WbE1KL7pCfxDEKa1y+vqtvmIrf0s1e4xXe LJXMIWOs7EJNeLxYN58vGglF0jsR+4BhCbwt+x/sm7yiF28xc0Iz6HwcqLCfEwmA1IT0 tq1+h9jC31wNeXoCB/k8wKJp4zEszqbY7uoLivN13nwqSkQzq/IXgWdI0inT63w9jIDP 9/2KG4C4lWKVvIAGfKj31rYy+8j/Fcux5Jmt/i/IDrz5rE9vjzqhZQwMflucXI+PC9Lx h48+MATY8LZHIdHMAE+BRhUvP/R/y/zL/doMl7j9KWwnNI6iVv3EQqhThDiIMesgjOJF Cp/w== X-Gm-Message-State: AOAM533Ugp5LxuYmTpJmQOEqI/r0u5+6PBiyN6Cnh3h0ZY/DKiuUi6q3 ZywQ88a/VqI3BWrK2b7Pz2XpFpQgzlBldaF0MBk= X-Google-Smtp-Source: ABdhPJwJ/57uuhyPoQE+TXFP5lOIjDTeNFyT8yVBltrEAqgMx56J23B/zcKxUFLtRkHeSapbY69GsI0/QmF3uBMbFg8= X-Received: by 2002:a2e:b6d4:: with SMTP id m20mr12360025ljo.465.1597823014344; Wed, 19 Aug 2020 00:43:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andreas Nilsson Date: Wed, 19 Aug 2020 09:43:21 +0200 Message-ID: Subject: Re: funny thing with the drm0 To: "Lizbeth Mutterhunt, Ph.D" Cc: Current FreeBSD X-Rspamd-Queue-Id: 4BWfsj4DP2z4MWg X-Spamd-Bar: / X-Spamd-Result: default: False [-0.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_SHORT(0.03)[0.027]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 07:43:38 -0000 On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < lizbethmutterhunt@gmail.com> wrote: > After having had some near-death-experiences in Greece I'm back to my > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > But this is the experience with my Dell Vostro on 13 current: > > > After finally recompiling the kernel with the drm-module inside and > the trick of injecting the > This is not the way to do it. Modern hardware require drm-kmod from ports, or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > > device IWNFW > Again, this is not needed, firmware is autoloaded on module load. Just add if_iwn to kld_list in /etc/rc.conf > > I get a *nice* message a bootup: > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 20060810 > Aug 19 02:51:10 current kernel: drmn0: on vgapci0 > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > device = 2048M > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > Graphics performance may suffer. > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > Aug 19 02:51:10 current kernel: iicbus0: on > iicbb_nostop0 addr 0x1 > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > Aug 19 02:51:10 current kernel: iicbus1: on intel_gmbus0 > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > Aug 19 02:51:10 current kernel: iicbus2: on > iicbb_nostop1 addr 0x12 > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > Aug 19 02:51:10 current kernel: iicbus3: on intel_gmbus1 > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > Aug 19 02:51:10 current kernel: iicbus4: on > iicbb_nostop2 addr 0x12 > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > Aug 19 02:51:10 current kernel: iicbus5: on intel_gmbus2 > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > Aug 19 02:51:10 current kernel: iicbus6: on > iicbb_nostop3 addr 0x12 > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > Aug 19 02:51:10 current kernel: iicbus7: on intel_gmbus3 > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > Aug 19 02:51:10 current kernel: iicbus8: on > iicbb_nostop4 addr 0x12 > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > Aug 19 02:51:10 current kernel: iicbus9: on intel_gmbus4 > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > Aug 19 02:51:10 current kernel: iicbus10: on > iicbb_nostop5 addr 0x12 > > And furthermore: > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > caching Rev 1 (10.10.201> > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > vblank timestamp query. > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > range 0xe0000000-0xf0000000 > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > mode from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.HDMI-A-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > from tunables: > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > and may be deleted before> > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new "fb". > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > 20080730 for drmn0 on minor 0 > > so far so good, quality of text in grafics 1368x1024 is perfectly > initialized. but now, when starting xinit or lightdm or sddm or > whatever I get a kernel panic: > > Dump header from device: /dev/ada0p4 > Architecture: i386 > Architecture Version: 4 > Dump Length: 97792 > Blocksize: 512 > Compression: none > Dumptime: 2020-08-19 02:49:00 +0200 > Hostname: current > Magic: FreeBSD Text Dump > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > CEST 2020 > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > busy @ /usr/src/sys/vm/vm> > Dump Parity: 2773167169 > Bounds: 1 > Dump Status: good > > /var/crash/vmcore.0 not found > Do you have dumpdev="AUTO" in /etc/rc.conf ? > > First thing I think is kern options: > > options WITNESS_SKIPSPIN > options WITNESS > > I disabled device HYPERV but this can't be the reason, kern is being > compiled with clang. > Clang is the default since a long time. > > To disable WITNESS would be one way I think but this can't be the > yellw of the egg, isn't it? > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some performance improvements. > > Another thing but I guess having nothing to do with bug above is on > rather the end of startup: > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > /usr/src/sys/vm/vm_page.c:1609 > Aug 19 02:51:10 current savecore[1209]: writing core to > /var/crash/textdump.tar.1 > Aug 19 02:51:10 current kernel: linsysfs: > Aug 19 02:51:10 current kernel: Device busy > Aug 19 02:51:10 current kernel: lock order reversal: > Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ > /usr/src/sys/kern/vfs_mount.c:1008 > Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) > @ /usr/src/sys/kern/vfs_mount.c:1019 > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established at: > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at witness_checkorder+0x3c5 > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at lockmgr_lock_flags+0x140 > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > __stop_set_sysinit_set+0xd0a4199e > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > Aug 19 02:51:10 current kernel: #0 0x1028360 at witness_checkorder+0xa50 > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > __stop_set_sysinit_set+0xd0a41989 > > any ideas? > Miranda > > > > does someone know how to fix it? > > Miranda > Hope this helps. Best regards Andreas Nilsson From owner-freebsd-current@freebsd.org Wed Aug 19 08:27:33 2020 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 1BCAE3B6E04; Wed, 19 Aug 2020 08:27:33 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWgrM45Qdz4PpN; Wed, 19 Aug 2020 08:27:31 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi1-x22f.google.com with SMTP id l204so20312052oib.3; Wed, 19 Aug 2020 01:27:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YeLNXkEWWaCaNFkwI2FLx9WtMT7ddiWBVWP7oVooA7k=; b=f2Qo8zxSAqIRNchQbdS8RT7N9tSwtyTdMpUxseKvf8LMZqoesUWyuEOgirx+nnPkQ4 M3Fp8BCa2jInmelk+XDXHCIPDBtipPSk0rTpjRwndUryD6wlscx+/uA0j0GMMULhUoC/ v5mJRMqC/jj9v+iER1EulKwsmRs9T0z3rsUy6ib+/y23TOHmj05mHUZHRnKGBgfMUEI7 JrVWwL7fHLX5Rv4gKIH8P5rAYde3o5CTgPTAEhUZZE+hPwDDUXkgjtqlH30DGCfMQcFA zr7jFbYoV2G0339QGh2+Kz+BlI9Mjgkp66gs2Sk6PDmsDYASr1obv5PHSKpUw/RiyOad YoyQ== X-Gm-Message-State: AOAM5325e9yuvB2hsQ//e0j272dQZQ7OQ8PnpRxIrQ1Mia9/4w/TOPM2 km7+oTIc54JknWZfn+Uvoj0lia8DUPry25OUka0= X-Google-Smtp-Source: ABdhPJwDITG4eHzECc/n59gF4lpAYKo6AWlxkpGVUa+B5HUpZkpGZZ0kwlv+gV7W3Zt5U9RO117gwNYbqIW4abFDLOg= X-Received: by 2002:aca:ec02:: with SMTP id k2mr2448606oih.97.1597825650451; Wed, 19 Aug 2020 01:27:30 -0700 (PDT) MIME-Version: 1.0 References: <20200725231318.GO4213@funkthat.com> <20200726211447.GQ4213@funkthat.com> <20200727183503.GW4213@funkthat.com> In-Reply-To: <20200727183503.GW4213@funkthat.com> From: Ganbold Tsagaankhuu Date: Wed, 19 Aug 2020 16:27:19 +0800 Message-ID: Subject: Re: CFT: major update to if_ure To: Ganbold Tsagaankhuu , freebsd-net@freebsd.org, freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4BWgrM45Qdz4PpN X-Spamd-Bar: / X-Spamd-Result: default: False [-0.97 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[ganbold]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.031]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22f:from]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net,freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 08:27:33 -0000 On Tue, Jul 28, 2020 at 2:35 AM John-Mark Gurney wrote: > Ganbold Tsagaankhuu wrote this message on Mon, Jul 27, 2020 at 18:29 +0800: > > On Mon, Jul 27, 2020 at 5:14 AM John-Mark Gurney > wrote: > > > > > Ganbold Tsagaankhuu wrote this message on Sun, Jul 26, 2020 at 11:05 > +0800: > > > > On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I'd like people who have ure (RealTek) based USB devices to test > > > > > review D25809[0]. > > > > > > > > > > This update adds support for: > > > > > - HW VLAN tagging > > > > > - HW checksum offload for IPv4 and IPv6 > > > > > - tx and rx aggreegation (for full gige speeds) > > > > > - multiple transactions > > > > > > > > > > In my testing, I am able to get 900-950Mbps depending upon > > > > > TCP or UDP, which is a significant improvement over the previous > > > > > 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). > > > > > > > > Does performance improve for if_ure device on USB2? > > > > I will try to test it in a couple of days on NanoPI R1 and R1S > boards. > > > > > > Yes, it should. > > > > > > I never tested the before driver on USB2, but I'm now able to get > > > 211Mbps TX and 190Mbps RX TCP, and 227Mbps TX and 225Mbps RX UDP. > > > > > > I believe it is likely that the same 91Mbps speed limit applied to > > > USB2 as well. > > > > Couldn't find your iperf test scripts and I tested only tcp: > > My test script isn't performance, just features, and I'm thinking about > how/where to publish it... > > You can also test UDP using -u w/ iperf3 and adjust the bandwidth w/ > -b 300m (or other Mbps)... > > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 > > Connecting to host 192.168.111.1, port 5201 > > [ 5] local 192.168.111.10 port 28569 connected to 192.168.111.1 port > 5201 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 27.4 MBytes 230 Mbits/sec 0 95.4 KBytes > > [ 5] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 2.00-3.00 sec 27.7 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 3.00-4.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 5.00-6.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 6.00-7.00 sec 27.7 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 7.00-8.00 sec 27.7 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > [ 5] 9.00-10.00 sec 27.6 MBytes 232 Mbits/sec 0 95.4 KBytes > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-10.00 sec 276 MBytes 232 Mbits/sec 0 > sender > > [ 5] 0.00-10.79 sec 276 MBytes 215 Mbits/sec > > receiver > > > > iperf Done. > > root@nanopi-r1s-h5:~ # iperf3 -c 192.168.111.1 -R > > Connecting to host 192.168.111.1, port 5201 > > Reverse mode, remote host 192.168.111.1 is sending > > [ 5] local 192.168.111.10 port 29384 connected to 192.168.111.1 port > 5201 > > [ ID] Interval Transfer Bitrate > > [ 5] 0.00-1.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 1.00-2.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 2.00-3.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 4.00-5.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 6.00-7.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec > > [ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec > > [ 5] 9.00-10.00 sec 12.1 MBytes 102 Mbits/sec > > - - - - - - - - - - - - - - - - - - - - - - - - - > > [ ID] Interval Transfer Bitrate Retr > > [ 5] 0.00-11.25 sec 121 MBytes 90.3 Mbits/sec 2539 > > sender > > [ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec > > receiver > > > > iperf Done. > > root@nanopi-r1s-h5:~ # sysctl -a | grep cpu.0.freq > > dev.cpu.0.freq_levels: 1248/-1 1008/-1 816/-1 624/-1 480/-1 > > dev.cpu.0.freq: 1248 > > Hmmm... The reverse seems slow, but I can't think of why it'd be that > slow though. When I did my tests on the USB2 ports, both directions > were about the same speed... > > Thanks for the test! Great to hear things are working... > When can you commit it? thanks, Ganbold > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-current@freebsd.org Wed Aug 19 13:29:20 2020 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 136DC3BE7FD for ; Wed, 19 Aug 2020 13:29:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWpXb22mVz3YHw for ; Wed, 19 Aug 2020 13:29:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f196.google.com with SMTP id j9so20602213ilc.11 for ; Wed, 19 Aug 2020 06:29:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yri5YzutDosWQFDLdb8mFh6CWEkXeht4Qk2h2UNxXbI=; b=GlA75n1ct1Yu3TfQNMpajbMY+WXdL3MYqv1mvYz31/EfKZoKxCK5dmJuTurJk++2wN KHCydm+WdduGVGVl6zmhfSKZBb1j8/QOffWVzdNggP0XKgYwhukzK1MOtSU02EsM64mU ypFuozKp6nFO0DoxR1S6kOuAuehATRRdcVzwSZBZTRemjeoJl1l7vUkslNFfP/+OzF2B As7rbL+uGW6hBcTyENjTafvUVYD0kSodJpO266AyP9B2lqyO+TPu6HKSxyRgVIWxupeZ xb7JOSlmNfBiaCcGByQ//W+GGiTGmj4crCvi6DwXJKNtxgEneHSZJppA/l1tJ0b3odIW v8hg== X-Gm-Message-State: AOAM5317UNvl8ZEkZvQxSfCm3SbW2vfSFTxVwvnOGCeqjX8ulUDMzxII afcEzcdzdxExsvK/TKvql9a0L60j8yT3uCEn3M/FCAO0JDs= X-Google-Smtp-Source: ABdhPJyw7Z1Da8om/uEmz1tJfsPNSDI6zM4J6HmYNysClGeZQlE6PepjO2rOh4Thwi47qPyCrH+lPyyAaa87vWVB4jg= X-Received: by 2002:a92:4f:: with SMTP id 76mr17897890ila.11.1597843757796; Wed, 19 Aug 2020 06:29:17 -0700 (PDT) MIME-Version: 1.0 References: <0be4e1e1-a7a4-49c3-4865-3302786c2c00@protected-networks.net> In-Reply-To: From: Ed Maste Date: Wed, 19 Aug 2020 09:29:05 -0400 Message-ID: Subject: Re: kldref: too many segments on kernel build To: Dustin Marquess Cc: Michael Butler , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4BWpXb22mVz3YHw X-Spamd-Bar: / X-Spamd-Result: default: False [-0.20 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[carpeddiem]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.20)[-0.203]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.196:from]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.196:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 13:29:20 -0000 On Wed, 19 Aug 2020 at 00:19, Dustin Marquess wrote: > > On Tue, Aug 18, 2020 at 3:19 PM Michael Butler > wrote: > > > > Any thoughts as to why this is happening when I build a (custom) kernel? > > > > kldxref: /boot/kernel/kernel: too many segments > > I'm seeing this too. I haven't tried actually booting the kernel > because of this. This is fallout from Clang 11. The kernel should boot fine despite the warnings, and this should be cleaned up in the near future (by increasing the number of segments supported by kldxref, by changing the kernel linker script, or a combination of both). From owner-freebsd-current@freebsd.org Wed Aug 19 15:39:01 2020 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 EA4EE3C1C0E for ; Wed, 19 Aug 2020 15:39:01 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BWsQF1Zhzz40kZ; Wed, 19 Aug 2020 15:39:01 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id z18so21950852wrm.12; Wed, 19 Aug 2020 08:39:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NvgjKBiTxiT1zZryZnObgG+N9NnANpq7TQ5miLGd7zY=; b=BO0Jekw96TNbyBYBTvgp/jPE3jy+r+d21pLCX4jDKAZg3JIXPWwEyKNbgr+9xjssFs LYaGDehdy6S7wvPMWIM1GUyH1lr4ASxYWzXf+188EBZmbdn/YQsdiMELaVJ3tn0HJAA9 Pp2Sl1gHUH3vJmfOFTO6z69+AH33QbGie5QMT/dyfsLmINQf/lYbF0d6ctc7HEDj9Q74 QIOg7Calr+l0QBqucVcWgJG2DlayftW3LD/O6QJHGPZASP4YGZylzQ48AWlzL5UxJm5g zd/fVdYV4SlwVmzaHAm54+OUxIyaQzu6NbB/TcGZjz50Nx8nCeACD0f8KKaMAR5ra0ed tVMg== X-Gm-Message-State: AOAM530LycS6vo+h/xgr5LOkpwShar6aLlHhvpglN7MpIUqPDWZHqxoW aKwtYmlkzQOFrLqiF1bcIcWgRGPQr8U= X-Google-Smtp-Source: ABdhPJzwouuk+t/vpREEUZWRFI5gK+Ocg0miLONMfHRG5b3yi2t9SpnSnQYXCDztiTpafhTifNkdew== X-Received: by 2002:adf:e68f:: with SMTP id r15mr25039725wrm.196.1597851538621; Wed, 19 Aug 2020 08:38:58 -0700 (PDT) Received: from MacBook-Pro-van-Johan.local (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id l7sm3341817wmh.15.2020.08.19.08.38.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 08:38:58 -0700 (PDT) Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images To: Matthew Macy , freebsd-current@freebsd.org References: From: Johan Hendriks Message-ID: Date: Wed, 19 Aug 2020 17:38:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl X-Rspamd-Queue-Id: 4BWsQF1Zhzz40kZ X-Spamd-Bar: / X-Spamd-Result: default: False [-0.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.028]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::434:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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, 19 Aug 2020 15:39:02 -0000 Op 04-08-2020 om 02:24 schreef Matthew Macy: > On Wednesday, July 8th I issued the initial call for testing for the > update to HEAD to vendored openzfs. We'd like to give users roughly a > month to test before merging. The tentative merge date is August > 17th. > > Again, I hope it's not terribly controversial to point out that > it really rests with users of non amd64 platforms to test to avoid any > unpleasant surprises the next time they update their trees following > the merge. > > amd64, i386, and aarch64 memdisk images can be found at: > https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/ > > If you're using a platform not listed above and would be inclined to > test if you had an image to work with, let us know. Alternatively, you > can still build following the instructions below. > > The review for merging in to base can be found at: > https://reviews.freebsd.org/D25872 > > ========================================================== > NB: Do NOT zpool upgrade unless you are willing to live without the > ability to ever rollback to the legacy zfs kmod. > > Checkout updated HEAD: > % git clone https://github.com/mattmacy/networking.git -b > projects/openzfs_vendor freebsd > > Checkout updated openzfs in to sys/contrib: > % git clone https://github.com/zfsonfreebsd/ZoF.git -b > projects/openzfs_vendor freebsd/sys/contrib/openzfs > > Build world and kernel with whatever your usual configuration is. > Where possible the openzfs kmod is backward compatible with the cmd > utils in HEAD so common operations work with existing tools and the > new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries > are backward compatible with the zfs kmod in HEAD. Although ideally > one would test this in a separate boot environment, the > interoperability should allow one to rollback without too much > difficulty. > > NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools > other than the root pool will not be imported at boot. > > Thanks in advance for your time. > > -M > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > I just downloaded the freebsd-openzfs-amd64-2020081100-memstick.img image and installed it as a fresh install. (ZFS install) Then i imported a pool that is a mirrored zfs pool of 6 WD drives created with FreeBSD 12.1 without any problem. The only thing i see when the ZFS module is loaded is the message can't handle raw ops yet!!! # kldload zfs can't handle raw ops yet!!! can't handle raw ops yet!!! can't handle raw ops yet!!! ZFS filesystem version: 5 ZFS storage pool version: features support 5000 can't handle raw ops yet!!! regards Johan From owner-freebsd-current@freebsd.org Thu Aug 20 01:20:13 2020 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 2B61D3CDBD5 for ; Thu, 20 Aug 2020 01:20:13 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BX6Js0LNjz4mp7 for ; Thu, 20 Aug 2020 01:20:13 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id DD8A31A98B for ; Thu, 20 Aug 2020 01:20:12 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lj1-f169.google.com with SMTP id w25so346947ljo.12 for ; Wed, 19 Aug 2020 18:20:12 -0700 (PDT) X-Gm-Message-State: AOAM533hXcThVz8nfAI7vESMO/qpq3U/x+YWRqy0rZnsC+Gy3FH2Jh9e 2YUKnnAn8QUQJFa1VAaOzU0Q26uJ5tKXF534QY8= X-Google-Smtp-Source: ABdhPJzYvysP3xnLK2jx0pFnHFnOWjYGDEpHN2RbvSjJzkjKhUwZf9pgGIztGepmi/ZaGjbn2usAB4YVWgQbHKOo6Ik= X-Received: by 2002:a2e:9cd2:: with SMTP id g18mr378951ljj.448.1597886411415; Wed, 19 Aug 2020 18:20:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Wed, 19 Aug 2020 18:19:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT for vendor openzfs - week 5 reminder + memdisk images To: Johan Hendriks Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 01:20:13 -0000 > # kldload zfs > can't handle raw ops yet!!! > can't handle raw ops yet!!! > can't handle raw ops yet!!! > ZFS filesystem version: 5 > ZFS storage pool version: features support 5000 > can't handle raw ops yet!!! I'm working on it - Ryan reminded me of it today. It will probably get fixed before the merge. KSTAT_TYPE_RAW isn't supported in legacy ZFS, so strictly speaking it's not a regression (apart from the annoying reminder on debug kernels). -M From owner-freebsd-current@freebsd.org Thu Aug 20 06:33:39 2020 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 D41753B278F for ; Thu, 20 Aug 2020 06:33:39 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXFGV3PPyz3gqd for ; Thu, 20 Aug 2020 06:33:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x333.google.com with SMTP id 3so585508wmi.1 for ; Wed, 19 Aug 2020 23:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=CfwGBRL0cbkR7oEFz8nRFUNr3RrUVr2uGbOasQ3Sxeg=; b=NrZr/WvOIIxx32fj1WlviZQZknrxoubEAOSo7KxciPPeLCDHtkkRWYEK7z0U++mDAh kMsuKXCdmXEqnM9oUTYttuLslPDc51Jy6rW2h36kIFzflbvPQ9E9TM3xBA6TEFNJNOoe nun4mzb44b7mKkALJcx/sDJYCw1M4l94dgbD7rCz1XttG/gRlLqGHSJJq6NWnedLRNCm v3TQR9/qs60HxHM033r6iQJGR2MrSAyFpaOgyXhd4RCy8mYiKn4b+JUzMItmCRHVfZGd qvVoEHXrUKshpsurN6E1JQgqua8M8A1+gmivis65aQIMDoSvLzEyFl+PngkQ767xJON7 PGGQ== X-Gm-Message-State: AOAM532Fm+bkQtAGXrSSnYq8CV892dwb8cjjxFwth2vF3bw7eiLQM1DI SvcyRffXwEJivVOeERiUzd5qh5uf0es= X-Google-Smtp-Source: ABdhPJzNGSGhevyckyaD2DWWyJvaER6mqWcGVREgpHmw//Ghs+ODPYIiLpyv2Ecxn2vvFw9b9xuhvw== X-Received: by 2002:a1c:cc05:: with SMTP id h5mr1802541wmb.129.1597905216295; Wed, 19 Aug 2020 23:33:36 -0700 (PDT) Received: from ernst.home (pd9e23482.dip0.t-ipconnect.de. [217.226.52.130]) by smtp.gmail.com with ESMTPSA id f16sm2150898wro.34.2020.08.19.23.33.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 23:33:35 -0700 (PDT) Date: Thu, 20 Aug 2020 08:33:32 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: PRINTF_BUFR_SIZE dangerous? Message-ID: <20200820083332.59d7fbbb@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXFGV3PPyz3gqd X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.34)[-0.339]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[217.226.52.130:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.039]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::333:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 06:33:39 -0000 It seems like PRINTF_BUFR_SIZE is a kernel fault waiting to happen. Only /usr/src/sys/cam/cam_xpt.c asserts that it's <= a maximum value of 512 bytes. /usr/src/sys/kern/tty.c uses it to malloc space without checking its size. /usr/src/sys/dev/xen/console/xen_console.c and /usr/src/sys/kern/subr_prf.c blindly use it to allocate a buffer on the kernel stack. /usr/src/sys/geom/geom_subr.c and /usr/src/sys/geom/geom_io.c check whether it's defined and set it to 64 if it isn't. Otherwise it's simply used to allocate a buffer on the kernel stack. A user who doesn't really understand the purpose of PRINTF_BUFR_SIZE might think "the bigger the better" and set it to be multi-megabytes in size. I may be paranoid, but it seems like PRINTF_BUFR_SIZE should be checked everywhere the way that cam_xpt.c does it. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Thu Aug 20 06:49:19 2020 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 8D9413B34A6 for ; Thu, 20 Aug 2020 06:49:19 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXFcZ5qJHz3yhf for ; Thu, 20 Aug 2020 06:49:18 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id r4so930097wrx.9 for ; Wed, 19 Aug 2020 23:49:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=I5GVI0p5TSj60QpfAwPqZBPI5sfLPNx0O4oxVSIBNgk=; b=deJqhIRQvYEuNXy+E4yYlp3EvHCXmQdU95lgaSCPPQAaIxKSZ9rtTlzIfflpoumX3N +K+vwBvYjVNZ/+YbzwoPnRqqqt1ftEdAQzW8zn7SuqX2l5Yk8DEKlX+hNCfnhmFN7tu3 8nN7ii4Sy2MKHfyqwgWF++BWDQcEH6HV2rUFBOSsxxzMDXTypOWwsG2Q/IWik8EW1aOJ qbboQIOalwbwftX/WOvPvC2gJfuuHiKCepn+ss7K9+3kFov6HBo8kDLAZHop9QN0AlL1 DtgZbzOuk3CMp9F6SeBYhuaVwCT5fFWbrrbBRYqwPvitaBnsdrNh3Eu+9js2GNX3Fi1Z ltfA== X-Gm-Message-State: AOAM530Sqi4cDJ4jMMQ7VCqXrmUZFd2zmVEGrv3x7zNv7xL199f2/aOx YMWfiRpnZcoVHv0JK6bZQflWpaUUfhM= X-Google-Smtp-Source: ABdhPJw/QdQiCagQAZno9iTjbKRXZbuYAs1gHZMnxi4tXSr/DPsihcXr7g3aYjQZCw5nDpnyWLFI0Q== X-Received: by 2002:a5d:5048:: with SMTP id h8mr1573317wrt.424.1597906156862; Wed, 19 Aug 2020 23:49:16 -0700 (PDT) Received: from ernst.home (pd9e23482.dip0.t-ipconnect.de. [217.226.52.130]) by smtp.gmail.com with ESMTPSA id i4sm2286111wrw.26.2020.08.19.23.49.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2020 23:49:16 -0700 (PDT) Date: Thu, 20 Aug 2020 08:49:15 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: PRINTF_BUFR_SIZE dangerous? Message-ID: <20200820084915.4967e80b@ernst.home> In-Reply-To: <20200820083332.59d7fbbb@ernst.home> References: <20200820083332.59d7fbbb@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXFcZ5qJHz3yhf X-Spamd-Bar: / X-Spamd-Result: default: False [-0.32 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.368]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[217.226.52.130:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.05)[0.048]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 06:49:19 -0000 On Thu, 20 Aug 2020 08:33:32 +0200 Gary Jennejohn wrote: > It seems like PRINTF_BUFR_SIZE is a kernel fault waiting to happen. > > Only /usr/src/sys/cam/cam_xpt.c asserts that it's <= a maximum value of > 512 bytes. > > /usr/src/sys/kern/tty.c uses it to malloc space without checking its size. > > /usr/src/sys/dev/xen/console/xen_console.c and /usr/src/sys/kern/subr_prf.c > blindly use it to allocate a buffer on the kernel stack. > > /usr/src/sys/geom/geom_subr.c and /usr/src/sys/geom/geom_io.c check whether > it's defined and set it to 64 if it isn't. Otherwise it's simply used to > allocate a buffer on the kernel stack. > > A user who doesn't really understand the purpose of PRINTF_BUFR_SIZE might > think "the bigger the better" and set it to be multi-megabytes in size. > > I may be paranoid, but it seems like PRINTF_BUFR_SIZE should be checked > everywhere the way that cam_xpt.c does it. > OK, I decided to try setting PRINTF_BUFR_SIZE to (1024*1024) and the static assert in /usr/src/sys/cam/cam_xpt.c saved the day. Still, if a user isn't using scbus the problem would still exist. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Thu Aug 20 06:51:52 2020 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 07C2A3B390A for ; Thu, 20 Aug 2020 06:51:52 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXFgV6vQ7z40Bf for ; Thu, 20 Aug 2020 06:51:50 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id r15so915515wrp.13 for ; Wed, 19 Aug 2020 23:51:50 -0700 (PDT) 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:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=0glyVBu1+4kHk/AkGlJj4KYkI0qn7n0zTRcq1blNIDY=; b=GfqNzO6E8+4FXUGc077rTswWwVYRFJjOb/lr+P1r8Qn1XFLctl7f4FQN7AHFJFBLxT 9EvoTD5jUrsbWxj/y6jEfAX/uXCDCa+bmI5R7TKuUtPFecJu9CBFXuqRusSC/ficvwTg X35C/sPwPBBnuhJNllEDYQqNppgvoDaHCJIAoU62fb/f8bmxQG14K3JFoelIffoqRZxR bAyeExg5iDHezvetyLfI/mmIIPZGQz9QxLTAWLR5HfhSMC25q5S+ORIonArsxgPHhlb/ Rpq1wCViCet0GWxpCu7HqVocmGmDEeVkBTjBdia+swcmaxXyJy+A1d6pYguqRfU89a12 QXxw== X-Gm-Message-State: AOAM530F0cm/NbrwMgbyTI40sqFjQdFkCcrmjeww5QnZmbTgOGSN+M6h 8hqiNpXac+TCIERtL3mCwaByPrJeZYxgOOe1 X-Google-Smtp-Source: ABdhPJxVE33iOv7/mkixqR+c2moXlIYzETEaX+oTE5t3lB9U7+Ue8H/dV9wKOlDoDvNFsXFT64VRug== X-Received: by 2002:a17:906:1f8b:: with SMTP id t11mr1951444ejr.32.1597905809677; Wed, 19 Aug 2020 23:43:29 -0700 (PDT) Received: from [192.168.8.105] (213162072245.public.t-mobile.at. [213.162.72.245]) by smtp.gmail.com with ESMTPSA id h16sm815294ejf.120.2020.08.19.23.43.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 23:43:29 -0700 (PDT) To: freebsd-current@freebsd.org From: "Vanbreukelingen Ltd." Subject: drn0 - crash dump not in /var/crash Message-ID: Date: Thu, 20 Aug 2020 08:43:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4BXFgV6vQ7z40Bf X-Spamd-Bar: +++++ X-Spamd-Result: default: False [5.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[213.162.72.245:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_CSS(4.00)[213.162.72.245:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.41)[0.412]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::443:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 06:51:52 -0000 On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote: > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > lizbethmutterhunt@gmail.com> wrote: > > > After having had some near-death-experiences in Greece I'm back to my > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.!  > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > After finally recompiling the kernel with the drm-module inside and > > > the trick of injecting the > > > > This is not the way to do it. Modern hardware require drm-kmod from ports, > > or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf wasn't yet finished (c [see] beyond), but I guess I have to disable the whole output with something like hw.*=1 or so. is it possible to make a bootlogo while VEBOSE output = 2 just for the reason some kids try to play with it. > > > device IWNFW >  doesn't install the 6000, btw --- probably can't find FW on device HAL. > > > Again, this is not needed, firmware is autoloaded on module load. Just add > > if_iwn to kld_list in /etc/rc.conf >  built of 15 hours of NanoBSD while finishing the nightly built someone was on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but some reason tells me behind this system in system is something to beat beastie in killing KFC forks.  > > > > I get a *nice* message a bootup: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 > > > 20060810 > > > Aug 19 02:51:10 current kernel: drmn0: on > > > vgapci0 > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > > > device = 2048M > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > > > Graphics performance may suffer. > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > iicbb_nostop0 addr 0x1 > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > Aug 19 02:51:10 current kernel: iicbus1: on > > > intel_gmbus0 > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > iicbb_nostop1 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > Aug 19 02:51:10 current kernel: iicbus3: on > > > intel_gmbus1 > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > iicbb_nostop2 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > Aug 19 02:51:10 current kernel: iicbus5: on > > > intel_gmbus2 > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > iicbb_nostop3 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > Aug 19 02:51:10 current kernel: iicbus7: on > > > intel_gmbus3 > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > iicbb_nostop4 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > Aug 19 02:51:10 current kernel: iicbus9: on > > > intel_gmbus4 > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > iicbb_nostop5 addr 0x12 > > > > > > And furthermore: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > > > caching Rev 1 (10.10.201> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > > > vblank timestamp query. > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > range 0xe0000000-0xf0000000 > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.LVDS-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.VGA-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > > > mode from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - > > > kern.vt.fb.modes.HDMI-A-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.DP-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > > > and may be deleted before> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new > > > "fb". > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > 20080730 for drmn0 on minor 0 > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > initialized. but now, when starting xinit or lightdm or sddm or > > > whatever I get a kernel panic: > > > > > > Dump header from device: /dev/ada0p4 > > > > > > Architecture: i386 > > > Architecture Version: 4 > > > Dump Length: 97792 > > > Blocksize: 512 > > > Compression: none > > > Dumptime: 2020-08-19 02:49:00 +0200 > > > Hostname: current > > > Magic: FreeBSD Text Dump > > > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > > > > > > CEST 2020 > > > > > > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > Dump Parity: 2773167169 > > > Bounds: 1 > > > Dump Status: good > > > > > > /var/crash/vmcore.0 not found > > > > Do you have  dumpdev="AUTO" in /etc/rc.conf ? > yes and the directory is /var/crash, but this is all I get as lack of insufficent memory of dump, it says. > > > > First thing I think is kern options: > > > > > > options WITNESS_SKIPSPIN > > > options WITNESS > > > > > > I disabled device HYPERV but this can't be the reason, kern is being > > > compiled with clang. > > > > Clang is the default since a long time. > depends on gcc++ development in 4D AIs. > > > > To disable WITNESS would be one way I think but this can't be the > > > yellw of the egg, isn't it? > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some > > performance improvements. > yup. we don't need another debugger. killing insects is murder but when getting better stuff I never resist to lance them. like housecats with flys. > > > Another thing but I guess having nothing to do with bug above is on > > > rather the end of  startup: > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > /usr/src/sys/vm/vm_page.c:1609 > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > /var/crash/textdump.tar.1 > > > Aug 19 02:51:10 current kernel: linsysfs: > > > Aug 19 02:51:10 current kernel: Device busy > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, lockmgr) @ > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, lockmgr) > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established at: > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at witness_checkorder+0x3c5 > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at lockmgr_lock_flags+0x140 > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > __stop_set_sysinit_set+0xd0a4199e > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at witness_checkorder+0xa50 > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > any ideas? > > > Miranda > > > > > > > > > > > > does someone know how to fix it? > > > > > > Miranda > > > > Hope this helps. > It does! > > > Best regards > > Andreas Nilsson > Yours, Miranda van Breukelingen From owner-freebsd-current@freebsd.org Thu Aug 20 12:48:58 2020 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 5334E3BDB8E for ; Thu, 20 Aug 2020 12:48:58 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXPbY13j0z4PnR for ; Thu, 20 Aug 2020 12:48:56 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-ej1-x642.google.com with SMTP id jp10so2387189ejb.0 for ; Thu, 20 Aug 2020 05:48:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SXI3hE1IXP/DhJDZ3m5wnknHXGUzAiKdAHSg4CA7tHU=; b=ts9iIHHkUDokD4ZjadVKa6S+UkOA1/rc8gIpTm8/NFsu6BCINZ1fN/cTS3b8mGzM9A tUcEjm6ZRNbGk3kPy6gdTDnT7IeMBuaMyr8jpqWijnqyid+fcbYhSypx2C1bx6m0XFd0 AfncEOVKI4llkcnR/lS8KCZ5Jw+/HDUKhi2LlRs/AhEEb1c+wKAWhyldfw2Vs1T6qhS8 MHyFtHAn4EugPNpBqDOQl5gPzEL2wQVmXCNRWylnCotecRQbYWWKPDSKKpH+av8P1bSx OhjHu1R8tsv/FWbhuQhSSF+kXiexyCSn62g2fY0y4QfWlI2Tf1eThWz7J+BIq7uQYvMg SO6A== X-Gm-Message-State: AOAM530Iai9bwYRi+vLOjhQHsT63f+BXDrV7oUBn97Cd6pJ9iFdJuXGo ycNfimfPP7+EZUYg0g7ucxaNPjdf46rp/Q== X-Google-Smtp-Source: ABdhPJx/7qEXvJ3MtmfypoiDmvDE9BzacEMO/lSKMz8HAx+x/2rHxRLLzf+j5XrO2DbHCW3ruyj5Fw== X-Received: by 2002:a17:906:9382:: with SMTP id l2mr2971439ejx.513.1597927735472; Thu, 20 Aug 2020 05:48:55 -0700 (PDT) Received: from alice.localnet (213162072245.public.t-mobile.at. [213.162.72.245]) by smtp.gmail.com with ESMTPSA id d16sm1425221ejb.8.2020.08.20.05.48.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2020 05:48:55 -0700 (PDT) From: "Vanbreukelingen Ltd." To: Current FreeBSD Subject: Re: funny thing with the drm0 Date: Thu, 20 Aug 2020 08:15:56 +0200 Message-ID: <8073347.hK6j7OjjKr@alice> In-Reply-To: <3105850.kTNGU1mI0b@alice> References: <3105850.kTNGU1mI0b@alice> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4BXPbY13j0z4PnR X-Spamd-Bar: ++++++ X-Spamd-Result: default: False [6.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,meta]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; CTE_CASE(0.50)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_CSS(4.00)[213.162.72.245:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.94)[0.941]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.99)[0.989]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[213.162.72.245:received]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::642:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 12:48:58 -0000 On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote: > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > lizbethmutterhunt@gmail.com> wrote: > > > After having had some near-death-experiences in Greece I'm back to my > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > After finally recompiling the kernel with the drm-module inside and > > > the trick of injecting the > > > > This is not the way to do it. Modern hardware require drm-kmod from ports, > > or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf wasn't yet finished (c [see] beyond), but I guess I have to disable the whole output with something like hw.*=1 or so. is it possible to make a bootlogo while VEBOSE output = 2 just for the reason some kids try to play with it. > > > device IWNFW > doesn't install the 6000, btw --- probably can't find FW on device HAL. > > > Again, this is not needed, firmware is autoloaded on module load. Just add > > if_iwn to kld_list in /etc/rc.conf > built of 15 hours of NanoBSD while finishing the nightly built someone was on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but some reason tells me behind this system in system is something to beat beastie in killing KFC forks. ;-) > > > > I get a *nice* message a bootup: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 > > > 20060810 > > > Aug 19 02:51:10 current kernel: drmn0: on > > > vgapci0 > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > > > device = 2048M > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > > > Graphics performance may suffer. > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > iicbb_nostop0 addr 0x1 > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > Aug 19 02:51:10 current kernel: iicbus1: on > > > intel_gmbus0 > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > iicbb_nostop1 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > Aug 19 02:51:10 current kernel: iicbus3: on > > > intel_gmbus1 > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > iicbb_nostop2 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > Aug 19 02:51:10 current kernel: iicbus5: on > > > intel_gmbus2 > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > iicbb_nostop3 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > Aug 19 02:51:10 current kernel: iicbus7: on > > > intel_gmbus3 > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > iicbb_nostop4 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > Aug 19 02:51:10 current kernel: iicbus9: on > > > intel_gmbus4 > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > iicbb_nostop5 addr 0x12 > > > > > > And furthermore: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > > > caching Rev 1 (10.10.201> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > > > vblank timestamp query. > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > range 0xe0000000-0xf0000000 > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > > > mode from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > kern.vt.fb.modes.HDMI-A-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > > > and may be deleted before> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new > > > "fb". > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > 20080730 for drmn0 on minor 0 > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > initialized. but now, when starting xinit or lightdm or sddm or > > > whatever I get a kernel panic: > > > > > > Dump header from device: /dev/ada0p4 > > > > > > Architecture: i386 > > > Architecture Version: 4 > > > Dump Length: 97792 > > > Blocksize: 512 > > > Compression: none > > > Dumptime: 2020-08-19 02:49:00 +0200 > > > Hostname: current > > > Magic: FreeBSD Text Dump > > > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > > > > > > CEST 2020 > > > > > > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > Dump Parity: 2773167169 > > > Bounds: 1 > > > Dump Status: good > > > > > > /var/crash/vmcore.0 not found > > > > Do you have dumpdev="AUTO" in /etc/rc.conf ? > yes and the directory is /var/crash, but this is all I get as lack of insufficent memory of dump, it says. > > > > First thing I think is kern options: > > > > > > options WITNESS_SKIPSPIN > > > options WITNESS > > > > > > I disabled device HYPERV but this can't be the reason, kern is being > > > compiled with clang. > > > > Clang is the default since a long time. > depends on gcc++ development in 4D AIs. > > > > To disable WITNESS would be one way I think but this can't be the > > > yellw of the egg, isn't it? > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some > > performance improvements. > yup. we don't need another debugger. killing insects is murder but when getting better stuff I never resist to lance them. like housecats with flys. > > > Another thing but I guess having nothing to do with bug above is on > > > rather the end of startup: > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > /usr/src/sys/vm/vm_page.c:1609 > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > /var/crash/textdump.tar.1 > > > Aug 19 02:51:10 current kernel: linsysfs: > > > Aug 19 02:51:10 current kernel: Device busy > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established at: > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at witness_checkorder+0x3c5 > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at lockmgr_lock_flags+0x140 > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > __stop_set_sysinit_set+0xd0a4199e > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at witness_checkorder+0xa50 > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > any ideas? > > > Miranda > > > > > > > > > > > > does someone know how to fix it? > > > > > > Miranda > > > > Hope this helps. > It does! > > > Best regards > > Andreas Nilsson > Yours, Miranda van Breukelingen From owner-freebsd-current@freebsd.org Thu Aug 20 14:44:15 2020 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 735243C0457 for ; Thu, 20 Aug 2020 14:44:15 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXS8W22Lyz4WH2 for ; Thu, 20 Aug 2020 14:44:11 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: by mail-lf1-x136.google.com with SMTP id r25so1070178lfe.5 for ; Thu, 20 Aug 2020 07:44:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/v3KQ7LYQer3iQpFoHZAhBYSLSUQfEyFxnuos7j8Lr8=; b=L2z1q2Bl1uJ31mVgJFUSrNrrHb6E5sCgDvsc+UZIEjeFHAEXJ0aG6HNJJv8OT6Xuhp njSoZaX8pipULVwviNfytK1x1cZFfefPj7aBdTUS7Otd3DZr+ip/E7gFcr/ULxhUvX6h Jr42K9om2HRewVsfVUVp56yFyLLgkAoCSW3ryYi/W08HHcj9ZuzizF7WjuP2iCMncsw9 ZLk0KF/4rROklOu8NTdTN+knkbNeYLSBe9Kt5ugbr0VoxDARAA/GPUqp3OKNUcji+xMZ bNEJCHlZorZ2+/rW3geIz5ax31C6LZ45bp8v8zRsSKGk/YYIPWOihWM7TtoWsVZUiHrr +dow== X-Gm-Message-State: AOAM530yBXqXkE6CbFPeFMlz6/0EN6F/6OW3h6aanh9lu0GLj7ybPccF 5D3sOZFXDgjJzUE+tb6axbih74XAoDzqvGwLzYs= X-Google-Smtp-Source: ABdhPJy2k/HGFw6AkhKQx6yGsM5Oh+RH1yDcCYTg5Ic7ZH6uG3lBqFd1RlONcdPDxdS+f1jhw/oeDBCi3hEHKqjIBdM= X-Received: by 2002:a19:e50:: with SMTP id 77mr1760708lfo.188.1597934648822; Thu, 20 Aug 2020 07:44:08 -0700 (PDT) MIME-Version: 1.0 References: <3105850.kTNGU1mI0b@alice> In-Reply-To: <3105850.kTNGU1mI0b@alice> From: Andreas Nilsson Date: Thu, 20 Aug 2020 16:43:56 +0200 Message-ID: Subject: Re: funny thing with the drm0 To: "Vanbreukelingen Ltd." , Current FreeBSD X-Rspamd-Queue-Id: 4BXS8W22Lyz4WH2 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.928]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_SHORT(-0.56)[-0.560]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::136:from]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 14:44:15 -0000 On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. < lizbethmutterhunt@gmail.com> wrote: > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > lizbethmutterhunt@gmail.com> wrote: > > > After having had some near-death-experiences in Greece I'm back to my > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > After finally recompiling the kernel with the drm-module inside and > > > the trick of injecting the > > > > This is not the way to do it. Modern hardware require drm-kmod from > ports, > > or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > wasn't yet finished (c [see] beyond), but I guess I have to disable the > whole > output with something like hw.*=1 or so. is it possible to make a bootlogo > while VEBOSE output = 2 just for the reason some kids try to play with it. > > > > > device IWNFW > doesn't install the 6000, btw --- probably can't find FW on device HAL. > > Again, this is not needed, firmware is autoloaded on module load. Just > add > > if_iwn to kld_list in /etc/rc.conf > Here I admit I was wrong, iwn handles it differently than iwm. The man page lists 3 different firmware versions for the 6000 series, which can be loaded from loader.conf > built 15 hours of NanoBSD while finishing the nightly built someone was on > Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but > some > reason tells me behind this system in system is something to beat beastie > in > killing KFC forks. > > > > > I get a *nice* message a bootup: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 > 20060810 > > > Aug 19 02:51:10 current kernel: drmn0: on > vgapci0 > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > > > device = 2048M > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > > > Graphics performance may suffer. > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > iicbb_nostop0 addr 0x1 > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > Aug 19 02:51:10 current kernel: iicbus1: on > intel_gmbus0 > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > iicbb_nostop1 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > Aug 19 02:51:10 current kernel: iicbus3: on > intel_gmbus1 > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > iicbb_nostop2 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > Aug 19 02:51:10 current kernel: iicbus5: on > intel_gmbus2 > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > iicbb_nostop3 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > Aug 19 02:51:10 current kernel: iicbus7: on > intel_gmbus3 > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > iicbb_nostop4 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > Aug 19 02:51:10 current kernel: iicbus9: on > intel_gmbus4 > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > iicbb_nostop5 addr 0x12 > > > > > > And furthermore: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > > > caching Rev 1 (10.10.201> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > > > vblank timestamp query. > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > range 0xe0000000-0xf0000000 > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > > > mode from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - > kern.vt.fb.modes.HDMI-A-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > > > and may be deleted before> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new > "fb". > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > 20080730 for drmn0 on minor 0 > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > initialized. but now, when starting xinit or lightdm or sddm or > > > whatever I get a kernel panic: > > > > > > Dump header from device: /dev/ada0p4 > > > > > > Architecture: i386 > > > Architecture Version: 4 > > > Dump Length: 97792 > > > Blocksize: 512 > > > Compression: none > > > Dumptime: 2020-08-19 02:49:00 +0200 > > > Hostname: current > > > Magic: FreeBSD Text Dump > > > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > > > > > > CEST 2020 > > > > > > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > Dump Parity: 2773167169 > > > Bounds: 1 > > > Dump Status: good > > > > > > /var/crash/vmcore.0 not found > > > > Do you have dumpdev="AUTO" in /etc/rc.conf ? > yes and the directory is /var/crash, but this is all I get as lack of > insufficent memory of dump, it says. > Sounds like your swap device is to small. How big is it, and how much memory do you have? > > > > > First thing I think is kern options: > > > > > > options WITNESS_SKIPSPIN > > > options WITNESS > > > > > > I disabled device HYPERV but this can't be the reason, kern is being > > > compiled with clang. > > > > Clang is the default since a long time. > depends on gcc++ development in 4D AIs. > > Nothing stops you from using gcc for compiling your programs. Clang is just the default for the OS. > > > > To disable WITNESS would be one way I think but this can't be the > > > yellw of the egg, isn't it? > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some > > performance improvements. > > yup. we don't need another debugger. killing insects is murder but when > getting better stuff I never resist to lance them. like housecats with > flys. > > > > Another thing but I guess having nothing to do with bug above is on > > > rather the end of startup: > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > /usr/src/sys/vm/vm_page.c:1609 > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > /var/crash/textdump.tar.1 > > > Aug 19 02:51:10 current kernel: linsysfs: > > > Aug 19 02:51:10 current kernel: Device busy > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established at: > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at > witness_checkorder+0x3c5 > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at lockmgr_lock_flags+0x140 > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > __stop_set_sysinit_set+0xd0a4199e > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at > witness_checkorder+0xa50 > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > any ideas? > > > Miranda > > > > > > > > > > > > does someone know how to fix it? > > > > > > Miranda > > > > Hope this helps. > It does! > > > Best regards > > Andreas Nilsson > > Yours, > Miranda van Breukelingen > > > Best regards Andreas Nilsson From owner-freebsd-current@freebsd.org Thu Aug 20 14:58:31 2020 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 1315F3C0845 for ; Thu, 20 Aug 2020 14:58:31 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXST21P71z4X5s for ; Thu, 20 Aug 2020 14:58:29 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id g19so2853605ejc.9 for ; Thu, 20 Aug 2020 07:58:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pB97/8yfOEltjQY0hbUna+S1SUQdIw6k/JK/6rEzlRI=; b=ED51rkHFVTqfFYchNjY8A/VVDpnqU1JM7m1Hd2ugk6kLJDRt4MRAbZoe3o3dQO2s+K nQxWw9lX+toJRV8Lw7B8yYjAX6dimlGihLy6UUxDCEl0NL21CUy6wY23v6duox2z3OdH 6cacobCPEIvXnPjmIrWLREby6SLiZRrL4QmYPsg1Cm0DrNAJ8ZUTYzESL4GpQOvV+70/ yNd3sOCVYlso2xTbeXkU4QmYw1thVTiwtyyJi+pkVWqhQrSTdOWnUubOyaHyrKzo/nxL VN4J6Dr62gjtSnqTOImbq9/yTf9ZoHTSOjBdDMvk55In2gBchwQSdYBYUEd5deOuuJ33 vR8Q== X-Gm-Message-State: AOAM530xrrECe1GJb1CjzZBC0s7d/LxPcRvKZkug/3sR8bgYUbWjSWLU RDmS1AikL4gDJbbxYjPkiRchMIqqzv8LFg== X-Google-Smtp-Source: ABdhPJwM4XoyBMXLdy/teRBOOQlFHhDZRgk9+vBdaewfLt+ZO8ChiBXcxz/c798mA5zuJ/q6MCr2ZQ== X-Received: by 2002:a17:906:c10d:: with SMTP id do13mr3596519ejc.109.1597935507234; Thu, 20 Aug 2020 07:58:27 -0700 (PDT) Received: from [192.168.8.105] (213162072245.public.t-mobile.at. [213.162.72.245]) by smtp.gmail.com with ESMTPSA id v13sm1636124ejq.59.2020.08.20.07.58.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 07:58:26 -0700 (PDT) Subject: Re: funny thing with the drm0 To: Andreas Nilsson , freebsd-current@freebsd.org References: <3105850.kTNGU1mI0b@alice> From: "Vanbreukelingen Ltd." Message-ID: Date: Thu, 20 Aug 2020 16:58:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: 4BXST21P71z4X5s X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,meta]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_CSS(4.00)[213.162.72.245:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.07)[0.073]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.90)[0.901]; BAD_REP_POLICIES(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[213.162.72.245:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 14:58:31 -0000 On 2020-08-20 16:43, Andreas Nilsson wrote: > > > On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. > > wrote: > > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > lizbethmutterhunt@gmail.com > > wrote: > > > After having had some near-death-experiences in Greece I'm > back to my > > > screens. As horizon arises, BSD gets up --- and if it is 3 > a.m.! :-) > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > After finally recompiling the kernel with the drm-module > inside and > > > the trick of injecting the > > > > This is not the way to do it. Modern hardware require drm-kmod > from ports, > > or if you want the latest drm-devel-kmod. Then add > /boot/modules/drm.ko > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > wasn't yet finished (c [see] beyond), but I guess I have to > disable the whole > output with something like hw.*=1 or so. is it possible to make a > bootlogo > while VEBOSE output = 2 just for the reason some kids try to play > with it. > tried it now: next kernel panic on lightdm and sddm makes a mouse in mouse pointer over a blank screen. the driver is initialised but hungs up like this: Dump header from device: /dev/ada0p4   Architecture: i386   Architecture Version: 4   Dump Length: 97792   Blocksize: 512   Compression: none   Dumptime: 2020-08-20 16:41:45 +0200   Hostname: current   Magic: FreeBSD Text Dump   Version String: FreeBSD 13.0-CURRENT #3 r364372: Wed Aug 19 07:54:57 CEST 2020     root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy @ /usr/src/sys/vm/vm_page.c:1609** **  Dump Parity: 4227235352*   Bounds: 2   Dump Status: good > > > > device IWNFW > doesn't install the 6000, btw --- probably can't find FW on device > HAL. > > > > Again, this is not needed, firmware is autoloaded on module > load. Just add > > if_iwn to kld_list in /etc/rc.conf > > > Here I admit I was wrong, iwn handles it differently than iwm. The man > page lists 3 different firmware versions for the 6000 series, which > can be loaded from loader.conf When compiling DEVICE iwnfb into kern: mine (iwn6000g2bfw) doesn't load probably at bootup but with wpa_supplicant -d BSD -i wlan0 -c /etc/wpa_supplicant.conf it loads correctly and automatically assigns an IP. > built 15 hours of NanoBSD while finishing the nightly built > someone was on > Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at > all but some > reason tells me behind this system in system is something to beat > beastie in > killing KFC forks. > > > > > I get a *nice* message a bootup: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm > 1.1.0 20060810 > > > Aug 19 02:51:10 current kernel: drmn0: > on vgapci0 > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by > graphics > > > device = 2048M > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation > failed. > > > Graphics performance may suffer. > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > iicbb_nostop0 addr 0x1 > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > Aug 19 02:51:10 current kernel: iicbus1: on > intel_gmbus0 > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > iicbb_nostop1 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > Aug 19 02:51:10 current kernel: iicbus3: on > intel_gmbus1 > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > iicbb_nostop2 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > Aug 19 02:51:10 current kernel: iicbus5: on > intel_gmbus2 > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > iicbb_nostop3 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > Aug 19 02:51:10 current kernel: iicbus7: on > intel_gmbus3 > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > iicbb_nostop4 addr 0x12 > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > Aug 19 02:51:10 current kernel: iicbus9: on > intel_gmbus4 > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > iicbb_nostop5 addr 0x12 > > > > > > And furthermore: > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 > message(s) > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank > timestamp > > > caching Rev 1 (10.10.201> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports > precise > > > vblank timestamp query. > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on > drmn0 > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: > detached > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > range 0xe0000000-0xf0000000 > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: > get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.modes.LVDS-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: > get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.modes.VGA-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector > HDMI-A-1: get > > > mode from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.modes.HDMI-A-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: > get mode > > > from tunables: > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.modes.DP-1 > > > Aug 19 02:51:10 current kernel: info: [drm]   - > kern.vt.fb.default_mode > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant > locked > > > and may be deleted before> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" > with new "fb". > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > 20080730 for drmn0 on minor 0 > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > initialized. but now, when starting xinit or lightdm or sddm or > > > whatever I get a kernel panic: > > > > > > Dump header from device: /dev/ada0p4 > > > > > >   Architecture: i386 > > >   Architecture Version: 4 > > >   Dump Length: 97792 > > >   Blocksize: 512 > > >   Compression: none > > >   Dumptime: 2020-08-19 02:49:00 +0200 > > >   Hostname: current > > >   Magic: FreeBSD Text Dump > > >   Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 > 20:18:40 > > > > > > CEST 2020 > > > > > >  root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > >   Panic String: vm_page_assert_xbusied: page 0x72bd024 not > exclusive > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > >   Dump Parity: 2773167169 > > >   Bounds: 1 > > >   Dump Status: good > > > > > >   /var/crash/vmcore.0 not found > > > > Do you have  dumpdev="AUTO" in /etc/rc.conf ? > yes and the directory is /var/crash, but this is all I get as lack of > insufficent memory of dump, it says. > > Sounds like your swap device is to small. How big is it, and how much > memory do you have? > > > > > > First thing I think is kern options: > > > > > > options WITNESS_SKIPSPIN > > > options WITNESS > > > > > > I disabled device HYPERV but this can't be the reason, kern is > being > > > compiled with clang. > > > > Clang is the default since a long time. > depends on gcc++ development in 4D AIs. > > Nothing stops you from using gcc for compiling your programs. Clang is > just the default for the OS. > > > > > To disable WITNESS would be one way I think but this can't be the > > > yellw of the egg, isn't it? > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS > for some > > performance improvements. > > yup. we don't need another debugger. killing insects is murder but > when > getting better stuff I never resist to lance them. like housecats > with flys. > > > > Another thing but I guess having nothing to do with bug above > is on > > > rather the end of  startup: > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > /usr/src/sys/vm/vm_page.c:1609 > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > /var/crash/textdump.tar.1 > > > Aug 19 02:51:10 current kernel: linsysfs: > > > Aug 19 02:51:10 current kernel: Device busy > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, > lockmgr) @ > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, > lockmgr) > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs > established at: > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at > witness_checkorder+0x3c5 > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at > lockmgr_lock_flags+0x140 > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > Aug 19 02:51:10 current kernel: #9 0x10859be at > vfs_mountroot+0x4ce > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > __stop_set_sysinit_set+0xd0a4199e > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs > attempted at: > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at > witness_checkorder+0xa50 > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > any ideas? > > > Miranda > > > > > > > > > > > > does someone know how to fix it? > > > > > > Miranda > > > > Hope this helps. > It does! > > > Best regards > > Andreas Nilsson > > Yours, > Miranda van Breukelingen > > > Best regards > Andreas Nilsson From owner-freebsd-current@freebsd.org Thu Aug 20 17:05:56 2020 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 8B4083C2E52 for ; Thu, 20 Aug 2020 17:05:56 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BXWJ42cdbz4frT for ; Thu, 20 Aug 2020 17:05:56 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: by mailman.nyi.freebsd.org (Postfix) id 5815D3C2EC5; Thu, 20 Aug 2020 17:05:56 +0000 (UTC) Delivered-To: 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 57DEC3C319F for ; Thu, 20 Aug 2020 17:05:56 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXWJ33gG8z4g6r; Thu, 20 Aug 2020 17:05:55 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from disco.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 7A1775648F; Thu, 20 Aug 2020 12:05:48 -0500 (CDT) To: current@freebsd.org, kevans@freebsd.org From: Eric van Gyzen Subject: LOR: tun_ioctl after tun_mtx Message-ID: <41921dc3-b1e9-b823-12f4-d108319c08d4@vangyzen.net> Date: Thu, 20 Aug 2020 12:05:45 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BXWJ33gG8z4g6r X-Spamd-Bar: / X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[vangyzen.net]; NEURAL_SPAM_MEDIUM(0.05)[0.050]; NEURAL_SPAM_SHORT(0.45)[0.455]; FREEFALL_USER(0.00)[eric]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50:1000::/36, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 17:05:56 -0000 I see this LOR on head r364364 while running the tcptestsuite (ports/net/tcptestsuite). In fact, I interrupted a test with Ctrl-C, and got a panic. I assume it's the same, since the test was twiddling the MTU, but I haven't looked closely. Eric lock order reversal: (sleepable after non-sleepable) 1st 0xfffff802238ea690 tun_mtx (tun_mtx, sleep mutex) @ /usr/src/sys/net/if_tuntap.c:1628 2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) @ /usr/src/sys/net/if_tuntap.c:1326 lock order tun_ioctl -> tun_mtx established at: #0 0xffffffff80c432dd at witness_checkorder+0x46d #1 0xffffffff80bb38e4 at __mtx_lock_flags+0x94 #2 0xffffffff80cfad2b at tuninit+0x4b #3 0xffffffff80cfa44f at tunifioctl+0x6f #4 0xffffffff80dc398f at in6_update_ifa+0xa8f #5 0xffffffff80dc96f0 at in6_ifattach+0x5b0 #6 0xffffffff80dc577e at in6_if_up+0x7e #7 0xffffffff80ceb289 at if_up+0x69 #8 0xffffffff80cec2f7 at ifhwioctl+0xd07 #9 0xffffffff80ced475 at ifioctl+0x395 #10 0xffffffff80c490ae at kern_ioctl+0x28e #11 0xffffffff80c48d77 at sys_ioctl+0x127 #12 0xffffffff81015820 at amd64_syscall+0x140 #13 0xffffffff80febb3e at fast_syscall_common+0xf8 lock order tun_mtx -> tun_ioctl attempted at: #0 0xffffffff80c43c3c at witness_checkorder+0xdcc #1 0xffffffff80be0247 at _sx_xlock+0x67 #2 0xffffffff80cfa411 at tunifioctl+0x31 #3 0xffffffff80ceba5b at ifhwioctl+0x46b #4 0xffffffff80cf9101 at tunioctl+0x5b1 #5 0xffffffff80a7b0fc at devfs_ioctl+0xcc #6 0xffffffff80cc9bf2 at vn_ioctl+0x132 #7 0xffffffff80a7b76e at devfs_ioctl_f+0x1e #8 0xffffffff80c490ae at kern_ioctl+0x28e #9 0xffffffff80c48d77 at sys_ioctl+0x127 #10 0xffffffff81015820 at amd64_syscall+0x140 #11 0xffffffff80febb3e at fast_syscall_common+0xf8 local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_ipv4 -> ^C[-- Signal caught; please wait for cleanup --] Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock KDB: stack backtrace of thread 100505: sched_switch() at sched_switch+0x5b2/frame 0xfffffe00627165a0 mi_switch() at mi_switch+0x155/frame 0xfffffe00627165c0 sleepq_switch() at sleepq_switch+0x109/frame 0xfffffe0062716600 _sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfffffe00627166a0 _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe00627166e0 tunifioctl() at tunifioctl+0x31/frame 0xfffffe0062716720 ifhwioctl() at ifhwioctl+0x46b/frame 0xfffffe00627167a0 tunioctl() at tunioctl+0x5b1/frame 0xfffffe0062716810 devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe0062716860 vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe0062716970 devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0062716990 kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0062716a00 sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0062716ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0062716bf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0062716bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp = 0x7fffffffd408, rbp = 0x7fffffffd540 --- panic: sleeping thread cpuid = 4 time = 1597942792 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00652545e0 vpanic() at vpanic+0x182/frame 0xfffffe0065254630 panic() at panic+0x43/frame 0xfffffe0065254690 propagate_priority() at propagate_priority+0x219/frame 0xfffffe00652546d0 turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe0065254720 __mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfffffe00652547b0 __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0065254800 tunifioctl() at tunifioctl+0xdc/frame 0xfffffe0065254840 ifhwioctl() at ifhwioctl+0x2b1/frame 0xfffffe00652548c0 ifioctl() at ifioctl+0x395/frame 0xfffffe0065254990 kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0065254a00 sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0065254ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0065254bf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0065254bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp = 0x7fffffffd428, rbp = 0x7fffffffdc50 --- KDB: enter: panic [ thread pid 61418 tid 100573 ] Stopped at kdb_enter+0x37: movq $0,0x10b70b6(%rip) From owner-freebsd-current@freebsd.org Thu Aug 20 21:42:14 2020 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 A8B953A93D9 for ; Thu, 20 Aug 2020 21:42:14 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXdQs5JPSz433h for ; Thu, 20 Aug 2020 21:42:13 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id h19so3717831ljg.13 for ; Thu, 20 Aug 2020 14:42:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0mBPsMMJNZjjFYNFHJ3bY9CFipfXrjJE3lLXfJED7HM=; b=TW+NzUiLrJ2EqihNHLzvtjmk4xGktC6FvdVzQ+92Vaf3Svhb7wytji9x2bKGGs+1kT YBmezlwR9LgvNelCv2vhfMpvb8tjtTpzQPKQs3h/NoqP55P9vnQ+ps32DU4dqxd9RXeS vDvybRh3MdtLfcpa08+yoOHjWa64SjQk4muCA1DFW09YGZ/gVDqDYCnVvgRXMV25LHWh 6uNQ0trW3Fgy/rRetI8pGeWPHE1l8R/XHPgsp38oxccNUojVVGU62EhT6BxEBazzAhGU c7QYdY+Zco2ItNZNfaFBRGTQGB/V8rZgTSMbtOUANQchQn1VAda7l6fN9zl7R8PtztZK AreA== X-Gm-Message-State: AOAM530UXWMxgSKvVJERZJ5+BCEH2YT2YflkYNt4OftGqZEf9r0B6tm4 pUB5epIpYL8nzfd6WTt10GjdqyruXcXaJ6iNeTZm+GXxvg== X-Google-Smtp-Source: ABdhPJxGidClxrApb/l6UN3XjsQCHFxR9BFcnZjQADXos1al9Vi3MVL4lcv2YYeKUUREZZ0GFf669SiBJE+NonnKLuM= X-Received: by 2002:a05:651c:330:: with SMTP id b16mr137376ljp.77.1597959731040; Thu, 20 Aug 2020 14:42:11 -0700 (PDT) MIME-Version: 1.0 From: Clay Daniels Date: Thu, 20 Aug 2020 16:41:59 -0500 Message-ID: Subject: Weekly Current 13.0 Snapshot? To: "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4BXdQs5JPSz433h X-Spamd-Bar: / X-Spamd-Result: default: False [-0.58 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.77)[-0.769]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_SHORT(0.19)[0.194]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::229:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 21:42:14 -0000 I hope nobody is ill & just busy filling the weekly snapshot of 13.0 Current with new goodies. I don't see it at it's usual location: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ Clay From owner-freebsd-current@freebsd.org Thu Aug 20 21:47:09 2020 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 430E43A9C07 for ; Thu, 20 Aug 2020 21:47:09 +0000 (UTC) (envelope-from gjb@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXdXY11rQz43cS; Thu, 20 Aug 2020 21:47:09 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B12CA14B0F; Thu, 20 Aug 2020 21:47:08 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Thu, 20 Aug 2020 21:47:06 +0000 From: Glen Barber To: Clay Daniels Cc: "freebsd-current@freebsd.org" Subject: Re: Weekly Current 13.0 Snapshot? Message-ID: <20200820214706.GK61041@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mNqB7BSMRyhUYAix" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1597960029; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LPY6O4sPtNOWOIpwiqa5xOIduM9BSabW2DxXuxV/Z5s=; b=jSYGoqowt5qosBKcERBZ7Y0Bu8KpPzgsotffiMuvZssuBl7EKkWKjcaL126ectqRCg7Bzk CsrYEOuSSY3xX7Lx1G64Pnfok0hOenv8DGImhHC9gLZ1LO2XvdqP5z5awuCIh0EHVxhbCz DzDmrSwZGKM969C8jsdhnXSE1vQHKBPpIdDY6q7PJ/ruPqQgrcxL2Fdn3+wt1BiXiG9m4e d2Qvn9LWncSWppgaNfqWMAZ13hWRvPebS84w8xnjI3VMLz26VQ8ryjoNN8yemOX0XtB867 YGvFoTS1USJqh09eJTcFLNkbnpomZ5+A67yamMIbXPOPRCWrBSu4I8hJ1hpgfQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1597960029; a=rsa-sha256; cv=none; b=skUCjx+3N7JRxYrOkV13vD/aOXwKXiK7maXiem1YedofUiTcDOSAOgN1dpp9/FpDHH2gb5 BxrozGvPLbNu11AwMVCyv3i4/UZ4MlqVskJiRg1swKpIGLsavpWSDd7spHzweozpKyhFFV IgTAH2JugxDXRVf8K9MbVUty2qu7KYsb1uA61RW7zRw5hf+V0QtsZeEYlRHXQJQp9xfpcl 7d8mo8ixTSvTIsNkhwoI6jZ5Cs0gYmkFxLLohI5dWwbdYxWMVSSxhNGBeNDHaUEz1TQWLT gPsBRxo+Uy27lHIK4HLKcrYDSZ+lXRnygRTCgjTvYinAcSB8AdWE11UnQtCIVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 21:47:09 -0000 --mNqB7BSMRyhUYAix Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > Current with new goodies. I don't see it at it's usual location: >=20 > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >=20 Not ill, but indeed sick of the build being broken so much. https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.ht= ml Glen --mNqB7BSMRyhUYAix Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl8+71oACgkQAxRYpUeP 4pMlbQ/8D/YIEYy6oWOzZraPr8XY6/ZGjWhKIZHjPaaLAUdcjb7vKje5vT8Y87qG 1DhvIdBjdPcpGDaw1emEU/PAiINtatBvqe/FWbsQR0MxoWVpaUxLPZQgcX4/e/Os 7MmSzZiltOzjy9TqKsN35uk5AtoCVpfTge0hg8Ecc/AQgBFZ0FuUquq3VqiRX3RH YPwiOV/r3tcYKnE4Cz133IEGj+2z8T1gqIJoYj7ee61P2zAqMH0vkvGVKhZFk80z LIX25V9pq51AR6lT6QmQi03bNe2hVa605uQivSvyvDlM5OBGGlkaLDdRYMSOWuB0 y1dgvEHD12xtfoHMtUQ4kW5uvB4QsXm4RfqZnx8nIrBz4cFfO6x01HQxg3qru4jK qNn3aGkVqhkfhzfif96jRD8GKOFkM6Pfhrnm9+2c4wkFdYaDHH3Wwgd9GOGt6xc0 lTdoHbSElfp61QadYXOYgpZvfCrgC0HMbm/zwqZ6mUKa+n456NQnaZKV92QYUY0t AuND/3cqLAie9Be65WOYVRerxpNSVcfALpNmcfXfBfeVT36+/8lDkXNR1kbgPGPZ 1MmdmXgf6w7XvKKWsG5Ud949wE4DlP91/a9s0xVF/DWvhd2iSbyijhv8ZfI+Swc5 o1yCItWVyflLQsz/YiowiPvS2VOog46I6nNvDVEQVv5eOgTtKIU= =IPNm -----END PGP SIGNATURE----- --mNqB7BSMRyhUYAix-- From owner-freebsd-current@freebsd.org Thu Aug 20 21:54:52 2020 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 4743F3AA219 for ; Thu, 20 Aug 2020 21:54:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXdjQ4s2Sz442X for ; Thu, 20 Aug 2020 21:54:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id s16so2334653qtn.7 for ; Thu, 20 Aug 2020 14:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xhoBu1M8NuvPWub+V0UuHPNF3IUyCz8XduvpbVh9MHE=; b=JpWtOpEkHPKKP4BBXzioZ3lcsJKWNJPoVdunOk7lrpyNwEq1HathNzdgiKcJplgUYM Lj99XGr+p9tz+Y2EACNDp7q6AGKCjglxthopdVmlA8yEVlX/aVvcqgH5lOyO18Qq5Oov r6iNh84NA3tKwi7gyoLgZ7uys6pv5dt19HhlBSTMV7e3vHSLwDWq2UveHQVPJ2G4+fXw KScjcopGK4BpuB1NsF1FpfCQK3sxir1woh8sWitizg7lX/y7haE2D67Kxb1NC6fNUcrj bQbKYXF/fiBYYfWGVMZj12kNceHx0ScpfzAw3EtvKEwTGPStEe3Takdxaj5wEQOKofdC sbQA== X-Gm-Message-State: AOAM530c1MePbEXGyIHzIIYBqFLDurHGBmN2UCbR7MDtQrd64UWHtPyt dK4mjwEgvPJRtWdAlufFsaiOeXOvtWh3EcaQ6gEGsQ== X-Google-Smtp-Source: ABdhPJx1gKrZjm/pcl5RfpfvL5Ncmi392inE5t1pTAnSNRNTA2ZUrnif02AryuGUPO4Q6iwKlUuGm7Sqhp1WEZ5r0Dc= X-Received: by 2002:ac8:47c8:: with SMTP id d8mr598377qtr.32.1597960488870; Thu, 20 Aug 2020 14:54:48 -0700 (PDT) MIME-Version: 1.0 References: <20200820214706.GK61041@FreeBSD.org> In-Reply-To: <20200820214706.GK61041@FreeBSD.org> From: Warner Losh Date: Thu, 20 Aug 2020 15:54:37 -0600 Message-ID: Subject: Re: Weekly Current 13.0 Snapshot? To: Glen Barber Cc: Clay Daniels , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4BXdjQ4s2Sz442X X-Spamd-Bar: / X-Spamd-Result: default: False [0.42 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.122]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::836:from]; NEURAL_HAM_MEDIUM(-0.70)[-0.702]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; DMARC_NA(0.00)[bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 21:54:52 -0000 On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > > Current with new goodies. I don't see it at it's usual location: > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > > > > Not ill, but indeed sick of the build being broken so much. > > > https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.html Build isn't broken now, can't you just run it again? Warner From owner-freebsd-current@freebsd.org Thu Aug 20 22:39:08 2020 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 D43C83AAFB2 for ; Thu, 20 Aug 2020 22:39:08 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXfhX3zdJz46Gy; Thu, 20 Aug 2020 22:39:08 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from [192.168.1.17] (24.102.164.36.res-cmts.swb2.ptd.net [24.102.164.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id DEBA12DFDE; Thu, 20 Aug 2020 22:38:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us DEBA12DFDE Mime-Version: 1.0 (1.0) Subject: Re: Weekly Current 13.0 Snapshot? From: Glen Barber In-Reply-To: Date: Thu, 20 Aug 2020 18:38:58 -0400 Cc: Clay Daniels , "freebsd-current@freebsd.org" Message-Id: References: To: Warner Losh X-Mailer: iPhone Mail (17G68) X-Rspamd-Queue-Id: 4BXfhX3zdJz46Gy X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:36236, ipnet:208.86.227.0/24, country:US]; TAGGED_RCPT(0.00)[]; local_wl_from(0.00)[FreeBSD.org] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 22:39:08 -0000 Not without putting a wedge in place with updating scripts for the git conve= rsion, which as you know, I am already past the deadline. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >> > Current with new goodies. I don't see it at it's usual location: >> >=20 >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/= >> >=20 >>=20 >> Not ill, but indeed sick of the build being broken so much. >>=20 >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.= html >=20 > Build isn't broken now, can't you just run it again? >=20 > Warner=20 From owner-freebsd-current@freebsd.org Thu Aug 20 23:43:36 2020 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 622F23ACE8B for ; Thu, 20 Aug 2020 23:43:36 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BXh6v2pClz4CMH; Thu, 20 Aug 2020 23:43:35 +0000 (UTC) (envelope-from clay.daniels.jr@gmail.com) Received: by mail-lj1-x22a.google.com with SMTP id t23so4011306ljc.3; Thu, 20 Aug 2020 16:43:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9nl0AmTodoYXjN5uD/QeXyUAJIGoLzgwnynSpXb4niE=; b=R+VRYhIgo4QrS+xCzkb2jw4lBsKq4C8IKrK3KMJlB2RPtnbWswMMQXKa15yqEmM2ZP XqMUqoRgXUxX8e8/LBaBiNtGjAd3HikWbdD83AFKHLthn/gx0ii3iWoaHgnYkwVmggIb nfMp9wH5m7rf4rSy6Pzqs9xy3V9IWxD5Wo21wXDKCYeX8SLJEFVfwqvzWRCv9/1hicvf 9YGe0RnwpyhAPa8ukDM2E/TLqj68T9b87vjhcADSXAAWMf38QR6blrAVNJNgqKlO11Xo hp4hFXjOWVmNKksINUC6AUZbyEs/PdjiUTMGGnAHx5DMOGxYiC6Mi/N/mS1XTBRiPpJe 4qaw== X-Gm-Message-State: AOAM531TsJZv6IZUxMeaol8sDEqTkGEpURD7vL+4qo0hewq5AmB+VAsj Y/wA88w4I4lilnvCG4ez9g5/M8jKS5bIuJv553Lf6jE= X-Google-Smtp-Source: ABdhPJx5kEWO3Q6YV5E02N9U3upiAFUx91HmqvOx+9shczKPX2A+DsISWZzTVobcQjCyfLsWvS7yYTlhUXtiM8ukAHw= X-Received: by 2002:a2e:b5b3:: with SMTP id f19mr173923ljn.210.1597967012464; Thu, 20 Aug 2020 16:43:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clay Daniels Date: Thu, 20 Aug 2020 18:43:19 -0500 Message-ID: Subject: Re: Weekly Current 13.0 Snapshot? To: Glen Barber Cc: Warner Losh , "freebsd-current@freebsd.org" X-Rspamd-Queue-Id: 4BXh6v2pClz4CMH X-Spamd-Bar: / X-Spamd-Result: default: False [-0.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_MEDIUM(-0.94)[-0.943]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22a:from]; NEURAL_HAM_SHORT(-0.05)[-0.046]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 23:43:36 -0000 Sorry to bug you. I didn't even know about the snapshot email list, but I have just subscribed and will know next time. Do what you need to and don't worry about the snapshot this week. I too am busy this week and have plenty to do. Clay On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: > Not without putting a wedge in place with updating scripts for the git > conversion, which as you know, I am already past the deadline. > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. > > On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: > > =EF=BB=BF > > > On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >> > Current with new goodies. I don't see it at it's usual location: >> > >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0= / >> > >> >> Not ill, but indeed sick of the build being broken so much. >> >> >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739= .html > > > Build isn't broken now, can't you just run it again? > > Warner > > From owner-freebsd-current@freebsd.org Thu Aug 20 23:48:31 2020 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 882DD3AD118 for ; Thu, 20 Aug 2020 23:48:31 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXhDb1B2qz4CSQ; Thu, 20 Aug 2020 23:48:30 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from [192.168.1.17] (24.102.164.36.res-cmts.swb2.ptd.net [24.102.164.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id EAD212D044; Thu, 20 Aug 2020 23:48:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us EAD212D044 Mime-Version: 1.0 (1.0) Subject: Re: Weekly Current 13.0 Snapshot? From: Glen Barber In-Reply-To: Date: Thu, 20 Aug 2020 19:48:23 -0400 Cc: Warner Losh , "freebsd-current@freebsd.org" Message-Id: References: To: Clay Daniels X-Mailer: iPhone Mail (17G68) X-Rspamd-Queue-Id: 4BXhDb1B2qz4CSQ X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US]; TAGGED_RCPT(0.00)[]; local_wl_from(0.00)[FreeBSD.org] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 20 Aug 2020 23:48:31 -0000 Not bugging at all. I=E2=80=99m hoping that the state that machine is in now, with some sanding o= ff some newly-discovered rough edges of some code changes, to have snapshots= from git before Wednesday. Fingers crossed.... Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 20, 2020, at 7:43 PM, Clay Daniels wrot= e: >=20 > =EF=BB=BF > Sorry to bug you. I didn't even know about the snapshot email list, but I h= ave just subscribed and will know next time. Do what you need to and don't w= orry about the snapshot this week. I too am busy this week and have plenty t= o do. >=20 > Clay >=20 >> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: >> Not without putting a wedge in place with updating scripts for the git co= nversion, which as you know, I am already past the deadline. >>=20 >> Glen >> Sent from my phone. >> Please excuse my brevity and/or typos. >>=20 >>>> On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: >>>>=20 >>> =EF=BB=BF >>>=20 >>>=20 >>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>>> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>>> > Current with new goodies. I don't see it at it's usual location: >>>> >=20 >>>> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.= 0/ >>>> >=20 >>>>=20 >>>> Not ill, but indeed sick of the build being broken so much. >>>>=20 >>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/00073= 9.html >>>=20 >>> Build isn't broken now, can't you just run it again? >>>=20 >>> Warner=20 From owner-freebsd-current@freebsd.org Fri Aug 21 17:38:00 2020 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 AF6163C3BA0 for ; Fri, 21 Aug 2020 17:38:00 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BY7yb4NMxz4GPr for ; Fri, 21 Aug 2020 17:37:59 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-ed1-x543.google.com with SMTP id w14so1610587eds.0 for ; Fri, 21 Aug 2020 10:37:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DJEVDmTfru+d0ko5egoJc30rJV8egWRnVYxgBo8xL6s=; b=h3iZ+BMJ2jcE8tB08c8RO2y8++u2P2/tvcKj1kAHYQ3YlzI+yASRXVpNfda/jwi5JG OxFTcW+Cui1/phUIlnb0Ttz0Lc97WtRsnwaBvRSMjw2XN1RgzGSxEXpUJDjj34eEUUv4 zSW7NeoC1qVV+05WgWl9wGKPHXeT3DvsDwNpCW1VnrgXd0ZlhTij8BQxu5NYUbJlP3ts YdzuyZVqdk5poYfE0TuC0sG2CkC+UH1VwIRF3cKOsF/iN2VKrGNzYY6u8EcDYzysHeFe zdUR5AJ4fshAaMV45Jtq+dUH6THq6uppGZ6bhp8GRKS6ppX9p7051ZsKjrF6aBVGp+IB ngww== X-Gm-Message-State: AOAM533GOunmkezxd1z1Y630NVqhTP6rV7QhrbFawXlbcGns3C0TwLnj hvKFF3lbu1BRma2U3CExk/oyNtEK+f4KgWHi X-Google-Smtp-Source: ABdhPJx95yyBOjH1KYwhKjA306nXC423m4DLqBkKppqZjHvkr+COA+UaHYWHxA+ECu3GkF6ARIHeGw== X-Received: by 2002:aa7:d9d0:: with SMTP id v16mr4032560eds.137.1598031477107; Fri, 21 Aug 2020 10:37:57 -0700 (PDT) Received: from alice.localnet (213162072245.public.t-mobile.at. [213.162.72.245]) by smtp.gmail.com with ESMTPSA id c5sm1660545ejb.103.2020.08.21.10.37.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2020 10:37:56 -0700 (PDT) From: "Vanbreukelingen Ltd." To: freebsd-current@freebsd.org Subject: Re: freebsd-current Digest, Vol 877, Issue 6 Date: Fri, 21 Aug 2020 19:37:54 +0200 Message-ID: <2624761.GQDcWxOStt@alice> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4BY7yb4NMxz4GPr X-Spamd-Bar: - X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; CTE_CASE(0.50)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.813]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.81)[-0.812]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.19)[0.189]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::543:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Fri, 21 Aug 2020 17:38:00 -0000 here we go - when nothing works anymore (kernel panic after a simple 'xinit' and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics. https://pasteboard.co/Jnqgbeq.png On Friday, August 21, 2020 2:00:00 PM CEST freebsd-current-request@freebsd.org wrote: > Message: 1 > Date: Thu, 20 Aug 2020 08:15:56 +0200 > From: "Vanbreukelingen Ltd." > To: Current FreeBSD > Subject: Re: funny thing with the drm0 > Message-ID: <8073347.hK6j7OjjKr@alice> > Content-Type: text/plain; charset="us-ascii" > > On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote: > > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > > > lizbethmutterhunt@gmail.com> wrote: > > > > After having had some near-death-experiences in Greece I'm back to my > > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > > > > After finally recompiling the kernel with the drm-module inside and > > > > the trick of injecting the > > > > > > This is not the way to do it. Modern hardware require drm-kmod from > > > ports, > > > or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko > > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > > wasn't yet finished (c [see] beyond), but I guess I have to disable the > whole output with something like hw.*=1 or so. is it possible to make a > bootlogo while VEBOSE output = 2 just for the reason some kids try to play > with it. > > > > > device IWNFW > > doesn't install the 6000, btw --- probably can't find FW on device HAL. > > > > Again, this is not needed, firmware is autoloaded on module load. Just > > > add > > > if_iwn to kld_list in /etc/rc.conf > > built of 15 hours of NanoBSD while finishing the nightly built someone was > on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all > but some reason tells me behind this system in system is something to beat > beastie in killing KFC forks. ;-) > > > > > I get a *nice* message a bootup: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 > > > > 20060810 > > > > Aug 19 02:51:10 current kernel: drmn0: on > > > > vgapci0 > > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > > > > device = 2048M > > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > > > > Graphics performance may suffer. > > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > > iicbb_nostop0 addr 0x1 > > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > > Aug 19 02:51:10 current kernel: iicbus1: on > > > > intel_gmbus0 > > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > > iicbb_nostop1 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > > Aug 19 02:51:10 current kernel: iicbus3: on > > > > intel_gmbus1 > > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > > iicbb_nostop2 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > > Aug 19 02:51:10 current kernel: iicbus5: on > > > > intel_gmbus2 > > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > > iicbb_nostop3 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > > Aug 19 02:51:10 current kernel: iicbus7: on > > > > intel_gmbus3 > > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > > iicbb_nostop4 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > > Aug 19 02:51:10 current kernel: iicbus9: on > > > > intel_gmbus4 > > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > > iicbb_nostop5 addr 0x12 > > > > > > > > And furthermore: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > > > > caching Rev 1 (10.10.201> > > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > > > > vblank timestamp query. > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > > range 0xe0000000-0xf0000000 > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.modes.LVDS-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > > > > mode from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.modes.HDMI-A-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > > > > and may be deleted before> > > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new > > > > "fb". > > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > > 20080730 for drmn0 on minor 0 > > > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > > initialized. but now, when starting xinit or lightdm or sddm or > > > > whatever I get a kernel panic: > > > > > > > > Dump header from device: /dev/ada0p4 > > > > > > > > Architecture: i386 > > > > Architecture Version: 4 > > > > Dump Length: 97792 > > > > Blocksize: 512 > > > > Compression: none > > > > Dumptime: 2020-08-19 02:49:00 +0200 > > > > Hostname: current > > > > Magic: FreeBSD Text Dump > > > > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > > > > > > > > CEST 2020 > > > > > > > > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > > > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > > > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > > > Dump Parity: 2773167169 > > > > Bounds: 1 > > > > Dump Status: good > > > > > > > > /var/crash/vmcore.0 not found > > > > > > Do you have dumpdev="AUTO" in /etc/rc.conf ? > > yes and the directory is /var/crash, but this is all I get as lack of > insufficent memory of dump, it says. > > > > > First thing I think is kern options: > > > > > > > > options WITNESS_SKIPSPIN > > > > options WITNESS > > > > > > > > I disabled device HYPERV but this can't be the reason, kern is being > > > > compiled with clang. > > > > > > Clang is the default since a long time. > > depends on gcc++ development in 4D AIs. > > > > > To disable WITNESS would be one way I think but this can't be the > > > > yellw of the egg, isn't it? > > > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some > > > performance improvements. > > yup. we don't need another debugger. killing insects is murder but when > getting better stuff I never resist to lance them. like housecats with flys. > > > > Another thing but I guess having nothing to do with bug above is on > > > > rather the end of startup: > > > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > > /usr/src/sys/vm/vm_page.c:1609 > > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > > /var/crash/textdump.tar.1 > > > > Aug 19 02:51:10 current kernel: linsysfs: > > > > Aug 19 02:51:10 current kernel: Device busy > > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > > Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ > > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > > Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) > > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established > > > > at: > > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at > > > > witness_checkorder+0x3c5 > > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at > > > > lockmgr_lock_flags+0x140 > > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > > __stop_set_sysinit_set+0xd0a4199e > > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at > > > > witness_checkorder+0xa50 > > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > > > any ideas? > > > > Miranda > > > > > > > > > > > > > > > > does someone know how to fix it? > > > > > > > > Miranda > > > > > > Hope this helps. > > It does! > > > > Best regards > > > Andreas Nilsson > > Yours, > Miranda van Breukelingen > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 20 Aug 2020 16:43:56 +0200 > From: Andreas Nilsson > To: "Vanbreukelingen Ltd." , Current > FreeBSD > Subject: Re: funny thing with the drm0 > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. < > > lizbethmutterhunt@gmail.com> wrote: > > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > > > lizbethmutterhunt@gmail.com> wrote: > > > > After having had some near-death-experiences in Greece I'm back to my > > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) > > > > > > > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > > > > After finally recompiling the kernel with the drm-module inside and > > > > the trick of injecting the > > > > > > This is not the way to do it. Modern hardware require drm-kmod from > > > > ports, > > > > > or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko > > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > > > > wasn't yet finished (c [see] beyond), but I guess I have to disable the > > whole > > output with something like hw.*=1 or so. is it possible to make a bootlogo > > while VEBOSE output = 2 just for the reason some kids try to play with it. > > > > > > device IWNFW > > > > doesn't install the 6000, btw --- probably can't find FW on device HAL. > > > > > Again, this is not needed, firmware is autoloaded on module load. Just > > > > add > > > > > if_iwn to kld_list in /etc/rc.conf > > Here I admit I was wrong, iwn handles it differently than iwm. The man page > lists 3 different firmware versions for the 6000 series, which can be > loaded from loader.conf > > > built 15 hours of NanoBSD while finishing the nightly built someone was on > > Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but > > some > > reason tells me behind this system in system is something to beat beastie > > in > > killing KFC forks. > > > > > > I get a *nice* message a bootup: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 > > > > 20060810 > > > > > > Aug 19 02:51:10 current kernel: drmn0: on > > > > vgapci0 > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics > > > > device = 2048M > > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. > > > > Graphics performance may suffer. > > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > > iicbb_nostop0 addr 0x1 > > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > > Aug 19 02:51:10 current kernel: iicbus1: on > > > > intel_gmbus0 > > > > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > > iicbb_nostop1 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > > Aug 19 02:51:10 current kernel: iicbus3: on > > > > intel_gmbus1 > > > > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > > iicbb_nostop2 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > > Aug 19 02:51:10 current kernel: iicbus5: on > > > > intel_gmbus2 > > > > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > > iicbb_nostop3 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > > Aug 19 02:51:10 current kernel: iicbus7: on > > > > intel_gmbus3 > > > > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > > iicbb_nostop4 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > > Aug 19 02:51:10 current kernel: iicbus9: on > > > > intel_gmbus4 > > > > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > > iicbb_nostop5 addr 0x12 > > > > > > > > And furthermore: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) > > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp > > > > caching Rev 1 (10.10.201> > > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise > > > > vblank timestamp query. > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached > > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > > range 0xe0000000-0xf0000000 > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.modes.LVDS-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get > > > > mode from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.modes.HDMI-A-1 > > > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 > > > > Aug 19 02:51:10 current kernel: info: [drm] - > > > > kern.vt.fb.default_mode > > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked > > > > and may be deleted before> > > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new > > > > "fb". > > > > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > > 20080730 for drmn0 on minor 0 > > > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > > initialized. but now, when starting xinit or lightdm or sddm or > > > > whatever I get a kernel panic: > > > > > > > > Dump header from device: /dev/ada0p4 > > > > > > > > Architecture: i386 > > > > Architecture Version: 4 > > > > Dump Length: 97792 > > > > Blocksize: 512 > > > > Compression: none > > > > Dumptime: 2020-08-19 02:49:00 +0200 > > > > Hostname: current > > > > Magic: FreeBSD Text Dump > > > > Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 > > > > > > > > CEST 2020 > > > > > > > > root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > > > Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive > > > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > > > Dump Parity: 2773167169 > > > > Bounds: 1 > > > > Dump Status: good > > > > > > > > /var/crash/vmcore.0 not found > > > > > > Do you have dumpdev="AUTO" in /etc/rc.conf ? > > > > yes and the directory is /var/crash, but this is all I get as lack of > > insufficent memory of dump, it says. > > Sounds like your swap device is to small. How big is it, and how much > memory do you have? > > > > > First thing I think is kern options: > > > > > > > > options WITNESS_SKIPSPIN > > > > options WITNESS > > > > > > > > I disabled device HYPERV but this can't be the reason, kern is being > > > > compiled with clang. > > > > > > Clang is the default since a long time. > > > > depends on gcc++ development in 4D AIs. > > > > Nothing stops you from using gcc for compiling your programs. Clang is > > just the default for the OS. > > > > > To disable WITNESS would be one way I think but this can't be the > > > > yellw of the egg, isn't it? > > > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some > > > performance improvements. > > > > yup. we don't need another debugger. killing insects is murder but when > > getting better stuff I never resist to lance them. like housecats with > > flys. > > > > > > Another thing but I guess having nothing to do with bug above is on > > > > rather the end of startup: > > > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > > /usr/src/sys/vm/vm_page.c:1609 > > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > > /var/crash/textdump.tar.1 > > > > Aug 19 02:51:10 current kernel: linsysfs: > > > > Aug 19 02:51:10 current kernel: Device busy > > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > > Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ > > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > > Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) > > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established > > > > at: > > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at > > > > witness_checkorder+0x3c5 > > > > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at > > > > lockmgr_lock_flags+0x140 > > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce > > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > > __stop_set_sysinit_set+0xd0a4199e > > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: > > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at > > > > witness_checkorder+0xa50 > > > > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > > > any ideas? > > > > Miranda > > > > > > > > > > > > > > > > does someone know how to fix it? > > > > > > > > Miranda > > > > > > Hope this helps. > > > > It does! > > > > > Best regards > > > Andreas Nilsson > > > > Yours, > > Miranda van Breukelingen > > > > > > Best regards > > Andreas Nilsson > > > ------------------------------ > > Message: 3 > Date: Thu, 20 Aug 2020 16:58:25 +0200 > From: "Vanbreukelingen Ltd." > To: Andreas Nilsson , freebsd-current@freebsd.org > Subject: Re: funny thing with the drm0 > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2020-08-20 16:43, Andreas Nilsson wrote: > > On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. > > > > > wrote: > > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: > > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < > > > > > > lizbethmutterhunt@gmail.com > > > > > wrote: > > > > After having had some near-death-experiences in Greece I'm > > > > back to my > > > > > > screens. As horizon arises, BSD gets up --- and if it is 3 > > > > a.m.! :-) > > > > > > But this is the experience with my Dell Vostro on 13 current: > > > > > > > > > > > > After finally recompiling the kernel with the drm-module > > > > inside and > > > > > > the trick of injecting the > > > > > > This is not the way to do it. Modern hardware require drm-kmod > > > > from ports, > > > > > or if you want the latest drm-devel-kmod. Then add > > > > /boot/modules/drm.ko > > > > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf > > > > wasn't yet finished (c [see] beyond), but I guess I have to > > disable the whole > > output with something like hw.*=1 or so. is it possible to make a > > bootlogo > > while VEBOSE output = 2 just for the reason some kids try to play > > with it. > > tried it now: next kernel panic on lightdm and sddm makes a mouse in > mouse pointer over a blank screen. the driver is initialised but hungs > up like this: > > Dump header from device: /dev/ada0p4 > ? Architecture: i386 > ? Architecture Version: 4 > ? Dump Length: 97792 > ? Blocksize: 512 > ? Compression: none > ? Dumptime: 2020-08-20 16:41:45 +0200 > ? Hostname: current > ? Magic: FreeBSD Text Dump > ? Version String: FreeBSD 13.0-CURRENT #3 r364372: Wed Aug 19 07:54:57 > CEST 2020 > ??? root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy > @ /usr/src/sys/vm/vm_page.c:1609** > **? Dump Parity: 4227235352* > ? Bounds: 2 > ? Dump Status: good > > > > > device IWNFW > > > > doesn't install the 6000, btw --- probably can't find FW on device > > HAL. > > > > > Again, this is not needed, firmware is autoloaded on module > > > > load. Just add > > > > > if_iwn to kld_list in /etc/rc.conf > > > > Here I admit I was wrong, iwn handles it differently than iwm. The man > > page lists 3 different firmware versions for the 6000 series, which > > can be loaded from loader.conf > > When compiling DEVICE iwnfb into kern: mine (iwn6000g2bfw) doesn't load > probably at bootup but with wpa_supplicant -d BSD -i wlan0 -c > /etc/wpa_supplicant.conf it loads correctly and automatically assigns an > IP. > > > built 15 hours of NanoBSD while finishing the nightly built > > someone was on > > Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at > > all but some > > reason tells me behind this system in system is something to beat > > beastie in > > killing KFC forks. > > > > > > I get a *nice* message a bootup: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm > > > > 1.1.0 20060810 > > > > > > Aug 19 02:51:10 current kernel: drmn0: > > > > on vgapci0 > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by > > > > graphics > > > > > > device = 2048M > > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation > > > > failed. > > > > > > Graphics performance may suffer. > > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus0: on > > > > iicbb_nostop0 addr 0x1 > > > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 > > > > Aug 19 02:51:10 current kernel: iicbus1: on > > > > intel_gmbus0 > > > > > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 > > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus2: on > > > > iicbb_nostop1 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 > > > > Aug 19 02:51:10 current kernel: iicbus3: on > > > > intel_gmbus1 > > > > > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 > > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus4: on > > > > iicbb_nostop2 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 > > > > Aug 19 02:51:10 current kernel: iicbus5: on > > > > intel_gmbus2 > > > > > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 > > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus6: on > > > > iicbb_nostop3 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 > > > > Aug 19 02:51:10 current kernel: iicbus7: on > > > > intel_gmbus3 > > > > > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 > > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus8: on > > > > iicbb_nostop4 addr 0x12 > > > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 > > > > Aug 19 02:51:10 current kernel: iicbus9: on > > > > intel_gmbus4 > > > > > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 > > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 > > > > Aug 19 02:51:10 current kernel: iicbus10: on > > > > iicbb_nostop5 addr 0x12 > > > > > > > > And furthermore: > > > > > > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 > > > > message(s) > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank > > > > timestamp > > > > > > caching Rev 1 (10.10.201> > > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports > > > > precise > > > > > > vblank timestamp query. > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on > > > > drmn0 > > > > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: > > detached > > > > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 > > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious > > > > range 0xe0000000-0xf0000000 > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: > > get mode > > > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.modes.LVDS-1 > > > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.default_mode > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: > > get mode > > > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.modes.VGA-1 > > > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.default_mode > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector > > > > HDMI-A-1: get > > > > > > mode from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.modes.HDMI-A-1 > > > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.default_mode > > > > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: > > get mode > > > > > > from tunables: > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.modes.DP-1 > > > > > > Aug 19 02:51:10 current kernel: info: [drm]? ?- > > > > kern.vt.fb.default_mode > > > > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 > > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant > > > > locked > > > > > > and may be deleted before> > > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" > > > > with new "fb". > > > > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 > > > > 20080730 for drmn0 on minor 0 > > > > > > > > so far so good, quality of text in grafics 1368x1024 is perfectly > > > > initialized. but now, when starting xinit or lightdm or sddm or > > > > whatever I get a kernel panic: > > > > > > > > Dump header from device: /dev/ada0p4 > > > > > > > >? ?Architecture: i386 > > > >? ?Architecture Version: 4 > > > >? ?Dump Length: 97792 > > > >? ?Blocksize: 512 > > > >? ?Compression: none > > > >? ?Dumptime: 2020-08-19 02:49:00 +0200 > > > >? ?Hostname: current > > > >? ?Magic: FreeBSD Text Dump > > > >? ?Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 > > > > 20:18:40 > > > > > > CEST 2020 > > > > > > > > ?root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA > > > > > > > >? ?Panic String: vm_page_assert_xbusied: page 0x72bd024 not > > > > exclusive > > > > > > busy @ /usr/src/sys/vm/vm> > > > > > > > >? ?Dump Parity: 2773167169 > > > >? ?Bounds: 1 > > > >? ?Dump Status: good > > > > > > > >? ?/var/crash/vmcore.0 not found > > > > > > Do you have? dumpdev="AUTO" in /etc/rc.conf ? > > > > yes and the directory is /var/crash, but this is all I get as lack of > > insufficent memory of dump, it says. > > > > Sounds like your swap device is to small. How big is it, and how much > > memory do you have? > > > > > > First thing I think is kern options: > > > > > > > > options WITNESS_SKIPSPIN > > > > options WITNESS > > > > > > > > I disabled device HYPERV but this can't be the reason, kern is > > > > being > > > > > > compiled with clang. > > > > > > Clang is the default since a long time. > > > > depends on gcc++ development in 4D AIs. > > > > Nothing stops you from using gcc for compiling your programs. Clang is > > just the default for the OS. > > > > > > To disable WITNESS would be one way I think but this can't be the > > > > yellw of the egg, isn't it? > > > > > > I use the GENERIC-NODEBUG kernel config which disables WITNESS > > > > for some > > > > > performance improvements. > > > > yup. we don't need another debugger. killing insects is murder but > > when > > getting better stuff I never resist to lance them. like housecats > > with flys. > > > > > > Another thing but I guess having nothing to do with bug above > > > > is on > > > > > > rather the end of? startup: > > > > > > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: > > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ > > > > /usr/src/sys/vm/vm_page.c:1609 > > > > Aug 19 02:51:10 current savecore[1209]: writing core to > > > > /var/crash/textdump.tar.1 > > > > Aug 19 02:51:10 current kernel: linsysfs: > > > > Aug 19 02:51:10 current kernel: Device busy > > > > Aug 19 02:51:10 current kernel: lock order reversal: > > > > Aug 19 02:51:10 current kernel:? 1st 0x3121e870 ufs (ufs, > > > > lockmgr) @ > > > > > > /usr/src/sys/kern/vfs_mount.c:1008 > > > > Aug 19 02:51:10 current kernel:? 2nd 0x3121e744 devfs (devfs, > > > > lockmgr) > > > > > > @ /usr/src/sys/kern/vfs_mount.c:1019 > > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs > > > > established at: > > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at > > > > witness_checkorder+0x3c5 > > > > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at > > > > lockmgr_lock_flags+0x140 > > > > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 > > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 > > > > Aug 19 02:51:10 current kernel: #9 0x10859be at > > > > vfs_mountroot+0x4ce > > > > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 > > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 > > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at > > > > __stop_set_sysinit_set+0xd0a4199e > > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs > > > > attempted at: > > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at > > > > witness_checkorder+0xa50 > > > > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 > > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a > > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f > > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f > > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 > > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b > > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d > > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 > > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at > > > > __stop_set_sysinit_set+0xd0a41989 > > > > > > > > any ideas? > > > > Miranda > > > > > > > > > > > > > > > > does someone know how to fix it? > > > > > > > > Miranda > > > > > > Hope this helps. > > > > It does! > > > > > Best regards > > > Andreas Nilsson > > > > Yours, > > Miranda van Breukelingen > > > > Best regards > > Andreas Nilsson > > ------------------------------ > > Message: 4 > Date: Thu, 20 Aug 2020 12:05:45 -0500 > From: Eric van Gyzen > To: current@freebsd.org, kevans@freebsd.org > Subject: LOR: tun_ioctl after tun_mtx > Message-ID: <41921dc3-b1e9-b823-12f4-d108319c08d4@vangyzen.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > I see this LOR on head r364364 while running the tcptestsuite > (ports/net/tcptestsuite). In fact, I interrupted a test with Ctrl-C, > and got a panic. I assume it's the same, since the test was twiddling > the MTU, but I haven't looked closely. > > Eric > > lock order reversal: (sleepable after non-sleepable) > 1st 0xfffff802238ea690 tun_mtx (tun_mtx, sleep mutex) @ > /usr/src/sys/net/if_tuntap.c:1628 > 2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) @ > /usr/src/sys/net/if_tuntap.c:1326 > lock order tun_ioctl -> tun_mtx established at: > #0 0xffffffff80c432dd at witness_checkorder+0x46d > #1 0xffffffff80bb38e4 at __mtx_lock_flags+0x94 > #2 0xffffffff80cfad2b at tuninit+0x4b > #3 0xffffffff80cfa44f at tunifioctl+0x6f > #4 0xffffffff80dc398f at in6_update_ifa+0xa8f > #5 0xffffffff80dc96f0 at in6_ifattach+0x5b0 > #6 0xffffffff80dc577e at in6_if_up+0x7e > #7 0xffffffff80ceb289 at if_up+0x69 > #8 0xffffffff80cec2f7 at ifhwioctl+0xd07 > #9 0xffffffff80ced475 at ifioctl+0x395 > #10 0xffffffff80c490ae at kern_ioctl+0x28e > #11 0xffffffff80c48d77 at sys_ioctl+0x127 > #12 0xffffffff81015820 at amd64_syscall+0x140 > #13 0xffffffff80febb3e at fast_syscall_common+0xf8 > lock order tun_mtx -> tun_ioctl attempted at: > #0 0xffffffff80c43c3c at witness_checkorder+0xdcc > #1 0xffffffff80be0247 at _sx_xlock+0x67 > #2 0xffffffff80cfa411 at tunifioctl+0x31 > #3 0xffffffff80ceba5b at ifhwioctl+0x46b > #4 0xffffffff80cf9101 at tunioctl+0x5b1 > #5 0xffffffff80a7b0fc at devfs_ioctl+0xcc > #6 0xffffffff80cc9bf2 at vn_ioctl+0x132 > #7 0xffffffff80a7b76e at devfs_ioctl_f+0x1e > #8 0xffffffff80c490ae at kern_ioctl+0x28e > #9 0xffffffff80c48d77 at sys_ioctl+0x127 > #10 0xffffffff81015820 at amd64_syscall+0x140 > #11 0xffffffff80febb3e at fast_syscall_common+0xf8 > > local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_i > pv4 -> ^C[-- Signal caught; please wait for cleanup --] > > Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock > KDB: stack backtrace of thread 100505: > sched_switch() at sched_switch+0x5b2/frame 0xfffffe00627165a0 > mi_switch() at mi_switch+0x155/frame 0xfffffe00627165c0 > sleepq_switch() at sleepq_switch+0x109/frame 0xfffffe0062716600 > _sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfffffe00627166a0 > _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe00627166e0 > tunifioctl() at tunifioctl+0x31/frame 0xfffffe0062716720 > ifhwioctl() at ifhwioctl+0x46b/frame 0xfffffe00627167a0 > tunioctl() at tunioctl+0x5b1/frame 0xfffffe0062716810 > devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe0062716860 > vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe0062716970 > devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0062716990 > kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0062716a00 > sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0062716ad0 > amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0062716bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0062716bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp = > 0x7fffffffd408, rbp = 0x7fffffffd540 --- > panic: sleeping thread > cpuid = 4 > time = 1597942792 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00652545e0 > vpanic() at vpanic+0x182/frame 0xfffffe0065254630 > panic() at panic+0x43/frame 0xfffffe0065254690 > propagate_priority() at propagate_priority+0x219/frame 0xfffffe00652546d0 > turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe0065254720 > __mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfffffe00652547b0 > __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0065254800 > tunifioctl() at tunifioctl+0xdc/frame 0xfffffe0065254840 > ifhwioctl() at ifhwioctl+0x2b1/frame 0xfffffe00652548c0 > ifioctl() at ifioctl+0x395/frame 0xfffffe0065254990 > kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0065254a00 > sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0065254ad0 > amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0065254bf0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0065254bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp = > 0x7fffffffd428, rbp = 0x7fffffffdc50 --- > KDB: enter: panic > [ thread pid 61418 tid 100573 ] > Stopped at kdb_enter+0x37: movq $0,0x10b70b6(%rip) > > > ------------------------------ > > Message: 5 > Date: Thu, 20 Aug 2020 16:41:59 -0500 > From: Clay Daniels > To: "freebsd-current@freebsd.org" > Subject: Weekly Current 13.0 Snapshot? > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > Current with new goodies. I don't see it at it's usual location: > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > > Clay > > > ------------------------------ > > Message: 6 > Date: Thu, 20 Aug 2020 21:47:06 +0000 > From: Glen Barber > To: Clay Daniels > Cc: "freebsd-current@freebsd.org" > Subject: Re: Weekly Current 13.0 Snapshot? > Message-ID: <20200820214706.GK61041@FreeBSD.org> > Content-Type: text/plain; charset="us-ascii" > > On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > > Current with new goodies. I don't see it at it's usual location: > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > > Not ill, but indeed sick of the build being broken so much. > > https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.htm > l > > Glen > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: > dfc32d/attachment-0001.sig> > > ------------------------------ > > Message: 7 > Date: Thu, 20 Aug 2020 15:54:37 -0600 > From: Warner Losh > To: Glen Barber > Cc: Clay Daniels , > "freebsd-current@freebsd.org" > Subject: Re: Weekly Current 13.0 Snapshot? > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > > On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > > > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > > > Current with new goodies. I don't see it at it's usual location: > > > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > > > > Not ill, but indeed sick of the build being broken so much. > > > > > > https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.h > > tml > Build isn't broken now, can't you just run it again? > > Warner > > > ------------------------------ > > Message: 8 > Date: Thu, 20 Aug 2020 18:38:58 -0400 > From: Glen Barber > To: Warner Losh > Cc: Clay Daniels , > "freebsd-current@freebsd.org" > Subject: Re: Weekly Current 13.0 Snapshot? > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Not without putting a wedge in place with updating scripts for the git > conversion, which as you know, I am already past the deadline. > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. > > > On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: > > > > ? > > > >> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > >> > >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > >> > Current with new goodies. I don't see it at it's usual location: > >> > > >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > >> > >> Not ill, but indeed sick of the build being broken so much. > >> > >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739. > >> html> > > Build isn't broken now, can't you just run it again? > > > > Warner > > ------------------------------ > > Message: 9 > Date: Thu, 20 Aug 2020 18:43:19 -0500 > From: Clay Daniels > To: Glen Barber > Cc: Warner Losh , "freebsd-current@freebsd.org" > > Subject: Re: Weekly Current 13.0 Snapshot? > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Sorry to bug you. I didn't even know about the snapshot email list, but I > have just subscribed and will know next time. Do what you need to and don't > worry about the snapshot this week. I too am busy this week and have plenty > to do. > > Clay > > On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: > > Not without putting a wedge in place with updating scripts for the git > > conversion, which as you know, I am already past the deadline. > > > > Glen > > Sent from my phone. > > Please excuse my brevity and/or typos. > > > > On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: > > > > ? > > > > On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > >> > Current with new goodies. I don't see it at it's usual location: > >> > > >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ > >> > >> Not ill, but indeed sick of the build being broken so much. > >> > >> > >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739. > >> html> > > Build isn't broken now, can't you just run it again? > > > > Warner > > ------------------------------ > > Message: 10 > Date: Thu, 20 Aug 2020 19:48:23 -0400 > From: Glen Barber > To: Clay Daniels > Cc: Warner Losh , "freebsd-current@freebsd.org" > > Subject: Re: Weekly Current 13.0 Snapshot? > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Not bugging at all. > > I?m hoping that the state that machine is in now, with some sanding off some > newly-discovered rough edges of some code changes, to have snapshots from > git before Wednesday. > > Fingers crossed.... > > Glen > Sent from my phone. > Please excuse my brevity and/or typos. > > > On Aug 20, 2020, at 7:43 PM, Clay Daniels > > wrote: > > > > ? > > Sorry to bug you. I didn't even know about the snapshot email list, but I > > have just subscribed and will know next time. Do what you need to and > > don't worry about the snapshot this week. I too am busy this week and > > have plenty to do. > > > > Clay > > > >> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: > >> Not without putting a wedge in place with updating scripts for the git > >> conversion, which as you know, I am already past the deadline. > >> > >> Glen > >> Sent from my phone. > >> Please excuse my brevity and/or typos. > >> > >>>> On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: > >>> ? > >>> > >>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: > >>>> > >>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: > >>>> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0 > >>>> > Current with new goodies. I don't see it at it's usual location: > >>>> > > >>>> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13. > >>>> > 0/ > >>>> > >>>> Not ill, but indeed sick of the build being broken so much. > >>>> > >>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/00073 > >>>> 9.html>>> > >>> Build isn't broken now, can't you just run it again? > >>> > >>> Warner > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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" > > > ------------------------------ > > End of freebsd-current Digest, Vol 877, Issue 6 > *********************************************** From owner-freebsd-current@freebsd.org Fri Aug 21 18:52:31 2020 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 55BF13C5E3E for ; Fri, 21 Aug 2020 18:52:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BY9cZ4HXFz4Lyt for ; Fri, 21 Aug 2020 18:52:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: m2NweIUVM1l3iplc_QmD7rNw5kH72tPWpCG.DqIQ_IRcfNKuj4y2WQmEQZDfF3G 84fZ1DlzCHGWrU6oe5u21My2pI4gSQvNEWiPfmmqQfQgOiBJ.dtVNHVAS7kWcJ0G2OG8Ntbihb7o mAUi8xDlZDio2uqO7uoEiE7Uc99QmSb.__Uyzwd_T1PmQo89LTZ_L7NeUwT2OQsL8b2xbC25mxw9 f11bZ42YxFm0JmmJiz5Tj8iLnZOrwrDFvVWqct9S6XQArBEswsLrXK87VZanafQYIOXad0Us0hHr zH7527M1PqC1jRbf6rZGtLOP0qlQkzRz1PoVzhNObizieQRM1YQjRraUo6v8o42h34WAImJVHseE W.W2Z4ZVhy0WsHvJr3Zx02fSxtaVvmvPqZiRTBExjR.AhH8JJPjn4L68mBx0Rfybf9OxJ9wPrQkY vYpqyhETvi5IozptupVXl6eHyoC5sCHyxs_bPKjRhc9FTxmKBt92HgzqwlFR7hzDDyRMh_T7KFkO kzzV8oyPnAGXioNRRGsaHE_p4MxOW5GcgFWuKDcATMW3gEo4fNxBWgRQTXeCOvvPyBe6lmBFGUiJ re7_GPBWG5PqkSjqPwBVMJCWZmvka5ySu2B5_8AHDAsYxp1IXogH.562a.L2Gxa4VIr0cOqG2xLr Cf.8IzBP1ZJl1Dm6fPYrdLfbWbLgQahkHhJ2yZv4H3XeRAO1FpzZQkGXpn11y_ezwhqlL1YLG0eL uiKnTq0ORwWAO4qWJvYOKO7DO3Az838JStd3RoOmssTNL9Zq40JegMIRY1emmB6SiHoSywWunhcZ QsUNisajJe6TA_yHiyOKqQIb4nUTH.YjALPEOo9LjQV58VCnD6xPjNIsbbLYyOfB8Qpm5FhDWjRI ABySX6hWy9acwcvwF6vV2E.9JrPM5Sf9hnuU1w5s70RRP3KTdVWlQkmfxIdMiW_eOeflxRlm3AVS kJp6I_pNn6zu1bRbQVjzAdJYkZDi4D7NYQVIP_2dQOR9yq5gy7VAmiIZT9xz55Gbrs6BgzpXTJ1t AZ63WiqqCkBQqJyL7FKC2rNBoMaqjlwHwcyHzMBc49phvpFMSIhfbw2HajcoplCwJEx.oYzcb.0S UlChLO_vR4NBB00lnabFQDTVc6h9S6GdzAWz0Cm3xnUfPpzDPr6dmT.FLb9EIxPAbTkSnO8RtpKP uAdo0t9Bf0bytxiFF8jKYyQAQEueaZHK_e9dFxPFScS5TeeGO_a.o4SkYZCq8tegQqdnDECuBh_j 2yBK.kQnt_zEjhmm4Fa83EWJFdvnJDuEAeCUSsJbxA91iLULhQ48lwKG5XCXecIMFa7XTel1WaJ0 7go01cHLZjBieulKlzOH2IhxvaSF6uOsOKShsH3bmvzzeJ1wLmrpflY0yc78Gp4X_OWTLe09WEPr Pf1sIkMEmwjYJXFck1UvKG9prrwbpp7ENb2nET8GiYI9yLu8wj7rL9js_0loZYJ8KixxCfkxQ1EY JnmzgqjqxcERWYC_FFznoKyfB9PSL.JNdyTzT9a.n_umoi7oWjtys7BVV7tl2hbrmJ2Ad_UNy4At u1g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Aug 2020 18:52:29 +0000 Received: by smtp405.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 041dde3f83bda0f19f2ce808289ca7c9; Fri, 21 Aug 2020 18:52:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default? Message-Id: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> Date: Fri, 21 Aug 2020 11:52:23 -0700 Cc: freebsd-arm To: FreeBSD Current , FreeBSD Toolchain X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF.ref@yahoo.com> X-Rspamd-Queue-Id: 4BY9cZ4HXFz4Lyt X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.41)[-0.407]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.01)[-1.012]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Fri, 21 Aug 2020 18:52:31 -0000 My context: head ( currently at -r363590 ) man src.conf is explicit that WITHOUT_OPENMP is the default for aarch64 (for example). But I note that https://openmp.llvm.org/README.txt says: (it has the more detailed breakdown of OS/compiler combinations for architectures where it matters) QUOTE Architectures Supported ======================= * IA-32 architecture * Intel(R) 64 architecture * Intel(R) Many Integrated Core Architecture * ARM* architecture * Aarch64 (64-bit ARM) architecture * IBM(R) Power architecture (big endian) * IBM(R) Power architecture (little endian) * MIPS and MIPS64 architectures * RISC-V 64 bit architecture Supported RTL Build Configurations ================================== Supported Architectures: IA-32 architecture, Intel(R) 64, and Intel(R) Many Integrated Core Architecture ---------------------------------------------- | icc/icl | gcc | clang | --------------|---------------|----------------------------| | Linux* OS | Yes(1,5) | Yes(2,4) | Yes(4,6,7) | | FreeBSD* | No | No | Yes(4,6,7,8) | | OS X* | Yes(1,3,4) | No | Yes(4,6,7) | | Windows* OS | Yes(1,4) | No | No | ------------------------------------------------------------ . . . (7) Clang* currently does not offer a software-implemented 128 bit extended precision type. Thus, all entry points reliant on this type are removed from the library and cannot be called in the user program. The following functions are not available: __kmpc_atomic_cmplx16_* __kmpc_atomic_float16_* __kmpc_atomic_*_fp . . . Supported Architectures: IBM(R) Power 7 and Power 8 ----------------------------- | gcc | clang | --------------|------------|--------------| | Linux* OS | Yes(1,2) | Yes(3,4) | ------------------------------------------- . . . ENDQUOTE Nothing stands out for why WITH_OPENMP is in use by default only for amd64, i386, and powerpc64. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri Aug 21 21:19:05 2020 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 303F83C8EBE; Fri, 21 Aug 2020 21:19:05 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BYDsj0VL8z4V8M; Fri, 21 Aug 2020 21:19:05 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 06BAA3A1B; Fri, 21 Aug 2020 21:19:05 +0000 (UTC) Date: Fri, 21 Aug 2020 21:19:04 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-08-16 Message-ID: <20200821211904.GA21926@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1598044745; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=TE+DxKYSc+3gCSplNcUkwGsDTXJ05EKLVP3SzY2wvrQ=; b=lMlfyGMoWSOTyI3QyC3XSbnBHhRAKI/8WaKig1NcYxzfk1fdLIyekDA1LKW3waD/adOeVd MVfXJsqkT2OkYkW3MjFTZrSz5ExoOQ8F71xLEYm4ZKKYEAB7QHv6x7r5iHNcqiGW/bRa4I msbQbED+rJyFcRiHJ1beT5avnQFJDqR7Tx5/cejnDNSkhGZHPuKkejsZN7jk7wzyG9m1DJ amhC4VVzm6zW+pFJRS/Y7W11gkMMUIFskq77cqU3145dTfiXhreJZaMERPslBeynSIO4rx mMYhIlBdMT27R14q/wSLBbe/dF0TEkWvg9hIwAcfcn5Mr0wj7Z5z+jwBSvSGYA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1598044745; a=rsa-sha256; cv=none; b=iskPnar7nC+lUqpzAvpzflrDLlwiiDR3LQ23V50yrKcj1hoFvEf3qAyR/Z2U0aMkTbWVJS u3yfdkSBISnz3IxkP1NUBaK5mB78oOen1sjyqucoi1M6kIPKcN56LjnHmYZQF0OFJK8ATl pKN7uccHYPbWYQ46vlUZM/4uCFntyKYsoBhO24GVmGOSH+zr6Neg2IhKB56ERjouytrN9/ FWt5VhDdWSBa3JhhePsK3vLEl8Fdd+ez6myVHpAKIZEZkFLHbiAt5TjqDMx+0XOjjVjJkC YjN/m7ml0EpZJa1B5gdbN3/k0XDVWpUtddKV05opdhggk9CQvB/zJOLr1WQI/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Fri, 21 Aug 2020 21:19:05 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-08-16 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-08-10 to 2020-08-16. During this period, we have: * 2008 builds (93.7% (-0.3) passed, 6.3% (+0.3) 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. * 229 test runs (87.8% (-8.6) passed, 11.8% (+8.7) unstable, 0.4% (-0.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 100 doc and www builds (100% (+0) passed) Test case status (on 2020-08-16 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ---------- | --------- | -------- | ------- | | head/amd64 | 7894 (+20) | 7786 (+2) | 18 (+18) | 90 (0) | | head/i386 | 7892 (+20) | 7777 (+5) | 18 (+18) | 97 (-3) | | 12-STABLE/amd64 | 7620 (0) | 7563 (+3) | 0 (0) | 57 (-3) | | 12-STABLE/i386 | 7618 (0) | 7550 (0) | 0 (0) | 68 (0) | | 11-STABLE/amd64 | 6912 (0) | 6858 (-3) | 0 (0) | 54 (+3) | | 11-STABLE/i386 | 6910 (0) | 6854 (0) | 0 (0) | 56 (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-20200816 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ There are still mutiple errors when building with gcc6, error log available at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 Needs to check if llvm11 import fixes this. * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , needs more verification. ## 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 ~13 failing and ~109 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 * Work on running these tests over OpenZFS is in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 647 failures, 825 skipped ## 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 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 * 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 lib.libcasper.services.cap_net.net_test.* 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/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 ## Issues ### Cause build fails * 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 ### Open * 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/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 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Fri Aug 21 21:24:00 2020 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 58F9D3C9B04 for ; Fri, 21 Aug 2020 21:24:00 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYDzH0nJ2z4Wwb for ; Fri, 21 Aug 2020 21:23:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 070CA2602CF; Fri, 21 Aug 2020 23:23:44 +0200 (CEST) Subject: Re: Kernel crash during video transcoding To: Alexandre Levy Cc: freebsd-current@freebsd.org References: <13793020-1bde-b13f-65e3-909e27d876ad@selasky.org> <4e9d9a89-4883-1f1c-c796-e5925fd171cc@selasky.org> <51a2fe4f-5a3e-8d24-19e2-3cdaa8378015@selasky.org> <5fe820c0-69af-8c41-69d6-a3c33ed55e2e@selasky.org> From: Hans Petter Selasky Message-ID: <0ccb28fe-569d-2abb-f94b-f33d6155a9e8@selasky.org> Date: Fri, 21 Aug 2020 23:23:19 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BYDzH0nJ2z4Wwb X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Fri, 21 Aug 2020 21:24:00 -0000 On 2020-08-16 22:23, Alexandre Levy wrote: > Any suggestions ? Are there any simple steps to reproduce this? --HPS From owner-freebsd-current@freebsd.org Sat Aug 22 09:08:05 2020 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 2A76E3B350B; Sat, 22 Aug 2020 09:08:05 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYXbl5Kphz4MZK; Sat, 22 Aug 2020 09:08:03 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Sat, 22 Aug 2020 09:07:55 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Mark Millard , FreeBSD Current , FreeBSD Toolchain CC: freebsd-arm Subject: Re: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default? In-Reply-To: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> References: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF.ref@yahoo.com> <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> Message-ID: <90091F80-717F-4405-952B-B6B955AE6E1F@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.90 X-Rspamd-Queue-Id: 4BYXbl5Kphz4MZK X-Spamd-Bar: / X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.48)[-0.480]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current,freebsd-toolchain] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 09:08:05 -0000 On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm wrote: >My context: head ( currently at -r363590 ) > >man src=2Econf is explicit that WITHOUT_OPENMP is the default for >aarch64 (for example)=2E [=2E=2E=2E] >Nothing stands out for why WITH_OPENMP is in use by default only >for amd64, i386, and powerpc64=2E Because nobody has bothered to merge https://reviews=2Efreebsd=2Eorg/D2116= 7 From owner-freebsd-current@freebsd.org Sat Aug 22 11:49:46 2020 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 6FBB73B77ED for ; Sat, 22 Aug 2020 11:49:46 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYcBK0gQQz4W7d for ; Sat, 22 Aug 2020 11:49:44 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DF6D460C22 for ; Sat, 22 Aug 2020 11:49:36 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Sat, 22 Aug 2020 11:49:34 +0000 From: marco To: freebsd-current Subject: 13-CURRENT won't boot after switch to sysutils/openzfs Message-ID: <20200822114934.GB40844@lordsith.net> Reply-To: marco Mail-Followup-To: marco , freebsd-current MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-Virus-Scanned: clamav-milter 0.102.4 at c03mi01 X-Virus-Status: Clean X-Uptime: 11:28AM up 6 days, 14:36, 1 user, load averages: 0.49, 0.64, 0.64 X-Rspamd-Queue-Id: 4BYcBK0gQQz4W7d X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.84 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[lordsith.net]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.44)[-0.436]; R_SPF_ALLOW(-0.20)[+a]; SIGNED_PGP(-2.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 11:49:46 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm running r364030. [~] uname -apKU FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue Aug 11 07:15:59 UTC 2020 root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 amd64 1300105 1300105 When switching from base ZFS to sysutils/openzfs 2020080800 the boot proces= s fails. These are the steps I took: - bectl create r364030-OpenZFS - bectl mount r364030-OpenZFS /mnt - edit /mnt/boot/loader.conf to use openzfs_load=3D"YES" instead of zfs_loa= d. - bectl activate r364030-OpenZFS - bectl umount r364030-OpenZFS - shutdown -r now The boot process shows: Loader variables: vfs.root.mountfrom=3Dzfs:zroot/ROOT/r364030-OpenZFS But in the end never boots and drops me to the mountroot prompt I've tried several options to make it boot but when I just enter (empty line) I get the following: panic: mountroot: unable to (re-)mount root pls see https://bsd.to/C4yL --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSgJdiqrBvS/DgNT8GOoAuohYDmywUCX0EGSwAKCRCOoAuohYDm y+YCAJ4gX7A7fx1lg8ck+ya7p+ocfMTlWQCfR5U83DLIkBggmJ4STUCi7D1SIqY= =m0br -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-current@freebsd.org Sat Aug 22 13:29:41 2020 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 8D4E53BAD92 for ; Sat, 22 Aug 2020 13:29:41 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYfPc6xz9z4c3G for ; Sat, 22 Aug 2020 13:29:40 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MBP.attlocal.net (unknown [IPv6:2600:1700:358a:c660:b9be:3040:c283:345d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 64DF815A02 for ; Sat, 22 Aug 2020 13:29:40 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs To: freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> From: Ryan Moeller Message-ID: Date: Sat, 22 Aug 2020 09:29:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200822114934.GB40844@lordsith.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 13:29:42 -0000 On 8/22/20 7:49 AM, marco wrote: > I'm running r364030. > > [~] uname -apKU > FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue Aug > 11 07:15:59 UTC 2020 > root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 > amd64 1300105 1300105 > > When switching from base ZFS to sysutils/openzfs 2020080800 the boot process fails. The most recent version (2020081800) fixes this. -Ryan > These are the steps I took: > > - bectl create r364030-OpenZFS > - bectl mount r364030-OpenZFS /mnt > - edit /mnt/boot/loader.conf to use openzfs_load="YES" instead of zfs_load. > - bectl activate r364030-OpenZFS > - bectl umount r364030-OpenZFS > - shutdown -r now > > The boot process shows: > Loader variables: > vfs.root.mountfrom=zfs:zroot/ROOT/r364030-OpenZFS > > But in the end never boots and drops me to the mountroot prompt > I've tried several options to make it boot but when I just enter (empty > line) I get the following: > > panic: mountroot: unable to (re-)mount root > > pls see https://bsd.to/C4yL > From owner-freebsd-current@freebsd.org Sat Aug 22 13:47:49 2020 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 D591A3BB86D for ; Sat, 22 Aug 2020 13:47:49 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYfpY5K6cz4dXZ for ; Sat, 22 Aug 2020 13:47:49 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MBP.attlocal.net (unknown [IPv6:2600:1700:358a:c660:30a2:5ed0:7c41:3bda]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8271C15BD1 for ; Sat, 22 Aug 2020 13:47:49 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs To: freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> From: Ryan Moeller Message-ID: Date: Sat, 22 Aug 2020 09:47:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 13:47:49 -0000 On 8/22/20 9:29 AM, Ryan Moeller wrote: > > On 8/22/20 7:49 AM, marco wrote: >> I'm running r364030. >> >>   [~] uname -apKU >>   FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue >> Aug >>   11 07:15:59 UTC 2020 >> root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 >>   amd64 1300105 1300105 >> >> When switching from base ZFS to sysutils/openzfs 2020080800 the boot >> process fails. > > The most recent version (2020081800) fixes this. > > -Ryan > Sorry, pre-coffee. I don't think the issue I had in mind there (OpenZFS uses /etc/zfs/zpool.cache instead of /boot/zfs/zpool.cache, we added a fallback) explains your problem. Did you install openzfs from the pkg repo? -Ryan >> These are the steps I took: >> >> - bectl create r364030-OpenZFS >> - bectl mount r364030-OpenZFS /mnt >> - edit /mnt/boot/loader.conf to use openzfs_load="YES" instead of >> zfs_load. >> - bectl activate r364030-OpenZFS >> - bectl umount r364030-OpenZFS >> - shutdown -r now >> >> The boot process shows: >> Loader variables: >> vfs.root.mountfrom=zfs:zroot/ROOT/r364030-OpenZFS >> >> But in the end never boots and drops me to the mountroot prompt >> I've tried several options to make it boot but when I just enter (empty >> line) I get the following: >> >> panic: mountroot: unable to (re-)mount root >> >> pls see https://bsd.to/C4yL >> > _______________________________________________ > 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 Sat Aug 22 16:27:48 2020 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 A81703BFDCE for ; Sat, 22 Aug 2020 16:27:48 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYkM765gwz4pKb for ; Sat, 22 Aug 2020 16:27:47 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id CB0AE6060F for ; Sat, 22 Aug 2020 16:27:45 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Sat, 22 Aug 2020 16:27:43 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs Message-ID: <20200822162743.GA64297@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-Virus-Scanned: clamav-milter 0.102.4 at c03mi01 X-Virus-Status: Clean X-Uptime: 3:48PM up 6 days, 18:56, 1 user, load averages: 0.28, 0.25, 0.33 X-Rspamd-Queue-Id: 4BYkM765gwz4pKb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.34 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lordsith.net]; NEURAL_HAM_SHORT(-0.94)[-0.942]; SIGNED_PGP(-2.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 16:27:48 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 22, 2020 at 09:47:49AM -0400, you (Ryan Moeller) sent the follo= wing to [freebsd-current] : >=20 > On 8/22/20 9:29 AM, Ryan Moeller wrote: > >> > >> When switching from base ZFS to sysutils/openzfs 2020080800 the boot= =20 > >> process fails. > > > > The most recent version (2020081800) fixes this. > > > > -Ryan > > > Sorry, pre-coffee. I don't think the issue I had in mind there (OpenZFS= =20 > uses /etc/zfs/zpool.cache instead of /boot/zfs/zpool.cache, we added a=20 > fallback) explains your problem. >=20 > Did you install openzfs from the pkg repo? I installed openzfs from the latest FreeBSD repo (pkg+http://pkg.FreeBSD.org/${ABI}/latest) current BEs [~] bectl list -aDs BE/Dataset/Snapshot Active Mountpoint Space Created r364030 zroot/ROOT/r364030 NR / 15.2G 2020-0= 8-11 08:25 r364030@2020-08-22-15:52:19-0 - - 31.4M 2020-0= 8-22 15:52 r364030-OpenZFS zroot/ROOT/r364030-OpenZFS - /mnt 419M 2020-0= 8-22 15:52 zroot/ROOT/r364030@2020-08-22-15:52:19-0 - - 31.4M 2020-0= 8-22 15:52 Just did a 'pkg update' on my active BE. I don't know what is happening here, can't seem to upgrade openzfs: [~] pkg version | grep openzfs openzfs-2020080800 < openzfs-kmod-2020080800 < So there should be an update for sysutils/openzfs and openzfs-kmod but runn= ing a 'pkg upgrade' doesn't list openzfs for an upgrade. After creating and mounting the new BE I've also tried: [~] d bectl mount r364030-OpenZFS /mnt [~] d pkg -r /mnt update -f [~] d pkg -r /mnt upgrade Openzfs isn't listed for an upgrade. After the pkg upgrade, running pkg version claims : [~] pkg -r /mnt version | grep openzfs openzfs-2020080800 =3D openzfs-kmod-2020080800 =3D [~] d pkg -r /mnt upgrade -f openzfs [~] d pkg -r /mnt upgrade -f openzfs Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 1 package(s) will be affected (of 0 checked): Installed packages to be REINSTALLED: openzfs-2020080800 Number of packages to be reinstalled: 1 2 MiB to be downloaded. Proceed with this action? [y/N]: So besides not being able to boot from the openzfs 2020080800 package insta= ll, I can't figure out why I can't upgrade the openzfs pkg to 2020081800 (w= hich is the latest one in ports so I presume a package also exists of that = same version) --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSgJdiqrBvS/DgNT8GOoAuohYDmywUCX0FHfAAKCRCOoAuohYDm y5e7AJ4zkZNPJxcWq87/zocS39bixPzW5gCgopgVYElymVDqqCywjn1GWzue9MY= =NQ29 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@freebsd.org Sat Aug 22 16:31:25 2020 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 A836B3BFFC9 for ; Sat, 22 Aug 2020 16:31:25 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYkRK42Kxz4pfn for ; Sat, 22 Aug 2020 16:31:25 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MBP.attlocal.net (unknown [IPv6:2600:1700:358a:c660:30a2:5ed0:7c41:3bda]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5D02316C22 for ; Sat, 22 Aug 2020 16:31:25 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs To: freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> <20200822162743.GA64297@freedom.nl> From: Ryan Moeller Message-ID: Date: Sat, 22 Aug 2020 12:31:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200822162743.GA64297@freedom.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 16:31:25 -0000 On 8/22/20 12:27 PM, marco wrote: > On Sat, Aug 22, 2020 at 09:47:49AM -0400, you (Ryan Moeller) sent the following to [freebsd-current] : >> On 8/22/20 9:29 AM, Ryan Moeller wrote: >>>> When switching from base ZFS to sysutils/openzfs 2020080800 the boot >>>> process fails. >>> The most recent version (2020081800) fixes this. >>> >>> -Ryan >>> >> Sorry, pre-coffee. I don't think the issue I had in mind there (OpenZFS >> uses /etc/zfs/zpool.cache instead of /boot/zfs/zpool.cache, we added a >> fallback) explains your problem. >> >> Did you install openzfs from the pkg repo? > I installed openzfs from the latest FreeBSD repo > (pkg+http://pkg.FreeBSD.org/${ABI}/latest) > > current BEs > > [~] bectl list -aDs > BE/Dataset/Snapshot Active Mountpoint Space Created > > r364030 > zroot/ROOT/r364030 NR / 15.2G 2020-08-11 08:25 > r364030@2020-08-22-15:52:19-0 - - 31.4M 2020-08-22 15:52 > > r364030-OpenZFS > zroot/ROOT/r364030-OpenZFS - /mnt 419M 2020-08-22 15:52 > zroot/ROOT/r364030@2020-08-22-15:52:19-0 - - 31.4M 2020-08-22 15:52 > > Just did a 'pkg update' on my active BE. > I don't know what is happening here, can't seem to upgrade openzfs: > > [~] pkg version | grep openzfs > openzfs-2020080800 < > openzfs-kmod-2020080800 < > > So there should be an update for sysutils/openzfs and openzfs-kmod but running a 'pkg upgrade' doesn't list openzfs for an upgrade. > > After creating and mounting the new BE I've also tried: > > [~] d bectl mount r364030-OpenZFS /mnt > [~] d pkg -r /mnt update -f > [~] d pkg -r /mnt upgrade > > Openzfs isn't listed for an upgrade. > After the pkg upgrade, running pkg version claims : > > [~] pkg -r /mnt version | grep openzfs > openzfs-2020080800 = > openzfs-kmod-2020080800 = > > [~] d pkg -r /mnt upgrade -f openzfs > [~] d pkg -r /mnt upgrade -f openzfs > Updating FreeBSD repository catalogue... > FreeBSD repository is up to date. > All repositories are up to date. > The following 1 package(s) will be affected (of 0 checked): > > Installed packages to be REINSTALLED: > openzfs-2020080800 > > Number of packages to be reinstalled: 1 > > 2 MiB to be downloaded. > > Proceed with this action? [y/N]: > > So besides not being able to boot from the openzfs 2020080800 package install, I can't figure out why I can't upgrade the openzfs pkg to 2020081800 (which is the latest one in ports so I presume a package also exists of that same version) Ok the pkg repo may not be updated with the new version yet, the latest I see is still 08. I think the problem though is you aren't using the GENERIC kernel, so the module from the pkg repo is failing to load at boot. You should build the module from ports instead, or use the GENERIC kernel. Let me know if that works for you! -Ryan From owner-freebsd-current@freebsd.org Sat Aug 22 16:48:53 2020 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 7896B3C089F for ; Sat, 22 Aug 2020 16:48:53 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYkqS1YXWz4qdt for ; Sat, 22 Aug 2020 16:48:51 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id E0FCF60897 for ; Sat, 22 Aug 2020 16:48:49 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Sat, 22 Aug 2020 16:48:48 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs Message-ID: <20200822164848.GA71156@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> <20200822162743.GA64297@freedom.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-Virus-Scanned: clamav-milter 0.102.4 at c03mi01 X-Virus-Status: Clean X-Uptime: 4:32PM up 6 days, 19:39, 1 user, load averages: 0.57, 0.42, 0.30 X-Rspamd-Queue-Id: 4BYkqS1YXWz4qdt X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.65 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[116.202.65.215:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:116.202.65.208/28]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lordsith.net]; NEURAL_HAM_SHORT(-1.15)[-1.154]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[116.202.65.215:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 16:48:53 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 22, 2020 at 12:31:24PM -0400, you (Ryan Moeller) sent the follo= wing to [freebsd-current] : >=20 > > So besides not being able to boot from the openzfs 2020080800 package i= nstall, I can't figure out why I can't upgrade the openzfs pkg to 202008180= 0 (which is the latest one in ports so I presume a package also exists of t= hat same version) >=20 >=20 > Ok the pkg repo may not be updated with the new version yet, the latest= =20 > I see is still 08. I think the problem though is you aren't using the=20 > GENERIC kernel, so the module from the pkg repo is failing to load at=20 > boot. You should build the module from ports instead, or use the GENERIC= =20 > kernel. Let me know if that works for you! Okay, currently running a buildkernel which I'll install into r364030-OpenZFS. I'm running GENERIC-NODEBUG to see if I can squeeze a bit more performnce out of this ThinkPad X230 But I'll build and install GENERIC into the new BE to see if that'll make a= difference. These will be my steps: cd /usr/src (currently at r364030) make -DMALLOC_PRODUCTION -j4 buildkernel bectl mount r364030-OpenZFS /mnt set openzfs_load=3D"YES" in /mnt/boot/loader.conf and comment out zfs_load = for Base ZFS make -DMALLOC_PRODUCTION -j4 installkernel DESTDIR=3D/mnt mergemaster -Fp -D /mnt /* don't think is needed since I haven't buildworld= from updated sources beyond r364030 mergemaster -Fi -D /mnt /* don't think is needed since I haven't buildworld= from updated sources beyond r364030 make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=3D/mnt bectl umount r364030-OpenZFS bectl activate r364030-OpenZFS shutdown -r now If that won't work either I'll see if I can build sysutils/openzfs from por= ts but I'd rather not mix packages and ports. --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSgJdiqrBvS/DgNT8GOoAuohYDmywUCX0FMbQAKCRCOoAuohYDm y7JKAJ4oX1q0pu57bm3Gd12dgNk5Dff9tgCeKz1xV/XWOchchC5LDFgSzscDPCQ= =CrlA -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@freebsd.org Sat Aug 22 22:10:22 2020 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 40B4B3C6A76 for ; Sat, 22 Aug 2020 22:10:22 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYsyP0MBtz3d0R for ; Sat, 22 Aug 2020 22:10:20 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 1D06260274 for ; Sat, 22 Aug 2020 22:10:18 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Sat, 22 Aug 2020 22:10:14 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs Message-ID: <20200822221014.GA1744@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> <20200822162743.GA64297@freedom.nl> <20200822164848.GA71156@freedom.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20200822164848.GA71156@freedom.nl> Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-Virus-Scanned: clamav-milter 0.102.4 at c03mi01 X-Virus-Status: Clean X-Uptime: 10:06PM up 2 mins, 1 user, load averages: 0.12, 0.05, 0.01 X-Rspamd-Queue-Id: 4BYsyP0MBtz3d0R X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.90 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[lordsith.net]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.504]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 22:10:22 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 22, 2020 at 04:48:48PM +0000, you (marco) sent the following to= [freebsd-current] : > On Sat, Aug 22, 2020 at 12:31:24PM -0400, you (Ryan Moeller) sent the fol= lowing to [freebsd-current] : > > > > > So besides not being able to boot f= rom the openzfs 2020080800 package install, I can't figure out why I can't = upgrade the openzfs pkg to 2020081800 (which is the latest one in ports so = I presume a package also exists of that same version) > >=20 > >=20 > > Ok the pkg repo may not be updated with the new version yet, the latest= =20 > > I see is still 08. I think the problem though is you aren't using the= =20 > > GENERIC kernel, so the module from the pkg repo is failing to load at= =20 > > boot. You should build the module from ports instead, or use the GENERI= C=20 > > kernel. Let me know if that works for you! >=20 > Okay, currently running a buildkernel which I'll install into > r364030-OpenZFS. > I'm running GENERIC-NODEBUG to see if I can squeeze a bit more > performnce out of this ThinkPad X230 > But I'll build and install GENERIC into the new BE to see if that'll make= a difference. >=20 > These will be my steps: >=20 > cd /usr/src (currently at r364030) > make -DMALLOC_PRODUCTION -j4 buildkernel > bectl mount r364030-OpenZFS /mnt > set openzfs_load=3D"YES" in /mnt/boot/loader.conf and comment out zfs_loa= d for Base ZFS > make -DMALLOC_PRODUCTION -j4 installkernel DESTDIR=3D/mnt > mergemaster -Fp -D /mnt /* don't think is needed since I haven't buildwor= ld from updated sources beyond r364030 > mergemaster -Fi -D /mnt /* don't think is needed since I haven't buildwor= ld from updated sources beyond r364030 > make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=3D/mnt > bectl umount r364030-OpenZFS > bectl activate r364030-OpenZFS > shutdown -r now >=20 > If that won't work either I'll see if I can build sysutils/openzfs from p= orts but I'd rather not mix packages and ports. building and installing the GENERIC kernel did not do anything. I can confirm BE r364030-OpenZFS booted with GENERIC but I got dropped into the mountroot prompt again. Before I got there I saw: Trying to mount root from zfs:zroot/ROOT/r364030-OpenZFS failed with error 2: unknown file system. Guess I'll try to install sysutils/openzfs from ports next. --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSgJdiqrBvS/DgNT8GOoAuohYDmywUCX0GXwwAKCRCOoAuohYDm yzMYAJ9OKQYPM+Yk1+isrdZoDtla/3NzPQCfcLhLbebUHhTaOC5QRVv/31o6Cfw= =om85 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@freebsd.org Sat Aug 22 23:20:55 2020 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 D95B33A8078 for ; Sat, 22 Aug 2020 23:20:55 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4BYvWq1JtQz3xwN for ; Sat, 22 Aug 2020 23:20:54 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: by mail-ed1-x542.google.com with SMTP id f24so2674923edw.10 for ; Sat, 22 Aug 2020 16:20:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8zfo5z/6xZMPmS2aH+MB9QoUO0vO7ulfh+1WvHQJXeg=; b=lS75nbliQgW/8iXzM/2NqlxNeXu1rYbVkvoS3FSU+Oh6wYQMinI/X225N+wQe/1inH 3M73SfMC5KrNs1+d8Q+C15jxbuIZfCRbAFnKqRoaaB0LiUnzxB6Fitvd9p/1gRK+Bxyj NMgi/2XAdwW+V+IJA+uFPA0/RIXLoQUzhAhLcTRG7nY+GvIfcy4CLiwLU5wMAGWlOUjR uvj8vy7hAPT76k9yRTgkMUwWAklsvE+sU9fF0cOAiicwgA/BFEKpPRTXnBw/OczfhJch 4ahQnsYASGm05DJhczUAmyJ147CvPpJzILrI728+aKJzYLsgUZvOKun+fGjjNWGSO5ND 2Dgw== X-Gm-Message-State: AOAM533S9QOLY9JwU7NnPO4FP11gWHzxQYZ2jIQJi8fcD2ibvnWowoSS toId32Z0bpbsL2knlAaeKehamMeSCPUqp0FO X-Google-Smtp-Source: ABdhPJxACWGXNHI3aCa6foafBuMJ0KmlEoF+b7nTPDh9hFzw0t0XGYsQz5jTksBGSj6muTLPciIltw== X-Received: by 2002:a05:6402:45a:: with SMTP id p26mr8867595edw.8.1598138452806; Sat, 22 Aug 2020 16:20:52 -0700 (PDT) Received: from [192.168.8.105] (213162072245.public.t-mobile.at. [213.162.72.245]) by smtp.gmail.com with ESMTPSA id du2sm4364357ejc.2.2020.08.22.16.20.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Aug 2020 16:20:52 -0700 (PDT) Subject: Re: freebsd-current Digest, Vol 877, Issue 7 To: freebsd-current@freebsd.org References: From: "Vanbreukelingen Ltd." Message-ID: <43599bed-8f47-0bb4-348e-9b527a7160dd@gmail.com> Date: Sun, 23 Aug 2020 01:20:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4BYvWq1JtQz3xwN X-Spamd-Bar: - X-Spamd-Result: default: False [-1.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::542:from]; NEURAL_HAM_SHORT(-0.76)[-0.764]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 23:20:55 -0000 replying to myself at 1am: 1. completely new-install 2. kmod-legacy and kmd-stable built 3. svn up; make kernel 4. linux-c7 from /ports installed 5. kld_load x 2 6. fine drm initialized but when trying to sddm or xinit or startx or whatever I get a loooooong debug output message with self reset running over my screen. any help? miranda On 22.08.20 14:00, freebsd-current-request@freebsd.org wrote: > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org > > You can reach the person managing the list at > freebsd-current-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > > Today's Topics: > > 1. Re: freebsd-current Digest, Vol 877, Issue 6 > (Vanbreukelingen Ltd.) > 2. /usr/lib/libomp.so : is there a reason that aarch64 does not > have such by default? (Mark Millard) > 3. FreeBSD CI Weekly Report 2020-08-16 (Li-Wen Hsu) > 4. Re: Kernel crash during video transcoding (Hans Petter Selasky) > 5. Re: /usr/lib/libomp.so : is there a reason that aarch64 does > not have such by default? (myfreeweb) > 6. 13-CURRENT won't boot after switch to sysutils/openzfs (marco) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Aug 2020 19:37:54 +0200 > From: "Vanbreukelingen Ltd." > To: freebsd-current@freebsd.org > Subject: Re: freebsd-current Digest, Vol 877, Issue 6 > Message-ID: <2624761.GQDcWxOStt@alice> > Content-Type: text/plain; charset="us-ascii" > > here we go - when nothing works anymore (kernel panic after a simple 'xinit' > and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics. > > https://pasteboard.co/Jnqgbeq.png > > > > On Friday, August 21, 2020 2:00:00 PM CEST freebsd-current-request@freebsd.org > wrote: > >> Message: 1 >> Date: Thu, 20 Aug 2020 08:15:56 +0200 >> From: "Vanbreukelingen Ltd." >> To: Current FreeBSD >> Subject: Re: funny thing with the drm0 >> Message-ID: <8073347.hK6j7OjjKr@alice> >> Content-Type: text/plain; charset="us-ascii" >> >> On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote: >>> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: >>>> On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < >>>> >>>> lizbethmutterhunt@gmail.com> wrote: >>>>> After having had some near-death-experiences in Greece I'm back to my >>>>> screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) >>>>> >>>>> >>>>> But this is the experience with my Dell Vostro on 13 current: >>>>> >>>>> >>>>> After finally recompiling the kernel with the drm-module inside and >>>>> the trick of injecting the >>>> This is not the way to do it. Modern hardware require drm-kmod from >>>> ports, >>>> or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko >>>> and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf >> wasn't yet finished (c [see] beyond), but I guess I have to disable the >> whole output with something like hw.*=1 or so. is it possible to make a >> bootlogo while VEBOSE output = 2 just for the reason some kids try to play >> with it. >> >>>>> device IWNFW >> doesn't install the 6000, btw --- probably can't find FW on device HAL. >> >>>> Again, this is not needed, firmware is autoloaded on module load. Just >>>> add >>>> if_iwn to kld_list in /etc/rc.conf >> built of 15 hours of NanoBSD while finishing the nightly built someone was >> on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all >> but some reason tells me behind this system in system is something to beat >> beastie in killing KFC forks. ;-) >> >>>>> I get a *nice* message a bootup: >>>>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 >>>>> 20060810 >>>>> Aug 19 02:51:10 current kernel: drmn0: on >>>>> vgapci0 >>>>> Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics >>>>> device = 2048M >>>>> Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. >>>>> Graphics performance may suffer. >>>>> Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus0: on >>>>> iicbb_nostop0 addr 0x1 >>>>> Aug 19 02:51:10 current kernel: iic0: on iicbus0 >>>>> Aug 19 02:51:10 current kernel: iicbus1: on >>>>> intel_gmbus0 >>>>> Aug 19 02:51:10 current kernel: iic1: on iicbus1 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus2: on >>>>> iicbb_nostop1 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic2: on iicbus2 >>>>> Aug 19 02:51:10 current kernel: iicbus3: on >>>>> intel_gmbus1 >>>>> Aug 19 02:51:10 current kernel: iic3: on iicbus3 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus4: on >>>>> iicbb_nostop2 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic4: on iicbus4 >>>>> Aug 19 02:51:10 current kernel: iicbus5: on >>>>> intel_gmbus2 >>>>> Aug 19 02:51:10 current kernel: iic5: on iicbus5 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus6: on >>>>> iicbb_nostop3 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic6: on iicbus6 >>>>> Aug 19 02:51:10 current kernel: iicbus7: on >>>>> intel_gmbus3 >>>>> Aug 19 02:51:10 current kernel: iic7: on iicbus7 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus8: on >>>>> iicbb_nostop4 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic8: on iicbus8 >>>>> Aug 19 02:51:10 current kernel: iicbus9: on >>>>> intel_gmbus4 >>>>> Aug 19 02:51:10 current kernel: iic9: on iicbus9 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus10: on >>>>> iicbb_nostop5 addr 0x12 >>>>> >>>>> And furthermore: >>>>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) >>>>> Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp >>>>> caching Rev 1 (10.10.201> >>>>> Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise >>>>> vblank timestamp query. >>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 >>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached >>>>> Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious >>>>> range 0xe0000000-0xf0000000 >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.modes.LVDS-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get >>>>> mode from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.modes.HDMI-A-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: fbd0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked >>>>> and may be deleted before> >>>>> Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new >>>>> "fb". >>>>> ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 >>>>> 20080730 for drmn0 on minor 0 >>>>> >>>>> so far so good, quality of text in grafics 1368x1024 is perfectly >>>>> initialized. but now, when starting xinit or lightdm or sddm or >>>>> whatever I get a kernel panic: >>>>> >>>>> Dump header from device: /dev/ada0p4 >>>>> >>>>> Architecture: i386 >>>>> Architecture Version: 4 >>>>> Dump Length: 97792 >>>>> Blocksize: 512 >>>>> Compression: none >>>>> Dumptime: 2020-08-19 02:49:00 +0200 >>>>> Hostname: current >>>>> Magic: FreeBSD Text Dump >>>>> Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 >>>>> >>>>> CEST 2020 >>>>> >>>>> root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>>>> >>>>> Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive >>>>> >>>>> busy @ /usr/src/sys/vm/vm> >>>>> >>>>> Dump Parity: 2773167169 >>>>> Bounds: 1 >>>>> Dump Status: good >>>>> >>>>> /var/crash/vmcore.0 not found >>>> Do you have dumpdev="AUTO" in /etc/rc.conf ? >> yes and the directory is /var/crash, but this is all I get as lack of >> insufficent memory of dump, it says. >> >>>>> First thing I think is kern options: >>>>> >>>>> options WITNESS_SKIPSPIN >>>>> options WITNESS >>>>> >>>>> I disabled device HYPERV but this can't be the reason, kern is being >>>>> compiled with clang. >>>> Clang is the default since a long time. >> depends on gcc++ development in 4D AIs. >> >>>>> To disable WITNESS would be one way I think but this can't be the >>>>> yellw of the egg, isn't it? >>>> I use the GENERIC-NODEBUG kernel config which disables WITNESS for some >>>> performance improvements. >> yup. we don't need another debugger. killing insects is murder but when >> getting better stuff I never resist to lance them. like housecats with flys. >>>>> Another thing but I guess having nothing to do with bug above is on >>>>> rather the end of startup: >>>>> >>>>> Aug 19 02:51:10 current savecore[1209]: reboot after panic: >>>>> vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ >>>>> /usr/src/sys/vm/vm_page.c:1609 >>>>> Aug 19 02:51:10 current savecore[1209]: writing core to >>>>> /var/crash/textdump.tar.1 >>>>> Aug 19 02:51:10 current kernel: linsysfs: >>>>> Aug 19 02:51:10 current kernel: Device busy >>>>> Aug 19 02:51:10 current kernel: lock order reversal: >>>>> Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ >>>>> /usr/src/sys/kern/vfs_mount.c:1008 >>>>> Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) >>>>> @ /usr/src/sys/kern/vfs_mount.c:1019 >>>>> Aug 19 02:51:10 current kernel: lock order devfs -> ufs established >>>>> at: >>>>> Aug 19 02:51:10 current kernel: #0 0x1027cd5 at >>>>> witness_checkorder+0x3c5 >>>>> Aug 19 02:51:10 current kernel: #1 0xf9cca0 at >>>>> lockmgr_lock_flags+0x140 >>>>> Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 >>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>>>> Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 >>>>> Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 >>>>> Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce >>>>> Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 >>>>> Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 >>>>> Aug 19 02:51:10 current kernel: #12 0xffc0340e at >>>>> __stop_set_sysinit_set+0xd0a4199e >>>>> Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: >>>>> Aug 19 02:51:10 current kernel: #0 0x1028360 at >>>>> witness_checkorder+0xa50 >>>>> Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 >>>>> Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a >>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>>>> Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d >>>>> Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 >>>>> Aug 19 02:51:10 current kernel: #9 0xffc033f9 at >>>>> __stop_set_sysinit_set+0xd0a41989 >>>>> >>>>> any ideas? >>>>> Miranda >>>>> >>>>> >>>>> >>>>> does someone know how to fix it? >>>>> >>>>> Miranda >>>> Hope this helps. >> It does! >> >>>> Best regards >>>> Andreas Nilsson >> Yours, >> Miranda van Breukelingen >> >> >> >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 20 Aug 2020 16:43:56 +0200 >> From: Andreas Nilsson >> To: "Vanbreukelingen Ltd." , Current >> FreeBSD >> Subject: Re: funny thing with the drm0 >> Message-ID: >> VkKAsBQ@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. < >> >> lizbethmutterhunt@gmail.com> wrote: >>> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: >>>> On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < >>>> >>>> lizbethmutterhunt@gmail.com> wrote: >>>>> After having had some near-death-experiences in Greece I'm back to my >>>>> screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-) >>>>> >>>>> >>>>> But this is the experience with my Dell Vostro on 13 current: >>>>> >>>>> >>>>> After finally recompiling the kernel with the drm-module inside and >>>>> the trick of injecting the >>>> This is not the way to do it. Modern hardware require drm-kmod from >>> ports, >>> >>>> or if you want the latest drm-devel-kmod. Then add /boot/modules/drm.ko >>>> and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf >>> wasn't yet finished (c [see] beyond), but I guess I have to disable the >>> whole >>> output with something like hw.*=1 or so. is it possible to make a bootlogo >>> while VEBOSE output = 2 just for the reason some kids try to play with it. >>> >>>>> device IWNFW >>> doesn't install the 6000, btw --- probably can't find FW on device HAL. >>> >>>> Again, this is not needed, firmware is autoloaded on module load. Just >>> add >>> >>>> if_iwn to kld_list in /etc/rc.conf >> Here I admit I was wrong, iwn handles it differently than iwm. The man page >> lists 3 different firmware versions for the 6000 series, which can be >> loaded from loader.conf >> >>> built 15 hours of NanoBSD while finishing the nightly built someone was on >>> Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but >>> some >>> reason tells me behind this system in system is something to beat beastie >>> in >>> killing KFC forks. >>> >>>>> I get a *nice* message a bootup: >>>>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0 >>> 20060810 >>> >>>>> Aug 19 02:51:10 current kernel: drmn0: on >>> vgapci0 >>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics >>>>> device = 2048M >>>>> Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed. >>>>> Graphics performance may suffer. >>>>> Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus0: on >>>>> iicbb_nostop0 addr 0x1 >>>>> Aug 19 02:51:10 current kernel: iic0: on iicbus0 >>>>> Aug 19 02:51:10 current kernel: iicbus1: on >>> intel_gmbus0 >>> >>>>> Aug 19 02:51:10 current kernel: iic1: on iicbus1 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus2: on >>>>> iicbb_nostop1 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic2: on iicbus2 >>>>> Aug 19 02:51:10 current kernel: iicbus3: on >>> intel_gmbus1 >>> >>>>> Aug 19 02:51:10 current kernel: iic3: on iicbus3 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus4: on >>>>> iicbb_nostop2 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic4: on iicbus4 >>>>> Aug 19 02:51:10 current kernel: iicbus5: on >>> intel_gmbus2 >>> >>>>> Aug 19 02:51:10 current kernel: iic5: on iicbus5 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus6: on >>>>> iicbb_nostop3 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic6: on iicbus6 >>>>> Aug 19 02:51:10 current kernel: iicbus7: on >>> intel_gmbus3 >>> >>>>> Aug 19 02:51:10 current kernel: iic7: on iicbus7 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus8: on >>>>> iicbb_nostop4 addr 0x12 >>>>> Aug 19 02:51:10 current kernel: iic8: on iicbus8 >>>>> Aug 19 02:51:10 current kernel: iicbus9: on >>> intel_gmbus4 >>> >>>>> Aug 19 02:51:10 current kernel: iic9: on iicbus9 >>>>> Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 >>>>> Aug 19 02:51:10 current kernel: iicbus10: on >>>>> iicbb_nostop5 addr 0x12 >>>>> >>>>> And furthermore: >>>>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s) >>>>> Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp >>>>> caching Rev 1 (10.10.201> >>>>> Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise >>>>> vblank timestamp query. >>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0 >>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached >>>>> Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious >>>>> range 0xe0000000-0xf0000000 >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.modes.LVDS-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.VGA-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get >>>>> mode from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>> kern.vt.fb.modes.HDMI-A-1 >>> >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode >>>>> from tunables: >>>>> Aug 19 02:51:10 current kernel: info: [drm] - kern.vt.fb.modes.DP-1 >>>>> Aug 19 02:51:10 current kernel: info: [drm] - >>>>> kern.vt.fb.default_mode >>>>> Aug 19 02:51:10 current kernel: fbd0 on drmn0 >>>>> Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked >>>>> and may be deleted before> >>>>> Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new >>> "fb". >>> >>>>> ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 >>>>> 20080730 for drmn0 on minor 0 >>>>> >>>>> so far so good, quality of text in grafics 1368x1024 is perfectly >>>>> initialized. but now, when starting xinit or lightdm or sddm or >>>>> whatever I get a kernel panic: >>>>> >>>>> Dump header from device: /dev/ada0p4 >>>>> >>>>> Architecture: i386 >>>>> Architecture Version: 4 >>>>> Dump Length: 97792 >>>>> Blocksize: 512 >>>>> Compression: none >>>>> Dumptime: 2020-08-19 02:49:00 +0200 >>>>> Hostname: current >>>>> Magic: FreeBSD Text Dump >>>>> Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40 >>>>> >>>>> CEST 2020 >>>>> >>>>> root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>>>> >>>>> Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive >>>>> >>>>> busy @ /usr/src/sys/vm/vm> >>>>> >>>>> Dump Parity: 2773167169 >>>>> Bounds: 1 >>>>> Dump Status: good >>>>> >>>>> /var/crash/vmcore.0 not found >>>> Do you have dumpdev="AUTO" in /etc/rc.conf ? >>> yes and the directory is /var/crash, but this is all I get as lack of >>> insufficent memory of dump, it says. >> Sounds like your swap device is to small. How big is it, and how much >> memory do you have? >> >>>>> First thing I think is kern options: >>>>> >>>>> options WITNESS_SKIPSPIN >>>>> options WITNESS >>>>> >>>>> I disabled device HYPERV but this can't be the reason, kern is being >>>>> compiled with clang. >>>> Clang is the default since a long time. >>> depends on gcc++ development in 4D AIs. >>> >>> Nothing stops you from using gcc for compiling your programs. Clang is >> just the default for the OS. >> >>>>> To disable WITNESS would be one way I think but this can't be the >>>>> yellw of the egg, isn't it? >>>> I use the GENERIC-NODEBUG kernel config which disables WITNESS for some >>>> performance improvements. >>> yup. we don't need another debugger. killing insects is murder but when >>> getting better stuff I never resist to lance them. like housecats with >>> flys. >>> >>>>> Another thing but I guess having nothing to do with bug above is on >>>>> rather the end of startup: >>>>> >>>>> Aug 19 02:51:10 current savecore[1209]: reboot after panic: >>>>> vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ >>>>> /usr/src/sys/vm/vm_page.c:1609 >>>>> Aug 19 02:51:10 current savecore[1209]: writing core to >>>>> /var/crash/textdump.tar.1 >>>>> Aug 19 02:51:10 current kernel: linsysfs: >>>>> Aug 19 02:51:10 current kernel: Device busy >>>>> Aug 19 02:51:10 current kernel: lock order reversal: >>>>> Aug 19 02:51:10 current kernel: 1st 0x3121e870 ufs (ufs, lockmgr) @ >>>>> /usr/src/sys/kern/vfs_mount.c:1008 >>>>> Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) >>>>> @ /usr/src/sys/kern/vfs_mount.c:1019 >>>>> Aug 19 02:51:10 current kernel: lock order devfs -> ufs established >>>>> at: >>>>> Aug 19 02:51:10 current kernel: #0 0x1027cd5 at >>> witness_checkorder+0x3c5 >>> >>>>> Aug 19 02:51:10 current kernel: #1 0xf9cca0 at >>>>> lockmgr_lock_flags+0x140 >>>>> Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 >>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>>>> Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 >>>>> Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 >>>>> Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce >>>>> Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 >>>>> Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 >>>>> Aug 19 02:51:10 current kernel: #12 0xffc0340e at >>>>> __stop_set_sysinit_set+0xd0a4199e >>>>> Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at: >>>>> Aug 19 02:51:10 current kernel: #0 0x1028360 at >>> witness_checkorder+0xa50 >>> >>>>> Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 >>>>> Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a >>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>>>> Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d >>>>> Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 >>>>> Aug 19 02:51:10 current kernel: #9 0xffc033f9 at >>>>> __stop_set_sysinit_set+0xd0a41989 >>>>> >>>>> any ideas? >>>>> Miranda >>>>> >>>>> >>>>> >>>>> does someone know how to fix it? >>>>> >>>>> Miranda >>>> Hope this helps. >>> It does! >>> >>>> Best regards >>>> Andreas Nilsson >>> Yours, >>> Miranda van Breukelingen >>> >>> >>> Best regards >> Andreas Nilsson >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 20 Aug 2020 16:58:25 +0200 >> From: "Vanbreukelingen Ltd." >> To: Andreas Nilsson , freebsd-current@freebsd.org >> Subject: Re: funny thing with the drm0 >> Message-ID: >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> On 2020-08-20 16:43, Andreas Nilsson wrote: >>> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. >>> >>> > wrote: >>> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote: >>> > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D < >>> > >>> > lizbethmutterhunt@gmail.com >>> >>> > wrote: >>> > > After having had some near-death-experiences in Greece I'm >>> >>> back to my >>> >>> > > screens. As horizon arises, BSD gets up --- and if it is 3 >>> >>> a.m.! :-) >>> >>> > > But this is the experience with my Dell Vostro on 13 current: >>> > > >>> > > >>> > > After finally recompiling the kernel with the drm-module >>> >>> inside and >>> >>> > > the trick of injecting the >>> > >>> > This is not the way to do it. Modern hardware require drm-kmod >>> >>> from ports, >>> >>> > or if you want the latest drm-devel-kmod. Then add >>> >>> /boot/modules/drm.ko >>> >>> > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf >>> >>> wasn't yet finished (c [see] beyond), but I guess I have to >>> disable the whole >>> output with something like hw.*=1 or so. is it possible to make a >>> bootlogo >>> while VEBOSE output = 2 just for the reason some kids try to play >>> with it. >> tried it now: next kernel panic on lightdm and sddm makes a mouse in >> mouse pointer over a blank screen. the driver is initialised but hungs >> up like this: >> >> Dump header from device: /dev/ada0p4 >> ? Architecture: i386 >> ? Architecture Version: 4 >> ? Dump Length: 97792 >> ? Blocksize: 512 >> ? Compression: none >> ? Dumptime: 2020-08-20 16:41:45 +0200 >> ? Hostname: current >> ? Magic: FreeBSD Text Dump >> ? Version String: FreeBSD 13.0-CURRENT #3 r364372: Wed Aug 19 07:54:57 >> CEST 2020 >> ??? root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >> *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy >> @ /usr/src/sys/vm/vm_page.c:1609** >> **? Dump Parity: 4227235352* >> ? Bounds: 2 >> ? Dump Status: good >> >>> > > device IWNFW >>> >>> doesn't install the 6000, btw --- probably can't find FW on device >>> HAL. >>> >>> > Again, this is not needed, firmware is autoloaded on module >>> >>> load. Just add >>> >>> > if_iwn to kld_list in /etc/rc.conf >>> >>> Here I admit I was wrong, iwn handles it differently than iwm. The man >>> page lists 3 different firmware versions for the 6000 series, which >>> can be loaded from loader.conf >> When compiling DEVICE iwnfb into kern: mine (iwn6000g2bfw) doesn't load >> probably at bootup but with wpa_supplicant -d BSD -i wlan0 -c >> /etc/wpa_supplicant.conf it loads correctly and automatically assigns an >> IP. >> >>> built 15 hours of NanoBSD while finishing the nightly built >>> someone was on >>> Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at >>> all but some >>> reason tells me behind this system in system is something to beat >>> beastie in >>> killing KFC forks. >>> >>> > > I get a *nice* message a bootup: >>> > > >>> > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm >>> >>> 1.1.0 20060810 >>> >>> > > Aug 19 02:51:10 current kernel: drmn0: >>> >>> on vgapci0 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by >>> >>> graphics >>> >>> > > device = 2048M >>> > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation >>> >>> failed. >>> >>> > > Graphics performance may suffer. >>> > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus0: on >>> > > iicbb_nostop0 addr 0x1 >>> > > Aug 19 02:51:10 current kernel: iic0: on iicbus0 >>> > > Aug 19 02:51:10 current kernel: iicbus1: on >>> >>> intel_gmbus0 >>> >>> > > Aug 19 02:51:10 current kernel: iic1: on iicbus1 >>> > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus2: on >>> > > iicbb_nostop1 addr 0x12 >>> > > Aug 19 02:51:10 current kernel: iic2: on iicbus2 >>> > > Aug 19 02:51:10 current kernel: iicbus3: on >>> >>> intel_gmbus1 >>> >>> > > Aug 19 02:51:10 current kernel: iic3: on iicbus3 >>> > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus4: on >>> > > iicbb_nostop2 addr 0x12 >>> > > Aug 19 02:51:10 current kernel: iic4: on iicbus4 >>> > > Aug 19 02:51:10 current kernel: iicbus5: on >>> >>> intel_gmbus2 >>> >>> > > Aug 19 02:51:10 current kernel: iic5: on iicbus5 >>> > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus6: on >>> > > iicbb_nostop3 addr 0x12 >>> > > Aug 19 02:51:10 current kernel: iic6: on iicbus6 >>> > > Aug 19 02:51:10 current kernel: iicbus7: on >>> >>> intel_gmbus3 >>> >>> > > Aug 19 02:51:10 current kernel: iic7: on iicbus7 >>> > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus8: on >>> > > iicbb_nostop4 addr 0x12 >>> > > Aug 19 02:51:10 current kernel: iic8: on iicbus8 >>> > > Aug 19 02:51:10 current kernel: iicbus9: on >>> >>> intel_gmbus4 >>> >>> > > Aug 19 02:51:10 current kernel: iic9: on iicbus9 >>> > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0 >>> > > Aug 19 02:51:10 current kernel: iicbus10: on >>> > > iicbb_nostop5 addr 0x12 >>> > > >>> > > And furthermore: >>> > > >>> > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 >>> >>> message(s) >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank >>> >>> timestamp >>> >>> > > caching Rev 1 (10.10.201> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports >>> >>> precise >>> >>> > > vblank timestamp query. >>> > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on >>> >>> drmn0 >>> >>> > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: >>> detached >>> >>> > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0 >>> > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious >>> > > range 0xe0000000-0xf0000000 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: >>> get mode >>> >>> > > from tunables: >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.modes.LVDS-1 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.default_mode >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: >>> get mode >>> >>> > > from tunables: >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.modes.VGA-1 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.default_mode >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Connector >>> >>> HDMI-A-1: get >>> >>> > > mode from tunables: >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.modes.HDMI-A-1 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.default_mode >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: >>> get mode >>> >>> > > from tunables: >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.modes.DP-1 >>> >>> > > Aug 19 02:51:10 current kernel: info: [drm]? ?- >>> >>> kern.vt.fb.default_mode >>> >>> > > Aug 19 02:51:10 current kernel: fbd0 on drmn0 >>> > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant >>> >>> locked >>> >>> > > and may be deleted before> >>> > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" >>> >>> with new "fb". >>> >>> > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0 >>> > > 20080730 for drmn0 on minor 0 >>> > > >>> > > so far so good, quality of text in grafics 1368x1024 is perfectly >>> > > initialized. but now, when starting xinit or lightdm or sddm or >>> > > whatever I get a kernel panic: >>> > > >>> > > Dump header from device: /dev/ada0p4 >>> > > >>> > >? ?Architecture: i386 >>> > >? ?Architecture Version: 4 >>> > >? ?Dump Length: 97792 >>> > >? ?Blocksize: 512 >>> > >? ?Compression: none >>> > >? ?Dumptime: 2020-08-19 02:49:00 +0200 >>> > >? ?Hostname: current >>> > >? ?Magic: FreeBSD Text Dump >>> > >? ?Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 >>> >>> 20:18:40 >>> >>> > > CEST 2020 >>> > > >>> > > ?root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>> > > >>> > >? ?Panic String: vm_page_assert_xbusied: page 0x72bd024 not >>> >>> exclusive >>> >>> > > busy @ /usr/src/sys/vm/vm> >>> > > >>> > >? ?Dump Parity: 2773167169 >>> > >? ?Bounds: 1 >>> > >? ?Dump Status: good >>> > > >>> > >? ?/var/crash/vmcore.0 not found >>> > >>> > Do you have? dumpdev="AUTO" in /etc/rc.conf ? >>> >>> yes and the directory is /var/crash, but this is all I get as lack of >>> insufficent memory of dump, it says. >>> >>> Sounds like your swap device is to small. How big is it, and how much >>> memory do you have? >>> >>> > > First thing I think is kern options: >>> > > >>> > > options WITNESS_SKIPSPIN >>> > > options WITNESS >>> > > >>> > > I disabled device HYPERV but this can't be the reason, kern is >>> >>> being >>> >>> > > compiled with clang. >>> > >>> > Clang is the default since a long time. >>> >>> depends on gcc++ development in 4D AIs. >>> >>> Nothing stops you from using gcc for compiling your programs. Clang is >>> just the default for the OS. >>> >>> > > To disable WITNESS would be one way I think but this can't be the >>> > > yellw of the egg, isn't it? >>> > >>> > I use the GENERIC-NODEBUG kernel config which disables WITNESS >>> >>> for some >>> >>> > performance improvements. >>> >>> yup. we don't need another debugger. killing insects is murder but >>> when >>> getting better stuff I never resist to lance them. like housecats >>> with flys. >>> >>> > > Another thing but I guess having nothing to do with bug above >>> >>> is on >>> >>> > > rather the end of? startup: >>> > > >>> > > Aug 19 02:51:10 current savecore[1209]: reboot after panic: >>> > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @ >>> > > /usr/src/sys/vm/vm_page.c:1609 >>> > > Aug 19 02:51:10 current savecore[1209]: writing core to >>> > > /var/crash/textdump.tar.1 >>> > > Aug 19 02:51:10 current kernel: linsysfs: >>> > > Aug 19 02:51:10 current kernel: Device busy >>> > > Aug 19 02:51:10 current kernel: lock order reversal: >>> > > Aug 19 02:51:10 current kernel:? 1st 0x3121e870 ufs (ufs, >>> >>> lockmgr) @ >>> >>> > > /usr/src/sys/kern/vfs_mount.c:1008 >>> > > Aug 19 02:51:10 current kernel:? 2nd 0x3121e744 devfs (devfs, >>> >>> lockmgr) >>> >>> > > @ /usr/src/sys/kern/vfs_mount.c:1019 >>> > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs >>> >>> established at: >>> > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at >>> >>> witness_checkorder+0x3c5 >>> >>> > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at >>> >>> lockmgr_lock_flags+0x140 >>> >>> > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57 >>> > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>> > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>> > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>> > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>> > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57 >>> > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452 >>> > > Aug 19 02:51:10 current kernel: #9 0x10859be at >>> >>> vfs_mountroot+0x4ce >>> >>> > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22 >>> > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68 >>> > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at >>> > > __stop_set_sysinit_set+0xd0a4199e >>> > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs >>> >>> attempted at: >>> > > Aug 19 02:51:10 current kernel: #0 0x1028360 at >>> >>> witness_checkorder+0xa50 >>> >>> > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46 >>> > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a >>> > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f >>> > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f >>> > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99 >>> > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b >>> > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d >>> > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195 >>> > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at >>> > > __stop_set_sysinit_set+0xd0a41989 >>> > > >>> > > any ideas? >>> > > Miranda >>> > > >>> > > >>> > > >>> > > does someone know how to fix it? >>> > > >>> > > Miranda >>> > >>> > Hope this helps. >>> >>> It does! >>> >>> > Best regards >>> > Andreas Nilsson >>> >>> Yours, >>> Miranda van Breukelingen >>> >>> Best regards >>> Andreas Nilsson >> ------------------------------ >> >> Message: 4 >> Date: Thu, 20 Aug 2020 12:05:45 -0500 >> From: Eric van Gyzen >> To: current@freebsd.org, kevans@freebsd.org >> Subject: LOR: tun_ioctl after tun_mtx >> Message-ID: <41921dc3-b1e9-b823-12f4-d108319c08d4@vangyzen.net> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> I see this LOR on head r364364 while running the tcptestsuite >> (ports/net/tcptestsuite). In fact, I interrupted a test with Ctrl-C, >> and got a panic. I assume it's the same, since the test was twiddling >> the MTU, but I haven't looked closely. >> >> Eric >> >> lock order reversal: (sleepable after non-sleepable) >> 1st 0xfffff802238ea690 tun_mtx (tun_mtx, sleep mutex) @ >> /usr/src/sys/net/if_tuntap.c:1628 >> 2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) @ >> /usr/src/sys/net/if_tuntap.c:1326 >> lock order tun_ioctl -> tun_mtx established at: >> #0 0xffffffff80c432dd at witness_checkorder+0x46d >> #1 0xffffffff80bb38e4 at __mtx_lock_flags+0x94 >> #2 0xffffffff80cfad2b at tuninit+0x4b >> #3 0xffffffff80cfa44f at tunifioctl+0x6f >> #4 0xffffffff80dc398f at in6_update_ifa+0xa8f >> #5 0xffffffff80dc96f0 at in6_ifattach+0x5b0 >> #6 0xffffffff80dc577e at in6_if_up+0x7e >> #7 0xffffffff80ceb289 at if_up+0x69 >> #8 0xffffffff80cec2f7 at ifhwioctl+0xd07 >> #9 0xffffffff80ced475 at ifioctl+0x395 >> #10 0xffffffff80c490ae at kern_ioctl+0x28e >> #11 0xffffffff80c48d77 at sys_ioctl+0x127 >> #12 0xffffffff81015820 at amd64_syscall+0x140 >> #13 0xffffffff80febb3e at fast_syscall_common+0xf8 >> lock order tun_mtx -> tun_ioctl attempted at: >> #0 0xffffffff80c43c3c at witness_checkorder+0xdcc >> #1 0xffffffff80be0247 at _sx_xlock+0x67 >> #2 0xffffffff80cfa411 at tunifioctl+0x31 >> #3 0xffffffff80ceba5b at ifhwioctl+0x46b >> #4 0xffffffff80cf9101 at tunioctl+0x5b1 >> #5 0xffffffff80a7b0fc at devfs_ioctl+0xcc >> #6 0xffffffff80cc9bf2 at vn_ioctl+0x132 >> #7 0xffffffff80a7b76e at devfs_ioctl_f+0x1e >> #8 0xffffffff80c490ae at kern_ioctl+0x28e >> #9 0xffffffff80c48d77 at sys_ioctl+0x127 >> #10 0xffffffff81015820 at amd64_syscall+0x140 >> #11 0xffffffff80febb3e at fast_syscall_common+0xf8 >> >> local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_i >> pv4 -> ^C[-- Signal caught; please wait for cleanup --] >> >> Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock >> KDB: stack backtrace of thread 100505: >> sched_switch() at sched_switch+0x5b2/frame 0xfffffe00627165a0 >> mi_switch() at mi_switch+0x155/frame 0xfffffe00627165c0 >> sleepq_switch() at sleepq_switch+0x109/frame 0xfffffe0062716600 >> _sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfffffe00627166a0 >> _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe00627166e0 >> tunifioctl() at tunifioctl+0x31/frame 0xfffffe0062716720 >> ifhwioctl() at ifhwioctl+0x46b/frame 0xfffffe00627167a0 >> tunioctl() at tunioctl+0x5b1/frame 0xfffffe0062716810 >> devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe0062716860 >> vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe0062716970 >> devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0062716990 >> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0062716a00 >> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0062716ad0 >> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0062716bf0 >> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0062716bf0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp = >> 0x7fffffffd408, rbp = 0x7fffffffd540 --- >> panic: sleeping thread >> cpuid = 4 >> time = 1597942792 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe00652545e0 >> vpanic() at vpanic+0x182/frame 0xfffffe0065254630 >> panic() at panic+0x43/frame 0xfffffe0065254690 >> propagate_priority() at propagate_priority+0x219/frame 0xfffffe00652546d0 >> turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe0065254720 >> __mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfffffe00652547b0 >> __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0065254800 >> tunifioctl() at tunifioctl+0xdc/frame 0xfffffe0065254840 >> ifhwioctl() at ifhwioctl+0x2b1/frame 0xfffffe00652548c0 >> ifioctl() at ifioctl+0x395/frame 0xfffffe0065254990 >> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0065254a00 >> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0065254ad0 >> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0065254bf0 >> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0065254bf0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp = >> 0x7fffffffd428, rbp = 0x7fffffffdc50 --- >> KDB: enter: panic >> [ thread pid 61418 tid 100573 ] >> Stopped at kdb_enter+0x37: movq $0,0x10b70b6(%rip) >> >> >> ------------------------------ >> >> Message: 5 >> Date: Thu, 20 Aug 2020 16:41:59 -0500 >> From: Clay Daniels >> To: "freebsd-current@freebsd.org" >> Subject: Weekly Current 13.0 Snapshot? >> Message-ID: >> zQ3fz80=CRZGyYqb03hvmt2Sw@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >> Current with new goodies. I don't see it at it's usual location: >> >> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >> >> Clay >> >> >> ------------------------------ >> >> Message: 6 >> Date: Thu, 20 Aug 2020 21:47:06 +0000 >> From: Glen Barber >> To: Clay Daniels >> Cc: "freebsd-current@freebsd.org" >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: <20200820214706.GK61041@FreeBSD.org> >> Content-Type: text/plain; charset="us-ascii" >> >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>> Current with new goodies. I don't see it at it's usual location: >>> >>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >> Not ill, but indeed sick of the build being broken so much. >> >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.htm >> l >> >> Glen >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 833 bytes >> Desc: not available >> URL: >> > dfc32d/attachment-0001.sig> >> >> ------------------------------ >> >> Message: 7 >> Date: Thu, 20 Aug 2020 15:54:37 -0600 >> From: Warner Losh >> To: Glen Barber >> Cc: Clay Daniels , >> "freebsd-current@freebsd.org" >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> > >> Content-Type: text/plain; charset="UTF-8" >> >> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>>> Current with new goodies. I don't see it at it's usual location: >>>> >>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >>> Not ill, but indeed sick of the build being broken so much. >>> >>> >>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.h >>> tml >> Build isn't broken now, can't you just run it again? >> >> Warner >> >> >> ------------------------------ >> >> Message: 8 >> Date: Thu, 20 Aug 2020 18:38:58 -0400 >> From: Glen Barber >> To: Warner Losh >> Cc: Clay Daniels , >> "freebsd-current@freebsd.org" >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> Not without putting a wedge in place with updating scripts for the git >> conversion, which as you know, I am already past the deadline. >> >> Glen >> Sent from my phone. >> Please excuse my brevity and/or typos. >> >>> On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: >>> >>> ? >>> >>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >>>> >>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>>>> Current with new goodies. I don't see it at it's usual location: >>>>> >>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >>>> Not ill, but indeed sick of the build being broken so much. >>>> >>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739. >>>> html> >>> Build isn't broken now, can't you just run it again? >>> >>> Warner >> ------------------------------ >> >> Message: 9 >> Date: Thu, 20 Aug 2020 18:43:19 -0500 >> From: Clay Daniels >> To: Glen Barber >> Cc: Warner Losh , "freebsd-current@freebsd.org" >> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> WN251hqAb9JEwUwicSPR=1K6GyOw@mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> Sorry to bug you. I didn't even know about the snapshot email list, but I >> have just subscribed and will know next time. Do what you need to and don't >> worry about the snapshot this week. I too am busy this week and have plenty >> to do. >> >> Clay >> >> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: >>> Not without putting a wedge in place with updating scripts for the git >>> conversion, which as you know, I am already past the deadline. >>> >>> Glen >>> Sent from my phone. >>> Please excuse my brevity and/or typos. >>> >>> On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: >>> >>> ? >>> >>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>>>> Current with new goodies. I don't see it at it's usual location: >>>>> >>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/ >>>> Not ill, but indeed sick of the build being broken so much. >>>> >>>> >>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739. >>>> html> >>> Build isn't broken now, can't you just run it again? >>> >>> Warner >> ------------------------------ >> >> Message: 10 >> Date: Thu, 20 Aug 2020 19:48:23 -0400 >> From: Glen Barber >> To: Clay Daniels >> Cc: Warner Losh , "freebsd-current@freebsd.org" >> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> Content-Type: text/plain; charset=utf-8 >> >> Not bugging at all. >> >> I?m hoping that the state that machine is in now, with some sanding off some >> newly-discovered rough edges of some code changes, to have snapshots from >> git before Wednesday. >> >> Fingers crossed.... >> >> Glen >> Sent from my phone. >> Please excuse my brevity and/or typos. >> >>> On Aug 20, 2020, at 7:43 PM, Clay Daniels >>> wrote: >>> >>> ? >>> Sorry to bug you. I didn't even know about the snapshot email list, but I >>> have just subscribed and will know next time. Do what you need to and >>> don't worry about the snapshot this week. I too am busy this week and >>> have plenty to do. >>> >>> Clay >>> >>>> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber wrote: >>>> Not without putting a wedge in place with updating scripts for the git >>>> conversion, which as you know, I am already past the deadline. >>>> >>>> Glen >>>> Sent from my phone. >>>> Please excuse my brevity and/or typos. >>>> >>>>>> On Aug 20, 2020, at 5:54 PM, Warner Losh wrote: >>>>> ? >>>>> >>>>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber wrote: >>>>>> >>>>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote: >>>>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0 >>>>>>> Current with new goodies. I don't see it at it's usual location: >>>>>>> >>>>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13. >>>>>>> 0/ >>>>>> Not ill, but indeed sick of the build being broken so much. >>>>>> >>>>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/00073 >>>>>> 9.html>>> >>>>> Build isn't broken now, can't you just run it again? >>>>> >>>>> Warner >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> 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" >> >> >> ------------------------------ >> >> End of freebsd-current Digest, Vol 877, Issue 6 >> *********************************************** > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 21 Aug 2020 11:52:23 -0700 > From: Mark Millard > To: FreeBSD Current , FreeBSD Toolchain > > Cc: freebsd-arm > Subject: /usr/lib/libomp.so : is there a reason that aarch64 does not > have such by default? > Message-ID: <2E4E8340-E4C1-4ED4-9E3D-F249D85D10FF@yahoo.com> > Content-Type: text/plain; charset=us-ascii > > My context: head ( currently at -r363590 ) > > man src.conf is explicit that WITHOUT_OPENMP is the default for > aarch64 (for example). > > But I note that https://openmp.llvm.org/README.txt says: > (it has the more detailed breakdown of OS/compiler combinations > for architectures where it matters) > > QUOTE > Architectures Supported > ======================= > * IA-32 architecture > * Intel(R) 64 architecture > * Intel(R) Many Integrated Core Architecture > * ARM* architecture > * Aarch64 (64-bit ARM) architecture > * IBM(R) Power architecture (big endian) > * IBM(R) Power architecture (little endian) > * MIPS and MIPS64 architectures > * RISC-V 64 bit architecture > > Supported RTL Build Configurations > ================================== > > Supported Architectures: IA-32 architecture, Intel(R) 64, and > Intel(R) Many Integrated Core Architecture > > ---------------------------------------------- > | icc/icl | gcc | clang | > --------------|---------------|----------------------------| > | Linux* OS | Yes(1,5) | Yes(2,4) | Yes(4,6,7) | > | FreeBSD* | No | No | Yes(4,6,7,8) | > | OS X* | Yes(1,3,4) | No | Yes(4,6,7) | > | Windows* OS | Yes(1,4) | No | No | > ------------------------------------------------------------ > . . . > (7) Clang* currently does not offer a software-implemented 128 bit extended > precision type. Thus, all entry points reliant on this type are removed > from the library and cannot be called in the user program. The following > functions are not available: > __kmpc_atomic_cmplx16_* > __kmpc_atomic_float16_* > __kmpc_atomic_*_fp > . . . > Supported Architectures: IBM(R) Power 7 and Power 8 > > ----------------------------- > | gcc | clang | > --------------|------------|--------------| > | Linux* OS | Yes(1,2) | Yes(3,4) | > ------------------------------------------- > . . . > ENDQUOTE > > Nothing stands out for why WITH_OPENMP is in use by default only > for amd64, i386, and powerpc64. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > > > ------------------------------ > > Message: 3 > Date: Fri, 21 Aug 2020 21:19:04 +0000 > From: Li-Wen Hsu > To: freebsd-testing@freebsd.org > Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org > Subject: FreeBSD CI Weekly Report 2020-08-16 > Message-ID: <20200821211904.GA21926@freefall.freebsd.org> > Content-Type: text/plain; charset=us-ascii > > (Please send the followup to freebsd-testing@ and note Reply-To is set.) > > FreeBSD CI Weekly Report 2020-08-16 > =================================== > > Here is a summary of the FreeBSD Continuous Integration results for the period > from 2020-08-10 to 2020-08-16. > > During this period, we have: > > * 2008 builds (93.7% (-0.3) passed, 6.3% (+0.3) 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. > * 229 test runs (87.8% (-8.6) passed, 11.8% (+8.7) unstable, 0.4% (-0.1) > exception) were executed on amd64, i386, riscv64 architectures for head, > stable/12, stable/11 branches. > * 100 doc and www builds (100% (+0) passed) > > Test case status (on 2020-08-16 23:59): > | Branch/Architecture | Total | Pass | Fail | Skipped | > | ------------------- | ---------- | --------- | -------- | ------- | > | head/amd64 | 7894 (+20) | 7786 (+2) | 18 (+18) | 90 (0) | > | head/i386 | 7892 (+20) | 7777 (+5) | 18 (+18) | 97 (-3) | > | 12-STABLE/amd64 | 7620 (0) | 7563 (+3) | 0 (0) | 57 (-3) | > | 12-STABLE/i386 | 7618 (0) | 7550 (0) | 0 (0) | 68 (0) | > | 11-STABLE/amd64 | 6912 (0) | 6858 (-3) | 0 (0) | 54 (+3) | > | 11-STABLE/i386 | 6910 (0) | 6854 (0) | 0 (0) | 56 (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-20200816 and archive is available at > https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. > > ## Failing jobs > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ > There are still mutiple errors when building with gcc6, error log available at > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console > > ## Regressions > > * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 > https://bugs.freebsd.org/246537 > > * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import > https://bugs.freebsd.org/244732 > Needs to check if llvm11 import fixes this. > > * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 > https://bugs.freebsd.org/244163 > Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) > > * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel > https://bugs.freebsd.org/244168 > Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) > Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , needs more verification. > > ## 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 ~13 failing and ~109 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 > * Work on running these tests over OpenZFS is in progress > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ > * Total 3749 tests, 2277 success, 647 failures, 825 skipped > > ## 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 > 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 > * 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 > lib.libcasper.services.cap_net.net_test.* > 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/ > * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child > https://bugs.freebsd.org/243605 > * sys.kern.ptrace_test.ptrace__parent_wait_after_attach > https://bugs.freebsd.org/244055 > * sys.kern.ptrace_test.ptrace__parent_exits_before_child > https://bugs.freebsd.org/244056 > * sys.net.if_lagg_test.witness (i386) > https://bugs.freebsd.org/244163 > * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main > https://bugs.freebsd.org/244165 > * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) > https://bugs.freebsd.org/244168 > * sys.netinet6.frag6.frag6_07.frag6_07 > https://bugs.freebsd.org/244170 > * sys.netinet.fibs_test.udp_dontroute6 > https://bugs.freebsd.org/244172 > * sys.netpfil.pf.nat.exhaust > https://bugs.freebsd.org/244703 > * sys.geom.class.gate.ggate_test.ggated (i386) > https://bugs.freebsd.org/244737 > * sys.kern.sysv_test.msg > https://bugs.freebsd.org/233649 > > ## Issues > > ### Cause build fails > * 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 > > ### Open > * 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/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 > * https://bugs.freebsd.org/246443 > sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua > * https://bugs.freebsd.org/247510 > sys.net.if_lagg_test.status_stress panics kernel on i386 > > ### Others > > * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) > > > ------------------------------ > > Message: 4 > Date: Fri, 21 Aug 2020 23:23:19 +0200 > From: Hans Petter Selasky > To: Alexandre Levy > Cc: freebsd-current@freebsd.org > Subject: Re: Kernel crash during video transcoding > Message-ID: <0ccb28fe-569d-2abb-f94b-f33d6155a9e8@selasky.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2020-08-16 22:23, Alexandre Levy wrote: >> Any suggestions ? > Are there any simple steps to reproduce this? > > --HPS > > > ------------------------------ > > Message: 5 > Date: Sat, 22 Aug 2020 09:07:55 +0000 > From: myfreeweb > To: Mark Millard , FreeBSD Current > , FreeBSD Toolchain > > Cc: freebsd-arm > Subject: Re: /usr/lib/libomp.so : is there a reason that aarch64 does > not have such by default? > Message-ID: > <90091F80-717F-4405-952B-B6B955AE6E1F@unrelenting.technology> > Content-Type: text/plain; charset=utf-8 > > > > On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm wrote: >> My context: head ( currently at -r363590 ) >> >> man src.conf is explicit that WITHOUT_OPENMP is the default for >> aarch64 (for example). > [...] >> Nothing stands out for why WITH_OPENMP is in use by default only >> for amd64, i386, and powerpc64. > Because nobody has bothered to merge https://reviews.freebsd.org/D21167 > > > ------------------------------ > > Message: 6 > Date: Sat, 22 Aug 2020 11:49:34 +0000 > From: marco > To: freebsd-current > Subject: 13-CURRENT won't boot after switch to sysutils/openzfs > Message-ID: <20200822114934.GB40844@lordsith.net> > Content-Type: text/plain; charset="us-ascii" > > I'm running r364030. > > [~] uname -apKU > FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue Aug > 11 07:15:59 UTC 2020 > root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 > amd64 1300105 1300105 > > When switching from base ZFS to sysutils/openzfs 2020080800 the boot process fails. > > These are the steps I took: > > - bectl create r364030-OpenZFS > - bectl mount r364030-OpenZFS /mnt > - edit /mnt/boot/loader.conf to use openzfs_load="YES" instead of zfs_load. > - bectl activate r364030-OpenZFS > - bectl umount r364030-OpenZFS > - shutdown -r now > > The boot process shows: > Loader variables: > vfs.root.mountfrom=zfs:zroot/ROOT/r364030-OpenZFS > > But in the end never boots and drops me to the mountroot prompt > I've tried several options to make it boot but when I just enter (empty > line) I get the following: > > panic: mountroot: unable to (re-)mount root > > pls see https://bsd.to/C4yL > From owner-freebsd-current@freebsd.org Sat Aug 22 23:39:50 2020 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 EF5653A88DE for ; Sat, 22 Aug 2020 23:39:50 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYvxd6l8Pz3yQ5 for ; Sat, 22 Aug 2020 23:39:49 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 0122F60293 for ; Sat, 22 Aug 2020 23:39:48 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Sat, 22 Aug 2020 23:39:45 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs Message-ID: <20200822233945.GA2522@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> <20200822162743.GA64297@freedom.nl> <20200822164848.GA71156@freedom.nl> <20200822221014.GA1744@freedom.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20200822221014.GA1744@freedom.nl> Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-GPG-Fingerprint: A025 D8AA AC1B D2FC 380D 4FC1 8EA0 0BA8 8580 E6CB X-Virus-Scanned: clamav-milter 0.102.4 at c03mi01 X-Virus-Status: Clean X-Uptime: 11:22PM up 34 mins, 1 user, load averages: 0.19, 0.17, 0.18 X-Rspamd-Queue-Id: 4BYvxd6l8Pz3yQ5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[116.202.65.215:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:116.202.65.208/28]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lordsith.net]; NEURAL_HAM_SHORT(-0.90)[-0.896]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[116.202.65.215:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 23:39:51 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 22, 2020 at 10:10:14PM +0000, you (marco) sent the following to= [freebsd-current] : > On Sat, Aug 22, 2020 at 04:48:48PM +0000, you (marco) sent the following = to [freebsd-current] : > > On Sat, Aug 22, 2020 at 12:31:24PM -0400, you (Ryan Moeller) sent the f= ollowing to [freebsd-current] : > > > > > So besides not being able to boot= from the openzfs 2020080800 package install, I can't figure out why I can'= t upgrade the openzfs pkg to 2020081800 (which is the latest one in ports s= o I presume a package also exists of that same version) > >=20 > > If that won't work either I'll see if I can build sysutils/openzfs from= ports but I'd rather not mix packages and ports. >=20 > building and installing the GENERIC kernel did not do anything. > I can confirm BE r364030-OpenZFS booted with GENERIC but I got dropped > into the mountroot prompt again. > Before I got there I saw: >=20 > Trying to mount root from zfs:zroot/ROOT/r364030-OpenZFS failed with > error 2: unknown file system. >=20 > Guess I'll try to install sysutils/openzfs from ports next. Not happy with having to install the port but that worked. I removed openzfs and openzfs-kmod via pkg remove. Then did a 'make install clean' from sysutils/openzfs (2020081800) with r3= 64030 BE active. Once I confirmed the port installed a newer /boot/modules/openzfs.ko I destroyed r364030-OpenZFS and created it again so it would be in sync with r364030 and it would have the latest openzfs.ko. When I imported my backup pool (single drive, 1 vdev) /etc/zfs/zpool.cache was automatically created. So now I have 2 zpool cache files [~] ls -l /boot/zfs/zpool.cache /etc/zfs/zpool.cache -rw-r--r-- 1 root wheel 1456 Aug 22 22:04 /boot/zfs/zpool.cache -rw-r--r-- 1 root wheel 3088 Aug 22 22:54 /etc/zfs/zpool.cache [~] zpool get cachefile zroot backup NAME PROPERTY VALUE SOURCE backup cachefile - default zroot cachefile - default So the port does work even with running the GENERIC-NODEBUG kernel. Is it even possible to build a port only into a new BE and not the current one given how /usr is not mounted? Now I had to polute the active BE which could get me into trouble. I was hoping using BEs I could experiment by installing a port straight int= o the mounted BE. If that is possible I wouldn't mind getting some pointers on how to make th= at work. --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSgJdiqrBvS/DgNT8GOoAuohYDmywUCX0GsvgAKCRCOoAuohYDm y4WzAJwOCdiSWEDgywQ3OJo1YxWUN6CzLQCfTHqubd2hDoemyyEBh92swhKoZRM= =KpED -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@freebsd.org Sat Aug 22 23:46:08 2020 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 CB6033A89F1 for ; Sat, 22 Aug 2020 23:46:08 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BYw4w53TTz400X for ; Sat, 22 Aug 2020 23:46:08 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from Ryans-MBP.attlocal.net (unknown [IPv6:2600:1700:358a:c660:30a2:5ed0:7c41:3bda]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7BA6919AD4 for ; Sat, 22 Aug 2020 23:46:08 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Subject: Re: 13-CURRENT won't boot after switch to sysutils/openzfs To: freebsd-current@freebsd.org References: <20200822114934.GB40844@lordsith.net> <20200822162743.GA64297@freedom.nl> <20200822164848.GA71156@freedom.nl> <20200822221014.GA1744@freedom.nl> <20200822233945.GA2522@freedom.nl> From: Ryan Moeller Message-ID: <8a0b3636-bba5-d997-8cd2-34d4e78f9db4@FreeBSD.org> Date: Sat, 22 Aug 2020 19:46:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200822233945.GA2522@freedom.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 22 Aug 2020 23:46:08 -0000 On 8/22/20 7:39 PM, marco wrote: > On Sat, Aug 22, 2020 at 10:10:14PM +0000, you (marco) sent the following to [freebsd-current] : >> On Sat, Aug 22, 2020 at 04:48:48PM +0000, you (marco) sent the following to [freebsd-current] : >>> On Sat, Aug 22, 2020 at 12:31:24PM -0400, you (Ryan Moeller) sent the following to [freebsd-current] : > > > > > So besides not being able to boot from the openzfs 2020080800 package install, I can't figure out why I can't upgrade the openzfs pkg to 2020081800 (which is the latest one in ports so I presume a package also exists of that same version) >>> >>> If that won't work either I'll see if I can build sysutils/openzfs from ports but I'd rather not mix packages and ports. >> building and installing the GENERIC kernel did not do anything. >> I can confirm BE r364030-OpenZFS booted with GENERIC but I got dropped >> into the mountroot prompt again. >> Before I got there I saw: >> >> Trying to mount root from zfs:zroot/ROOT/r364030-OpenZFS failed with >> error 2: unknown file system. >> >> Guess I'll try to install sysutils/openzfs from ports next. > Not happy with having to install the port but that worked. Kernel modules are very dependent on the built module being in sync with the kernel you're running. Ports that provide kernel modules are prone to this sort of breakage on -CURRENT because the kernel changes so frequently break compatibility. > I removed openzfs and openzfs-kmod via pkg remove. > Then did a 'make install clean' from sysutils/openzfs (2020081800) with r364030 BE > active. > Once I confirmed the port installed a newer /boot/modules/openzfs.ko I > destroyed r364030-OpenZFS and created it again so it would be in sync > with r364030 and it would have the latest openzfs.ko. > > When I imported my backup pool (single drive, 1 vdev) > /etc/zfs/zpool.cache was automatically created. > > So now I have 2 zpool cache files > > [~] ls -l /boot/zfs/zpool.cache /etc/zfs/zpool.cache > -rw-r--r-- 1 root wheel 1456 Aug 22 22:04 /boot/zfs/zpool.cache > -rw-r--r-- 1 root wheel 3088 Aug 22 22:54 /etc/zfs/zpool.cache > > [~] zpool get cachefile zroot backup > NAME PROPERTY VALUE SOURCE > backup cachefile - default > zroot cachefile - default > > So the port does work even with running the GENERIC-NODEBUG kernel. > > Is it even possible to build a port only into a new BE and not the > current one given how /usr is not mounted? The port will build in a jail for sure, maybe also a chroot. So `bectl jail` should do the trick. > Now I had to polute the active BE which could get me into trouble. > I was hoping using BEs I could experiment by installing a port straight into the mounted BE. > If that is possible I wouldn't mind getting some pointers on how to make that work. >