From owner-freebsd-current@freebsd.org Sun May 3 01:47:03 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 526B12CD2A8 for ; Sun, 3 May 2020 01:47:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 49F84460KPz41Q4 for ; Sun, 3 May 2020 01:47:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Je91.JsVM1ltv_HQv7RPo8lTpTRycFoqzySPqqjE0TqqPJDSgl2wrD6oF6S1XVs d1qDmWaJAJehOqk8oe.7Ipt.G7QV8bj.otr9HeKeoxY2i5BWR4tTNwKYEVkkvLLomHdk27efm6Pn R00XHn8DwOcJpZsJ.K63G8ou5VoF5N840cQH2ECzAu18TZoFJFO3yZBfIdd23ZkPtQk9U98ePpvo Rdewpte3qUgIQoRa7ibTgDLHZtmiCjkRn45qZHjVRPFo65PUvXl1xZxuRpV7fohA9OIuaw6gqIa. RzT7hvdDspYdvyLSm2pG.0POTWCOJh7JtGSSX6scZrgppN1K1HWhjmMQGOrS8makSIKlyFFo7Gyx G8ACMe0g2kmOofKxrsYEPrBPqu6e_bXh8L7WsXYRwzxlYkQvxgejllkIkG8icHcLEkAhZ2fJ21jY IwEoZBmPhGealeVUAciF68JwoODAXlT5eMujt6urX.ptkVKQGYcaMsKzlhE4Aopu6oTMXAWsCKrn RNtox1Of1er_ZrrMhwJujCSbC48QrR6cal7pPri0tYqaEclSot_R.ndWW5.UlfIShYhdlb0hfqkJ zxM1DDhm4_3CA5bKElKA29U9353rr9ocAZE0hm2DEEWSTQllqJ3cCtcKjeoOr0E8UFwi6x4VIpV4 NS7Nb_563U_i9oEJE7ucID4iR2xxtKa_2UH_8a82ghVwjHJ9tdJnJRZ3xdCM6LekhPYq73d7wNbZ Fd__aMIl021gr6mVGd90tMjS5iu.yz.6B0EYbg065Bax3qFoKebJqDVixns.yM9APzXBcJv2.1bN Us2D6BahOo_CxHox.K7QbC.VU7jJUA0FVvVpYn3tIW3Bs4Ihtf7VHULYqni9KFTirOFbsRVM9Tz6 RjNvJO_8RIZXK2ucjENimeYuleDtYo6g0YcDWQBWvsFD6SUDhXX36dqA.J88kFY_etlq9t2AIJly FSwRZl02XU3ZscxsQLI1cH218SEN4S0rxYZp7hZV4alwjcU5YZ6uAPCSD4_e6MEXPQLZN6nBZC6y sqgfH1_H22IYxg7JDYi6AM0Tk1lcg8nKLE0g9AqOM9KYda17o4etBzK_AmwvWzcU2.lRXvtzrLjD vreHvtRlU3Estnhwm1EC96Jx1PGCOcDoBb5ahcHt7xB9h1uREAQKbA.D6iE1Rh.d5yHtHuGr20xw eKsnCfOmv_im7NjHv_7KT0PBl1EFj_bRLqhFmH.3Ypwei7v1tlZBTw7HxVrzU.eyR72_J.de5DLb EcTawSkW5s5UbhYSyhggiFdFE4U4jY8P1wG0sECxjDA3g7GwLf0acgyS36BDTRwv4SiNEd7QIl4j 7eASqnwbMs6RYDXdeY8_Hr10Cyw9EdS6gszJpJY.EVt3A4YlwotCB._0TC1UgLUKTjrPdKR153_L sgW7Fkw9v30nrOIIO0jUTZJTakaPjkvjpOS3ctPXxXB6ZhS.N5nt33jqzor0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 01:46:58 +0000 Received: by smtp427.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bd44885a1276e2c9781055283e56c150; Sun, 03 May 2020 01:46:55 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-Id: Date: Sat, 2 May 2020 18:46:54 -0700 To: "vangyzen@freebsd.org " , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 49F84460KPz41Q4 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.28 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.873,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.909,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.87), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 01:47:03 -0000 [I'm only claiming the new jemalloc is involved and that reverting avoids the problem.] I've been reporting to some lists problems with: dhclient sendmail rpcbind mountd nfsd getting SIGSEGV (signal 11) crashes and some core dumps on the old 2-socket (1 core per socket) 32-bit PowerMac G4 running head -r360311. Mika=C3=ABl Urankar sent a note suggesting that I try testing reverting head -r360233 for my head -r360311 context. He got it right . . . Context: The problem was noticed by an inability to have other machines do a: mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt sort of operation and to have succeed. By contrast, on the old PowerMac G4 I could initiate mounts against other machines just fine. I do not see any such problems on any of (all based on head -r360311): powerpc64 (old PowerMac G5 2-sockets with 2 cores each) armv7 (OrangePi+ 2ed) aarch64 (Rock64, RPi4, RPi3, OverDrive 1000, Macchiatobin Double Shot) amd64 (ThreadRipper 1950X) So I expect something 32-bit powerpc specific is somehow involved, even if jemalloc is only using whatever it is. (A kyua run with a debug kernel did not find other unexpected signal 11 sources on the 32-bit PowerMac compared to past kyua runs, at least that I noticed. There were a few lock order reversals that I do not know if they are expected or known-safe or not. I've reported those reversals to the lists as well.) Recent experiments based on the suggestion: Doing the buildworld, buildkernel and installing just the new kernel and rebooting made no difference. But then installing the new world and rebooting did make things work again: I no longer get core files for the likes of (old cores from before the update): # find / -name "*.core" -print /var/spool/clientmqueue/sendmail.core /rpcbind.core /mountd.core /nfsd.core Nor do I see the various notices for sendmail signal 11's that did not leave behind a core file --or for dhclient (no core file left behind). And I can mount the old PowerMac's drive from other machines just fine. Other notes: I do not actively use sendmail but it was left to do its default things, partially to test if such default things are working. Unfortunately, PowerMacs have a problematical status under FreeBSD and my context has my historical experiments with avoiding various problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun May 3 05:05:35 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 069B72D3F35 for ; Sun, 3 May 2020 05:05:35 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FDTB0GJdz4FF5 for ; Sun, 3 May 2020 05:05:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id x18so16867436wrq.2 for ; Sat, 02 May 2020 22:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0982GGyMT8ZeZ+kzb1cvZnn+JYIhtKaD2MNiEUPF0Hc=; b=NluyiL/8HJ9eYYrLHFrv13b/lVKqlar1qzP8kwfssfBLWUGTMLKhDEw+JcDlhUwc1z rCcT28mBd9jW2Z3ln+D/7rNcxJLuEKKjy1xEwe53aD2CqZqJcYiueWYmWOAmPQ++N+Zx HuR8soDNdsBsAl/sE/W4T4fRt+Lx57npoLlAFwlzr0wHbOuvke3C+P9lbgwu9t9/+iXk C4X79mAijpoXHNfHgESdNQkYCvTTZ6SewcRkIRy/Wh3aCYShKnpEgokuB5H/NNyJNbUu XjzPS5qN/Z8a44g3zgcU2Bv/IK1iHowneBIXQs/pQeBgL51B3BXz/uXQOflIW3dWCV3R w/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0982GGyMT8ZeZ+kzb1cvZnn+JYIhtKaD2MNiEUPF0Hc=; b=lkdB5/uiHBgbp52wasfSS6Vi35cblroC4GF2AHsRxK9OR7tiYtnxW03CbGAWt4GgqD SYd46rorzgX7vUxxKRZy6vAzzJmYQAI15hw7KZ/WSOLYCfOWCOxjmp8X7LKXZs/Oanb6 hjLOgK8c3VCZ7R/Hd6qwzf8ziDaysKKd3gyE6ymcATDXaEfIzqFzY4nZyhs6n0KW9Xoj YqtbCbIrVbSv1Pm3gq5hNJv9voO3SPD93WJh7y+Q5gL/v02X1c1+Lpjg+/dBNSFJ18hU XPFleFdX92miuCCh8IK2X6Rak/BDjdrrtvKKpI+F3qJHAuwkgSgQataLNKPjItXfPxh4 ERdA== X-Gm-Message-State: AGi0PuaoGhWh/KrULbdXGf8fIyIoiEnGi1j3cSUBB46bU9ZIknjDfRqL 91lEZ+fFg73D63bDFjJbrpnfoHneJqQ= X-Google-Smtp-Source: APiQypLE0ecddlt0xmuyP1SZTdMde+vDebcYzbWWIuLsNed8mJ+VOeITmcr1s9n7jbu4QiDez9YJFA== X-Received: by 2002:adf:fe51:: with SMTP id m17mr12006842wrs.414.1588482331357; Sat, 02 May 2020 22:05:31 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id r15sm78206wrq.93.2020.05.02.22.05.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 22:05:30 -0700 (PDT) Subject: Re: beadm no longer able to destroy, maybe since using OpenZFS From: Graham Perrin To: freebsd-current@freebsd.org References: Message-ID: <8e30bce4-e740-2d8b-24dd-b73471bf0fab@gmail.com> Date: Sun, 3 May 2020 06:05:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.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-Rspamd-Queue-Id: 49FDTB0GJdz4FF5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=NluyiL/8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; 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.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; 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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.33), ipnet: 2a00:1450::/32(-2.31), asn: 15169(-0.43), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 05:05:35 -0000 After reverting from OpenZFS to ZFS, I was able to destroy two of the boot environments that previously (below, 1st May, OpenZFS) could not be destroyed. I'm left with at least one BE 'r360237c' that can not be destroyed. Is it ever normal to find a snapshot described as '-'? root@momh167-gjp4-8570p:~ # kldstat | grep zfs  2    1 0xffffffff82109000   3a8b40 zfs.ko root@momh167-gjp4-8570p:~ # date Sun May  3 05:59:06 BST 2020 root@momh167-gjp4-8570p:~ # beadm list -as BE/Dataset/Snapshot                            Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                     -      - 314.0M 2020-03-10 18:24     r360237c@2020-03-20-06:19:45               -      - 1.0G 2020-03-20 06:19 r357746h   copperbowl/ROOT/r357746h                     -      - 3.4M 2020-04-08 09:28     r360237c@2020-04-09-17:59:32               -      - 1.1G 2020-04-09 17:59 r360237c   copperbowl/ROOT/r360237c@2020-03-20-06:19:45 -      - 1.0G 2020-03-20 06:19   copperbowl/ROOT/r360237c@2020-04-09-17:59:32 -      - 1.1G 2020-04-09 17:59   copperbowl/ROOT/r360237c@2020-04-29-13:24:52 -      - 11.2M 2020-04-29 13:24   copperbowl/ROOT/r360237c                     -      - 80.4G 2020-04-29 13:24 r360237e   copperbowl/ROOT/r360237e@2020-05-01-17:58:33 -      - 96.6M 2020-05-01 17:58   copperbowl/ROOT/r360237e                     NR     / 1.3G 2020-05-01 17:58     r360237c@2020-04-29-13:24:52               -      - 11.2M 2020-04-29 13:24 root@momh167-gjp4-8570p:~ # beadm destroy r360237c Are you sure you want to destroy 'r360237c'? This action cannot be undone (y/[n]): y Boot environment 'r360237c' was created from existing snapshot Destroy '-' snapshot? (y/[n]): y cannot destroy 'copperbowl/ROOT/r360237c': filesystem has dependent clones use '-R' to destroy the following datasets: copperbowl/ROOT/r360237e@2020-05-01-17:58:33 copperbowl/ROOT/r360237e copperbowl/ROOT/r357746h copperbowl/ROOT/Waterfox root@momh167-gjp4-8570p:~ # zfs list -t snapshot NAME                                                     USED AVAIL  REFER  MOUNTPOINT copperbowl/ROOT/r360237c@2020-03-20-06:19:45            1.02G -  59.2G  - copperbowl/ROOT/r360237c@2020-04-09-17:59:32            1.15G -  60.0G  - copperbowl/ROOT/r360237c@2020-04-29-13:24:52            11.2M -  62.2G  - copperbowl/ROOT/r360237e@2020-05-01-17:58:33            96.6M -  62.3G  - copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers     8K -  1.24G  - copperbowl/poudriere/jails/head@clean                    376K -  1.91G  - copperbowl/usr/home@2020-05-03-05:55-r360237            57.7M -   171G  - root@momh167-gjp4-8570p:~ # uname -v FreeBSD 13.0-CURRENT #54 r360237: Fri Apr 24 09:10:37 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # ---- On 01/05/2020 18:57, Graham Perrin wrote: > root@momh167-gjp4-8570p:~ # date ; uname -v > Fri May  1 18:52:31 BST 2020 > FreeBSD 13.0-CURRENT #54 r360237: Fri Apr 24 09:10:37 BST 2020 > root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > root@momh167-gjp4-8570p:~ # beadm list > BE       Active Mountpoint  Space Created > Waterfox -      -            1.3G 2020-03-10 18:24 > r357746h -      -          928.4M 2020-04-08 09:28 > r360237b -      -          213.6M 2020-04-28 20:17 > r360237c -      -           92.0G 2020-04-29 13:24 > r360237d -      -          153.2M 2020-04-30 13:08 > r360237e NR     /          720.4M 2020-05-01 17:58 > root@momh167-gjp4-8570p:~ # beadm destroy r360237b > Are you sure you want to destroy 'r360237b'? > This action cannot be undone (y/[n]): y > cannot promote 'copperbowl/ROOT/r360237d': not a cloned filesystem > root@momh167-gjp4-8570p:~ # beadm destroy r360237c > Are you sure you want to destroy 'r360237c'? > This action cannot be undone (y/[n]): y > Boot environment 'r360237c' was created from existing snapshot > Destroy '-' snapshot? (y/[n]): y > cannot destroy 'copperbowl/ROOT/r360237c': filesystem has dependent > clones > use '-R' to destroy the following datasets: > copperbowl/ROOT/r360237e > copperbowl/ROOT/r360237d@2020-05-01-17:58:54 > copperbowl/ROOT/r360237d@2020-05-01-17:58:33 > copperbowl/ROOT/r360237d > copperbowl/ROOT/r360237b@2020-04-30-13:08:36 > copperbowl/ROOT/r360237b > copperbowl/ROOT/r357746h > copperbowl/ROOT/Waterfox > root@momh167-gjp4-8570p:~ # beadm destroy r360237d > Are you sure you want to destroy 'r360237d'? > This action cannot be undone (y/[n]): y > cannot promote 'copperbowl/ROOT/r360237e': not a cloned filesystem > root@momh167-gjp4-8570p:~ # beadm list -as > BE/Dataset/Snapshot                            Active Mountpoint Space > Created > > Waterfox >   copperbowl/ROOT/Waterfox                     -      - 314.0M > 2020-03-10 18:24 >     r360237c@2020-03-20-06:19:45               -      - 1.0G > 2020-03-20 06:19 > > r357746h >   copperbowl/ROOT/r357746h                     -      - 3.4M > 2020-04-08 09:28 >     r360237c@2020-04-09-17:59:32               -      - 925.0M > 2020-04-09 17:59 > > r360237b >   copperbowl/ROOT/r360237b                     -      - 202.4M > 2020-04-28 20:17 >     r360237c@2020-04-29-13:24:52               -      - 11.2M > 2020-04-29 13:24 >   copperbowl/ROOT/r360237b@2020-04-30-13:08:36 -      - 1.4M > 2020-04-30 13:08 > > r360237c >   copperbowl/ROOT/r360237c@2020-03-20-06:19:45 -      - 1.0G > 2020-03-20 06:19 >   copperbowl/ROOT/r360237c@2020-04-09-17:59:32 -      - 925.0M > 2020-04-09 17:59 >   copperbowl/ROOT/r360237c@2020-04-20-06:44:01 -      - 11.6G > 2020-04-20 06:44 >   copperbowl/ROOT/r360237c@2020-04-29-13:24:52 -      - 11.2M > 2020-04-29 13:24 >   copperbowl/ROOT/r360237c                     -      - 92.0G > 2020-04-29 13:24 > > r360237d >   copperbowl/ROOT/r360237d                     -      - 151.8M > 2020-04-30 13:08 >     r360237b@2020-04-30-13:08:36               -      - 1.4M > 2020-04-30 13:08 >   copperbowl/ROOT/r360237d@2020-05-01-17:58:33 -      - 440.0K > 2020-05-01 17:58 >   copperbowl/ROOT/r360237d@2020-05-01-17:58:54 -      - 408.0K > 2020-05-01 17:58 > > r360237e >   copperbowl/ROOT/r360237e                     NR     / 720.0M > 2020-05-01 17:58 >     r360237d@2020-05-01-17:58:54               -      - 408.0K > 2020-05-01 17:58 > root@momh167-gjp4-8570p:~ # zfs list -t snapshot > NAME                                                     USED AVAIL  > REFER  MOUNTPOINT > copperbowl/ROOT/r360237b@2020-04-30-13:08:36            1.36M - 62.3G  - > copperbowl/ROOT/r360237c@2020-03-20-06:19:45            1.02G - 59.2G  - > copperbowl/ROOT/r360237c@2020-04-09-17:59:32             925M - 60.0G  - > copperbowl/ROOT/r360237c@2020-04-20-06:44:01            11.6G - 61.7G  - > copperbowl/ROOT/r360237c@2020-04-29-13:24:52            11.2M - 62.2G  - > copperbowl/ROOT/r360237d@2020-05-01-17:58:33             440K - 62.3G  - > copperbowl/ROOT/r360237d@2020-05-01-17:58:54             408K - 62.3G  - > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers     8K - 1.24G  - > copperbowl/poudriere/jails/head@clean                    384K - 1.91G  - > copperbowl/usr/home@2020-04-28-10:42-r360237            5.89G - 172G  - > root@momh167-gjp4-8570p:~ # > From owner-freebsd-current@freebsd.org Sun May 3 07: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 D36C42D6441 for ; Sun, 3 May 2020 07:05:56 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FH832HrHz4Lh1 for ; Sun, 3 May 2020 07:05:55 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id d15so17013874wrx.3 for ; Sun, 03 May 2020 00:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=iMCyxydXzB2O+VB/1q3PFL/VqDXSM35uBUEZv4Q1jJM=; b=BgjE7/6nEQn8exGNl5MVdRUnSCXubci27yyUASjAvyTrgvl7Z8+aDvIf9qgaDBhR+C /yLzkS8HskEPMpEDxXGNNgTerXAzETreJ2Aujvo2jpwM39K22iXQqyDavPH9kGPrpk7Y 1Bwghok2aidXkKE9Sfr5rA51as2Mwi08oXMNSwlAZbwL5jAdBbUoE2kG2vTPZNEnV6by PGUFpetr6KkwA0V6k7IjPe+vK6sRpprPNPuWBdrUrVYH6DieIk3Yds2WsmGu2c6V/S16 c6C6ePC72jXWTvnXna7TAXaUDNFovrbqxTNaLk+Oh60G5ugdxFMziMui8UB3k8sWIMwV qv9w== 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=iMCyxydXzB2O+VB/1q3PFL/VqDXSM35uBUEZv4Q1jJM=; b=Wd5GJB05/plQYt9cSsV4cJD3JWflski3RlWAG/gV76Gteq49x3Bz/BzdHV2Ac+efly IginMgOw4RxksTRXbS5o/Tpl7d1JawkP8/Xft0ipb6wn6jdPC0H0xhKpXzA0DWnYfdDg spb8/tYUzX8CpkdayEqhkYejiam/eJ3PNtMk0KO3PkOcj2WAwgPIhWwqlHNbjdxQc3j1 GHJpyCZWsq0gOASqKWPaiHNKeFzo5JX14nZIUT8R0VhvdTP0Sv1hlx3qE5xc+RS7xMcc coD+dJfUcO6ZW3Y3APqA0Tih4l/D75uaMyOGcjmSjcmi3hC7ObI5yvvrOKB5nd4xjnlq 4xSw== X-Gm-Message-State: AGi0Puaim/NGfeFNqcOizZhRhT4OHVkr0NslO2rCoaoT6ucQUA26zo1m PMKJ6PLgkYJitszp6RAw7tZFLvxE X-Google-Smtp-Source: APiQypKN82EDzfUCClXT1VkDJNW9r6yS5xqUTHeAuoP4yK+IciZzuO6QELJ8pLwV/4SONpSlbPO+lg== X-Received: by 2002:a5d:42cf:: with SMTP id t15mr12486720wrr.354.1588489553849; Sun, 03 May 2020 00:05:53 -0700 (PDT) Received: from ernst.home (pD9E2349A.dip0.t-ipconnect.de. [217.226.52.154]) by smtp.gmail.com with ESMTPSA id j4sm12564411wrm.85.2020.05.03.00.05.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 00:05:53 -0700 (PDT) Date: Sun, 3 May 2020 09:05:52 +0200 From: Gary Jennejohn To: Chris Cc: Grzegorz Junka , Subject: Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371 Message-ID: <20200503090552.36bfe99c@ernst.home> In-Reply-To: <8df5a5cd4ac5bd9e10516c1321ea2de2@udns.ultimatedns.net> References: <8df5a5cd4ac5bd9e10516c1321ea2de2@udns.ultimatedns.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: 49FH832HrHz4Lh1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=BgjE7/6n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[154.52.226.217.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.34), ipnet: 2a00:1450::/32(-2.31), asn: 15169(-0.43), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 07:05:56 -0000 On Sat, 02 May 2020 16:28:46 -0700 Chris wrote: > On Sun, 3 May 2020 00:15:48 +0100 Grzegorz Junka list1@gjunka.com said > > > On 02/05/2020 20:43, Chris wrote: > > > On Sat, 2 May 2020 20:19:56 +0100 Grzegorz Junka list1@gjunka.com said > > > > > >> On 02/05/2020 14:56, Grzegorz Junka wrote: > > >> > > > >> > On 02/05/2020 14:15, Grzegorz Junka wrote: > > >> >> cpuid = 3 > > >> >> > > >> >> time = 1588422616 > > >> >> > > >> >> KDB: stack backtrace: > > >> >> > > >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> > > >> 0xfffffe00b27e86b0 > > >> >> > > >> >> vpanic() at vpanic+0x182/frame 0xfffffe00b27e8700 > > >> >> > > >> >> panic() at panic+0x43/frame ... > > >> >> > > >> >> sleepq_add() > > >> >> > > >> >> ... > > >> >> > > >> >> I see > > >> >> > > >> >> db> > > >> >> > > >> >> in the terminal. I tried "dump" but it says, Cannot dump: no dump > > >> >> device specified. > > >> >> > > >> >> Is there a guide how to deal wit those, i.e. to gather information > > >> >> required to investigate issues? > > >> > > > >> > > >> Another thing is that I don't quite understand why the crash couldn't > > >> be dumped. > > >> > > >> root@crayon2:~ # swapinfo > > >> Device__________________ 1K-blocks________ Used______ Avail Capacity > > >> /dev/zvol/tank3/swap__ 33554432______________ 0 33554432________ 0% > > >> > > >> There is no entry in /etc/fstab though, should it be there too? > > > > > > How about your rc.conf(5) ? > > > > > > You need to define a dumpdev within it as: > > > > > > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > > > dumpdev="YES" > > > > > > Which defaults to the location of: > > > > > > /var/crash > > > > > > > Yes, of course I have 'dumpdev="AUTO"'. Should it be "YES" instead? > Yes, it should of course be AUTO. I was distracted at the time of writing. > Sorry. > Does /var/crash exist? > > That _should_ be enough. Assuming /var/crash is writable. > Sorry, but read the man page for rc.conf. This is the entry for dumpdev: dumpdev (str) Indicates the device (usually a swap partition) to which a crash dump should be written in the event of a system crash. If the value of this variable is "AUTO", the first suitable swap device listed in /etc/fstab will be used as dump device. Otherwise, the value of this variable is passed as the argument to dumpon(8). To disable crash dumps, set this variable to "NO". If there are no swap devices in /etc/fstab then "AUTO" will not work. But a partition can be specified. I have dumpdev="/dev/ada0p5" in my rc.conf. /var/crash is the target for crash dumps after the system is re-booted. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sun May 3 08:26: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 E5F532D7A7A for ; Sun, 3 May 2020 08:26:19 +0000 (UTC) (envelope-from nonameless@ukr.net) Received: from frv197.fwdcdn.com (frv197.fwdcdn.com [212.42.77.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FJwp0gmjz4Pqt for ; Sun, 3 May 2020 08:26:18 +0000 (UTC) (envelope-from nonameless@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cTqMXKxtjm3PrzRBzX+3tC1Nj0fVsf476tQZl60eRbs=; b=eiiVOJyeHu7/9m/xGHdz42AJoT k8yIWEQZ6XyDhUbWwLYxE2tjppmkM8UqQMmXLVkJp2l0sxApeuiT+AMW0CJ5TGkWUBKyqhcLxIPyD 1+DRyDzOx/0gnxb8GbtzfJUAJiT0PyJXZI9Op7NYQIQ2hyvhITTxAR96zlhSaINlUPzg=; Received: from [10.10.80.11] (helo=frv55.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1jV9wv-000OLS-JC for freebsd-current@freebsd.org; Sun, 03 May 2020 11:26:09 +0300 Date: Sun, 03 May 2020 11:26:09 +0300 From: nonameless@ukr.net Subject: Re[2]: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 To: Mark Millard Cc: =?us-ascii?q?vangyzen=40freebsd=2Eorg?= , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Received: from nonameless@ukr.net by frv55.fwdcdn.com; Sun, 03 May 2020 11:26:09 +0300 In-Reply-To: References: X-Reply-Action: reply Message-Id: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 49FJwp0gmjz4Pqt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=eiiVOJye; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of nonameless@ukr.net designates 212.42.77.197 as permitted sender) smtp.mailfrom=nonameless@ukr.net X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.88), asn: 8856(-3.91), country: UA(0.07)]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[ukr.net]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; CC_EXCESS_QP(1.20)[]; RCPT_COUNT_FIVE(0.00)[6]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 08:26:20 -0000 --- Original message --- From: "Mark Millard"  Date: 3 May 2020, 04:47:14 > [I'm only claiming the new jemalloc is involved and that > reverting avoids the problem.] > > I've been reporting to some lists problems with: > > dhclient > sendmail > rpcbind > mountd > nfsd > > getting SIGSEGV (signal 11) crashes and some core > dumps on the old 2-socket (1 core per socket) 32-bit > PowerMac G4 running head -r360311. > > Mikaël Urankar sent a note suggesting that I try > testing reverting head -r360233 for my head -r360311 > context. He got it right . . . > > > Context: > > The problem was noticed by an inability to have > other machines do a: > > mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt > > sort of operation and to have succeed. By contrast, on > the old PowerMac G4 I could initiate mounts against > other machines just fine. > > I do not see any such problems on any of (all based > on head -r360311): > > powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > armv7 (OrangePi+ 2ed) > aarch64 (Rock64, RPi4, RPi3, > OverDrive 1000, > Macchiatobin Double Shot) > amd64 (ThreadRipper 1950X) > > So I expect something 32-bit powerpc specific > is somehow involved, even if jemalloc is only > using whatever it is. > > (A kyua run with a debug kernel did not find other > unexpected signal 11 sources on the 32-bit PowerMac > compared to past kyua runs, at least that I noticed. > There were a few lock order reversals that I do not > know if they are expected or known-safe or not. > I've reported those reversals to the lists as well.) > > > Recent experiments based on the suggestion: > > Doing the buildworld, buildkernel and installing just > the new kernel and rebooting made no difference. > > But then installing the new world and rebooting did > make things work again: I no longer get core files > for the likes of (old cores from before the update): > > # find / -name "*.core" -print > /var/spool/clientmqueue/sendmail.core > /rpcbind.core > /mountd.core > /nfsd.core > > Nor do I see the various notices for sendmail > signal 11's that did not leave behind a core file > --or for dhclient (no core file left behind). > And I can mount the old PowerMac's drive from > other machines just fine. > > > Other notes: > > I do not actively use sendmail but it was left > to do its default things, partially to test if > such default things are working. Unfortunately, > PowerMacs have a problematical status under > FreeBSD and my context has my historical > experiments with avoiding various problems. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Hi Mark, It should be fixed, but not by reverting to old version. We can't stuck on old version because of ancient hardware. I think upstream is not interested in support such hardware. So, it have to patched locally. Thanks. From owner-freebsd-current@freebsd.org Sun May 3 12:48:18 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 F0E262DCA81 for ; Sun, 3 May 2020 12:48:18 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 49FQl55db9z4d1t for ; Sun, 3 May 2020 12:48:17 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 9E47140EF3; Sun, 3 May 2020 14:48:11 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -100.931 X-Spam-Level: X-Spam-Status: No, score=-100.931 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=0.069, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id H3DQ5WvJNweB; Sun, 3 May 2020 14:48:10 +0200 (CEST) Received: from localhost (p5793B96B.dip0.t-ipconnect.de [87.147.185.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 4F37E40EED; Sun, 3 May 2020 14:48:10 +0200 (CEST) Date: Sun, 3 May 2020 14:48:07 +0200 From: Marco Steinbach To: Willem Jan Withagen Cc: freebsd current Subject: Re: Trying to compiles today Current Message-ID: <20200503144807.00004f8f@executive-computing.de> In-Reply-To: <836fe62d-2e0f-646b-7142-d598f9c33c64@digiware.nl> References: <836fe62d-2e0f-646b-7142-d598f9c33c64@digiware.nl> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49FQl55db9z4d1t X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of coco@executive-computing.de designates 195.96.35.7 as permitted sender) smtp.mailfrom=coco@executive-computing.de X-Spamd-Result: default: False [-5.33 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[executive-computing.de]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-3.13)[ip: (-8.23), ipnet: 195.96.32.0/19(-4.11), asn: 8354(-3.29), country: DE(-0.02)]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[107.185.147.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8354, ipnet:195.96.32.0/19, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 12:48:19 -0000 On Sun, 29 Mar 2020 15:36:22 +0200 Willem Jan Withagen wrote: > I keep getting errors in building my ports from portsbuilder. > But it is with Current/Clang10. > > So I'm trying to get a server at that level, but building world > keeps giving me: > --- all_subdir_cddl --- > ld: > error: /usr/obj/usr/srcs/head/amd64.amd64/tmp/usr/lib/libuutil.so: > undefined reference to __assfail cc: error: linker command failed > with exit code 1 (use -v to see invocation) *** [zfs.full] Error code > 1 > > > Completely cleared src and obj, but the error persists. > > Current on this system is: > FreeBSD 13.0-CURRENT #0 r358358: Thu Feb 27 04:40:39 UTC 2020 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > How to fix this? In my case a leftover CFLAGS=-O0 in /etc/make.conf was the culprit ('=' instead of '+=' not being a typo). As another side effect, build world took about four times as long as usual, before it errored out. While at it, I of also ran into what's described in https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072531.html, before removing DEBUG_FLAGS from /etc/make.conf. Conditionalizing the flags to only be pulled in for the directories I actually wanted them to be relevant for would certainly have helped. MfG CoCo From owner-freebsd-current@freebsd.org Sun May 3 13:11: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 72D862DD444 for ; Sun, 3 May 2020 13:11:19 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FRFf1mstz4fWx for ; Sun, 3 May 2020 13:11:17 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from [10.70.7.24] ([10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 043DB91P099724 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 3 May 2020 13:11:09 GMT (envelope-from list1@gjunka.com) Subject: Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371 To: freebsd-current@freebsd.org References: <8df5a5cd4ac5bd9e10516c1321ea2de2@udns.ultimatedns.net> <20200503090552.36bfe99c@ernst.home> From: Grzegorz Junka Message-ID: Date: Sun, 3 May 2020 14:11:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200503090552.36bfe99c@ernst.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 49FRFf1mstz4fWx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[gjunka.com]; IP_SCORE(-3.57)[ip: (-9.36), ipnet: 88.98.192.0/18(-4.68), asn: 56478(-3.74), country: GB(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 13:11:19 -0000 On 03/05/2020 08:05, Gary Jennejohn wrote: > On Sat, 02 May 2020 16:28:46 -0700 > Chris wrote: > >> >>> >>>>> Another thing is that I don't quite understand why the crash couldn't >>>>> be dumped. >>>>> >>>>> root@crayon2:~ # swapinfo >>>>> Device__________________ 1K-blocks________ Used______ Avail Capacity >>>>> /dev/zvol/tank3/swap__ 33554432______________ 0 33554432________ 0% >>>>> >>>>> There is no entry in /etc/fstab though, should it be there too? >>>> How about your rc.conf(5) ? >>>> >>>> You need to define a dumpdev within it as: >>>> >>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable >>>> dumpdev="YES" >>>> >>>> Which defaults to the location of: >>>> >>>> /var/crash >>>> >>> Yes, of course I have 'dumpdev="AUTO"'. Should it be "YES" instead? >> Yes, it should of course be AUTO. I was distracted at the time of writing. >> Sorry. >> Does /var/crash exist? >> >> That _should_ be enough. Assuming /var/crash is writable. >> > Sorry, but read the man page for rc.conf. > > This is the entry for dumpdev: > > dumpdev (str) Indicates the device (usually a swap partition) to > which a crash dump should be written in the event of a system > crash. If the value of this variable is "AUTO", the first > suitable swap device listed in /etc/fstab will be used as > dump device. Otherwise, the value of this variable is passed > as the argument to dumpon(8). To disable crash dumps, set > this variable to "NO". > > If there are no swap devices in /etc/fstab then "AUTO" will not work. But > a partition can be specified. I have dumpdev="/dev/ada0p5" in my rc.conf. > > /var/crash is the target for crash dumps after the system is re-booted. > /var/crash existed but might not have had the right permissions. I think it was 755 whereas the handbook recommends 700. Shouldn't matter though. I don't have anything about swap in fstab since I am using Root on ZFS. swapinfo correctly recognizes the swap partition and uses it. This the typical usage while I am compiling ports: last pid: 85116;  load averages:  8.95,  8.50, 8.34 up 0+18:06:31  13:02:32 72 processes:  14 running, 57 sleeping, 1 zombie CPU:  0.0% user, 90.5% nice,  9.5% system,  0.0% interrupt,  0.0% idle Mem: 993M Active, 594M Inact, 6400K Laundry, 12G Wired, 2225M Free ARC: 6160M Total, 3093M MFU, 2657M MRU, 214M Anon, 100M Header, 193M Other      5300M Compressed, 5861M Uncompressed, 1.11:1 Ratio Swap: 32G Total, 61M Used, 32G Free The crash happened in similar conditions so there should be nothing preventing dumping the crash to the zfs swap, unless dumpon isn't smart enough to use zfs swap. I don't have a partition that I could use for swap. I have two whole disks added to ZFS. Maybe on the boot drive but that would require repartitioning and I have Windows/FreeBSD there, so not so straightforward. --GrzegorzJ From owner-freebsd-current@freebsd.org Sun May 3 13:18: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 C6F612DD7A4 for ; Sun, 3 May 2020 13:18:09 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FRPY0gxkz4gCZ for ; Sun, 3 May 2020 13:18:08 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from [10.70.7.24] ([10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 043DI7qE099783 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 3 May 2020 13:18:07 GMT (envelope-from list1@gjunka.com) Subject: Re: lock order reversal and poudriere To: freebsd-current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net References: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> From: Grzegorz Junka Message-ID: <0c256497-955c-122e-400a-8642f90b8e97@gjunka.com> Date: Sun, 3 May 2020 14:18:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 49FRPY0gxkz4gCZ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd,lor]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gjunka.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-3.57)[ip: (-9.36), ipnet: 88.98.192.0/18(-4.68), asn: 56478(-3.75), country: GB(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 13:18:09 -0000 On 02/05/2020 10:08, Grzegorz Junka wrote: > I am compiling some packages with poudriere on 13-current kernel. I > noticed some strange messages printed into the terminal and dmesg: > > lock order reversal: >  1st 0xfffff8010ca78250 zfs (zfs) @ /usr/src-13/sys/kern/vfs_mount.c:1005 >  2nd 0xfffff8010cd37250 devfs (devfs) @ > /usr/src-13/sys/kern/vfs_mount.c:1016 > stack backtrace: > #0 0xffffffff80c2d5f1 at witness_debugger+0x71 > #1 0xffffffff80b92f18 at lockmgr_lock_flags+0x188 > #2 0xffffffff80cae744 at _vn_lock+0x54 > #3 0xffffffff80c90756 at vfs_domount+0xd16 > #4 0xffffffff80c8efd1 at vfs_donmount+0x871 > #5 0xffffffff80c8e729 at sys_nmount+0x69 > #6 0xffffffff81060c40 at amd64_syscall+0x140 > #7 0xffffffff810370a0 at fast_syscall_common+0x101 > pid 17216 (conftest), jid 6, uid 0: exited on signal 11 > pid 51159 (conftest), jid 6, uid 0: exited on signal 11 > pid 23833 (conftest), jid 3, uid 0: exited on signal 11 > pid 4916 (conftest), jid 3, uid 0: exited on signal 11 > > (... then there is a bunch of similar ones, then ...) > > pid 14504 (conftest), jid 3, uid 0: exited on signal 11 > pid 27466 (conftest), jid 6, uid 0: exited on signal 11 > pid 43297 (conftest), jid 5, uid 0: exited on signal 11 > lock order reversal: >  1st 0xfffffe00bc68c030 filedesc structure (filedesc structure) @ > /usr/src-13/sys/kern/sys_generic.c:1557 >  2nd 0xfffff803baeddbd8 tmpfs (tmpfs) @ > /usr/src-13/sys/kern/vfs_vnops.c:1553 > stack backtrace: > #0 0xffffffff80c2d5f1 at witness_debugger+0x71 > #1 0xffffffff80b946b5 at lockmgr_xlock+0x55 > #2 0xffffffff80cae744 at _vn_lock+0x54 > #3 0xffffffff80cad0da at vn_poll+0x3a > #4 0xffffffff80c33e19 at kern_poll+0x419 > #5 0xffffffff80c340df at sys_ppoll+0x6f > #6 0xffffffff81060c40 at amd64_syscall+0x140 > #7 0xffffffff810370a0 at fast_syscall_common+0x101 > pid 37533 (conftest), jid 5, uid 0: exited on signal 11 > pid 43474 (conftest), jid 5, uid 0: exited on signal 11 > > I restarted the compilation and again seeing similar LORs: lock order reversal:  1st 0xfffff80115d32068 zfs (zfs) @ /usr/src-13/sys/kern/vfs_mount.c:1005  2nd 0xfffff800243d6808 devfs (devfs) @ /usr/src-13/sys/kern/vfs_mount.c:1016 stack backtrace: #0 0xffffffff80c2d5f1 at witness_debugger+0x71 #1 0xffffffff80b92f18 at lockmgr_lock_flags+0x188 #2 0xffffffff80cae744 at _vn_lock+0x54 #3 0xffffffff80c90756 at vfs_domount+0xd16 #4 0xffffffff80c8efd1 at vfs_donmount+0x871 #5 0xffffffff80c8e729 at sys_nmount+0x69 #6 0xffffffff81060c40 at amd64_syscall+0x140 #7 0xffffffff810370a0 at fast_syscall_common+0x101 lock order reversal:  1st 0xfffffe00a7aa49b0 filedesc structure (filedesc structure) @ /usr/src-13/sys/kern/sys_generic.c:1557  2nd 0xfffff800aa2cdbd8 zfs (zfs) @ /usr/src-13/sys/kern/vfs_vnops.c:1553 stack backtrace: #0 0xffffffff80c2d5f1 at witness_debugger+0x71 #1 0xffffffff80b946b5 at lockmgr_xlock+0x55 #2 0xffffffff80cae744 at _vn_lock+0x54 #3 0xffffffff80cad0da at vn_poll+0x3a #4 0xffffffff80c33e19 at kern_poll+0x419 #5 0xffffffff80c339f0 at sys_poll+0x50 #6 0xffffffff81060c40 at amd64_syscall+0x140 #7 0xffffffff810370a0 at fast_syscall_common+0x101 The page to report still returns 404 :) -- GrzegorzJ From owner-freebsd-current@freebsd.org Sun May 3 14:00: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 ED2C82DE46C for ; Sun, 3 May 2020 14:00:58 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 49FSLx2NHsz3F47; Sun, 3 May 2020 14:00:56 +0000 (UTC) (envelope-from zeising+freebsd@daemonic.se) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 49FSLk6wpRz3mGw; Sun, 3 May 2020 14:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=daemonic.se; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=20151023; t=1588514445; bh=rB8J2tl5FrI6SoF5u21QXbjI x4PC7WUvSa/MNGkrw8E=; b=WcbzUOPVqL2XfIpypaFH6dJwGxHSep9kFAy0G4qz QQPj95SM4L+fSAML7WzhDlfS41xLr7v6ZfV3saH9W04lHNPE9GAOE1RuYddfMIPZ dtaRI5BQPkE11aS3Szh7cWR81BDluCP4Vwlm002tK8nL8gckg6hbayikkXucTmUx zR8= X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id zEWhmXciQ24N; Sun, 3 May 2020 14:00:45 +0000 (UTC) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:2::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 49FSLh6xQ1z3lb5; Sun, 3 May 2020 14:00:44 +0000 (UTC) Subject: Re: lock order reversal and poudriere To: Kurt Jaeger , Grzegorz Junka Cc: bzeeb+freebsd+lor@zabbadoz.net, freebsd-current@freebsd.org References: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> <20200502095404.GN39563@home.opsec.eu> <20200502183634.GA90255@fc.opsec.eu> From: Niclas Zeising Message-ID: Date: Sun, 3 May 2020 16:00:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200502183634.GA90255@fc.opsec.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49FSLx2NHsz3F47 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=daemonic.se header.s=20151023 header.b=WcbzUOPV; dmarc=pass (policy=none) header.from=daemonic.se; spf=pass (mx1.freebsd.org: domain of zeising@daemonic.se designates 2607:f740:d:20::25 as permitted sender) smtp.mailfrom=zeising@daemonic.se X-Spamd-Result: default: False [-6.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[daemonic.se:s=20151023]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd,lor]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[daemonic.se:+]; DMARC_POLICY_ALLOW(-0.50)[daemonic.se,none]; IP_SCORE(-3.69)[ip: (-9.72), ipnet: 2607:f740:d::/48(-4.86), asn: 36236(-3.80), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US]; TAGGED_FROM(0.00)[freebsd]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:00:59 -0000 On 2020-05-02 20:36, Kurt Jaeger wrote: > Hi! > >>>> I am compiling some packages with poudriere on 13-current kernel. I >>>> noticed some strange messages printed into the terminal and dmesg: >>>> >>>> lock order reversal: >>> [...] >>>> Are those the debug messages that aren't visible on non-current kernel >>>> and should they be reported? >>> Yes, they should be checked and reported. >>> >>> For more details see: >>> >>> http://sources.zabbadoz.net/freebsd/lor.html >>> >>> There's a webpage with a list of all known LORs and a way to >>> report new LORs. > >> Thanks Kurt. I can't find those two specific LORs in the list on that >> page. The page also says to report them using a link, which leads to 404 >> :-), or on this mailing list, which I did. I am not sure what else should >> I do. > > I don't know, either 8-} bz@ is in Cc:, so he'll probably know what > to do. > >> How do I know if I have got a backtrace? >> >> Are those errors: >> >> pid 43297 (conftest), jid 5, uid 0: exited on signal 11 >> >> related or it's a different issue? > > I think that's a different issue. > conftest is when configure scripts do things. Configure works a lot by compiling (and sometimes running) small snippets of code to figure out what's going on. Sometimes those snippets core dump. It's all normal. Regards -- Niclas From owner-freebsd-current@freebsd.org Sun May 3 14:13:35 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 770B12DEA8B for ; Sun, 3 May 2020 14:13:35 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FSdV5jYSz3G3h for ; Sun, 3 May 2020 14:13:34 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x344.google.com with SMTP id z6so5768346wml.2 for ; Sun, 03 May 2020 07:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=lKIzBYNDqA2A0jbUsy4lzSImtITwinAjmYP2RpfMR0A=; b=QuG5pSoviwV0r88bG1xpdh9TLx8C+eUMHDv1zecgGzUVIAz7cCGzag44dTu8UxFvCQ Gy+P/scg3I9xX53lTkrenvZjtbwW7j/Ufi8BPuoV2Yo3BLH9f3ZtnBUeAY3Ax4jC861H h1h+znJf7Bu/AuQGxbhSN9ZdlQnHp3uvUXEmm32GGrsrQXT6cZ1SLk7OFcIztyeNmtlM 0gD+X+lwaO7qKuquE/55gFL/CeEXTwy302cX/bCScP9qhIHZEcoa/DZ+vImFP8zk6XtM ehC+lN05eF0tW2UziPXWcsdtbG3oYjKIICxV6QUDV79QS0PoZN5eb/cMaX4pk1AjuKfV 512g== 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=lKIzBYNDqA2A0jbUsy4lzSImtITwinAjmYP2RpfMR0A=; b=obnFHNeH//IvgbsKdp4GaqqblrHbxcKXjOP1v1v3zY8nvjEJo8HARE853OPgS1+He2 NKm4pYnx56gQqfYSGjwuCz6CBDuY0POIue0jMY86pgkgYNDiITnxd6wZcj/Rw5ScJXFA P9IOD0v6T+bFgujOzzlvU/kBWWUAaBmZiXIsQXjQOGuShyDf+gS5iR7rlAFE1aT4BlBI SFcLwI1TrNdnhBdDY8LZP2PDTDRqrBd5i5ti+XtJ4THN71pWf0VvtUavCxqzK5Uk2O+b 5654TKka+qDiWAMQxPKzZlWEmCsfL1MB6+cEMUnRE/WHRzf3RCOX/L+xDTAhUij+LP3B /TTg== X-Gm-Message-State: AGi0PuZ2s+URr3C2IUl7UiAFYxuY0gq16Qlhr/IbbbBTAGbO1n9JPxEZ 6rJ2/K79/1mJRPQp5MCzj3QUrdNk X-Google-Smtp-Source: APiQypL1b60ywVfRJEGtyAW+wyF2YIa6Xlxv+/vpwAnvl27GVjst2rpB3hvR/hjgfXV8bMfUyoYnEg== X-Received: by 2002:a1c:a90a:: with SMTP id s10mr8973532wme.99.1588515212569; Sun, 03 May 2020 07:13:32 -0700 (PDT) Received: from ernst.home (pD9E2349A.dip0.t-ipconnect.de. [217.226.52.154]) by smtp.gmail.com with ESMTPSA id e2sm13992591wrv.89.2020.05.03.07.13.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 07:13:32 -0700 (PDT) Date: Sun, 3 May 2020 16:13:30 +0200 From: Gary Jennejohn To: Grzegorz Junka Cc: freebsd-current@freebsd.org Subject: Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371 Message-ID: <20200503161330.621850a7@ernst.home> In-Reply-To: References: <8df5a5cd4ac5bd9e10516c1321ea2de2@udns.ultimatedns.net> <20200503090552.36bfe99c@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: 49FSdV5jYSz3G3h X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QuG5pSov; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::344 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; TO_DN_SOME(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]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[154.52.226.217.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.47), ipnet: 2a00:1450::/32(-2.31), asn: 15169(-0.43), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:13:35 -0000 On Sun, 3 May 2020 14:11:09 +0100 Grzegorz Junka wrote: > On 03/05/2020 08:05, Gary Jennejohn wrote: > > On Sat, 02 May 2020 16:28:46 -0700 > > Chris wrote: > > > >> > >>> > >>>>> Another thing is that I don't quite understand why the crash couldn't > >>>>> be dumped. > >>>>> > >>>>> root@crayon2:~ # swapinfo > >>>>> Device__________________ 1K-blocks________ Used______ Avail Capacity > >>>>> /dev/zvol/tank3/swap__ 33554432______________ 0 33554432________ 0% > >>>>> > >>>>> There is no entry in /etc/fstab though, should it be there too? > >>>> How about your rc.conf(5) ? > >>>> > >>>> You need to define a dumpdev within it as: > >>>> > >>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > >>>> dumpdev="YES" > >>>> > >>>> Which defaults to the location of: > >>>> > >>>> /var/crash > >>>> > >>> Yes, of course I have 'dumpdev="AUTO"'. Should it be "YES" instead? > >> Yes, it should of course be AUTO. I was distracted at the time of writing. > >> Sorry. > >> Does /var/crash exist? > >> > >> That _should_ be enough. Assuming /var/crash is writable. > >> > > Sorry, but read the man page for rc.conf. > > > > This is the entry for dumpdev: > > > > dumpdev (str) Indicates the device (usually a swap partition) to > > which a crash dump should be written in the event of a system > > crash. If the value of this variable is "AUTO", the first > > suitable swap device listed in /etc/fstab will be used as > > dump device. Otherwise, the value of this variable is passed > > as the argument to dumpon(8). To disable crash dumps, set > > this variable to "NO". > > > > If there are no swap devices in /etc/fstab then "AUTO" will not work. But > > a partition can be specified. I have dumpdev="/dev/ada0p5" in my rc.conf. > > > > /var/crash is the target for crash dumps after the system is re-booted. > > > > /var/crash existed but might not have had the right permissions. I think > it was 755 whereas the handbook recommends 700. Shouldn't matter though. > /var/crash is irrelevant when a crash dump is being written out. > I don't have anything about swap in fstab since I am using Root on ZFS. > swapinfo correctly recognizes the swap partition and uses it. This the > typical usage while I am compiling ports: > > last pid: 85116;__ load averages:__ 8.95,__ 8.50, 8.34 up 0+18:06:31__ 13:02:32 > 72 processes:__ 14 running, 57 sleeping, 1 zombie > CPU:__ 0.0% user, 90.5% nice,__ 9.5% system,__ 0.0% interrupt,__ 0.0% idle > Mem: 993M Active, 594M Inact, 6400K Laundry, 12G Wired, 2225M Free > ARC: 6160M Total, 3093M MFU, 2657M MRU, 214M Anon, 100M Header, 193M Other > ________ 5300M Compressed, 5861M Uncompressed, 1.11:1 Ratio > Swap: 32G Total, 61M Used, 32G Free > > The crash happened in similar conditions so there should be nothing > preventing dumping the crash to the zfs swap, unless dumpon isn't smart > enough to use zfs swap. > > I don't have a partition that I could use for swap. I have two whole > disks added to ZFS. Maybe on the boot drive but that would require > repartitioning and I have Windows/FreeBSD there, so not so straightforward. > As the dumpon man pages states, by the time a crash dump is needed the files systems are dead. No way to dump to a ZFS file system. That's why a raw partition is required. The other option would be netdump. See the dumpon man page. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sun May 3 14:38: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 D93722DF054 for ; Sun, 3 May 2020 14:38:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 49FT9x2m4Sz3H03 for ; Sun, 3 May 2020 14:38:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GK_At_sVM1nO4_VNufUJRQiRbBHFzGzYXYgVFH083iNk.b.MLZwLCxzQqnnsUNa x_8tvuR148QZ_3Kho53XjSXrKURYdHi6Mepaq0aR7AicR9ZXqrywG9b5VYoZ3p53tjxMKaaPOop0 pvyQ13wozBpoV6BHbme6jU2kelDLsAfqNTMNrWmCLTOFt2EGGIBHBW5hfOC_PN7MuUz0_k9THFAT y6nD1dJ2WZTwHhhXYmheWp7ZRs7pC4ujL0V2OF4_oDk.EvN3u_0qz8MLcU7DYY3tgGURYU7TR5Lg 4Dboz27fxBNRunL70Mv7hTI8MKCqk5oEWYh6PRlYLRDSlfJd.BEGjqPjVBtqHTPf5YZtGInMUolY ERAlV4mcsW.aY9RPf0kHlzjFuIabM2DDPVKlKinsgES2721ZQK9CNodqY8PoF_ZpPVKqjZPHHeVD EufxgxQ.uN.wJeLiOKddrQU_bJ2ALPk3Zn2Ctrd9hk0dPEWqfSlEH3GUcNZciLJ_v1JzOeaGs1b5 J1LNxKNc.vdqOAvNAOO3p9yfHTDhb1pax4SihajEkIys2VqoTL4E83jyVMLqxznBSCVKoLR0MCjP nKP1PhCNcjmj7P2EN7GMGUVq84IzaT2BjwIw_tCL9_4H1L.0k6uAblCxzNw8M2cA9tNK7nq8LtG8 fZTTJg0asx0TtwrpMKs1GzifRDtcRw41L5h2QarqElv4O.WCHXZBXu0Op9VTjJ5pmsHd4aUFEk6H HvUZZcqdKARb9Si2zlMfUyHEd0EH3qHjxCn.fVSYSvca4wpO2vInGnPl3dug7GaiCbhEvmOv4HLo iaNvd6QI2UiyFq0Ude4r4pYClsi2qiFh.usFs_8LDm9CvByvWx5.cPxMY.5VLn9U5kHKqpCtwwrE 3UacgmEl3rIqvX1THtMGWhZT2R1xplGqEvD2H8bS0wtPcyZaiAbuIy6LkGNM.58fn9HDPz4m8vQi xSNZ98UUCqjbrj5WiDIncS3de0AqzHNnQXgcqKYzq_CzJWTogxu0SiPnixGzfEQM.LMFfdcuePiH crHr1ZgP.cRnv9is1apmTGeHkuPs7l9xwhXErNydjgmq.7ebx7UbhQmDGC65uSyZeIKl9PqbQ5RU rhLSjTHbrBMJ3yMtfVAJTm1hN4Yh1LCTpazzGQa3Fhg8_bX281zBoMF9qqo.4eteSvXS5QE_hqci 0jRR3FVq.ammdhNbrjwZ55KrDaLmjcx729KoBqKZROcwXwlDD8qHcGtu8wkcpLuuXDJsGhrWm3dt v4.VXuUtkE.loMX9ZCBtIi0iI2TS8FoqXb3S8.IvI4o69lKXSZsMWG2tNtAgA2xoxfc6StW1dKSX hw0cRa6jpj8IJrdck2.YqCM9DyPZudBQg5oWBjX5Dtw02Mq0_nJspvLkRxCWyR2ffeIlDQm0SGZy I3Ka4EANwc7jutC3H4dTtDuVpAMuFJA30XpUzkCgoqE_c69mBuCy95GmkL7h6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 14:38:11 +0000 Received: by smtp425.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 152cb9da62572901c7e41056e9bc8777; Sun, 03 May 2020 14:38:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> Date: Sun, 3 May 2020 07:38:06 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> To: nonameless@ukr.net X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FT9x2m4Sz3H03 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.40 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[ukr.net]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.935,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.967,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.91), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[30.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[30.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:38:14 -0000 On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > --- Original message --- > From: "Mark Millard" > Date: 3 May 2020, 04:47:14 >=20 >=20 >=20 >> [I'm only claiming the new jemalloc is involved and that >> reverting avoids the problem.] >>=20 >> I've been reporting to some lists problems with: >>=20 >> dhclient >> sendmail >> rpcbind >> mountd >> nfsd >>=20 >> getting SIGSEGV (signal 11) crashes and some core >> dumps on the old 2-socket (1 core per socket) 32-bit >> PowerMac G4 running head -r360311. >>=20 >> Mika=C3=ABl Urankar sent a note suggesting that I try >> testing reverting head -r360233 for my head -r360311 >> context. He got it right . . . >>=20 >>=20 >> Context: >>=20 >> The problem was noticed by an inability to have >> other machines do a: >>=20 >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >>=20 >> sort of operation and to have succeed. By contrast, on >> the old PowerMac G4 I could initiate mounts against >> other machines just fine. >>=20 >> I do not see any such problems on any of (all based >> on head -r360311): >>=20 >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) >> armv7 (OrangePi+ 2ed) >> aarch64 (Rock64, RPi4, RPi3, >> OverDrive 1000, >> Macchiatobin Double Shot) >> amd64 (ThreadRipper 1950X) >>=20 >> So I expect something 32-bit powerpc specific >> is somehow involved, even if jemalloc is only >> using whatever it is. >>=20 >> (A kyua run with a debug kernel did not find other >> unexpected signal 11 sources on the 32-bit PowerMac >> compared to past kyua runs, at least that I noticed. >> There were a few lock order reversals that I do not >> know if they are expected or known-safe or not. >> I've reported those reversals to the lists as well.) >>=20 >>=20 >> Recent experiments based on the suggestion: >>=20 >> Doing the buildworld, buildkernel and installing just >> the new kernel and rebooting made no difference. >>=20 >> But then installing the new world and rebooting did >> make things work again: I no longer get core files >> for the likes of (old cores from before the update): >>=20 >> # find / -name "*.core" -print >> /var/spool/clientmqueue/sendmail.core >> /rpcbind.core >> /mountd.core >> /nfsd.core >>=20 >> Nor do I see the various notices for sendmail >> signal 11's that did not leave behind a core file >> --or for dhclient (no core file left behind). >> And I can mount the old PowerMac's drive from >> other machines just fine. >>=20 >>=20 >> Other notes: >>=20 >> I do not actively use sendmail but it was left >> to do its default things, partially to test if >> such default things are working. Unfortunately, >> PowerMacs have a problematical status under >> FreeBSD and my context has my historical >> experiments with avoiding various problems. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >>=20 >=20 > Hi Mark, >=20 > It should be fixed, but not by reverting to old version. We can't = stuck on old version because of ancient hardware. I think upstream is = not interested in support such hardware. So, it have to patched locally. Observing and reporting the reverting result is an initial part of problem isolation. I made no request for FreeBSD to give up on using the updated jemalloc. (Unfortunately, I'm not sure what a good next step of problem isolation might be for the dual-socket PowerMac G4 context.) Other than reverting, no patch is known for the issue at this point. More problem isolation is needed first. While I do not have access, https://wiki.freebsd.org/powerpc lists more modern 32-bit powerpc hardware as supported: MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). (The AmigaOne A1222 seems to be dual-ore/single-socket.) So folks with access to one of those may want to see if they also see the problem(s) with head -r360233 or later. Another interesting context to test could be single-socket with just one core. (I might be able to do that on another old PowerMac, booting the same media after moving the media.) If I understand right, the most common 32-bit powerpc tier 2 hardware platforms may still be old PowerMac's. They are considered supported and "mature", instead of just "stable". See https://wiki.freebsd.org/powerpc . However, the reality is that there are various problems for old PowerMacs (32-bit and 64-bit, at least when there is more than one socket present). The wiki page does not hint at such. (I'm not sure about single socket/multi-core PowerMacs: no access to such.) It is certainly possible for some problem to happen that would lead to dropping the supported-status for some or all old 32-bit PowerMacs, even as tier 2. But that has not happened yet and I'd have no say in such a choice. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun May 3 15:01: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 DC68C2DFA87 for ; Sun, 3 May 2020 15:01:53 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FTjF0Pcgz3JJd for ; Sun, 3 May 2020 15:01:52 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from [10.70.7.24] ([10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 043F1pH8001370 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 3 May 2020 15:01:51 GMT (envelope-from list1@gjunka.com) Subject: Re: lock order reversal and poudriere To: freebsd-current@freebsd.org References: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> <20200502095404.GN39563@home.opsec.eu> <20200502183634.GA90255@fc.opsec.eu> From: Grzegorz Junka Message-ID: Date: Sun, 3 May 2020 16:01:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 49FTjF0Pcgz3JJd X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[gjunka.com]; IP_SCORE(-3.57)[ip: (-9.36), ipnet: 88.98.192.0/18(-4.68), asn: 56478(-3.75), country: GB(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:01:53 -0000 On 03/05/2020 15:00, Niclas Zeising wrote: > On 2020-05-02 20:36, Kurt Jaeger wrote: >> >> I don't know, either 8-} bz@ is in Cc:, so he'll probably know what >> to do. >> >>> How do I know if I have got a backtrace? >>> >>> Are those errors: >>> >>> pid 43297 (conftest), jid 5, uid 0: exited on signal 11 >>> >>> related or it's a different issue? >> >> I think that's a different issue. >> > > conftest is when configure scripts do things.  Configure works a lot > by compiling (and sometimes running) small snippets of code to figure > out what's going on.  Sometimes those snippets core dump. It's all > normal. > Good to know. It's mostly conftest but sometimes others too: pid 37407 (cc), jid 9, uid 0: exited on signal 6 pid 95358 (conftest), jid 3, uid 0: exited on signal 11 pid 70242 (conftest), jid 9, uid 0: exited on signal 11 pid 27480 (ngc27183), jid 3, uid 0: exited on signal 11 Regards --GrzegorzJ From owner-freebsd-current@freebsd.org Sun May 3 15:04: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 D69882DFDA6 for ; Sun, 3 May 2020 15:04:39 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FTmR1bc4z3JY2 for ; Sun, 3 May 2020 15:04:38 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from [10.70.7.24] ([10.70.7.24]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id 043F4bUx001392 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 3 May 2020 15:04:37 GMT (envelope-from list1@gjunka.com) Subject: Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371 To: freebsd-current@freebsd.org References: <8df5a5cd4ac5bd9e10516c1321ea2de2@udns.ultimatedns.net> <20200503090552.36bfe99c@ernst.home> <20200503161330.621850a7@ernst.home> From: Grzegorz Junka Message-ID: <0f222d54-99be-322d-ec73-ccb3740d677b@gjunka.com> Date: Sun, 3 May 2020 16:04:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200503161330.621850a7@ernst.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 49FTmR1bc4z3JY2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list1@gjunka.com designates 88.98.225.149 as permitted sender) smtp.mailfrom=list1@gjunka.com X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.98.225.149:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[gjunka.com]; IP_SCORE(-3.57)[ip: (-9.37), ipnet: 88.98.192.0/18(-4.68), asn: 56478(-3.75), country: GB(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:56478, ipnet:88.98.192.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:04:39 -0000 On 03/05/2020 15:13, Gary Jennejohn wrote: > On Sun, 3 May 2020 14:11:09 +0100 > Grzegorz Junka wrote: > >> I don't have a partition that I could use for swap. I have two whole >> disks added to ZFS. Maybe on the boot drive but that would require >> repartitioning and I have Windows/FreeBSD there, so not so straightforward. >> > As the dumpon man pages states, by the time a crash dump is needed the > files systems are dead. No way to dump to a ZFS file system. That's > why a raw partition is required. > > The other option would be netdump. See the dumpon man page. > I will consider a separate partition next time I partition my disk. For now I will have to ignore panics and dumps. I tried netdump and it didn't work - it couldn't ARP the netmapd server. --GrzegorzJ From owner-freebsd-current@freebsd.org Sun May 3 15:38:10 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 74DD32E05C7 for ; Sun, 3 May 2020 15:38:10 +0000 (UTC) (envelope-from nonameless@ukr.net) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FVW53T56z3KvV for ; Sun, 3 May 2020 15:38:09 +0000 (UTC) (envelope-from nonameless@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tt42P0Zvr9+bApZvWbmXDXeXrA2RJyFe70eK+5ctp9o=; b=TFeKlFmSnuzfx5sN4ShdwhRQlR FV6a8zSPK4MCmPgnS5lw9I2butpPo1GW8pQopLG6DLCvErOd9ZelUf6trmgY9xhBAvy+V9nBwe4xV 9cEUqNZc1Lg93JqeRRGaiB2iLebjCW9E3b8WQrHpfHkgf+fgcTtViVYVcxUATlkyfGX8=; Received: from [10.10.80.23] (helo=frv55.fwdcdn.com) by frv190.fwdcdn.com with smtp ID 1jVGgr-000DWA-6n for freebsd-current@freebsd.org; Sun, 03 May 2020 18:38:01 +0300 Date: Sun, 03 May 2020 18:38:01 +0300 From: nonameless@ukr.net Subject: Re[2]: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Received: from nonameless@ukr.net by frv55.fwdcdn.com; Sun, 03 May 2020 18:38:01 +0300 In-Reply-To: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> X-Reply-Action: reply Message-Id: <1588519871.700235000.j9rwguqu@frv55.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 49FVW53T56z3KvV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=TFeKlFmS; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of nonameless@ukr.net designates 212.42.77.190 as permitted sender) smtp.mailfrom=nonameless@ukr.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.88), asn: 8856(-3.91), country: UA(0.07)]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[ukr.net]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24:c]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; FROM_NO_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:38:10 -0000 --- Original message --- From: "Mark Millard"  Date: 3 May 2020, 17:38:14 > > > On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > > > > > > --- Original message --- > > From: "Mark Millard" > > Date: 3 May 2020, 04:47:14 > > > > > > > >> [I'm only claiming the new jemalloc is involved and that > >> reverting avoids the problem.] > >> > >> I've been reporting to some lists problems with: > >> > >> dhclient > >> sendmail > >> rpcbind > >> mountd > >> nfsd > >> > >> getting SIGSEGV (signal 11) crashes and some core > >> dumps on the old 2-socket (1 core per socket) 32-bit > >> PowerMac G4 running head -r360311">360311. > >> > >> Mikaël Urankar sent a note suggesting that I try > >> testing reverting head -r360233">360233 for my head -r360311">360311 > >> context. He got it right . . . > >> > >> > >> Context: > >> > >> The problem was noticed by an inability to have > >> other machines do a: > >> > >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt > >> > >> sort of operation and to have succeed. By contrast, on > >> the old PowerMac G4 I could initiate mounts against > >> other machines just fine. > >> > >> I do not see any such problems on any of (all based > >> on head -r360311): > >> > >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > >> armv7 (OrangePi+ 2ed) > >> aarch64 (Rock64, RPi4, RPi3, > >> OverDrive 1000">1000, > >> Macchiatobin Double Shot) > >> amd64 (ThreadRipper 1950X) > >> > >> So I expect something 32-bit powerpc specific > >> is somehow involved, even if jemalloc is only > >> using whatever it is. > >> > >> (A kyua run with a debug kernel did not find other > >> unexpected signal 11 sources on the 32-bit PowerMac > >> compared to past kyua runs, at least that I noticed. > >> There were a few lock order reversals that I do not > >> know if they are expected or known-safe or not. > >> I've reported those reversals to the lists as well.) > >> > >> > >> Recent experiments based on the suggestion: > >> > >> Doing the buildworld, buildkernel and installing just > >> the new kernel and rebooting made no difference. > >> > >> But then installing the new world and rebooting did > >> make things work again: I no longer get core files > >> for the likes of (old cores from before the update): > >> > >> # find / -name "*.core" -print > >> /var/spool/clientmqueue/sendmail.core > >> /rpcbind.core > >> /mountd.core > >> /nfsd.core > >> > >> Nor do I see the various notices for sendmail > >> signal 11's that did not leave behind a core file > >> --or for dhclient (no core file left behind). > >> And I can mount the old PowerMac's drive from > >> other machines just fine. > >> > >> > >> Other notes: > >> > >> I do not actively use sendmail but it was left > >> to do its default things, partially to test if > >> such default things are working. Unfortunately, > >> PowerMacs have a problematical status under > >> FreeBSD and my context has my historical > >> experiments with avoiding various problems. > >> > >> === > >> Mark Millard > >> marklmi at yahoo.com > >> ( dsl-only.net went > >> away in early 2018">2018-Mar) > >> > > > > Hi Mark, > > > > It should be fixed, but not by reverting to old version. We can't stuck on old version because of ancient hardware. I think upstream is not interested in support such hardware. So, it have to patched locally. > > Observing and reporting the reverting result is an initial > part of problem isolation. I made no request for FreeBSD > to give up on using the updated jemalloc. (Unfortunately, > I'm not sure what a good next step of problem isolation > might be for the dual-socket PowerMac G4 context.) > > Other than reverting, no patch is known for the issue at > this point. More problem isolation is needed first. > > While I do not have access, https://wiki.freebsd.org/powerpc > lists more modern 32-bit powerpc hardware as supported: > MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). > (The AmigaOne A1222 seems to be dual-ore/single-socket.) > > So folks with access to one of those may want to see > if they also see the problem(s) with head -r360233 or > later. > > Another interesting context to test could be single-socket > with just one core. (I might be able to do that on another > old PowerMac, booting the same media after moving the > media.) > > If I understand right, the most common 32-bit powerpc > tier 2 hardware platforms may still be old PowerMac's. > They are considered supported and "mature", instead of > just "stable". See https://wiki.freebsd.org/powerpc . > However, the reality is that there are various problems > for old PowerMacs (32-bit and 64-bit, at least when > there is more than one socket present). The wiki page > does not hint at such. (I'm not sure about > single socket/multi-core PowerMacs: no access to > such.) > > It is certainly possible for some problem to happen > that would lead to dropping the supported-status > for some or all old 32-bit PowerMacs, even as tier 2. > But that has not happened yet and I'd have no say in > such a choice. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Just don't want to see again previous situation when jemalloc was committed, then reverted and was forgotten for six months. From owner-freebsd-current@freebsd.org Sun May 3 16:04: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 AF2682E15EA for ; Sun, 3 May 2020 16:04:15 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from 44-233-67-66-mail.ore.mailhop.org (44-233-67-66-mail.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49FW5C1g08z3N7y for ; Sun, 3 May 2020 16:04:15 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1588521848; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=h9vUdTbiYZ6iZGZR4b+dJkgCfl3R6G/A/VeKjgvXfgFxWyhy1XHiFV1ToNEdBh6cTj2ZFE+HXVD0N ghzyMaJgWVgyU6pG6bwNJ0xgOvYBe3Jcj2dAZjsJx2oGHEaRN3AL6uu2mYTg1ogYHES1yglyopvGqV bdL6VXyAiNjdPRFHt8Zy7Rlqtz/MDeivXhzSWmjBbrq2rc1cUmchTAxJAHMAKsCgsdY2H6ro93LzMO UzbA4iR3xJIa5rBtOTfOrKVGfXwZ3yN/EG5bK11b9sUNS8ry7mdvvaFFKMgb8fXxshb1aISyrlJNaK m4e6O4giY1CoHy01fL9UKz58qnPv70Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=wOQ+nFvnqrygpWHDC8wrLV1cmNPPobp0XkcOXNZUhv4=; b=jxEwGM5nw0y+zFetr4/xCsmWWg5xoFV8ZVHohQ5iUSjsLsN8X25ZX8dbfj9WLLKskz4Z7mo+INItN F/uyATznOiiGL1CFrk53MM4d945kWu2fBGg7UQuVEjHRO3TPc0VQlE027C9RRutxT1gapM1rkwfoNi 4v0CrMDLCEdcxhIupKztdbDurESK8F1PLcvTIQzouztBtrhmTz22AuVjaGVslF7goPLCtQPSzCQrrk 8Eosz6AcNCEMBw8nWpfeld/XMKFX2Y+lszyhJOM1IVRz9daceJmIcsmNbqmT0VBXaNhvVg/kaXhuGH MvdHXN1m5Jevre4be4oLnmVFs0rHl+A== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=wOQ+nFvnqrygpWHDC8wrLV1cmNPPobp0XkcOXNZUhv4=; b=w6wjIceXo4VhX07a/DxSNOr986dCNWug1H0PhsQOk81vLs4dcqO46gnI/V/J7RJxZ2k6pc5Gm/cuN z94o1C9N9LvMaBiG8SuWb7kjIfNHV2P8g1s6cqFHyqSkZYN376BHkd1WjNFdqVCp2vlBR6tOJznEjO v6gNTm3VepJivTPVv77Yplj4iSmd0vIwBVe4eHPbiZaeWJX0yOU0AMUfUQ64u+RU9VOFMQOvzMeVP0 o12Cs1NiEv1DdRCo7aKqZX7QrWAm5tRLYPJWEMbk8VezZ8NRHfXHpCORTV4++2PyLOWpBOYEllE/Mf n/Ps+oJMgQCuMitDRb5Mfga1jGo1ANA== X-MHO-RoutePath: aGlwcGll X-MHO-User: b694888b-8d57-11ea-b10c-b5956a7dd1a1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id b694888b-8d57-11ea-b10c-b5956a7dd1a1; Sun, 03 May 2020 16:04:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 043G44q0042973; Sun, 3 May 2020 10:04:04 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: lock order reversal and poudriere From: Ian Lepore To: Kurt Jaeger , Grzegorz Junka Cc: bzeeb+freebsd+lor@zabbadoz.net, freebsd-current@freebsd.org Date: Sun, 03 May 2020 10:04:04 -0600 In-Reply-To: <20200502183634.GA90255@fc.opsec.eu> References: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> <20200502095404.GN39563@home.opsec.eu> <20200502183634.GA90255@fc.opsec.eu> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49FW5C1g08z3N7y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.94 / 15.00]; TAGGED_RCPT(0.00)[freebsd,lor]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.96)[-0.961,0]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US]; NEURAL_HAM_LONG(-0.98)[-0.980,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 16:04:15 -0000 On Sat, 2020-05-02 at 20:36 +0200, Kurt Jaeger wrote: > Hi! > > > > > I am compiling some packages with poudriere on 13-current kernel. I > > > > noticed some strange messages printed into the terminal and dmesg: > > > > > > > > lock order reversal: > > > > > > [...] > > > > Are those the debug messages that aren't visible on non-current kernel > > > > and should they be reported? > > > > > > Yes, they should be checked and reported. > > > > > > For more details see: > > > > > > http://sources.zabbadoz.net/freebsd/lor.html > > > > > > There's a webpage with a list of all known LORs and a way to > > > report new LORs. > > Thanks Kurt. I can't find those two specific LORs in the list on that > > page. The page also says to report them using a link, which leads to 404 > > :-), or on this mailing list, which I did. I am not sure what else should > > I do. > > I don't know, either 8-} bz@ is in Cc:, so he'll probably know what > to do. > That LOR site hasn't been updated in years. Many many years. The sad truth appears to be that nobody cares about LORs anymore. The same ones have been there for years. Nobody fixes them, nobody does anything to suppress reporting them. We just keep pointing new users to a dead website because that has always been the only response available. > > How do I know if I have got a backtrace? > > > > Are those errors: > > > > pid 43297 (conftest), jid 5, uid 0: exited on signal 11 > > > > related or it's a different issue? > > I think that's a different issue. > Segfaults and other problems with a program named "conftest" while building ports is normal. Autotools' configure script writes and runs programs named conftest to detect the presence or absence of features or bugs. That doesn't mean every failure of a program named conftest is normal and expected, but in general it's not a thing to worry about. -- Ian From owner-freebsd-current@freebsd.org Sun May 3 17:44: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 9E7432E3B1A for ; Sun, 3 May 2020 17:44:53 +0000 (UTC) (envelope-from grahamperrin@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FYKJ5cjWz40Pv for ; Sun, 3 May 2020 17:44:52 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id x18so18166473wrq.2 for ; Sun, 03 May 2020 10:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=nC/gzxhqd0cCcaW6JtV4qhZFfub/b7oM3ZFPG3ky34M=; b=O45W65//AQ2e9CZlJiWIdkGl/HqCV/GFjCN645+5W3WoIFQDOOJVoRNB6+ed8KzHzk jQZ0LN8XTwOMyIs1/yZcGm24ZNICj5t4VAWVt2DF21PiWT51NaYuHj9t2T9ZQn7L+fL0 l4gtsMem4TLrWiC1PiLUD86j4P2bniQw1ilbM5Yj6QUwc7pneMKopuNK3pTiNxT50BN2 Ul3iVVyUE0eR4k28yKykkC+mTtIPWNS9XlH38Z6LaWHxr2wXuX9VhBMuDtk8wYC2g7Pz XzCtVmnOwGNTaEHZSJKKdEWxr4t8aw6aBIoI6c1Yh1pVlywYmpID+hc/LVnZOVqbKtwf 6fPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nC/gzxhqd0cCcaW6JtV4qhZFfub/b7oM3ZFPG3ky34M=; b=TBSjOltlpzpzgn4fIMK935Q86l8ByCaYqNI0sL+8M3kX9LOb5E3U5IH0x9cUO3S4jS hRMMWobGy0XghMs/hXu2A7d3NHnoKSGijdCeOUFaHlif8hZshC0vo0KOfHUP3xNlXQy1 +lpFcJG8+C5tjPaUlTrJZ4qM0sc+EGv9DbNWBnIlQcxfpmy1f/0PSrcM97b0eRtkWbXA eHj+IIR4UIbMJY3NqYFOutX25Y+JbPGZdE63dL+NaT3frTeasNtE5rJZrxZMMc9iyvwz xU+d8x+W8CUMc+CDuA/Z7TgZJRmL4VyAta8AFd20HS22MjQ1RCDfkSikyniyxav8kMBO bM2w== X-Gm-Message-State: AGi0PuY655V2ikX9F1Rx2/+q78Xp1s9urK/4ifoUJPs6NyAr6b613q6F +SINt4jfWr0o9fWfd8XGsG++0DiwDL4= X-Google-Smtp-Source: APiQypJMq4sRgXsugnumyhOBtlE6505ic+txXS8r+ZumhNbfU62n/t48UVfGpVo+49Z/dN0w/N8xsw== X-Received: by 2002:a5d:6b8a:: with SMTP id n10mr14407219wrx.36.1588527890405; Sun, 03 May 2020 10:44:50 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id a1sm15016311wrn.80.2020.05.03.10.44.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 10:44:49 -0700 (PDT) Subject: Re: beadm no longer able to destroy, maybe since using OpenZFS From: Graham Perrin To: freebsd-current@freebsd.org References: <8e30bce4-e740-2d8b-24dd-b73471bf0fab@gmail.com> Message-ID: <7bd898ec-7e56-959d-48a5-6cfea4561602@gmail.com> Date: Sun, 3 May 2020 18:44:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8e30bce4-e740-2d8b-24dd-b73471bf0fab@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 49FYKJ5cjWz40Pv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=O45W65//; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+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.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.147.66.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; 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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.34), ipnet: 2a00:1450::/32(-2.31), asn: 15169(-0.43), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[2.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 17:44:53 -0000 On 03/05/2020 06:05, Graham Perrin wrote: > After reverting from OpenZFS to ZFS, I was able to destroy two of the > boot environments that previously (below, 1st May, OpenZFS) could not > be destroyed. > > I'm left with at least one BE 'r360237c' that can not be destroyed. Is > it ever normal to find a snapshot described as '-'? > > root@momh167-gjp4-8570p:~ # kldstat | grep zfs >  2    1 0xffffffff82109000   3a8b40 zfs.ko > root@momh167-gjp4-8570p:~ # date > Sun May  3 05:59:06 BST 2020 … > root@momh167-gjp4-8570p:~ # beadm destroy r360237c > Are you sure you want to destroy 'r360237c'? > This action cannot be undone (y/[n]): y > Boot environment 'r360237c' was created from existing snapshot > Destroy '-' snapshot? (y/[n]): y > cannot destroy 'copperbowl/ROOT/r360237c': filesystem has dependent > clones > use '-R' to destroy the following datasets: > copperbowl/ROOT/r360237e@2020-05-01-17:58:33 > copperbowl/ROOT/r360237e > copperbowl/ROOT/r357746h > copperbowl/ROOT/Waterfox … I temporarily activated (but did not boot from) an older environment BE r357746h, then created and activated r360237f. Then the previously indestructible r360237c was destroyed successfully: ---- root@momh167-gjp4-8570p:~ # beadm list -as BE/Dataset/Snapshot                            Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                     -      - 314.0M 2020-03-10 18:24     r360237f@2020-03-20-06:19:45               -      - 1.0G 2020-03-20 06:19 r357746h   copperbowl/ROOT/r357746h                     -      - 3.4M 2020-04-08 09:28     r360237f@2020-04-09-17:59:32               -      - 1.1G 2020-04-09 17:59 r360237c   copperbowl/ROOT/r360237c                     -      - 17.0M 2020-04-29 13:24     r360237f@2020-04-29-13:24:52               -      - 229.0M 2020-04-29 13:24 r360237e   copperbowl/ROOT/r360237e                     N      / 680.0K 2020-05-01 17:58     r360237f@2020-05-03-18:30:25               -      - 440.0K 2020-05-03 18:30 r360237f   copperbowl/ROOT/r360237f@2020-03-20-06:19:45 -      - 1.0G 2020-03-20 06:19   copperbowl/ROOT/r360237f@2020-04-09-17:59:32 -      - 1.1G 2020-04-09 17:59   copperbowl/ROOT/r360237f@2020-04-29-13:24:52 -      - 229.0M 2020-04-29 13:24   copperbowl/ROOT/r360237f@2020-05-01-17:58:33 -      - 162.0M 2020-05-01 17:58   copperbowl/ROOT/r360237f                     R      - 81.7G 2020-05-03 18:30   copperbowl/ROOT/r360237f@2020-05-03-18:30:25 -      - 440.0K 2020-05-03 18:30 root@momh167-gjp4-8570p:~ # date ; uname -v ; uptime Sun May  3 18:32:31 BST 2020 FreeBSD 13.0-CURRENT #54 r360237: Fri Apr 24 09:10:37 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  6:32PM  up 12:54, 5 users, load averages: 0.48, 0.44, 0.41 root@momh167-gjp4-8570p:~ # kldstat | grep zfs  2    1 0xffffffff82109000   3a8b40 zfs.ko root@momh167-gjp4-8570p:~ # beadm destroy r360237c Are you sure you want to destroy 'r360237c'? This action cannot be undone (y/[n]): y Destroyed successfully root@momh167-gjp4-8570p:~ # zfs destroy copperbowl/ROOT/r360237f@2020-03-20-06:19:45 cannot destroy 'copperbowl/ROOT/r360237f@2020-03-20-06:19:45': snapshot has dependent clones use '-R' to destroy the following datasets: copperbowl/ROOT/Waterfox root@momh167-gjp4-8570p:~ # zfs destroy copperbowl/ROOT/r360237f@2020-04-09-17:59:32 cannot destroy 'copperbowl/ROOT/r360237f@2020-04-09-17:59:32': snapshot has dependent clones use '-R' to destroy the following datasets: copperbowl/ROOT/r357746h root@momh167-gjp4-8570p:~ # zfs destroy copperbowl/ROOT/r360237f@2020-05-01-17:58:33 root@momh167-gjp4-8570p:~ # beadm list -as BE/Dataset/Snapshot                            Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                     -      - 314.0M 2020-03-10 18:24     r360237f@2020-03-20-06:19:45               -      - 1.0G 2020-03-20 06:19 r357746h   copperbowl/ROOT/r357746h                     -      - 3.4M 2020-04-08 09:28     r360237f@2020-04-09-17:59:32               -      - 1.1G 2020-04-09 17:59 r360237e   copperbowl/ROOT/r360237e                     N      / 756.0K 2020-05-01 17:58     r360237f@2020-05-03-18:30:25               -      - 440.0K 2020-05-03 18:30 r360237f   copperbowl/ROOT/r360237f@2020-03-20-06:19:45 -      - 1.0G 2020-03-20 06:19   copperbowl/ROOT/r360237f@2020-04-09-17:59:32 -      - 1.1G 2020-04-09 17:59   copperbowl/ROOT/r360237f                     R      - 80.9G 2020-05-03 18:30   copperbowl/ROOT/r360237f@2020-05-03-18:30:25 -      - 440.0K 2020-05-03 18:30 root@momh167-gjp4-8570p:~ # bectl list -as BE/Dataset/Snapshot                              Active Mountpoint Space Created Waterfox   copperbowl/ROOT/Waterfox                       -      - 314M  2020-03-10 18:24 r357746h   copperbowl/ROOT/r357746h                       -      - 3.44M 2020-04-08 09:28 r360237e   copperbowl/ROOT/r360237e                       N      / 764K  2020-05-01 17:58 r360237f   copperbowl/ROOT/r360237f                       R      - 80.9G 2020-05-03 18:30   r360237f@2020-03-20-06:19:45                   -      - 1.02G 2020-03-20 06:19   r360237f@2020-04-09-17:59:32                   -      - 1.15G 2020-04-09 17:59   r360237f@2020-05-03-18:30:25                   -      - 440K  2020-05-03 18:30 root@momh167-gjp4-8570p:~ # From owner-freebsd-current@freebsd.org Sun May 3 18:08: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 894DA2E4476 for ; Sun, 3 May 2020 18:08:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 49FYrf4GwXz41sZ for ; Sun, 3 May 2020 18:08:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1oX6N4AVM1kMEt_vPxuFXH9vEhh1wYomaWReYDYjULLXvDflLYHJiezPy_PUB3r JgJ0FHTSFm9MJZ9RL7pKFvscGotD95w45Lba1uwxAPX0Wz4YlbPdRn76Vrzg2lrQF51vIBEM7Iia NtbtlW_Brm6UT1HX7GAtvzWR80EFMGGGz2IxTYxbUKsbNO2ZRCU.f7yLKWTl_GZx2MjtpW4oU77B UiaQwBSwN7TgKBWI0FcwPinkrOZioD.XUQS24i_ACCIdPVccgJUNR8vCHdhGTVTHM.9.DUcXfGX8 U1EBvDfBOBt8hVIgi7KdHHjVU8qK53uLEnnQeqx0Wc7aZ7Bu3ZQZjJUKo253ddI0xW08i6kp0MVt rXUeUXRHukehLn.2svajv90uPVWzeBV4.FRx1_ym85CCzZGUJ3QOLJUH_NNylGBkZfa5eP2VV9EE APhM0cZ8o8GNrHPvulT6lqSZLjWRLoKAIEAVt6fhyiKTQhN6lDc57o6AOVSbvrQdNbXKdqfA8smm OzCws63s9R_LMSjL7q6Yn8WYHxI5pWPfxFSR6TKRNJkocJ6cEttlSIJn.haWkabQCA5pBCI3_Ss7 oeipxHzpQJnl6cSKFNyxWUSbw8TQXnp1B8oqfofzH3MaISfml7ksJqzW.zPuOOrtgYESFCO2kw2V giR6umdL5MEF4fVQWZvBBsZRxDDh5RPFWK.fOKr51txJw1oHcK8j.1.KmcsQ.bxdHtIPV6RQK5vV 0bv9z_3qG_CEdWLIIswO34W.T22RRVUEvT0NCKEX5nFvLXJtHBh7Ij9055ZqSnK71IUTgL5MdgBv 7LLCwL598HOfs27rntQDl5lRfmSFULqFuKYrOie4.iAehxD0l9Gb76eM4v2rkPUt6wQNxn_HvY0v vEoIFxL9sJK.bU5Cop21fIF48lhB0c9eeIe6T2rTGPAY_Rya22MA6FxI7zMURQe7iH73fWgog9Od dWh1E8H3HvlCjHqf_QmDXGaznD2j1n6H5zpMarpY_eIk97qicL.UfrSYXGksHBsHxEL4NOCJXPMZ 4i.qz.tdb0MG1zZf38.LFrGUmHJlDFnr_O2Mt6abokrw9_v.jIuqIyoFGUJK8wxmr_kAh9yqbja2 fH3uW9lcyP_JkGP3STEX0NSBUiQKuyGxVk_kt7Msz7307g2Pn2yA3fG0XROxErkhR2X8HIMrIPM0 u9x9LaIXJz6.EHoNO.QTcl4Zf52KxOklCmQO3cNV1zJTmH5E3ldU_1QdQ8wKM7PSY4kSoYOQGpWV M4NVExzZ6bpbUXH1bLcgyl2aRFzL._Bcp1A9nJ5R_H.HuZPrxw82zeVlbpm6jGsJjpjgu158aKYY hgVzf3kpsPO1ZCcnQDyt7PAX.R1Y6WzJA6ThHJYtKSA3r5ISa_p..VDrk6zTkQM.GWvpzHCbjlU1 eNJ3xXdJdnvZlnifZo2xn.vGythTSa3G1APVLxceufCV1EwU56ZaikDdf6WDJj9RHmsc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 18:08:32 +0000 Received: by smtp422.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 233fcb4833509f60a9288f2901074f87; Sun, 03 May 2020 18:08:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Sun, 3 May 2020 11:08:27 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> References: To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FYrf4GwXz41sZ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.71), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 18:08:36 -0000 [At around 4AM local time dhcient got a signal 11, despite the jemalloc revert. The other exmaples have not happened.] On 2020-May-2, at 18:46, Mark Millard wrote: > [I'm only claiming the new jemalloc is involved and that > reverting avoids the problem.] >=20 > I've been reporting to some lists problems with: >=20 > dhclient > sendmail > rpcbind > mountd > nfsd >=20 > getting SIGSEGV (signal 11) crashes and some core > dumps on the old 2-socket (1 core per socket) 32-bit > PowerMac G4 running head -r360311. >=20 > Mika=C3=ABl Urankar sent a note suggesting that I try > testing reverting head -r360233 for my head -r360311 > context. He got it right . . . >=20 >=20 > Context: >=20 > The problem was noticed by an inability to have > other machines do a: >=20 > mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >=20 > sort of operation and to have succeed. By contrast, on > the old PowerMac G4 I could initiate mounts against > other machines just fine. >=20 > I do not see any such problems on any of (all based > on head -r360311): >=20 > powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > armv7 (OrangePi+ 2ed) > aarch64 (Rock64, RPi4, RPi3, > OverDrive 1000, > Macchiatobin Double Shot) > amd64 (ThreadRipper 1950X) >=20 > So I expect something 32-bit powerpc specific > is somehow involved, even if jemalloc is only > using whatever it is. >=20 > (A kyua run with a debug kernel did not find other > unexpected signal 11 sources on the 32-bit PowerMac > compared to past kyua runs, at least that I noticed. > There were a few lock order reversals that I do not > know if they are expected or known-safe or not. > I've reported those reversals to the lists as well.) >=20 >=20 > Recent experiments based on the suggestion: >=20 > Doing the buildworld, buildkernel and installing just > the new kernel and rebooting made no difference. >=20 > But then installing the new world and rebooting did > make things work again: I no longer get core files > for the likes of (old cores from before the update): >=20 > # find / -name "*.core" -print > /var/spool/clientmqueue/sendmail.core > /rpcbind.core > /mountd.core > /nfsd.core >=20 > Nor do I see the various notices for sendmail > signal 11's that did not leave behind a core file > --or for dhclient (no core file left behind). > And I can mount the old PowerMac's drive from > other machines just fine. >=20 >=20 > Other notes: >=20 > I do not actively use sendmail but it was left > to do its default things, partially to test if > such default things are working. Unfortunately, > PowerMacs have a problematical status under > FreeBSD and my context has my historical > experiments with avoiding various problems. Looking, I see that I got a: pid 572 (dhclient), jid 0, uid 0: exited on signal 11 (core dumped) notice under the reverted build. No instances of the other examples. This is the first that a dhclient example has produced a .core file. gdb indicates 0x5180936c for r7 in: lwz r8,36(r7) as leading to the failure. This was in arena_dalloc_bin_locked_impl (where arena_slab_reg_dalloc and bitmap_unset were apparently inlined). The chain for the example seems to be: fork_privchld -> dispatch_imsg -> jemalloc For reference . . . # gdb dhclient /dhclient.core=20 GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from dhclient... Reading symbols from /usr/lib/debug//sbin/dhclient.debug... [New LWP 100089] Core was generated by `dhclient: gem0 [priv]'. Program terminated with signal SIGSEGV, Segmentation fault. #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= 341 = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h: = No such file or directory. (gdb) bt -full #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= goff =3D gp =3D 0x51809390 propagate =3D g =3D i =3D #1 arena_slab_reg_dalloc (slab=3D0x50407140, slab_data=3D0x50407164, = ptr=3D0x50088b50) at jemalloc_arena.c:273 bin_info =3D binind =3D 0 regind =3D 167842154 #2 arena_dalloc_bin_locked_impl (tsdn=3D0x5009f018, arena=3D, slab=3D, ptr=3D, junked=3D) at jemalloc_arena.c:1540 slab_data =3D binind =3D bin_info =3D bin =3D nfree =3D #3 0x502916a8 in __je_arena_dalloc_bin_junked_locked (tsdn=3D, arena=3D, extent=3D, ptr=3D) at jemalloc_arena.c:1559 No locals. #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 ptr =3D i =3D 0 extent =3D 0x50407140 bin_arena =3D 0x50400380 bin =3D ndeferred =3D 0 merged_stats =3D arena =3D 0x50400380 nflush =3D 75 __vla_expr0 =3D item_extent =3D 0xffffd1f0 #5 0x502508a0 in __je_tcache_event_hard (tsd=3D, = tcache=3D0x5009f108) at jemalloc_tcache.c:54 tbin_info =3D binind =3D 7 tbin =3D 0x5009f1c0 #6 0x5029a684 in __free (ptr=3D0x500530c0) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/rtree.h:374 tcache =3D 0x5009f108 tsd =3D log_var =3D log_var =3D #7 0x10025994 in dispatch_imsg (ifix=3D, fd=3D10) at = /usr/powerpc32_src/sbin/dhclient/privsep.c:215 hdr =3D {code =3D IMSG_SCRIPT_WRITE_PARAMS, len =3D 3225} lease =3D {next =3D 0x0, expiry =3D 1588504529, renewal =3D = 1588504229, rebind =3D 1588504454, address =3D {len =3D 4, iabuf =3D = "\300\250\001i", '\000' }, nextserver =3D {len =3D 4,=20= iabuf =3D '\000' }, server_name =3D 0x0, = filename =3D 0x0, medium =3D 0x0, is_static =3D 0, is_bootp =3D 0, = options =3D {{len =3D 0, data =3D 0x0}, {len =3D 4,=20 data =3D 0x500530c8 "\377\377\377"}, {len =3D 0, data =3D = 0x0}, {len =3D 4, data =3D 0x500530d0 "\300\250\001\001"}, {len =3D 0, = data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 4,=20 data =3D 0x500530d8 "\300\250\001\001"}, {len =3D 0, data = =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D = 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, = { len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len = =3D 20, data =3D 0x50055200 "hsd1.or.comcast.net."}, {len =3D 0, data =3D = 0x0} , {len =3D 4, data =3D 0x500530e0 ""}, {len =3D = 0,=20 data =3D 0x0}, {len =3D 1, data =3D 0x500530e8 "\005"}, = {len =3D 4, data =3D 0x500530f0 "\300\250\001\001"}, {len =3D 0, data =3D = 0x0} }} medium_len =3D medium =3D totlen =3D 3225 filename_len =3D filename =3D 0x0 ret =3D buf =3D mtu =3D servername_len =3D servername =3D 0x0 reason_len =3D reason =3D --Type for more, q to quit, c to continue without paging-- prefix_len =3D prefix =3D 0x500530c0 "new_" i =3D 0 optlen =3D 0 #8 0x100189f4 in fork_privchld (fd=3D10, fd2=3D) at = /usr/powerpc32_src/sbin/dhclient/dhclient.c:2847 pfd =3D {{fd =3D 10, events =3D 1, revents =3D 1}} nfds =3D #9 0x10017a80 in main (argc=3D, argv=3D) = at /usr/powerpc32_src/sbin/dhclient/dhclient.c:505 pipe_fd =3D {10, 11} rights =3D {cr_rights =3D {1342801412, 18446706484155777024}} immediate_daemon =3D 0 i =3D 0 ch =3D otherpid =3D 8 pw =3D 0x5039b9d8 fd =3D capmode =3D (gdb) disass Dump of assembler code for function arena_dalloc_bin_locked_impl: 0x502916b8 <+0>: mflr r0 0x502916bc <+4>: stw r0,4(r1) 0x502916c0 <+8>: stwu r1,-48(r1) 0x502916c4 <+12>: stw r30,40(r1) 0x502916c8 <+16>: stw r24,16(r1) 0x502916cc <+20>: stw r25,20(r1) 0x502916d0 <+24>: stw r26,24(r1) 0x502916d4 <+28>: stw r27,28(r1) 0x502916d8 <+32>: stw r28,32(r1) 0x502916dc <+36>: stw r29,36(r1) 0x502916e0 <+40>: bl 0x502916e4 = 0x502916e4 <+44>: mr r27,r3 0x502916e8 <+48>: mflr r30 0x502916ec <+52>: addis r30,r30,14 0x502916f0 <+56>: addi r30,r30,7788 0x502916f4 <+60>: mr r28,r4 0x502916f8 <+64>: lwz r4,5856(r30) 0x502916fc <+68>: lwz r3,4(r5) 0x50291700 <+72>: mr r29,r5 0x50291704 <+76>: andi. r5,r7,1 0x50291708 <+80>: mr r26,r6 0x5029170c <+84>: lbz r4,0(r4) 0x50291710 <+88>: rlwinm r5,r3,14,25,31 0x50291714 <+92>: mulli r24,r5,224 0x50291718 <+96>: mulli r25,r5,44 0x5029171c <+100>: cmpwi cr1,r4,0 0x50291720 <+104>: cror 4*cr5+lt,4*cr1+eq,gt 0x50291724 <+108>: bge cr5,0x50291a2c = 0x50291728 <+112>: lwz r4,0(r29) 0x5029172c <+116>: lwz r6,6036(r30) 0x50291730 <+120>: lwz r7,8(r29) 0x50291734 <+124>: rlwinm r8,r5,2,0,29 0x50291738 <+128>: li r9,1 0x5029173c <+132>: add r24,r28,r24 0x50291740 <+136>: lwzx r6,r6,r8 0x50291744 <+140>: subf r7,r7,r26 0x50291748 <+144>: mulhwu r6,r6,r7 0x5029174c <+148>: rlwinm r7,r6,29,3,29 0x50291750 <+152>: add r7,r29,r7 =3D> 0x50291754 <+156>: lwz r8,36(r7) 0x50291758 <+160>: clrlwi r10,r6,27 0x5029175c <+164>: slw r9,r9,r10 0x50291760 <+168>: xor r9,r9,r8 0x50291764 <+172>: cmplwi r8,0 0x50291768 <+176>: stw r9,36(r7) 0x5029176c <+180>: bne 0x502917e4 = 0x50291770 <+184>: lwz r7,4408(r30) 0x50291774 <+188>: mulli r8,r5,44 0x50291778 <+192>: add r5,r7,r8 0x5029177c <+196>: lwz r5,16(r5) 0x50291780 <+200>: cmplwi r5,2 0x50291784 <+204>: blt 0x502917e4 = msr cr 0x42480c00 1112017920 lr 0x502916e4 0x502916e4 = ctr 0x5005d114 1342558484 xer 0x0 0 fpscr 0x0 0 vscr vrsave =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun May 3 18:16: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 B21562E49F3 for ; Sun, 3 May 2020 18:16:26 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FZ1k339Tz42f9; Sun, 3 May 2020 18:16:26 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id A171C13E42; Sun, 3 May 2020 18:16:25 +0000 (UTC) Date: Sun, 3 May 2020 18:16:24 +0000 From: Mark Linimon To: Ian Lepore Cc: Kurt Jaeger , Grzegorz Junka , bzeeb+freebsd+lor@zabbadoz.net, freebsd-current@freebsd.org Subject: Re: lock order reversal and poudriere Message-ID: <20200503181624.GB3224@lonesome.com> References: <68514e96-f1a5-0c8d-998f-bf81034ed61d@gjunka.com> <20200502095404.GN39563@home.opsec.eu> <20200502183634.GA90255@fc.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 49FZ1k339Tz42f9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-1.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.928,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.15)[ip: (0.04), ipnet: 18.220.0.0/14(0.21), asn: 16509(-0.96), country: US(-0.05)]; TAGGED_RCPT(0.00)[freebsd,lor]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.94)[-0.938,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 18:16:26 -0000 On Sun, May 03, 2020 at 10:04:04AM -0600, Ian Lepore wrote: > That LOR site hasn't been updated in years. Many many years. If someone wants to help me set up a page on the wiki, let me know. (I have too much on my plate to do it myself.) mcl From owner-freebsd-current@freebsd.org Sun May 3 20:11: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 10A4A2E69AD; Sun, 3 May 2020 20:11:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FcZ00WdPz47XW; Sun, 3 May 2020 20:11:03 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id VKx1jF8CcYYpxVKx3jTjFg; Sun, 03 May 2020 14:11:02 -0600 X-Authority-Analysis: v=2.3 cv=OubUNx3t c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=mi56gJdQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=iqZg9Ac-I8Q_iH7sYJkA:9 a=CjuIK1q_8ugA:10 a=m6W23KLcDyq3lIHOBnQi:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 0C5A523A; Sun, 3 May 2020 13:10:59 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 043KAw3G005794; Sun, 3 May 2020 13:10:58 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 043KAwm9005791; Sun, 3 May 2020 13:10:58 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005032010.043KAwm9005791@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Baptiste Daroussin cc: Cy Schubert , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/screen-ncurses port In-reply-to: <20200430130449.cwsf3x42o6w67gor@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> Comments: In-reply-to Baptiste Daroussin message dated "Thu, 30 Apr 2020 15:04:49 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 May 2020 13:10:58 -0700 X-CMAE-Envelope: MS4wfDEyiCzvv5tJZTGpUhsVF+0tU0Hnn3JbFqWTDeA0FC6nOKUHw0OmVFiYb7q7Ja9YdcF7JIUKRYOASslFRxlJ2+oU54d+T4baJCd9OWRkpr4qhX4l5vny yvpM0hSybUKGLX07YHVuigAS1412jzO2a5CECY0sSPT0sA+xcQs3QTTwzF+Mby5x1T+3KZp8ijJakMAE9gWE344rINh/qPlxzHsAYkjYa5vSIEbcaEJjQtBB roDdpHPZuSOt3jQvdkuWNA== X-Rspamd-Queue-Id: 49FcZ00WdPz47XW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.52)[ip: (-6.63), ipnet: 64.59.128.0/20(-3.30), asn: 6327(-2.58), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[138.136.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 20:11:05 -0000 In message <20200430130449.cwsf3x42o6w67gor@ivaldir.net>, Baptiste Daroussin wr ites: > > > --mvhxgm4zl62unzlf > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote: > > In message <20200430075337.3wdzglshhorcd2qn@ivaldir.net>, Baptiste=20 > > Daroussin wr > > ites: > > >=20 > > > > > > --vwrr5drfobpkyvop > > > Content-Type: text/plain; charset=3Dus-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote: > > > > Would people be open to the idea of a sysutils/screen-ncurses port th= > at=3D > > > =3D20 > > > > depends on devel/ncurses instead of ncureses in base? The reason for = > this=3D > > > =3D20 > > > > is there are screen.* terminfo entries in devel/ncurses that don't ex= > ist =3D > > > in=3D20 > > > > termcap(5). People who want that extra functionality would be advised= > to=3D > > > =3D20 > > > > install the alternative pkg or build the sysutils/screen port with th= > e=3D20 > > > > appropriate option. > > > >=3D20 > > > > Or, simply change the default from whatever ncurses is available to a= > lway=3D > > > s=3D20 > > > > install devel/ncurses. People could always select one of the other op= > tion=3D > > > s.=3D20 > > > > Personally, I'm not enamoured with this approach. > > > > > > I think it is a terrible idea, and we should fix the initial problem in= > stea=3D > > > d of > > > workarounding it. > > > > > > 1/ why those are not in our termcap(5) ? they should be added if they a= > re > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice) > >=20 > > I came to this conclusion last night after sending this email thread oud= > =20 > > and will test it some time today. > >=20 > > > > > > 2/ we should allow our base ncurses to get informations from newer term= > cap(=3D > > > 5) if > > > needed. > > > So far the default TERMCAP is > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,.db} > > > > > > First the user can be advise to point configure the $home/.termcap this= > is =3D > > > for > > > quick now. > > that is in your scope via a pkg-message :D > > > > > > > Second for later futur proof mechanism we could modify our termcap read= > er (=3D > > > we > > > use our own, not the one in provided by ncurses). to be able to fetch t= > ermc=3D > > > ap > > > capabilities from /usr/local/share/misc/termcap/*.conf for example > > > > > > This way ports with random termcap info to add would be able to do it w= > itho=3D > > > ut > > > the requirement to wait for a commit in base and a MFC. > >=20 > > This is probably outside of my scope at the moment but, yes, agreed. > >=20 > I will then. > I added that to my TODO There's already a utility in devel/ncurses called infotocap (and its corresponding captoinfo) that already does this. Both are links to tic. Our ncurses import includes tic. Looks like all that's needed is add it to buildworld. I can look at it later tonight. Seems like a quick win. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sun May 3 21:32: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 E02362BA1E2 for ; Sun, 3 May 2020 21:32:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 49FfN849ggz4LRh for ; Sun, 3 May 2020 21:32:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: KnuII7sVM1nfAwvNbPtHtam40Uu8y6WCL4Z47wcV3hlZx0ZkXFkRJEK_ULFEmhU jrMOQc60Mr8XZKuajjcE0dqxRsQ.D0kEZy..Gmsxc5moHHHqV2s0C7L2AsTdRg7B0LQqK.511ONo IeMhZBvN1WbypwXPg4xQk8O2ZRbdMWqToHSWR9GRc3QPnLzih5xK7PR461Tf2yFrPMYC0QtwoN71 ZPP1HlMjSF7RUOSczLZhoEULqHuAxcYpF9RhwmWV4f4HDAPsCMH0NIJh370QSXAX6R6RieThPXLf ElFXInU86S3gyxVJVUyeNvv.PZQdpcJjQYO6FUwIg6DqdjEvxCNZpckGlmUOi9jbaOuCrIMknfk2 Z_sYORL8iSmhLPGpN_NHeTWknpmtPhWyqn40_9yGbrKrkSFMH5k53v0MGTrtcTIvN6S9EeMxvNPG e_MEPNfC1XAWDzG89UTh8l42xljp.wgoObTmMBespduGvoWGOVGDt8iu.epn74aCCLmq5Ld7zzm8 teytPIdS2V4cvhc0w2kUbrKYtbQdkW6GX0IzN.w3cI0LMunf9l8nZEdV6M8BJZn8mAtvm9QdoSmJ smV6YmEZxlVfPyKfiMx2pEERTXpKqOSeJCQjgDb1h_XnngBJ6G2ijO4AfxLUCJPJLhj52KTfDIxy HXGsFhZR57EaR0GC9DH6fUmfjs6Tdqw1iQKW6IbpOAV2pgq08EkxvxHOwOfkmmaajl8HNO31ldes Y2yPsWYPY08Hg5aFK3qeEsnF5MWWQhHqLr6WDxoziG_j7KR9T8_iVh2XgOYg2HteIT0XVtN.VpTW M6aTftNwBOGWsyDqhxOrYiEDanoO1D45fGEEUi5Ka9iGCtKAVDeYYA4phffIxmNBwpkFdBEJ9b4K QHp5Rb.C9HMnq7m7N1Ws__bPVDBHkPvHnVgxh67ZWYZr8a7HynVkZh6mm0kfl1HNH0WXFnlwERkx uZHDL2vVj3STIr36P5bEZ4cE.HKv9QSRS7i7RouW.UXehDJUBuoA9B7nVK1HU4.tWudtjKp49YNX bC_DyAqdbI1iZd9VZL8NmGP6V._Q2TSuzisY1CtTvnXby0VBhn1OEpHL_qIVKpBy.v3YM915ncA8 JhSKid05LjD.RZV_S_x.lJRqGT3hh7ULAhCJHZxa.mCDkEXjJK6RizZgoCyMUTuBhohnBa7mSZSD _PXv7_A6NiOprGs2pPx.Fet8XwH61i_vQqS3Iv0rXIhcTo3NFIdK4guEoNB6ZcSIeuzanv2XtIT8 48Gwhk5a9imkhIh4Q_EeHGSu6Ll1.kkAfZEjKYcxxAU4x.wZGgt2Wfq4IKNPE2ZzXQJY.R9V1_dM uTFKAWEsXj9zUjKD0Mjo5bwCl4MUJXZicVpR1AAKxqDwsTULRYCtyZAyx1A08Wxyja3YbOtPJCl. 2GKcTXrYvnvLcJSxBeCj15eEWNhZVRZQiCXW01CQIEOEsalzueEbqsgAhNKPY8W8meOUPJg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 21:32:37 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0baeaae5442914f50439d86f6563f26f; Sun, 03 May 2020 21:32:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> Date: Sun, 3 May 2020 14:32:34 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FfN849ggz4LRh X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.31 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.887,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.922,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.59), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:32:42 -0000 [The bit argument ot bitmap_unset seems to be way too large.] On 2020-May-3, at 11:08, Mark Millard wrote: > [At around 4AM local time dhcient got a signal 11, > despite the jemalloc revert. The other exmaples > have not happened.] >=20 > On 2020-May-2, at 18:46, Mark Millard wrote: >=20 >> [I'm only claiming the new jemalloc is involved and that >> reverting avoids the problem.] >>=20 >> I've been reporting to some lists problems with: >>=20 >> dhclient >> sendmail >> rpcbind >> mountd >> nfsd >>=20 >> getting SIGSEGV (signal 11) crashes and some core >> dumps on the old 2-socket (1 core per socket) 32-bit >> PowerMac G4 running head -r360311. >>=20 >> Mika=C3=ABl Urankar sent a note suggesting that I try >> testing reverting head -r360233 for my head -r360311 >> context. He got it right . . . >>=20 >>=20 >> Context: >>=20 >> The problem was noticed by an inability to have >> other machines do a: >>=20 >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >>=20 >> sort of operation and to have succeed. By contrast, on >> the old PowerMac G4 I could initiate mounts against >> other machines just fine. >>=20 >> I do not see any such problems on any of (all based >> on head -r360311): >>=20 >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) >> armv7 (OrangePi+ 2ed) >> aarch64 (Rock64, RPi4, RPi3, >> OverDrive 1000, >> Macchiatobin Double Shot) >> amd64 (ThreadRipper 1950X) >>=20 >> So I expect something 32-bit powerpc specific >> is somehow involved, even if jemalloc is only >> using whatever it is. >>=20 >> (A kyua run with a debug kernel did not find other >> unexpected signal 11 sources on the 32-bit PowerMac >> compared to past kyua runs, at least that I noticed. >> There were a few lock order reversals that I do not >> know if they are expected or known-safe or not. >> I've reported those reversals to the lists as well.) >>=20 >>=20 >> Recent experiments based on the suggestion: >>=20 >> Doing the buildworld, buildkernel and installing just >> the new kernel and rebooting made no difference. >>=20 >> But then installing the new world and rebooting did >> make things work again: I no longer get core files >> for the likes of (old cores from before the update): >>=20 >> # find / -name "*.core" -print >> /var/spool/clientmqueue/sendmail.core >> /rpcbind.core >> /mountd.core >> /nfsd.core >>=20 >> Nor do I see the various notices for sendmail >> signal 11's that did not leave behind a core file >> --or for dhclient (no core file left behind). >> And I can mount the old PowerMac's drive from >> other machines just fine. >>=20 >>=20 >> Other notes: >>=20 >> I do not actively use sendmail but it was left >> to do its default things, partially to test if >> such default things are working. Unfortunately, >> PowerMacs have a problematical status under >> FreeBSD and my context has my historical >> experiments with avoiding various problems. >=20 > Looking, I see that I got a: >=20 > pid 572 (dhclient), jid 0, uid 0: exited on signal 11 (core dumped) >=20 > notice under the reverted build. No instances > of the other examples. This is the first that a > dhclient example has produced a .core file. >=20 > gdb indicates 0x5180936c for r7 in: >=20 > lwz r8,36(r7) >=20 > as leading to the failure. This was in > arena_dalloc_bin_locked_impl (where > arena_slab_reg_dalloc and bitmap_unset > were apparently inlined). >=20 > The chain for the example seems to be: > fork_privchld -> dispatch_imsg -> jemalloc >=20 > For reference . . . >=20 > # gdb dhclient /dhclient.core=20 > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > . . . > Reading symbols from dhclient... > Reading symbols from /usr/lib/debug//sbin/dhclient.debug... > [New LWP 100089] > Core was generated by `dhclient: gem0 [priv]'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= > 341 = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h: = No such file or directory. > (gdb) bt -full > #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= > goff =3D > gp =3D 0x51809390 > propagate =3D > g =3D > i =3D > #1 arena_slab_reg_dalloc (slab=3D0x50407140, slab_data=3D0x50407164, = ptr=3D0x50088b50) at jemalloc_arena.c:273 > bin_info =3D > binind =3D 0 > regind =3D 167842154 > #2 arena_dalloc_bin_locked_impl (tsdn=3D0x5009f018, arena=3D, slab=3D, ptr=3D, junked=3D) at jemalloc_arena.c:1540 > slab_data =3D > binind =3D > bin_info =3D > bin =3D > nfree =3D > #3 0x502916a8 in __je_arena_dalloc_bin_junked_locked (tsdn=3D, arena=3D, extent=3D, ptr=3D) at jemalloc_arena.c:1559 > No locals. > #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 > ptr =3D > i =3D 0 > extent =3D 0x50407140 > bin_arena =3D 0x50400380 > bin =3D > ndeferred =3D 0 > merged_stats =3D > arena =3D 0x50400380 > nflush =3D 75 > __vla_expr0 =3D > item_extent =3D 0xffffd1f0 > #5 0x502508a0 in __je_tcache_event_hard (tsd=3D, = tcache=3D0x5009f108) at jemalloc_tcache.c:54 > tbin_info =3D > binind =3D 7 > tbin =3D 0x5009f1c0 > #6 0x5029a684 in __free (ptr=3D0x500530c0) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/rtree.h:374 > tcache =3D 0x5009f108 > tsd =3D > log_var =3D > log_var =3D > #7 0x10025994 in dispatch_imsg (ifix=3D, fd=3D10) at = /usr/powerpc32_src/sbin/dhclient/privsep.c:215 > hdr =3D {code =3D IMSG_SCRIPT_WRITE_PARAMS, len =3D 3225} > lease =3D {next =3D 0x0, expiry =3D 1588504529, renewal =3D = 1588504229, rebind =3D 1588504454, address =3D {len =3D 4, iabuf =3D = "\300\250\001i", '\000' }, nextserver =3D {len =3D 4,=20= > iabuf =3D '\000' }, server_name =3D 0x0, = filename =3D 0x0, medium =3D 0x0, is_static =3D 0, is_bootp =3D 0, = options =3D {{len =3D 0, data =3D 0x0}, {len =3D 4,=20 > data =3D 0x500530c8 "\377\377\377"}, {len =3D 0, data =3D = 0x0}, {len =3D 4, data =3D 0x500530d0 "\300\250\001\001"}, {len =3D 0, = data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 4,=20 > data =3D 0x500530d8 "\300\250\001\001"}, {len =3D 0, data = =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D = 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, = { > len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len = =3D 20, data =3D 0x50055200 "hsd1.or.comcast.net."}, {len =3D 0, data =3D = 0x0} , {len =3D 4, data =3D 0x500530e0 ""}, {len =3D = 0,=20 > data =3D 0x0}, {len =3D 1, data =3D 0x500530e8 "\005"}, = {len =3D 4, data =3D 0x500530f0 "\300\250\001\001"}, {len =3D 0, data =3D = 0x0} }} > medium_len =3D > medium =3D > totlen =3D 3225 > filename_len =3D > filename =3D 0x0 > ret =3D > buf =3D > mtu =3D > servername_len =3D > servername =3D 0x0 > reason_len =3D > reason =3D > --Type for more, q to quit, c to continue without paging-- > prefix_len =3D > prefix =3D 0x500530c0 "new_" > i =3D 0 > optlen =3D 0 > #8 0x100189f4 in fork_privchld (fd=3D10, fd2=3D) at = /usr/powerpc32_src/sbin/dhclient/dhclient.c:2847 > pfd =3D {{fd =3D 10, events =3D 1, revents =3D 1}} > nfds =3D > #9 0x10017a80 in main (argc=3D, argv=3D) at /usr/powerpc32_src/sbin/dhclient/dhclient.c:505 > pipe_fd =3D {10, 11} > rights =3D {cr_rights =3D {1342801412, 18446706484155777024}} > immediate_daemon =3D 0 > i =3D 0 > ch =3D > otherpid =3D 8 > pw =3D 0x5039b9d8 > fd =3D > capmode =3D >=20 > (gdb) disass > Dump of assembler code for function arena_dalloc_bin_locked_impl: > 0x502916b8 <+0>: mflr r0 > 0x502916bc <+4>: stw r0,4(r1) > 0x502916c0 <+8>: stwu r1,-48(r1) > 0x502916c4 <+12>: stw r30,40(r1) > 0x502916c8 <+16>: stw r24,16(r1) > 0x502916cc <+20>: stw r25,20(r1) > 0x502916d0 <+24>: stw r26,24(r1) > 0x502916d4 <+28>: stw r27,28(r1) > 0x502916d8 <+32>: stw r28,32(r1) > 0x502916dc <+36>: stw r29,36(r1) > 0x502916e0 <+40>: bl 0x502916e4 = > 0x502916e4 <+44>: mr r27,r3 > 0x502916e8 <+48>: mflr r30 > 0x502916ec <+52>: addis r30,r30,14 > 0x502916f0 <+56>: addi r30,r30,7788 > 0x502916f4 <+60>: mr r28,r4 > 0x502916f8 <+64>: lwz r4,5856(r30) > 0x502916fc <+68>: lwz r3,4(r5) > 0x50291700 <+72>: mr r29,r5 > 0x50291704 <+76>: andi. r5,r7,1 > 0x50291708 <+80>: mr r26,r6 > 0x5029170c <+84>: lbz r4,0(r4) > 0x50291710 <+88>: rlwinm r5,r3,14,25,31 > 0x50291714 <+92>: mulli r24,r5,224 > 0x50291718 <+96>: mulli r25,r5,44 > 0x5029171c <+100>: cmpwi cr1,r4,0 > 0x50291720 <+104>: cror 4*cr5+lt,4*cr1+eq,gt > 0x50291724 <+108>: bge cr5,0x50291a2c = > 0x50291728 <+112>: lwz r4,0(r29) > 0x5029172c <+116>: lwz r6,6036(r30) > 0x50291730 <+120>: lwz r7,8(r29) > 0x50291734 <+124>: rlwinm r8,r5,2,0,29 > 0x50291738 <+128>: li r9,1 > 0x5029173c <+132>: add r24,r28,r24 > 0x50291740 <+136>: lwzx r6,r6,r8 > 0x50291744 <+140>: subf r7,r7,r26 > 0x50291748 <+144>: mulhwu r6,r6,r7 > 0x5029174c <+148>: rlwinm r7,r6,29,3,29 > 0x50291750 <+152>: add r7,r29,r7 > =3D> 0x50291754 <+156>: lwz r8,36(r7) > 0x50291758 <+160>: clrlwi r10,r6,27 > 0x5029175c <+164>: slw r9,r9,r10 > 0x50291760 <+168>: xor r9,r9,r8 > 0x50291764 <+172>: cmplwi r8,0 > 0x50291768 <+176>: stw r9,36(r7) > 0x5029176c <+180>: bne 0x502917e4 = > 0x50291770 <+184>: lwz r7,4408(r30) > 0x50291774 <+188>: mulli r8,r5,44 > 0x50291778 <+192>: add r5,r7,r8 > 0x5029177c <+196>: lwz r5,16(r5) > 0x50291780 <+200>: cmplwi r5,2 > 0x50291784 <+204>: blt 0x502917e4 = . . . >=20 > (gdb) info reg > r0 0x502916a8 1344870056 > r1 0xffffd1a0 4294955424 > r2 0x500a6018 1342857240 > r3 0x0 0 > r4 0x0 0 > r5 0x0 0 > r6 0xa01116a 167842154 > r7 0x5180936c 1367380844 > r8 0x0 0 > r9 0x1 1 > r10 0x1e 30 > r11 0x5005d114 1342558484 > r12 0x84000c00 2214595584 > r13 0x0 0 > r14 0xffffd1f0 4294955504 > r15 0xfffffffc 4294967292 > r16 0x4a 74 > r17 0x4b 75 > r18 0x0 0 > r19 0x504009a0 1346374048 > r20 0x0 0 > r21 0xffffd1f0 4294955504 > r22 0x620 1568 > r23 0x50400380 1346372480 > r24 0x50400380 1346372480 > r25 0x0 0 > r26 0x50088b50 1342737232 > r27 0x5009f018 1342828568 > r28 0x50400380 1346372480 > r29 0x50407140 1346400576 > r30 0x50373550 1345795408 > r31 0xffffd310 4294955792 > pc 0x50291754 0x50291754 = > msr > cr 0x42480c00 1112017920 > lr 0x502916e4 0x502916e4 = > ctr 0x5005d114 1342558484 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) explains calculating: gp =3D 0x51809390 via bitmap+(bit/4/8): (gdb) print/x 0x50407164 +167842154/4/8=20 $16 =3D 0x51809390 The last potential bit/4/8 value to be able to access memory (without spanning a hole) is: (gdb) print *(bitmap+582566) $13 =3D 0 (gdb) print/x (bitmap+582566) $14 =3D 0x5063fffc So it looks like arena_slab_reg_dalloc produced an invalid bit value. Looking at that code shows that regind hold the parameter value that matches: static void arena_slab_reg_dalloc(extent_t *slab, arena_slab_data_t *slab_data, void = *ptr) { szind_t binind =3D extent_szind_get(slab); const bin_info_t *bin_info =3D &bin_infos[binind]; size_t regind =3D arena_slab_regind(slab, binind, ptr); =20 assert(extent_nfree_get(slab) < bin_info->nregs); /* Freeing an unallocated pointer can cause assertion failure. = */ assert(bitmap_get(slab_data->bitmap, &bin_info->bitmap_info, = regind)); bitmap_unset(slab_data->bitmap, &bin_info->bitmap_info, regind); extent_nfree_inc(slab); } The backtrace showed binind=3D=3D0 for arena_slab_reg_dalloc. That leaves: arena_slab_regind(slab, binind, ptr) as producing the odd value. size_t arena_slab_regind(extent_t *slab, szind_t binind, const void *ptr) { size_t diff, regind; /* Freeing a pointer outside the slab can cause assertion = failure. */ assert((uintptr_t)ptr >=3D (uintptr_t)extent_addr_get(slab)); assert((uintptr_t)ptr < (uintptr_t)extent_past_get(slab)); /* Freeing an interior pointer can cause assertion failure. */ assert(((uintptr_t)ptr - (uintptr_t)extent_addr_get(slab)) % (uintptr_t)bin_infos[binind].reg_size =3D=3D 0); diff =3D (size_t)((uintptr_t)ptr - = (uintptr_t)extent_addr_get(slab)); /* Avoid doing division with a variable divisor. */ regind =3D div_compute(&arena_binind_div_info[binind], diff); assert(regind < bin_infos[binind].nregs); return regind; } ptr =3D=3D 0x50088b50 slab =3D=3D 0x50407140 static inline void * extent_addr_get(const extent_t *extent) { assert(extent->e_addr =3D=3D PAGE_ADDR2BASE(extent->e_addr) || !extent_slab_get(extent)); return extent->e_addr; } (gdb) print *slab $17 =3D {e_bits =3D 0, e_addr =3D 0x0, {e_size_esn =3D 0, e_bsize =3D = 0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= {bitmap =3D { 0 }}, e_prof_tctx =3D {repr =3D 0x0}}} That looks wrong: all fields are zero, which is not likely to be the description of a slab. But I'll continue to be sure I get the reported value of bit. So extent_addr_get(slab)=3D=3Dslab->e_addr and slab->e_addr=3D=3D0x0 and diff=3D=3Dptr . (gdb) print/x arena_binind_div_info[binind] $19 =3D {magic =3D 0x20000000} static inline size_t div_compute(div_info_t *div_info, size_t n) { assert(n <=3D (uint32_t)-1); /* * This generates, e.g. mov; imul; shr on x86-64. On a 32-bit = machine, * the compilers I tried were all smart enough to turn this into = the * appropriate "get the high 32 bits of the result of a = multiply" (e.g. * mul; mov edx eax; on x86, umull on arm, etc.). */ size_t i =3D ((uint64_t)n * (uint64_t)div_info->magic) >> 32; #ifdef JEMALLOC_DEBUG assert(i * div_info->d =3D=3D n); #endif return i; } (gdb) print/x ((unsigned long long)0x50088b50 * (unsigned long = long)0x20000000) >> 32 $21 =3D 0xa01116a (gdb) print ((unsigned long long)0x50088b50 * (unsigned long = long)0x20000000) >> 32 $22 =3D 167842154 (As reported.) So returning to *slab being all zero . . . The slab value in the call chain seems to trace back to=3D __je_tcache_bin_flush_small code: bin_t *bin =3D &bin_arena->bins[binind]; . . . malloc_mutex_lock(tsd_tsdn(tsd), &bin->lock); . . . for (unsigned i =3D 0; i < nflush; i++) { void *ptr =3D *(tbin->avail - 1 - i); extent =3D item_extent[i]; assert(ptr !=3D NULL && extent !=3D NULL); if (extent_arena_get(extent) =3D=3D bin_arena) { = arena_dalloc_bin_junked_locked(tsd_tsdn(tsd), bin_arena, extent, ptr); . . . malloc_mutex_unlock(tsd_tsdn(tsd), &bin->lock); (So ptr's value here is later slab's value in the call chain.) The backtrace shows binind =3D 7 via __je_tcache_event_hard . (Not the same as the earlier binind.) #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 ptr =3D i =3D 0 extent =3D 0x50407140 bin_arena =3D 0x50400380 bin =3D ndeferred =3D 0 merged_stats =3D arena =3D 0x50400380 nflush =3D 75 __vla_expr0 =3D item_extent =3D 0xffffd1f0 (gdb) print/x bin_arena->bins[7] $44 =3D {lock =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, = max_wait_time =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D = 0x0, max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0},=20 n_owner_switches =3D 0x0, prev_owner =3D 0x0, n_lock_ops =3D = 0x0}, lock =3D 0x0, postponed_next =3D 0x504021d0}, witness =3D {name =3D = 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0}}, slabcur =3D = 0x50407140, slabs_nonfull =3D {ph_root =3D 0x0}, slabs_full =3D = {qlh_first =3D 0x0}, stats =3D {nmalloc =3D 0x64, ndalloc =3D 0x0, = nrequests =3D 0x1,=20 curregs =3D 0x64, nfills =3D 0x1, nflushes =3D 0x1, nslabs =3D 0x1, = reslabs =3D 0x0, curslabs =3D 0x1, mutex_data =3D {tot_wait_time =3D {ns = =3D 0x0}, max_wait_time =3D {ns =3D 0x0}, n_wait_times =3D 0x0,=20 n_spin_acquired =3D 0x0, max_n_thds =3D 0x0, n_waiting_thds =3D = {repr =3D 0x0}, n_owner_switches =3D 0x0, prev_owner =3D 0x0, n_lock_ops = =3D 0x0}}} That indicates: bin_arena->bins[7]->lock =3D 0x0 . Expected? Single threaded context? (gdb) print *item_extent[0] $27 =3D {e_bits =3D 0, e_addr =3D 0x0, {e_size_esn =3D 0, e_bsize =3D = 0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= {bitmap =3D { 0 }}, e_prof_tctx =3D {repr =3D 0x0}}} Other *item_extent[INDEX] that I tried got the same: all zeros. This is what contributed to the huge bit value. item_extent[] is based on the declaration: VARIABLE_ARRAY(extent_t *, item_extent, nflush); and: /* Declare a variable-length array. */ #if __STDC_VERSION__ < 199901L # ifdef _MSC_VER # include # define alloca _alloca # else # ifdef JEMALLOC_HAS_ALLOCA_H # include # else # include # endif # endif # define VARIABLE_ARRAY(type, name, count) \ type *name =3D alloca(sizeof(type) * (count)) #else # define VARIABLE_ARRAY(type, name, count) type name[(count)] #endif WARNING: C11 turned VLAs into a conditional feature (__STDC_NO_VLA__). Only C99 has it as required. Thus the above definition of VARIABLE_ARRAY is incomplete or limited to C99 and before relative the the language vintages. Looking around, the stack frames seem to span the space okay: (gdb) print/x &item_extent[75] $32 =3D 0xffffd31c (gdb) print/x &item_extent[0] $33 =3D 0xffffd1f0 r1 0xffffd1a0 4294955424 r14 0xffffd1f0 4294955504 r15 0xfffffffc 4294967292 r21 0xffffd1f0 4294955504 (gdb) print/x *(void**)0xffffd1a0 $36 =3D 0xffffd1d0 (gdb) print/x *(void**)0xffffd1d0 $37 =3D 0xffffd1e0 (gdb) print/x *(void**)0xffffd1e0 $38 =3D 0xffffd440 (gdb) print/x *(void**)0xffffd440 $39 =3D 0xffffd460 And I've run out of ideas for what else to look at (for now). (It is not like I understand jemalloc.) (Last I knew, 32-bit powerpc did not have red-zone stack-space criteria to leave room for signals to use.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon May 4 03:35: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 306C12C1D2C for ; Mon, 4 May 2020 03:35:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 49FpR15xJJz4cPY for ; Mon, 4 May 2020 03:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: k6zKPnsVM1lfrCrcQF5bRJOn.HgrqX3l23eRyTPe6AXTqAVsXKJfcIN2SvJg6B1 .gd0V6_dWoAb2J8tqbCnwFDSEA4ImyXhxngCs1rXaSKMZ2WzXGD_Dqs4XkBx_2FdRFgeapuLD2po _CHP_7yMQtdP2LcldiJi38IMpt3sizYgGYxHy_N80uNHkFZGPy0BtBPquQdrahF7MpFKSbkCIuTR zGGM_aVcAzN9rJPDhVrNahUo2t5t_b4yW.MtwOQs2g7n02PYy_5_8Ce2fsPXfxNwUzLOR1.SNlL_ v6nSyHHpOVrmYrEfINqvIbGvQkuE79j2Wjx8A6dj5BjMwfH2n3Cy7s17fiT8uL.LjFJJQDQrTadm 1f4MMCeTy4sNMk0d3gMRk40QiKuLZqxZJelae8EQKaCp2bkV9dj1DIkVCwuIW45IkKHI0eJ86DHR tOfJdnAYRLOo8HFEyVFVCbWkclyuUhkdCRw2jaqATVSAWGpPqkZ4PCSth0MPp3dz2WcOZx8HpnBL .mnbB3XOmsxT4Uzxonxeyjo3SVWIbGIZCJlWFOCn1IC2L3bKlwF3oR.Kgd1vLA8bgNoNXzIU3Dv. D8QoJSUBtqB04dKkh_CB0JxF.9bxR3Xlms_rfK4H0BncktRy1tsXFUl0ho5tAhBFD5xbjPbTqSWV RlweHPHL4iBAhLzUn7K7v7sUC581yJpSuFb34jXAD0dZDN88DARLrNKSzgtxVBSzTOq1ntfsapz5 _lBFo_ATpkeSl_drJUbxlolZV_hTcA24UgesCS1E_HtKtAPe_agj1Rdl_lWPAR_xcVuARdVVAT3s JCvMJVveQGxPicWOizbuWEfB9vPtLFemI2IBGJcsByOQEAI6kw8vkqXwKPUVAj9yBC8iGTN.xv.n wrdlx3pmlBCrvWLk4xjjob652Oxo_Itsgw0W1kBSYW9g4jg0z1IGEgkVzpUYD0.OaiLOWX4T1OLc DACqxfd_U4mzMztoJ2SuJdGI.0Of3sTE4nAAFwsm7HwJ4PCQqJatkl_QbUtGUpaRzMtc_X8FTGlz og50slZw8QHRSn3AA0B.xo0haFGCgGnLne.OSv8c9EOrLZsAbPiDSc0DyHgAhBAYLMrZ8av_w518 QMm27jfMrceXW_Jfwbk0rsp2dqo5MqCb5BFc3iahwzTfN.KX8X_oz9e3a.ljxCBGxpYnaMtWE6dc H4NS.X0jMO8bMuAsfeVEAjcBLzuADQkEpUUEQHIWz_8np2fzNP7hFUse3Sp9QvMcfeCETBmyZ2Lr VpJZ_9DqiM4qz5UpBrKP0lIUUQo68haPsVQcKZJ6nxkTXYzpd1NShMjgIRDjgWFsSwpCWcyeuoe_ W5ecdYjRuV9TEUIGVTx56COQMnpOFPOU9Qm_zs5Uz1iqoXOnWf6cDJIT.ymcBd308Oz7Vbm73cRh OwAy.cHJQ64lLPNBWgnTh3Bpfgf9izg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 May 2020 03:35:39 +0000 Received: by smtp415.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0f1626b2cc68caa9d0a40fce7235f8f4; Mon, 04 May 2020 03:35:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> Date: Sun, 3 May 2020 20:35:35 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FpR15xJJz4cPY X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-3.25), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 03:35:43 -0000 This note just reports things from looking at 2 .core files (mountd and rpcbind) from the new jemalloc context's failures. May be someone that knows more can get something out of it. I've not included any of the prior message history. For mountd: Core was generated by `/usr/sbin/mountd -r'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x50235df0 in cache_bin_dalloc_easy (bin=3D, = bin_info=3D, ptr=3D0x50049160) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/cache_bin.h:121 warning: Source file is more recent than executable. 121 if (unlikely(bin->ncached =3D=3D bin_info->ncached_max)) = { It turns out that bin_info traces back to: cache_bin_t *bin =3D tcache_small_bin_get(tcache, = alloc_ctx.szind); cache_bin_info_t *bin_info =3D = &tcache_bin_info[alloc_ctx.szind]; if (!cache_bin_dalloc_easy(bin, bin_info, ptr)) { return false; } based on: #define tcache_bin_info JEMALLOC_N(tcache_bin_info) and: # define JEMALLOC_N(n) __je_##n But gdb reports: (gdb) print __je_tcache_bin_info $3 =3D (cache_bin_info_t *) 0x0 (gdb) print alloc_ctx $1 =3D {szind =3D 0, slab =3D } so bin_info =3D NULL and bin_info->ncached_max would fail (and does). By contrast, bin->ncached seems to be from: (gdb) print *(cache_bin_t*)0x50094018 $6 =3D {low_water =3D 65536, ncached =3D 1, tstats =3D {nrequests =3D = 4796680610075595179}, avail =3D 0x0} For rpcbind: Core was generated by `/usr/sbin/rpcbind'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x50243fec in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:323 323 newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; (gdb) print *newxprt $5 =3D {xp_fd =3D 14, xp_port =3D 0, xp_ops =3D 0x50329e1c, xp_addrlen =3D= 0, xp_raddr =3D {sin_len =3D 0 '\000', sin_family =3D 0 '\000', = sin_port =3D 0, sin_addr =3D {s_addr =3D 0},=20 sin_zero =3D "\000\000\000\000P1O\374"}, xp_ops2 =3D 0x50329e34, = xp_tp =3D 0x0, xp_netid =3D 0x50047310 "unix", xp_ltaddr =3D {maxlen =3D = 1345322064, len =3D 1970170232, buf =3D 0x2020}, xp_rtaddr =3D { maxlen =3D 268500992, len =3D 16, buf =3D 0x0}, xp_verf =3D = {oa_flavor =3D 0, oa_base =3D 0x202d2020 , oa_length =3D 538976364}, xp_p1 =3D 0x6f6f7000,=20 xp_p2 =3D 0x0, xp_p3 =3D 0x202d2020, xp_type =3D 538976288} so newxprt->xp_rtaddr.buf =3D=3D 0x0 . But taht is very odd . . . /* * make a new transporter (re-uses xprt) */ newxprt =3D makefd_xprt(sock, r->sendsize, r->recvsize); newxprt->xp_rtaddr.buf =3D mem_alloc(len); if (newxprt->xp_rtaddr.buf =3D=3D NULL) return (FALSE); memcpy(newxprt->xp_rtaddr.buf, &addr, len); newxprt->xp_rtaddr.len =3D len; #ifdef PORTMAP if (addr.ss_family =3D=3D AF_INET || addr.ss_family =3D=3D = AF_LOCAL) { newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; newxprt->xp_addrlen =3D sizeof (struct sockaddr_in); } #endif /* PORTMAP */ Or, in machine code terms: 0x50243f90 <+260>: mr r28,r3 0x50243f94 <+264>: lwz r4,0(r24) 0x50243f98 <+268>: lwz r5,4(r24) 0x50243f9c <+272>: mr r3,r28 0x50243fa0 <+276>: bl 0x5024308c 0x50243fa4 <+280>: lwz r27,36(r1) 0x50243fa8 <+284>: mr r29,r3 0x50243fac <+288>: li r3,1 0x50243fb0 <+292>: mr r4,r27 0x50243fb4 <+296>: bl 0x502e3214 <00000000.plt_pic32.calloc> 0x50243fb8 <+300>: cmplwi r3,0 0x50243fbc <+304>: stw r3,64(r29) 0x50243fc0 <+308>: beq 0x50244160 Note: getting here means that newxprt->xp_rtaddr.buf ws not NULL . Also the value was stored to 64(r29). 0x50243fc4 <+312>: addi r4,r1,296 0x50243fc8 <+316>: mr r5,r27 0x50243fcc <+320>: bl 0x502e3264 <00000000.plt_pic32.memcpy> Note: getting here means that memcpy was able to store where ewxprt->xp_rtaddr.buf indicated (as the r3 value). 0x50243fd0 <+324>: lbz r3,297(r1) 0x50243fd4 <+328>: stw r27,60(r29) 0x50243fd8 <+332>: addi r3,r3,-1 0x50243fdc <+336>: clrlwi r3,r3,24 0x50243fe0 <+340>: cmplwi r3,1 0x50243fe4 <+344>: bgt 0x50244014 0x50243fe8 <+348>: lwz r3,64(r29) =3D> 0x50243fec <+352>: lwz r4,0(r3) Note: the failure was above with r3=3D=3D0x0: (gdb) info reg r0 0x50243fb8 1344552888 r1 0xffffb400 4294947840 r2 0x500a1018 1342836760 r3 0x0 0 r4 0xffffb538 4294948152 r5 0x10 16 r6 0x50047328 1342468904 r7 0x0 0 r8 0x50047324 1342468900 r9 0x0 0 r10 0x20 32 r11 0x502d691c 1345153308 r12 0x24200880 606079104 r13 0x0 0 r14 0x0 0 r15 0xffffbc28 4294949928 r16 0x10002848 268445768 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5004c044 1342488644 r22 0xffffb63c 4294948412 r23 0x80 128 r24 0x50048010 1342472208 r25 0x14 20 r26 0xffffb630 4294948400 r27 0x10 16 r28 0xe 14 r29 0x500472e0 1342468832 r30 0x5030112c 1345327404 r31 0x10040000 268697600 pc 0x50243fec 0x50243fec msr cr 0x84200080 2216689792 lr 0x50243fd0 0x50243fd0 ctr 0x0 0 xer 0x0 0 fpscr 0x0 0 vscr vrsave Note: The rest of the 2 assignments would have been done by: 0x50243ff0 <+356>: stw r4,16(r29) 0x50243ff4 <+360>: lwz r4,4(r3) 0x50243ff8 <+364>: stw r4,20(r29) 0x50243ffc <+368>: lwz r4,8(r3) 0x50244000 <+372>: stw r4,24(r29) 0x50244004 <+376>: li r4,16 0x50244008 <+380>: lwz r3,12(r3) 0x5024400c <+384>: stw r4,12(r29) 0x50244010 <+388>: stw r3,28(r29) My only guesses for alternatives are: A) A processor context switch where the other processor did not (yet) see the value stored via 64(r29) and so it used an older value. B) Something trashed the memory at 64(r29) after it was updated by the code above. C) r29's value was trashed by something, changing where 64(r29) referenced. D) r3 was trashed between the two back-to-back instructions: 0x50243fe8 <+348>: lwz r3,64(r29) =3D> 0x50243fec <+352>: lwz r4,0(r3) E) ??? I've no clue which. Both .core files seem to have zero's showing up in unexpected places previously non-zero. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon May 4 07:26:57 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 DF1192C73AC; Mon, 4 May 2020 07:26:57 +0000 (UTC) (envelope-from bapt@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) server-signature RSA-PSS (4096 bits) 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 49FvYs5d69z3KNq; Mon, 4 May 2020 07:26:57 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 919A95542; Mon, 4 May 2020 07:26:57 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id D3750C22B6; Mon, 4 May 2020 09:26:24 +0200 (CEST) Date: Mon, 4 May 2020 09:26:24 +0200 From: Baptiste Daroussin To: Cy Schubert Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <20200504072624.wlyd73pehq25tcp2@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <202005032010.043KAwm9005791@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ma2vde2ykv3k7k6b" Content-Disposition: inline In-Reply-To: <202005032010.043KAwm9005791@slippy.cwsent.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 07:26:57 -0000 --ma2vde2ykv3k7k6b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote: > In message <20200430130449.cwsf3x42o6w67gor@ivaldir.net>, Baptiste=20 > Daroussin wr > ites: > >=20 > > > > --mvhxgm4zl62unzlf > > Content-Type: text/plain; charset=3Dus-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote: > > > In message <20200430075337.3wdzglshhorcd2qn@ivaldir.net>, Baptiste=3D= 20 > > > Daroussin wr > > > ites: > > > >=3D20 > > > > > > > > --vwrr5drfobpkyvop > > > > Content-Type: text/plain; charset=3D3Dus-ascii > > > > Content-Disposition: inline > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote: > > > > > Would people be open to the idea of a sysutils/screen-ncurses por= t th=3D > > at=3D3D > > > > =3D3D20 > > > > > depends on devel/ncurses instead of ncureses in base? The reason = for =3D > > this=3D3D > > > > =3D3D20 > > > > > is there are screen.* terminfo entries in devel/ncurses that don'= t ex=3D > > ist =3D3D > > > > in=3D3D20 > > > > > termcap(5). People who want that extra functionality would be adv= ised=3D > > to=3D3D > > > > =3D3D20 > > > > > install the alternative pkg or build the sysutils/screen port wit= h th=3D > > e=3D3D20 > > > > > appropriate option. > > > > >=3D3D20 > > > > > Or, simply change the default from whatever ncurses is available = to a=3D > > lway=3D3D > > > > s=3D3D20 > > > > > install devel/ncurses. People could always select one of the othe= r op=3D > > tion=3D3D > > > > s.=3D3D20 > > > > > Personally, I'm not enamoured with this approach. > > > > > > > > I think it is a terrible idea, and we should fix the initial proble= m in=3D > > stea=3D3D > > > > d of > > > > workarounding it. > > > > > > > > 1/ why those are not in our termcap(5) ? they should be added if th= ey a=3D > > re > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice) > > >=3D20 > > > I came to this conclusion last night after sending this email thread = oud=3D > > =3D20 > > > and will test it some time today. > > >=3D20 > > > > > > > > 2/ we should allow our base ncurses to get informations from newer = term=3D > > cap(=3D3D > > > > 5) if > > > > needed. > > > > So far the default TERMCAP is > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,= =2Edb} > > > > > > > > First the user can be advise to point configure the $home/.termcap = this=3D > > is =3D3D > > > > for > > > > quick now. > > > > that is in your scope via a pkg-message :D > > > > > > > > > > Second for later futur proof mechanism we could modify our termcap = read=3D > > er (=3D3D > > > > we > > > > use our own, not the one in provided by ncurses). to be able to fet= ch t=3D > > ermc=3D3D > > > > ap > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example > > > > > > > > This way ports with random termcap info to add would be able to do = it w=3D > > itho=3D3D > > > > ut > > > > the requirement to wait for a commit in base and a MFC. > > >=3D20 > > > This is probably outside of my scope at the moment but, yes, agreed. > > >=3D20 > > I will then. > > I added that to my TODO >=20 > There's already a utility in devel/ncurses called infotocap (and its=20 > corresponding captoinfo) that already does this. Both are links to tic. O= ur=20 > ncurses import includes tic. Looks like all that's needed is add it to=20 > buildworld. >=20 > I can look at it later tonight. Seems like a quick win. >=20 That is not the point, tic won't work here except if create your own versio= n or use infotocap. Tic is for terminfo databases while we are still using the= =20 termcap for historical reason Having both ncurses from ports and ncurses from base installed at the same = time can open a special can of worm so imho that is not really something we want= to look forward. Best regards, Bapt --ma2vde2ykv3k7k6b Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl6vw6AACgkQY4mL3PG3 PlrxbQ/9HVPaPIBpFzm17RyftswDZ1uDyMSEk/1vH3ybiscgI08Ew/PGsevDq4ji ntBJ1M6DZojTNQIzCUyO7+Zmf8wCBfu4pIlMURiCNe5ng/p2Y7eXENGxgTtxlZwl rOvoaMdBNqykQGLCBusjt5FiGLORoN9N4/1aVdafa+B1jfRvIdDXMV1dZkQj3saM gPvLfO/5sgKpkydUZUZiDrjstf+rFafFMpD7KdtCs2+SrTuq61VcFrODoMUN4N3F aXB3hVZ/DSTL3Hhi3+pelxS+mOQXRC7iqQEZ9vh2e411RtoGDMYQq6GaUkhNNBTU 9zN4pL7lxkIAbpHm39CwLxtR0/LNohbsai67BbZcI1EeQtrLFfobaAOT3Xlcl2tD WZfQqQt+chzCs9/r12LfY/oQUkp1XJ2ENNtlHqDFpt0eDoJhv6VaYIoxGQVQwM+1 LTF77UU7c2KNXW6cAzYiChZpIJ3HdGX4vwHOP2w0GEvYot6/oes4i/tdzeTHsh0t wAhxS62M7WVASAGkoxt15a1uq6xunfl9besXQ/OcSTAkZwvHIj2NoSAIsRL9413S q6Jjnxns6ZQY2tVf39qk6P0W5rhqjow5bM5OdY2+fVqNQg0giSzupcxf42ew+f43 8As80W0Llvor53bTSevvfJbfQYdNHBbLcIM+e7nHLTevNmScQrI= =6phY -----END PGP SIGNATURE----- --ma2vde2ykv3k7k6b-- From owner-freebsd-current@freebsd.org Mon May 4 13:35: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 B0C4F2D00C8; Mon, 4 May 2020 13:35:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49G3kj2w7zz4CpX; Mon, 4 May 2020 13:35:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id VbFQjlpXkng7KVbFSjxrc4; Mon, 04 May 2020 07:35:07 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=mi56gJdQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=Wmk-lukIvAQwSAJmWjgA:9 a=CjuIK1q_8ugA:10 a=m6W23KLcDyq3lIHOBnQi:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 185CDA01; Mon, 4 May 2020 06:35:04 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 044DZ3Ve054568; Mon, 4 May 2020 06:35:03 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 044DZ3m1054565; Mon, 4 May 2020 06:35:03 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202005041335.044DZ3m1054565@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Baptiste Daroussin cc: Cy Schubert , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/screen-ncurses port In-reply-to: <20200504072624.wlyd73pehq25tcp2@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <202005032010.043KAwm9005791@slippy.cwsent.com> <20200504072624.wlyd73pehq25tcp2@ivaldir.net> Comments: In-reply-to Baptiste Daroussin message dated "Mon, 04 May 2020 09:26:24 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 May 2020 06:35:03 -0700 X-CMAE-Envelope: MS4wfOILSq5cypboP80vohdzOREKFeH2ud0M4alkS5dy6wZSwhwVqUUZKCf6z5r6T8u424Xw+aI2cu4JWS9WRIrI5JO7y3Hx3df9p7uDL+ucA75DKbvYiAk9 /+IPHkGV2fsmjetF70r1zj6CZitvSkOf+b4F4XQsZlVrkM+1003CdLvhhP0chQkuf0jRwmCpA15XxqNVyGBJPkXvH+IvEQbHBgITS2wsMcevKLvCujGvS/9X cwgZ5+trCCjcl8vpBVI5fg== X-Rspamd-Queue-Id: 49G3kj2w7zz4CpX X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 13:35:09 -0000 In message <20200504072624.wlyd73pehq25tcp2@ivaldir.net>, Baptiste Daroussin wr ites: > > > --ma2vde2ykv3k7k6b > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote: > > In message <20200430130449.cwsf3x42o6w67gor@ivaldir.net>, Baptiste=20 > > Daroussin wr > > ites: > > >=20 > > > > > > --mvhxgm4zl62unzlf > > > Content-Type: text/plain; charset=3Dus-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > > > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote: > > > > In message <20200430075337.3wdzglshhorcd2qn@ivaldir.net>, Baptiste=3D= > 20 > > > > Daroussin wr > > > > ites: > > > > >=3D20 > > > > > > > > > > --vwrr5drfobpkyvop > > > > > Content-Type: text/plain; charset=3D3Dus-ascii > > > > > Content-Disposition: inline > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote: > > > > > > Would people be open to the idea of a sysutils/screen-ncurses por= > t th=3D > > > at=3D3D > > > > > =3D3D20 > > > > > > depends on devel/ncurses instead of ncureses in base? The reason = > for =3D > > > this=3D3D > > > > > =3D3D20 > > > > > > is there are screen.* terminfo entries in devel/ncurses that don'= > t ex=3D > > > ist =3D3D > > > > > in=3D3D20 > > > > > > termcap(5). People who want that extra functionality would be adv= > ised=3D > > > to=3D3D > > > > > =3D3D20 > > > > > > install the alternative pkg or build the sysutils/screen port wit= > h th=3D > > > e=3D3D20 > > > > > > appropriate option. > > > > > >=3D3D20 > > > > > > Or, simply change the default from whatever ncurses is available = > to a=3D > > > lway=3D3D > > > > > s=3D3D20 > > > > > > install devel/ncurses. People could always select one of the othe= > r op=3D > > > tion=3D3D > > > > > s.=3D3D20 > > > > > > Personally, I'm not enamoured with this approach. > > > > > > > > > > I think it is a terrible idea, and we should fix the initial proble= > m in=3D > > > stea=3D3D > > > > > d of > > > > > workarounding it. > > > > > > > > > > 1/ why those are not in our termcap(5) ? they should be added if th= > ey a=3D > > > re > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice) > > > >=3D20 > > > > I came to this conclusion last night after sending this email thread = > oud=3D > > > =3D20 > > > > and will test it some time today. > > > >=3D20 > > > > > > > > > > 2/ we should allow our base ncurses to get informations from newer = > term=3D > > > cap(=3D3D > > > > > 5) if > > > > > needed. > > > > > So far the default TERMCAP is > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termcap{,= > =2Edb} > > > > > > > > > > First the user can be advise to point configure the $home/.termcap = > this=3D > > > is =3D3D > > > > > for > > > > > quick now. > > > > > > that is in your scope via a pkg-message :D > > > > > > > > > > > > > Second for later futur proof mechanism we could modify our termcap = > read=3D > > > er (=3D3D > > > > > we > > > > > use our own, not the one in provided by ncurses). to be able to fet= > ch t=3D > > > ermc=3D3D > > > > > ap > > > > > capabilities from /usr/local/share/misc/termcap/*.conf for example > > > > > > > > > > This way ports with random termcap info to add would be able to do = > it w=3D > > > itho=3D3D > > > > > ut > > > > > the requirement to wait for a commit in base and a MFC. > > > >=3D20 > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > >=3D20 > > > I will then. > > > I added that to my TODO > >=20 > > There's already a utility in devel/ncurses called infotocap (and its=20 > > corresponding captoinfo) that already does this. Both are links to tic. O= > ur=20 > > ncurses import includes tic. Looks like all that's needed is add it to=20 > > buildworld. > >=20 > > I can look at it later tonight. Seems like a quick win. > >=20 > That is not the point, tic won't work here except if create your own versio= > n or > use infotocap. Tic is for terminfo databases while we are still using the= > =20 > termcap for historical reason I'm not suggesting replacing all of termcap. Just adding some converted screen.* entries. > > Having both ncurses from ports and ncurses from base installed at the same = > time > can open a special can of worm so imho that is not really something we want= > to > look forward. Some ports require ncurses from ports. Same can of worms as installing a kerberos or openssl port. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon May 4 13:51: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 BBEE52D097F; Mon, 4 May 2020 13:51:09 +0000 (UTC) (envelope-from bapt@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) server-signature RSA-PSS (4096 bits) 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 49G4594cFhz4DwY; Mon, 4 May 2020 13:51:09 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 563528391; Mon, 4 May 2020 13:51:09 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 9AC29C2B11; Mon, 4 May 2020 15:50:37 +0200 (CEST) Date: Mon, 4 May 2020 15:50:37 +0200 From: Baptiste Daroussin To: Cy Schubert Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <20200504135037.mcrqeomkkqmoew3w@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <202005032010.043KAwm9005791@slippy.cwsent.com> <20200504072624.wlyd73pehq25tcp2@ivaldir.net> <202005041335.044DZ3m1054565@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2ep4og2cnix6if2a" Content-Disposition: inline In-Reply-To: <202005041335.044DZ3m1054565@slippy.cwsent.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 13:51:09 -0000 --2ep4og2cnix6if2a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 04, 2020 at 06:35:03AM -0700, Cy Schubert wrote: > In message <20200504072624.wlyd73pehq25tcp2@ivaldir.net>, Baptiste=20 > Daroussin wr > ites: > >=20 > > > > --ma2vde2ykv3k7k6b > > Content-Type: text/plain; charset=3Dus-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Sun, May 03, 2020 at 01:10:58PM -0700, Cy Schubert wrote: > > > In message <20200430130449.cwsf3x42o6w67gor@ivaldir.net>, Baptiste=3D= 20 > > > Daroussin wr > > > ites: > > > >=3D20 > > > > > > > > --mvhxgm4zl62unzlf > > > > Content-Type: text/plain; charset=3D3Dus-ascii > > > > Content-Disposition: inline > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > On Thu, Apr 30, 2020 at 05:56:54AM -0700, Cy Schubert wrote: > > > > > In message <20200430075337.3wdzglshhorcd2qn@ivaldir.net>, Baptist= e=3D3D=3D > > 20 > > > > > Daroussin wr > > > > > ites: > > > > > >=3D3D20 > > > > > > > > > > > > --vwrr5drfobpkyvop > > > > > > Content-Type: text/plain; charset=3D3D3Dus-ascii > > > > > > Content-Disposition: inline > > > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > On Wed, Apr 29, 2020 at 11:41:46AM -0700, Cy Schubert wrote: > > > > > > > Would people be open to the idea of a sysutils/screen-ncurses= por=3D > > t th=3D3D > > > > at=3D3D3D > > > > > > =3D3D3D20 > > > > > > > depends on devel/ncurses instead of ncureses in base? The rea= son =3D > > for =3D3D > > > > this=3D3D3D > > > > > > =3D3D3D20 > > > > > > > is there are screen.* terminfo entries in devel/ncurses that = don'=3D > > t ex=3D3D > > > > ist =3D3D3D > > > > > > in=3D3D3D20 > > > > > > > termcap(5). People who want that extra functionality would be= adv=3D > > ised=3D3D > > > > to=3D3D3D > > > > > > =3D3D3D20 > > > > > > > install the alternative pkg or build the sysutils/screen port= wit=3D > > h th=3D3D > > > > e=3D3D3D20 > > > > > > > appropriate option. > > > > > > >=3D3D3D20 > > > > > > > Or, simply change the default from whatever ncurses is availa= ble =3D > > to a=3D3D > > > > lway=3D3D3D > > > > > > s=3D3D3D20 > > > > > > > install devel/ncurses. People could always select one of the = othe=3D > > r op=3D3D > > > > tion=3D3D3D > > > > > > s.=3D3D3D20 > > > > > > > Personally, I'm not enamoured with this approach. > > > > > > > > > > > > I think it is a terrible idea, and we should fix the initial pr= oble=3D > > m in=3D3D > > > > stea=3D3D3D > > > > > > d of > > > > > > workarounding it. > > > > > > > > > > > > 1/ why those are not in our termcap(5) ? they should be added i= f th=3D > > ey a=3D3D > > > > re > > > > > > missing. and MFC asap (prior 11.4 and 12.2 would be nice) > > > > >=3D3D20 > > > > > I came to this conclusion last night after sending this email thr= ead =3D > > oud=3D3D > > > > =3D3D20 > > > > > and will test it some time today. > > > > >=3D3D20 > > > > > > > > > > > > 2/ we should allow our base ncurses to get informations from ne= wer =3D > > term=3D3D > > > > cap(=3D3D3D > > > > > > 5) if > > > > > > needed. > > > > > > So far the default TERMCAP is > > > > > > ${HOME}/.termcap{,.db}:/etc/termcap{,.db}:/usr/share/misc/termc= ap{,=3D > > =3D2Edb} > > > > > > > > > > > > First the user can be advise to point configure the $home/.term= cap =3D > > this=3D3D > > > > is =3D3D3D > > > > > > for > > > > > > quick now. > > > > > > > > that is in your scope via a pkg-message :D > > > > > > > > > > > > > > > > Second for later futur proof mechanism we could modify our term= cap =3D > > read=3D3D > > > > er (=3D3D3D > > > > > > we > > > > > > use our own, not the one in provided by ncurses). to be able to= fet=3D > > ch t=3D3D > > > > ermc=3D3D3D > > > > > > ap > > > > > > capabilities from /usr/local/share/misc/termcap/*.conf for exam= ple > > > > > > > > > > > > This way ports with random termcap info to add would be able to= do =3D > > it w=3D3D > > > > itho=3D3D3D > > > > > > ut > > > > > > the requirement to wait for a commit in base and a MFC. > > > > >=3D3D20 > > > > > This is probably outside of my scope at the moment but, yes, agre= ed. > > > > >=3D3D20 > > > > I will then. > > > > I added that to my TODO > > >=3D20 > > > There's already a utility in devel/ncurses called infotocap (and its= =3D20 > > > corresponding captoinfo) that already does this. Both are links to ti= c. O=3D > > ur=3D20 > > > ncurses import includes tic. Looks like all that's needed is add it t= o=3D20 > > > buildworld. > > >=3D20 > > > I can look at it later tonight. Seems like a quick win. > > >=3D20 > > That is not the point, tic won't work here except if create your own ve= rsio=3D > > n or > > use infotocap. Tic is for terminfo databases while we are still using t= he=3D > > =3D20 > > termcap for historical reason >=20 > I'm not suggesting replacing all of termcap. Just adding some converted= =20 > screen.* entries. >=20 > > > > Having both ncurses from ports and ncurses from base installed at the s= ame =3D > > time > > can open a special can of worm so imho that is not really something we = want=3D > > to > > look forward. >=20 > Some ports require ncurses from ports. Same can of worms as installing a= =20 > kerberos or openssl port. >=20 On head, no ports should have to now. Best regards, bapt --2ep4og2cnix6if2a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl6wHa0ACgkQY4mL3PG3 PloUlA/9GVRkrCbXok1EWqBBbnFG4Bl2uHtQK48dFkwYKb9OCe+Cb3Ib3JpxXu41 1BQAo07zLvkEFcDl6Vt0I5JvLXstzF2zDFGF46i+/QNGN0vNduNIp8qXD0PrzXAM djptBSyrcAd5Qubt/8VDpn0tzEZfFB0PFCXkNRihXXRdEG9ZfcGxSsCwoGYnIgRt ulhulwhs/MEpyXc6tBmiFVxtQC/0vU+/zLYfUHz0GLMy1SWFISKHSOZlqQOP3lrp /lPbH4hx5f9/df8tx2EPRfgERObhH1yDPh51Qoqj8hJybjJu1HAXdkfS/9sGFY5N 1KPUVfHnMt99VBnxo5DcSfaPPViZqdhs35Yve5gMeF3K0i4weeBC3BjR7OzCDmCS ae4kQMxl4L2O88qu1lNkFErWO9tfCRnakUEckgIkbIseGZlUQAS5ctfDRSoJuHVn 1M6/ZroP+lLBD8Qh/MM3gespbTVQmR1lCSUCJvRpgpMMBwL/gNf4QkdjoZuDtquR vFHCbPjowoO5UiMYHlVrk9Z1xXFn/jSeYB9P84/w+Md8W7qh5hGNcJ3y0It0v8PV M6XCF0c7yXOe+Lk8mkOniUKX/bOD25oRxDXM96Ff/6N4fUe49aTaWBqgTAc45EL9 v+t2UeTWBQJoBklsHAEPRELvkBUKNGrxId5OGLqBV92oZMM12zM= =3B0R -----END PGP SIGNATURE----- --2ep4og2cnix6if2a-- From owner-freebsd-current@freebsd.org Mon May 4 18:12: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 811262D61EE for ; Mon, 4 May 2020 18:12:02 +0000 (UTC) (envelope-from SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 49G9t93RNPz4Wty; Mon, 4 May 2020 18:12:01 +0000 (UTC) (envelope-from SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5AFB828434; Mon, 4 May 2020 20:11:53 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D597C28416; Mon, 4 May 2020 20:11:47 +0200 (CEST) Subject: Re: PCIe NVME drives not detected on Dell R6515 From: Miroslav Lachman <000.fbsd@quip.cz> To: Scott Long Cc: Kurt Jaeger , Warner Losh , FreeBSD-Current References: <0F8BCB8C-DE60-4A34-A4D8-F1BB4B9F906A@samsco.org> <9EF043C1-FF8F-4997-B59A-EC3BF7D1CEEE@samsco.org> <31E8B2BE-BED2-4084-868D-32C48CB3CD6E@samsco.org> <573f5fab-1ef6-151f-18ca-58d3a4a89c72@quip.cz> <07B6763F-C23B-4B7C-B76A-26267AC35453@samsco.org> <20200417194431.GD39563@home.opsec.eu> <148dcdf7-f185-f14f-52ee-d4df3a2a1dc7@quip.cz> <8D8E1F62-AB66-47E1-8444-3D66F8EADA74@samsco.org> <015c7aa8-9385-4219-1bf1-0137f65ed80d@quip.cz> <90C35FEF-690C-4D04-A0D8-D3E5A448C744@samsco.org> <4736a46d-716d-7860-ff56-6c1d7391dbeb@quip.cz> Message-ID: <6e6461d1-fbc4-c306-f71f-54767f2849cb@quip.cz> Date: Mon, 4 May 2020 20:11:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <4736a46d-716d-7860-ff56-6c1d7391dbeb@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49G9t93RNPz4Wty X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; IP_SCORE(0.81)[ip: (0.26), ipnet: 94.124.104.0/21(0.13), asn: 42000(3.56), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.87)[0.870,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.996,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=ZcGF=6S=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:12:02 -0000 On 2020-04-27 08:02, Miroslav Lachman wrote: > I don't know what is with Scott. I hope he is well. > Is there somebody else who can help me with this issue? > Scott wrote there are hotplug PCIe buses not probed during boot process. > I am not a developer so I cannot move forward alone. The problem is with PCIe Hot Plug. Hot Plug bus was not enumerated thus no NVME detected. Dan Lukes suggested (privately) to disable hot plugging by this at second stage loader prompt: set hw.pci.enable_pcie_hp=0 Then I was able to boot FreeBSD installer ISO in BIOS mode (I don't know why but this machine is not able to boot FreeBSD ISO media in UEFI mode). Installer sees both NVME disks and installation was successful but it cannot boot - Dell R6515 in BIOS mode does not show NVME drives. Switching to UEFI boot shows disks but they didn't contained EFI partition boot code. When I modified the partitions layout (remove swap, ad efi partition and swap again) it is now able to boot FreeBSD 11.3 amd64 in UEFI mode from NVME disks with Hot Plug disabled in loader.conf. Can somebody look on to it why the bus is not probed when Hot Plug is enabled? I have a few days to run some tests on this HW before it will go in to production. Kind regards Miroslav Lachman From owner-freebsd-current@freebsd.org Mon May 4 18:16: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 5324B2D6484 for ; Mon, 4 May 2020 18:16:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (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 49G9zC3kjCz4XP5 for ; Mon, 4 May 2020 18:16:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LIeyrEgVM1li9ooYhqzhtSDUrWGsBQaCd98bLHYPxzr1tWDaTQiFgQsVdy3sLYQ DuY7YJWnuvRsz8wt20s_q1gEXLVVWUJh4J7L8XXZfRdqA2QEDbPuojhsTo2VCZbDj3ZF.7eI0lfz o9c7ALvAJ6spb7M13DWi.WLosHHwcCt04GW6O8TjA2mlM_1bsBxCcfNWdqTo..lAnYHjPEDBx7HV _2Tx1qIzQ0cOI6GRFvSIsXRo5_nYDcyP4awQVt17mJBdAdz6Yk0vj82E5_JvCI0leB62JA3tm78h 1XD5wQwUZlerLBCGKHqLs7qcDxNr9pv3ZV8LLDFFT.tFMFBhVGs6Rs3O4IpXpFEr1cMiOnFHAhte Da.EZXxSbmsUFkHC0su6tanKGYhKy42h7GJ5OqkojE.nD7H78Vn0GLA93fU7dMt4_RlHcKBG0lxX vz3tNV4s0kGeIQEz53hRxg5yqWEeTuzc6mbNmjjN0.UVqbg3TjZzyLIuXvHvH2xBQgfdsz3VfrqZ vfA26Zu6oKgZ8Ez66yktajslvTCiZNlCGBnDitZ_ZitHlKk5_zk4KzX2BOe1dRzuyLyrkyw6FAeY LGllG7Pcf5JChIynJj6g6ghPqlCEY0JsByIIzUhzRP15Bh51CAgFN41VfGV2XAitDX5YVpBCdIZy Td8B.fb2u0R6Fmwh9b_5JFLJJMZs.gsTKEAx8HwjLQjNHpQodaUV4eEoFq6fqBdsNJaLg8KZ1acV 7yHmFiZiHKItADe.WNn3cFhzQn7gRXafkxT0J75Br5IEJWHBOEqjYCh1HHhqmGg4YAplI9nRFnzc WGIwg69XgJ86bPT6I_kpA4mTgUUa5lcHOGsVwEtKBGkoJXUXVTl9agBtFFtV6uHGuYJsGvCV8bWQ imQUDp3YhDa0AZ2OO3XCkOSGtGJFwOnEnqZnsowIrQRC7PTldWSC9Mh6cKxsLAQktEBdaqf84vX3 DpS6UUYwVDWQWgNJtDyFUiFx1KxQ.7_ZAoSEkO2zk7WahJ6aq_R5QA55BRyhAYOnTMezWiEQINqe X7BU8mdf2zwRz4wP0wew6kBTKybCFZP95mAQQXhlqMUbZkuA9PVCnTQe7z4h8RQ2Pn3KJNgopgR1 IUmbIHXyAgT4r.t3wNabY8D.Bdh7aT99AMohI_UcQplI8D0fDqyDIf8ZAdMKlAQ3sey.uUzqokMw wRQsSJ4FyGIPWpc.7WYefhujclI_4uqWnDhGhlowYfWeMVYP6PaePQZ0q_rOvAAvpvToWbVPcvO_ pL3eiTH.l.HOZk3MvqnPmtNOjJ7lSvxkLpNpI0mhpR3s4xKJ58eeMgODzqBAk2KLkOyWyKpozc6d Uu68LoHo4fJZEtTpZPLGb57.PJZ_nNAKDfvgLeFoXGEQCfGqQ9pEV066Ro2m.tdyKUvItA_N7.pH fbUbXHzl7f9mOfQYNyX1hQt7mvs8Xwcw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 May 2020 18:16:22 +0000 Received: by smtp412.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a91220a105656127b80ed8ef3721be0e; Mon, 04 May 2020 18:16:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> Date: Mon, 4 May 2020 11:16:14 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49G9zC3kjCz4XP5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.43 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.940,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.26), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:16:24 -0000 [This report just shows some material for the sendmail SIGSEGV's, based on truss output.] I've returned to using the modern jemalloc because it seems to show problems more, after having caught the earlier reported dhclient example under the older jemalloc context. (Again: jemalloc may be exposing a problem elsewhere.) I had truss monitor sendmail, including following child processes. A child process start and end normally looks like: 963: 3092.707439595 0.000033895 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 2432: 3092.708024959 0.000000000 963: 3092.708136462 0.000470115 fork() =3D 2432 (0x980) 2432: 3092.708441039 0.000033319 thr_self(0x50120000) =3D 0 (0x0) . . . 2432: 3092.717283761 0.000036008 sigaction(SIGQUIT,{ SIG_IGN SA_RESTART = ss_t },{ SIG_IGN SA_RESTART ss_t }) =3D 0 (0x0) 2432: 3092.717544288 0.000034352 sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 = (0x0) 2432: 3092.717799894 0.000035768 close(0) =3D 0 (0x0) 2432: 3092.718174733 0.000103726 = openat(AT_FDCWD,"/dev/null",O_RDONLY,00) =3D 0 (0x0) 2432: 3092.718480437 0.000052091 = openat(AT_FDCWD,"/dev/null",O_WRONLY,00) =3D 4 (0x4) 2432: 3092.718778028 0.000037856 dup2(4,1) =3D 1 (0x1) 2432: 3092.719003051 0.000034255 dup2(4,2) =3D 2 (0x2) 2432: 3092.719225122 0.000033655 close(4) =3D 0 (0x0) 2432: 3092.719437735 0.000047626 fstat(0,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.719679274 0.000037400 fstat(1,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.719908859 0.000035816 fstat(2,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.720138299 0.000033727 clock_gettime(13,{ = 1588570204.000000000 }) =3D 0 (0x0) 2432: 3092.720658945 0.000035360 getpid() =3D 2432 (0x980) 2432: 3092.720931594 0.000048730 = __sysctl("kern.proc.args.2432",4,0x0,0x0,0x508ae000,49) =3D 0 (0x0) 2432: 3092.721572338 0.000062318 = open(".",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,00) =3D 4 (0x4) 2432: 3092.721962132 0.000037808 fcntl(4,F_ISUNIONSTACK,0x0) =3D 0 = (0x0) 2432: 3092.722323792 0.000098613 = getdirentries(4,"\0\0\0\0\0\t\M-I\M^Q\0\0\0\0\0\0"...,4096,{ 0x0 }) =3D = 144 (0x90) 2432: 3092.722944875 0.000036944 getdirentries(4,0x50859000,4096,{ = 0x200 }) =3D 0 (0x0) 2432: 3092.723294461 0.000045250 close(4) =3D 0 (0x0) 2432: 3092.723576400 0.000041144 clock_gettime(13,{ = 1588570204.000000000 }) =3D 0 (0x0) 2432: 3092.723828718 0.000037928 setitimer(0,{ 0.000000, 0.000000 = },0x0) =3D 0 (0x0) 2432: 3092.724092245 0.000035815 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ = }) =3D 0 (0x0) 2432: 3092.724591527 0.000038024 getpid() =3D 2432 (0x980) 2432: 3092.724952323 0.000052955 setuid(0x0) ERR#1 'Operation not = permitted' 2432: 3092.727852159 0.000042969 clock_gettime(4,{ 21633.960374942 }) =3D= 0 (0x0) 2432: 3092.728508193 0.000034327 clock_gettime(4,{ 21633.961033929 }) =3D= 0 (0x0) 2432: 3092.729146608 0.000036872 clock_gettime(4,{ 21633.961670903 }) =3D= 0 (0x0) 2432: 3092.729824967 0.000038360 clock_gettime(4,{ 21633.962349071 }) =3D= 0 (0x0) 2432: 3092.732435446 0.001634793 exit(0x0) =20 2432: 3092.732555855 0.001755202 process exit, rval =3D 0 963: 3092.732638865 0.018571063 SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED = pid=3D2432 uid=3D25 status=3D0 963: 3092.732822864 0.018755062 sigsuspend({ }) ERR#4 'Interrupted = system call' 963: 3092.733076525 0.000039968 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 963: 3092.733447788 0.000076601 wait4(-1,{ EXITED,val=3D0 = },WNOHANG,0x0) =3D 2432 (0x980) 963: 3092.733781410 0.000034783 wait4(-1,0xffffbe60,WNOHANG,0x0) = ERR#10 'No child processes' 963: 3092.734065366 0.000037328 sigreturn(0xffffbe90) EJUSTRETURN 963: 3092.734263408 0.000033295 sigprocmask(SIG_BLOCK,0x0,{ }) =3D 0 = (0x0) (No activity in 963 for about 1800 seconds.) But once it starts failing, the SIGSEGV happens just after the: setuid(0x0) ERR#1 'Operation not permitted' For example: . . . 4745: 37293.335510778 0.000035023 clock_gettime(13,{ = 1588604405.000000000 }) =3D 0 (0x0) 4745: 37293.335754863 0.000037593 setitimer(0,{ 0.000000, 0.000000 = },0x0) =3D 0 (0x0) 4745: 37293.336010253 0.000036200 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ = }) =3D 0 (0x0) 4745: 37293.336488027 0.000033823 getpid() =3D 4745 (0x1289) 4745: 37293.336836797 0.000051995 setuid(0x0) ERR#1 'Operation not = permitted' 4745: 37293.338022675 0.001237873 SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR = trapno=3D768 addr=3D0x506a11f0 4745: 37293.339546520 0.002761718 process killed, signal =3D 11 963: 37293.339627249 0.050797919 SIGNAL 20 (SIGCHLD) code=3DCLD_KILLED = pid=3D4745 uid=3D25 status=3D11 963: 37293.339794781 0.050965451 sigsuspend({ }) ERR#4 'Interrupted = system call' 963: 37293.340038313 0.000037544 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 963: 37293.340329951 0.000070215 wait4(-1,{ SIGNALED,sig=3DSIGSEGV = },WNOHANG,0x0) =3D 4745 (0x1289) 963: 37293.340634048 0.000034903 wait4(-1,0xffffbe60,WNOHANG,0x0) = ERR#10 'No child processes' 963: 37293.340901417 0.000037615 sigreturn(0xffffbe90) EJUSTRETURN 963: 37293.341090122 0.000033319 sigprocmask(SIG_BLOCK,0x0,{ }) =3D 0 = (0x0) (Another about 1800 seconds.) So it seems that sendmail's SIGSEGV always happens during the winding down of the child process: getting ready to exit. So far, it seems that once it starts happening, it happens for each child process created after that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon May 4 21:51:57 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 F20252C461F for ; Mon, 4 May 2020 21:51:57 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49GGlw6cWzz3MQR for ; Mon, 4 May 2020 21:51:56 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id 044Lpm9X081867 for ; Mon, 4 May 2020 23:51:48 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 554C0B2D for ; Mon, 4 May 2020 23:51:48 +0200 (CEST) To: freebsd-current@freebsd.org From: Harry Schmalzbauer Subject: zfs.core, 'send' crashing - how to debug offline? Organization: OmniLAN Message-ID: Date: Mon, 4 May 2020 23:51:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 04 May 2020 23:51:48 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Rspamd-Queue-Id: 49GGlw6cWzz3MQR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-3.74 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[omnilan.de]; IP_SCORE(-2.44)[ip: (-9.22), ipnet: 2a00:e10:2800::/38(-4.59), asn: 61157(1.61), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 21:51:58 -0000 Hello, playing with -current snapshot provides all kinds of surprises :-) The one  regarding the topic: 'zfs send' aborts with "invalid argument". The machine in question doesn't have internet access (but local FreeBSD FTP mirror, so I managed to install matching base-dbg). What debugger am I supposed to use these days for -current?  Sorry for that ignorant/stupid question – all I know about the transition to llvm/clang is that it's still 'cc' ;-) There's still /usr/libexe/kdgb, but I can't use it for my userland core dump, can I? Not beeing able to dump ZFS is a very severe problem for me and I'd like to provide at least some useful problem reports. Any help highly appreciated, thanks, -harry P.S. No matter if I try to send snapshots or unmounted fielsystems - 'send' is always aborting (scrub doesn't detect inconsistencies). P.P.S.: sendmail(8) is back in base!?! and DMA gone???????? P.P.P.S.: efi\freebsd\loader.efi doesn't work well – raised and already commented by bcran@ P.P.P.P.S: kern.vt.fb.default_mode vs. efi_max_resolution for loader.conf(8) was hard to invalidate reading vt(4) – still completely unsure how/if to change non-KMS UEFI/GOP resolution outside loader(8). From owner-freebsd-current@freebsd.org Tue May 5 06:05: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 CD13E2D85BC for ; Tue, 5 May 2020 06:05:11 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GTj21wyHz4MrV for ; Tue, 5 May 2020 06:05:10 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id s8so1159336wrt.9 for ; Mon, 04 May 2020 23:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=/YGgPelTSfnjsa9XI8Hx8EMh+bKNr0TYmOv9sPq4l18=; b=oYDbbi9DPLN4Nz6kqDmVlq87a8asMRETiuAhNCwMJsKGk3G3+Dafguai6rNYowDZLy doeq/7KfvjwN9XNSGpmywKQgWfa4uYaocpwZr7g/MZTABRVRYJcrcayuC6mfAq1B0kXG uobVx1l4YjY4xSVuGehPxtZdAsfLzonU9LLT0pzxnK/JVNH/tcYTq/YN8X+eVEV330IO dmSDYAwN/fWCmSXSGKX8np9VUNrAYREj+T0aT0cCBv6sztNebCSlCzE2Wn7UqIEO1tYD M2FLPVbfn2mn2eTWdtVEcSOxW3EnnE9vw7ciepir7/pjxRZwirzDySs9b11Nt/zwKB5i 7L3A== 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=/YGgPelTSfnjsa9XI8Hx8EMh+bKNr0TYmOv9sPq4l18=; b=hkM5dKJqHOIlb0P3lIc180xEojS2WLp10sS5PkL+OFsfMySY58eFRNiDKJPDJxltBv pyqCPrT1XrPASAhaGOGFhym9knKR7jqseaIe8Jo+ydSh+dCfAJVgO1hce/gCwkfIz5am MOj8lrIhPeWlAaVwQjkWH6vPWBLZT8yya7g8O1HgiZj7RxBDoq2jjajwY3y86FDINXMJ yv/dTHzWcrifGAjBMSqqEW0s4A64FM8FFBYve9gkJjOmpxZIpomaSQPrHG66c0wQsZz2 1Ri2Gs/W74KHPpeSMkR9Gy0XfsaYFwKAKepXd2nWbYy8OZ5M6uiVXxeJQWLDl2M+4VT3 U9kA== X-Gm-Message-State: AGi0Puaquzjh2pU6IoU0W/7t7ZbWHpO8supvGUDwWmU4jG52P/Ym4+SI Sy8ByhAO3PzxVyHTcW/fOAM13n1K X-Google-Smtp-Source: APiQypJp0nJ+Znx9ybRo5ImBZ+CDo8mFF6wcVEEGJ2oIqEhoHF4H7mUIYu+eVrpLGWmXvqXWeNWR+A== X-Received: by 2002:adf:aa8e:: with SMTP id h14mr1823773wrc.371.1588658708316; Mon, 04 May 2020 23:05:08 -0700 (PDT) Received: from ernst.home (p5B023232.dip0.t-ipconnect.de. [91.2.50.50]) by smtp.gmail.com with ESMTPSA id 1sm2099551wmi.0.2020.05.04.23.05.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 23:05:07 -0700 (PDT) Date: Tue, 5 May 2020 08:05:06 +0200 From: Gary Jennejohn To: Harry Schmalzbauer Cc: freebsd-current@freebsd.org Subject: Re: zfs.core, 'send' crashing - how to debug offline? Message-ID: <20200505080506.07460af1@ernst.home> In-Reply-To: References: 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: 49GTj21wyHz4MrV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=oYDbbi9D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[50.50.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-8.66), ipnet: 2a00:1450::/32(-2.31), asn: 15169(-0.43), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 06:05:11 -0000 On Mon, 4 May 2020 23:51:47 +0200 Harry Schmalzbauer wrote: > Hello, > > playing with -current snapshot provides all kinds of surprises :-) > > The one__ regarding the topic: > 'zfs send' aborts with "invalid argument". > The machine in question doesn't have internet access (but local FreeBSD > FTP mirror, so I managed to install matching base-dbg). > What debugger am I supposed to use these days for -current?__ Sorry for > that ignorant/stupid question ___ all I know about the transition to > llvm/clang is that it's still 'cc' ;-) > There's still /usr/libexe/kdgb, but I can't use it for my userland core > dump, can I? > I can't address the other questions, but I'm pretty sure that the gdb from ports is what you want. It's a much newer version than what was under /usr/src. > Not beeing able to dump ZFS is a very severe problem for me and I'd like > to provide at least some useful problem reports. > > Any help highly appreciated, thanks, > > -harry > > P.S. No matter if I try to send snapshots or unmounted fielsystems - > 'send' is always aborting (scrub doesn't detect inconsistencies). > > P.P.S.: sendmail(8) is back in base!?! and DMA gone???????? > P.P.P.S.: efi\freebsd\loader.efi doesn't work well ___ raised and already > commented by bcran@ > P.P.P.P.S: kern.vt.fb.default_mode vs. efi_max_resolution for > loader.conf(8) was hard to invalidate reading vt(4) ___ still completely > unsure how/if to change non-KMS UEFI/GOP resolution outside loader(8). > -- Gary Jennejohn From owner-freebsd-current@freebsd.org Tue May 5 08:52:35 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 7AF492DCE87 for ; Tue, 5 May 2020 08:52:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 49GYQB3h6nz4YR9 for ; Tue, 5 May 2020 08:52:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 45cOfUYVM1nnpRZ33.aMxVMjSiZ4AG_vYL0FwrHrpO7VaAFhdklIEfC9zGIRjyz GXZjb2NYXPub2F3iVpivu3EyANzT9in3EHE0EHurFD3bDJtif3FKJKKlbmwqDLN6v.YL9SMYk2oM CCCqlLImoAINRo79X1TyeVQ3WJsG313XI_QbmSC_WsPNLnlffP.hc1JFPJzdAkhDf9nQ9zqW3UTV zX_dNJyHukdSh54bOiv5oBk7pJUWUy7l9QXs4a1TO1hlah_gcaBcm3F7fSLoNfG6pV9L9d7k3H0J Pc30MGC5yTV5mvmf9lAQVXE1EZFxNXO_fZZEfOhdjDvCbNJouD1PiIra_5Lsr.eKk7O.5biMCueA jPB3KKLa3yrkQmbgQLvC8Z8.gKgLcMpk3B0UUjWQyzRpWSmm7inACIBlZ2d0tfz4u.4JFVY7R01m AyXrbIq0zmw6Yl7koe3FUTYclzbQsaEjnuPXfNyAqqohr3mGsgkgt1Va72ahPtUBe5UicT32yS8Q uabeMpmz2o73du._KFb0cTyPV9bifh_ZMizkiT13MPusvAidZyPC6kO3SnMiUjhXm.ok7m9Q2h3E oEMUd0cGUflqJao1fBguO1tGoh2PNGjurwlU_7tStIqwtdE0v398.NFSDe4jfBM5m3ajfQeTuujO WaXSI.Qx_oA_VhoTWn6CkeQnb4sB8JyzMloIUqLjT8NSdN8l6C6VEw5hBfECUC8188SBZVX27hXF IXwHfEg_AOeJ_Qo0hJm6ZgRuSNVDd3_cwdq.LeTQoHYJpue9uaAS6PCisVjRSBmDZpdKPaTEghUk Z1AN4EfdyyMBiomrcYxLdRWtJWUDXYWp1kdRUYlyX5g6bUZbch70F_ifnIvLkFnK2I4YkLZP384N FGFKCIzlt75XwafGGiQjYqoirgiPBo4ITrYUplwc_WYn3Zwvzmnhk0wXrO8pJJ4N2I4wI.w1TRBd m70VAweMW.t48tj_xYJgUaEfEFIc7urswFyJ5XvZK6fOD9EuhydE0_hk_Z_jKLA8XRZSE4x.QuH9 k1HgRKCapVZHMC5iNdYMfBYN3QShQ4pDA1kezt0TkJK46tdxCTeE037ZjGBTw_HZqMtIqI.4kEfv JatltgZybgNc4mpkd4hA3BA1LdEqZyYh_MiUUy_Cbymj_HvV228fx5Vfa0JCc_fYXmd0saRizQ5Z Rm4aP.ubUk6hpnEltHOqQnIAkcB4wxxR4v66kWo3sBW93k79n.FYD0oWQL6eJDi7oo2uHzsdAFn. Z_o.tSJPhZRhnq.TbpT2p5pjDCATsjKCzDJE0C0.ew2Dcd4YywaelGVJdsvEWCS3oGISsTdm4rH3 2Lv4ZRYlU1MgsRk3sw5nvy7.nc5lXy0PKI4AS6B8tKHaQQ4FUxWq1iYvyA1mF3B764Mw96Qox.5u H2JqwKyJqY_DUvZqQXoBRYYpAk2UWfNLdSibGbgvuOwR1Gw8lz1wwgRsHD20CF_8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 May 2020 08:52:33 +0000 Received: by smtp434.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID da1665613de72442d31e291f1d443e23; Tue, 05 May 2020 08:52:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Tue, 5 May 2020 01:52:27 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49GYQB3h6nz4YR9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.00), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 08:52:35 -0000 [This report just shows an interesting rpcbind crash: a pointer was filled with part of a string instead, leading to a failed memory access attempt from the junk address produced.] Core was generated by `/usr/sbin/rpcbind'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5024405c in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:335 335 cd->recvsize =3D r->recvsize; (gdb) list 330 _setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, = &len, sizeof (len)); 331 } 332=09 333 cd =3D (struct cf_conn *)newxprt->xp_p1; 334=09 335 cd->recvsize =3D r->recvsize; 336 cd->sendsize =3D r->sendsize; 337 cd->maxrec =3D r->maxrec; 338=09 339 if (cd->maxrec !=3D 0) { (gdb) print/c *cd Cannot access memory at address 0x2d202020 FYI: . . . 0x50244050 <+452>: bl 0x502e3404 = <00000000.plt_pic32._setsockopt> 0x50244054 <+456>: lwz r27,80(r29) 0x50244058 <+460>: lwz r3,4(r24) =3D> 0x5024405c <+464>: stw r3,436(r27) Note the 80(r29) use. (gdb) info reg r0 0x50244020 1344552992 r1 0xffffb400 4294947840 r2 0x500a1018 1342836760 r3 0x2328 9000 r4 0x32ef559c 854545820 r5 0x0 0 r6 0xffffb360 4294947680 r7 0xffffb364 4294947684 r8 0x5004733c 1342468924 r9 0x0 0 r10 0x20 32 r11 0x50252ea0 1344614048 r12 0x24200ca0 606080160 r13 0x0 0 r14 0x0 0 r15 0xffffbc28 4294949928 r16 0x10002848 268445768 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5004c044 1342488644 r22 0xffffb63c 4294948412 r23 0x80 128 r24 0x50048010 1342472208 r25 0x14 20 r26 0xffffb630 4294948400 r27 0x2d202020 757080096 r28 0xf 15 r29 0x50047308 1342468872 r30 0x5030112c 1345327404 r31 0x10040000 268697600 pc 0x5024405c 0x5024405c msr cr 0x842000a0 2216689824 lr 0x50244020 0x50244020 ctr 0x50252ea0 1344614048 xer 0x0 0 fpscr 0x0 0 vscr vrsave (gdb) x/s 0x50047308+72 0x50047350: " - - -\n" So it tried to use "- " as a pointer value. It appears that the r29 value was from: 0x50243f90 <+260>: mr r28,r3 0x50243f94 <+264>: lwz r4,0(r24) 0x50243f98 <+268>: lwz r5,4(r24) 0x50243f9c <+272>: mr r3,r28 0x50243fa0 <+276>: bl 0x5024308c 0x50243fa4 <+280>: lwz r27,36(r1) 0x50243fa8 <+284>: mr r29,r3 The makefd_xprt being used as part of: /* * make a new transporter (re-uses xprt) */ newxprt =3D makefd_xprt(sock, r->sendsize, r->recvsize); newxprt->xp_rtaddr.buf =3D mem_alloc(len); if (newxprt->xp_rtaddr.buf =3D=3D NULL) return (FALSE); memcpy(newxprt->xp_rtaddr.buf, &addr, len); newxprt->xp_rtaddr.len =3D len; #ifdef PORTMAP if (addr.ss_family =3D=3D AF_INET || addr.ss_family =3D=3D = AF_LOCAL) { newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; newxprt->xp_addrlen =3D sizeof (struct sockaddr_in); } #endif /* PORTMAP */ if (__rpc_fd2sockinfo(sock, &si) && si.si_proto =3D=3D = IPPROTO_TCP) { len =3D 1; /* XXX fvdl - is this useful? */ _setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &len, sizeof = (len)); } =20 cd =3D (struct cf_conn *)newxprt->xp_p1; =20 cd->recvsize =3D r->recvsize; cd->sendsize =3D r->sendsize; cd->maxrec =3D r->maxrec; FYI: (gdb) print *r $5 =3D {sendsize =3D 9000, recvsize =3D 9000, maxrec =3D 9000} There is more evidence of strings in pointers in *newxprt (xp_tp, oa_base, xp_p1, xp_p2, xp_p3): (gdb) print *newxprt $7 =3D {xp_fd =3D 15, xp_port =3D 0, xp_ops =3D 0x50329e1c, xp_addrlen =3D= 16, xp_raddr =3D {sin_len =3D 16 '\020', sin_family =3D 1 '\001', = sin_port =3D 0, sin_addr =3D {s_addr =3D 0},=20 sin_zero =3D "\000\000\000\000\000\000\000"}, xp_ops2 =3D = 0x756e6978, xp_tp =3D 0x2020 ,=20 xp_netid =3D 0x10010000 , xp_ltaddr =3D {maxlen =3D 0, len =3D 0, buf =3D 0x0}, = xp_rtaddr =3D {maxlen =3D 539828256, len =3D 16, buf =3D 0x50047330}, = xp_verf =3D { oa_flavor =3D 0, oa_base =3D 0x202d2020 , oa_length =3D 538976288}, xp_p1 =3D 0x2d202020, = xp_p2 =3D 0x20202020, xp_p3 =3D 0x2d0a0079, xp_type =3D 543780384} (gdb) print (char*)(&newxprt->xp_verf.oa_base) $24 =3D 0x50047350 " - - -\n" (gdb) print (char*)(&newxprt->xp_p3)+3 $13 =3D 0x50047363 "y in FreeBSD.\n" (gdb) print (char*)(&newxprt->xp_type) $25 =3D 0x50047364 " in FreeBSD.\n" =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue May 5 12:24: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 EA40E2E4AD8 for ; Tue, 5 May 2020 12:24:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 49Gf6c4lRfz3Pvv; Tue, 5 May 2020 12:24:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jVwcR-0008Ux-7b; Tue, 05 May 2020 15:24:15 +0300 Date: Tue, 5 May 2020 15:24:15 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Cc: Cy Schubert , freebsd-current@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <20200505122415.GA20209@zxy.spb.ru> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200430130449.cwsf3x42o6w67gor@ivaldir.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 49Gf6c4lRfz3Pvv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.38)[-0.379,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.15)[0.154,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.36), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 12:24:26 -0000 On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > This way ports with random termcap info to add would be able to do it witho= > > > ut > > > the requirement to wait for a commit in base and a MFC. > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > I will then. > I added that to my TODO Can you also see at termcap/ncurses related code? Latest commit in base do unusable sh/tcsh w/ emacs tramp mode and inside screen. And paste from screen too (many unneed trailing space from lines). From owner-freebsd-current@freebsd.org Tue May 5 12:29: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 ABA462E4DAB for ; Tue, 5 May 2020 12:29:01 +0000 (UTC) (envelope-from bapt@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) server-signature RSA-PSS (4096 bits) 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 49GfCx46p5z3QCX; Tue, 5 May 2020 12:29:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 6B31F127D6; Tue, 5 May 2020 12:29:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 1BE88D8D1E; Tue, 5 May 2020 14:29:00 +0200 (CEST) Date: Tue, 5 May 2020 14:29:00 +0200 From: Baptiste Daroussin To: Slawa Olhovchenkov Cc: Cy Schubert , freebsd-current@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <20200505122900.4tp5tfjp4ac3r2dm@ivaldir.net> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <20200505122415.GA20209@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="75bzhx66yao3fsni" Content-Disposition: inline In-Reply-To: <20200505122415.GA20209@zxy.spb.ru> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 12:29:01 -0000 --75bzhx66yao3fsni Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: >=20 > > > > This way ports with random termcap info to add would be able to do = it witho=3D > > > > ut > > > > the requirement to wait for a commit in base and a MFC. > > >=20 > > > This is probably outside of my scope at the moment but, yes, agreed. > > >=20 > > I will then. > > I added that to my TODO >=20 > Can you also see at termcap/ncurses related code? > Latest commit in base do unusable sh/tcsh w/ emacs > tramp mode and inside screen. I am not aware of sh/tcsh being unsable at all. I heard about an emacs thin= gy but not being an emacs guy myself I haven't reproduced. I can have a look but I would need a more specific feedback with examples of failures. Best regards, Bapt --75bzhx66yao3fsni Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl6xXAsACgkQY4mL3PG3 Plq3MA/+JVOW0lE/FfjhxcMAdkqMj6AjNs7w0Z4b5Oje6Ws8MfIDa7Z5PzKmbN1Q VCwYOi5ilgd5OkPg0388neoZtUm0p6fEpcOzXYzmxLHw2SnWA+ZG8rMzP8JM7Qx1 LloFu9iomTxHp4hLR273gM1VmlJztQjmjkQ7yiYrUDRQ8UG0usbNCMG9Cvu9Fa6k 2RyzDyfPwnR9Szg8Oa+v5tu2YfF1N5hWRupbiiWlTBuFSABI/ElsPa4dpQVImOVI mTaQ8loXgFB6FLmyisQRkzaTL1YNeoj65utnRyhNklIl97aAjOjAIk7yf+l0dQfg ip1P/N+MUEVXMSkcL+RcUx/9evMnQFtpA7VGcArGIWYuZxoHu9/YdzxF1GlPDTiZ frYsJzLLIWmpopUrP6mrWhzXIIMhCefydgTLM479nhXHHVKQyg1i4U1zCmg44G33 IJl9MhQVRx58/h7hIifhqQJVyukyfROoPe8dMJa1elCvhiVxFF3+eP4w03guqWvb 4FTQO4MdiYCh8u7JFOJMb28BEz+2grZtB3gzvIe0TPZF/RsdQktxhekt3ylUn1z5 IHT2+xm8gbjUW4lfKBlbMpJtGvefk0I1oEAGew4ZGgjMANWlGrqyg5HLom5E3yaf c8+QLHmUkPh0nmqbM8cKcvJNVTgPg+II3uEG/dtwZFQHPC7JjYs= =WuA3 -----END PGP SIGNATURE----- --75bzhx66yao3fsni-- From owner-freebsd-current@freebsd.org Tue May 5 12:48: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 99E672E575B for ; Tue, 5 May 2020 12:48:01 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 49Gfdr618lz3wdM; Tue, 5 May 2020 12:48:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jVwzO-0008cZ-Dp; Tue, 05 May 2020 15:47:58 +0300 Date: Tue, 5 May 2020 15:47:58 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Cc: Cy Schubert , freebsd-current@freebsd.org Subject: Re: sysutils/screen-ncurses port Message-ID: <20200505124758.GB20209@zxy.spb.ru> References: <202004291841.03TIfkZh081308@slippy.cwsent.com> <20200430075337.3wdzglshhorcd2qn@ivaldir.net> <202004301256.03UCusls050859@slippy.cwsent.com> <20200430130449.cwsf3x42o6w67gor@ivaldir.net> <20200505122415.GA20209@zxy.spb.ru> <20200505122900.4tp5tfjp4ac3r2dm@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505122900.4tp5tfjp4ac3r2dm@ivaldir.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 49Gfdr618lz3wdM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 12:48:02 -0000 On Tue, May 05, 2020 at 02:29:00PM +0200, Baptiste Daroussin wrote: > On Tue, May 05, 2020 at 03:24:15PM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 30, 2020 at 03:04:49PM +0200, Baptiste Daroussin wrote: > > > > > > > This way ports with random termcap info to add would be able to do it witho= > > > > > ut > > > > > the requirement to wait for a commit in base and a MFC. > > > > > > > > This is probably outside of my scope at the moment but, yes, agreed. > > > > > > > I will then. > > > I added that to my TODO > > > > Can you also see at termcap/ncurses related code? > > Latest commit in base do unusable sh/tcsh w/ emacs > > tramp mode and inside screen. > > I am not aware of sh/tcsh being unsable at all. I heard about an emacs thingy > but not being an emacs guy myself I haven't reproduced. > > I can have a look but I would need a more specific feedback with examples of > failures. Do you see this my mail https://lists.freebsd.org/pipermail/freebsd-stable/2020-April/092251.html ? This is reproduce by different gay too. tcsh inside screen at editing near to end of screen produce grabadge at multiple lines. Not sure about 100% reproduce this. From owner-freebsd-current@freebsd.org Tue May 5 17:43: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 88C0513E699; Tue, 5 May 2020 17:43:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GnBl5X4Dz4Hqp; Tue, 5 May 2020 17:43:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f41.google.com with SMTP id e9so2846634iok.9; Tue, 05 May 2020 10:43:27 -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=4Vfbu8HHnV2fyS16OYkkavTpNf0vFyBhFUXDNmVDdLQ=; b=UFXFs56bygxs0Ua1RF/an2RLehPTRBt+zeLCgWdMkt62cJuaJVDDRhF1n3HXaEEAo9 i6cUTaj8nf/Z+YhZns9mRevIaacVREpy2AX40Q6NMmRScTIM2B3NarYELQPeXUysOgkt 4q9ro7HCqqoRJiK0y4y1VuCIEpQCW+fGu8MOSloIfpbZTetawQDPLlpmavLE4T0TJSWD 7Jlo9gYJitpnAUsOROceXMVPKM9+0fUonXzrdaUNTUURwVjtcSkliz/fUAPutHTZTiK0 oazS2RllGCZBhNxd8fHHu8CKRiWDGoqPshK4jCvNwIKm4BmNoc5kUlja8Y9oK1ZfCp5/ sJfw== X-Gm-Message-State: AGi0Pub+I1RIYwuftpF1udstey8OYWAS8mq2HgpyHgWNa2mlK9LmA9Rp TfiTltArwr9yxMaL7htUpIDm3x4ZqT6LMwRyUtvebqjJGz8= X-Google-Smtp-Source: APiQypKIJvspRFQN6Q6Zj/5mXcHcjswZMF5jS6F8Sw2TSq+Zwmv0A/jvAZS94O7GlK+wUdld4GUcSafZCa9HFb7kYiM= X-Received: by 2002:a02:966a:: with SMTP id c97mr4728069jai.106.1588700606020; Tue, 05 May 2020 10:43:26 -0700 (PDT) MIME-Version: 1.0 From: Ed Maste Date: Tue, 5 May 2020 13:43:14 -0400 Message-ID: Subject: HEADS-UP: /usr/bin/objdump to be removed To: FreeBSD Ports , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49GnBl5X4Dz4Hqp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.90)[ip: (-3.61), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[41.166.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[41.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 05 May 2020 17:43:28 -0000 I plan to remove the obsolete GNU binutils 2.17.50 objdump from the base system in the next few days. If you currently use objdump from the base system you can give llvm-objdump a try instead - it is mostly compatible, but has a few missing options and the output format may be slightly different. Otherwise, install binutils from ports or packages. There are a few ports that need adjustment as well, identified in exp-run PR 212319: - PR 246229 databases/galera Fixed by adding a ${LOCALBASE}/bin/objdump:devel/binutils BUILD_DEPENDS. - PR 241159 devel/powerpc64-gcc (and other *-gcc ports) The build finishes, but "make package" fails because certain files are missing. - PR 241157: www/node (and node*) - No PR yet, graphics/embree Once this is committed the only remaining obsolete binutils tool will be /usr/bin/as, on amd64 and i386 only. I expect it will also be removed for FreeBSD 13.0. From owner-freebsd-current@freebsd.org Wed May 6 23:52: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 9EBEC2E3012 for ; Wed, 6 May 2020 23:52:48 +0000 (UTC) (envelope-from current@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49HYLS3lh5z4NkJ for ; Wed, 6 May 2020 23:52:48 +0000 (UTC) (envelope-from current@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 80C272E3011; Wed, 6 May 2020 23:52: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 808142E3010 for ; Wed, 6 May 2020 23:52:48 +0000 (UTC) (envelope-from current@freebsd.org) Received: from ap.apidicity.live (ap.apidicity.live [45.95.171.141]) (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 49HYLS1lg4z4NkH for ; Wed, 6 May 2020 23:52:47 +0000 (UTC) (envelope-from current@freebsd.org) From: freebsd.org support To: current@freebsd.org Subject: You have 5 Pending incoming emails Date: 6 May 2020 16:52:58 -0700 Message-ID: <20200506165258.ABC164D0C483CF62@freebsd.org> X-Rspamd-Queue-Id: 49HYLS1lg4z4NkH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-0.99)[-0.986,0]; ASN(0.00)[asn:42864, ipnet:45.95.168.0/22, country:HU] MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 06 May 2020 23:52:48 -0000 From owner-freebsd-current@freebsd.org Wed May 6 23:58: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 02B262E3C20 for ; Wed, 6 May 2020 23:58:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 49HYSX4mtSz4PGy for ; Wed, 6 May 2020 23:58:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .tMrsL8VM1lHXQP1QD1XvZPA.c2.3hOgHOxwWwSCQi09XDVpsXAd5ewGprIy6L1 bNqzZCaCCdY2_oNp9HMnBiRgfiyaGnEKtxgGWZdWmz1RJk4QhDnh23eirM4m3r.Cp94YkOaV0Uj8 O9awIIh7GssVjPFBgOzK3AQ6OyV5Wg009wwsVB8HZ.P7GFFvF4n1LnY7bJKCHIONZhrfVI7iGHZu F.iq.YkK.5wFY7EpOFv81jf30uZoxZqIsAV5jX.cE0iZvNDn8yh3zdcvPYlgOPz.IwEbFJq47R_7 PUY0Pk6QnDPKq9dROHiEr6hcaBs1cYNFzdE2tYQCGa29cOL_HtpRVCntJltJ9jrsQM7MP1I4a55c T0JLEdVJS9qVFJCyE35Kh9e0.9lqI7eaJyZ2f2L9OhRH.ec7k6aIgeuGbwiCl7guWS8wnRpRj1Bg RhurB93CwUj0tnHEpWh2GUP584a_4ds_HCr1fcWc.VHZFRXN2PtSB8s92qMIzthS9Yk4TSKrb_1s e8OQEyHk2zOlSJ_psMp0Gutl6_U2Z.jtnC.izImKdMyBTvCfEdX4xiIJ7U083wCIpxTEqRQ_jXN6 TiLh0Mxers3xJtQkAkAb32eII10xTvJEg_vcNQn5K6hfi_5Lp6URAFx1t6_SU62sXZZ4_uLjyjF2 xZd8KuAxpPmhFtFEBQ0rfy13B4P4e9NHfLz1SRsJpYpf.YPMU8kvglnsVD7UdUjfthU.fL88pXGD LXXFOoWUOAl06Vyr8cMGqWoH9aTSpr7BmGtvWTU7w4Z_U_Ai0CAObR51iPwT4slwjmbRHst.vwac yKC3IZoKuLFui2oYI1fdiBjAk9z.rtaBaLVjT7OR38SE7HJOCxCG_CMcB8Td.AARjZxj7l1S79Ot ciTVOg6xySj5cNq3fQvUXRggsU5AG8U5OmKz6KfS3qUQIzMuzwonRwUSB_dHtsKAyMWcSt5f1nBp 7sZ0T19os.GFqLkSmQbbDXKeKFLO13UtWQHEreoPW_ZDnDL9UnJ0Mba9uTu26E4wVGDqtagV52tQ s8VsNV0VLej2ISum1AMkBZSMdCYz_vBw6IltGJk0puzOyiblXVhn5I8WyWllgE1RileXEhUjbMuK dvP45LHE1ChrPbSXWyRpIBNkqmpKUZco83BwXUaTJmtksHC4DchQ7h4JFZqeWK9WoF5a7MiVYW0s LlJ_Ov54Q9nLSzZFgXTP5iAD4W4KtYIyolYDjkSBhqxotIY2i03RxPNDqJBHnI86Jepp9lyk0a5k b3xxYVEJ0fPg.o0ILqXANdpq2hMVUKAojQZxthATbCyUNEw_0jQY3S6DNBtrTR08nbynZ.gDhXc. XXZdgQwtOlr4EeOT1TxyJROSIIRELaKQSIuL4p4SMSpazgeSKBXhOkprKZi.UJJQD9BprLa7bqOP zxGyZxjAONZf6EQH51EvguF0u2wPsDIJeeRuyCFsz1.EPpmUO6BFN9p2Xw5OLIemj4iwU Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 May 2020 23:58:03 +0000 Received: by smtp408.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 275644a7f42f203160b12da5531da6aa; Wed, 06 May 2020 23:57:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> Date: Wed, 6 May 2020 16:57:55 -0700 Cc: Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49HYSX4mtSz4PGy X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.05 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.65)[-0.648,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.90)[-0.905,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.24), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 06 May 2020 23:58:06 -0000 [This explores process crashes that happen during system shutdown, in a context not having MALLOC_PRODUCTION=3D . So assert failures are reported as the stopping points.] It looks like shutdown -p now, shutdown -r now, and the like can lead some processes to assert during their exit attempt, including a sshd failure (that I've not seen before), rpcbind, and nfsd. I show information about the observed asserts for those below. sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : (gdb) bt=20 #0 thr_kill () at thr_kill.S:4 #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160, = alloc_ctx=3D, is_internal=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 #7 0x5087b294 in __free (ptr=3D0x5008a180) at jemalloc_jemalloc.c:2852 #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 . . . (gdb) up #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 67 (void)raise(SIGABRT); (gdb) up #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 315 assert(slab =3D=3D extent_slab_get(extent)); (gdb) list 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ More fully: 285 JEMALLOC_ALWAYS_INLINE void 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, 287 alloc_ctx_t *alloc_ctx, bool slow_path) { 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); 289 assert(ptr !=3D NULL); 290=09 291 if (unlikely(tcache =3D=3D NULL)) { 292 arena_dalloc_no_tcache(tsdn, ptr); 293 return; 294 } 295=09 296 szind_t szind; 297 bool slab; 298 rtree_ctx_t *rtree_ctx; 299 if (alloc_ctx !=3D NULL) { 300 szind =3D alloc_ctx->szind; 301 slab =3D alloc_ctx->slab; 302 assert(szind !=3D SC_NSIZES); 303 } else { 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, 306 (uintptr_t)ptr, true, &szind, &slab); 307 } 308=09 309 if (config_debug) { 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, 321 slow_path); 322 } else { 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); 324 } 325 } rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) : (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 #8 0x50265690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, recvsize=3D9000) = at /usr/src/lib/libc/rpc/svc_vc.c:250 #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #12 0x50265d1c in svc_getreq_poll (pfdp=3D, pollretval=3D1)= at /usr/src/lib/libc/rpc/svc.c:739 #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 #14 0x10014ad8 in main (argc=3D, argv=3D) = at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 (gdb) up 3 #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 159 assert(ret =3D=3D sz_size2index_compute(size)); (gdb) print ret $1 =3D 0 154 JEMALLOC_ALWAYS_INLINE szind_t 155 sz_size2index_lookup(size_t size) { 156 assert(size <=3D SC_LOOKUP_MAXCLASS); 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) 158 >> SC_LG_TINY_MIN]); 159 assert(ret =3D=3D sz_size2index_compute(size)); 160 return ret; 161 } nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) (also, but a different caller of sz_size2index): (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 #7 0x50206294 in __free (ptr=3D0x50041028) at jemalloc_jemalloc.c:2852 #8 0x50287ec8 in ns_src_free (src=3D0x50329004, srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12, = free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 #15 #16 0x00000000 in ?? () (gdb) up 3 #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 200 assert(ret =3D=3D sz_index2size_compute(index)); (ret is optimized out.) 197 JEMALLOC_ALWAYS_INLINE size_t 198 sz_index2size_lookup(szind_t index) { 199 size_t ret =3D (size_t)sz_index2size_tab[index]; 200 assert(ret =3D=3D sz_index2size_compute(index)); 201 return ret; 202 } Booting and immediately trying something like: service nfsd stop did not lead to a failure. But may be after a while it would and be less drastic than a reboot or power down. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu May 7 07:46:40 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 BCE8913ACA3 for ; Thu, 7 May 2020 07:46:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 49HlsC2BZWz3FJV for ; Thu, 7 May 2020 07:46:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OPNsNFcVM1lg_qAnMTDQTK3p6D7_v8d4a1hkBTBFATb9D8EdW0fAtSiyXqJ_CmM cC.GFKzJu6vWWOjImpl4nGd10z5jcwXRE4L_Zr3b.DPcoxvN6IhM_G._7lnBVJjz9648dLc9jexF 88y8_cXMAv5Hzl3H3sk14v8aqNLLWqPcjXLWmL_sWASxHG4ypnCqrDY8f9ErNDPy8rMrXjYFm.oV zXp1g3oynvSj3CPH5lvDZSbW_FHh_u5SSBuZAwBwEJPOZKXJ5n6d7fWQnWds0zoPMhLx37njt4RB 2tylxDS5OVSvqRO.LFRvLdQFynLF7QyAfwfpcidUu0Eu9WQkqdsrcFB7VjEeB_.xFFVkjwe.USmE flW3X0xWiZtx9qIUdwx7br59WvcMQzmeg_cWGFm_Y68hz6scsIONmz5l5LuvvYoCi65qNuB3PkQ4 ZxJP0quX2TFsJ7EYkvOSBrVISRtgGRj4yyV_7CIVm7doZz14jL1K04qtx22O26ym4aHszXrgNXVI C9Khdn6yqiWdJFIIjV6Ftz5PpuM_D8KaMqQSHKtDeD1Fd6fbQJXb.YMLHyjFvHEYVvNKMXfhamFM rEUizUep4d4jwJemX6RVG1C1SCbdO3VQlkq3Ege.fTMTHhrbmlEBCWXLJQQ6vQ1_AkheZFBKl5Ja QTVSXsuCnRIgrf4Sfj.pb5UDAjIlHLx2hpVQo.H.xFz3CpHrQU.46Oog8HYvLCZW.qlacrf3V.3P 9fWbk5tD5wYtkkIhtTcMt05EZGZOUyafwcOZnqsT7KsYbvk_lTTJsA5.AOpU7LykWndBZ2iw_YBZ 7Zx7b8c8Hlmdh0Xk0iTih77k2jSBxhDtFptkEGRzzAnx9FbN1TjURg24VkSnHmjFuYaK6kugFAr7 aln_UFbHTq3Z1JzdzISv3qZDhAzS8WCQmau2ctWHqezQvvKcXeOMDsRaYanFPtCYClbeUNd7MBgx 7jurHTue0kNeQl5nCWrUkNFemFYCXwL8jGGg06parSo9RXv2cYNafsr7FXBr1L3L9Dv6rECpnhU7 nWdtoPD6ayz6WNkjXadg0Pa9.dkTj7WPeguLP_X04u3ne1Epb.aH3bM6nmu8XhyVi0uBNMdocGW2 Qc_Ew2E6OQacImCkp8xkF4HtOmqhEwRWoyI7IGBz6vaRQBwtH5MnK3a1u3Sl0kQFew9qCBeQQTC9 QURNKJRimayT2l55hHSo32SmQ1PKeNDunnJ2s_dGsgPM.3WGHWw8P5fTftVy4aUP61vaVjKZkxnV wOPcZwnnyaqFpUt52YMNRy_r3WCIXGXmdywPo5HqjeESQSKOrZJl4wtI8SCgTC7C31F58Si.Y4Hi KV8U06tHi8ewwIHnLchtdcpMxYLBdZ3_EcO5IKJYqubtNJuvwUQfLxEA2n3cQM33BgnZ_dVYCGvA MFCn73Vdfk6ZK9f5X.lo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2020 07:46:37 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2d65ee9bbf6f83b7a0d0434cbd6c20e4; Thu, 07 May 2020 07:46:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> Date: Thu, 7 May 2020 00:46:30 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49HlsC2BZWz3FJV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.15 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.716,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.929,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.75), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[32.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[32.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 07:46:40 -0000 [__je_sz_size2index_tab seems messed up in 2 of the asserting contexts: first 384 are zero in both. More before that is also messed up (all zero). I show the details later below.] On 2020-May-6, at 16:57, Mark Millard wrote: > [This explores process crashes that happen during system > shutdown, in a context not having MALLOC_PRODUCTION=3D . > So assert failures are reported as the stopping points.] >=20 > It looks like shutdown -p now, shutdown -r now, and the > like can lead some processes to assert during their exit > attempt, including a sshd failure (that I've not seen > before), rpcbind, and nfsd. I show information about the > observed asserts for those below. >=20 >=20 > sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >=20 > (gdb) bt=20 > #0 thr_kill () at thr_kill.S:4 > #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 > #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160,= alloc_ctx=3D, is_internal=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 > #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 > #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 > #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 > #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 > #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >=20 > . . . > (gdb) up > #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > 67 (void)raise(SIGABRT); > (gdb) up > #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 > 315 assert(slab =3D=3D extent_slab_get(extent)); >=20 > (gdb) list > 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, > 312 rtree_ctx, (uintptr_t)ptr, true); > 313 assert(szind =3D=3D extent_szind_get(extent)); > 314 assert(szind < SC_NSIZES); > 315 assert(slab =3D=3D extent_slab_get(extent)); > 316 } > 317=09 > 318 if (likely(slab)) { > 319 /* Small allocation. */ >=20 > More fully: >=20 > 285 JEMALLOC_ALWAYS_INLINE void > 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, > 287 alloc_ctx_t *alloc_ctx, bool slow_path) { > 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); > 289 assert(ptr !=3D NULL); > 290=09 > 291 if (unlikely(tcache =3D=3D NULL)) { > 292 arena_dalloc_no_tcache(tsdn, ptr); > 293 return; > 294 } > 295=09 > 296 szind_t szind; > 297 bool slab; > 298 rtree_ctx_t *rtree_ctx; > 299 if (alloc_ctx !=3D NULL) { > 300 szind =3D alloc_ctx->szind; > 301 slab =3D alloc_ctx->slab; > 302 assert(szind !=3D SC_NSIZES); > 303 } else { > 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, > 306 (uintptr_t)ptr, true, &szind, &slab); > 307 } > 308=09 > 309 if (config_debug) { > 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, > 312 rtree_ctx, (uintptr_t)ptr, true); > 313 assert(szind =3D=3D extent_szind_get(extent)); > 314 assert(szind < SC_NSIZES); > 315 assert(slab =3D=3D extent_slab_get(extent)); > 316 } > 317=09 > 318 if (likely(slab)) { > 319 /* Small allocation. */ > 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, > 321 slow_path); > 322 } else { > 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); > 324 } > 325 } The following are only shown for contrast with the later cases of lots of zeros showing up where below shows non-zero values (taken from sshd.core, which failed differently): (gdb) x/4x __je_arenas+16368/4 0x50981ab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 (gdb) print/x __je_arenas_lock=20 $1 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x5008bf00, = postponed_next =3D 0x50974070, locked =3D {repr =3D 0x0}}}, witness =3D = {name =3D 0x50760b04, rank =3D 0x3, comp =3D 0x0, opaque =3D 0x0, link =3D= { qre_next =3D 0x50981b10, qre_prev =3D 0x50981b10}}, lock_order =3D = 0x0} (gdb) print/x __je_narenas_auto $2 =3D 0x8 (gdb) print/x malloc_conf $3 =3D 0x0 (gdb) print/x __je_ncpus $4 =3D 0x2 (gdb) print/x __je_manual_arena_base $5 =3D 0x9 (gdb) print/x __je_sz_pind2sz_tab=20 $6 =3D {0x1000, 0x2000, 0x3000, 0x4000, 0x5000, 0x6000, 0x7000, 0x8000, = 0xa000, 0xc000, 0xe000, 0x10000, 0x14000, 0x18000, 0x1c000, 0x20000, = 0x28000, 0x30000, 0x38000, 0x40000, 0x50000, 0x60000,=20 0x70000, 0x80000, 0xa0000, 0xc0000, 0xe0000, 0x100000, 0x140000, = 0x180000, 0x1c0000, 0x200000, 0x280000, 0x300000, 0x380000, 0x400000, = 0x500000, 0x600000, 0x700000, 0x800000, 0xa00000, 0xc00000,=20 0xe00000, 0x1000000, 0x1400000, 0x1800000, 0x1c00000, 0x2000000, = 0x2800000, 0x3000000, 0x3800000, 0x4000000, 0x5000000, 0x6000000, = 0x7000000, 0x8000000, 0xa000000, 0xc000000, 0xe000000,=20 0x10000000, 0x14000000, 0x18000000, 0x1c000000, 0x20000000, = 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, 0x60000000, = 0x70000000, 0x70001000} (gdb) print/x __je_sz_index2size_tab $7 =3D {0x8, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70, 0x80, 0xa0, 0xc0, = 0xe0, 0x100, 0x140, 0x180, 0x1c0, 0x200, 0x280, 0x300, 0x380, 0x400, = 0x500, 0x600, 0x700, 0x800, 0xa00, 0xc00, 0xe00, 0x1000,=20 0x1400, 0x1800, 0x1c00, 0x2000, 0x2800, 0x3000, 0x3800, 0x4000, = 0x5000, 0x6000, 0x7000, 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, = 0x14000, 0x18000, 0x1c000, 0x20000, 0x28000, 0x30000, 0x38000,=20 0x40000, 0x50000, 0x60000, 0x70000, 0x80000, 0xa0000, 0xc0000, = 0xe0000, 0x100000, 0x140000, 0x180000, 0x1c0000, 0x200000, 0x280000, = 0x300000, 0x380000, 0x400000, 0x500000, 0x600000, 0x700000,=20 0x800000, 0xa00000, 0xc00000, 0xe00000, 0x1000000, 0x1400000, = 0x1800000, 0x1c00000, 0x2000000, 0x2800000, 0x3000000, 0x3800000, = 0x4000000, 0x5000000, 0x6000000, 0x7000000, 0x8000000, 0xa000000,=20 0xc000000, 0xe000000, 0x10000000, 0x14000000, 0x18000000, 0x1c000000, = 0x20000000, 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, = 0x60000000, 0x70000000} (gdb) print/x __je_sz_size2index_tab $2 =3D {0x0, 0x0, 0x1, 0x2, 0x2, 0x3, 0x3, 0x4, 0x4, 0x5, 0x5, 0x6, 0x6, = 0x7, 0x7, 0x8, 0x8, 0x9, 0x9, 0x9, 0x9, 0xa, 0xa, 0xa, 0xa, 0xb, 0xb, = 0xb, 0xb, 0xc, 0xc, 0xc, 0xc, 0xd, 0xd, 0xd, 0xd, 0xd,=20 0xd, 0xd, 0xd, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xf, 0xf, 0xf, = 0xf, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, = 0x11 , 0x12 ,=20 0x13 , 0x14 , 0x15 , 0x16 , 0x17 , 0x18 , 0x19 ,=20 0x1a , 0x1b , 0x1c } > rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) = : >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 > #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 > #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 > #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 > #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 > #8 0x50265690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 > #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:250 > #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 > #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 > #12 0x50265d1c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 > #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 > #14 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 > (gdb) up 3 > #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 > 159 assert(ret =3D=3D sz_size2index_compute(size)); > (gdb) print ret > $1 =3D 0 >=20 > 154 JEMALLOC_ALWAYS_INLINE szind_t > 155 sz_size2index_lookup(size_t size) { > 156 assert(size <=3D SC_LOOKUP_MAXCLASS); > 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) > 158 >> SC_LG_TINY_MIN]); > 159 assert(ret =3D=3D sz_size2index_compute(size)); > 160 return ret; > 161 } gdb reports for sz_size2index_tab (really JEMALLOC_N(sz_size2index_tab), i.e., __je_sz_size2index_tab): (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } Also: (gdb) x/4x __je_arenas+16368/4 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 (gdb) print/x __je_arenas_lock = =20 $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0} (gdb) print/x __je_narenas_auto $9 =3D 0x0 (gdb) print/x malloc_conf =20 $10 =3D 0x0 (gdb) print/x __je_ncpus=20 $11 =3D 0x0 (gdb) print/x __je_manual_arena_base $12 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab =20 $13 =3D {0x0 } (gdb) print/x __je_sz_index2size_tab $14 =3D {0x0 } > nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) [Correction: That should have referenced sz_index2size_lookup(index).] > (also, but a different caller of sz_size2index): [Correction: The "also" comment should be ignored: sz_index2size_lookup(index) is referenced below.] >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 > #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 > #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 > #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 > #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 > #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 > #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 > #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12, = free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 > #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 > #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 > #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 > #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 > #15 > #16 0x00000000 in ?? () >=20 > (gdb) up 3 > #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 > 200 assert(ret =3D=3D sz_index2size_compute(index)); >=20 > (ret is optimized out.) >=20 > 197 JEMALLOC_ALWAYS_INLINE size_t > 198 sz_index2size_lookup(szind_t index) { > 199 size_t ret =3D (size_t)sz_index2size_tab[index]; > 200 assert(ret =3D=3D sz_index2size_compute(index)); > 201 return ret; > 202 } (gdb) print/x __je_sz_index2size_tab $3 =3D {0x0 } Also: (gdb) x/4x __je_arenas+16368/4 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 (gdb) print/x __je_arenas_lock = =20 $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0} (gdb) print/x __je_narenas_auto $9 =3D 0x0 (gdb) print/x malloc_conf =20 $10 =3D 0x0 (gdb) print/x __je_ncpus=20 $11 =3D 0x0 (gdb) print/x __je_manual_arena_base $12 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab =20 $13 =3D {0x0 } (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } > Booting and immediately trying something like: >=20 > service nfsd stop >=20 > did not lead to a failure. But may be after > a while it would and be less drastic than a > reboot or power down. More detail: So, for rpcbind and nfds at some point a large part of __je_sz_size2index_tab is being stomped on, as is all of __je_sz_index2size_tab and more. For rpcbind, the following area is zero but in a live process is not all-zero (I show the partially non-zero live-process context instead of the all-zero .core file content): 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 0x5034cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cb00 <__je_arenas_lock+64>: 0x00000000 0x5033f070 = 0x00000000 0x00000000 0x5034cb10 <__je_arenas_lock+80>: 0x5012bb04 0x00000003 = 0x00000000 0x00000000 0x5034cb20 <__je_arenas_lock+96>: 0x5034cb10 0x5034cb10 = 0x00000000 0x00000000 Then the memory in the crash continues to be zero until: 0x5034d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b Notice the interesting page boundary for where non-zero is first available again! Between __je_arenas_lock and __je_sz_size2index_tab are: 0x5034cb30 __je_narenas_auto 0x5034cb38 malloc_conf 0x5034cb3c __je_ncpus 0x5034cb40 __je_manual_arena_base 0x5034cb80 __je_sz_pind2sz_tab 0x5034ccc0 __je_sz_index2size_tab 0x5034ce80 __je_sz_size2index_tab For nfsd, it is similar (again showing the partially non-zero live process context instead of the all-zeros from the .core file): 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 Then the memory in the crash continues to be zero until: 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b Notice the interesting page boundary for where non-zero is first available again! Between __je_arenas_lock and __je_sz_size2index_tab are: 0x5030cb30 __je_narenas_auto 0x5030cb38 malloc_conf 0x5030cb3c __je_ncpus 0x5030cb40 __je_manual_arena_base 0x5030cb80 __je_sz_pind2sz_tab 0x5030ccc0 __je_sz_index2size_tab 0x5030ce80 __je_sz_size2index_tab Note: because __je_arenas is normally mostly zero for these contexts, I can not tell where the memory trashing started, only where it replaced non-zero values with zeros. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu May 7 12:41: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 5898C2C7F20 for ; Thu, 7 May 2020 12:41:28 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49HtPN1lhtz47Xg for ; Thu, 7 May 2020 12:41:28 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3C1F82C7F1F; Thu, 7 May 2020 12:41: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 3BE732C7F1E for ; Thu, 7 May 2020 12:41:28 +0000 (UTC) (envelope-from bapt@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) server-signature RSA-PSS (4096 bits) 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 49HtPN0plWz47Xf for ; Thu, 7 May 2020 12:41:28 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id F32542ACE for ; Thu, 7 May 2020 12:41:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id 34FBADCB4D; Thu, 7 May 2020 14:41:26 +0200 (CEST) Date: Thu, 7 May 2020 14:41:26 +0200 From: Baptiste Daroussin To: current@FreeBSD.org Subject: Move from termcap(5) to terminfo(5) Message-ID: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 12:41:28 -0000 Hello everyone, I can't find any proper rationale in our history (maybe I missed it) which explains why our ncurses is stuck on using termcap(5) instead of terminfo(5) Except an argument in the Makefile that builds ncurses: "Used instead of the hideous read_termcap.c abomination." Which I do not find really useful. I would like to make the move from termcap to terminfo which would give us the bonus to be able to track terminfo sources from upstream aka ncurses and to add and use tic(1). Given the very few people that are actually maintaining the termcap database. I don't think there is a good rationale at keeping our own format (as far as I know everyone moved to terminfo(5)) and parser. Without any strong arguments against it I will start working on that move by next week. If you have some knowledge you want to share: "be careful about this or that" I would be more than happy to collect it, to make sure the transition is as smooth as possible. Best regards, Bapt From owner-freebsd-current@freebsd.org Thu May 7 12:58: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 2163B2D85EE for ; Thu, 7 May 2020 12:58:01 +0000 (UTC) (envelope-from steffen@sdaoden.eu) 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 49HtmS5758z48Nw for ; Thu, 7 May 2020 12:58:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by mailman.nyi.freebsd.org (Postfix) id AFD3D2D85ED; Thu, 7 May 2020 12:58:00 +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 AFA0D2D85EC for ; Thu, 7 May 2020 12:58:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49HtmS3nfMz48Nt; Thu, 7 May 2020 12:58:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 14F6C16054; Thu, 7 May 2020 14:57:53 +0200 (CEST) Date: Thu, 07 May 2020 14:57:52 +0200 From: Steffen Nurpmeso To: Baptiste Daroussin Cc: current@FreeBSD.org Subject: Re: Move from termcap(5) to terminfo(5) Message-ID: <20200507125752.OhGX4%steffen@sdaoden.eu> In-Reply-To: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> References: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> Mail-Followup-To: Baptiste Daroussin , current@FreeBSD.org User-Agent: s-nail v14.9.19-42-g6235a28f OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 49HtmS3nfMz48Nt X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 12:58:01 -0000 Just my one cent. Baptiste Daroussin wrote in <20200507124126.g4z5op4cyv45pmxn@ivaldir.net>: |I can't find any proper rationale in our history (maybe I missed it) which |explains why our ncurses is stuck on using termcap(5) instead of terminf\ |o(5) ... |I would like to make the move from termcap to terminfo which would \ |give us the |bonus to be able to track terminfo sources from upstream aka ncurses and to |add and use tic(1). | |Given the very few people that are actually maintaining the termcap \ |database. I |don't think there is a good rationale at keeping our own format (as \ |far as I |know everyone moved to terminfo(5)) and parser. | |Without any strong arguments against it I will start working on that \ |move by |next week. | |If you have some knowledge you want to share: "be careful about this \ |or that" I |would be more than happy to collect it, to make sure the transition \ |is as smooth |as possible. If termcap is implemented by means of termcap and not by means of internally converting termcap to curses which then does the job, then termcap is a very small library and the terminal descriptions almost as powerful. They miss some keys, otherwise i do not know what they miss. Otherwise termcap is terribly expensive and my MUA tries to go for -ltinfo before falling back to -lcurses or -lcursesw. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Thu May 7 13:21:57 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 621582D9007 for ; Thu, 7 May 2020 13:21:57 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49HvJ50w51z49xR for ; Thu, 7 May 2020 13:21:57 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1F5132D9006; Thu, 7 May 2020 13:21:57 +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 1F1502D9005 for ; Thu, 7 May 2020 13:21:57 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49HvJ42Lj9z49xH; Thu, 7 May 2020 13:21:56 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id x17so6369085wrt.5; Thu, 07 May 2020 06:21: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:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=C0cvV2FJXoVDTM2koiUz4SlbNkUHL5pU1d0Mt0MyRp0=; b=U6opMQHCljmkMd1/BquDqgu9tDG+RcG49oDDMyecQmeZHpxPnXeJr1bjoibc+ICVXB WfSHwvq1dg3U1ddq0wu3cWU/frUFvzseF9pv/hvvMEB4HxL7SnFpu8XTACRyptTVV4uG p8lG4O7RFrSvOqh2HY3CGiEAuW4LGoJsN5PQz1SSg8N8WLun/y7icfc1wrD/5Suh7xhw VT3sANgHAI+YpCyMNs7HHarkQ3Wwd8YQL5UiW422+EqxJCBTVrP+lLfz9QiQ/hEpEXoV Si4b1LMfs3spDadOsCpqAvn9VUvhosjHxo7zIFyfE1eDGHma9Tz/Z4lkh4nu63Ky6gUO TQJA== X-Gm-Message-State: AGi0PuazFtWZrdmXp8ZOBjarbafu1DstfL9OO1F6s/0X+3J+mFANZ/M7 YQV99pMUyqUSxRSwIQJgowfZ8Gte X-Google-Smtp-Source: APiQypLdN9boTduVFdyE5oY+a9PTnTEalJAa1Jf6rRlImTmW0WoWJlRtaKbHJ8WCOguUJXUDatH2HQ== X-Received: by 2002:adf:e7cb:: with SMTP id e11mr14642953wrn.145.1588857714453; Thu, 07 May 2020 06:21:54 -0700 (PDT) Received: from ?IPv6:2a02:8109:98c0:1bc0:5e5f:67ff:fef4:ffd8? ([2a02:8109:98c0:1bc0:5e5f:67ff:fef4:ffd8]) by smtp.gmail.com with ESMTPSA id h17sm8139144wmm.6.2020.05.07.06.21.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 06:21:53 -0700 (PDT) Subject: Re: Move from termcap(5) to terminfo(5) To: Baptiste Daroussin , current@FreeBSD.org References: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> From: Mateusz Piotrowski <0mp@FreeBSD.org> Message-ID: Date: Thu, 7 May 2020 15:22:20 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 49HvJ42Lj9z49xH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mpp302@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=mpp302@gmail.com X-Spamd-Result: default: False [-2.21 / 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)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-0.21)[ip: (-0.20), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[50.221.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FORGED_SENDER(0.30)[0mp@FreeBSD.org,mpp302@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[50.221.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[0mp@FreeBSD.org,mpp302@gmail.com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 13:21:57 -0000 Hi, On 5/7/20 2:41 PM, Baptiste Daroussin wrote: > Hello everyone, > > I can't find any proper rationale in our history (maybe I missed it) which > explains why our ncurses is stuck on using termcap(5) instead of terminfo(5) > Except an argument in the Makefile that builds ncurses: > "Used instead of the hideous read_termcap.c abomination." > > Which I do not find really useful. > > I would like to make the move from termcap to terminfo which would give us the > bonus to be able to track terminfo sources from upstream aka ncurses and to > add and use tic(1). That's great! I've been bitten by termcap not being well understood by the open source community many times. I am supporting the move to terminfo wholeheartedly. > If you have some knowledge you want to share: "be careful about this or that" I > would be more than happy to collect it, to make sure the transition is as smooth > as possible. What comes to my mind is that we should probably pay special attention to terminal ports, like x11/sterm. We might need to tell those ports to install their terminfo files. I don't remember the details though. Cheers, Mateusz From owner-freebsd-current@freebsd.org Thu May 7 13:24:37 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 D13CA2D9238 for ; Thu, 7 May 2020 13:24:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49HvM95Ft2z4BDB for ; Thu, 7 May 2020 13:24:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id B45862D9236; Thu, 7 May 2020 13:24:37 +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 B42142D9235 for ; Thu, 7 May 2020 13:24:37 +0000 (UTC) (envelope-from bapt@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) server-signature RSA-PSS (4096 bits) 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 49HvM94NFqz4BD9; Thu, 7 May 2020 13:24:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from ivaldir.etoilebsd.net (etoilebsd.net [178.32.217.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 7A3EC3108; Thu, 7 May 2020 13:24:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by ivaldir.etoilebsd.net (Postfix, from userid 1001) id A4CE9DCC06; Thu, 7 May 2020 15:24:36 +0200 (CEST) Date: Thu, 7 May 2020 15:24:36 +0200 From: Baptiste Daroussin To: Mateusz Piotrowski <0mp@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Move from termcap(5) to terminfo(5) Message-ID: <20200507132436.x6gzrtqls7grwbik@ivaldir.net> References: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uk33hxiyeltbz75r" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 13:24:37 -0000 --uk33hxiyeltbz75r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 07, 2020 at 03:22:20PM +0200, Mateusz Piotrowski wrote: > Hi, >=20 > On 5/7/20 2:41 PM, Baptiste Daroussin wrote: > > Hello everyone, > >=20 > > I can't find any proper rationale in our history (maybe I missed it) wh= ich > > explains why our ncurses is stuck on using termcap(5) instead of termin= fo(5) > > Except an argument in the Makefile that builds ncurses: > > "Used instead of the hideous read_termcap.c abomination." > >=20 > > Which I do not find really useful. > >=20 > > I would like to make the move from termcap to terminfo which would give= us the > > bonus to be able to track terminfo sources from upstream aka ncurses an= d to > > add and use tic(1). > That's great! I've been bitten by termcap not being well understood by the > open source community many times. I am supporting the move to terminfo > wholeheartedly. > > If you have some knowledge you want to share: "be careful about this or= that" I > > would be more than happy to collect it, to make sure the transition is = as smooth > > as possible. >=20 > What comes to my mind is that we should probably pay special attention to > terminal ports, like x11/sterm. We might need to tell those ports to inst= all > their terminfo files. I don't remember the details though. >=20 All their terminfo files are already in recent ncurses, so we will have not= hing to do with them. Best regards, Bapt --uk33hxiyeltbz75r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAl60DBQACgkQY4mL3PG3 PlquyBAArPL9iiECOIF+A5v1IZO+/sus/1HAffq+BLkuj/p4q0RRU3ju89nW+xml mMHD31aGT2qmH5bnD1xaTiLnErHSLWW8cnYaWBlAI2DxJmmqclDAHiCCyb1VXK7e t+6LGIPLhOHF01ngy+PkuZ4SXFxRqrkiZNMThy8/sHR0EAz/eLrknWEAe8g2+tk8 i8e3Indw9fHRY9lSg2mizNjGFOPaWcDudkHyuq7Z2VvuVCFIHs9WcVi8CvIodwts TTXYYGiMnPoCWrlLgqkgT4zwFjk9X9tc1I46ZOS7GDc7JVCCZBm8Pp+kqaTQsMUi JRqcvC+Oa2OZ1/JwYPjTAj5POa3bvWt2LOQ49iNOaQ4GkhQzUQ6sqyQRKotZIYUH Tb7ii58B/w54KjYjpJK1avCvam/A3W678BrmF1tnZn0nNlCzL0uFyA5gFPearBvF FfHcmyVJV0uEkkLHEnTgsGfOdgYOSKXo2d7oCpcOMOqRtYsxv3yTWwxDIViX/0m/ cXV9sUzQlh2kDEIJAU58SuuFxF9Q12FKCTENc39rkdbbr+YoVvox1t+htuvr9B4c iJ7GDxooWH0Q7sdGyK0LXMTt72t6ow4RX75VuohZ40dISFX71vS97ufartMthhhb f4hrw2Kopmyrrp+LaX2B1AQxXEcRVijLzuqxQQaV7Nsbsydn3fk= =eQek -----END PGP SIGNATURE----- --uk33hxiyeltbz75r-- From owner-freebsd-current@freebsd.org Thu May 7 16:35:18 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 7FAD12DDA16 for ; Thu, 7 May 2020 16:35:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49HzbB1Q8Zz4NWy for ; Thu, 7 May 2020 16:35:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.nyi.freebsd.org (Postfix) id 308A82DDA15; Thu, 7 May 2020 16:35:18 +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 305662DDA14 for ; Thu, 7 May 2020 16:35:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Hzb96fR5z4NWx; Thu, 7 May 2020 16:35:17 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 047GZGbM048719; Thu, 7 May 2020 09:35:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 047GZGC3048718; Thu, 7 May 2020 09:35:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005071635.047GZGC3048718@gndrsh.dnsmgr.net> Subject: Re: Move from termcap(5) to terminfo(5) In-Reply-To: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> To: Baptiste Daroussin Date: Thu, 7 May 2020 09:35:16 -0700 (PDT) CC: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49Hzb96fR5z4NWx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 16:35:18 -0000 > Hello everyone, > > I can't find any proper rationale in our history (maybe I missed it) which > explains why our ncurses is stuck on using termcap(5) instead of terminfo(5) > Except an argument in the Makefile that builds ncurses: > "Used instead of the hideous read_termcap.c abomination." > > Which I do not find really useful. > > I would like to make the move from termcap to terminfo which would give us the > bonus to be able to track terminfo sources from upstream aka ncurses and to > add and use tic(1). > > Given the very few people that are actually maintaining the termcap database. I > don't think there is a good rationale at keeping our own format (as far as I > know everyone moved to terminfo(5)) and parser. > > Without any strong arguments against it I will start working on that move by > next week. > > If you have some knowledge you want to share: "be careful about this or that" I > would be more than happy to collect it, to make sure the transition is as smooth > as possible. The feedback I have from the few people that *are* effected by our lack of use of terminfo is positive on this change. Our use of termcap is a pain for them, especially with the base vs ports issues. As far as I am aware the termcap vs terminfo is simply historical in nature with no strong reason to change it. It use to be that both had pretty close shares of the supported by software segment. That historical precedence has worn thin, as there is very little support for termcap today. > Best regards, > Bapt -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Thu May 7 16:38: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 088732DDC68 for ; Thu, 7 May 2020 16:38:39 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Hzg21k0wz4Nq8 for ; Thu, 7 May 2020 16:38:37 +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 201E556468 for ; Thu, 7 May 2020 11:38:31 -0500 (CDT) To: freebsd-current From: Eric van Gyzen Subject: ${COMPILER_VERSION} < 40300 Message-ID: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> Date: Thu, 7 May 2020 11:38:24 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 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: 49Hzg21k0wz4Nq8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-2.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SUBJECT_HAS_CURRENCY(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; DMARC_NA(0.00)[vangyzen.net]; TO_DN_ALL(0.00)[]; SUBJ_ALL_CAPS(2.03)[27]; IP_SCORE(-2.99)[ip: (-7.23), ipnet: 2607:fc50:1000::/36(-3.85), asn: 36236(-3.80), country: US(-0.05)]; 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]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 16:38:39 -0000 If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, which ones should I keep? I would probably confine it to head, so I could prune quite a few. Eric From owner-freebsd-current@freebsd.org Thu May 7 17:01: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 7CDBC2DE3E7 for ; Thu, 7 May 2020 17:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49J0930pH6z4QKG for ; Thu, 7 May 2020 17:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1B71B2DE3E6; Thu, 7 May 2020 17:01:11 +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 1B37A2DE3E5 for ; Thu, 7 May 2020 17:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J0916RFvz4QK4 for ; Thu, 7 May 2020 17:01:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id k81so6861711qke.5 for ; Thu, 07 May 2020 10:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Bc5Q2AfLEL/SjpjHLVSTj+cATQyVNnLYMxyRZZSbko=; b=MolNqRb7E2Lu+lXitnWC5le1ZyIkc1qu8lZoHbczFz8SgEHI54t06zorDvrdWhlwuh lcToqAyRrSb4cwn/cFybDDDwRM8NLIpOP2NEPWg3MgmJ2Yv4Rh0QerEn6Y6ffAOZgF/F 7MeR3Pk04OmNu9DsBVj6UFlA1QZYRuZbfVK/jsCL9QXcL5AWEa/wj+SuQQsch59uv8dy NGGw+a+ERsFACNjWyL57/jFQsJwiFZak9iGqzRHkAkEd2br0WRSczd52lnREzkM71M1k taZXnfWlwu56jRPvhGi3eVIy4hDawWKkIZS3lP/6yY0/sQ7rLCv/WVyrj94SyQL5Rcdd 3C9A== 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=0Bc5Q2AfLEL/SjpjHLVSTj+cATQyVNnLYMxyRZZSbko=; b=swaJhtss/hb3irIm2m4Z/WdZdCoR8BgQxrWsAC2amqhTpm9tkBBh1XXwsK+ivC96f0 b3hMF6NpWq6A2qx1zArrtLlOjDrMUhJpfUSsbrTNblRIkblvezF3/oMmxwWvssEiCxx1 A4pta4P3hpDAAwhtXVSMs+uTMZEqGamJQHYrumh7r5RDgkIwqdB02kLHNe+Hzr6x9Da3 bI2gAYRLRQSTcDmvfJaeDyNiU1fWtQY+TKDw8C4rWR7KW0Gz8VVRXsrBGyDjEfVzIdO6 X2IH7igBTdvawiZmXg9eHEPfh3BY4GzVrSlfTlLw9mHhHXcF6IGrBJsWZpKZTVit3r09 WeMQ== X-Gm-Message-State: AGi0PuYYlIrezX5HBparWxRJXPZkiGPEn3J7n6JVPY1hMw8KBKd4n46i CvMln52GiQkHPwg3lsJ1uNp1938aSciamkkNlOcR+aPpjlo= X-Google-Smtp-Source: APiQypJH1UJ7xoCC5pujG5Flb7yArP2SFZFv8FHRfuE5oJM/tH0uDamZoFwSIp1ch9W4GhdD3fnnElBkIrR8cmvp4DU= X-Received: by 2002:a37:4955:: with SMTP id w82mr14199872qka.240.1588870868832; Thu, 07 May 2020 10:01:08 -0700 (PDT) MIME-Version: 1.0 References: <20200507124126.g4z5op4cyv45pmxn@ivaldir.net> <202005071635.047GZGC3048718@gndrsh.dnsmgr.net> In-Reply-To: <202005071635.047GZGC3048718@gndrsh.dnsmgr.net> From: Warner Losh Date: Thu, 7 May 2020 11:00:56 -0600 Message-ID: Subject: Re: Move from termcap(5) to terminfo(5) To: "Rodney W. Grimes" Cc: Baptiste Daroussin , FreeBSD Current X-Rspamd-Queue-Id: 49J0916RFvz4QK4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=MolNqRb7; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72b) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[b.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.02)[ip: (-9.30), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 17:01:11 -0000 On Thu, May 7, 2020 at 10:35 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Hello everyone, > > > > I can't find any proper rationale in our history (maybe I missed it) > which > > explains why our ncurses is stuck on using termcap(5) instead of > terminfo(5) > > Except an argument in the Makefile that builds ncurses: > > "Used instead of the hideous read_termcap.c abomination." > > > > Which I do not find really useful. > > > > I would like to make the move from termcap to terminfo which would give > us the > > bonus to be able to track terminfo sources from upstream aka ncurses and > to > > add and use tic(1). > > > > Given the very few people that are actually maintaining the termcap > database. I > > don't think there is a good rationale at keeping our own format (as far > as I > > know everyone moved to terminfo(5)) and parser. > > > > Without any strong arguments against it I will start working on that > move by > > next week. > > > > If you have some knowledge you want to share: "be careful about this or > that" I > > would be more than happy to collect it, to make sure the transition is > as smooth > > as possible. > > The feedback I have from the few people that *are* effected by our > lack of use of terminfo is positive on this change. > Our use of termcap is a pain for them, especially with the base vs > ports issues. > There are a number of people, though, that have custom TERMCAP entries in their environment, or that do special things with /etc/termcap that will need to be consulted. The TERMCAP env variable is likely the hardest to convert, though they work around various bugs that have been in various flavors of ncurses over the years. The impact here is likely small, but likely non-zero as some of the bugs are worked around in other ways these days (eg screen save/restore: bug or feature). nanobsd used to deploy a tiny termcap file for space reasons. There's a number of other custom image building scripts in the community that I'm aware of that do this too, though I don't think any are publicly available. The reworking isn't super hard for nanobsd, so long as tic produced target independent binaries. There may be some work needed in nanobsd if the tic files are big in aggregate to trim them down to vt100/xterm/cons25. > As far as I am aware the termcap vs terminfo is simply historical in > nature with no strong reason to change it. It use to be that both > had pretty close shares of the supported by software segment. That > historical precedence has worn thin, as there is very little support > for termcap today. > terminfo was AT&T System V and very jealously guarded at the start of the project. Given the other issues the project had in the early days with USL, poking the bear by switching to terminfo, even one that was clean room done, was simply not an option. It was BSD and there has been zero pressure to change until this thread (though I see others have brushed up against this issue before now)... As with other deprecations of user facing interfaces, announcing the timeline, etc should be done here. It's not a huge deal, assuming tic produces sensible binaries that are platform neutral. If it doesn't, then the transition will be harder... Warner From owner-freebsd-current@freebsd.org Thu May 7 17:17: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 82D3C2DEE93 for ; Thu, 7 May 2020 17:17:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J0XN3D0Lz4RbK for ; Thu, 7 May 2020 17:17:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id f13so392340qkh.2 for ; Thu, 07 May 2020 10:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=znq2NZRYNCEH1YEXe4TJzrnlqdELstWdC1jrfodxSmo=; b=X7lcHKJmT1sJEonAqfGkVhj1u3kHm6jZC3LeyBOTUUGSaIE3NKQ0gPy2ecrcFEGFK3 cWvzTDi6fZsWbOKaIU4hV4xCSfJ5S6TjexMah3HqBJDutJArZ6lqJsXn7MNNGCeFYS04 O8nJoo+JflfdKrtXSTiejN+ZmYIIEqAwOPt2e75hnjHFcjXK0s0ypnIvY6pc8XKEv5GL Xw97CkTovr5j+Yr8YJ18FbVxWbUa6AUkeAKlSGqgqPMNSe2P9xSUIeGTT1MvoqJ4DU+u 7HHs2wmAUrOQgbM3QRulrb/AhxVGmWnCJjs9rb5FkNXCZUfqQd/5na9xcrLfOm0ywwFz jrsg== 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=znq2NZRYNCEH1YEXe4TJzrnlqdELstWdC1jrfodxSmo=; b=Sho2wpjwar1tpLFLMBVdQUS7jaRz/rZOjwNzeWeYh7imKxJ7TWwocfvrZg5yhZDsLi ZqWHmu4wp/Mi/q0DwXFCIzYgToxm5Vb9Z0tmIq8jYThzshRZLCBnU0vbZfmVT0X9p1Ho a3Mh1xWkTwL8psWXLJN2dADNL8RYWrQKMGRwBqAQ06O1bMGG2NYvzGpExGwiJyuzjhA3 zFRye+GtpwfC2UPyTLarxgV3ZIAxHucLeUUTtAdfm0XAhZGHFZmdtHK/ZkDeYV4SKMg5 VPXhVTrfBQpMugJLt0o29ZgdGnzr/SgK++hSBVcs7RWgt5FBC3EmduFMF9hrggFJZckt RwMA== X-Gm-Message-State: AGi0PuZBoNmMRDgMDeiD1lBkXbuinNYkuPylub33hz+HmuUc0RQxGtwN lXReOYOai+JJu1ZGtq9QTqjHZfD5r1alxYkSEQLEVMOrk1w= X-Google-Smtp-Source: APiQypKa7yOf5rTRwZTJwYIpqv8ZYtjcX+L2AX67utkTBdcd0kas+a+JnSWlwFYOlMseTYRAhE8fKHy5llq7vKr0Pl4= X-Received: by 2002:a37:a9d6:: with SMTP id s205mr13993340qke.380.1588871875184; Thu, 07 May 2020 10:17:55 -0700 (PDT) MIME-Version: 1.0 References: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> In-Reply-To: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> From: Warner Losh Date: Thu, 7 May 2020 11:17:43 -0600 Message-ID: Subject: Re: ${COMPILER_VERSION} < 40300 To: Eric van Gyzen Cc: freebsd-current X-Rspamd-Queue-Id: 49J0XN3D0Lz4RbK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=X7lcHKJm; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::734) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; SUBJ_ALL_CAPS(2.03)[27]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.99)[ip: (-9.12), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 17:17:58 -0000 On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen wrote: > If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, > which ones should I keep? I would probably confine it to head, so I > could prune quite a few. > Anything in the bootstrap path should remain, especially in the install portion of the bootstrap path since we don't require new compilers for that. I doubt there's more than one or two of these and there may be zero. The rest can go away. We should also look at taking out the fmake workarounds in the tree too. Most of these are in src/Makefile and src/Makefile.inc. Warner From owner-freebsd-current@freebsd.org Thu May 7 19:06: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 C24182E1EA0 for ; Thu, 7 May 2020 19:06:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.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 49J2xn1tTQz4Zqb for ; Thu, 7 May 2020 19:06:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ymUHbHAVM1nxMvrnBetflgticeA9_e1fEHsRRHVMHn0m2qCUC.tTFaDDeMuvFXO JMGVC3bkuHxMQ3Gh2xCgvxW4jAGW6JsVsVXrx8HToAGqGgMVCwx1cYVzQ9BNdiu1NFjhrJMUFNX3 KOPexm9XqKb_62elZnxldMtv6kG67pexLkfYuhEK9GdrVmZoPQPmNmfeTxtTlAdcoHeStPre1w2O Ce0doYJbKpkR39sSZm7clKruyOcUtyvXTNQKFn7L63qLYm.IDcrwekGcccVJct0Ihcw2hnVctlXD VSEssj9Dyqr2B8XK9PhIyZSiXkN.kIiXSKma5esYqfAREwas0lVoLKmkQ1LJLvMFnI2a630GjD9L bUJeisuATRy2OHPRzFKAlAyymPTwMzg23QeWoBQKvLBwzp_JsDmBQOzRWZOdGWkXkJAQAJghNNjL aWdUNOc5seAEdCA7qBs7Em9miC5WHxmYlNanPibU9x0x2Y5Ih_9c1MdOB8edHM3MfA0BmDcw2e3A A4.xhSVnMHvFB2kl9IwAlP1jFpNEoDUbsMwYPJaoSvuzv2BSwPcGvGqHkX870PPgfrDj32d7O7hn ul_vXE4u42qUxd.KMVyI27S7uGVNDXmzyuT2d6ZGROYtvob__cL6xBmNhT7C_81b5aCwSyJOUbTs cx9f__cSs8bOGlC6sbtxRs8VqrLaxHyJKvoZvsbIfFkLs0M9ANzOXEzG5fllGBnUNFCI6bIS9WCx ZcllYQuVYqpLDvuhS3h00YppZc4LDLZN40bnsZj8VOafpMtgoC1fWEllCewltGw11jV.Had9Mfud f5LxYdj3CXef8em.11Zv.Pdt6qDYCD0har50cPmDgT13cSYL.O9GsbK5DeSxdNqciTJuv5LdcKob xgHlWPjb8dxR1fHYXgieiHprpzMBHpz_kL_K_kLqp0i6xs9QiMQ17mZ5mo5pVrRbyXro1TUn2Bvc pF2WP6I6vjM6G55BVesaEl.VAgS3mxTJVMps52zZfq2mw0BStsODtQZ3SAQKf7KEZlXoNx91xXLz WTkybn.q9c5UzDLu_pX1aJDr1fGQPp9asliXeImYT1l4DsySQU8fuGnx.k5RleIMVwH7cRVr1BOj .cPbQvbcsNyHLvizcNWwqzHzYpopO3_gkwVXcRYlerQgiUztzU.1zWxpYOa7HQXowhAs5bFoHsbl 7fMk0lceaJTOCuM1_z3Ab_FRuiMuIV6cheVf_Ai.QzEGOw3.XCr7gyDL1t61cLC8LPareeeH_x9E zl1CVhlvBMkpWhiJiXIpICBhd1uWUqLpd8oakTxub26b3x4Zzgk0gT5OlK6YeMs_vL58OepvSMNH nf9yMHViwKnvByXTPJAQsxNKB8TrDLI7Z5PwSOpjXusG59yUk6.nEwKCAlr3DT5uOpYO1ufMP5XF PZSUUB1BRwmXrx2to51w4MVcqCV.DLSwqh7fFh9IaiCi8sY5qZObGhxPpPGX_.w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2020 19:06:35 +0000 Received: by smtp434.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f7716cd2133ed3096a69b5432fcac9e7; Thu, 07 May 2020 19:06:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> Date: Thu, 7 May 2020 12:06:15 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49J2xn1tTQz4Zqb X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-0.08), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 19:06:38 -0000 [mountd failure example: also at sz_size2index_lookup assert for the same zero'd memory problem.] > On 2020-May-7, at 00:46, Mark Millard wrote: >=20 > [__je_sz_size2index_tab seems messed up in 2 of the > asserting contexts: first 384 are zero in both. More > before that is also messed up (all zero). I show the > details later below.] >=20 > On 2020-May-6, at 16:57, Mark Millard wrote: >=20 >> [This explores process crashes that happen during system >> shutdown, in a context not having MALLOC_PRODUCTION=3D . >> So assert failures are reported as the stopping points.] >>=20 >> It looks like shutdown -p now, shutdown -r now, and the >> like can lead some processes to assert during their exit >> attempt, including a sshd failure (that I've not seen >> before), rpcbind, and nfsd. I show information about the >> observed asserts for those below. >>=20 >>=20 >> sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >>=20 >> (gdb) bt=20 >> #0 thr_kill () at thr_kill.S:4 >> #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >> #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, alloc_ctx=3D, is_internal=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 >> #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 >> #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 >> #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 >> #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 >> #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >>=20 >> . . . >> (gdb) up >> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> 67 (void)raise(SIGABRT); >> (gdb) up >> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >> 315 assert(slab =3D=3D extent_slab_get(extent)); >>=20 >> (gdb) list >> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >> 312 rtree_ctx, (uintptr_t)ptr, true); >> 313 assert(szind =3D=3D extent_szind_get(extent)); >> 314 assert(szind < SC_NSIZES); >> 315 assert(slab =3D=3D extent_slab_get(extent)); >> 316 } >> 317=09 >> 318 if (likely(slab)) { >> 319 /* Small allocation. */ >>=20 >> More fully: >>=20 >> 285 JEMALLOC_ALWAYS_INLINE void >> 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, >> 287 alloc_ctx_t *alloc_ctx, bool slow_path) { >> 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); >> 289 assert(ptr !=3D NULL); >> 290=09 >> 291 if (unlikely(tcache =3D=3D NULL)) { >> 292 arena_dalloc_no_tcache(tsdn, ptr); >> 293 return; >> 294 } >> 295=09 >> 296 szind_t szind; >> 297 bool slab; >> 298 rtree_ctx_t *rtree_ctx; >> 299 if (alloc_ctx !=3D NULL) { >> 300 szind =3D alloc_ctx->szind; >> 301 slab =3D alloc_ctx->slab; >> 302 assert(szind !=3D SC_NSIZES); >> 303 } else { >> 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, >> 306 (uintptr_t)ptr, true, &szind, &slab); >> 307 } >> 308=09 >> 309 if (config_debug) { >> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >> 312 rtree_ctx, (uintptr_t)ptr, true); >> 313 assert(szind =3D=3D extent_szind_get(extent)); >> 314 assert(szind < SC_NSIZES); >> 315 assert(slab =3D=3D extent_slab_get(extent)); >> 316 } >> 317=09 >> 318 if (likely(slab)) { >> 319 /* Small allocation. */ >> 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, >> 321 slow_path); >> 322 } else { >> 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); >> 324 } >> 325 } >=20 > The following are only shown for contrast with the later > cases of lots of zeros showing up where below shows > non-zero values (taken from sshd.core, which failed > differently): >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x50981ab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > (gdb) print/x __je_arenas_lock=20 > $1 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x5008bf00, = postponed_next =3D 0x50974070, locked =3D {repr =3D 0x0}}}, witness =3D = {name =3D 0x50760b04, rank =3D 0x3, comp =3D 0x0, opaque =3D 0x0, link =3D= { > qre_next =3D 0x50981b10, qre_prev =3D 0x50981b10}}, lock_order =3D = 0x0} > (gdb) print/x __je_narenas_auto > $2 =3D 0x8 > (gdb) print/x malloc_conf > $3 =3D 0x0 > (gdb) print/x __je_ncpus > $4 =3D 0x2 > (gdb) print/x __je_manual_arena_base > $5 =3D 0x9 > (gdb) print/x __je_sz_pind2sz_tab=20 > $6 =3D {0x1000, 0x2000, 0x3000, 0x4000, 0x5000, 0x6000, 0x7000, = 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, 0x14000, 0x18000, 0x1c000, = 0x20000, 0x28000, 0x30000, 0x38000, 0x40000, 0x50000, 0x60000,=20 > 0x70000, 0x80000, 0xa0000, 0xc0000, 0xe0000, 0x100000, 0x140000, = 0x180000, 0x1c0000, 0x200000, 0x280000, 0x300000, 0x380000, 0x400000, = 0x500000, 0x600000, 0x700000, 0x800000, 0xa00000, 0xc00000,=20 > 0xe00000, 0x1000000, 0x1400000, 0x1800000, 0x1c00000, 0x2000000, = 0x2800000, 0x3000000, 0x3800000, 0x4000000, 0x5000000, 0x6000000, = 0x7000000, 0x8000000, 0xa000000, 0xc000000, 0xe000000,=20 > 0x10000000, 0x14000000, 0x18000000, 0x1c000000, 0x20000000, = 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, 0x60000000, = 0x70000000, 0x70001000} > (gdb) print/x __je_sz_index2size_tab > $7 =3D {0x8, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70, 0x80, 0xa0, = 0xc0, 0xe0, 0x100, 0x140, 0x180, 0x1c0, 0x200, 0x280, 0x300, 0x380, = 0x400, 0x500, 0x600, 0x700, 0x800, 0xa00, 0xc00, 0xe00, 0x1000,=20 > 0x1400, 0x1800, 0x1c00, 0x2000, 0x2800, 0x3000, 0x3800, 0x4000, = 0x5000, 0x6000, 0x7000, 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, = 0x14000, 0x18000, 0x1c000, 0x20000, 0x28000, 0x30000, 0x38000,=20 > 0x40000, 0x50000, 0x60000, 0x70000, 0x80000, 0xa0000, 0xc0000, = 0xe0000, 0x100000, 0x140000, 0x180000, 0x1c0000, 0x200000, 0x280000, = 0x300000, 0x380000, 0x400000, 0x500000, 0x600000, 0x700000,=20 > 0x800000, 0xa00000, 0xc00000, 0xe00000, 0x1000000, 0x1400000, = 0x1800000, 0x1c00000, 0x2000000, 0x2800000, 0x3000000, 0x3800000, = 0x4000000, 0x5000000, 0x6000000, 0x7000000, 0x8000000, 0xa000000,=20 > 0xc000000, 0xe000000, 0x10000000, 0x14000000, 0x18000000, 0x1c000000, = 0x20000000, 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, = 0x60000000, 0x70000000} > (gdb) print/x __je_sz_size2index_tab > $2 =3D {0x0, 0x0, 0x1, 0x2, 0x2, 0x3, 0x3, 0x4, 0x4, 0x5, 0x5, 0x6, = 0x6, 0x7, 0x7, 0x8, 0x8, 0x9, 0x9, 0x9, 0x9, 0xa, 0xa, 0xa, 0xa, 0xb, = 0xb, 0xb, 0xb, 0xc, 0xc, 0xc, 0xc, 0xd, 0xd, 0xd, 0xd, 0xd,=20 > 0xd, 0xd, 0xd, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xf, 0xf, 0xf, = 0xf, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, = 0x11 , 0x12 ,=20 > 0x13 , 0x14 , 0x15 , 0x16 , 0x17 , 0x18 , 0x19 ,=20 > 0x1a , 0x1b , 0x1c } >=20 >=20 >> rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) = : >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 >> #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 >> #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 >> #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 >> #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 >> #8 0x50265690 in svc_xprt_alloc () at = /usr/src/lib/libc/rpc/svc.c:541 >> #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:250 >> #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 >> #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >> #12 0x50265d1c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 >> #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 >> #14 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 >> (gdb) up 3 >> #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 >> 159 assert(ret =3D=3D sz_size2index_compute(size)); >> (gdb) print ret >> $1 =3D 0 >>=20 >> 154 JEMALLOC_ALWAYS_INLINE szind_t >> 155 sz_size2index_lookup(size_t size) { >> 156 assert(size <=3D SC_LOOKUP_MAXCLASS); >> 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) >> 158 >> SC_LG_TINY_MIN]); >> 159 assert(ret =3D=3D sz_size2index_compute(size)); >> 160 return ret; >> 161 } >=20 > gdb reports for sz_size2index_tab (really = JEMALLOC_N(sz_size2index_tab), > i.e., __je_sz_size2index_tab): >=20 > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_index2size_tab > $14 =3D {0x0 } >=20 >=20 >> nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) >=20 > [Correction: That should have referenced sz_index2size_lookup(index).] >=20 >> (also, but a different caller of sz_size2index): >=20 > [Correction: The "also" comment should be ignored: > sz_index2size_lookup(index) is referenced below.] >=20 >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 >> #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 >> #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 >> #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 >> #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 >> #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 >> #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12,= free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 >> #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 >> #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 >> #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 >> #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 >> #15 >> #16 0x00000000 in ?? () >>=20 >> (gdb) up 3 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >>=20 >> (ret is optimized out.) >>=20 >> 197 JEMALLOC_ALWAYS_INLINE size_t >> 198 sz_index2size_lookup(szind_t index) { >> 199 size_t ret =3D (size_t)sz_index2size_tab[index]; >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >> 201 return ret; >> 202 } >=20 > (gdb) print/x __je_sz_index2size_tab > $3 =3D {0x0 } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 >> Booting and immediately trying something like: >>=20 >> service nfsd stop >>=20 >> did not lead to a failure. But may be after >> a while it would and be less drastic than a >> reboot or power down. >=20 > More detail: >=20 > So, for rpcbind and nfds at some point a large part of > __je_sz_size2index_tab is being stomped on, as is all of > __je_sz_index2size_tab and more. >=20 > For rpcbind, the following area is zero but in a > live process is not all-zero (I show the partially > non-zero live-process context instead of the all-zero > .core file content): >=20 > 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5034cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cb00 <__je_arenas_lock+64>: 0x00000000 0x5033f070 = 0x00000000 0x00000000 > 0x5034cb10 <__je_arenas_lock+80>: 0x5012bb04 0x00000003 = 0x00000000 0x00000000 > 0x5034cb20 <__je_arenas_lock+96>: 0x5034cb10 0x5034cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5034d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5034cb30 __je_narenas_auto > 0x5034cb38 malloc_conf > 0x5034cb3c __je_ncpus > 0x5034cb40 __je_manual_arena_base > 0x5034cb80 __je_sz_pind2sz_tab > 0x5034ccc0 __je_sz_index2size_tab > 0x5034ce80 __je_sz_size2index_tab >=20 > For nfsd, it is similar (again showing the partially > non-zero live process context instead of the all-zeros > from the .core file): >=20 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 > 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 > 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5030cb30 __je_narenas_auto > 0x5030cb38 malloc_conf > 0x5030cb3c __je_ncpus > 0x5030cb40 __je_manual_arena_base > 0x5030cb80 __je_sz_pind2sz_tab > 0x5030ccc0 __je_sz_index2size_tab > 0x5030ce80 __je_sz_size2index_tab >=20 >=20 > Note: because __je_arenas is normally > mostly zero for these contexts, I can > not tell where the memory trashing > started, only where it replaced non-zero > values with zeros. >=20 I got a mountd assert failure in sz_size2index_lookup while attempting __calloc during makefd_xprt. (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x50301170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50260cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x5025e260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 #5 imalloc_body (sopts=3D0xffffd000, dopts=3D0xffffcfe0, = tsd=3D0x50094018) at jemalloc_jemalloc.c:2066 #6 0x50253874 in imalloc (sopts=3D0xffffd000, dopts=3D0xffffcfe0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 #7 0x50253fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 #8 0x50274690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 #9 0x502725f4 in makefd_xprt (fd=3D10, sendsize=3D9000, recvsize=3D9000) = at /usr/src/lib/libc/rpc/svc_vc.c:250 #10 0x502734b4 in rendezvous_request (xprt=3D0x5007b120, msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 #11 0x50274a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #12 0x502748e0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 #13 0x1001434c in main (argc=3D, argv=3D0xffffde3c) at = /usr/src/usr.sbin/mountd/mountd.c:683 (gdb) up 3 #3 0x5025e260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 159 assert(ret =3D=3D sz_size2index_compute(size)); Again there is that area of memory that has been zeroed, with the same stopping point in __je_sz_size2index_tab: (gdb) print/x __je_narenas_auto $2 =3D 0x0 (gdb) print/x malloc_conf=20 $3 =3D 0x0 (gdb) print/x __je_ncpus $4 =3D 0x0 (gdb) print/x __je_manual_arena_base $5 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab $6 =3D {0x0 } (gdb) print/x __je_sz_size2index_tab $7 =3D {0x0 , 0x1a, 0x1b , 0x1c = } Showing where the zeroing stopped: . . . (gdb) x/156x __je_sz_size2index_tab 0x5035be80 <__je_sz_size2index_tab>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035be90 <__je_sz_size2index_tab+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bea0 <__je_sz_size2index_tab+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035beb0 <__je_sz_size2index_tab+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bec0 <__je_sz_size2index_tab+64>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bed0 <__je_sz_size2index_tab+80>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bee0 <__je_sz_size2index_tab+96>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bef0 <__je_sz_size2index_tab+112>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf00 <__je_sz_size2index_tab+128>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf10 <__je_sz_size2index_tab+144>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf20 <__je_sz_size2index_tab+160>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf30 <__je_sz_size2index_tab+176>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf40 <__je_sz_size2index_tab+192>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf50 <__je_sz_size2index_tab+208>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf60 <__je_sz_size2index_tab+224>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf70 <__je_sz_size2index_tab+240>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf80 <__je_sz_size2index_tab+256>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf90 <__je_sz_size2index_tab+272>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfa0 <__je_sz_size2index_tab+288>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfb0 <__je_sz_size2index_tab+304>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfc0 <__je_sz_size2index_tab+320>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfd0 <__je_sz_size2index_tab+336>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfe0 <__je_sz_size2index_tab+352>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bff0 <__je_sz_size2index_tab+368>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035c000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c010 <__je_sz_size2index_tab+400>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c020 <__je_sz_size2index_tab+416>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c030 <__je_sz_size2index_tab+432>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c040 <__je_sz_size2index_tab+448>: 0x1b1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c050 <__je_sz_size2index_tab+464>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c060 <__je_sz_size2index_tab+480>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c070 <__je_sz_size2index_tab+496>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c080 <__je_sz_size2index_tab+512>: 0x1c000000 = 0x00000000 0x50303474 0x00000000 0x5035c090: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0a0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0b0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0c0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0d0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0e0: 0x00000000 0x00000000 0x00000000 = 0x00000000 Again: a nice page boundary: 0x5035c000 for where the zeros stop. Note that, despite the address ranges shifting around between programs, the same global variables are being stomped on, stopping at the same index into __je_sz_size2index_tab in each of the 3 programs. It always is page aligned there in my context. (The sshd example is different. I've yet to explore it much.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Thu May 7 21:11:12 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 E0BE72E5994; Thu, 7 May 2020 21:11:12 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J5jX5dFjz3GjP; Thu, 7 May 2020 21:11:12 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id B759219EE4; Thu, 7 May 2020 21:11:12 +0000 (UTC) Date: Thu, 7 May 2020 21:11:12 +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-05-03 Message-ID: <20200507211112.GA99308@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 07 May 2020 21:11:12 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-05-03 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-27 to 2020-05-03. During this period, we have: * 2099 builds (93.6% (-0.8) passed, 6.4% (+0.8) 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. * 327 test runs (68.2% (+5.7) passed, 28.1% (-6.7) unstable, 3.7% (+1.0) exception) were executed on amd64, i386, riq scv64 architectures for head, stable/12, stable/11 branches. * 26 doc and www builds (84.6% (+0.4) passed, 15.4% (-0.4) failed) Test case status (on 2020-05-03 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | ---------- | ---------- | ------ | -------- | | head/amd64 | 7778 (+10) | 7685 (+10) | 0 (0) | 93 (0) | | head/i386 | 7776 (+10) | 7676 (+11) | 0 (0) | 100 (-1) | | 12-STABLE/amd64 | 7521 (+3) | 7463 (+1) | 2 (+2) | 56 (0) | | 12-STABLE/i386 | 7519 (+3) | 7453 (+1) | 2 (+2) | 64 (0) | | 11-STABLE/amd64 | 6883 (0) | 6834 (0) | 0 (0) | 49 (0) | | 11-STABLE/i386 | 6881 (0) | 6830 (0) | 0 (0) | 51 (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-20200503 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Fixed tests * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 Fixed in r360567 * sys.netipsec.tunnel.empty.v{4,6} fail after r359374 https://bugs.freebsd.org/245832 Fixed in r360560 ## Failing (and fixed) jobs * https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/ https://ci.freebsd.org/job/FreeBSD-head-powerpcspe-build/ Failing after r360569 and fixed in r360788 * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * (head, stable/12) 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * 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)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## 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 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * 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 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## 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 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/242689 * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * skip sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/244053 * 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.geom.class.multipath.misc.fail_on_error (12-STABLE) https://bugs.freebsd.org/244158 * 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 https://bugs.freebsd.org/244737 * (NEW) sys.netipsec.tunnel.empty.v{4,6} https://bugs.freebsd.org/245832 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Fri May 8 03:11: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 3213E2ED534 for ; Fri, 8 May 2020 03:11:26 +0000 (UTC) (envelope-from roberthuff@rcn.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 49JFj96sZ6z47Vd for ; Fri, 8 May 2020 03:11:25 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: by mailman.nyi.freebsd.org (Postfix) id EB9C12ED533; Fri, 8 May 2020 03:11:25 +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 EB5D32ED532 for ; Fri, 8 May 2020 03:11:25 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 49JFj85wZ8z47Vb for ; Fri, 8 May 2020 03:11:24 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1588907483; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=7lVGsLDmUpTVFJ0Fi/XcvrTBlsc=; b=r5c3wOUzBqEiaj+uqLkoCMFH9a6ccQ4X/t4mCZPje4tbciD16YGiH7J+djS/JnDs QR08GVU1swMCkfrInFF4KPeHlLczBP47DR9EBJJSOBezyyaYKfT1FY8CO1Ix3pSz OldbWi4FojR0/iFP9f41DuO2A0IlOVpYsS+xZokgM0fmEZQQw64Hta9z4/cgSt/V yAlkT2vZo7stPHhvTMHvi2EketQFjBj78fCKwaRFclTT+mfm0qEzcpUWbnM7FNiH 1zLQKJAIMimp6vF22pptiCLiOxjwXN1bJgfkgSuSBBlPk2Fr6lvvxVI2EE3eScf3 pw2EbPHSMpkSk2qnOkymmg==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=Z5uS40ZA c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=sTwFKg_x9MkA:10 a=48faUk6PgeAA:10 a=m2jvxtsRbgmtDF1jtV8A:9 a=Ar-oQTQnc3zy6oMI:21 a=xKl21SY9ah6SOurs:21 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [209.6.230.48] ([209.6.230.48:45651] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id 23/97-10869-BDDC4BE5; Thu, 07 May 2020 23:11:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <24244.52698.726479.288103@jerusalem.litteratus.org> Date: Thu, 7 May 2020 23:11:22 -0400 From: Robert Huff To: current@freebsd.org Subject: "make buildworld" fails for r360785? X-Rspamd-Queue-Id: 49JFj85wZ8z47Vb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (body hash did not verify) header.d=rcn.com header.s=20180516 header.b=r5c3wOUz; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-3.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[78.97.168.69.rep.mailspike.net : 127.0.0.17]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; R_DKIM_REJECT(0.00)[rcn.com:s=20180516]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; IP_SCORE(-1.55)[ip: (-9.06), ipnet: 69.168.97.0/24(0.64), asn: 36271(0.71), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[rcn.com:-]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(0.00)[rcn.com,none]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 08 May 2020 03:11:26 -0000 DQpIZWxsbzoNCglPbiBhIHN5c3RlbSBydW5uaW5nOg0KDQpGcmVlQlNEIDEzLjAtQ1VSUkVOVCAj MCByMzU0MTMxOiBNb24gT2N0IDI4IDE3OjI3OjMzIEVEVCAyMDE5ICBhbWQ2NA0KDQoJVG9kYXkg YXJvdW5kIG5vb24gSSBkb3dubG9hZGVkIGEgZnJlc2ggY29weSBvZiB0aGUgc291cmNlIHRyZWUN Cihmb3IgYmFzZS9oZWFkKSB0byByMzYwNzg1Lg0KCW1ha2UuY29uZjoNCg0KI1dJVEhfREVCVUc9 eWVzDQoNClNFTkRNQUlMX0NGTEFHUz0tSS91c3IvbG9jYWwvaW5jbHVkZS9zYXNsIC1EU0FTTA0K U0VORE1BSUxfTERGTEFHUz0tTC91c3IvbG9jYWwvbGliDQpTRU5ETUFJTF9MREFERD0tbHNhc2wy DQoNCiNERUZBVUxUX1ZFUlNJT05TKz1saW51eD1jNl82NCBzYW1iYT00LjQgcHl0aG9uPTMuNSBw eXRob24zPTMuNQ0KREVGQVVMVF9WRVJTSU9OUys9bGludXg9Yzcgc2FtYmE9NC4xMA0KDQojIFBv c3NpYmxlIHZhbHVlczogMi43LCAzLjQsIDMuNSwgMy42DQpERUZBVUxUX1ZFUlNJT05TKz1weXRo b249My43DQoNCiMgUG9zc2libGUgdmFsdWVzOiAyLjcNCkRFRkFVTFRfVkVSU0lPTlMrPXB5dGhv bjI9Mi43DQoNCiMgUG9zc2libGUgdmFsdWVzOiAzLjQsIDMuNSwgMy42DQpERUZBVUxUX1ZFUlNJ T05TKz1weXRob24zPTMuNw0KDQpERUZBVUxUX1ZFUlNJT05TKz1wZXJsNT01LjMwDQoNCkRFRkFV TFRfVkVSU0lPTlMrPWphdmE9MTINCg0KREVGQVVMVF9WRVJTSU9OUys9c2FtYmE9NC4xMA0KDQoj V0lUSF9DQ0FDSEVfQlVJTEQ9eWVzDQojQ0NBQ0hFX0RJUj0vdmFyL3RtcA0KDQoJc3JjLmNvbmY6 DQoNCldJVEhPVVRfUFJPRklMRT15ZXMNCldJVEhPVVRfVEVTVFM9eWVzDQpXSVRIX0RFQlVHPXll cw0KV0lUSE9VVF9ERUJVR19GSUxFUz15ZXMNCiNXSVRIX0NDQUNIRV9CVUlMRD15ZXMNCiNDQ0FD SEVfRElSPS92YXIvdG1wDQoNCiNQT1JUU19NT0RVTEVTPXN5c3V0aWxzL2xzb2YgZ3JhcGhpY3Mv ZHJtLWxlZ2FjeS1rbW9kIGdyYXBoaWNzL2dwdS1maXJtd2FyZS1rbW9kDQojUE9SVFNfTU9EVUxF UyArPSANClBPUlRTX01PRFVMRVMgKz0gZ3JhcGhpY3MvZHJtLWxlZ2FjeS1rbW9kDQpQT1JUU19N T0RVTEVTICs9IGdyYXBoaWNzL2dwdS1maXJtd2FyZS1rbW9kDQpQT1JUU19NT0RVTEVTICs9IHN5 c3V0aWxzL2xzb2YNCg0KCSJtYWtlIGJ1aWxkb3dybGQiIGZhaWxzIHdpdGg6DQoNCj4gIGMrKyAg LU8yIC1waXBlIC1mbm8tY29tbW9uIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAv b2JqLXRvb2xzL2xpYi9jbGFuZy9saWJjbGFuZyAtSS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1k NjQvdG1wL29iai10b29scy9saWIvY2xhbmcvbGlibGx2bSAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2 bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYyAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0 L2NsYW5nL2xpYi9Ecml2ZXIgLUkvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9p bmNsdWRlIC1JL3Vzci9zcmMvbGliL2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9jb250cmliL2xs dm0tcHJvamVjdC9sbHZtL2luY2x1ZGUgLURfX1NURENfQ09OU1RBTlRfTUFDUk9TIC1EX19TVERD X0ZPUk1BVF9NQUNST1MgLURfX1NURENfTElNSVRfTUFDUk9TIC1ESEFWRV9WQ1NfVkVSU0lPTl9J TkMgLURMTFZNX0RFRkFVTFRfVEFSR0VUX1RSSVBMRT1cIng4Nl82NC11bmtub3duLWZyZWVic2Qx My4wXCIgLURMTFZNX0hPU1RfVFJJUExFPVwieDg2XzY0LXVua25vd24tZnJlZWJzZDEzLjBcIiAt RERFRkFVTFRfU1lTUk9PVD1cIi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wXCIgLURM TFZNX1RBUkdFVF9FTkFCTEVfWDg2IC1ETExWTV9OQVRJVkVfQVNNUEFSU0VSPUxMVk1Jbml0aWFs aXplWDg2QXNtUGFyc2VyIC1ETExWTV9OQVRJVkVfQVNNUFJJTlRFUj1MTFZNSW5pdGlhbGl6ZVg4 NkFzbVByaW50ZXIgLURMTFZNX05BVElWRV9ESVNBU1NFTUJMRVI9TExWTUluaXRpYWxpemVYODZE aXNhc3NlbWJsZXIgLURMTFZNX05BVElWRV9UQVJHRVQ9TExWTUluaXRpYWxpemVYODZUYXJnZXQg LURMTFZNX05BVElWRV9UQVJHRVRJTkZPPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0SW5mbyAtRExM Vk1fTkFUSVZFX1RBUkdFVE1DPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0TUMgLWZmdW5jdGlvbi1z ZWN0aW9ucyAtZmRhdGEtc2VjdGlvbnMgLU1EIC1NRi5kZXBlbmQuQmFzaWNfU2FuaXRpemVyU3Bl Y2lhbENhc2VMaXN0Lm8gLU1UQmFzaWMvU2FuaXRpemVyU3BlY2lhbENhc2VMaXN0Lm8gLVduby1m b3JtYXQtemVyby1sZW5ndGggLVF1bnVzZWQtYXJndW1lbnRzIC1JL3Vzci9vYmovdXNyL3NyYy9h bWQ2NC5hbWQ2NC90bXAvbGVnYWN5L3Vzci9pbmNsdWRlICAtZm5vLWV4Y2VwdGlvbnMgLWZuby1y dHRpIC1zdGQ9YysrMTQgLXN0ZGxpYj1saWJjKysgLVduby1jKysxMS1leHRlbnNpb25zICAgLWMg L3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvY2xhbmcvbGliL0Jhc2ljL1Nhbml0aXplclNw ZWNpYWxDYXNlTGlzdC5jcHAgLW8gQmFzaWMvU2FuaXRpemVyU3BlY2lhbENhc2VMaXN0Lm8NCj4g IGMrKyAgLU8yIC1waXBlIC1mbm8tY29tbW9uIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2 NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9saWJjbGFuZyAtSS91c3Ivb2JqL3Vzci9zcmMvYW1k NjQuYW1kNjQvdG1wL29iai10b29scy9saWIvY2xhbmcvbGlibGx2bSAtSS91c3Ivc3JjL2NvbnRy aWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYyAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1w cm9qZWN0L2NsYW5nL2xpYi9Ecml2ZXIgLUkvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9j bGFuZy9pbmNsdWRlIC1JL3Vzci9zcmMvbGliL2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9jb250 cmliL2xsdm0tcHJvamVjdC9sbHZtL2luY2x1ZGUgLURfX1NURENfQ09OU1RBTlRfTUFDUk9TIC1E X19TVERDX0ZPUk1BVF9NQUNST1MgLURfX1NURENfTElNSVRfTUFDUk9TIC1ESEFWRV9WQ1NfVkVS U0lPTl9JTkMgLURMTFZNX0RFRkFVTFRfVEFSR0VUX1RSSVBMRT1cIng4Nl82NC11bmtub3duLWZy ZWVic2QxMy4wXCIgLURMTFZNX0hPU1RfVFJJUExFPVwieDg2XzY0LXVua25vd24tZnJlZWJzZDEz LjBcIiAtRERFRkFVTFRfU1lTUk9PVD1cIi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1w XCIgLURMTFZNX1RBUkdFVF9FTkFCTEVfWDg2IC1ETExWTV9OQVRJVkVfQVNNUEFSU0VSPUxMVk1J bml0aWFsaXplWDg2QXNtUGFyc2VyIC1ETExWTV9OQVRJVkVfQVNNUFJJTlRFUj1MTFZNSW5pdGlh bGl6ZVg4NkFzbVByaW50ZXIgLURMTFZNX05BVElWRV9ESVNBU1NFTUJMRVI9TExWTUluaXRpYWxp emVYODZEaXNhc3NlbWJsZXIgLURMTFZNX05BVElWRV9UQVJHRVQ9TExWTUluaXRpYWxpemVYODZU YXJnZXQgLURMTFZNX05BVElWRV9UQVJHRVRJTkZPPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0SW5m byAtRExMVk1fTkFUSVZFX1RBUkdFVE1DPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0TUMgLWZmdW5j dGlvbi1zZWN0aW9ucyAtZmRhdGEtc2VjdGlvbnMgLU1EIC1NRi5kZXBlbmQuQmFzaWNfU2FuaXRp emVycy5vIC1NVEJhc2ljL1Nhbml0aXplcnMubyAtV25vLWZvcm1hdC16ZXJvLWxlbmd0aCAtUXVu dXNlZC1hcmd1bWVudHMgLUkvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kv dXNyL2luY2x1ZGUgIC1mbm8tZXhjZXB0aW9ucyAtZm5vLXJ0dGkgLXN0ZD1jKysxNCAtc3RkbGli PWxpYmMrKyAtV25vLWMrKzExLWV4dGVuc2lvbnMgICAtYyAvdXNyL3NyYy9jb250cmliL2xsdm0t cHJvamVjdC9jbGFuZy9saWIvQmFzaWMvU2FuaXRpemVycy5jcHAgLW8gQmFzaWMvU2FuaXRpemVy cy5vDQo+ICBjKysgIC1PMiAtcGlwZSAtZm5vLWNvbW1vbiAtSS91c3Ivb2JqL3Vzci9zcmMvYW1k NjQuYW1kNjQvdG1wL29iai10b29scy9saWIvY2xhbmcvbGliY2xhbmcgLUkvdXNyL29iai91c3Iv c3JjL2FtZDY0LmFtZDY0L3RtcC9vYmotdG9vbHMvbGliL2NsYW5nL2xpYmxsdm0gLUkvdXNyL3Ny Yy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFzaWMgLUkvdXNyL3NyYy9jb250cmli L2xsdm0tcHJvamVjdC9jbGFuZy9saWIvRHJpdmVyIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXBy b2plY3QvY2xhbmcvaW5jbHVkZSAtSS91c3Ivc3JjL2xpYi9jbGFuZy9pbmNsdWRlIC1JL3Vzci9z cmMvY29udHJpYi9sbHZtLXByb2plY3QvbGx2bS9pbmNsdWRlIC1EX19TVERDX0NPTlNUQU5UX01B Q1JPUyAtRF9fU1REQ19GT1JNQVRfTUFDUk9TIC1EX19TVERDX0xJTUlUX01BQ1JPUyAtREhBVkVf VkNTX1ZFUlNJT05fSU5DIC1ETExWTV9ERUZBVUxUX1RBUkdFVF9UUklQTEU9XCJ4ODZfNjQtdW5r bm93bi1mcmVlYnNkMTMuMFwiIC1ETExWTV9IT1NUX1RSSVBMRT1cIng4Nl82NC11bmtub3duLWZy ZWVic2QxMy4wXCIgLURERUZBVUxUX1NZU1JPT1Q9XCIvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFt ZDY0L3RtcFwiIC1ETExWTV9UQVJHRVRfRU5BQkxFX1g4NiAtRExMVk1fTkFUSVZFX0FTTVBBUlNF Uj1MTFZNSW5pdGlhbGl6ZVg4NkFzbVBhcnNlciAtRExMVk1fTkFUSVZFX0FTTVBSSU5URVI9TExW TUluaXRpYWxpemVYODZBc21QcmludGVyIC1ETExWTV9OQVRJVkVfRElTQVNTRU1CTEVSPUxMVk1J bml0aWFsaXplWDg2RGlzYXNzZW1ibGVyIC1ETExWTV9OQVRJVkVfVEFSR0VUPUxMVk1Jbml0aWFs aXplWDg2VGFyZ2V0IC1ETExWTV9OQVRJVkVfVEFSR0VUSU5GTz1MTFZNSW5pdGlhbGl6ZVg4NlRh cmdldEluZm8gLURMTFZNX05BVElWRV9UQVJHRVRNQz1MTFZNSW5pdGlhbGl6ZVg4NlRhcmdldE1D IC1mZnVuY3Rpb24tc2VjdGlvbnMgLWZkYXRhLXNlY3Rpb25zIC1NRCAtTUYuZGVwZW5kLkJhc2lj X1NvdXJjZUxvY2F0aW9uLm8gLU1UQmFzaWMvU291cmNlTG9jYXRpb24ubyAtV25vLWZvcm1hdC16 ZXJvLWxlbmd0aCAtUXVudXNlZC1hcmd1bWVudHMgLUkvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFt ZDY0L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgIC1mbm8tZXhjZXB0aW9ucyAtZm5vLXJ0dGkgLXN0 ZD1jKysxNCAtc3RkbGliPWxpYmMrKyAtV25vLWMrKzExLWV4dGVuc2lvbnMgICAtYyAvdXNyL3Ny Yy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFzaWMvU291cmNlTG9jYXRpb24uY3Bw IC1vIEJhc2ljL1NvdXJjZUxvY2F0aW9uLm8NCj4gIGMrKyAgLU8yIC1waXBlIC1mbm8tY29tbW9u IC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9s aWJjbGFuZyAtSS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL29iai10b29scy9saWIv Y2xhbmcvbGlibGx2bSAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9C YXNpYyAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9Ecml2ZXIgLUkv dXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9pbmNsdWRlIC1JL3Vzci9zcmMvbGli L2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9sbHZtL2luY2x1 ZGUgLURfX1NURENfQ09OU1RBTlRfTUFDUk9TIC1EX19TVERDX0ZPUk1BVF9NQUNST1MgLURfX1NU RENfTElNSVRfTUFDUk9TIC1ESEFWRV9WQ1NfVkVSU0lPTl9JTkMgLURMTFZNX0RFRkFVTFRfVEFS R0VUX1RSSVBMRT1cIng4Nl82NC11bmtub3duLWZyZWVic2QxMy4wXCIgLURMTFZNX0hPU1RfVFJJ UExFPVwieDg2XzY0LXVua25vd24tZnJlZWJzZDEzLjBcIiAtRERFRkFVTFRfU1lTUk9PVD1cIi91 c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wXCIgLURMTFZNX1RBUkdFVF9FTkFCTEVfWDg2 IC1ETExWTV9OQVRJVkVfQVNNUEFSU0VSPUxMVk1Jbml0aWFsaXplWDg2QXNtUGFyc2VyIC1ETExW TV9OQVRJVkVfQVNNUFJJTlRFUj1MTFZNSW5pdGlhbGl6ZVg4NkFzbVByaW50ZXIgLURMTFZNX05B VElWRV9ESVNBU1NFTUJMRVI9TExWTUluaXRpYWxpemVYODZEaXNhc3NlbWJsZXIgLURMTFZNX05B VElWRV9UQVJHRVQ9TExWTUluaXRpYWxpemVYODZUYXJnZXQgLURMTFZNX05BVElWRV9UQVJHRVRJ TkZPPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0SW5mbyAtRExMVk1fTkFUSVZFX1RBUkdFVE1DPUxM Vk1Jbml0aWFsaXplWDg2VGFyZ2V0TUMgLWZmdW5jdGlvbi1zZWN0aW9ucyAtZmRhdGEtc2VjdGlv bnMgLU1EIC1NRi5kZXBlbmQuQmFzaWNfU291cmNlTWFuYWdlci5vIC1NVEJhc2ljL1NvdXJjZU1h bmFnZXIubyAtV25vLWZvcm1hdC16ZXJvLWxlbmd0aCAtUXVudXNlZC1hcmd1bWVudHMgLUkvdXNy L29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgIC1mbm8tZXhj ZXB0aW9ucyAtZm5vLXJ0dGkgLXN0ZD1jKysxNCAtc3RkbGliPWxpYmMrKyAtV25vLWMrKzExLWV4 dGVuc2lvbnMgICAtYyAvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFz aWMvU291cmNlTWFuYWdlci5jcHAgLW8gQmFzaWMvU291cmNlTWFuYWdlci5vDQo+ICAvdXNyL3Ny Yy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFzaWMvU291cmNlTWFuYWdlci5jcHA6 MTIyODoxMDogZmF0YWwgZXJyb3I6ICdlbW1pbnRyaW4uaCcgZmlsZSBub3QgZm91bmQNCj4gICNp bmNsdWRlIDxlbW1pbnRyaW4uaD4NCj4gICAgICAgICAgIF5+fn5+fn5+fn5+fn4NCj4gIDEgZXJy b3IgZ2VuZXJhdGVkLg0KPiAgKioqIEVycm9yIGNvZGUgMQ0KDQoJSGF2ZSBJIHNjcmV3ZWQgc29t ZXRoaW5nIHVwPyAgTm90aGluZyBpbiBVUERBVElORyBzZWVtcw0KYXBwcm9wcmlhdGUuDQoJSGVs cCwgcGxlYXNlPw0KDQoNCgkJCVJlc3BlY3RmdWxseSwNCg0KDQoJCQkJUm9iZXJ0IEh1ZmY= From owner-freebsd-current@freebsd.org Fri May 8 03:35:40 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 BE1052EE292 for ; Fri, 8 May 2020 03:35:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.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 49JGF81yX6z48r3 for ; Fri, 8 May 2020 03:35:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: by mailman.nyi.freebsd.org (Postfix) id 433CD2EE291; Fri, 8 May 2020 03:35:40 +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 42F942EE290 for ; Fri, 8 May 2020 03:35:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JGF75468z48r2 for ; Fri, 8 May 2020 03:35:39 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 0483ZZ3m042227 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 May 2020 20:35:42 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: <24244.52698.726479.288103@jerusalem.litteratus.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Robert Huff Subject: Re: "make buildworld" fails for r360785? Date: Thu, 07 May 2020 20:35:42 -0700 Message-Id: <849835c13cac7bb6ce9f6e13eaa3b589@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49JGF75468z48r2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.89 / 15.00]; NEURAL_HAM_MEDIUM(-0.92)[-0.920,0]; NEURAL_HAM_LONG(-0.97)[-0.969,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.30 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, 08 May 2020 03:35:40 -0000 On Thu, 7 May 2020 23:11:22 -0400 Robert Huff roberthuff@rcn=2Ecom said > Hello: > =09On a system running: >=20 > FreeBSD 13=2E0-CURRENT #0 r354131: Mon Oct 28 17:27:33 EDT 2019 amd64 >=20 > =09Today around noon I downloaded a fresh copy of the source tree > (for base/head) to r360785=2E > =09make=2Econf: >=20 > #WITH_DEBUG=3Dyes >=20 > SENDMAIL_CFLAGS=3D-I/usr/local/include/sasl -DSASL > SENDMAIL_LDFLAGS=3D-L/usr/local/lib > SENDMAIL_LDADD=3D-lsasl2 >=20 > #DEFAULT_VERSIONS+=3Dlinux=3Dc6_64 samba=3D4=2E4 python=3D3=2E5 python3=3D3=2E5 > DEFAULT_VERSIONS+=3Dlinux=3Dc7 samba=3D4=2E10 >=20 > # Possible values: 2=2E7, 3=2E4, 3=2E5, 3=2E6 > DEFAULT_VERSIONS+=3Dpython=3D3=2E7 >=20 > # Possible values: 2=2E7 > DEFAULT_VERSIONS+=3Dpython2=3D2=2E7 >=20 > # Possible values: 3=2E4, 3=2E5, 3=2E6 > DEFAULT_VERSIONS+=3Dpython3=3D3=2E7 >=20 > DEFAULT_VERSIONS+=3Dperl5=3D5=2E30 >=20 > DEFAULT_VERSIONS+=3Djava=3D12 >=20 > DEFAULT_VERSIONS+=3Dsamba=3D4=2E10 >=20 > #WITH_CCACHE_BUILD=3Dyes > #CCACHE_DIR=3D/var/tmp >=20 > =09src=2Econf: >=20 > WITHOUT_PROFILE=3Dyes > WITHOUT_TESTS=3Dyes > WITH_DEBUG=3Dyes > WITHOUT_DEBUG_FILES=3Dyes > #WITH_CCACHE_BUILD=3Dyes > #CCACHE_DIR=3D/var/tmp >=20 > #PORTS_MODULES=3Dsysutils/lsof graphics/drm-legacy-kmod > graphics/gpu-firmware-kmod > #PORTS_MODULES +=3D=20 > PORTS_MODULES +=3D graphics/drm-legacy-kmod > PORTS_MODULES +=3D graphics/gpu-firmware-kmod > PORTS_MODULES +=3D sysutils/lsof >=20 > =09"make buildowrld" fails with: >=20 > > c++ -O2 -pipe -fno-common > > -I/usr/obj/usr/src/amd64=2Eamd64/tmp/obj-tools/lib/clang/libclang > > -I/usr/obj/usr/src/amd64=2Eamd64/tmp/obj-tools/lib/clang/libllvm > > -I/usr/src/contrib/llvm-project/clang/lib/Basic > > -I/usr/src/contrib/llvm-project/clang/lib/Driver > > -I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/inc= lude =2E=2E=2E > > -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeX86TargetMC -ffunction-sections > > -fdata-sectio > ns -MD -MF=2Edepend=2EBasic_SourceManager=2Eo -MTBasic/SourceManager=2Eo > -Wno-format-zero-length -Qunused-arguments > -I/usr/obj/usr/src/amd64=2Eamd64/tmp/legacy/usr/include -fno-exceptions > -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ -Wno-c++11-extensions -c > /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager=2Ecpp -o > Basic/SourceManager=2Eo > > /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager=2Ecpp:1228:1= 0: > > fatal error: 'emmintrin=2Eh' file not found > > #include > > ^~~~~~~~~~~~~ > > 1 error generated=2E > > *** Error code 1 I ran ionto this awhile back, and I think the way I was able to solve it wi= th a make kernel-toolchain and then building world && kernel Best wishes=2E --Chris >=20 > =09Have I screwed something up? Nothing in UPDATING seems > appropriate=2E > =09Help, please? >=20 >=20 > =09=09=09Respectfully, >=20 >=20 > =09=09=09=09Robert Huff > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Fri May 8 15:53: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 C46022DA9A5 for ; Fri, 8 May 2020 15:53:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JZcS693Pz3y64; Fri, 8 May 2020 15:53:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f51.google.com with SMTP id t11so1802412lfe.4; Fri, 08 May 2020 08:53:28 -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:cc:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=CpipfMD3GxqU+1Gt7/w+gK0hPGH/wnt7sSP9zNfwGw4=; b=PECaARzTIr3uTDlnTwVqeD7vGbAz51XLeyO+3Sy3k4g9dMos4atmYRqpncrIzbvG7O ocCydbtFfDwk54WMlaOe0woYoorUtoKQB4bBl7HN4O5d2g4JpnO33rKFHH0w09ncXQfB EH/j8j1a7iVF7hcaBQZ1vq3MVOPYEEaRjLSedt7enE2lLNToGjtg1Xc/bkfqi6NSZvEN s0nnui8+H0iYhY/3Ml6Vmzy1yyjoBi1ggjbUOZB52vCt596N24NZc3moxxSqgb5SDNH8 mm+tUGkfHXaJMKBUM1Od13JnkOyYGelEyFbtyXbiRK/qqLdyo26XonHtOH1vNTJibc5h 7eCQ== X-Gm-Message-State: AOAM530wnh4laUnpljrm+gjBJhsBTaRKiUgvrofV/bFggNvKqnS1V67W b3la0Rw1+en3BaVOqDzFzAk+lAP5tVM= X-Google-Smtp-Source: ABdhPJz8JWTO9qE0E/abis4KSc9moWCU2JLgiPgI8TNLmISLRVmloE7jWjwbHsC1lS/5io+mzZ7QsQ== X-Received: by 2002:a19:5053:: with SMTP id z19mr2418307lfj.177.1588953206402; Fri, 08 May 2020 08:53:26 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id j29sm1708916lfp.90.2020.05.08.08.53.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 08:53:25 -0700 (PDT) To: FreeBSD Current Cc: Konstantin Belousov From: Andriy Gapon Subject: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> Date: Fri, 8 May 2020 18:53:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49JZcS693Pz3y64 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979,0]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[FreeBSD.org]; IP_SCORE(-0.27)[ip: (-0.46), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[51.167.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[51.167.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 15:53:30 -0000 I have a reproducible panic with a custom kernel without option NUMA while using amdgpu driver from linuxkpi-based drm: panic: address 41ec00000 beyond the last segment I did some quick debugging and the panic happens when Xorg server tries to access a frame buffer (or something like that). There is a page fault that gets satisfied by ttm with a fictitious page. The stack trace is: #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, m=, prot=, flags=, psind=) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 #13 0xffffffff80b288be in vm_fault_populate (fs=) at /usr/devel/git/motil/sys/vm/vm_fault.c:519 #14 vm_fault_allocate (fs=) at /usr/devel/git/motil/sys/vm/vm_fault.c:1032 #15 vm_fault (map=, vaddr=, fault_type=, fault_flags=, m_hold=) at /usr/devel/git/motil/sys/vm/vm_fault.c:1342 #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, vaddr=, fault_type=, fault_flags=0, signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at /usr/devel/git/motil/sys/vm/vm_fault.c:589 #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, usermode=, signo=, ucode=0xffffffff80853250 ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 The line number in pmap_enter() is incorrect, I guess because of optimizations. The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> PHYS_TO_PV_LIST_LOCK -> pa_index(). The panic in correct in that the page is fictitious and its physical address is beyond the end of real physical memory. It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one is not. -- Andriy Gapon From owner-freebsd-current@freebsd.org Fri May 8 16:14: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 645F52DB641 for ; Fri, 8 May 2020 16:14:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 49Jb4m2d5Hz40mT for ; Fri, 8 May 2020 16:14:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: TVENuvoVM1n_zA_0fs6Z719DKccdLvBZKI4IF2arNLX_N4maUdk63_v7VCedtYw kKmDxIpX7OF5E6wicfhOXIHMkD7lDSBRJFGS_kqn447wUaref25ZfPYh4YEESAzPpA2rIsETZB3z FYvkZLf5Po8MZyT3KX6Cain4buVLJUUhDIkLbXksSeWUo51VxQJMV3C6fCuJu6nWndqmA4Qh1mTt XMLaHVA8E9GNT_PfDLNvZKcnGbANy5qhCfkmZ4LOEF_GyAwAuZ1aHHwY4GOgyyoND1NHNxa04rat NulF6Fool9duKR9UmGva60q4Gl0HmRxyNNKQN253LMyOVhNlZ0B1iRkkEqig4JqhdM_aHxu0iktm AnoAodoa.Ws3BKJogkqMMnXCv91vkDRVyuxh7FDK3uf1SqN_2x9C_UpWLfrkwAET.ydd4aJEVT0N Jbz1FrB9uo8yq5KeD_uNskh1N2rHXtc30BDQOzrqsRDKcyZvcK3XcLvW6NMtMlM0UF5gHMNAA5uH 23SQcUX_sHjsarQTcf8.orhY4Xane0WX0kMO_QrZTnT00PQrlrGn0.GdH6_o8zwEAG.xcsFSLgTT _.yybkiZ.p3hwwxvTQEJWfzdQQDpj0FQcRE9gtcU8ONPqCXCZM14u73ArBF1F7dFJ8lEEru25dR5 0vErXFnRDQs.kxzebK4TWqJe24GHRSXhvLpALkZgqUp.BNqakGjSg97Y3OvQPdmLQAoPG_1S.Cje Hk9FfmYnXohSWqwBtfBgRzhd13NCi_uztl8yy2zdHs9e19MEuf8AvhwIX2AgBgSnRgde45zygkYH y.gPaQ8GewxsVdScud1nCUICCM1ACyu1IxRqZvu3QDrsoqhx5C3mTnYcvxZbAoC5QEoJ.1i3aIWy 4ooOqAK0xXFAp1VVpr3zp99dzwDc0PdtY3l6ar7sMa_uBpDCLaBry2ZCzQQmErOYj5_jeg0HH_sK 5mVHAUngzgcF_GJv29m7NC3viQH16l.e0mLx70pJv4goQuGhC_JoT9re8DZq3o9sbJIYTiTve8G9 xAqAgkZJUXQoPqkQD9bcr3cgUNMH3XCF55R0wJoH7TFpx5vYUZ3Qu4.DatFyku_ISXHer15cnlXN ThYqGhAVjHZ_cPf1N7EjWDuJxl6vtPrxbLgNPYG5eVrBVb0Y8meyYv9e9nPlCEYkPWDdGcVd8gvB Z77cDzOsF3Q8d0OJsBRBPyLjgMydpRbaffFyT0fAD22FU8rjdidlFmPmf9orIe6fRLZK4RKZh.gr rMRj5aMwaDpfT4G4KLlY9X.vCUNZ4eZasZkWtUnhoaq0ReXMJXFtCiWwEr3q_b9coYIqliudGjWR 7aUsa6GVnP53AU6aTKEurLaKhBF8tyndHLlpg8KVBobgq3YhFzOOsLv.rikJwACuuuc0eZlQh5rN TrcgPmggrtVjMJg_b2OXVrlBnJDEfhbGt0Tm_3IEz6t3qTdCQCG7XB7_ObBwezDw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 May 2020 16:14:30 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f4875cfc9e4acaebf3d65b4cfeaaba16; Fri, 08 May 2020 16:14:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Fri, 8 May 2020 09:14:24 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <624CE71B-2C50-4E77-85A2-42D9FA140AD0@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Jb4m2d5Hz40mT X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.40 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.926,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.970,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.91), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 16:14:34 -0000 [More details for a sshd failure. The other examples are omitted. The sshd failure also shows a all-zeros-up-to-a-page-boundary issue, just for a different address range.] On 2020-May-7, at 12:06, Mark Millard wrote: >=20 > [mountd failure example: also at sz_size2index_lookup assert > for the same zero'd memory problem.] >=20 >> On 2020-May-7, at 00:46, Mark Millard wrote: >>=20 >> [__je_sz_size2index_tab seems messed up in 2 of the >> asserting contexts: first 384 are zero in both. More >> before that is also messed up (all zero). I show the >> details later below.] >>=20 >> On 2020-May-6, at 16:57, Mark Millard wrote: >>=20 >>> [This explores process crashes that happen during system >>> shutdown, in a context not having MALLOC_PRODUCTION=3D . >>> So assert failures are reported as the stopping points.] >>>=20 >>> It looks like shutdown -p now, shutdown -r now, and the >>> like can lead some processes to assert during their exit >>> attempt, including a sshd failure (that I've not seen >>> before), rpcbind, and nfsd. I show information about the >>> observed asserts for those below. >>>=20 >>>=20 >>> sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >>>=20 >>> (gdb) bt=20 >>> #0 thr_kill () at thr_kill.S:4 >>> #1 0x50927170 in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >>> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >>> #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, alloc_ctx=3D, is_internal=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 >>> #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 >>> #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 >>> #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 >>> #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 >>> #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >>>=20 >>> . . . >>> (gdb) up >>> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >>> 67 (void)raise(SIGABRT); >>> (gdb) up >>> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>>=20 >>> (gdb) list >>> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >>> 312 rtree_ctx, (uintptr_t)ptr, true); >>> 313 assert(szind =3D=3D extent_szind_get(extent)); >>> 314 assert(szind < SC_NSIZES); >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>> 316 } >>> 317=09 >>> 318 if (likely(slab)) { >>> 319 /* Small allocation. */ >>>=20 >>> More fully: >>>=20 >>> 285 JEMALLOC_ALWAYS_INLINE void >>> 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, >>> 287 alloc_ctx_t *alloc_ctx, bool slow_path) { >>> 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); >>> 289 assert(ptr !=3D NULL); >>> 290=09 >>> 291 if (unlikely(tcache =3D=3D NULL)) { >>> 292 arena_dalloc_no_tcache(tsdn, ptr); >>> 293 return; >>> 294 } >>> 295=09 >>> 296 szind_t szind; >>> 297 bool slab; >>> 298 rtree_ctx_t *rtree_ctx; >>> 299 if (alloc_ctx !=3D NULL) { >>> 300 szind =3D alloc_ctx->szind; >>> 301 slab =3D alloc_ctx->slab; >>> 302 assert(szind !=3D SC_NSIZES); >>> 303 } else { >>> 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, >>> 306 (uintptr_t)ptr, true, &szind, &slab); >>> 307 } >>> 308=09 >>> 309 if (config_debug) { >>> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >>> 312 rtree_ctx, (uintptr_t)ptr, true); >>> 313 assert(szind =3D=3D extent_szind_get(extent)); >>> 314 assert(szind < SC_NSIZES); >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>> 316 } >>> 317=09 >>> 318 if (likely(slab)) { >>> 319 /* Small allocation. */ >>> 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, >>> 321 slow_path); >>> 322 } else { >>> 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); >>> 324 } >>> 325 } >>=20 >> . . . The machine code for: 309 if (config_debug) { 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } was dropping the address in "extent" the next instruction after finding it: replacing with with a field's value. So by the time the status of the assert could be known, examining extent was a difficulty. So I touched the source code to force the address to be kept and to give a place to breakpoint on failure before calling another routine: # svnlite diff = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h Index: = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h =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 --- = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h = (revision 360322) +++ = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h = (working copy) @@ -308,11 +308,11 @@ =20 if (config_debug) { rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); - extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, + extent_t * volatile extent =3D rtree_extent_read(tsdn, = &extents_rtree, rtree_ctx, (uintptr_t)ptr, true); assert(szind =3D=3D extent_szind_get(extent)); assert(szind < SC_NSIZES); - assert(slab =3D=3D extent_slab_get(extent)); + assert((slab =3D=3D extent_slab_get(extent)) ?true = :extent=3D=3DNULL); } =20 if (likely(slab)) { The ":extent=3D=3DNULL" should be guaranteed to produce :false as a = result but with more code involved to get there. It gave me a place to = breakpoint on failure. (gdb) bt -full #0 0x50883258 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 extent =3D 0x51007fc0 slab =3D szind =3D rtree_ctx =3D 0x500dd06c extent =3D #1 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160, = alloc_ctx=3D, is_internal=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 No locals. #2 0x5087b0e4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 alloc_ctx =3D {szind =3D 0, slab =3D true} rtree_ctx =3D usize =3D #3 0x5087acec in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 tcache =3D 0x500dd160 tsd =3D #4 0x5087b2d4 in __free (ptr=3D0x5008a180) at jemalloc_jemalloc.c:2852 log_var =3D log_var =3D #5 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 from =3D {ss_len =3D 16 '\020', ss_family =3D 2 '\002', = __ss_pad1 =3D "\317\200\300\250\001\031", __ss_align =3D 0,=20 __ss_pad2 =3D "\000\000\000\000\000\000\000\002Am", '\000' = , "\065\341I\000\000\000\000^\264\234\331", '\000' = , = "^\262\027\034-a\241H\000\000\000\000\000\000\000\000^\264\235Y,\024\247\0= 30\000\000\000\000\000\000\000\000V\312\331f6-N\370\000\000\000\000\000\00= 0\000\000\000\000\002\000\000\000\000\000\000\000\000\b"} rnd =3D '\000' startup_p =3D {6, 7} startups =3D 1 i =3D maxfd =3D 6 fdset =3D fromlen =3D ret =3D j =3D pid =3D laddr =3D raddr =3D #6 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 config_s =3D {8, 9} on =3D 1 ssh =3D 0x0 logfile =3D newsock =3D -1 sock_out =3D -1 sock_in =3D -1 connection_info =3D i =3D opt =3D line =3D r =3D key =3D pubkey =3D keytype =3D fp =3D j =3D new_umask =3D already_daemon =3D remote_port =3D remote_ip =3D rdomain =3D --Type for more, q to quit, c to continue without paging-- laddr =3D authctxt =3D obytes =3D ibytes =3D (gdb) list 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t * volatile extent =3D = rtree_extent_read(tsdn, &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert((slab =3D=3D extent_slab_get(extent)) = ?true :extent=3D=3DNULL); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ (gdb) print/x extent $6 =3D 0x51007fc0 (gdb) print/x *extent $2 =3D {e_bits =3D 0x0, e_addr =3D 0x0, {e_size_esn =3D 0x0, e_bsize =3D = 0x0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= { bitmap =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff, 0xffffffff, = 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, = 0xffffffff, 0xffffffff, 0xfff8}}, {e_alloc_time =3D { ns =3D 0x0}, e_prof_tctx =3D {repr =3D 0x0}}}} It looks like the prefix of the above has been stomped on to be zeros. Checking addresses as well: (gdb) x/64x extent 0x51007fc0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007fd0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007fe0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007ff0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008000: 0xffffffff 0xffffffff 0xffffffff = 0xffffffff 0x51008010: 0xffffffff 0xffffffff 0xffffffff = 0xffffffff 0x51008020: 0xffffffff 0xffffffff 0x0000fff8 = 0x00000000 0x51008030: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008040: 0x00000800 0x0014f000 0x5008b000 = 0x00005000 0x51008050: 0x51008040 0x51008040 0x00000000 = 0x00000000 0x51008060: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008070: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008080: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008090: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x510080a0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x510080b0: 0x00000000 0x00000000 0x00000000 = 0x00000000 Note that the non-zero values start at: 0x51008000, again a page boundary, like the other examples in prior notes for other cases. This appears to be another example of memory having been stomped on/replaced that likely previously had the intended values. The first prior non-zero values are at: 0x51005a30: 0x00000000 0x51008740 0x0000000f = 0x01000000 0x51005a40: 0x51008740 0x0000000f 0x01000000 = 0x51008740 0x51005a50: 0x0000000f 0x01000000 0x51008740 = 0x0000000f 0x51005a60: 0x01000000 0x51008740 0x0000000f = 0x01000000 0x51005a70: 0x51008740 0x0000000f 0x01000000 = 0x51008740 0x51005a80: 0x0000000f 0x01000000 0x51008940 = 0x00000014 0x51005a90: 0x01000000 0x510089c0 0x00000014 = 0x01000000 0x51005aa0: 0x51008a40 0x00000018 0x01000000 = 0x51008ac0 0x51005ab0: 0x00000018 0x01000000 0x51008b40 = 0x00000018 0x51005ac0: 0x01000000 0x51008bc0 0x00000018 = 0x01000000 0x51005ad0: 0x51008c40 0x00000018 0x01000000 = 0x51008cc0 0x51005ae0: 0x00000001 0x01000000 0x00000000 = 0x00000000 So the pages for address ranges 0x51006yyy and 0x51007yyy seem to be all-zero, along with the tail of the page for the range 0x51005yyy. #2 (ifree) in the backtrace shows the alloc_ctx content: alloc_ctx =3D {szind =3D 0, slab =3D true} So slab=3D=3Dtrue but the bit in extent->e_bits=3D=3Dfalse, leading to the failed assert. Before going to sleep for the night, I could ssh into the old PowerMac without this detection. After getting up, trying the same got the failure detection. I did not have the machine doing anything else special between. The other examples in the other programs are similar: just waiting long enough with normal background processing going on eventually leads to the context for the next explicit use (or exit) to detect the problem. I'm still no where near identifying when the stomped-on memory range is trashed with zeros in code terms in any example program. But sshd, dhclient, rpcbind, nfsd, and sendmail all seem to have some common subject area(s) involved in their implementation. So I suspect something common across those is essentially involved. For reference: In #0: (gdb) print/x rtree_ctx $5 =3D 0x500dd06c (gdb) print/x *rtree_ctx $4 =3D {cache =3D {{leafkey =3D 0x50000000, leaf =3D 0x51004fc0}, = {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = {leafkey =3D 0x50c00000, leaf =3D 0x51008dc0}, {leafkey =3D 0x1,=20 leaf =3D 0x0} }, l2_cache =3D {{leafkey =3D 0x1, = leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D= 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = { leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = {leafkey =3D 0x1, leaf =3D 0x0}}} =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Fri May 8 16:15: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 2BCA42DB7D7 for ; Fri, 8 May 2020 16:15:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jb5S6WN2z4126; Fri, 8 May 2020 16:15:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 048GF1jD069320 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 May 2020 19:15:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 048GF1jD069320 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 048GF1TY069319; Fri, 8 May 2020 19:15:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 May 2020 19:15:00 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Message-ID: <20200508161500.GC44519@kib.kiev.ua> References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,PLING_QUERY 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: 49Jb5S6WN2z4126 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 16:15:09 -0000 On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: > > I have a reproducible panic with a custom kernel without option NUMA while using > amdgpu driver from linuxkpi-based drm: > > panic: address 41ec00000 beyond the last segment > > I did some quick debugging and the panic happens when Xorg server tries to > access a frame buffer (or something like that). There is a page fault that gets > satisfied by ttm with a fictitious page. > > The stack trace is: > #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, > m=, prot=, flags=, psind= out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 > #13 0xffffffff80b288be in vm_fault_populate (fs=) at > /usr/devel/git/motil/sys/vm/vm_fault.c:519 > #14 vm_fault_allocate (fs=) at > /usr/devel/git/motil/sys/vm/vm_fault.c:1032 > #15 vm_fault (map=, vaddr=, fault_type= out>, fault_flags=, m_hold=) at > /usr/devel/git/motil/sys/vm/vm_fault.c:1342 > #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, > vaddr=, fault_type=, fault_flags=0, > signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at > /usr/devel/git/motil/sys/vm/vm_fault.c:589 > #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, > usermode=, signo=, ucode=0xffffffff80853250 > ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 > #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at > /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 > > > The line number in pmap_enter() is incorrect, I guess because of optimizations. > The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> > PHYS_TO_PV_LIST_LOCK -> pa_index(). > > The panic in correct in that the page is fictitious and its physical address is > beyond the end of real physical memory. > It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one > is not. I think you can remove this assert. pa_index() is always taken by % NVP_LIST_LOCKS, because fictitious mappings are not promoted. Try that and commit if it works for you. From owner-freebsd-current@freebsd.org Fri May 8 18:22: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 5A73A2DEA45 for ; Fri, 8 May 2020 18:22:53 +0000 (UTC) (envelope-from jhb@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) server-signature RSA-PSS (4096 bits) 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 49Jdws1pphz49TT; Fri, 8 May 2020 18:22:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-164.local (unknown [IPv6:2601:648:8203:2990:2188:73e5:7ca9:66ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id D0714105B1; Fri, 8 May 2020 18:22:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: ${COMPILER_VERSION} < 40300 To: Warner Losh , Eric van Gyzen Cc: freebsd-current References: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Fri, 8 May 2020 11:22:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 18:22:53 -0000 On 5/7/20 10:17 AM, Warner Losh wrote: > On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen wrote: > >> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, >> which ones should I keep? I would probably confine it to head, so I >> could prune quite a few. >> > > Anything in the bootstrap path should remain, especially in the install > portion of the bootstrap path since we don't require new compilers for > that. I doubt there's more than one or two of these and there may be zero. > The rest can go away. > > We should also look at taking out the fmake workarounds in the tree too. > Most of these are in src/Makefile and src/Makefile.inc. I think Eric though was asking about and the like. Right now we still have conditional support for some really old compilers that are likely to never be used with FreeBSD 13 (ancient Intel icc, gcc 2.95, etc.). Like, do we keep support for pre-ANSI C to delete 'const' etc. via macros? Admittedly there isn't a tremendous amount of cruft in cdefs.h. What would seem more invasive would be to do things like require C99 and use 'restrict' directly instead of __restrict, but the first step towards any of that is probably to remove some of the cruft from cdefs.h and possibly some other places. (BTW, it would be good to know if it's at all useful to keep any of the icc bits around.) -- John Baldwin From owner-freebsd-current@freebsd.org Fri May 8 18:34: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 C88752DEE1C for ; Fri, 8 May 2020 18:34:06 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jf9p0CpLz4BLP; Fri, 8 May 2020 18:34:05 +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 5BB9756468; Fri, 8 May 2020 13:33:59 -0500 (CDT) Subject: Re: ${COMPILER_VERSION} < 40300 To: John Baldwin , Warner Losh Cc: freebsd-current References: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> From: Eric van Gyzen Message-ID: Date: Fri, 8 May 2020 13:33:53 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.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: 49Jf9p0CpLz4BLP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-2.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.967,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[vangyzen.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; SUBJ_ALL_CAPS(2.03)[27]; IP_SCORE(-2.96)[ip: (-7.14), ipnet: 2607:fc50:1000::/36(-3.81), asn: 36236(-3.80), country: US(-0.05)]; 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]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 18:34:06 -0000 On 5/8/20 1:22 PM, John Baldwin wrote: > I think Eric though was asking about and the like. Actually, I was asking about makefile conditions, but this is still a good discussion to have. I'm in a cleanup mood. > (BTW, it would be good to know if it's at all useful to keep any of the > icc bits around.) Intel made a FreeBSD version of their 2016 compiler. https://software.intel.com/content/www/us/en/develop/articles/intel-system-studio-2016-for-freebsd.html That uses Clang as a front-end, so maybe some of the old icc bits can still go away. I still have a copy of that compiler, so I can test things as needed. Eric From owner-freebsd-current@freebsd.org Fri May 8 19:18: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 A41092DFAFF for ; Fri, 8 May 2020 19:18:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jg8x1fWkz4DJt; Fri, 8 May 2020 19:18:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 048JIFNY012454 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 May 2020 22:18:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 048JIFNY012454 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 048JIF6h012453; Fri, 8 May 2020 22:18:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 May 2020 22:18:15 +0300 From: Konstantin Belousov To: John Baldwin Cc: Warner Losh , Eric van Gyzen , freebsd-current Subject: Re: ${COMPILER_VERSION} < 40300 Message-ID: <20200508191815.GD44519@kib.kiev.ua> References: <2f15c981-8846-ddef-6593-dadc14933cc5@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,SUBJ_ALL_CAPS 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: 49Jg8x1fWkz4DJt X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 19:18:25 -0000 On Fri, May 08, 2020 at 11:22:51AM -0700, John Baldwin wrote: > On 5/7/20 10:17 AM, Warner Losh wrote: > > On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen wrote: > > > >> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, > >> which ones should I keep? I would probably confine it to head, so I > >> could prune quite a few. > >> > > > > Anything in the bootstrap path should remain, especially in the install > > portion of the bootstrap path since we don't require new compilers for > > that. I doubt there's more than one or two of these and there may be zero. > > The rest can go away. > > > > We should also look at taking out the fmake workarounds in the tree too. > > Most of these are in src/Makefile and src/Makefile.inc. > > I think Eric though was asking about and the like. Right now > we still have conditional support for some really old compilers that are > likely to never be used with FreeBSD 13 (ancient Intel icc, gcc 2.95, etc.). > > Like, do we keep support for pre-ANSI C to delete 'const' etc. via > macros? Admittedly there isn't a tremendous amount of cruft in cdefs.h. > What would seem more invasive would be to do things like require C99 and > use 'restrict' directly instead of __restrict, but the first step towards > any of that is probably to remove some of the cruft from cdefs.h and > possibly some other places. I think __restrict still needs to be around, due to C++ not supporting the keyword. Actually there is more urgent need to add some bits to cdefs.h, like c17 and newer POSIX_C_SOURCE. > > (BTW, it would be good to know if it's at all useful to keep any of the > icc bits around.) > > -- > John Baldwin > _______________________________________________ > 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 Fri May 8 21:31:47 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 817452E4DC6 for ; Fri, 8 May 2020 21:31:47 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49Jk6q0VbBz3JXd for ; Fri, 8 May 2020 21:31:47 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: by mailman.nyi.freebsd.org (Postfix) id 10E2E2E4DC4; Fri, 8 May 2020 21:31:47 +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 0F7312E4DC3; Fri, 8 May 2020 21:31:47 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [5.45.198.249]) (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 49Jk6n1chHz3JXM; Fri, 8 May 2020 21:31:44 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback23g.mail.yandex.net (mxback23g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:323]) by forward106j.mail.yandex.net (Yandex) with ESMTP id D675211A0355; Sat, 9 May 2020 00:31:41 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback23g.mail.yandex.net (mxback/Yandex) with ESMTP id pvLKJehai4-VfSGh5fr; Sat, 09 May 2020 00:31:41 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1588973501; bh=fU4KKmxUJg0b3jNHeyLKHYjK55BcgDRMnOOU3mlJZt0=; h=Message-Id:Date:Subject:To:From; b=kNvHlrWGwzeCWsOUgcDHBRLiJu8H1CD2culRH+nsyaWQ79iCq7hKzO2aa1u4X149O SdVa+Ku98wVKGbcOCkPuj8iWBqCzLmLWDsUWjInqdIAhiwLk3R4dOuKWrNL9Sb3J+t 2bckgEe2sJjQgBSpMblCg+vXPPvlT8Z6Qwl8rN9k= Received: by iva1-3b1c0a1a240c.qloud-c.yandex.net with HTTP; Sat, 09 May 2020 00:31:41 +0300 From: Alexander V. Chernikov To: "current@FreeBSD.org" , "net@freebsd.org" Subject: Next-hop objects and scalable multipath routing project status update [May 8] MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 08 May 2020 22:31:41 +0100 Message-Id: <1573911588972910@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Rspamd-Queue-Id: 49Jk6n1chHz3JXM X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=kNvHlrWG; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 5.45.198.249 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-6.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.45.192.0/19]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[249.198.45.5.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU]; IP_SCORE(-3.70)[ip: (-9.78), ipnet: 5.45.192.0/18(-4.86), asn: 13238(-3.86), country: RU(0.01)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 08 May 2020 21:31:47 -0000 Hi, I would like to share the current state and the next steps for the nhops/multipath project. To recap: project is about modernising the current routing stack and implementing scalable multipath routing. Most changes are based on introduction of the concept of nexthops. Nexthops, which are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in https://reviews.freebsd.org/D24141 . All changes[*] from the stage1 (nexthop objects introduction) has landed. Currently the focus is on upgrading various route change notification mechanisms to allow transparent multipath introduction. After that the focus will switch on landing the actual multipath implementation. [*] D24776 is pending commit tomorrow. More detailed plan: 1 Nexthop objects [In progress] 1.1 Introduction of nexthop objects [DONE: r359823] 1.2 Conversion of old KPI users to the new one [DONE] 1.2.1 Conversion of route caching to nexthop caching [DONE: r360292] 1.3 Conversion of struct `rtentry` field access to nhop field access [DONE] 1.4 Eliminating old lookup KPI and hiding struct rtentry. [95% complete, rtentry: rS360824, kpi: D24776 (pending), ] 2 Multipath [In progress] 2.1 Switch control plane customers to use (rtentry, nhop) pair instead of rtentry to allow multipath changes happen transparently. [10% complete] 2.2 Introduce nexthop group objects 2.3 Add mutipath support for the rib manipulation functions 2.4 Add flowid generation for outbound traffic to enable load balancing -- [No timeline] 3 Rtsock/netlink nhops support 3.1 Implement index lookup for nhops/nhop groups 3.2 Design rtsock messages for nhop/nhgrp operations& prefix binding 3.3 Implement kernel part 3.4 Implement frr or bird support 4 Modular longest-prefix-match lookup algorithm 4.1 Design control plane framework for attaching algos. 4.2 Implement one (IPv6?) lookup algorithm /Alexander From owner-freebsd-current@freebsd.org Sat May 9 02:40: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 D6C382D6BA4 for ; Sat, 9 May 2020 02:40:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49Jryj24bMz44yC for ; Sat, 9 May 2020 02:40:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 473C72D6BA1; Sat, 9 May 2020 02:40:13 +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 46F9F2D6BA0 for ; Sat, 9 May 2020 02:40:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jryh1thGz44y9; Sat, 9 May 2020 02:40:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f193.google.com with SMTP id j16so10236324oih.10; Fri, 08 May 2020 19:40:12 -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=etPzV5kngpNyANxLWW19MnkrIanFROgy85om3UIAwi8=; b=aFmlDikN7GMknOEnjn3OO8K3Zws0k+vDbeLkx3Ai+zV9zaqFZ/AM2UJcedQDUjNewW GcmwdA0J+xUOo0oOUXyf1WxHiaHeWF1ZMlE6XuOreSSKeazB3v89eg0I9xy8lOIKc5J3 Vgb//artbzs1lnW3NU7+DPj1BWL7uTVcaQ24QH28ceftDPyTOr+jmiZKwINvXd5utsnR SYG2Qprz8pAbfBRfXva8RO02HVTHVqPqJqV0RHZI98viIp6oZhdDV+DrWIfgRWQ46RYs q/rAQPn7QimftKWARZ5EnhwEFc4P9FjRFpiqYyX9Q/aQfPsnKutKUEJq6JO2iHaR37ee phlw== X-Gm-Message-State: AGi0Pubgf5prJYUB2M0R7MznrFh1kgEp12cJNk3TL82/8DhPB5rpSvCB KwPF7663GGij8rk5/owiFdA+/x9a31kOBe6NzSI= X-Google-Smtp-Source: APiQypJMExqB/I9p7WaSX8+lE3fqiaiwzqjoXGIVLN/YBsBAsrDmr0+5ZyKhn/v/biJvIOgNIrPcjtWum//yfbJsyP0= X-Received: by 2002:aca:4f4b:: with SMTP id d72mr12597542oib.73.1588992010775; Fri, 08 May 2020 19:40:10 -0700 (PDT) MIME-Version: 1.0 References: <20200427105124.GP2522@kib.kiev.ua> In-Reply-To: <20200427105124.GP2522@kib.kiev.ua> From: Alan Somers Date: Fri, 8 May 2020 20:39:59 -0600 Message-ID: Subject: Re: Panic in fusefs(5) on 13.0-CURRENT r359773 To: Konstantin Belousov Cc: Mateusz Piotrowski <0mp@freebsd.org>, current X-Rspamd-Queue-Id: 49Jryh1thGz44y9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.193 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.901,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.90)[-0.899,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[freebsd.org]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[193.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.17)[ip: (0.00), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 02:40:13 -0000 On Mon, Apr 27, 2020 at 4:51 AM Konstantin Belousov wrote: > On Mon, Apr 27, 2020 at 11:39:41AM +0200, Mateusz Piotrowski wrote: > > Hi everyone! > > > > I'm experiencing panics every day. Apparently, they are caused by a bug > in > > our FUSE implementation. > > > > The panic occurs when I'm editing files in a folder mounted via SSHFS > from a > > bhyve VM running Ubuntu 18.04. > > > > I'm sending some parts of the core.txt file. Let me know if I can provide > > any additional information. > > > > Cheers, > > > > Mateusz > > > > ------- > > > > t480 dumped core - see /var/crash/vmcore.3 > > > > Mon Apr 27 11:30:19 CEST 2020 > > > > FreeBSD t480 13.0-CURRENT FreeBSD 13.0-CURRENT #4 r359773: Sat Apr 11 > > 05:32:31 CEST 2020 root@t480:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > > > panic: Assertion bp->b_flags & B_VMIO failed at > > /usr/src/sys/fs/fuse/fuse_node.c:433 > > > > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > > Copyright (C) 2020 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "x86_64-portbld-freebsd13.0". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > . > > Find the GDB manual and other documentation resources online at: > > . > > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from /boot/kernel/kernel... > > Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... > > > > Unread portion of the kernel message buffer: > > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577 > > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577 > > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577 > > WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) > failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:622 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at > /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 > > <4>WARN_ON(!mutex_is_locked(&dev->struct_mutex)) > > > > <4>WARN_ON(!mutex_is_locked(&fbc->lock)) > > > > > <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock)) > > panic: Assertion bp->b_flags & B_VMIO failed at > > /usr/src/sys/fs/fuse/fuse_node.c:433 > > cpuid = 5 > > time = 1587979693 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfffffe00cc0ef330 > > vpanic() at vpanic+0x182/frame 0xfffffe00cc0ef380 > > panic() at panic+0x43/frame 0xfffffe00cc0ef3e0 > > fuse_vnode_setsize() at fuse_vnode_setsize+0x135/frame 0xfffffe00cc0ef430 > > fuse_internal_cache_attrs() at fuse_internal_cache_attrs+0xc4/frame > > 0xfffffe00cc0ef490 > > fuse_vnop_lookup() at fuse_vnop_lookup+0x6bf/frame 0xfffffe00cc0ef620 > > lookup() at lookup+0x5e1/frame 0xfffffe00cc0ef6c0 > > namei() at namei+0x524/frame 0xfffffe00cc0ef7b0 > > kern_statat() at kern_statat+0x7f/frame 0xfffffe00cc0ef8d0 > > sys_fstatat() at sys_fstatat+0x2f/frame 0xfffffe00cc0ef9d0 > > amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe00cc0efaf0 > > fast_syscall_common() at fast_syscall_common+0x101/frame > 0xfffffe00cc0efaf0 > > --- syscall (552, FreeBSD ELF64, sys_fstatat), rip = 0x8006c2aaa, rsp = > > 0x7fffffffda78, rbp = 0x7fffffffdb20 --- > > KDB: enter: panic > > > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct > pcpu, > > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394 > > #2 0xffffffff8049a43a in db_dump (dummy=, > > dummy2=, dummy3=, dummy4=) > > at /usr/src/sys/ddb/db_command.c:575 > > #3 0xffffffff8049a1fc in db_command (last_cmdp=, > > cmd_table=, dopager=1) at > > /usr/src/sys/ddb/db_command.c:482 > > #4 0xffffffff80499f6d in db_command_loop () > > at /usr/src/sys/ddb/db_command.c:535 > > #5 0xffffffff8049d168 in db_trap (type=, code= > out>) > > at /usr/src/sys/ddb/db_main.c:253 > > #6 0xffffffff80c06f24 in kdb_trap (type=3, code=0, tf=) > > at /usr/src/sys/kern/subr_kdb.c:699 > > #7 0xffffffff8105bc68 in trap (frame=0xfffffe00cc0ef260) > > at /usr/src/sys/amd64/amd64/trap.c:578 > > #8 > > #9 kdb_enter (why=0xffffffff811ea4f2 "panic", msg=) > > at /usr/src/sys/kern/subr_kdb.c:486 > > #10 0xffffffff80bbc9fe in vpanic (fmt=, ap= out>) > > at /usr/src/sys/kern/kern_shutdown.c:902 > > #11 0xffffffff80bbc793 in panic ( > > fmt=0xffffffff81c8db28 "*\350\032\201\377\377\377\377") > > at /usr/src/sys/kern/kern_shutdown.c:839 > > #12 0xffffffff83f0ba05 in fuse_vnode_setsize (vp=0xfffff801e94515b8, > > newsize=13793) at /usr/src/sys/fs/fuse/fuse_node.c:433 > > #13 0xffffffff83f15a74 in fuse_internal_cache_attrs > (vp=0xfffff801e94515b8, > > attr=0xfffffe012ba5b028, attr_valid=1, attr_valid_nsec=0, vap=0x0) > > at /usr/src/sys/fs/fuse/fuse_internal.c:267 > > #14 0xffffffff83f1346e in fuse_vnop_lookup (ap=) > > at /usr/src/sys/fs/fuse/fuse_vnops.c:1187 > > #15 0xffffffff80c873b1 in VOP_LOOKUP (dvp=0xfffff801e9451988, > > vpp=0xfffffe00cc0ef820, cnp=0xfffffe00cc0ef850) at ./vnode_if.h:54 > > #16 lookup (ndp=0xfffffe00cc0ef7c0) at /usr/src/sys/kern/vfs_lookup.c:951 > > #17 0xffffffff80c868e4 in namei (ndp=0xfffffe00cc0ef7c0) > > at /usr/src/sys/kern/vfs_lookup.c:512 > > #18 0xffffffff80ca210f in kern_statat (td=0xfffffe00cc61f800, > > flag=, fd=, > > path=0x800c9ff50 0x800c9ff50>, > > pathseg=UIO_USERSPACE, sbp=0xfffffe00cc0ef8e8, hook=0x0) > > at /usr/src/sys/kern/vfs_syscalls.c:2340 > > #19 0xffffffff80ca28cf in sys_fstatat (td=0xffffffff81c8db28 > , > > uap=0xfffffe00cc61fbd8) at /usr/src/sys/kern/vfs_syscalls.c:2317 > > #20 0xffffffff8105caa0 in syscallenter (td=) > > at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:162 > > #21 amd64_syscall (td=0xfffffe00cc61f800, traced=0) > > at /usr/src/sys/amd64/amd64/trap.c:1161 > > #22 > > #23 0x00000008006c2aaa in ?? () > > Backtrace stopped: Cannot access memory at address 0x7fffffffda78 > > (kgdb) > > I believe that in your case, the file is stat(2)-ed without being opened > before, and might be because the stat(2) is called twice, while file size > is changed, fusefs wants to resize. > > For such vnodes, v_object is not created yet, so getblk() sets B_CACHE > because both B_VMIO and B_INVAL are clear. So it might be worth just do > nothing if v_object is NULL even if newsize < oldsize. > > What I do not understand is why vfs_bio_clrbuf() is correct there at all. > It has block granularity, so either we clear too much or too little. > And the data after EOF in the last buffer is not going to be used anyway. > At worst, it might cause userspace which mapped the backing pages to still > see the data after EOF, and if this is a problem, then manual bzero() is > needed anyway. > Two questions: 1) It sounds like this panic happens pretty regularly. Did it ever happen before you updated to r358867 ? 2) Have you found a reliable way to reproduce the panic yet? -Alan From owner-freebsd-current@freebsd.org Sat May 9 03:10: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 CE32B2D9106 for ; Sat, 9 May 2020 03:10:08 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49JsdD3qPjz47px for ; Sat, 9 May 2020 03:10:08 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: by mailman.nyi.freebsd.org (Postfix) id 830642D9105; Sat, 9 May 2020 03:10:08 +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 82AE52D9104 for ; Sat, 9 May 2020 03:10:08 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 49JsdC14sSz47pp for ; Sat, 9 May 2020 03:10:06 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1588993805; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=u4aa01rITpJhMmrIKQP3iSCTT4A=; b=Mlr3Z1Reb5v9P16ywjkRgAOUVRf7Di5dtaokcau3sEQZ5W+6qRAgiOW1OTRfpc+t TgBwBmuSmq22iMQIH4GNFq5rVg/g4n8zGNsJA8yukH1OtMQ/oHmm7FCfd8ywcHCo JthlA4+R719vYQXhqjRbilHhxkz38Un35h/kcAuhElj+X2n7GxQ3NOVGuEqmOGMg 3iXddKIv/txFNQ29XC+jFPjYRlJghQBhrQnYE9baMhaM6CeFKT1j+6f3lyom8RNX DqX7H9ctPGyamfMiB9DMCJwb3SrhhMkrbw9ka7qNeKY8BItZ/HFluo5vz9F90QaE GuKGgEq1MzYAumFAaFp9ug==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=J+PUEzvS c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=sTwFKg_x9MkA:10 a=48faUk6PgeAA:10 a=Gz9FAwiyw_CSBYzkx6IA:9 a=FlEqhASGHamUR4iX:21 a=9jM2TmADArFoEcIO:21 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [209.6.230.48] ([209.6.230.48:16417] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id 44/57-42436-D0F16BE5; Fri, 08 May 2020 23:10:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <24246.7948.924564.999680@jerusalem.litteratus.org> Date: Fri, 8 May 2020 23:10:04 -0400 From: Robert Huff To: bsd-lists@BSDforge.com Cc: Robert Huff , Subject: Re: "make buildworld" fails for r360785? In-Reply-To: <849835c13cac7bb6ce9f6e13eaa3b589@udns.ultimatedns.net> References: <24244.52698.726479.288103@jerusalem.litteratus.org> <849835c13cac7bb6ce9f6e13eaa3b589@udns.ultimatedns.net> X-Mailer: VM 8.2.0b under 26.3 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: 49JsdC14sSz47pp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail (body hash did not verify) header.d=rcn.com header.s=20180516 header.b=Mlr3Z1Re; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-3.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[78.97.168.69.rep.mailspike.net : 127.0.0.17]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; R_DKIM_REJECT(0.00)[rcn.com:s=20180516]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.55)[ip: (-9.05), ipnet: 69.168.97.0/24(0.64), asn: 36271(0.71), country: US(-0.05)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rcn.com:-]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(0.00)[rcn.com,none]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 03:10:08 -0000 DQpDaHJpcyB3cml0ZXM6DQo+ICA+IAkibWFrZSBidWlsZG93cmxkIiBmYWlscyB3aXRoOg0KPiAg PiANCj4gID4gPiAgYysrICAtTzIgLXBpcGUgLWZuby1jb21tb24NCj4gID4gPiAgLUkvdXNyL29i ai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9vYmotdG9vbHMvbGliL2NsYW5nL2xpYmNsYW5nDQo+ ICA+ID4gIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9j bGFuZy9saWJsbHZtDQo+ICA+ID4gIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvY2xh bmcvbGliL0Jhc2ljDQo+ICA+ID4gIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvY2xh bmcvbGliL0RyaXZlcg0KPiAgPiA+ICAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2Ns YW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9saWIvY2xhbmcvaW5jbHVkZQ0KPiAgLi4uDQo+ICA+ID4g IC1ETExWTV9OQVRJVkVfVEFSR0VUTUM9TExWTUluaXRpYWxpemVYODZUYXJnZXRNQyAtZmZ1bmN0 aW9uLXNlY3Rpb25zDQo+ICA+ID4gIC1mZGF0YS1zZWN0aW8NCj4gID4gbnMgLU1EIC1NRi5kZXBl bmQuQmFzaWNfU291cmNlTWFuYWdlci5vIC1NVEJhc2ljL1NvdXJjZU1hbmFnZXIubw0KPiAgPiAt V25vLWZvcm1hdC16ZXJvLWxlbmd0aCAtUXVudXNlZC1hcmd1bWVudHMNCj4gID4gLUkvdXNyL29i ai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgIC1mbm8tZXhjZXB0 aW9ucw0KPiAgPiAtZm5vLXJ0dGkgLXN0ZD1jKysxNCAtc3RkbGliPWxpYmMrKyAtV25vLWMrKzEx LWV4dGVuc2lvbnMgICAtYw0KPiAgPiAvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFu Zy9saWIvQmFzaWMvU291cmNlTWFuYWdlci5jcHAgLW8NCj4gID4gQmFzaWMvU291cmNlTWFuYWdl ci5vDQo+ICA+ID4gIC91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNp Yy9Tb3VyY2VNYW5hZ2VyLmNwcDoxMjI4OjEwOg0KPiAgPiA+ICBmYXRhbCBlcnJvcjogJ2VtbWlu dHJpbi5oJyBmaWxlIG5vdCBmb3VuZA0KPiAgPiA+ICAjaW5jbHVkZSA8ZW1taW50cmluLmg+DQo+ ICA+ID4gICAgICAgICAgIF5+fn5+fn5+fn5+fn4NCj4gID4gPiAgMSBlcnJvciBnZW5lcmF0ZWQu DQo+ICA+ID4gICoqKiBFcnJvciBjb2RlIDENCj4NCj4gIEkgcmFuIGlvbnRvIHRoaXMgYXdoaWxl IGJhY2ssIGFuZCBJIHRoaW5rIHRoZSB3YXkgSSB3YXMgYWJsZSB0byBzb2x2ZSBpdCB3aXRoIGEN Cj4gIG1ha2Uga2VybmVsLXRvb2xjaGFpbg0KDQoJSSB0cmllZCBib3RoICJtYWtlIHRvb2xjaGFp biIgYW5kICJtYWtlIGtlcm5lbC10b29sY2hhaW4iOyBib3RoDQpmYWlsZWQgd2l0aCANCg0KYysr ICAtTzIgLXBpcGUgLWZuby1jb21tb24gLUkvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3Rt cC9vYmotdG9vbHMvbGliL2NsYW5nL2xpYmNsYW5nIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5h bWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9saWJsbHZtIC1JL3Vzci9zcmMvY29udHJpYi9s bHZtLXByb2plY3QvY2xhbmcvbGliL0Jhc2ljIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2pl Y3QvY2xhbmcvbGliL0RyaXZlciAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5n L2luY2x1ZGUgLUkvdXNyL3NyYy9saWIvY2xhbmcvaW5jbHVkZSAtSS91c3Ivc3JjL2NvbnRyaWIv bGx2bS1wcm9qZWN0L2xsdm0vaW5jbHVkZSAtRF9fU1REQ19DT05TVEFOVF9NQUNST1MgLURfX1NU RENfRk9STUFUX01BQ1JPUyAtRF9fU1REQ19MSU1JVF9NQUNST1MgLURIQVZFX1ZDU19WRVJTSU9O X0lOQyAtRExMVk1fREVGQVVMVF9UQVJHRVRfVFJJUExFPVwieDg2XzY0LXVua25vd24tZnJlZWJz ZDEzLjBcIiAtRExMVk1fSE9TVF9UUklQTEU9XCJ4ODZfNjQtdW5rbm93bi1mcmVlYnNkMTMuMFwi IC1EREVGQVVMVF9TWVNST09UPVwiL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXBcIiAt RExMVk1fVEFSR0VUX0VOQUJMRV9YODYgLURMTFZNX05BVElWRV9BU01QQVJTRVI9TExWTUluaXRp YWxpemVYODZBc21QYXJzZXIgLURMTFZNX05BVElWRV9BU01QUklOVEVSPUxMVk1Jbml0aWFsaXpl WDg2QXNtUHJpbnRlciAtRExMVk1fTkFUSVZFX0RJU0FTU0VNQkxFUj1MTFZNSW5pdGlhbGl6ZVg4 NkRpc2Fzc2VtYmxlciAtRExMVk1fTkFUSVZFX1RBUkdFVD1MTFZNSW5pdGlhbGl6ZVg4NlRhcmdl dCAtRExMVk1fTkFUSVZFX1RBUkdFVElORk89TExWTUluaXRpYWxpemVYODZUYXJnZXRJbmZvIC1E TExWTV9OQVRJVkVfVEFSR0VUTUM9TExWTUluaXRpYWxpemVYODZUYXJnZXRNQyAtZmZ1bmN0aW9u LXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtTUQgLU1GLmRlcGVuZC5CYXNpY19TYW5pdGl6ZXJT cGVjaWFsQ2FzZUxpc3QubyAtTVRCYXNpYy9TYW5pdGl6ZXJTcGVjaWFsQ2FzZUxpc3QubyAtV25v LWZvcm1hdC16ZXJvLWxlbmd0aCAtUXVudXNlZC1hcmd1bWVudHMgLUkvdXNyL29iai91c3Ivc3Jj L2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgIC1mbm8tZXhjZXB0aW9ucyAtZm5v LXJ0dGkgLXN0ZD1jKysxNCAtc3RkbGliPWxpYmMrKyAtV25vLWMrKzExLWV4dGVuc2lvbnMgICAt YyAvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFzaWMvU2FuaXRpemVy U3BlY2lhbENhc2VMaXN0LmNwcCAtbyBCYXNpYy9TYW5pdGl6ZXJTcGVjaWFsQ2FzZUxpc3Qubw0K YysrICAtTzIgLXBpcGUgLWZuby1jb21tb24gLUkvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0 L3RtcC9vYmotdG9vbHMvbGliL2NsYW5nL2xpYmNsYW5nIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2 NC5hbWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9saWJsbHZtIC1JL3Vzci9zcmMvY29udHJp Yi9sbHZtLXByb2plY3QvY2xhbmcvbGliL0Jhc2ljIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXBy b2plY3QvY2xhbmcvbGliL0RyaXZlciAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2Ns YW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9saWIvY2xhbmcvaW5jbHVkZSAtSS91c3Ivc3JjL2NvbnRy aWIvbGx2bS1wcm9qZWN0L2xsdm0vaW5jbHVkZSAtRF9fU1REQ19DT05TVEFOVF9NQUNST1MgLURf X1NURENfRk9STUFUX01BQ1JPUyAtRF9fU1REQ19MSU1JVF9NQUNST1MgLURIQVZFX1ZDU19WRVJT SU9OX0lOQyAtRExMVk1fREVGQVVMVF9UQVJHRVRfVFJJUExFPVwieDg2XzY0LXVua25vd24tZnJl ZWJzZDEzLjBcIiAtRExMVk1fSE9TVF9UUklQTEU9XCJ4ODZfNjQtdW5rbm93bi1mcmVlYnNkMTMu MFwiIC1EREVGQVVMVF9TWVNST09UPVwiL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXBc IiAtRExMVk1fVEFSR0VUX0VOQUJMRV9YODYgLURMTFZNX05BVElWRV9BU01QQVJTRVI9TExWTUlu aXRpYWxpemVYODZBc21QYXJzZXIgLURMTFZNX05BVElWRV9BU01QUklOVEVSPUxMVk1Jbml0aWFs aXplWDg2QXNtUHJpbnRlciAtRExMVk1fTkFUSVZFX0RJU0FTU0VNQkxFUj1MTFZNSW5pdGlhbGl6 ZVg4NkRpc2Fzc2VtYmxlciAtRExMVk1fTkFUSVZFX1RBUkdFVD1MTFZNSW5pdGlhbGl6ZVg4NlRh cmdldCAtRExMVk1fTkFUSVZFX1RBUkdFVElORk89TExWTUluaXRpYWxpemVYODZUYXJnZXRJbmZv IC1ETExWTV9OQVRJVkVfVEFSR0VUTUM9TExWTUluaXRpYWxpemVYODZUYXJnZXRNQyAtZmZ1bmN0 aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtTUQgLU1GLmRlcGVuZC5CYXNpY19TYW5pdGl6 ZXJzLm8gLU1UQmFzaWMvU2FuaXRpemVycy5vIC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1RdW51 c2VkLWFyZ3VtZW50cyAtSS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91 c3IvaW5jbHVkZSAgLWZuby1leGNlcHRpb25zIC1mbm8tcnR0aSAtc3RkPWMrKzE0IC1zdGRsaWI9 bGliYysrIC1Xbm8tYysrMTEtZXh0ZW5zaW9ucyAgIC1jIC91c3Ivc3JjL2NvbnRyaWIvbGx2bS1w cm9qZWN0L2NsYW5nL2xpYi9CYXNpYy9TYW5pdGl6ZXJzLmNwcCAtbyBCYXNpYy9TYW5pdGl6ZXJz Lm8NCmMrKyAgLU8yIC1waXBlIC1mbm8tY29tbW9uIC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5h bWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9saWJjbGFuZyAtSS91c3Ivb2JqL3Vzci9zcmMv YW1kNjQuYW1kNjQvdG1wL29iai10b29scy9saWIvY2xhbmcvbGlibGx2bSAtSS91c3Ivc3JjL2Nv bnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYyAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2 bS1wcm9qZWN0L2NsYW5nL2xpYi9Ecml2ZXIgLUkvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVj dC9jbGFuZy9pbmNsdWRlIC1JL3Vzci9zcmMvbGliL2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9j b250cmliL2xsdm0tcHJvamVjdC9sbHZtL2luY2x1ZGUgLURfX1NURENfQ09OU1RBTlRfTUFDUk9T IC1EX19TVERDX0ZPUk1BVF9NQUNST1MgLURfX1NURENfTElNSVRfTUFDUk9TIC1ESEFWRV9WQ1Nf VkVSU0lPTl9JTkMgLURMTFZNX0RFRkFVTFRfVEFSR0VUX1RSSVBMRT1cIng4Nl82NC11bmtub3du LWZyZWVic2QxMy4wXCIgLURMTFZNX0hPU1RfVFJJUExFPVwieDg2XzY0LXVua25vd24tZnJlZWJz ZDEzLjBcIiAtRERFRkFVTFRfU1lTUk9PVD1cIi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQv dG1wXCIgLURMTFZNX1RBUkdFVF9FTkFCTEVfWDg2IC1ETExWTV9OQVRJVkVfQVNNUEFSU0VSPUxM Vk1Jbml0aWFsaXplWDg2QXNtUGFyc2VyIC1ETExWTV9OQVRJVkVfQVNNUFJJTlRFUj1MTFZNSW5p dGlhbGl6ZVg4NkFzbVByaW50ZXIgLURMTFZNX05BVElWRV9ESVNBU1NFTUJMRVI9TExWTUluaXRp YWxpemVYODZEaXNhc3NlbWJsZXIgLURMTFZNX05BVElWRV9UQVJHRVQ9TExWTUluaXRpYWxpemVY ODZUYXJnZXQgLURMTFZNX05BVElWRV9UQVJHRVRJTkZPPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0 SW5mbyAtRExMVk1fTkFUSVZFX1RBUkdFVE1DPUxMVk1Jbml0aWFsaXplWDg2VGFyZ2V0TUMgLWZm dW5jdGlvbi1zZWN0aW9ucyAtZmRhdGEtc2VjdGlvbnMgLU1EIC1NRi5kZXBlbmQuQmFzaWNfU291 cmNlTG9jYXRpb24ubyAtTVRCYXNpYy9Tb3VyY2VMb2NhdGlvbi5vIC1Xbm8tZm9ybWF0LXplcm8t bGVuZ3RoIC1RdW51c2VkLWFyZ3VtZW50cyAtSS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAgLWZuby1leGNlcHRpb25zIC1mbm8tcnR0aSAtc3RkPWMr KzE0IC1zdGRsaWI9bGliYysrIC1Xbm8tYysrMTEtZXh0ZW5zaW9ucyAgIC1jIC91c3Ivc3JjL2Nv bnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYy9Tb3VyY2VMb2NhdGlvbi5jcHAgLW8g QmFzaWMvU291cmNlTG9jYXRpb24ubw0KYysrICAtTzIgLXBpcGUgLWZuby1jb21tb24gLUkvdXNy L29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9vYmotdG9vbHMvbGliL2NsYW5nL2xpYmNsYW5n IC1JL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvb2JqLXRvb2xzL2xpYi9jbGFuZy9s aWJsbHZtIC1JL3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvY2xhbmcvbGliL0Jhc2ljIC1J L3Vzci9zcmMvY29udHJpYi9sbHZtLXByb2plY3QvY2xhbmcvbGliL0RyaXZlciAtSS91c3Ivc3Jj L2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2luY2x1ZGUgLUkvdXNyL3NyYy9saWIvY2xhbmcv aW5jbHVkZSAtSS91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2xsdm0vaW5jbHVkZSAtRF9f U1REQ19DT05TVEFOVF9NQUNST1MgLURfX1NURENfRk9STUFUX01BQ1JPUyAtRF9fU1REQ19MSU1J VF9NQUNST1MgLURIQVZFX1ZDU19WRVJTSU9OX0lOQyAtRExMVk1fREVGQVVMVF9UQVJHRVRfVFJJ UExFPVwieDg2XzY0LXVua25vd24tZnJlZWJzZDEzLjBcIiAtRExMVk1fSE9TVF9UUklQTEU9XCJ4 ODZfNjQtdW5rbm93bi1mcmVlYnNkMTMuMFwiIC1EREVGQVVMVF9TWVNST09UPVwiL3Vzci9vYmov dXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXBcIiAtRExMVk1fVEFSR0VUX0VOQUJMRV9YODYgLURMTFZN X05BVElWRV9BU01QQVJTRVI9TExWTUluaXRpYWxpemVYODZBc21QYXJzZXIgLURMTFZNX05BVElW RV9BU01QUklOVEVSPUxMVk1Jbml0aWFsaXplWDg2QXNtUHJpbnRlciAtRExMVk1fTkFUSVZFX0RJ U0FTU0VNQkxFUj1MTFZNSW5pdGlhbGl6ZVg4NkRpc2Fzc2VtYmxlciAtRExMVk1fTkFUSVZFX1RB UkdFVD1MTFZNSW5pdGlhbGl6ZVg4NlRhcmdldCAtRExMVk1fTkFUSVZFX1RBUkdFVElORk89TExW TUluaXRpYWxpemVYODZUYXJnZXRJbmZvIC1ETExWTV9OQVRJVkVfVEFSR0VUTUM9TExWTUluaXRp YWxpemVYODZUYXJnZXRNQyAtZmZ1bmN0aW9uLXNlY3Rpb25zIC1mZGF0YS1zZWN0aW9ucyAtTUQg LU1GLmRlcGVuZC5CYXNpY19Tb3VyY2VNYW5hZ2VyLm8gLU1UQmFzaWMvU291cmNlTWFuYWdlci5v IC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RoIC1RdW51c2VkLWFyZ3VtZW50cyAtSS91c3Ivb2JqL3Vz ci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAgLWZuby1leGNlcHRpb25z IC1mbm8tcnR0aSAtc3RkPWMrKzE0IC1zdGRsaWI9bGliYysrIC1Xbm8tYysrMTEtZXh0ZW5zaW9u cyAgIC1jIC91c3Ivc3JjL2NvbnRyaWIvbGx2bS1wcm9qZWN0L2NsYW5nL2xpYi9CYXNpYy9Tb3Vy Y2VNYW5hZ2VyLmNwcCAtbyBCYXNpYy9Tb3VyY2VNYW5hZ2VyLm8NCkluIGZpbGUgaW5jbHVkZWQg ZnJvbSAvdXNyL3NyYy9jb250cmliL2xsdm0tcHJvamVjdC9jbGFuZy9saWIvQmFzaWMvU291cmNl TWFuYWdlci5jcHA6MTIyODoNCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAvdXNyL2luY2x1ZGUvZW1t aW50cmluLmg6MTM6DQovdXNyL2luY2x1ZGUveG1taW50cmluLmg6Mjc6MTA6IGZhdGFsIGVycm9y OiAnbW1fbWFsbG9jLmgnIGZpbGUgbm90IGZvdW5kDQojaW5jbHVkZSA8bW1fbWFsbG9jLmg+DQog ICAgICAgICBefn5+fn5+fn5+fn5+DQoxIGVycm9yIGdlbmVyYXRlZC4NCioqKiBFcnJvciBjb2Rl IDENCg0KDQoJU28gLi4uIHByb2dyZXNzICh5ZXM/KSwgYnV0IG5vdCBzdWNjZXNzLiAgOi0oDQoJ V2hhdCBuZXh0Pw0KDQoNCgkJCVJlc3BlY3RmdWxseSwNCg0KDQoJCQkJUm9iZXJ0IEh1ZmYNCg0K DQo= From owner-freebsd-current@freebsd.org Sat May 9 03:58:10 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 12D032DB531 for ; Sat, 9 May 2020 03:58:10 +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 49Jthb6Smqz4Bwm for ; Sat, 9 May 2020 03:58:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: s0_eZEgVM1kntVEPp5zUb2Pq16aoJ1O8ool0YjqYxqXmvYgL8PHMFtmIwpbNfpG pxKFMBhV3sd28Fx3ufO1P5mYcQLHKDE1m5CZzhFzyJBBMzzHtBfxBLVnqAWkMyyAuZmqZ2ScnjMj cxVGWsQGfYur.9Ku7XZW._hrh8RLnFRQCF01D.moEPnPC0WTgKFm_GXn7SYkq6.Pg6C90yZDMjqw Vtib5SySCCLgrjLLrOua8o8Uh7FLsJFZygoKZytO0hCCStPuAaW._U0kSIRb92mwxPouIJHkvBr_ nhGADpZV5WmJ0Leor8z1Ku2dfqMpuFWQDd4zljLTUQpkYSKM7TBGNXLF8WE7Q8k41QyVZecMRvN9 Ufxzs78oOVrOELk6f0Ia71uSXshU6WRWmq2jMlAZhNeZVQpGnOHOPPqL9W1ZHhiUc27yY.lE1etw QWnCahLz9ApGIXMgeyzuhnosN517oR728w6YmL2gckxVaz4XSt.gfnz0ZqwBCWsazBp.7IfcI0bR b6FzhWhZCJiveX4tnkrTfGRyKRLiyT4k.S1uNWeI8.NQpRaCsA.NYPNTYqMt_Kht2TllSaWodXbH qSCyfW3o3azjKBGB5UkknnupwGfAWQLuy.qIqu56S7sLr27rX7truy_X1uvGowvx5ZXNZaNePqxT I1ZJG29M_Z80wl6BTuJL6jXByXHuAnPe1mT_XOxkvu7ZQdUJ6AbMiiuvfTglinoJhdDYfsxB5pVP HBviAwEBQXU0H6xcu02h2hkHWis.ktNJHlSRuAuTCr85WiDzqTyfsA1iRg611eV6.GKIexXNiUG7 whjFVar0Me_25vxiy3AgllxABzMXSTA5.FTuvVrzstGE0.eicLA318w7ty2jhII4lQTQpLP1abby .dKS7I4hgQosHxEicdvmZaLdTU3cbZ4eWLh7l9VzphGNSxT15mPVyqAiz78Igiak.HBJFoqmxuMD 09jARYa2OwCSVXPG8QAa72U47SlhwJVlyhfLUnA0cNuLcM_4Lw.g3eL5SNWKlTVMGuCGBvl4JKB3 LBNhojpv9exZQmEqy7QnNOGZfMOV76T1VdOARbW5WuCvDR2RsbnqxIHeGwDvIF4m7YTIV90XhbVK qderv9zcQCJZQTJYHj7WHEiCVg2dmFQ4Fv4K6nCNAMrkzufYII4jHJo7CjwccD1TrUJDp0doHSZt 82JCGkLWphzUXwMFeYfgRQLRt3AkU5mM_4YltVflTxRDVhDGyqsUaVnN98V101ghOlN0DcOSI6Ht CKIeM6UphwsEE2HG1HovfZMnv9RN1EhaA2ia.NNY_kAxOrRS232wMCuyYz3kZ7nQ86DDl6f8SR0R 1ZA.iRPhbPWJR0rozq7W0hb3l1Vm1QHhvgUd2cYhL2cWgYnndUzL2RwfkmGjlvMIFm5AaPKoCADw sVVUYgN0GqHUK64o2bSpDQa_OWbQXF08- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 May 2020 03:58:04 +0000 Received: by smtp415.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 143842a2404404a60b46c84d00c5d4fd; Sat, 09 May 2020 03:58:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Fri, 8 May 2020 20:58:02 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Jthb6Smqz4Bwm X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; 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.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.62)[-0.617,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.77)[-0.771,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (7.01), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 03:58:10 -0000 [I caused nfsd to having things shifted in mmeory some to see it it tracked content vs. page boundary for where the zeros stop. Non-nfsd examples omitted.] > . . . >> nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) >=20 > [Correction: That should have referenced sz_index2size_lookup(index).] >=20 >> (also, but a different caller of sz_size2index): >=20 > [Correction: The "also" comment should be ignored: > sz_index2size_lookup(index) is referenced below.] >=20 >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 >> #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 >> #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 >> #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 >> #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 >> #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 >> #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12,= free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 >> #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 >> #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 >> #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 >> #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 >> #15 >> #16 0x00000000 in ?? () >>=20 >> (gdb) up 3 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >>=20 >> (ret is optimized out.) >>=20 >> 197 JEMALLOC_ALWAYS_INLINE size_t >> 198 sz_index2size_lookup(szind_t index) { >> 199 size_t ret =3D (size_t)sz_index2size_tab[index]; >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >> 201 return ret; >> 202 } >=20 > (gdb) print/x __je_sz_index2size_tab > $3 =3D {0x0 } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 >> Booting and immediately trying something like: >>=20 >> service nfsd stop >>=20 >> did not lead to a failure. But may be after >> a while it would and be less drastic than a >> reboot or power down. >=20 > More detail: >=20 > So, for rpcbind and nfds at some point a large part of > __je_sz_size2index_tab is being stomped on, as is all of > __je_sz_index2size_tab and more. >=20 > . . . >=20 > For nfsd, it is similar (again showing the partially > non-zero live process context instead of the all-zeros > from the .core file): >=20 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 > 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 > 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5030cb30 __je_narenas_auto > 0x5030cb38 malloc_conf > 0x5030cb3c __je_ncpus > 0x5030cb40 __je_manual_arena_base > 0x5030cb80 __je_sz_pind2sz_tab > 0x5030ccc0 __je_sz_index2size_tab > 0x5030ce80 __je_sz_size2index_tab >=20 >=20 > Note: because __je_arenas is normally > mostly zero for these contexts, I can > not tell where the memory trashing > started, only where it replaced non-zero > values with zeros. > . . . I caused the memory content to have shifted some in nfsd. The resultant zeros-stop-at from the failure look like: (gdb) x/128x __je_sz_size2index_tab 0x5030cf00 <__je_sz_size2index_tab>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf10 <__je_sz_size2index_tab+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf20 <__je_sz_size2index_tab+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf30 <__je_sz_size2index_tab+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf40 <__je_sz_size2index_tab+64>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf50 <__je_sz_size2index_tab+80>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf60 <__je_sz_size2index_tab+96>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf70 <__je_sz_size2index_tab+112>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cf80 <__je_sz_size2index_tab+128>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cf90 <__je_sz_size2index_tab+144>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfa0 <__je_sz_size2index_tab+160>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfb0 <__je_sz_size2index_tab+176>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfc0 <__je_sz_size2index_tab+192>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfd0 <__je_sz_size2index_tab+208>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfe0 <__je_sz_size2index_tab+224>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cff0 <__je_sz_size2index_tab+240>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030d000 <__je_sz_size2index_tab+256>: 0x18191919 = 0x19191919 0x19191919 0x19191919 0x5030d010 <__je_sz_size2index_tab+272>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d020 <__je_sz_size2index_tab+288>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d030 <__je_sz_size2index_tab+304>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d040 <__je_sz_size2index_tab+320>: 0x191a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d050 <__je_sz_size2index_tab+336>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d060 <__je_sz_size2index_tab+352>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d070 <__je_sz_size2index_tab+368>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d080 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d090 <__je_sz_size2index_tab+400>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0a0 <__je_sz_size2index_tab+416>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0b0 <__je_sz_size2index_tab+432>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0c0 <__je_sz_size2index_tab+448>: 0x1b1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0d0 <__je_sz_size2index_tab+464>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0e0 <__je_sz_size2index_tab+480>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0f0 <__je_sz_size2index_tab+496>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c So, it is the page boundary that it tracks, not the detailed placement of the memory contents. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sat May 9 08: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 D93A32E0EA0 for ; Sat, 9 May 2020 08:52:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49K1DH5ScGz4SkJ for ; Sat, 9 May 2020 08:52:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id BB4852E0E9F; Sat, 9 May 2020 08:52:31 +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 BB0EF2E0E9E for ; Sat, 9 May 2020 08:52:31 +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) server-signature RSA-PSS (4096 bits) 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 49K1DH4VHhz4SkH; Sat, 9 May 2020 08:52:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 7CA3618B5F; Sat, 9 May 2020 08:52:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::c46:20c:cce1:f24f] (unknown [IPv6:2001:470:7a58:0:c46:20c:cce1:f24f]) (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 88B8E58263; Sat, 9 May 2020 10:52:30 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7FEA86C6-2B0B-4EC1-93BB-A67B0BF61028"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: "make buildworld" fails for r360785? Date: Sat, 9 May 2020 10:52:22 +0200 In-Reply-To: <24246.7948.924564.999680@jerusalem.litteratus.org> Cc: "bsd-lists@bsdforge.com" , current@freebsd.org To: Robert Huff References: <24244.52698.726479.288103@jerusalem.litteratus.org> <849835c13cac7bb6ce9f6e13eaa3b589@udns.ultimatedns.net> <24246.7948.924564.999680@jerusalem.litteratus.org> X-Mailer: Apple Mail (2.3445.104.14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 08:52:31 -0000 --Apple-Mail=_7FEA86C6-2B0B-4EC1-93BB-A67B0BF61028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 May 2020, at 05:10, Robert Huff wrote: >=20 > Chris writes: >>> "make buildowrld" fails with: ... >>>> = /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: >>>> fatal error: 'emmintrin.h' file not found >>>> #include >>>> ^~~~~~~~~~~~~ ... > In file included from = /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228: > In file included from /usr/include/emmintrin.h:13: > /usr/include/xmmintrin.h:27:10: fatal error: 'mm_malloc.h' file not = found > #include > ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 During which stage of buildworld is this? If it is during the cross-tools stage, your host environment is busted somehow. This appears to happen to some people on this list, for unknown reasons. My guess is they either run "make delete-old" before running buildworld (which is the wrong order!), or have done an earlier buildworld where they explicitly disabled clang, so the intrinsics headers never get installed. -Dimitry --Apple-Mail=_7FEA86C6-2B0B-4EC1-93BB-A67B0BF61028 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXrZvRgAKCRCwXqMKLiCW oynyAKD+yn+IJFUyWacomKuEm9qnN9u4XgCgyTfZ0c/kf7X+WtU0CzQzZQ6KjHU= =TlFq -----END PGP SIGNATURE----- --Apple-Mail=_7FEA86C6-2B0B-4EC1-93BB-A67B0BF61028-- From owner-freebsd-current@freebsd.org Sat May 9 09:35: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 DFF2D2E211E for ; Sat, 9 May 2020 09:35:48 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49K2BD4Ymlz4Vs2 for ; Sat, 9 May 2020 09:35:48 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9A9182E211D; Sat, 9 May 2020 09:35: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 9A4E32E211C for ; Sat, 9 May 2020 09:35:48 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic309-20.consmr.mail.ne1.yahoo.com (sonic309-20.consmr.mail.ne1.yahoo.com [66.163.184.146]) (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 49K2BC2rslz4Vs0 for ; Sat, 9 May 2020 09:35:47 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-YMail-OSG: j1ZXf.YVM1lkE5KYYBfgmOiKkPfSIg45xqT6vf2RxMjr3Uu6GqJK1CFxFWBam2z wn_S0EfFMH6aIibRBN6RH0WDtBbPQSTqs2.F1E1.CEurZr1VRnFi62fTI_zjBAZRCPv88X8_8g5r IY23XfDKVMmxzPrZuTa5tWkjW74EoRhr25VHaUwSNgjBDoxM6CUb5Ep5cUjmiNZ8TGZOmbJK4.yu JsiDtF4DHakyBTX8LyoNogVbnHreCDqk2cz27x0.1BqnDWQArI0WjBlU05tsOs9Qstoofvnes.Pq MFiBqeZo._HZJb1Af1oVfs23EJTlJs6.qAc_.wKwnXfHipyuEbDyAYrvuPbxPt93rZABGUHbIWNI x9wqSLRb6GhI6L2Jc7uG5nsdsY8aPnqUX92qJENh5Ftkjr_Qw7V98ZVWBuDWwOnA8J8egajSXhN4 80hSWafrR7yBUTAvEV_SrxsoOsC8OfCpqNGJn2_i_WbEDOPPHrrpvJUlLhL8ZG5Dggt1b64c1uUr kt0NwDMw..LMGaIsJ8Bn8rhrfE.t1h6RFON1KH7jlY52BTBojGEqnCjfshPxpTHVT1B5Lxo2mZnt fr5hZWIFBqes1RKpyEBV5A4hzkIyPXcjq4hW8Wq3ujxtUHIkxNPGzY1wir469Q5Plu8OuZPTYKcm R3GPrdcvxfJbkSnNk0BRICvP424_qE0ztmOFLcWJ5Pw3TaDzB_6071lHZPil5Li6ZfdEi6or3KRM 2pH9s2JWKgJxShi_Jn1oaW2Ddwct_kYEyUiM1UEau9VIm9sZz2giDbSaoeMbR5FT9TYrjf5k7iWU dDeXIYITGExDU5.O5jxZ_q3NX1miTwDREN9fVZT6aSDgHGQk1TGyptdOA6mH1OltaAcwqAcFyG8P 4wAIFGzBKv2NKI7hz90MTgvTaJCPrOgl9hHqxSvqVcA4dC8eMqkA3OKEzcof8DdzF4nSKfCb0pLR Lqh5S4YJcpbLZRzcEPdqxOBp8MDl4p9o586Qzp0r_QekoAua_BGM7o9nv.DcfxMqUm_D79EG.k53 kSClR6p1pa1HF3_aM5Te87V72eH9kF_Dx2hK6Cy19mqpktsekaaJA4sw.lRkSOsRyzMUWCZf_dZk 9yB4UtYv1J58gDM_EfgOKLz818E.qRLbv.ESlbcz4MqC5EwNYzZ0wtAJILgmtihleTdNjgzesLpF JNl8x_pljuurIOhpnpsTDVfKmxk19BTLDD41mU4r8AjGJDr5pOq_mM9X7YU4bi9xHQasz5j3IALZ B9sRLbGaqov67KMy9N.n9IzufLzUME3QDNYGTzzCs6xjM4ORWlHoOFwZLMsXAtMnacRBfre0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sat, 9 May 2020 09:35:45 +0000 Date: Sat, 9 May 2020 09:35:44 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <324127642.580017.1589016944774@mail.yahoo.com> Subject: Xorg question MIME-Version: 1.0 References: <324127642.580017.1589016944774.ref@mail.yahoo.com> X-Mailer: WebService/1.1.15902 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:74.0) Gecko/20100101 Firefox/74.0 X-Rspamd-Queue-Id: 49K2BC2rslz4Vs0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.837,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.84)[-0.842,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[146.184.163.66.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (3.72), ipnet: 66.163.184.0/21(1.15), asn: 36646(0.92), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.184.163.66.rep.mailspike.net : 127.0.0.17]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.32 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 09:35:48 -0000 I run the latest current and I have the following packages installed>xf86-i= nput-keyboard-1.9.0_4=20 xf86-input-libinput-0.28.2_1=C2=A0=20 xf86-input-mouse-1.9.3_3=C2=A0Should I keep all of them or may I keep xf86-= input-libinputThank youFilippo From owner-freebsd-current@freebsd.org Sat May 9 11:51: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 64E452E635E for ; Sat, 9 May 2020 11:51:33 +0000 (UTC) (envelope-from roberthuff@rcn.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 49K5Bs0sDSz4fnx for ; Sat, 9 May 2020 11:51:33 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1D6B52E635D; Sat, 9 May 2020 11:51: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 1D33C2E635C for ; Sat, 9 May 2020 11:51:33 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 49K5Br1VjWz4fnn for ; Sat, 9 May 2020 11:51:31 +0000 (UTC) (envelope-from roberthuff@rcn.com) DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1589025090; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=7zA4ioYlYdIdPuLnd9OFxvS/EAY=; b=g97V3ryMGyaHdy99gnTrnsIou/gJ4ExfC0/a54QOP+4dHSRCx0WVGrW1IsEnO5jK uikaJcwLmT5IdPcNxUsXxxLznM+rcu1hIEOjRgaIQlPi4TOln79Wk3DG65wyUV4q QIYZ5bQQ3xsJMtyr5Uyx9UuwEqfeO6hIzQWbDHrK+WAFLUUv/lGtILLAPUs2kZJX tC2TaS79FMNWVpxrQ08cuQ9mj5UbzkxEQOyYmQDgWLS7+PCRfEpN8mfxq8opuZs5 7aY4DuNo1VcJxZmGzs2uKmKjQY0fMnh7kNVNcpAzIdomw17MxC4xCAI81ck0ljQz qyVjUW7XIqP3+GyKCmJDHQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=F/kpiZpN c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=sTwFKg_x9MkA:10 a=48faUk6PgeAA:10 a=efXzQgPE_lsbtnV2nLsA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [209.6.230.48] ([209.6.230.48:63280] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id C2/4F-51190-24996BE5; Sat, 09 May 2020 07:51:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24246.39233.870089.343027@jerusalem.litteratus.org> Date: Sat, 9 May 2020 07:51:29 -0400 From: Robert Huff To: Dimitry Andric Cc: Robert Huff , current@freebsd.org Subject: Re: "make buildworld" fails for r360785? In-Reply-To: References: <24244.52698.726479.288103@jerusalem.litteratus.org> <849835c13cac7bb6ce9f6e13eaa3b589@udns.ultimatedns.net> <24246.7948.924564.999680@jerusalem.litteratus.org> X-Mailer: VM 8.2.0b under 26.3 (amd64-portbld-freebsd13.0) X-Rspamd-Queue-Id: 49K5Br1VjWz4fnn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=g97V3ryM; dmarc=pass (policy=none) header.from=rcn.com; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 69.168.97.78 as permitted sender) smtp.mailfrom=roberthuff@rcn.com X-Spamd-Result: default: False [-4.65 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RWL_MAILSPIKE_POSSIBLE(0.00)[78.97.168.69.rep.mailspike.net : 127.0.0.17]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.55)[ip: (-9.06), ipnet: 69.168.97.0/24(0.63), asn: 36271(0.71), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; DWL_DNSWL_LOW(-1.00)[rcn.com.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; RCVD_IN_DNSWL_LOW(-0.10)[78.97.168.69.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 11:51:33 -0000 Dimitry Andric writes: > >>>> /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: > >>>> fatal error: 'emmintrin.h' file not found > >>>> #include > >>>> ^~~~~~~~~~~~~ > ... > > In file included from /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228: > > In file included from /usr/include/emmintrin.h:13: > > /usr/include/xmmintrin.h:27:10: fatal error: 'mm_malloc.h' file not found > > #include > > ^~~~~~~~~~~~~ > > 1 error generated. > > *** Error code 1 > > During which stage of buildworld is this? If it is during the > cross-tools stage, your host environment is busted somehow. That is the latest stage listed by the complete build log. (Which I can make available if it's useful.) The only complaint I see is two lines at the top of the log: make[1]: "/usr/src/Makefile.inc1" line 325: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 330: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. Makefile.inc1 was downloaded with the fresh source tree, and I have already posted make.conf and src.conf. I am not sure what else could be broken, nor how to diagnose it. > This appears to happen to some people on this list, for unknown reasons. > My guess is they either run "make delete-old" before running buildworld > (which is the wrong order!), I did recently run "delete-old" ... but only as directed by the official documentation. But ... let's say that somehow happened. How do I recover? Is there a bootstrap process? > or have done an earlier buildworld where > they explicitly disabled clang, so the intrinsics headers never get > installed. Other than a custom kernel config file, I don't touch the system build process. Respectfully, Robert Huff From owner-freebsd-current@freebsd.org Sat May 9 12:18:57 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 A14F22E7C40 for ; Sat, 9 May 2020 12:18:57 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49K5pS2SFYz3DBq for ; Sat, 9 May 2020 12:18:56 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id h9so5053554wrt.0 for ; Sat, 09 May 2020 05:18: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:sender:date:from:to:subject:message-id :mime-version:content-disposition; bh=TYYSWtnA1g9NXpgjCwO2s29B1cHtP82Q8VBpvcXDi3s=; b=dAt/GQ9pa1/3nTSGSPdPiBPIIWMVMNhsIBL6MIKa2X6e5gtGZOpRRkw4mOCW449JPc GQI1MVe60shuDnKfNROYo9yXt+S6UWcBiXKroyMU4tDhi562NBLU+QfHI+TB6D0iNYfG x3ttpod+CgznZuhewRH5KhMDw1o/7+hwU5EgWlRBlG7r6iXDhGpeGW+IJ8K0PzUiq04v mvhoZZReHgFddeU6zkEKjIOVlXArBmZUSqOMgYOGzqjoCR4T0banvgZqS3NERe8VrTEC KPbFVb4pAuy7F0Cl5REPqJ0qunW/FpG5pnccVKowp/kc1/w5krXjzg1aw5IX3HHpQMTJ ixlA== X-Gm-Message-State: AGi0PuYXKy2+eYxeYCEm8GuOQRyKABLQdWnkDu6D7XBids5PEsxwbcOV uE7N0z9arTm+FE+yiK7PEx62p0bS X-Google-Smtp-Source: APiQypKo1ZZSNc0l1Muhi7vRW9Xrons7GAzqDAJCT13ntKp4TgJzIRFEmsx89JcWZXQU2cwqtTXKLQ== X-Received: by 2002:adf:fac4:: with SMTP id a4mr7851461wrs.134.1589026733905; Sat, 09 May 2020 05:18:53 -0700 (PDT) Received: from lion.0xfce3.net (p4FD3AF72.dip0.t-ipconnect.de. [79.211.175.114]) by smtp.gmail.com with ESMTPSA id q74sm10560052wme.14.2020.05.09.05.18.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2020 05:18:53 -0700 (PDT) Sender: Gordon Bergling Date: Sat, 9 May 2020 14:18:51 +0200 From: Gordon Bergling To: freebsd-current@freebsd.org Subject: Error loading tcp_bbr kernel module Message-ID: <20200509121851.GA59530@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 2:14PM up 21:43, 3 users, load averages: 0.46, 0.33, 0.31 X-Rspamd-Queue-Id: 49K5pS2SFYz3DBq X-Spamd-Bar: / X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.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:+]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[114.175.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(0.00)[ip: (-8.96), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-0.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[f.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 12:18:57 -0000 Greetings, I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error when I try to load for example tcp_bbr.ko. kldload: an error occurred while loading module tcp_rack.ko. Please check dmesg(8) for more details. dmesg shows: KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type Any hints on solving the problem? The kernel config is GENERIC. Best regards, Gordon From owner-freebsd-current@freebsd.org Sat May 9 12:26: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 157F32E8094 for ; Sat, 9 May 2020 12:26:43 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49K5zP26lWz3DmV for ; Sat, 9 May 2020 12:26:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id 049CQXgF082093; Sat, 9 May 2020 12:26:33 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id 049CQXdY082092; Sat, 9 May 2020 05:26:33 -0700 (PDT) (envelope-from david) Date: Sat, 9 May 2020 05:26:33 -0700 From: David Wolfskill To: Gordon Bergling Cc: freebsd-current@freebsd.org Subject: Re: Error loading tcp_bbr kernel module Message-ID: <20200509122633.GH1330@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Gordon Bergling , freebsd-current@freebsd.org References: <20200509121851.GA59530@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l6tbG+CHF5pXX68u" Content-Disposition: inline In-Reply-To: <20200509121851.GA59530@lion.0xfce3.net> X-Rspamd-Queue-Id: 49K5zP26lWz3DmV X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-7.13 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[googlemail.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]; IP_SCORE(-2.73)[ip: (-9.71), ipnet: 107.192.0.0/12(-4.86), asn: 7018(0.98), country: US(-0.05)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 12:26:43 -0000 --l6tbG+CHF5pXX68u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 09, 2020 at 02:18:51PM +0200, Gordon Bergling wrote: > Greetings, >=20 > I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the following = error > when I try to load for example tcp_bbr.ko. >=20 > kldload: an error occurred while loading module tcp_rack.ko. Please check= dmesg(8) for more details. >=20 > dmesg shows: >=20 > KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >=20 > Any hints on solving the problem? >=20 > The kernel config is GENERIC. >=20 > Best regards, >=20 > Gordon > .... Looks as if option TCPHPTS isn't in GENERIC, and it's a requisite for BBR. I'd probably create a custom kernel config that amounted to: include GENERIC options TCPHPTS Peace, david --=20 David H. Wolfskill david@catwhisker.org Donald Trump had 3 years to replenish the US stockpile of PPE -- and failed. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --l6tbG+CHF5pXX68u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl62oXlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcnUSAf9FWSctzXfbjKnN5XimEyBA9BnQEVN/YjRLNfi0Q/ugqqiK/x4wHOfBurt Qnbz6WXjijc/+aOn2UL4U97jNAKsm6WBgVPmTcILjzMraC+eCde9OHin7+5Tuj+s fqYrfyw6O36HgDRUQyo5OoedNVBxBq2E6pdRduvlgyiar2XHqzIY/r+vD3+tXvaC Zq/uPSI0WCqH1ZyhJIcFXfPfZdp1jXcHSBlQrK6Zs4XHFBel1O5G8RACGsbbxKXX vxij8BvmK1dc1Dzv+jQF2EttDDWEmrcGZFAyyNnr2Ygh0ZCRz0Jlvcv7FG6e3hJe u7N6gZ1BXH8y98ZBka6Frh7DuE6SRw== =Lj2G -----END PGP SIGNATURE----- --l6tbG+CHF5pXX68u-- From owner-freebsd-current@freebsd.org Sat May 9 12:37: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 241622E853D for ; Sat, 9 May 2020 12:37:11 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49K6CV75jrz3FJl for ; Sat, 9 May 2020 12:37:10 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 3D58A722CF6AC; Sat, 9 May 2020 14:37:08 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Error loading tcp_bbr kernel module From: Michael Tuexen In-Reply-To: <20200509121851.GA59530@lion.0xfce3.net> Date: Sat, 9 May 2020 14:37:07 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> References: <20200509121851.GA59530@lion.0xfce3.net> To: Gordon Bergling X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: 49K6CV75jrz3FJl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.98)[-0.982,0]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; NEURAL_HAM_LONG(-0.97)[-0.973,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 12:37:11 -0000 > On 9. May 2020, at 14:18, Gordon Bergling = wrote: >=20 > Greetings, >=20 > I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the = following error > when I try to load for example tcp_bbr.ko. > z > kldload: an error occurred while loading module tcp_rack.ko. Please = check dmesg(8) for more details. This indicates that you want to load the RACK stack. Please note that you need for BBR and RACK: options TCPHPTS in the kernel config and in addition to that for RACK options RATELIMIT Best regards Michael >=20 > dmesg shows: >=20 > KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch > linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >=20 > Any hints on solving the problem? >=20 > The kernel config is GENERIC. >=20 > Best regards, >=20 > Gordon > _______________________________________________ > 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 May 9 14:25: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 AFF962EB351 for ; Sat, 9 May 2020 14:25:24 +0000 (UTC) (envelope-from gbergling@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49K8cN4B3Tz3Prx; Sat, 9 May 2020 14:25:24 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id z72so4132889wmc.2; Sat, 09 May 2020 07:25:24 -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:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=CgFPFM9Vhxpfv6MPw/M3xvJBswOJEtl87ThDcCw5V40=; b=lqdYBCo9RuYhnDBqMis153CJyt8OAsmHij/qGKPiVYyZFGgtwEbeWCvfN1CUO1M5BF XuSnyjfcStmcw+NtBgmQcUSKqgZQeWkxPzNsmp2ZqzgxXY24OspS1agZoc1R3UUVAdzI 8+XfzEkU5IcKZdlrzrJS9wrF80SAjlC2k1wwmNpKB8s4I7XuzK3HL4ZyZTz0hRU2zROh CcxlFokKAGrIw4WY769gz+1+1ZSKBLFDlxsqOISMSf6w3u3TMwcl6UV7kJiCidkbdt1Z bmQicSdjyYLBVtfzwXRWjYF78BFetsWZnoX50ywQGwJp9M0GS6D9Fjn2/s0pfDOrdYoN e0+w== X-Gm-Message-State: AGi0Pubk9skI+a7kbn/CTyVBybqUA7gxeGyrMY0D6hlNT9NfogtzGfcT SUNSlUpQt6aEqRBPaJe+lsnfVWsN X-Google-Smtp-Source: APiQypKeFlq9c6RsltrfwQ5JUusFht38N+2LpLB/tN6wNA4/FBgdJdE25+hP/k5IDWFNytKITWZ97A== X-Received: by 2002:a7b:c245:: with SMTP id b5mr3699774wmj.162.1589034321379; Sat, 09 May 2020 07:25:21 -0700 (PDT) Received: from [10.0.1.111] (p4FD3AF72.dip0.t-ipconnect.de. [79.211.175.114]) by smtp.gmail.com with ESMTPSA id x6sm8305383wrv.57.2020.05.09.07.25.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2020 07:25:20 -0700 (PDT) Sender: Gordon Bergling Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Error loading tcp_bbr kernel module From: Gordon Bergling In-Reply-To: <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> Date: Sat, 9 May 2020 16:25:19 +0200 Cc: freebsd-current@freebsd.org, david@catwhisker.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200509121851.GA59530@lion.0xfce3.net> <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49K8cN4B3Tz3Prx X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 14:25:24 -0000 Hi Michael, thanks for your reply. I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just = posted the wrong error message. Both TCP stacks weren=E2=80=99t loadable = as a kernel module with just the former mentioned build option. I currently have build running with both kernel options you mentioned. If the build is successful and I can change the default TCP stack to = RACK and BBR I let you know. Further I didn=E2=80=99t find any documentation within tcp(4) regarding = RACK and BBR. Since I am about to enhance the manpages, I=E2=80=99ll = extent tcp(4) about information about RACK and BBR, but this is a = different topic. Best regards, Gordon > Am 09.05.2020 um 14:37 schrieb Michael Tuexen : >=20 >> On 9. May 2020, at 14:18, Gordon Bergling = wrote: >>=20 >> Greetings, >>=20 >> I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the = following error >> when I try to load for example tcp_bbr.ko. >> z >> kldload: an error occurred while loading module tcp_rack.ko. Please = check dmesg(8) for more details. > This indicates that you want to load the RACK stack. >=20 > Please note that you need for BBR and RACK: > options TCPHPTS > in the kernel config and in addition to that for RACK > options RATELIMIT >=20 > Best regards > Michael >>=20 >> dmesg shows: >>=20 >> KLD tcp_bbr.ko: depends on tcphpts - not available or version = mismatch >> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >>=20 >> Any hints on solving the problem? >>=20 >> The kernel config is GENERIC. >>=20 >> Best regards, >>=20 >> Gordon >> _______________________________________________ >> 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" >=20 > _______________________________________________ > 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 May 9 15:41: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 7FB5B2ED33E for ; Sat, 9 May 2020 15:41:11 +0000 (UTC) (envelope-from gbergling@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KBHp3D46z3yrY; Sat, 9 May 2020 15:41:10 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id y24so13920381wma.4; Sat, 09 May 2020 08:41: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:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=56rPrra0+3pQ85TajptxIlcT1fLR7Le4lzPU/gYAvdc=; b=qPFplpDSer2El6ZVwOhWlAdzemAwEd4l/G8S7JvfQhdFSBVegPZtkvBX1SrBs1g+// kIwZVM18iyTur2tpwEv3QaqCmz5NbT7jcfEC0WvVWYGDBDypSSH5ACF2BGr28xrF8D5e dbRDT1u0eLem5/ofIvRRHPxIyC4tvl9l26kc2USaHNHgHkztXCzoo8NQUs2FHt/I62rq fVYFjABKQRs/2wzOE8+66huB5hXfwJSJCnxYCU3aW0e6qtNRqzlro19Y81Q78dAIr5uq N8M84EvN68SeKEKTjCCwdu0vO5/UQKkhhBWM3/qxv/YLG6AH00RTjpv7wSW+xzMWB0lF 213w== X-Gm-Message-State: AGi0PubVaQnDBqV2sB+3eAODaVWvyvlH98qLYxDHcMTopkjIsZvljuWs 5trIHBLmLka9Bqspvk8N48BRlRCh X-Google-Smtp-Source: APiQypILj9J7t2v8aeLPWBG7DkigTa72mkuC2no7JoOwertVRgBWJQycUhAY96zQjcV1va/NBG62zw== X-Received: by 2002:a7b:c104:: with SMTP id w4mr21505121wmi.8.1589038868788; Sat, 09 May 2020 08:41:08 -0700 (PDT) Received: from [10.0.1.111] (p4FD3AF72.dip0.t-ipconnect.de. [79.211.175.114]) by smtp.gmail.com with ESMTPSA id a187sm18511763wmh.40.2020.05.09.08.41.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2020 08:41:08 -0700 (PDT) Sender: Gordon Bergling Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Error loading tcp_bbr kernel module From: Gordon Bergling In-Reply-To: Date: Sat, 9 May 2020 17:41:07 +0200 Cc: freebsd-current@freebsd.org, david@catwhisker.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E2260AE-9209-45D5-B42D-F7DC801E7E5B@googlemail.com> References: <20200509121851.GA59530@lion.0xfce3.net> <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49KBHp3D46z3yrY X-Spamd-Bar: / X-Spamd-Result: default: False [-0.16 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; FORGED_SENDER(0.30)[gbergling@googlemail.com,gbergling@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[114.175.211.79.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; IP_SCORE(0.00)[ip: (2.60), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-0.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[gbergling@googlemail.com,gbergling@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_POLICY_QUARANTINE(1.50)[googlemail.com : SPF not aligned (relaxed), DKIM not aligned (relaxed),quarantine]; NEURAL_HAM_LONG(-0.97)[-0.967,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 15:41:11 -0000 Hi Michael, with a kernel config which includes include GENERIC options RATELIMIT options TCPHPTS applied, I could successfully use net.inet.tcp.functions_default=3Dbbr to switch the TCP stack. Thanks for the fast help, Gordon > Am 09.05.2020 um 16:25 schrieb Gordon Bergling = : >=20 > Hi Michael, >=20 > thanks for your reply. >=20 > I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I = just posted the wrong error message. Both TCP stacks weren=E2=80=99t = loadable as a kernel module with just the former mentioned build option. >=20 > I currently have build running with both kernel options you = mentioned. >=20 > If the build is successful and I can change the default TCP stack to = RACK and BBR I let you know. >=20 > Further I didn=E2=80=99t find any documentation within tcp(4) = regarding RACK and BBR. Since I am about to enhance the manpages, I=E2=80=99= ll extent tcp(4) about information about RACK and BBR, but this is a = different topic. >=20 > Best regards, >=20 > Gordon >=20 >> Am 09.05.2020 um 14:37 schrieb Michael Tuexen : >>=20 >>> On 9. May 2020, at 14:18, Gordon Bergling = wrote: >>>=20 >>> Greetings, >>>=20 >>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the = following error >>> when I try to load for example tcp_bbr.ko. >>> z >>> kldload: an error occurred while loading module tcp_rack.ko. Please = check dmesg(8) for more details. >> This indicates that you want to load the RACK stack. >>=20 >> Please note that you need for BBR and RACK: >> options TCPHPTS >> in the kernel config and in addition to that for RACK >> options RATELIMIT >>=20 >> Best regards >> Michael >>>=20 >>> dmesg shows: >>>=20 >>> KLD tcp_bbr.ko: depends on tcphpts - not available or version = mismatch >>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >>>=20 >>> Any hints on solving the problem? >>>=20 >>> The kernel config is GENERIC. >>>=20 >>> Best regards, >>>=20 >>> Gordon >>> _______________________________________________ >>> 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" >>=20 >> _______________________________________________ >> 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" >=20 From owner-freebsd-current@freebsd.org Sat May 9 15:43: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 D6D4A2ED709 for ; Sat, 9 May 2020 15:43:23 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KBLM3R7sz40PJ for ; Sat, 9 May 2020 15:43:23 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 59316722CF6BD; Sat, 9 May 2020 17:42:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Error loading tcp_bbr kernel module From: Michael Tuexen In-Reply-To: Date: Sat, 9 May 2020 17:42:55 +0200 Cc: FreeBSD CURRENT , david@catwhisker.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200509121851.GA59530@lion.0xfce3.net> <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> To: Gordon Bergling X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: 49KBLM3R7sz40PJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 15:43:23 -0000 > On 9. May 2020, at 16:25, Gordon Bergling = wrote: >=20 > Hi Michael, >=20 > thanks for your reply. >=20 > I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I = just posted the wrong error message. Both TCP stacks weren=E2=80=99t = loadable as a kernel module with just the former mentioned build option. >=20 > I currently have build running with both kernel options you = mentioned. >=20 > If the build is successful and I can change the default TCP stack to = RACK and BBR I let you know. That would be great. I have them running on my machines, but I might = have missed something. >=20 > Further I didn=E2=80=99t find any documentation within tcp(4) = regarding RACK and BBR. Since I am about to enhance the manpages, I=E2=80=99= ll extent tcp(4) about information about RACK and BBR, but this is a = different topic. >=20 Yes it is. And I would suggest to use separate man pages, a single one = for each stack. The the generic man page might refer to them... Best regards Michael > Best regards, >=20 > Gordon >=20 >> Am 09.05.2020 um 14:37 schrieb Michael Tuexen : >>=20 >>> On 9. May 2020, at 14:18, Gordon Bergling = wrote: >>>=20 >>> Greetings, >>>=20 >>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the = following error >>> when I try to load for example tcp_bbr.ko. >>> z >>> kldload: an error occurred while loading module tcp_rack.ko. Please = check dmesg(8) for more details. >> This indicates that you want to load the RACK stack. >>=20 >> Please note that you need for BBR and RACK: >> options TCPHPTS >> in the kernel config and in addition to that for RACK >> options RATELIMIT >>=20 >> Best regards >> Michael >>>=20 >>> dmesg shows: >>>=20 >>> KLD tcp_bbr.ko: depends on tcphpts - not available or version = mismatch >>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >>>=20 >>> Any hints on solving the problem? >>>=20 >>> The kernel config is GENERIC. >>>=20 >>> Best regards, >>>=20 >>> Gordon >>> _______________________________________________ >>> 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" >>=20 >> _______________________________________________ >> 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" >=20 From owner-freebsd-current@freebsd.org Sat May 9 15:52: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 609442EDD99 for ; Sat, 9 May 2020 15:52:30 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KBXs08KKz41PZ for ; Sat, 9 May 2020 15:52:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f193.google.com with SMTP id e25so4848899ljg.5 for ; Sat, 09 May 2020 08:52:28 -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:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=beDVbPuE0NUq3mS0HptlSI63XIVQnQLE6e1zFEds0rI=; b=G9VagaJVPjpciWCScDiyJ7xk9xc8/ulgEeKQ2TS3WFFVV4RVPPU6wXt319sjg2l8ee +C4kMdEe42ZDXxfjMNfjln8AxGETWIGNw+c4829BoFjihVIM1ciK0SrLdOFowFVVkaBa N0VdtWtcx+0ZSWm8XGal1QdfPHAsu6LIQ9XlCZuOxYQ+QWR4gAq52i7ZwkdByHmwVmex BeUk5pY+0y3NQPRWaUWAzASYLbeRWe3X4uT4TF55oOLgbaZelidYNdgV3dHhr1QPrU9+ BvVwfR4vSKnXyiZZXdFDnTPES2VmVBq8GFsrpWGhDfzJNOB2C2b/Y/rt83Uo7bC7GiGE 2d3A== X-Gm-Message-State: AOAM53142CAevmle3aUiyfgdeJT97O93QVoRGxFXROC7aslnFJIN2fYw fGWCGz27gQx7PvFwLroZhwoLCQHjIcM= X-Google-Smtp-Source: ABdhPJz653gS0u9bk1ZnEB9onUyMvrWUoxAbKfiv35lOikmob++oEEydCPpKkGdkQ/ykmoTS2p7W2g== X-Received: by 2002:a2e:9018:: with SMTP id h24mr5004639ljg.217.1589039546929; Sat, 09 May 2020 08:52:26 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id g20sm4414683lfj.1.2020.05.09.08.52.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 08:52:26 -0700 (PDT) Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? To: Konstantin Belousov Cc: FreeBSD Current References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> Date: Sat, 9 May 2020 18:52:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200508161500.GC44519@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49KBXs08KKz41PZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.193 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.991,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[193.208.85.209.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-0.04)[ip: (0.66), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 15:52:30 -0000 On 08/05/2020 19:15, Konstantin Belousov wrote: > On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: >> >> I have a reproducible panic with a custom kernel without option NUMA while using >> amdgpu driver from linuxkpi-based drm: >> >> panic: address 41ec00000 beyond the last segment >> >> I did some quick debugging and the panic happens when Xorg server tries to >> access a frame buffer (or something like that). There is a page fault that gets >> satisfied by ttm with a fictitious page. >> >> The stack trace is: >> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 >> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 >> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, >> m=, prot=, flags=, psind=> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 >> #13 0xffffffff80b288be in vm_fault_populate (fs=) at >> /usr/devel/git/motil/sys/vm/vm_fault.c:519 >> #14 vm_fault_allocate (fs=) at >> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 >> #15 vm_fault (map=, vaddr=, fault_type=> out>, fault_flags=, m_hold=) at >> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 >> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, >> vaddr=, fault_type=, fault_flags=0, >> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at >> /usr/devel/git/motil/sys/vm/vm_fault.c:589 >> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, >> usermode=, signo=, ucode=0xffffffff80853250 >> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 >> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at >> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 >> >> >> The line number in pmap_enter() is incorrect, I guess because of optimizations. >> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> >> PHYS_TO_PV_LIST_LOCK -> pa_index(). >> >> The panic in correct in that the page is fictitious and its physical address is >> beyond the end of real physical memory. >> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one >> is not. > > I think you can remove this assert. pa_index() is always taken by > % NVP_LIST_LOCKS, because fictitious mappings are not promoted. > > Try that and commit if it works for you. I tried this change: diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 4deed86a76d1a..b834b7f0388b7 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) #define NPV_LIST_LOCKS MAXCPU #define PHYS_TO_PV_LIST_LOCK(pa) \ - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) #endif #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ It fixed the original problem, but I got a new panic. "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). I guess that !NUMA variant does not get much testing, so I'll probably just stick with the default. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat May 9 16:07: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 45BDC2EE39D for ; Sat, 9 May 2020 16:07:19 +0000 (UTC) (envelope-from gbergling@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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KBsz14bfz42Kx; Sat, 9 May 2020 16:07:18 +0000 (UTC) (envelope-from gbergling@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id h4so13282403wmb.4; Sat, 09 May 2020 09:07: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:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=4aka0P5ITLNIFJHDPat5sEuzQaDc644DRJjTR7WT//k=; b=jOhKLbdA6fO7kYe/nIxegwKy+izHV3LoPZxtet9NH9TnCdh2oLR1MzL5JXHY3+zIFF 6cnBiuWkfRdIGb+1/1NONyf7/yjHmjEV5VnGoBIjVkiGsy472qFJoy5Cl1NFLni+Mneb +a51EeKptnvBY8sI8DGq//GMsAGZ91nC07WsQzCcUkZu/jvDftupo1UYoKCVNwxUyb4J E+P4OYLLtoiU1n83uWw/gTj0bBRmHXIgpCPFMe/EaUonfi6SON3mcuymE3ACxHg9RZib NA8hsUNPK0iEtAqU5YcdUlBzBagyHPlCax6y7S2QB8XMNrFpgGBPMdX0iSMdyfQKmH+h L6fw== X-Gm-Message-State: AGi0PubSGKPooHCeUkx9A3tRnXuhgK0F53cpBfvdt2QV/dQggWgqJOWE z8ElyRuCsoQcjoUZk8txiqcZJcU+ X-Google-Smtp-Source: APiQypJ5f6uVvLDB4AtdcV1SKLxzckfh3lwyu5m3CjlngQi4J9sq4J4vGLTA6Jqt/9o1lmqoaC9EBg== X-Received: by 2002:a05:600c:1:: with SMTP id g1mr21556944wmc.142.1589040437466; Sat, 09 May 2020 09:07:17 -0700 (PDT) Received: from lion.0xfce3.net (p4FD3AF72.dip0.t-ipconnect.de. [79.211.175.114]) by smtp.gmail.com with ESMTPSA id 18sm6100340wmj.19.2020.05.09.09.07.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2020 09:07:16 -0700 (PDT) Sender: Gordon Bergling Date: Sat, 9 May 2020 18:07:14 +0200 From: Gordon Bergling To: Michael Tuexen Cc: FreeBSD CURRENT , david@catwhisker.org Subject: Re: Error loading tcp_bbr kernel module Message-ID: <20200509160714.GA38490@lion.0xfce3.net> References: <20200509121851.GA59530@lion.0xfce3.net> <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 5:49PM up 1 day, 1:18, 3 users, load averages: 0.27, 0.19, 0.45 X-Rspamd-Queue-Id: 49KBsz14bfz42Kx X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 16:07:19 -0000 Hi Michael, On Sat, May 09, 2020 at 05:42:55PM +0200, Michael Tuexen wrote: > > On 9. May 2020, at 16:25, Gordon Bergling wrote: > > I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just posted the wrong error message. Both TCP stacks weren’t loadable as a kernel module with just the former mentioned build option. > > > > I currently have build running with both kernel options you mentioned. > > > > If the build is successful and I can change the default TCP stack to RACK and BBR I let you know. > That would be great. I have them running on my machines, but I might have missed something. > > > > Further I didn’t find any documentation within tcp(4) regarding RACK and BBR. Since I am about to enhance the manpages, I’ll extent tcp(4) about information about RACK and BBR, but this is a different topic. > > > Yes it is. And I would suggest to use separate man pages, a single one for each stack. > The the generic man page might refer to them... My first thoughts on this topic were about to extent tcp(4) and create links to tcp_rack(4) and tcp_bbr(4), but separate manpages maybe the way to go. I just have to investigate the respective details. I was once very deep into TCP/IP, while building perimeter firewalls with FreeBSD, but this was 20 years ago. I add you as a reviever for the differential once I have a rough cut for the manpages ready. Best regards, Gordon > >> Am 09.05.2020 um 14:37 schrieb Michael Tuexen : > >>> On 9. May 2020, at 14:18, Gordon Bergling wrote: > >>> > >>> Greetings, > >>> > >>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error > >>> when I try to load for example tcp_bbr.ko. > >>> z > >>> kldload: an error occurred while loading module tcp_rack.ko. Please check dmesg(8) for more details. > >> This indicates that you want to load the RACK stack. > >> > >> Please note that you need for BBR and RACK: > >> options TCPHPTS > >> in the kernel config and in addition to that for RACK > >> options RATELIMIT > >> > >>> dmesg shows: > >>> > >>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch > >>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type > >>> > >>> Any hints on solving the problem? > >>> > >>> The kernel config is GENERIC. > >>> > >>> Best regards, > >>> > >>> Gordon From owner-freebsd-current@freebsd.org Sat May 9 16:13: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 41C972EE7DF for ; Sat, 9 May 2020 16:13:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49KC1G6Zb0z42sx; Sat, 9 May 2020 16:13:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 049GDQ9Y007394 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2020 19:13:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 049GDQ9Y007394 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 049GDPs3007393; Sat, 9 May 2020 19:13:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 9 May 2020 19:13:25 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Message-ID: <20200509161325.GH44519@kib.kiev.ua> References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,PLING_QUERY 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: 49KC1G6Zb0z42sx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 16:13:39 -0000 On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: > On 08/05/2020 19:15, Konstantin Belousov wrote: > > On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: > >> > >> I have a reproducible panic with a custom kernel without option NUMA while using > >> amdgpu driver from linuxkpi-based drm: > >> > >> panic: address 41ec00000 beyond the last segment > >> > >> I did some quick debugging and the panic happens when Xorg server tries to > >> access a frame buffer (or something like that). There is a page fault that gets > >> satisfied by ttm with a fictitious page. > >> > >> The stack trace is: > >> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > >> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > >> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, > >> m=, prot=, flags=, psind= >> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 > >> #13 0xffffffff80b288be in vm_fault_populate (fs=) at > >> /usr/devel/git/motil/sys/vm/vm_fault.c:519 > >> #14 vm_fault_allocate (fs=) at > >> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 > >> #15 vm_fault (map=, vaddr=, fault_type= >> out>, fault_flags=, m_hold=) at > >> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 > >> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, > >> vaddr=, fault_type=, fault_flags=0, > >> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at > >> /usr/devel/git/motil/sys/vm/vm_fault.c:589 > >> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, > >> usermode=, signo=, ucode=0xffffffff80853250 > >> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 > >> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at > >> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 > >> > >> > >> The line number in pmap_enter() is incorrect, I guess because of optimizations. > >> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> > >> PHYS_TO_PV_LIST_LOCK -> pa_index(). > >> > >> The panic in correct in that the page is fictitious and its physical address is > >> beyond the end of real physical memory. > >> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one > >> is not. > > > > I think you can remove this assert. pa_index() is always taken by > > % NVP_LIST_LOCKS, because fictitious mappings are not promoted. > > > > Try that and commit if it works for you. > > I tried this change: > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 4deed86a76d1a..b834b7f0388b7 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) > #define NPV_LIST_LOCKS MAXCPU > > #define PHYS_TO_PV_LIST_LOCK(pa) \ > - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) > + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) > #endif > > #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ > > It fixed the original problem, but I got a new panic. > "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). > I guess that !NUMA variant does not get much testing, so I'll probably just > stick with the default. Why didn't you just removed the KASSERT from pa_index ? From owner-freebsd-current@freebsd.org Sat May 9 16:16:32 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 929962EEA2D for ; Sat, 9 May 2020 16:16:32 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KC4b5NKMz437s for ; Sat, 9 May 2020 16:16:31 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id g4so4906427ljl.2 for ; Sat, 09 May 2020 09:16: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:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UPs7FK5xNtECg+QToJ60XoKKWDmH3JukHNOSlDIcFNA=; b=rXmDFmJmr60I4Valv7BjVJVfe/ha9VwmUbsULeBJlzXi2ACtbrzxeGROToRIVonUPf XbBr5zXpk7pTxb9O4S68mIY9rsYN6Cbh16536gMIUBuYvb/f5cLL8MUXwXs6aiWLZFUT z8a6rypJP65H3eK7cSguSr2GqkxonVqtmuU/MAvlzBDLNjtuTERqStSkF+5Y5wg2fj6z lhQf/2QBRMXSzXYno/0dZpInomZMn05C5ahaSvM90+cbOOcxzyUMc+/0q0GdoDc8E72C 8MquIiOZDiDSpUGPv8pKM6T/jZzKsJDYQEkHQLeEsJsbOZHp20p/Xlk+9DBIvomR5heU zDpQ== X-Gm-Message-State: AOAM532q4UefUof/Q0fX5Jp6XXWviKc5hFhGJ4Uuj2xUEAZrJnii8b9x krRKERxakAEQ7Jo7C9esStmqnUMO5vs= X-Google-Smtp-Source: ABdhPJzTGe/42XKt51meVg8DXmujCD2g2Ux4vMBcY9WSDSBjmYz4zuWbEQY6uT2mEtwRjXWPMiaQjQ== X-Received: by 2002:a2e:9e43:: with SMTP id g3mr5357138ljk.4.1589040989578; Sat, 09 May 2020 09:16:29 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id j29sm4989029lfp.90.2020.05.09.09.16.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 09:16:28 -0700 (PDT) Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? To: Konstantin Belousov Cc: FreeBSD Current References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Sat, 9 May 2020 19:16:27 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200509161325.GH44519@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49KC4b5NKMz437s X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.194 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-0.88 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.976,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[194.208.85.209.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(0.06)[ip: (1.14), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 16:16:32 -0000 On 09/05/2020 19:13, Konstantin Belousov wrote: > On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: >> On 08/05/2020 19:15, Konstantin Belousov wrote: >>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: >>>> >>>> I have a reproducible panic with a custom kernel without option NUMA while using >>>> amdgpu driver from linuxkpi-based drm: >>>> >>>> panic: address 41ec00000 beyond the last segment >>>> >>>> I did some quick debugging and the panic happens when Xorg server tries to >>>> access a frame buffer (or something like that). There is a page fault that gets >>>> satisfied by ttm with a fictitious page. >>>> >>>> The stack trace is: >>>> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 >>>> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 >>>> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, >>>> m=, prot=, flags=, psind=>>> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 >>>> #13 0xffffffff80b288be in vm_fault_populate (fs=) at >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:519 >>>> #14 vm_fault_allocate (fs=) at >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 >>>> #15 vm_fault (map=, vaddr=, fault_type=>>> out>, fault_flags=, m_hold=) at >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 >>>> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, >>>> vaddr=, fault_type=, fault_flags=0, >>>> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:589 >>>> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, >>>> usermode=, signo=, ucode=0xffffffff80853250 >>>> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 >>>> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at >>>> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 >>>> >>>> >>>> The line number in pmap_enter() is incorrect, I guess because of optimizations. >>>> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> >>>> PHYS_TO_PV_LIST_LOCK -> pa_index(). >>>> >>>> The panic in correct in that the page is fictitious and its physical address is >>>> beyond the end of real physical memory. >>>> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one >>>> is not. >>> >>> I think you can remove this assert. pa_index() is always taken by >>> % NVP_LIST_LOCKS, because fictitious mappings are not promoted. >>> >>> Try that and commit if it works for you. >> >> I tried this change: >> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >> index 4deed86a76d1a..b834b7f0388b7 100644 >> --- a/sys/amd64/amd64/pmap.c >> +++ b/sys/amd64/amd64/pmap.c >> @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) >> #define NPV_LIST_LOCKS MAXCPU >> >> #define PHYS_TO_PV_LIST_LOCK(pa) \ >> - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) >> + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) >> #endif >> >> #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ >> >> It fixed the original problem, but I got a new panic. >> "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). >> I guess that !NUMA variant does not get much testing, so I'll probably just >> stick with the default. > Why didn't you just removed the KASSERT from pa_index ? Well, I thought it might be useful in the NUMA case. pa_index() definition is shared between both cases. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat May 9 16:50: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 64EA02F074C for ; Sat, 9 May 2020 16:50:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49KCqc0QYFz457h; Sat, 9 May 2020 16:50:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 049GoABp015816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2020 19:50:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 049GoABp015816 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 049GoAp4015814; Sat, 9 May 2020 19:50:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 9 May 2020 19:50:10 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Message-ID: <20200509165010.GI44519@kib.kiev.ua> References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,PLING_QUERY 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: 49KCqc0QYFz457h X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 16:50:20 -0000 On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: > On 09/05/2020 19:13, Konstantin Belousov wrote: > > On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: > >> On 08/05/2020 19:15, Konstantin Belousov wrote: > >>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: > >>>> > >>>> I have a reproducible panic with a custom kernel without option NUMA while using > >>>> amdgpu driver from linuxkpi-based drm: > >>>> > >>>> panic: address 41ec00000 beyond the last segment > >>>> > >>>> I did some quick debugging and the panic happens when Xorg server tries to > >>>> access a frame buffer (or something like that). There is a page fault that gets > >>>> satisfied by ttm with a fictitious page. > >>>> > >>>> The stack trace is: > >>>> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > >>>> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > >>>> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, > >>>> m=, prot=, flags=, psind= >>>> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 > >>>> #13 0xffffffff80b288be in vm_fault_populate (fs=) at > >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:519 > >>>> #14 vm_fault_allocate (fs=) at > >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 > >>>> #15 vm_fault (map=, vaddr=, fault_type= >>>> out>, fault_flags=, m_hold=) at > >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 > >>>> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, > >>>> vaddr=, fault_type=, fault_flags=0, > >>>> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at > >>>> /usr/devel/git/motil/sys/vm/vm_fault.c:589 > >>>> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, > >>>> usermode=, signo=, ucode=0xffffffff80853250 > >>>> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 > >>>> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at > >>>> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 > >>>> > >>>> > >>>> The line number in pmap_enter() is incorrect, I guess because of optimizations. > >>>> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> > >>>> PHYS_TO_PV_LIST_LOCK -> pa_index(). > >>>> > >>>> The panic in correct in that the page is fictitious and its physical address is > >>>> beyond the end of real physical memory. > >>>> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one > >>>> is not. > >>> > >>> I think you can remove this assert. pa_index() is always taken by > >>> % NVP_LIST_LOCKS, because fictitious mappings are not promoted. > >>> > >>> Try that and commit if it works for you. > >> > >> I tried this change: > >> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > >> index 4deed86a76d1a..b834b7f0388b7 100644 > >> --- a/sys/amd64/amd64/pmap.c > >> +++ b/sys/amd64/amd64/pmap.c > >> @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) > >> #define NPV_LIST_LOCKS MAXCPU > >> > >> #define PHYS_TO_PV_LIST_LOCK(pa) \ > >> - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) > >> + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) > >> #endif > >> > >> #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ > >> > >> It fixed the original problem, but I got a new panic. > >> "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). > >> I guess that !NUMA variant does not get much testing, so I'll probably just > >> stick with the default. > > Why didn't you just removed the KASSERT from pa_index ? > > Well, I thought it might be useful in the NUMA case. > pa_index() definition is shared between both cases. Might be define the macro two times, for NUMA/non-NUMA. non-NUMA case does not need the assert, because users take it mod NPV_LIST_LOCKS. From owner-freebsd-current@freebsd.org Sat May 9 19:03: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 B2CE82F36BF for ; Sat, 9 May 2020 19:03:33 +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 "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KGnJ5SS8z4DGm for ; Sat, 9 May 2020 19:03:32 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A444D722D3922; Sat, 9 May 2020 21:03:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Error loading tcp_bbr kernel module From: Michael Tuexen In-Reply-To: <20200509160714.GA38490@lion.0xfce3.net> Date: Sat, 9 May 2020 21:03:02 +0200 Cc: FreeBSD CURRENT , david@catwhisker.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B396584-1018-46ED-B7F9-35215B4AF17C@freebsd.org> References: <20200509121851.GA59530@lion.0xfce3.net> <24D28CC3-AA45-412F-AF3D-9697A36FCB8D@freebsd.org> <20200509160714.GA38490@lion.0xfce3.net> To: Gordon Bergling X-Mailer: Apple Mail (2.3608.80.23.2.2) 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: 49KGnJ5SS8z4DGm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.93 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.95)[-0.951,0]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; NEURAL_HAM_LONG(-0.97)[-0.975,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 19:03:33 -0000 > On 9. May 2020, at 18:07, Gordon Bergling = wrote: >=20 > Hi Michael, >=20 > On Sat, May 09, 2020 at 05:42:55PM +0200, Michael Tuexen wrote: >>> On 9. May 2020, at 16:25, Gordon Bergling = wrote: >>> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I = just posted the wrong error message. Both TCP stacks weren=E2=80=99t = loadable as a kernel module with just the former mentioned build option. >>>=20 >>> I currently have build running with both kernel options you = mentioned. >>>=20 >>> If the build is successful and I can change the default TCP stack to = RACK and BBR I let you know. >> That would be great. I have them running on my machines, but I might = have missed something. >>>=20 >>> Further I didn=E2=80=99t find any documentation within tcp(4) = regarding RACK and BBR. Since I am about to enhance the manpages, I=E2=80=99= ll extent tcp(4) about information about RACK and BBR, but this is a = different topic. >>>=20 >> Yes it is. And I would suggest to use separate man pages, a single = one for each stack. >> The the generic man page might refer to them... >=20 > My first thoughts on this topic were about to extent tcp(4) and create = links to > tcp_rack(4) and tcp_bbr(4), but separate manpages maybe the way to go. = I just > have to investigate the respective details. I was once very deep into = TCP/IP,=20 > while building perimeter firewalls with FreeBSD, but this was 20 years = ago. >=20 > I add you as a reviever for the differential once I have a rough cut=20= > for the manpages ready. Hi Gordon, please do so. Don't forget to add rrs@, since he wrote both stacks. Best regards Michael >=20 > Best regards, >=20 > Gordon >=20 >>>> Am 09.05.2020 um 14:37 schrieb Michael Tuexen : >>>>> On 9. May 2020, at 14:18, Gordon Bergling = wrote: >>>>>=20 >>>>> Greetings, >>>>>=20 >>>>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=3D1, but I got the = following error >>>>> when I try to load for example tcp_bbr.ko. >>>>> z >>>>> kldload: an error occurred while loading module tcp_rack.ko. = Please check dmesg(8) for more details. >>>> This indicates that you want to load the RACK stack. >>>>=20 >>>> Please note that you need for BBR and RACK: >>>> options TCPHPTS >>>> in the kernel config and in addition to that for RACK >>>> options RATELIMIT >>>>=20 >>>>> dmesg shows: >>>>>=20 >>>>> KLD tcp_bbr.ko: depends on tcphpts - not available or version = mismatch >>>>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type >>>>>=20 >>>>> Any hints on solving the problem? >>>>>=20 >>>>> The kernel config is GENERIC. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Gordon From owner-freebsd-current@freebsd.org Sat May 9 20:33:45 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 7C0702F5068 for ; Sat, 9 May 2020 20:33:45 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KJnN4rBbz4JL7 for ; Sat, 9 May 2020 20:33:44 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f196.google.com with SMTP id f18so5296998lja.13 for ; Sat, 09 May 2020 13:33: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:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IccQXs/1thqS8XvKaAJzbjfCvK1RfHGfh4P96C0wYyE=; b=dztVHnPwnM5jRk9/D/v/z1urtljlSnnAHTALN4BjTtbZR/N1v1sCkWUPM6z1cY7xl0 GUInq0Q3gf6N/ZOsfkBQ86OPBSqq6rq5yYk/iOrww7P6Fhq0e+f8opB9j/rmmoD/yyGd dUiFfsyH2SDF2DfMgwGC2wPxzcLdEsSAaB1UPP8+U/RryJVH7iBpfRcPOVjL4JME7i00 rbuDRyv4N8Jp8xupUlCF4n1w1h4IllUENXeHZL83y9z645Bge/VVr/Hs6CBJueFLfV5V CLCYd1Ga8OxIGUwnIKRx0gWFZ3t86TrIFm/yom09nUciPpkl4+/ew2i61AbICjIbRCGE lk/w== X-Gm-Message-State: AOAM532WYzHGrrMmlfmUMHI4larbuZLQOXFvRtBTcCf9o3RrRw/tg6ye DQUZoQErrZYXHESoOm7Fx2LnGfnoVF0= X-Google-Smtp-Source: ABdhPJwCf5DuOnvslQU4NRMNn/SciaIyBEVnpPI5RnMF5giBkqDEqUiJCen5I7yCnqedJZEcDLNfcg== X-Received: by 2002:a2e:9712:: with SMTP id r18mr5593686lji.225.1589056422564; Sat, 09 May 2020 13:33:42 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id a10sm4660922ljp.16.2020.05.09.13.33.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 13:33:41 -0700 (PDT) Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? To: Konstantin Belousov Cc: FreeBSD Current References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> <20200509165010.GI44519@kib.kiev.ua> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <88ebc8f9-b10d-366d-a12a-fb74417904bc@FreeBSD.org> Date: Sat, 9 May 2020 23:33:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200509165010.GI44519@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49KJnN4rBbz4JL7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.196 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-0.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.955,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[196.208.85.209.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[196.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-0.02)[ip: (0.76), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 20:33:45 -0000 On 09/05/2020 19:50, Konstantin Belousov wrote: > On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: >> On 09/05/2020 19:13, Konstantin Belousov wrote: >>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: >>>> On 08/05/2020 19:15, Konstantin Belousov wrote: >>>>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: >>>>>> >>>>>> I have a reproducible panic with a custom kernel without option NUMA while using >>>>>> amdgpu driver from linuxkpi-based drm: >>>>>> >>>>>> panic: address 41ec00000 beyond the last segment >>>>>> >>>>>> I did some quick debugging and the panic happens when Xorg server tries to >>>>>> access a frame buffer (or something like that). There is a page fault that gets >>>>>> satisfied by ttm with a fictitious page. >>>>>> >>>>>> The stack trace is: >>>>>> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 >>>>>> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 >>>>>> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, >>>>>> m=, prot=, flags=, psind=>>>>> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 >>>>>> #13 0xffffffff80b288be in vm_fault_populate (fs=) at >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:519 >>>>>> #14 vm_fault_allocate (fs=) at >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 >>>>>> #15 vm_fault (map=, vaddr=, fault_type=>>>>> out>, fault_flags=, m_hold=) at >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 >>>>>> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, >>>>>> vaddr=, fault_type=, fault_flags=0, >>>>>> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:589 >>>>>> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, >>>>>> usermode=, signo=, ucode=0xffffffff80853250 >>>>>> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 >>>>>> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at >>>>>> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 >>>>>> >>>>>> >>>>>> The line number in pmap_enter() is incorrect, I guess because of optimizations. >>>>>> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> >>>>>> PHYS_TO_PV_LIST_LOCK -> pa_index(). >>>>>> >>>>>> The panic in correct in that the page is fictitious and its physical address is >>>>>> beyond the end of real physical memory. >>>>>> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one >>>>>> is not. >>>>> >>>>> I think you can remove this assert. pa_index() is always taken by >>>>> % NVP_LIST_LOCKS, because fictitious mappings are not promoted. >>>>> >>>>> Try that and commit if it works for you. >>>> >>>> I tried this change: >>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>>> index 4deed86a76d1a..b834b7f0388b7 100644 >>>> --- a/sys/amd64/amd64/pmap.c >>>> +++ b/sys/amd64/amd64/pmap.c >>>> @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) >>>> #define NPV_LIST_LOCKS MAXCPU >>>> >>>> #define PHYS_TO_PV_LIST_LOCK(pa) \ >>>> - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) >>>> + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) >>>> #endif >>>> >>>> #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ >>>> >>>> It fixed the original problem, but I got a new panic. >>>> "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). >>>> I guess that !NUMA variant does not get much testing, so I'll probably just >>>> stick with the default. >>> Why didn't you just removed the KASSERT from pa_index ? >> >> Well, I thought it might be useful in the NUMA case. >> pa_index() definition is shared between both cases. > Might be define the macro two times, for NUMA/non-NUMA. non-NUMA case > does not need the assert, because users take it mod NPV_LIST_LOCKS. > I still don't see how that could help with "DI already started" panic. -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat May 9 20:47:51 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 4646B2F548B for ; Sat, 9 May 2020 20:47:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49KK5g0CDVz4JyK; Sat, 9 May 2020 20:47:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 049KlhYE071227 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2020 23:47:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 049KlhYE071227 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 049Klhi2071226; Sat, 9 May 2020 23:47:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 9 May 2020 23:47:43 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Message-ID: <20200509204743.GA68906@kib.kiev.ua> References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> <20200509165010.GI44519@kib.kiev.ua> <88ebc8f9-b10d-366d-a12a-fb74417904bc@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88ebc8f9-b10d-366d-a12a-fb74417904bc@FreeBSD.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,PLING_QUERY 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: 49KK5g0CDVz4JyK X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 20:47:51 -0000 On Sat, May 09, 2020 at 11:33:40PM +0300, Andriy Gapon wrote: > On 09/05/2020 19:50, Konstantin Belousov wrote: > > On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: > >> On 09/05/2020 19:13, Konstantin Belousov wrote: > >>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: > >>>> On 08/05/2020 19:15, Konstantin Belousov wrote: > >>>>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote: > >>>>>> > >>>>>> I have a reproducible panic with a custom kernel without option NUMA while using > >>>>>> amdgpu driver from linuxkpi-based drm: > >>>>>> > >>>>>> panic: address 41ec00000 beyond the last segment > >>>>>> > >>>>>> I did some quick debugging and the panic happens when Xorg server tries to > >>>>>> access a frame buffer (or something like that). There is a page fault that gets > >>>>>> satisfied by ttm with a fictitious page. > >>>>>> > >>>>>> The stack trace is: > >>>>>> #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > >>>>>> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > >>>>>> #12 0xffffffff80bbc552 in pmap_enter (pmap=, va=34504441856, > >>>>>> m=, prot=, flags=, psind= >>>>>> out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035 > >>>>>> #13 0xffffffff80b288be in vm_fault_populate (fs=) at > >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:519 > >>>>>> #14 vm_fault_allocate (fs=) at > >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1032 > >>>>>> #15 vm_fault (map=, vaddr=, fault_type= >>>>>> out>, fault_flags=, m_hold=) at > >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:1342 > >>>>>> #16 0xffffffff80b26e7e in vm_fault_trap (map=0xfffffe0017cd39e8, > >>>>>> vaddr=, fault_type=, fault_flags=0, > >>>>>> signo=0xfffffe00a810dbc4, ucode=0xfffffe00a810dbc0) at > >>>>>> /usr/devel/git/motil/sys/vm/vm_fault.c:589 > >>>>>> #17 0xffffffff80bcf89c in trap_pfault (frame=0xfffffe00a810dc00, > >>>>>> usermode=, signo=, ucode=0xffffffff80853250 > >>>>>> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821 > >>>>>> #18 0xffffffff80bceeec in trap (frame=0xfffffe00a810dc00) at > >>>>>> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34 > >>>>>> > >>>>>> > >>>>>> The line number in pmap_enter() is incorrect, I guess because of optimizations. > >>>>>> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS -> > >>>>>> PHYS_TO_PV_LIST_LOCK -> pa_index(). > >>>>>> > >>>>>> The panic in correct in that the page is fictitious and its physical address is > >>>>>> beyond the end of real physical memory. > >>>>>> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one > >>>>>> is not. > >>>>> > >>>>> I think you can remove this assert. pa_index() is always taken by > >>>>> % NVP_LIST_LOCKS, because fictitious mappings are not promoted. > >>>>> > >>>>> Try that and commit if it works for you. > >>>> > >>>> I tried this change: > >>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > >>>> index 4deed86a76d1a..b834b7f0388b7 100644 > >>>> --- a/sys/amd64/amd64/pmap.c > >>>> +++ b/sys/amd64/amd64/pmap.c > >>>> @@ -345,7 +345,7 @@ pmap_pku_mask_bit(pmap_t pmap) > >>>> #define NPV_LIST_LOCKS MAXCPU > >>>> > >>>> #define PHYS_TO_PV_LIST_LOCK(pa) \ > >>>> - (&pv_list_locks[pa_index(pa) % NPV_LIST_LOCKS]) > >>>> + (&pv_list_locks[((pa) >> PDRSHIFT) % NPV_LIST_LOCKS]) > >>>> #endif > >>>> > >>>> #define CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, pa) do { \ > >>>> > >>>> It fixed the original problem, but I got a new panic. > >>>> "DI already started" in pmap_remove() -> pmap_delayed_invl_start_u(). > >>>> I guess that !NUMA variant does not get much testing, so I'll probably just > >>>> stick with the default. > >>> Why didn't you just removed the KASSERT from pa_index ? > >> > >> Well, I thought it might be useful in the NUMA case. > >> pa_index() definition is shared between both cases. > > Might be define the macro two times, for NUMA/non-NUMA. non-NUMA case > > does not need the assert, because users take it mod NPV_LIST_LOCKS. > > > > I still don't see how that could help with "DI already started" panic. Might be not, might be it would help due to pmap_delayed_invl_genp(). But I would more worry about this 'already started' issue, because this must not happen. Can you remove the assert from the macro and provide backtrace of 'DI already started' panic ? From owner-freebsd-current@freebsd.org Sat May 9 21:02: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 5D3482F5B99 for ; Sat, 9 May 2020 21:02:26 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KKQT26lgz4Kv4 for ; Sat, 9 May 2020 21:02:25 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f175.google.com with SMTP id h4so5346938ljg.12 for ; Sat, 09 May 2020 14:02:25 -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:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ChQkNQvIa+qVS269pcDtt+L6W9RTlEksgi9d1Re6OOA=; b=hAsg1T38AXh8pl9lS8lcLwClMsjtein+FfOCIYVxpYwdpsW02A5ds8cf75Va24sijo 2vzbhIqHZDkjPUNrbyEGTbOYwRQHxdHowQSwQ6ZSwDEMg3cmJG8Zq9x5hAQXtMTzL8LE VNeQ/HQYtqc3bvXi0m9bsY2R68v0x1niuP4UNCZMk7C8cGpgTCmwgqObsHaD/HKKDWYo axEpMv/Ott3lCzM3wH8sEKsau85YJ5tOPs80+g+lYnkMUDx59qP7GeafqcCtpV68cp9C ElvKFRFD591/+ZKg87mTNnikRUNlv+lc/uzZPSKU+w+pMtHZX+DPAzAkxBglnqXBQFq4 DmAA== X-Gm-Message-State: AOAM5301l/UXfnUKb8OuyYrQqMk66ZCh/2/noozeqoGK2wpnWdo9qGeI fQLFeYbxQ+wYqQqIEnoQpFwQQ73xaJo= X-Google-Smtp-Source: ABdhPJworvn3isdv7hnzDnMVD0VcnHUW3YL/85VeNI6H7YymIoszIS3TM4pq5hX7kmJtmH1ZT+uJRQ== X-Received: by 2002:a2e:8752:: with SMTP id q18mr5602750ljj.72.1589058142998; Sat, 09 May 2020 14:02:22 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q21sm5409066lfe.0.2020.05.09.14.02.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 14:02:22 -0700 (PDT) Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? To: Konstantin Belousov Cc: FreeBSD Current References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> <20200509165010.GI44519@kib.kiev.ua> <88ebc8f9-b10d-366d-a12a-fb74417904bc@FreeBSD.org> <20200509204743.GA68906@kib.kiev.ua> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <258a6528-2d43-d72e-b5e1-b189566a9b50@FreeBSD.org> Date: Sun, 10 May 2020 00:02:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200509204743.GA68906@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49KKQT26lgz4Kv4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-1.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[175.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.25)[ip: (-0.38), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[175.208.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 21:02:26 -0000 On 09/05/2020 23:47, Konstantin Belousov wrote: > Might be not, might be it would help due to pmap_delayed_invl_genp(). > But I would more worry about this 'already started' issue, because > this must not happen. Can you remove the assert from the macro and > provide backtrace of 'DI already started' panic ? Oh, now that you asked for it, I see that it was a secondary panic (through vt, fb, drm code path). The first panic was still the same "address %lx beyond the last segment". I'll test your suggestion tomorrow. #10 0xffffffff8080340e in vpanic (fmt=, ap=) at /usr/devel/git/motil/sys/kern/kern_shutdown.c:902 #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 "\265\001ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 #12 0xffffffff80bb4c05 in pmap_delayed_invl_start_u () at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:783 #13 0xffffffff80bb8ede in pmap_remove (pmap=0xffffffff812ee930 , sva=18446741877558251520, eva=) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5418 #14 0xffffffff80b2b6ad in _kmem_unback (object=, addr=18446741877558251520, size=102400) at /usr/devel/git/motil/sys/vm/vm_kern.c:574 #15 0xffffffff80b2b7dd in kmem_free (addr=18446741877558251520, size=102400) at /usr/devel/git/motil/sys/vm/vm_kern.c:614 #16 0xffffffff807db77b in free_large (addr=0xfffffe00ab2e9000, size=102400) at /usr/devel/git/motil/sys/kern/kern_malloc.c:599 #17 free (addr=0xfffffe00ab2e9000, mtp=0xffffffff825f90c0 ) at /usr/devel/git/motil/sys/kern/kern_malloc.c:818 #18 0xffffffff82444922 in dc_gamma_release (gamma=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:162 #19 destruct (plane_state=0xfffff800080ef800) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:53 #20 dc_plane_state_free (kref=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:140 #21 kref_put (kref=, rel=) at /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 #22 dc_plane_state_release (plane_state=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:146 #23 0xffffffff82442de9 in dc_resource_state_destruct (context=0xfffffe00a2af0000) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_resource.c:2295 #24 0xffffffff824355d2 in dc_state_free (kref=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc.c:1152 #25 kref_put (kref=, rel=) at /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 #26 dc_release_state (context=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc.c:1158 #27 0xffffffff8241f6cc in dm_atomic_destroy_state (obj=, state=0xfffff80020465550) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1667 #28 0xffffffff82569734 in drm_atomic_state_default_clear (state=0xfffff80008274a00) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:202 #29 0xffffffff82569827 in drm_atomic_state_clear (state=) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:240 #30 __drm_atomic_state_free (ref=0xfffff80008274a00) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:256 #31 0xffffffff825998d8 in kref_put (kref=0xfffff80008274a00, rel=) at /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 #32 drm_atomic_state_put (state=0xfffff80008274a00) at /usr/home/avg/devel/kms-drm/include/drm/drm_atomic.h:385 #33 restore_fbdev_mode_atomic (fb_helper=, active=true) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_fb_helper.c:461 #34 0xffffffff8259567a in drm_fb_helper_restore_fbdev_mode_unlocked (fb_helper=0xfffff8002096d800) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_fb_helper.c:549 #35 0xffffffff825bcc8a in vt_kms_postswitch (arg=0xfffff800027c52c0) at /usr/home/avg/devel/kms-drm/drivers/gpu/drm/linux_fb.c:97 #36 0xffffffff806b04b2 in vt_window_switch (vw=0xffffffff80e999a8 ) at /usr/devel/git/motil/sys/dev/vt/vt_core.c:603 #37 0xffffffff806ada0f in vtterm_cngrab (tm=) at /usr/devel/git/motil/sys/dev/vt/vt_core.c:1612 #38 0xffffffff8079f776 in cngrab () at /usr/devel/git/motil/sys/kern/kern_cons.c:397 #39 0xffffffff8080335c in vpanic (fmt=0xffffffff80cc257f "address %lx beyond the last segment", ap=0xfffffe009e18c890) at /usr/devel/git/motil/sys/kern/kern_shutdown.c:887 #40 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 "\265\001ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 #41 0xffffffff80bc2ac3 in pmap_remove_pte (pmap=0xfffffe00a4cdbb08, ptq=0xfffff800cd2b4000, va=34523316224, ptepde=3442163815, free=0xfffffe009e18c9a0, lockp=0xfffffe009e18c9b8) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:3599 #42 0xffffffff80bba98c in pmap_remove_ptes (pmap=0xfffffe00a4cdbb08, sva=34523316224, eva=34525413376, pde=0xfffff800b2515270, free=0xfffffe009e18c9a0, lockp=0xfffffe009e18c9b8) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5378 #43 0xffffffff80bb921c in pmap_remove (pmap=, sva=34523316224, eva=) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5506 #44 0xffffffff80b301a0 in vm_map_delete (map=0xfffffe00a4cdb9e8, start=, end=) at /usr/devel/git/motil/sys/vm/vm_map.c:3804 #45 0xffffffff80b3856e in kern_munmap (td=0xfffffe009c7be800, addr0=, size=2097152) at /usr/devel/git/motil/sys/vm/vm_mmap.c:624 #46 0xffffffff80bcff00 in syscallenter (td=) at /usr/devel/git/motil/sys/amd64/amd64/../../kern/subr_syscall.c:162 #47 amd64_syscall (td=0xfffffe009c7be800, traced=0) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:1161 -- Andriy Gapon From owner-freebsd-current@freebsd.org Sat May 9 21:25: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 067B32F654B for ; Sat, 9 May 2020 21:25:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49KKwy3VHJz4M5v; Sat, 9 May 2020 21:25:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 049LPClc080151 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 10 May 2020 00:25:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 049LPClc080151 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 049LPClP080149; Sun, 10 May 2020 00:25:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 May 2020 00:25:12 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ? Message-ID: <20200509212512.GB68906@kib.kiev.ua> References: <0d7db402-621e-cc6b-2918-2078f63e2a9b@FreeBSD.org> <20200508161500.GC44519@kib.kiev.ua> <6485ab77-a3d0-8916-9431-74e4da1e3ea7@FreeBSD.org> <20200509161325.GH44519@kib.kiev.ua> <20200509165010.GI44519@kib.kiev.ua> <88ebc8f9-b10d-366d-a12a-fb74417904bc@FreeBSD.org> <20200509204743.GA68906@kib.kiev.ua> <258a6528-2d43-d72e-b5e1-b189566a9b50@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <258a6528-2d43-d72e-b5e1-b189566a9b50@FreeBSD.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,PLING_QUERY 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: 49KKwy3VHJz4M5v X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.32 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, 09 May 2020 21:25:23 -0000 On Sun, May 10, 2020 at 12:02:19AM +0300, Andriy Gapon wrote: > On 09/05/2020 23:47, Konstantin Belousov wrote: > > Might be not, might be it would help due to pmap_delayed_invl_genp(). > > But I would more worry about this 'already started' issue, because > > this must not happen. Can you remove the assert from the macro and > > provide backtrace of 'DI already started' panic ? > > Oh, now that you asked for it, I see that it was a secondary panic (through vt, > fb, drm code path). > The first panic was still the same "address %lx beyond the last segment". > I'll test your suggestion tomorrow. Yes, the backtrace is reasonable in the sense that VM was recursed due to panic while already in DI section. So pmap_remove() from inside panic handler indeed triggered the right assert. > > > #10 0xffffffff8080340e in vpanic (fmt=, ap=) at > /usr/devel/git/motil/sys/kern/kern_shutdown.c:902 > #11 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > "\265\001ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > #12 0xffffffff80bb4c05 in pmap_delayed_invl_start_u () at > /usr/devel/git/motil/sys/amd64/amd64/pmap.c:783 > #13 0xffffffff80bb8ede in pmap_remove (pmap=0xffffffff812ee930 > , sva=18446741877558251520, eva=) at > /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5418 > #14 0xffffffff80b2b6ad in _kmem_unback (object=, > addr=18446741877558251520, size=102400) at /usr/devel/git/motil/sys/vm/vm_kern.c:574 > #15 0xffffffff80b2b7dd in kmem_free (addr=18446741877558251520, size=102400) at > /usr/devel/git/motil/sys/vm/vm_kern.c:614 > #16 0xffffffff807db77b in free_large (addr=0xfffffe00ab2e9000, size=102400) at > /usr/devel/git/motil/sys/kern/kern_malloc.c:599 > #17 free (addr=0xfffffe00ab2e9000, mtp=0xffffffff825f90c0 ) at > /usr/devel/git/motil/sys/kern/kern_malloc.c:818 > #18 0xffffffff82444922 in dc_gamma_release (gamma=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:162 > #19 destruct (plane_state=0xfffff800080ef800) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:53 > #20 dc_plane_state_free (kref=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:140 > #21 kref_put (kref=, rel=) at > /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 > #22 dc_plane_state_release (plane_state=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_surface.c:146 > #23 0xffffffff82442de9 in dc_resource_state_destruct > (context=0xfffffe00a2af0000) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc_resource.c:2295 > #24 0xffffffff824355d2 in dc_state_free (kref=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc.c:1152 > #25 kref_put (kref=, rel=) at > /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 > #26 dc_release_state (context=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/core/dc.c:1158 > #27 0xffffffff8241f6cc in dm_atomic_destroy_state (obj=, > state=0xfffff80020465550) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1667 > #28 0xffffffff82569734 in drm_atomic_state_default_clear > (state=0xfffff80008274a00) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:202 > #29 0xffffffff82569827 in drm_atomic_state_clear (state=) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:240 > #30 __drm_atomic_state_free (ref=0xfffff80008274a00) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_atomic.c:256 > #31 0xffffffff825998d8 in kref_put (kref=0xfffff80008274a00, rel= out>) at /usr/devel/git/motil/sys/compat/linuxkpi/common/include/linux/kref.h:74 > #32 drm_atomic_state_put (state=0xfffff80008274a00) at > /usr/home/avg/devel/kms-drm/include/drm/drm_atomic.h:385 > #33 restore_fbdev_mode_atomic (fb_helper=, active=true) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_fb_helper.c:461 > #34 0xffffffff8259567a in drm_fb_helper_restore_fbdev_mode_unlocked > (fb_helper=0xfffff8002096d800) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/drm_fb_helper.c:549 > #35 0xffffffff825bcc8a in vt_kms_postswitch (arg=0xfffff800027c52c0) at > /usr/home/avg/devel/kms-drm/drivers/gpu/drm/linux_fb.c:97 > #36 0xffffffff806b04b2 in vt_window_switch (vw=0xffffffff80e999a8 > ) at /usr/devel/git/motil/sys/dev/vt/vt_core.c:603 > #37 0xffffffff806ada0f in vtterm_cngrab (tm=) at > /usr/devel/git/motil/sys/dev/vt/vt_core.c:1612 > #38 0xffffffff8079f776 in cngrab () at /usr/devel/git/motil/sys/kern/kern_cons.c:397 > #39 0xffffffff8080335c in vpanic (fmt=0xffffffff80cc257f "address %lx beyond the > last segment", ap=0xfffffe009e18c890) at > /usr/devel/git/motil/sys/kern/kern_shutdown.c:887 > #40 0xffffffff808031a3 in panic (fmt=0xffffffff8119a998 > "\265\001ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839 > #41 0xffffffff80bc2ac3 in pmap_remove_pte (pmap=0xfffffe00a4cdbb08, > ptq=0xfffff800cd2b4000, va=34523316224, ptepde=3442163815, > free=0xfffffe009e18c9a0, lockp=0xfffffe009e18c9b8) at > /usr/devel/git/motil/sys/amd64/amd64/pmap.c:3599 > #42 0xffffffff80bba98c in pmap_remove_ptes (pmap=0xfffffe00a4cdbb08, > sva=34523316224, eva=34525413376, pde=0xfffff800b2515270, > free=0xfffffe009e18c9a0, lockp=0xfffffe009e18c9b8) at > /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5378 > #43 0xffffffff80bb921c in pmap_remove (pmap=, sva=34523316224, > eva=) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:5506 > #44 0xffffffff80b301a0 in vm_map_delete (map=0xfffffe00a4cdb9e8, > start=, end=) at > /usr/devel/git/motil/sys/vm/vm_map.c:3804 > #45 0xffffffff80b3856e in kern_munmap (td=0xfffffe009c7be800, addr0= out>, size=2097152) at /usr/devel/git/motil/sys/vm/vm_mmap.c:624 > #46 0xffffffff80bcff00 in syscallenter (td=) at > /usr/devel/git/motil/sys/amd64/amd64/../../kern/subr_syscall.c:162 > #47 amd64_syscall (td=0xfffffe009c7be800, traced=0) at > /usr/devel/git/motil/sys/amd64/amd64/trap.c:1161 > > -- > Andriy Gapon