From owner-freebsd-hackers@freebsd.org Sun May 3 01:47:03 2020 Return-Path: Delivered-To: freebsd-hackers@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 530C12CD2AA 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 49F84460JZz41Q3 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: 49F84460JZz41Q3 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Sun May 3 14:38:14 2020 Return-Path: Delivered-To: freebsd-hackers@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 E26552DF05A 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 49FT9x2VtYz3Gyy 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: 49FT9x2VtYz3Gyy 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:38:15 -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-hackers@freebsd.org Sun May 3 18:08:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 899AC2E4477 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 49FYrf4H0cz41sd 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: 49FYrf4H0cz41sd 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Sun May 3 21:32:41 2020 Return-Path: Delivered-To: freebsd-hackers@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 DFA802BA1E0 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 49FfN849qmz4LRl 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: 49FfN849qmz4LRl 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:32:41 -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-hackers@freebsd.org Sun May 3 21:50:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 8431A2BAD38; Sun, 3 May 2020 21:50:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 49Ffmq3Pc6z4MMN; Sun, 3 May 2020 21:50:35 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 034428DDD; Sun, 3 May 2020 21:50:28 +0000 (UTC) To: freebsd-hackers@freebsd.org, freebsd-x11@freebsd.org, multimedia@FreeBSD.org References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> From: Eric McCorkle Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXonLJBYJKwYBBAHaRw8BAQdA4oHU11A8qtqD0EtRofyORHbGX1ZIT/mnk9eceKQx56q0 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEPfuJobsx0Me4pIwLPOOjZtwQVqwFAl6JzIAC GQEACgkQPOOjZtwQVqy2DgD+IRCNNfb7C16fjEHazDMBwmBIMz+CTJUdhoz73P9iy0cA/ixK 83qOW46q1fpCpaZtPvv0FRpcZ5EppnNQ0Yuh40YLuDgEXonLJBIKKwYBBAGXVQEFAQEHQCxw rRXlvDoXgDGv2WMrLy9UaJ4fNWXIdlaiiKZIH7lBAwEIB4h+BBgWCAAmFiEEPfuJobsx0Me4 pIwLPOOjZtwQVqwFAl6JyyQCGwwFCQHhM4AACgkQPOOjZtwQVqxS7wD+JgzZC4995EL9j2iB qhPUZTIgs61IypLoDx+o1zsSfvkBALs+/jvkQL4plT0hGtfFaa0iMnLeIXKd/1FSNGSD9hQI Subject: Re: Working on Zoom port Message-ID: Date: Sun, 3 May 2020 17:50:24 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8NpgeSMBp7OJhWa0AXAcrdlOeo1oH9EN4" X-Rspamd-Queue-Id: 49Ffmq3Pc6z4MMN X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 2001:470:1f11:617::107) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-5.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[metricspace.net]; IP_SCORE(-2.66)[ip: (-5.03), ipnet: 2001:470::/32(-4.64), asn: 6939(-3.60), country: US(-0.05)]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:50:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8NpgeSMBp7OJhWa0AXAcrdlOeo1oH9EN4 Content-Type: multipart/mixed; boundary="YAWkh5MMXumm9knyy9LuOrs2TSVV2KxON"; protected-headers="v1" From: Eric McCorkle To: freebsd-hackers@freebsd.org, freebsd-x11@freebsd.org, multimedia@FreeBSD.org Message-ID: Subject: Re: Working on Zoom port References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> In-Reply-To: <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> --YAWkh5MMXumm9knyy9LuOrs2TSVV2KxON Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Finally got back to this, made a bit of progress... On 4/15/20 7:25 AM, Eric McCorkle wrote: >> Also they ship a whole bunch of libraries without any licenses. For su= re >> there is Apache and BSD code in there. I guess somebody could write >> Boston to the the GPL licenses, but the other libraries are totally a >> no-go without licenses. See below >> Are they using the "commerical" version of Qt? Or maybe they just got >> liberal with it like they did the other stuff? I think the commercial >> version is different than normal people have, if not now then soon. >=20 > I'm intending to figure out what version of Qt they are using. It woul= d > be better in my opinion to install the Qt ports. If they are using > professional, then we'll have to use whatever they install. >=20 > Regardless, this is going to have to be one of those packages that > doesn't get distributed by FreeBSD (like other commercial ports). >=20 Indeed, it seems to be some kind of commercial version of Qt. I have, however, gotten it to start all the way. I added linux-c7-nss to the dependency list (provides libsmime3). After that, you have to run the linux ldconfig: # /compat/linux/sbin/ldconfig /compat/linux/opt/zoom/ (I have to run this as root, and the effects don't seem to carry over to my standard user account. Confession: I don't fully understand what this is doing, and I imagine there's a "right" way to do this for ports")= If you do that, then zoom actually tries to start! Unfortunately, it seems to be missing assets or something: No PulseAudio daemon running, or not running as session daemon. zoom started. Client: Breakpad is using Single Client Mode! client fd =3D -1 QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root= ' [CZPClientLogMgr::LogClientEnvironment] [MacAddr: ][client: Linux][OS: CentOS Linux 7 (Core)][Hardware: CPU Core:4 Frenquency:3.1 G Memory size:32663MB CPU Brand:Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz GPU Brand:][Req ID: ] Linux Client Version is 3.5.385850.0413 QSG_RENDER_LOOP is XDG_CURRENT_DESKTOP =3D GNOME; GDMSESSION =3D gnome Graphics Card Info:: Zoom package arch is 64bit, runing OS arch is x86_64 AppIconMgr::systemDesktopName log Desktop Name: gnome qt.svg: link image0 hasn't been detected! qt.svg: :/images/wechat.svg:10:6: Could not resolve property: pattern0 ExceptionHandler::SendContinueSignalToChild sys_write failed:ExceptionHandler::WaitForContinueSignal sys_read failed:Broken pip= e ExceptionHandler::GenerateDump waitpid failed:Bad file descriptorBad file descriptor The pulseaudio non-detection is probably something to do with running zoom as a different user than my x session. Things I could use help with: 1) What is the "right way" to do this ldconfig step? (Preferably, something I could have the port do?) 2) Anyone who knows something about qt? --YAWkh5MMXumm9knyy9LuOrs2TSVV2KxON-- --8NpgeSMBp7OJhWa0AXAcrdlOeo1oH9EN4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQ9+4mhuzHQx7ikjAs846Nm3BBWrAUCXq88pAAKCRA846Nm3BBW rAKWAP0eH6+V2MidViXsgL22lsOvk9QB4PL47G/+db1BwjQ+/QEA8a6rIAxBQN/H ghj402/CFQgq4TMmQf0QiyFbcipFfgw= =93l/ -----END PGP SIGNATURE----- --8NpgeSMBp7OJhWa0AXAcrdlOeo1oH9EN4-- From owner-freebsd-hackers@freebsd.org Sun May 3 23:53:14 2020 Return-Path: Delivered-To: freebsd-hackers@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 A90D12BD5DB; Sun, 3 May 2020 23:53:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (static-108-31-38-18.washdc.fios.verizon.net [108.31.38.18]) by mx1.freebsd.org (Postfix) with ESMTP id 49FjVJ5Bxbz4SXD; Sun, 3 May 2020 23:53:12 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9D1D68ECE; Sun, 3 May 2020 23:53:06 +0000 (UTC) Subject: Re: Working on Zoom port To: freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> From: Eric McCorkle Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXonLJBYJKwYBBAHaRw8BAQdA4oHU11A8qtqD0EtRofyORHbGX1ZIT/mnk9eceKQx56q0 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEPfuJobsx0Me4pIwLPOOjZtwQVqwFAl6JzIAC GQEACgkQPOOjZtwQVqy2DgD+IRCNNfb7C16fjEHazDMBwmBIMz+CTJUdhoz73P9iy0cA/ixK 83qOW46q1fpCpaZtPvv0FRpcZ5EppnNQ0Yuh40YLuDgEXonLJBIKKwYBBAGXVQEFAQEHQCxw rRXlvDoXgDGv2WMrLy9UaJ4fNWXIdlaiiKZIH7lBAwEIB4h+BBgWCAAmFiEEPfuJobsx0Me4 pIwLPOOjZtwQVqwFAl6JyyQCGwwFCQHhM4AACgkQPOOjZtwQVqxS7wD+JgzZC4995EL9j2iB qhPUZTIgs61IypLoDx+o1zsSfvkBALs+/jvkQL4plT0hGtfFaa0iMnLeIXKd/1FSNGSD9hQI Message-ID: <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> Date: Sun, 3 May 2020 19:53:02 -0400 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PSUMg8AnPyGqDdHrRIdrd8l5fytiDsHgC" X-Rspamd-Queue-Id: 49FjVJ5Bxbz4SXD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 108.31.38.18) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; IP_SCORE(-0.78)[ip: (-2.98), ipnet: 108.31.0.0/16(-1.49), asn: 701(0.60), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:701, ipnet:108.31.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 23:53:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PSUMg8AnPyGqDdHrRIdrd8l5fytiDsHgC Content-Type: multipart/mixed; boundary="7wGfn05Uy6003GNZX9dd1GP2lxzfXRa0a"; protected-headers="v1" From: Eric McCorkle To: freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" Message-ID: <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> Subject: Re: Working on Zoom port References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> In-Reply-To: --7wGfn05Uy6003GNZX9dd1GP2lxzfXRa0a Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/3/20 5:50 PM, Eric McCorkle wrote: > Indeed, it seems to be some kind of commercial version of Qt. >=20 > I have, however, gotten it to start all the way. I added linux-c7-nss > to the dependency list (provides libsmime3). After that, you have to > run the linux ldconfig: >=20 > # /compat/linux/sbin/ldconfig /compat/linux/opt/zoom/ >=20 > (I have to run this as root, and the effects don't seem to carry over t= o > my standard user account. Confession: I don't fully understand what > this is doing, and I imagine there's a "right" way to do this for ports= ") >=20 > If you do that, then zoom actually tries to start! Unfortunately, it > seems to be missing assets or something: >=20 >=20 > No PulseAudio daemon running, or not running as session daemon. > zoom started. > Client: Breakpad is using Single Client Mode! client fd =3D -1 > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-ro= ot' > [CZPClientLogMgr::LogClientEnvironment] [MacAddr: ][client: Linux][OS: > CentOS Linux 7 (Core)][Hardware: CPU Core:4 Frenquency:3.1 G Memory > size:32663MB CPU Brand:Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz GPU > Brand:][Req ID: ] > Linux Client Version is 3.5.385850.0413 > QSG_RENDER_LOOP is > XDG_CURRENT_DESKTOP =3D GNOME; GDMSESSION =3D gnome > Graphics Card Info:: > Zoom package arch is 64bit, runing OS arch is x86_64 > AppIconMgr::systemDesktopName log Desktop Name: gnome > qt.svg: link image0 hasn't been detected! > qt.svg: :/images/wechat.svg:10:6: Could not resolve property: pattern0 > ExceptionHandler::SendContinueSignalToChild sys_write > failed:ExceptionHandler::WaitForContinueSignal sys_read failed:Broken p= ipe > ExceptionHandler::GenerateDump waitpid failed:Bad file descriptorBad > file descriptor 1) Pulseaudio issue was in fact different user IDs. 2) After looking at some issues posted for the linux client, it looks like the qt.svg messages are just noise. I also noticed some syslog messages that are probably the root cause: linux: pid 3906 (QDBusConnection): syscall inotify_init1 not implemented linux: pid 3906 (QDBusConnection): syscall inotify_init not implemented linux: pid 3919 (QDBusConnection): syscall inotify_init1 not implemented linux: pid 3919 (QDBusConnection): syscall inotify_init not implemented linux: pid 3906 (vcdn_thread): syscall inotify_init not implemented pid 3906 (ProcessThread), jid 0, uid 1001: exited on signal 11 (core dump= ed) I need to look more into what these are. Posting in case someone knows anything. --7wGfn05Uy6003GNZX9dd1GP2lxzfXRa0a-- --PSUMg8AnPyGqDdHrRIdrd8l5fytiDsHgC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQ9+4mhuzHQx7ikjAs846Nm3BBWrAUCXq9ZXgAKCRA846Nm3BBW rD7IAP9kBRHDW2jg5uEVWfsvuM+4xR+H2yuNTA0wPv0aE5gSVgEAntsgFSRIu7jX ht696Fz0hZxPSrUxWn2yw+Bi2eQBeAU= =BdbV -----END PGP SIGNATURE----- --PSUMg8AnPyGqDdHrRIdrd8l5fytiDsHgC-- From owner-freebsd-hackers@freebsd.org Mon May 4 00:18:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 D0B1D2BE6A9; Mon, 4 May 2020 00:18:48 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 49Fk3q4p9rz4Tf6; Mon, 4 May 2020 00:18:47 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id D82448F45; Mon, 4 May 2020 00:18:46 +0000 (UTC) To: Austin Shafer , freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> From: Eric McCorkle Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXonLJBYJKwYBBAHaRw8BAQdA4oHU11A8qtqD0EtRofyORHbGX1ZIT/mnk9eceKQx56q0 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEPfuJobsx0Me4pIwLPOOjZtwQVqwFAl6JzIAC GQEACgkQPOOjZtwQVqy2DgD+IRCNNfb7C16fjEHazDMBwmBIMz+CTJUdhoz73P9iy0cA/ixK 83qOW46q1fpCpaZtPvv0FRpcZ5EppnNQ0Yuh40YLuDgEXonLJBIKKwYBBAGXVQEFAQEHQCxw rRXlvDoXgDGv2WMrLy9UaJ4fNWXIdlaiiKZIH7lBAwEIB4h+BBgWCAAmFiEEPfuJobsx0Me4 pIwLPOOjZtwQVqwFAl6JyyQCGwwFCQHhM4AACgkQPOOjZtwQVqxS7wD+JgzZC4995EL9j2iB qhPUZTIgs61IypLoDx+o1zsSfvkBALs+/jvkQL4plT0hGtfFaa0iMnLeIXKd/1FSNGSD9hQI Subject: Re: Working on Zoom port Message-ID: <59438393-6608-1afb-7fcd-dbce5a7503f7@metricspace.net> Date: Sun, 3 May 2020 20:18:43 -0400 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MKw9zVrLkPQ9OxGcvaoB0IQpcEJjnBtoF" X-Rspamd-Queue-Id: 49Fk3q4p9rz4Tf6 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 2001:470:1f11:617::107) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-5.90 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.80)[ip: (-5.69), ipnet: 2001:470::/32(-4.64), asn: 6939(-3.60), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 00:18:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MKw9zVrLkPQ9OxGcvaoB0IQpcEJjnBtoF Content-Type: multipart/mixed; boundary="wzJmMcFKoLVAYGPGZ8ZbmUkaZbyA63m1U"; protected-headers="v1" From: Eric McCorkle To: Austin Shafer , freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" Message-ID: <59438393-6608-1afb-7fcd-dbce5a7503f7@metricspace.net> Subject: Re: Working on Zoom port References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> In-Reply-To: --wzJmMcFKoLVAYGPGZ8ZbmUkaZbyA63m1U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/3/20 8:07 PM, Austin Shafer wrote: >> linux: pid 3906 (QDBusConnection): syscall inotify_init1 not implement= ed >> linux: pid 3906 (QDBusConnection): syscall inotify_init not implemente= d >> linux: pid 3919 (QDBusConnection): syscall inotify_init1 not implement= ed >> linux: pid 3919 (QDBusConnection): syscall inotify_init not implemente= d >> linux: pid 3906 (vcdn_thread): syscall inotify_init not implemented >=20 > A while back I tried to map linux's inotify to kqueue in the linuxlator= > to solve this problem for steam. It was not very successful. Although i= t > could handle monitoring single files, it could not do directories which= > is how most people seem to use inotify. I wonder why zoom needs this? >=20 > Unfortunately I can't seem to find the patches. If I do I'll let > you know. >=20 Those are syslog messages. The corresponding application log messages look like it's trying to talk through a socket, probably to DBus --wzJmMcFKoLVAYGPGZ8ZbmUkaZbyA63m1U-- --MKw9zVrLkPQ9OxGcvaoB0IQpcEJjnBtoF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQ9+4mhuzHQx7ikjAs846Nm3BBWrAUCXq9fYwAKCRA846Nm3BBW rEeIAQDyN4O8wnrYQ/bZEiiLuHCr19bxGsgyuZoEvExgNQNkHwEAnndF/eA++c5F f/tF1HY4Wzti2MCUxlP+yBJSja5oiw8= =S4xJ -----END PGP SIGNATURE----- --MKw9zVrLkPQ9OxGcvaoB0IQpcEJjnBtoF-- From owner-freebsd-hackers@freebsd.org Mon May 4 00:35:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 B6B5E2BEE77; Mon, 4 May 2020 00:35:48 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (static-108-31-38-18.washdc.fios.verizon.net [108.31.38.18]) by mx1.freebsd.org (Postfix) with ESMTP id 49FkRS15Yhz4VRR; Mon, 4 May 2020 00:35:47 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 5D0D48EDF; Mon, 4 May 2020 00:35:47 +0000 (UTC) Subject: Re: Working on Zoom port To: Austin Shafer , freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> <59438393-6608-1afb-7fcd-dbce5a7503f7@metricspace.net> From: Eric McCorkle Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXonLJBYJKwYBBAHaRw8BAQdA4oHU11A8qtqD0EtRofyORHbGX1ZIT/mnk9eceKQx56q0 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEPfuJobsx0Me4pIwLPOOjZtwQVqwFAl6JzIAC GQEACgkQPOOjZtwQVqy2DgD+IRCNNfb7C16fjEHazDMBwmBIMz+CTJUdhoz73P9iy0cA/ixK 83qOW46q1fpCpaZtPvv0FRpcZ5EppnNQ0Yuh40YLuDgEXonLJBIKKwYBBAGXVQEFAQEHQCxw rRXlvDoXgDGv2WMrLy9UaJ4fNWXIdlaiiKZIH7lBAwEIB4h+BBgWCAAmFiEEPfuJobsx0Me4 pIwLPOOjZtwQVqwFAl6JyyQCGwwFCQHhM4AACgkQPOOjZtwQVqxS7wD+JgzZC4995EL9j2iB qhPUZTIgs61IypLoDx+o1zsSfvkBALs+/jvkQL4plT0hGtfFaa0iMnLeIXKd/1FSNGSD9hQI Message-ID: <66ed62a7-7417-a6ca-ff01-045dc837d41d@metricspace.net> Date: Sun, 3 May 2020 20:35:42 -0400 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dEQUCOMvssHU89fHhmQjp3UMrmtwAI5x6" X-Rspamd-Queue-Id: 49FkRS15Yhz4VRR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 108.31.38.18) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-4.03 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:701, ipnet:108.31.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.93)[ip: (-3.46), ipnet: 108.31.0.0/16(-1.73), asn: 701(0.59), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 00:35:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dEQUCOMvssHU89fHhmQjp3UMrmtwAI5x6 Content-Type: multipart/mixed; boundary="36XMZy87cA0aOKi5GI76P1EJKL1a8tzRF"; protected-headers="v1" From: Eric McCorkle To: Austin Shafer , freebsd-hackers@freebsd.org, multimedia@FreeBSD.org, "freebsd-x11@freebsd.org" Message-ID: <66ed62a7-7417-a6ca-ff01-045dc837d41d@metricspace.net> Subject: Re: Working on Zoom port References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> <59438393-6608-1afb-7fcd-dbce5a7503f7@metricspace.net> In-Reply-To: --36XMZy87cA0aOKi5GI76P1EJKL1a8tzRF Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/3/20 8:27 PM, Austin Shafer wrote: > Eric McCorkle writes: >=20 >> On 5/3/20 8:07 PM, Austin Shafer wrote: >>>> linux: pid 3906 (QDBusConnection): syscall inotify_init1 not impleme= nted >>>> linux: pid 3906 (QDBusConnection): syscall inotify_init not implemen= ted >>>> linux: pid 3919 (QDBusConnection): syscall inotify_init1 not impleme= nted >>>> linux: pid 3919 (QDBusConnection): syscall inotify_init not implemen= ted >>>> linux: pid 3906 (vcdn_thread): syscall inotify_init not implemented >>> >>> A while back I tried to map linux's inotify to kqueue in the linuxlat= or >>> to solve this problem for steam. It was not very successful. Although= it >>> could handle monitoring single files, it could not do directories whi= ch >>> is how most people seem to use inotify. I wonder why zoom needs this?= >>> >>> Unfortunately I can't seem to find the patches. If I do I'll let >>> you know. >>> >> >> Those are syslog messages. The corresponding application log messages= >> look like it's trying to talk through a socket, probably to DBus >=20 > Either way, something is trying to use inotify which the linuxlator doe= s not > support. >=20 Guess I'm dead in the water, then. Oh well, it was worth a shot. --36XMZy87cA0aOKi5GI76P1EJKL1a8tzRF-- --dEQUCOMvssHU89fHhmQjp3UMrmtwAI5x6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQ9+4mhuzHQx7ikjAs846Nm3BBWrAUCXq9jXgAKCRA846Nm3BBW rJkpAQCGiEjLUMlJ2F2Rigsii33Cc4ZUJtkOD8iWy1gVZKPengEA0kEc5UaEEzPk KlabuWmszt8QmUsWTdB8hi0EY98RAgU= =AdbV -----END PGP SIGNATURE----- --dEQUCOMvssHU89fHhmQjp3UMrmtwAI5x6-- From owner-freebsd-hackers@freebsd.org Mon May 4 03:35:43 2020 Return-Path: Delivered-To: freebsd-hackers@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 30A402C1D2D 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 49FpR15xRbz4cPc 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: 49FpR15xRbz4cPc 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Mon May 4 18:16:24 2020 Return-Path: Delivered-To: freebsd-hackers@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 536B02D6486 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 49G9zC3kQhz4XNy 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: 49G9zC3kQhz4XNy 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-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Mon May 4 22:02:53 2020 Return-Path: Delivered-To: freebsd-hackers@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 3A3AC2C4C0F for ; Mon, 4 May 2020 22:02:53 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 49GH0W63gqz3N9h for ; Mon, 4 May 2020 22:02:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] ([194.32.164.30]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 044M2hJE020021 for ; Mon, 4 May 2020 23:02:43 +0100 (BST) (envelope-from rb@gid.co.uk) From: Bob Bishop Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Linuxulator no DNS Message-Id: Date: Mon, 4 May 2020 23:02:43 +0100 To: Hackers freeBSD X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 49GH0W63gqz3N9h X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,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-hackers@freebsd.org]; DMARC_NA(0.00)[gid.co.uk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.43)[ip: (-1.68), ipnet: 194.32.164.0/24(-0.84), asn: 42831(0.44), country: GB(-0.07)]; TO_DN_ALL(0.00)[]; MV_CASE(0.50)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 22:02:53 -0000 Hi, I=E2=80=99m sure this is something simple but I can=E2=80=99t see it. = I=E2=80=99ve just installed biology/foldingathome on a recent HEAD, it = pulls in the linuxulator as a dependency. Everything works except that FAHClient isn=E2=80=99t seeing DNS = resolution. I can make it work by plugging relevant entries into = /compat/linux/etc/hosts, but looks like there is no DNS resolution in = the linuxulator world. DNS is working fine outside the linuxulator. Clue please? Thanks -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Mon May 4 23:39:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 B6A1A2C7062 for ; Mon, 4 May 2020 23:39:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) 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 49GK7d6HJGz3ygR for ; Mon, 4 May 2020 23:39:09 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk1-x744.google.com with SMTP id n14so565208qke.8 for ; Mon, 04 May 2020 16:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=h8LDimSet/38gOj9k+/3B5SPGGqlECfwGT7xtQ++7mM=; b=bVatq608eWh0i2TvbLdC0vsXZ2THOahKMAKZ301kz5JXHiE/ULBp2c3xcI8SrZ0MTq dAU3Ahak8Kx8C0SrYwEpbeicK1SLfRVejNKsyxF2PpPfXFqc05HsK3IYDrIQ7A/DMy9/ 4E1S16QA5PG6q+KaP6f5Vt/0k3htcHjK0/kjIa6maL6pNOl8oVceeo6OSi7jlipex0aN hba1FrWcxXoSmR2LK/2V0cKJQ0H+tIOTY0ID0E7Md+XcDVJh4ZiLU1VrhFsWf2N6KA+X yZ7QNKf3K8Ji6eUKYPKaKUH7Ys5U0Im9Cq4n4syRiwAqfkizYuI3sAqWuhSQqqFbGIsX WPVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=h8LDimSet/38gOj9k+/3B5SPGGqlECfwGT7xtQ++7mM=; b=scwXag9HjhHTT63nCPe1uNKJQ/95tq54OY9fVOgTHV/HWgUxAfKFEhe6FD17Qotgu9 oAtq3qyNrHaEdRWCLZQo7piA2gm96+OcY4eAWsLMOUc4QweE7bAsvFxfR220SRzU6fS2 HS+Tup3AUSxN+fKEiTWwjwr5pkgnUd7mH/d/hM1dO0zy1oGLy03oq3wAbFiNVFpkwqmy rMlFdwEmR8T5MFr5/H9s6O7nCNA4BC4iA/Yr5loKYY+sFEmP2P4tNKvyDKEhJq1pj+d/ vf4vOIJxpMSJFXqgq9cyJkVkWeA11tuZw5hkcpp3U0yVbbsMCzaOABAc99nONv+76guT O73A== X-Gm-Message-State: AGi0PuYijrkJlaQ6s0N2gIWELX7+k1HL5chm3KEdSlu3SOF7UfX4GvIR wrvYRzqRsmCAjFA49RGwPwTzrk+32PM= X-Google-Smtp-Source: APiQypILqsXFWEMKCqqDcnQkMjijV6IsuVB+mKQo8qOwgLO/Bf68MaqhoXsg3tmwnrLl1rAbO6mwSg== X-Received: by 2002:a37:49d5:: with SMTP id w204mr825517qka.335.1588635548720; Mon, 04 May 2020 16:39:08 -0700 (PDT) Received: from [192.168.1.31] (ool-457b63be.dyn.optonline.net. [69.123.99.190]) by smtp.gmail.com with ESMTPSA id l24sm286719qtp.8.2020.05.04.16.39.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2020 16:39:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mark Saad Mime-Version: 1.0 (1.0) Subject: Re: Linuxulator no DNS Date: Mon, 4 May 2020 19:39:06 -0400 Message-Id: References: Cc: Hackers freeBSD In-Reply-To: To: Bob Bishop X-Mailer: iPhone Mail (17D50) X-Rspamd-Queue-Id: 49GK7d6HJGz3ygR X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=bVatq608; dmarc=none; spf=none (mx1.freebsd.org: domain of nonesuch@longcount.org has no SPF policy when checking 2607:f8b0:4864:20::744) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-1.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.4.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)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.16)[ip: (0.01), 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]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[190.99.123.69.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 23:39:10 -0000 Bob=20 Check if your Linux chroot has an /etc/resolv.conf .=20 --- Mark Saad | nonesuch@longcount.org > On May 4, 2020, at 6:03 PM, Bob Bishop wrote: >=20 > =EF=BB=BFHi, >=20 > I=E2=80=99m sure this is something simple but I can=E2=80=99t see it. I=E2= =80=99ve just installed biology/foldingathome on a recent HEAD, it pulls in t= he linuxulator as a dependency. >=20 > Everything works except that FAHClient isn=E2=80=99t seeing DNS resolution= . I can make it work by plugging relevant entries into /compat/linux/etc/hos= ts, but looks like there is no DNS resolution in the linuxulator world. >=20 > DNS is working fine outside the linuxulator. Clue please? Thanks >=20 > -- > Bob Bishop > rb@gid.co.uk >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Tue May 5 06:30:59 2020 Return-Path: Delivered-To: freebsd-hackers@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 1D3FD2D9620 for ; Tue, 5 May 2020 06:30:59 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GVGn6pyGz4P66 for ; Tue, 5 May 2020 06:30:57 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from wwinf1m04 ([10.223.70.31]) by mwinf5d45 with ME id auWv2200P0gVLea03uWvE3; Tue, 05 May 2020 08:30:55 +0200 X-ME-Helo: wwinf1m04 X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Tue, 05 May 2020 08:30:55 +0200 X-ME-IP: 2.7.113.176 Date: Tue, 5 May 2020 08:30:55 +0200 (CEST) From: Paul FLOYD Reply-To: Paul FLOYD To: freebsd-hackers@freebsd.org Message-ID: <453259393.837.1588660255688.JavaMail.www@wwinf1m04> Subject: Call for testers - Valgrind MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [2.7.113.176] X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| X-Rspamd-Queue-Id: 49GVGn6pyGz4P66 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.132) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [3.40 / 15.00]; HAS_REPLYTO(0.00)[pjfloyd@wanadoo.fr]; HAS_XOIP(0.00)[]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; IP_SCORE(0.00)[ip: (4.90), ipnet: 80.12.240.0/20(1.72), asn: 3215(2.41), country: FR(-0.00)]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[132.242.12.80.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[wanadoo.fr]; RWL_MAILSPIKE_POSSIBLE(0.00)[132.242.12.80.rep.mailspike.net : 127.0.0.17]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 06:30:59 -0000 Hi I've done a lot of work since the start of the year trying to reboot Valgrind on FreeBSD. Whilst there is still a way to go, the results are looking promising. I'd like to get some feedback, in particular from developers that use debug versions of Qt and libc and who are capable of telling whether any errors produced are false positives or not. All of the items in the FreeBSD bugzilla concerning Valgrind have been addressed, even the enhancement requests. Supported Platforms ~~~~~~~~~~~~~ I've set up VirtualBox VMs as far back as FreeBSD 10 and tested that at least everything builds. I've been doing fairly extensive testing (with Valgrind's own regression suite) on 12.1 amd64 and i386. I'll set up a 13.0-CURRENT VM soon to ensure that I'm ready for the next release. Hardware other than amd64 and i386 is currently not supported with FreeBSD. Porting to other platforms would be a major endeavour. Known Limitations ~~~~~~~~~~~ 1. Signal handling is the current weakspot, particularly on i386. Asynchronous are not correctly delivered to guest signal handlers if they exist. 2. DRD does not work with dlopen() 3. Massif on i386 does not work with --pages-as-heap 4. There are still numerous missing syscalls. 5. ioctl support is limited to those that encode read and write information in the ioctl value. That's the case for most ioctls but not all. 6. _umtx_op ROBUST_LISTS are not supported 7. Valgrind does not work well with capsicum enabled applications, and massif won't work at all. My github repo is here https://github.com/paulfloyd/freebsd_valgrind A+ Paul From owner-freebsd-hackers@freebsd.org Tue May 5 08:52:35 2020 Return-Path: Delivered-To: freebsd-hackers@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 7B9CF2DCE8A 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 49GYQB3R6rz4YR7 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: 49GYQB3R6rz4YR7 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Tue May 5 09:18:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 052F12DE0A9 for ; Tue, 5 May 2020 09:18:36 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 49GZ0C0JjLz4bLC for ; Tue, 5 May 2020 09:18:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 0459IXtl059917; Tue, 5 May 2020 10:18:33 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Linuxulator no DNS From: rb@gid.co.uk In-Reply-To: Date: Tue, 5 May 2020 10:18:30 +0100 Cc: Hackers freeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <9FB18AC5-520E-4039-8A94-889795C359AE@gid.co.uk> References: To: Mark Saad X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 49GZ0C0JjLz4bLC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; IP_SCORE(-0.42)[ip: (-1.63), ipnet: 194.32.164.0/24(-0.82), asn: 42831(0.43), country: GB(-0.07)]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 09:18:36 -0000 Hi, I already added one - no change. host.conf says: order hosts, bind multi on Diagnosis is a bit difficult because there seems to be no host, drill, = dig or whatever in the chroot. > On 5 May 2020, at 00:39, Mark Saad wrote: >=20 > Bob=20 > Check if your Linux chroot has an /etc/resolv.conf .=20 >=20 > --- > Mark Saad | nonesuch@longcount.org >=20 >> On May 4, 2020, at 6:03 PM, Bob Bishop wrote: >>=20 >> =EF=BB=BFHi, >>=20 >> I=E2=80=99m sure this is something simple but I can=E2=80=99t see it. = I=E2=80=99ve just installed biology/foldingathome on a recent HEAD, it = pulls in the linuxulator as a dependency. >>=20 >> Everything works except that FAHClient isn=E2=80=99t seeing DNS = resolution. I can make it work by plugging relevant entries into = /compat/linux/etc/hosts, but looks like there is no DNS resolution in = the linuxulator world. >>=20 >> DNS is working fine outside the linuxulator. Clue please? Thanks >>=20 >> -- >> Bob Bishop >> rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Tue May 5 09:25:21 2020 Return-Path: Delivered-To: freebsd-hackers@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 B81B02DE6A6 for ; Tue, 5 May 2020 09:25:21 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 49GZ806Pjtz4cQF for ; Tue, 5 May 2020 09:25:20 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 0459PKZW064118; Tue, 5 May 2020 10:25:20 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Linuxulator no DNS From: rb@gid.co.uk In-Reply-To: Date: Tue, 5 May 2020 10:25:17 +0100 Cc: Hackers freeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <067F2830-DC70-484C-A277-B13F226E72A0@gid.co.uk> References: To: Mark Saad X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 49GZ806Pjtz4cQF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; IP_SCORE(-0.40)[ip: (-1.58), ipnet: 194.32.164.0/24(-0.79), asn: 42831(0.42), country: GB(-0.07)]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 09:25:21 -0000 Also, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246183 looks = relevant. _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed May 6 18:32:33 2020 Return-Path: Delivered-To: freebsd-hackers@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 3F3F82DC171 for ; Wed, 6 May 2020 18:32:33 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 49HQDw1tJVz41kj for ; Wed, 6 May 2020 18:32:32 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-il1-x12c.google.com with SMTP id c16so415441ilr.3 for ; Wed, 06 May 2020 11:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PYSG1rmiRdqmjnxNqr2XDXuPAOw7QknT5rHRfZZLjI8=; b=B8ZjsLiXOQiAL9OEj8bSnBVuaM5oJl8WSY3prAR5uczd+L5ZeT+NXpTRptWVbwkC2n gBWtFczVa16/04VMRm2xicb1U2FyiZ7tZs4g2Zv8PEhz5gp9vvOfn7OxhP2ZD4qqvrPH w7U1NvPOknPO3CHyfeZ1FnR1l9NO0OAqIBOJo1v7joq/FqOm45DcTW1ZGI7hE8Qg4ogo 9S0t1QFXBnlBb9ek9c5e9ckY+gOuOhh96RHdbsc+pbVo3lWyuFXWuFMVDN0FGb8fhRhu +bmz46BCWRY7bhMBjNVSKacL19g2fxnf5Pm+dbUvXkvi0kZysOdHmkF822DtCwpMFPPO X1tQ== 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=PYSG1rmiRdqmjnxNqr2XDXuPAOw7QknT5rHRfZZLjI8=; b=juEvx4REf8pVRKpU7AMVl0pZDdbBMfOt0YMIl3K04S2P99UgRv3pp3I9JEROUlvIng MuoaVZ7N/b9bVYH0dIiBVmNT/Jp94a+HUuI215rCQBPo4jMaNzK33eVIEEiy88JyITRm cesu/rGgHA3CqAebvLtHs4ZkupbV4yhkH8TGYCL8GNvC442C3HZQArVuIZqWn4S+lcIC R2alWQDbdlkpgz9CIJsGQc1nN3knKP3Qo0aZcVDUzPeR3gTVh2jiAaCJwGG5IxvR7Epj XUqy5zcnGEsPoBxFCRRkOpTToXUJUu3FwEbUUlH3JJzTsKLuDYgmZgKbUxf4crnAc/rs Tu2Q== X-Gm-Message-State: AGi0PuZ6pSVY7y77Ohv3/AXC4FBjljoZeymRQfWLO31hpQSDqX75Tzqq S5rwsbeMXgDUrnftpXCgAnoqsQHjU0I7kYcyLexjnG87bA9yWg== X-Google-Smtp-Source: APiQypKfxmvl+S/t8eIrrhz6c9Hs89QC/7rxXV/gRGP7CHKDUDxxYNDFPORROo+eI74I4Bul93RIgI5SvcOfq57VsMQ= X-Received: by 2002:a92:af11:: with SMTP id n17mr10901387ili.197.1588789950800; Wed, 06 May 2020 11:32:30 -0700 (PDT) MIME-Version: 1.0 From: Damjan Jovanovic Date: Wed, 6 May 2020 20:32:08 +0200 Message-ID: Subject: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...] To: Hackers freeBSD X-Rspamd-Queue-Id: 49HQDw1tJVz41kj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=B8ZjsLiX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of damjanjov@gmail.com designates 2607:f8b0:4864:20::12c as permitted sender) smtp.mailfrom=damjanjov@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-8.99), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[c.2.1.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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:32:33 -0000 Hi Currently "procstat fd [pid]" cannot view anything, even for other processes owned by the user making the call, not even their current working directory (CWD), unless it has PGET_CANDEBUG permission. linprocfs however allows reading the CWD for any process because it doesn't perform that check (sys/compat/linprocfs/linprocfs.c, function linprocfs_doproccwd()). Applications use this, eg. xfce4-terminal relies on /compat/linux/proc//cwd to find the shell's CWD, so that when you open a new tab, it starts in the same CWD as the tab you opened it from ( https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343). I would like to patch xfce4-terminal to use libprocstat for that instead of needing linprocfs to be mounted, but since procstat is more restrictive, it will break it. Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so you can view the CWD for processes you own? Maybe other open files still need to be hidden, but the CWD doesn't seem like a major security concern. Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and only hides file descriptors for processes you don't own. A patch along the following lines could be a start: diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 423968b2e1cc..f487232d2cff 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS) sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req); sbuf_clear_flags(&sb, SBUF_INCLUDENUL); - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); if (error != 0) { sbuf_delete(&sb); return (error); @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS) struct proc *p; name = (int *)arg1; - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); if (error != 0) return (error); fdp = fdhold(p); Thank you Damjan From owner-freebsd-hackers@freebsd.org Wed May 6 21:46:27 2020 Return-Path: Delivered-To: freebsd-hackers@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 AC05E2E0421 for ; Wed, 6 May 2020 21:46:27 +0000 (UTC) (envelope-from kib@freebsd.org) 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 49HVXf5q9jz4DXB for ; Wed, 6 May 2020 21:46:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 046LkBMH073422 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 May 2020 00:46:15 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 046LkBMH073422 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 046LkBOm073421; Thu, 7 May 2020 00:46:11 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 7 May 2020 00:46:11 +0300 From: Konstantin Belousov To: Damjan Jovanovic Cc: Hackers freeBSD Subject: Re: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...] Message-ID: <20200506214611.GD3866@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham 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: 49HVXf5q9jz4DXB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.96)[-0.960,0]; NEURAL_HAM_LONG(-0.98)[-0.983,0]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 21:46:27 -0000 On Wed, May 06, 2020 at 08:32:08PM +0200, Damjan Jovanovic wrote: > Hi > > Currently "procstat fd [pid]" cannot view anything, even for other > processes owned by the user making the call, not even their current working > directory (CWD), unless it has PGET_CANDEBUG permission. > > linprocfs however allows reading the CWD for any process because it doesn't > perform that check (sys/compat/linprocfs/linprocfs.c, function > linprocfs_doproccwd()). > > Applications use this, eg. xfce4-terminal relies on > /compat/linux/proc//cwd to find the shell's CWD, so that when you open > a new tab, it starts in the same CWD as the tab you opened it from ( > https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343). > I would like to patch xfce4-terminal to use libprocstat for that instead of > needing linprocfs to be mounted, but since procstat is more restrictive, it > will break it. > > Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so you can > view the CWD for processes you own? Maybe other open files still need to be > hidden, but the CWD doesn't seem like a major security concern. Can you explain why CANDEBUG vs CANSEE matters for your case ? Or better, why xfce4-terminal cannot debug shells it spawns ? Is it suid ? My initial reaction was that linprocfs should be patched to match FreeBSD native behaviour instead. > > Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and only > hides file descriptors for processes you don't own. > > A patch along the following lines could be a start: > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 423968b2e1cc..f487232d2cff 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS) > > sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > if (error != 0) { > sbuf_delete(&sb); > return (error); > @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS) > struct proc *p; > > name = (int *)arg1; > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > if (error != 0) > return (error); > fdp = fdhold(p); > > > > > Thank you > Damjan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed May 6 23:05:12 2020 Return-Path: Delivered-To: freebsd-hackers@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 9C0902E213D; Wed, 6 May 2020 23:05:12 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 49HXHV1fqmz4L03; Wed, 6 May 2020 23:05:09 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92 (FreeBSD)) (envelope-from ) id 1jWT66-000PCK-AQ; Wed, 06 May 2020 16:05:03 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 046N51nP096862; Wed, 6 May 2020 16:05:01 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 6 May 2020 16:05:00 -0700 From: Oleksandr Tymoshenko To: Eric McCorkle Cc: Austin Shafer , freebsd-hackers@freebsd.org, multimedia@freebsd.org, "freebsd-x11@freebsd.org" Subject: Re: Working on Zoom port Message-ID: <20200506230500.GA96464@bluezbox.com> References: <2119d998-b4a1-d72f-342d-0afc3cf3a480@metricspace.net> <76793d13-c7df-c607-6751-19bf02fde4b8@metricspace.net> <5d92730b-dad0-974d-f99e-894dcc17af40@metricspace.net> <59438393-6608-1afb-7fcd-dbce5a7503f7@metricspace.net> <66ed62a7-7417-a6ca-ff01-045dc837d41d@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66ed62a7-7417-a6ca-ff01-045dc837d41d@metricspace.net> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Eric McCorkle (eric@metricspace.net) wrote: > On 5/3/20 8:27 PM, Austin Shafer wrote: > > Eric McCorkle writes: > > > >> On 5/3/20 8:07 PM, Austin Shafer wrote: > >>>> linux: pi [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 49HXHV1fqmz4L03 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of gonzo@bluezbox.com designates 45.55.20.155 as permitted sender) smtp.mailfrom=gonzo@bluezbox.com X-Spamd-Result: default: False [-4.72 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[bluezbox.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.42)[ip: (-8.85), ipnet: 45.55.0.0/19(-4.35), asn: 14061(1.15), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 23:05:12 -0000 Eric McCorkle (eric@metricspace.net) wrote: > On 5/3/20 8:27 PM, Austin Shafer wrote: > > Eric McCorkle writes: > > > >> On 5/3/20 8:07 PM, Austin Shafer wrote: > >>>> linux: pid 3906 (QDBusConnection): syscall inotify_init1 not implemented > >>>> linux: pid 3906 (QDBusConnection): syscall inotify_init not implemented > >>>> linux: pid 3919 (QDBusConnection): syscall inotify_init1 not implemented > >>>> linux: pid 3919 (QDBusConnection): syscall inotify_init not implemented > >>>> linux: pid 3906 (vcdn_thread): syscall inotify_init not implemented > >>> > >>> A while back I tried to map linux's inotify to kqueue in the linuxlator > >>> to solve this problem for steam. It was not very successful. Although it > >>> could handle monitoring single files, it could not do directories which > >>> is how most people seem to use inotify. I wonder why zoom needs this? > >>> > >>> Unfortunately I can't seem to find the patches. If I do I'll let > >>> you know. > >>> > >> > >> Those are syslog messages. The corresponding application log messages > >> look like it's trying to talk through a socket, probably to DBus > > > > Either way, something is trying to use inotify which the linuxlator does not > > support. > > > > Guess I'm dead in the water, then. Oh well, it was worth a shot. Hi Eric, inotify seems to be optional. I was able to join Zoom meeting from the VirtualBox 12.0-RELEASE system. No camera, no audio though, only remote video stream rendering. When I tried to move stuff to my laptop the app started crashing. I think it's probably related to Xorg DRI/DRM because Linux glxgears also segfaults on the laptop but works in the VirtualBox Non-obvious stuff I had to do to unblock app start-up: start session dbus daemon, I did it using dbus-monitor app: nohup dbus-monitor & I also used zoom.sh wrapper to start Zoom app. Had to modify it by changing shell to /usr/local/bin/bash and removing core file Linux-isms. Hope it unblocks your progress with the port. -- gonzo From owner-freebsd-hackers@freebsd.org Wed May 6 23:58:06 2020 Return-Path: Delivered-To: freebsd-hackers@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 02B8D2E3C21 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 49HYSX449Cz4PGw 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: 49HYSX449Cz4PGw 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Thu May 7 07:46:40 2020 Return-Path: Delivered-To: freebsd-hackers@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 BCF3913ACA6 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 49HlsC2BLqz3FJP 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: 49HlsC2BLqz3FJP 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Thu May 7 11:23:46 2020 Return-Path: Delivered-To: freebsd-hackers@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 9E81B2C449B for ; Thu, 7 May 2020 11:23:46 +0000 (UTC) (envelope-from debdrup@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 49Hrgk3fRJz41t4 for ; Thu, 7 May 2020 11:23:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 7D3482C449A; Thu, 7 May 2020 11:23:46 +0000 (UTC) Delivered-To: hackers@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 7CFA22C4499 for ; Thu, 7 May 2020 11:23:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 49Hrgk2lfSz41t3 for ; Thu, 7 May 2020 11:23:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 3C73A10422; Thu, 7 May 2020 11:23:46 +0000 (UTC) Date: Thu, 7 May 2020 13:23:46 +0200 From: Daniel Ebdrup Jensen To: hackers@freebsd.org Subject: Regarding /cdrom in hier(7) Message-ID: <20200507112346.GA53286@freefall.freebsd.org> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 11:23:46 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline After a bit of a long conversation on IRC, I've concluded that perhaps it's time for the /cdrom entry in hier(7) to be sent off to better pastures. It's got a bit of a weird history where, before it was implemented, sysinstall used /mnt/dists until that was changed on the 22nd of May 1995, as shown on [1] - and it isn't readily apparent why it was changed, as presumably information from cdroms could easily have been extracted into /mnt/dists from /mnt/cdrom? After then, it spent a bunch of years being hard-coded, until on the 22nd of January, 1997 when it was changed to fix media initialization, as shown on [2]. Media initialization then got moved, along with the rest of sysinstall, with [3], where it spent its days until [4] where nwhitehorn@ gave it a proper sendoff. So my proposal is this: Do we remove /cdrom from hier(7), because at this point nobody should've been using it some time after 1997, or do we keep it around since people might still be using it? Yours hopefully, Daniel Ebdrup Jensen [1]: https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& [2]: https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 [3]: https://svnweb.freebsd.org/changeset/base/71150 [4]: https://svnweb.freebsd.org/changeset/base/225937 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl6z77pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rPcQf/eg30s/F52ksWklaeiEsPuX7o4r7uLDLhZ1jbm2lOlbja5k5Ru2q0oBas sqrf6JKHB64YT8uXaUPHzG3AbPr+mm+1Wz4OdfrqTclR/06a81xLo4c5KXVQNKhg Cl4sU7tkl/mOM2eFRFiUuTWiOTj9gDGzi3xfSGIctnLmR+sK8VtW9zrrlqVoOsbz KcNULPbVGP16gx9NrUAHBNX02IUuZG98v8MtejuJeP/sWspiO7XepfPUapaj2Y9d XDuWHLuwUjkNIS9RWfJgunuPtZpFFXG3jj/eYXycThmIXnD6y2ho1D4ts+fPGb13 WtuejhyzaCmDDGLwIqBrbrOjoNyegw== =c/HI -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-hackers@freebsd.org Thu May 7 16:26:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 43D9F2DD5BA for ; Thu, 7 May 2020 16:26:36 +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 49HzP762lYz4Ml8 for ; Thu, 7 May 2020 16:26:35 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.nyi.freebsd.org (Postfix) id CF5AB2DD5B9; Thu, 7 May 2020 16:26:35 +0000 (UTC) Delivered-To: hackers@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 CF23B2DD5B8 for ; Thu, 7 May 2020 16:26:35 +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 49HzP72l5Xz4Ml7; Thu, 7 May 2020 16:26:34 +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 047GQQKs048672; Thu, 7 May 2020 09:26:26 -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 047GQQH1048671; Thu, 7 May 2020 09:26:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> Subject: Re: Regarding /cdrom in hier(7) In-Reply-To: <20200507112346.GA53286@freefall.freebsd.org> To: Daniel Ebdrup Jensen Date: Thu, 7 May 2020 09:26:26 -0700 (PDT) CC: hackers@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: 49HzP72l5Xz4Ml7 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 16:26:36 -0000 > After a bit of a long conversation on IRC, I've concluded that perhaps > it's time for the /cdrom entry in hier(7) to be sent off to better > pastures. > > It's got a bit of a weird history where, before it was implemented, > sysinstall used /mnt/dists until that was changed on the 22nd of May > 1995, as shown on [1] - and it isn't readily apparent why it was > changed, as presumably information from cdroms could easily have been > extracted into /mnt/dists from /mnt/cdrom? > > After then, it spent a bunch of years being hard-coded, until on > the 22nd of January, 1997 when it was changed to fix media > initialization, as shown on [2]. > > Media initialization then got moved, along with the rest of > sysinstall, with [3], where it spent its days until [4] where > nwhitehorn@ gave it a proper sendoff. > > So my proposal is this: Do we remove /cdrom from hier(7), because at > this point nobody should've been using it some time after 1997, or do > we keep it around since people might still be using it? > > Yours hopefully, > Daniel Ebdrup Jensen > > [1]: https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& > [2]: https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 > [3]: https://svnweb.freebsd.org/changeset/base/71150 > [4]: https://svnweb.freebsd.org/changeset/base/225937 It is time to go, BUTT you need to clean up more than just hier(7), as this like most changes in FreeBSD is a weed and it has roots all over the place: :root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom ./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database foo ./man1/locate.1.gz:.Pa /cdrom/locate.database . ./man1/cdcontrol.1.gz:.Pa /dev/cdrom , ./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi ./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom ./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom ./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom ./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 /cdrom" ./man5/devfs.conf.5.gz:.Pa /dev/cdrom ./man5/devfs.conf.5.gz:.Pa /dev/cdrom ./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 -mask 255.255.255.0 ./man5/exports.5.gz:.Pa /cdrom ./man5/exports.5.gz:.Pa /cdrom ./man5/exports.5.gz:.Pa /cdrom ./man5/exports.5.gz:.Pa /cdrom , ./man5/exports.5.gz:.Pa /cdrom ./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto 0 0 ./man7/hier.7.gz:.It Pa /cdrom/ -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu May 7 17:45:57 2020 Return-Path: Delivered-To: freebsd-hackers@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 3851A2DF928 for ; Thu, 7 May 2020 17:45:57 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49J18j0prSz4TNf for ; Thu, 7 May 2020 17:45:57 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1BD4E2DF927; Thu, 7 May 2020 17:45:57 +0000 (UTC) Delivered-To: hackers@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 1B9AE2DF926 for ; Thu, 7 May 2020 17:45:57 +0000 (UTC) (envelope-from debdrup@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 49J18h72wDz4TNd for ; Thu, 7 May 2020 17:45:56 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Received: from nerd-thinkpad.local (unknown [85.27.246.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: debdrup) by smtp.freebsd.org (Postfix) with ESMTPSA id A63F5529B for ; Thu, 7 May 2020 17:45:56 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Date: Thu, 7 May 2020 19:45:54 +0200 From: Daniel Ebdrup Jensen To: hackers@freebsd.org Subject: Re: Regarding /cdrom in hier(7) Message-ID: <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@freebsd.org References: <20200507112346.GA53286@freefall.freebsd.org> <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rinasj5emo2qelua" Content-Disposition: inline In-Reply-To: <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 17:45:57 -0000 --rinasj5emo2qelua Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 07, 2020 at 09:26:26AM -0700, Rodney W. Grimes wrote: >> After a bit of a long conversation on IRC, I've concluded that perhaps >> it's time for the /cdrom entry in hier(7) to be sent off to better >> pastures. >> >> It's got a bit of a weird history where, before it was implemented, >> sysinstall used /mnt/dists until that was changed on the 22nd of May >> 1995, as shown on [1] - and it isn't readily apparent why it was >> changed, as presumably information from cdroms could easily have been >> extracted into /mnt/dists from /mnt/cdrom? >> >> After then, it spent a bunch of years being hard-coded, until on >> the 22nd of January, 1997 when it was changed to fix media >> initialization, as shown on [2]. >> >> Media initialization then got moved, along with the rest of >> sysinstall, with [3], where it spent its days until [4] where >> nwhitehorn@ gave it a proper sendoff. >> >> So my proposal is this: Do we remove /cdrom from hier(7), because at >> this point nobody should've been using it some time after 1997, or do >> we keep it around since people might still be using it? >> >> Yours hopefully, >> Daniel Ebdrup Jensen >> >> [1]: https://svnweb.freebsd.org/base/head/release/sysinstall/media_strat= egy.c?r1=3D8701&r2=3D8702&pathrev=3D8790& >> [2]: https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?rev= ision=3D21937&view=3Dmarkup&pathrev=3D21937 >> [3]: https://svnweb.freebsd.org/changeset/base/71150 >> [4]: https://svnweb.freebsd.org/changeset/base/225937 > > >It is time to go, BUTT you need to clean up more than just hier(7), >as this like most changes in FreeBSD is a weed and it has roots >all over the place: > >:root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom >./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database foo >./man1/locate.1.gz:.Pa /cdrom/locate.database . >./man1/cdcontrol.1.gz:.Pa /dev/cdrom , >./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi >./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom >./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom >./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom >./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 /cdrom" >./man5/devfs.conf.5.gz:.Pa /dev/cdrom >./man5/devfs.conf.5.gz:.Pa /dev/cdrom >./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 -mask 2= 55.255.255.0 >./man5/exports.5.gz:.Pa /cdrom >./man5/exports.5.gz:.Pa /cdrom >./man5/exports.5.gz:.Pa /cdrom >./man5/exports.5.gz:.Pa /cdrom , >./man5/exports.5.gz:.Pa /cdrom >./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto 0 = 0 >./man7/hier.7.gz:.It Pa /cdrom/ > >--=20 >Rod Grimes rgrimes@freebsd= =2Eorg Thanks, Rod. That's why I thought I'd ask first, because I knew it was not just the man-= page=20 that needed tending to - though I see you've found even more instances than= I=20 did in a quick grep through things. I'll make a note of all the places, the= n=20 wait a bit longer to see if anyone has anything to say on the topic, then s= et to it. Hopefully I'll get around to it some time before hedgehogs start hibernatin= g. :) Yours respectfully, Daniel Ebdrup Jensen --rinasj5emo2qelua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl60SUtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pOgAf7BlZV9xORYX3EvWOFrTBlqE9hDQpYB3jnFUc3i8mN8/UTPEIKANIXE0O0 zUOf5MiOx/veVYrcOei446+dJDjCyf2nyIiR9v4Yf9EvsVrmNlF5M0iNxHkjdR3s hsbqK0dQ7PMQaOmw0kazYqqQ2VBJH70WGuWkMbQ5I6wB1uJc002OqR8p2Lv95O4G qZQvwUY0q6I1X72W2rv0344R1r2X+hHCvIiqYsIRwGUqdsBqN2sJ018rfK5C8YRO jFss9z+EbkorIA6w3Qe1nmav7+oE8vjYuTrTua7RGpI00h6ep0maprX2lQ1ipzM4 eTCcJSQ6RyqTJllyjKl+IzbhgITuWQ== =ipta -----END PGP SIGNATURE----- --rinasj5emo2qelua-- From owner-freebsd-hackers@freebsd.org Thu May 7 18:01:00 2020 Return-Path: Delivered-To: freebsd-hackers@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 E1B392DFEF4 for ; Thu, 7 May 2020 18:01:00 +0000 (UTC) (envelope-from wlosh@bsdimp.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 49J1V43zJsz4VVv for ; Thu, 7 May 2020 18:01:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 8862E2DFEF3; Thu, 7 May 2020 18:01:00 +0000 (UTC) Delivered-To: hackers@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 882812DFEF2 for ; Thu, 7 May 2020 18:01:00 +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 49J1V406tzz4VVt for ; Thu, 7 May 2020 18:00:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72b.google.com with SMTP id q7so7113214qkf.3 for ; Thu, 07 May 2020 11:00:59 -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; bh=c53ajApmQ/zHPDy3RiN3YKCHD6NENGfiB1cVrJNjRRc=; b=U9FVM3M+ejFXM8+QN5EGHs68oCY0QZyiDyG55UjBdiX5KuK9lWRV5dh2407poLDNbG 467KFYEWTXkX3Q1MCvqQBNOi+B9rvShaxngrmUe+5wVAQOZY18ZfGlkCZr2YogVkiw63 pPvkm2P7wX//oqxF0yCu84ivmsSA6D7v7Jc3SyeTUIU/52kvwIq5GSjtfz4zu2Yst7/Z 0EP9SfPKm+sRM1KL1qB7h1kjmjuR6B5il0E0VjD3oRO8PNsvZmqvMpsO43H6m4SZVyzS PGYOox9su2humaxBT/ZAztjcpGBglSMgs4MFnFtW02qYLz2wuh2KjBaaNGYIa5C20lfm n1lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c53ajApmQ/zHPDy3RiN3YKCHD6NENGfiB1cVrJNjRRc=; b=ChGLUXZ8xJN63UBrenRuZYq4Ky37pMJf6ntN5VNR/H+9loHNeVruiP7Jssx50Lt5O0 1KyxCWrnmIpDydHvmfZW804F2N1Lq6yXNbSniDV6y9nTTm+yjXwpgNMb3zkkv61FOAb+ pUevebeJvmLnEL8ZKOgZhfe3f9+R3uHwTCqcVKBdMp/0O6BVd2Eu7vl+5h3o44+w0h+n vj8iVv8AONuMznEpNta76bsqGYdqSbMjyLdRYkmXTX0IzFvLgIxOxki/IaJc934F1iZf 7LTnk4LTlNZSmNDqUurYb/WXD3PvTlMwuI6rvACv8sWdM+6CINI32AgNxMoJhHVV8oLq FE/g== X-Gm-Message-State: AGi0PuZEj/h37fo+AwIBHiTdn/bS16j6FWCs2Y7i2oFwQSwziKAQD08d 2NkIwv+dD0xYhorlTfzp/U2w+iEKDJ4FcrTw1S/vyA== X-Google-Smtp-Source: APiQypIt7SrtB3Pr4RIgL5IvHENkGlo5Eo5/+8YU481eSyKwIR89Ks4kGqwVPeFvvZ/20vFENDN+Kc5/63y+iZCdNic= X-Received: by 2002:a37:a9d6:: with SMTP id s205mr14188819qke.380.1588874458943; Thu, 07 May 2020 11:00:58 -0700 (PDT) MIME-Version: 1.0 References: <20200507112346.GA53286@freefall.freebsd.org> <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> In-Reply-To: <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> From: Warner Losh Date: Thu, 7 May 2020 12:00:47 -0600 Message-ID: Subject: Re: Regarding /cdrom in hier(7) To: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49J1V406tzz4VVt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=U9FVM3M+; 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)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@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)[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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:01:00 -0000 On Thu, May 7, 2020 at 11:46 AM Daniel Ebdrup Jensen wrote: > On Thu, May 07, 2020 at 09:26:26AM -0700, Rodney W. Grimes wrote: > >> After a bit of a long conversation on IRC, I've concluded that perhaps > >> it's time for the /cdrom entry in hier(7) to be sent off to better > >> pastures. > >> > >> It's got a bit of a weird history where, before it was implemented, > >> sysinstall used /mnt/dists until that was changed on the 22nd of May > >> 1995, as shown on [1] - and it isn't readily apparent why it was > >> changed, as presumably information from cdroms could easily have been > >> extracted into /mnt/dists from /mnt/cdrom? > >> > >> After then, it spent a bunch of years being hard-coded, until on > >> the 22nd of January, 1997 when it was changed to fix media > >> initialization, as shown on [2]. > >> > >> Media initialization then got moved, along with the rest of > >> sysinstall, with [3], where it spent its days until [4] where > >> nwhitehorn@ gave it a proper sendoff. > >> > >> So my proposal is this: Do we remove /cdrom from hier(7), because at > >> this point nobody should've been using it some time after 1997, or do > >> we keep it around since people might still be using it? > >> > >> Yours hopefully, > >> Daniel Ebdrup Jensen > >> > >> [1]: > https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& > >> [2]: > https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 > >> [3]: https://svnweb.freebsd.org/changeset/base/71150 > >> [4]: https://svnweb.freebsd.org/changeset/base/225937 > > > > > >It is time to go, BUTT you need to clean up more than just hier(7), > >as this like most changes in FreeBSD is a weed and it has roots > >all over the place: > > > >:root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom > >./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database foo > >./man1/locate.1.gz:.Pa /cdrom/locate.database . > >./man1/cdcontrol.1.gz:.Pa /dev/cdrom , > >./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi > >./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom > >./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom > >./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom > >./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 /cdrom" > >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 -mask > 255.255.255.0 > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom , > >./man5/exports.5.gz:.Pa /cdrom > >./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto > 0 0 > >./man7/hier.7.gz:.It Pa /cdrom/ > > > >-- > >Rod Grimes > rgrimes@freebsd.org > > Thanks, Rod. > > That's why I thought I'd ask first, because I knew it was not just the > man-page > that needed tending to - though I see you've found even more instances > than I > did in a quick grep through things. I'll make a note of all the places, > then > wait a bit longer to see if anyone has anything to say on the topic, then > set to it. > > Hopefully I'll get around to it some time before hedgehogs start > hibernating. :) > The handbook also has a lot of references too: % cd doc/head % grep -r /cdrom en_US.ISO8859-1/ | grep -v cdrom.com | wc 478 1457 56420 Warner From owner-freebsd-hackers@freebsd.org Thu May 7 18:06:21 2020 Return-Path: Delivered-To: freebsd-hackers@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 9687F2E028B for ; Thu, 7 May 2020 18:06:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) 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 49J1cF1LR4z4Vwr for ; Thu, 7 May 2020 18:06:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.nyi.freebsd.org (Postfix) id 2C3862E028A; Thu, 7 May 2020 18:06:21 +0000 (UTC) Delivered-To: hackers@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 2BFEA2E0289 for ; Thu, 7 May 2020 18:06:21 +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 49J1cD5h4Bz4Vwq; Thu, 7 May 2020 18:06:20 +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 047I6IKv049185; Thu, 7 May 2020 11:06:18 -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 047I6ISS049184; Thu, 7 May 2020 11:06:18 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005071806.047I6ISS049184@gndrsh.dnsmgr.net> Subject: Re: Regarding /cdrom in hier(7) In-Reply-To: <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> To: Daniel Ebdrup Jensen Date: Thu, 7 May 2020 11:06:18 -0700 (PDT) CC: hackers@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: 49J1cD5h4Bz4Vwq 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:06:21 -0000 > On Thu, May 07, 2020 at 09:26:26AM -0700, Rodney W. Grimes wrote: > >> After a bit of a long conversation on IRC, I've concluded that perhaps > >> it's time for the /cdrom entry in hier(7) to be sent off to better > >> pastures. > >> > >> It's got a bit of a weird history where, before it was implemented, > >> sysinstall used /mnt/dists until that was changed on the 22nd of May > >> 1995, as shown on [1] - and it isn't readily apparent why it was > >> changed, as presumably information from cdroms could easily have been > >> extracted into /mnt/dists from /mnt/cdrom? > >> > >> After then, it spent a bunch of years being hard-coded, until on > >> the 22nd of January, 1997 when it was changed to fix media > >> initialization, as shown on [2]. > >> > >> Media initialization then got moved, along with the rest of > >> sysinstall, with [3], where it spent its days until [4] where > >> nwhitehorn@ gave it a proper sendoff. > >> > >> So my proposal is this: Do we remove /cdrom from hier(7), because at > >> this point nobody should've been using it some time after 1997, or do > >> we keep it around since people might still be using it? > >> > >> Yours hopefully, > >> Daniel Ebdrup Jensen > >> > >> [1]: https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& > >> [2]: https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 > >> [3]: https://svnweb.freebsd.org/changeset/base/71150 > >> [4]: https://svnweb.freebsd.org/changeset/base/225937 > > > > > >It is time to go, BUTT you need to clean up more than just hier(7), > >as this like most changes in FreeBSD is a weed and it has roots > >all over the place: > > > >:root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom > >./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database foo > >./man1/locate.1.gz:.Pa /cdrom/locate.database . > >./man1/cdcontrol.1.gz:.Pa /dev/cdrom , > >./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi > >./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom > >./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom > >./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom > >./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 /cdrom" > >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 -mask 255.255.255.0 > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom > >./man5/exports.5.gz:.Pa /cdrom , > >./man5/exports.5.gz:.Pa /cdrom > >./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto 0 0 > >./man7/hier.7.gz:.It Pa /cdrom/ > > > >-- > >Rod Grimes rgrimes@freebsd.org > > Thanks, Rod. > > That's why I thought I'd ask first, because I knew it was not just the man-page > that needed tending to - though I see you've found even more instances than I > did in a quick grep through things. I'll make a note of all the places, then > wait a bit longer to see if anyone has anything to say on the topic, then set to it. > > Hopefully I'll get around to it some time before hedgehogs start hibernating. :) You might want to run: :root {1010}# find /usr/src/ -type f | xargs grep -i /cdrom > > Yours respectfully, > Daniel Ebdrup Jensen -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu May 7 18:08:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 11B7C2E03E0 for ; Thu, 7 May 2020 18:08:47 +0000 (UTC) (envelope-from debdrup@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 49J1g25Bqvz4W5k for ; Thu, 7 May 2020 18:08:46 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id B22732E03DF; Thu, 7 May 2020 18:08:46 +0000 (UTC) Delivered-To: hackers@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 B1EA52E03DE for ; Thu, 7 May 2020 18:08:46 +0000 (UTC) (envelope-from debdrup@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 49J1g24FrGz4W5j for ; Thu, 7 May 2020 18:08:46 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Received: from nerd-thinkpad.local (unknown [85.27.246.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: debdrup) by smtp.freebsd.org (Postfix) with ESMTPSA id 2B85854F9 for ; Thu, 7 May 2020 18:08:46 +0000 (UTC) (envelope-from debdrup@FreeBSD.org) Date: Thu, 7 May 2020 20:08:44 +0200 From: Daniel Ebdrup Jensen To: "freebsd-hackers@freebsd.org" Subject: Re: Regarding /cdrom in hier(7) Message-ID: <20200507180844.7kb5hdn7awqejsay@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" References: <20200507112346.GA53286@freefall.freebsd.org> <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7lf3v42qvu7zphzz" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:08:47 -0000 --7lf3v42qvu7zphzz Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Thu, May 07, 2020 at 12:00:47PM -0600, Warner Losh wrote: >On Thu, May 7, 2020 at 11:46 AM Daniel Ebdrup Jensen >wrote: > >> On Thu, May 07, 2020 at 09:26:26AM -0700, Rodney W. Grimes wrote: >> >> After a bit of a long conversation on IRC, I've concluded that perhaps >> >> it's time for the /cdrom entry in hier(7) to be sent off to better >> >> pastures. >> >> >> >> It's got a bit of a weird history where, before it was implemented, >> >> sysinstall used /mnt/dists until that was changed on the 22nd of May >> >> 1995, as shown on [1] - and it isn't readily apparent why it was >> >> changed, as presumably information from cdroms could easily have been >> >> extracted into /mnt/dists from /mnt/cdrom? >> >> >> >> After then, it spent a bunch of years being hard-coded, until on >> >> the 22nd of January, 1997 when it was changed to fix media >> >> initialization, as shown on [2]. >> >> >> >> Media initialization then got moved, along with the rest of >> >> sysinstall, with [3], where it spent its days until [4] where >> >> nwhitehorn@ gave it a proper sendoff. >> >> >> >> So my proposal is this: Do we remove /cdrom from hier(7), because at >> >> this point nobody should've been using it some time after 1997, or do >> >> we keep it around since people might still be using it? >> >> >> >> Yours hopefully, >> >> Daniel Ebdrup Jensen >> >> >> >> [1]: >> https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& >> >> [2]: >> https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 >> >> [3]: https://svnweb.freebsd.org/changeset/base/71150 >> >> [4]: https://svnweb.freebsd.org/changeset/base/225937 >> > >> > >> >It is time to go, BUTT you need to clean up more than just hier(7), >> >as this like most changes in FreeBSD is a weed and it has roots >> >all over the place: >> > >> >:root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom >> >./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database foo >> >./man1/locate.1.gz:.Pa /cdrom/locate.database . >> >./man1/cdcontrol.1.gz:.Pa /dev/cdrom , >> >./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi >> >./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom >> >./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom >> >./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom >> >./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 /cdrom" >> >./man5/devfs.conf.5.gz:.Pa /dev/cdrom >> >./man5/devfs.conf.5.gz:.Pa /dev/cdrom >> >./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 -mask >> 255.255.255.0 >> >./man5/exports.5.gz:.Pa /cdrom >> >./man5/exports.5.gz:.Pa /cdrom >> >./man5/exports.5.gz:.Pa /cdrom >> >./man5/exports.5.gz:.Pa /cdrom , >> >./man5/exports.5.gz:.Pa /cdrom >> >./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto >> 0 0 >> >./man7/hier.7.gz:.It Pa /cdrom/ >> > >> >-- >> >Rod Grimes >> rgrimes@freebsd.org >> >> Thanks, Rod. >> >> That's why I thought I'd ask first, because I knew it was not just the >> man-page >> that needed tending to - though I see you've found even more instances >> than I >> did in a quick grep through things. I'll make a note of all the places, >> then >> wait a bit longer to see if anyone has anything to say on the topic, then >> set to it. >> >> Hopefully I'll get around to it some time before hedgehogs start >> hibernating. :) >> > >The handbook also has a lot of references too: > >% cd doc/head >% grep -r /cdrom en_US.ISO8859-1/ | grep -v cdrom.com | wc > 478 1457 56420 > >Warner Fair enough, maybe it'll be some time after hedgehogs stop hibernating then. ;) Yours, Daniel Ebdrup Jensen. --7lf3v42qvu7zphzz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl60TqVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rKqgf+J/rcIm92JhUenIN1YZ7c8/iCF1y/7sCySvrRrVcLdQ9+M0Ly+9TPwzbI OYZX0wXxIEAu19Yird+Y8flAnVgq+IgByrfm+qXTndtH0vB4y3aNZVYHuy6z/oex Z0DiqeNamk5ii3rwfua1ev4TO4kFqejvdheToEAV/UrTDDHzvBH7ydd4m1BqI6tq SVNPzrumQpf9aAbaxOFGDGJGR3KhrxmK75zZ81IZq1WFZeFzZz21hUT2iyhpvaa0 z5z2lXQ8hteUN+2dqiuH3V+8PGDO+32VfmsyxQxMdATLVYU3jVL/oPqO9y6oaLvu R1DnUhzywgYAtYWIeRfIkb572nN2fA== =n9mj -----END PGP SIGNATURE----- --7lf3v42qvu7zphzz-- From owner-freebsd-hackers@freebsd.org Thu May 7 18:10:32 2020 Return-Path: Delivered-To: freebsd-hackers@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 B4EAC2E054A for ; Thu, 7 May 2020 18:10:32 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 49J1j361pRz4WFw for ; Thu, 7 May 2020 18:10:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id j8so1567400iog.13 for ; Thu, 07 May 2020 11:10:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yF2qF3cGcG4yKnZWJMFSfpNJRndHuOI4W0e3T4cZ8fE=; b=F4LhJhy6GgGWSzv8BOJbcQoBr+OYNESGdQHCpsj0oZvTTKjoh/bDIH3gTGkqDn1V2q AKvpRoac3FRe9xJ4tnpFLuX/PfNsotLo02tpQhs5FLh5o1EmSygrW7iqBq/ZIjZeIxWy 6eSMjeCJ0NTnFJQ/DCsMQ3k5+3UeqFNOIMt12OoqTH1deLLfpTyx9Vrk4VSFVoKIDPYr hpdQ88IhU7HPwJYD01aeiLL/FzwKe5+dOXEuB5OTF+GpUvGk6RFH2o6BrGncRGCv7kYE kMiLGUEFDOJk9Ac9D5WxkTGFHcQSQ9j2Xqy76KuE71/O2NE4FmEmSH42gcI+etk7LXfa uEAw== X-Gm-Message-State: AGi0PuZjYlFPFpwWytD64RpdWaVBAsVoSITTB+gaeH1NdnrdaduB53sh Nk5vx0RoaIvwvszKNuUF1qKMoI4VPzVVrZ4w1hOEG8BQ X-Google-Smtp-Source: APiQypK28uNyPBffYQu4fAcuHcY49Q9ruqmy2f1WK7DyJ+g4kDDocwGaeseaywgYgEXyu9aOo+fX+NtlW6iilIlnEz0= X-Received: by 2002:a5e:c303:: with SMTP id a3mr6753975iok.15.1588875030578; Thu, 07 May 2020 11:10:30 -0700 (PDT) MIME-Version: 1.0 References: <453259393.837.1588660255688.JavaMail.www@wwinf1m04> In-Reply-To: <453259393.837.1588660255688.JavaMail.www@wwinf1m04> From: Ed Maste Date: Thu, 7 May 2020 14:10:17 -0400 Message-ID: Subject: Re: Call for testers - Valgrind To: Paul FLOYD Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49J1j361pRz4WFw 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.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[48.166.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.45)[ip: (-6.37), ipnet: 209.85.128.0/17(-0.39), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_TO(0.00)[wanadoo.fr]; RWL_MAILSPIKE_POSSIBLE(0.00)[48.166.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)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:10:32 -0000 On Tue, 5 May 2020 at 02:31, Paul FLOYD wrote: > > Hi > > I've done a lot of work since the start of the year trying to reboot Valgrind on FreeBSD. Whilst there is still a way to go, the results are looking promising. Thank you very much for picking this up! > I'd like to get some feedback, in particular from developers that use debug versions of Qt and libc and who are capable of telling whether any errors produced are false positives or not. I'll try to take a look at libc. > Supported Platforms > ~~~~~~~~~~~~~ > I've set up VirtualBox VMs as far back as FreeBSD 10 and tested that at least everything builds. I've been doing fairly extensive testing (with Valgrind's own regression suite) on 12.1 amd64 > and i386. I'll set up a 13.0-CURRENT VM soon to ensure that I'm ready for the next release. How are Valgrind's test results looking? > 4. There are still numerous missing syscalls. Do we have a list of the missing ones? From owner-freebsd-hackers@freebsd.org Thu May 7 18:10:45 2020 Return-Path: Delivered-To: freebsd-hackers@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 0BF4F2E0591 for ; Thu, 7 May 2020 18:10:45 +0000 (UTC) (envelope-from wlosh@bsdimp.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 49J1jJ5TK8z4WS3 for ; Thu, 7 May 2020 18:10:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id BBD602E058C; Thu, 7 May 2020 18:10:44 +0000 (UTC) Delivered-To: hackers@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 BB9742E058B for ; Thu, 7 May 2020 18:10:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 49J1jH5J3kz4WRl for ; Thu, 7 May 2020 18:10:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id 4so892433qtb.4 for ; Thu, 07 May 2020 11:10:43 -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; bh=FMBPJp3xURRHExRRPd/q5st67PTDugo07eBdrDJDt6I=; b=qezNsHno2hZbr6CxWIciylwJS8/eUjQ8lT0HQ9sizqpunBa6zwiAC7+2pK3nywHENy UQIxX290eUq06VGG/XtTu533Oh7kEHOOiSkEjPC1A604Pkg2C2T25m92ubMQbcEfAEYk tXOk//+bPHQpNwt5rjZaQnCIGmVvgGzNLdArAK7Sws1vmfWF+fkUp7qAJHDLOoB8rq8V Jr3MH7qvQ7SVr+zGXwkblXlscqLvuY9Ws65rd6o+0/E2MxaypEwZy/I4SAH07FaZMXWM 9dVG8Eae+y5vnY+uLrdaIxjqdPagLWAI0qDVJ8s+exs89Nb3sQxssPJ6nVtR9QIO3J7d ECZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FMBPJp3xURRHExRRPd/q5st67PTDugo07eBdrDJDt6I=; b=k5hUD83MSCPPhwo073CXDiZ0FtbG5uNFIrVrNRnJ3Ce7FA5Q0+QpfdAR30vByckhUM gW0i3fKbvO1wLxa7AL27C9b9RjmUP1NkZYIX0wUFiEhOW8DU5Sgd+14yLpdU9oRHi/q6 7lCUedLguPCWqZf68P5eZK3gB9jH9ylKpd4XEX6OMChtitO+f8ojuBKnQRx51986OmfA YZ2Dby7Jdomp5J+xvWiE6LArPrM8vhrpHbi8PzKT0dYCHObrT1q84fju7UJqVshLc31J Gu9QEDDRX8l5eHluJ1No4bAJWo29w3vrrFQGy7J4M8uW9obZk80sJRiOEueJq3Oj9bxV asxA== X-Gm-Message-State: AGi0PuaKY6JWtoM3lv64IEit8askVPG6a4jr4c6y5VRseXO17nFJcgmD Te2qnbOs6B9b9t3mweYb+ESFUNSL19ApxO7ZIt0RRw== X-Google-Smtp-Source: APiQypK3+0fq/gM8HYEvgyMEV8GT33ZwcDrUAtGPxKAvKClliSTm5GjGFyys4GHSYaVxhMJqlX1Lq51tWYgfdTWEw9I= X-Received: by 2002:ac8:35cc:: with SMTP id l12mr15768022qtb.291.1588875041912; Thu, 07 May 2020 11:10:41 -0700 (PDT) MIME-Version: 1.0 References: <20200507112346.GA53286@freefall.freebsd.org> <202005071626.047GQQH1048671@gndrsh.dnsmgr.net> <20200507174554.3agocyzveprspnyi@nerd-thinkpad.local> <20200507180844.7kb5hdn7awqejsay@nerd-thinkpad.local> In-Reply-To: <20200507180844.7kb5hdn7awqejsay@nerd-thinkpad.local> From: Warner Losh Date: Thu, 7 May 2020 12:10:29 -0600 Message-ID: Subject: Re: Regarding /cdrom in hier(7) To: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49J1jH5J3kz4WRl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=qezNsHno; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::833) smtp.mailfrom=wlosh@bsdimp.com 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)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@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)[3.3.8.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.00)[ip: (-9.18), 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:10:45 -0000 On Thu, May 7, 2020 at 12:08 PM Daniel Ebdrup Jensen wrote: > On Thu, May 07, 2020 at 12:00:47PM -0600, Warner Losh wrote: > >On Thu, May 7, 2020 at 11:46 AM Daniel Ebdrup Jensen > > >wrote: > > > >> On Thu, May 07, 2020 at 09:26:26AM -0700, Rodney W. Grimes wrote: > >> >> After a bit of a long conversation on IRC, I've concluded that > perhaps > >> >> it's time for the /cdrom entry in hier(7) to be sent off to better > >> >> pastures. > >> >> > >> >> It's got a bit of a weird history where, before it was implemented, > >> >> sysinstall used /mnt/dists until that was changed on the 22nd of May > >> >> 1995, as shown on [1] - and it isn't readily apparent why it was > >> >> changed, as presumably information from cdroms could easily have been > >> >> extracted into /mnt/dists from /mnt/cdrom? > >> >> > >> >> After then, it spent a bunch of years being hard-coded, until on > >> >> the 22nd of January, 1997 when it was changed to fix media > >> >> initialization, as shown on [2]. > >> >> > >> >> Media initialization then got moved, along with the rest of > >> >> sysinstall, with [3], where it spent its days until [4] where > >> >> nwhitehorn@ gave it a proper sendoff. > >> >> > >> >> So my proposal is this: Do we remove /cdrom from hier(7), because at > >> >> this point nobody should've been using it some time after 1997, or do > >> >> we keep it around since people might still be using it? > >> >> > >> >> Yours hopefully, > >> >> Daniel Ebdrup Jensen > >> >> > >> >> [1]: > >> > https://svnweb.freebsd.org/base/head/release/sysinstall/media_strategy.c?r1=8701&r2=8702&pathrev=8790& > >> >> [2]: > >> > https://svnweb.freebsd.org/base/head/release/sysinstall/cdrom.c?revision=21937&view=markup&pathrev=21937 > >> >> [3]: https://svnweb.freebsd.org/changeset/base/71150 > >> >> [4]: https://svnweb.freebsd.org/changeset/base/225937 > >> > > >> > > >> >It is time to go, BUTT you need to clean up more than just hier(7), > >> >as this like most changes in FreeBSD is a weed and it has roots > >> >all over the place: > >> > > >> >:root {1007}# find /usr/share/man -type f | xargs zgrep -i /cdrom > >> >./man1/locate.1.gz:$ locate -d $HOME/lib/mydb::/cdrom/locate.database > foo > >> >./man1/locate.1.gz:.Pa /cdrom/locate.database . > >> >./man1/cdcontrol.1.gz:.Pa /dev/cdrom , > >> >./man1/recoverdisk.1.gz:recoverdisk /cdrom/file.avi file.avi > >> >./man8/ggatec.8.gz:client# mount_cd9660 /dev/ggate0 /cdrom > >> >./man8/mount.8.gz:mount -t cd9660 -o -e /dev/cd0 /cdrom > >> >./man8/mount.8.gz:/sbin/mount_cd9660 -e /dev/cd0 /cdrom > >> >./man8/mount_cd9660.8.gz:.Dl "mount_cd9660 -o rw -v -s 0 /dev/cd0 > /cdrom" > >> >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >> >./man5/devfs.conf.5.gz:.Pa /dev/cdrom > >> >./man5/exports.5.gz:/cdrom -alldirs,quiet,ro -network 192.168.33.0 > -mask > >> 255.255.255.0 > >> >./man5/exports.5.gz:.Pa /cdrom > >> >./man5/exports.5.gz:.Pa /cdrom > >> >./man5/exports.5.gz:.Pa /cdrom > >> >./man5/exports.5.gz:.Pa /cdrom , > >> >./man5/exports.5.gz:.Pa /cdrom > >> >./man5/fstab.5.gz:/dev/cd0 /cdrom cd9660 ro,noauto > >> 0 0 > >> >./man7/hier.7.gz:.It Pa /cdrom/ > >> > > >> >-- > >> >Rod Grimes > >> rgrimes@freebsd.org > >> > >> Thanks, Rod. > >> > >> That's why I thought I'd ask first, because I knew it was not just the > >> man-page > >> that needed tending to - though I see you've found even more instances > >> than I > >> did in a quick grep through things. I'll make a note of all the places, > >> then > >> wait a bit longer to see if anyone has anything to say on the topic, > then > >> set to it. > >> > >> Hopefully I'll get around to it some time before hedgehogs start > >> hibernating. :) > >> > > > >The handbook also has a lot of references too: > > > >% cd doc/head > >% grep -r /cdrom en_US.ISO8859-1/ | grep -v cdrom.com | wc > > 478 1457 56420 > > > >Warner > > Fair enough, maybe it'll be some time after hedgehogs stop hibernating > then. ;) > Fortunately, most of them are in release notes (which won't change): grep -r /cdrom en_US.ISO8859-1/ | grep -v cdrom.com | grep -v /releases/ | wc 27 148 3473 So it's not too bad. Only 8 articles need to be changed. Warner From owner-freebsd-hackers@freebsd.org Thu May 7 18:16:24 2020 Return-Path: Delivered-To: freebsd-hackers@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 B23042E0A59 for ; Thu, 7 May 2020 18:16:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49J1qr281dz4X1X for ; Thu, 7 May 2020 18:16:24 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: by mailman.nyi.freebsd.org (Postfix) id 47B702E0A57; Thu, 7 May 2020 18:16:24 +0000 (UTC) Delivered-To: hackers@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 477A92E0A56 for ; Thu, 7 May 2020 18:16:24 +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 49J1qq64Dlz4X1W; Thu, 7 May 2020 18:16:23 +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 047IGJPP033638 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 May 2020 11:16:25 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: <20200507112346.GA53286@freefall.freebsd.org> From: Chris Reply-To: bsd-lists@BSDforge.com To: Daniel Ebdrup Jensen Subject: Re: Regarding /cdrom in hier(7) Date: Thu, 07 May 2020 11:16:25 -0700 Message-Id: <3e7c5b0eb9bdba8e6c1ba23f3f34da87@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49J1qq64Dlz4X1W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.81 / 15.00]; NEURAL_HAM_MEDIUM(-0.89)[-0.893,0]; NEURAL_HAM_LONG(-0.92)[-0.916,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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:16:24 -0000 On Thu, 7 May 2020 13:23:46 +0200 Daniel Ebdrup Jensen debdrup@freebsd=2Eorg = said > After a bit of a long conversation on IRC, I've concluded that perhaps > it's time for the /cdrom entry in hier(7) to be sent off to better > pastures=2E >=20 > It's got a bit of a weird history where, before it was implemented, > sysinstall used /mnt/dists until that was changed on the 22nd of May > 1995, as shown on [1] - and it isn't readily apparent why it was > changed, as presumably information from cdroms could easily have been > extracted into /mnt/dists from /mnt/cdrom? >=20 > After then, it spent a bunch of years being hard-coded, until on > the 22nd of January, 1997 when it was changed to fix media > initialization, as shown on [2]=2E >=20 > Media initialization then got moved, along with the rest of > sysinstall, with [3], where it spent its days until [4] where > nwhitehorn@ gave it a proper sendoff=2E >=20 > So my proposal is this: Do we remove /cdrom from hier(7), because at > this point nobody should've been using it some time after 1997, or do > we keep it around since people might still be using it? Paint it blue! ;-) On a more serious note=2E IMHO, if it counts, would be to nuke it=2E Doesn't /media && /mnt already cover it's intended use case? Even if some, even if many, still depend on it=2E It's fairly trivial to add it to fstab(5)=2E No? --Chris P=2ES=2E Thanks for the history, Daniel=2E :-) I can still remember installing over a modem, and juggling floppy disks -- whew! Glad those days are over=2E :-) >=20 > Yours hopefully, > Daniel Ebdrup Jensen >=20 > [1]: > https://svnweb=2Efreebsd=2Eorg/base/head/release/sysinstall/media_strategy=2Ec?= r1=3D8701&r2=3D8702&pathrev=3D8790& > [2]: > https://svnweb=2Efreebsd=2Eorg/base/head/release/sysinstall/cdrom=2Ec?revision= =3D21937&view=3Dmarkup&pathrev=3D21937 > [3]: https://svnweb=2Efreebsd=2Eorg/changeset/base/71150 > [4]: https://svnweb=2Efreebsd=2Eorg/changeset/base/225937 From owner-freebsd-hackers@freebsd.org Thu May 7 19:06:38 2020 Return-Path: Delivered-To: freebsd-hackers@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 C23D32E1E9F 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 49J2xn1tYkz4Zqf 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: 49J2xn1tYkz4Zqf 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-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Thu May 7 20:13:58 2020 Return-Path: Delivered-To: freebsd-hackers@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 696292E420F for ; Thu, 7 May 2020 20:13:58 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J4RT1Vrjz3C85 for ; Thu, 7 May 2020 20:13:56 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from garrigue.home ([2.7.113.176]) by mwinf5d29 with ME id bwDu220033oQd2y03wDuv8; Thu, 07 May 2020 22:13:54 +0200 X-ME-Helo: garrigue.home X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Thu, 07 May 2020 22:13:54 +0200 X-ME-IP: 2.7.113.176 From: Paul Floyd 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: Call for testers - Valgrind Date: Thu, 7 May 2020 22:13:53 +0200 References: <453259393.837.1588660255688.JavaMail.www@wwinf1m04> To: FreeBSD Hackers In-Reply-To: Message-Id: <02D4832B-4BEB-440D-879F-DB625E4CE946@wanadoo.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49J4RT1Vrjz3C85 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.128) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [3.38 / 15.00]; FREEMAIL_FROM(0.00)[wanadoo.fr]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[176.113.7.2.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.37), ipnet: 80.12.240.0/20(1.72), asn: 3215(2.40), country: FR(-0.00)]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.98)[0.978,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[128.242.12.80.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[128.242.12.80.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 20:13:58 -0000 Hi Ed > On 7 May 2020, at 20:10, Ed Maste wrote: >=20 > On Tue, 5 May 2020 at 02:31, Paul FLOYD wrote: >>=20 >> Hi >>=20 >> I've done a lot of work since the start of the year trying to reboot = Valgrind on FreeBSD. Whilst there is still a way to go, the results are = looking promising. >=20 > Thank you very much for picking this up! >=20 >> I'd like to get some feedback, in particular from developers that use = debug versions of Qt and libc and who are capable of telling whether any = errors produced are false positives or not. >=20 > I'll try to take a look at libc. >=20 >> Supported Platforms >> ~~~~~~~~~~~~~ >> I've set up VirtualBox VMs as far back as FreeBSD 10 and tested that = at least everything builds. I've been doing fairly extensive testing = (with Valgrind's own regression suite) on 12.1 amd64 >> and i386. I'll set up a 13.0-CURRENT VM soon to ensure that I'm ready = for the next release. >=20 > How are Valgrind's test results looking? There are around 710 tests for amd64 and around 650 tests for i386. When = everything is compiled with GCC then I get a bit less than 20 failures = on amd64. The figure goes up to about 60 failures for i386 and building = everything with clang. I=E2=80=99m still working through the i386 and = clang related issues. I=E2=80=99m tracking issues on GitHub as they are analysed. >=20 >> 4. There are still numerous missing syscalls. >=20 > Do we have a list of the missing ones? >=20 There=E2=80=99s a fairly large number of syscalls that predate FreeBSD = 10 and are not implemented. Here are the ones added in FreeBSD 10 or = later that aren=E2=80=99t implemented. // futimens 546 // utimensat 547 /* 548 is obsolete numa_getaffinity */ /* 549 is obsolete numa_setaffinity */ // fdatasync 550 // fstatat 552 // fhstat 553 // getdirentries 554 // mknodat 559 // kevent 560 // cpuset_getdomain 561 // cpuset_setdomain 562 // getfhat 564 // fhlink 565 // fhlinkat 566 // fhreadlink 567 A+ Paul= From owner-freebsd-hackers@freebsd.org Fri May 8 15:57:51 2020 Return-Path: Delivered-To: freebsd-hackers@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 63F512DAD5F for ; Fri, 8 May 2020 15:57:51 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 49JZjV4Lxbz3ybB; Fri, 8 May 2020 15:57:50 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-il1-x141.google.com with SMTP id t12so1837808ile.9; Fri, 08 May 2020 08:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jIZQ+/k+nPmUGrC47IQLxry/7K8dBhxqN1FljKfk8ZM=; b=CSeHyzqXkd5t0ValAuC/tV9SiSyAd2HkMrYbFGnaYZzSEranNDt28G9Vz0UZ38BX3F Tk/jZwijOrRuv2RMu0k1e7goqUamsbCCyPZu6wMJ93wpWgLu40uFnlKm9tfCwRxPalAF MHnSZ2TCgkAtJ8Pt+umL+z9FaM5fi/8PrVQH58G8SbuYuYw68xBGZAVFga4dbov09mH5 ss9Su+SsUAalTfepX0sHhWFhBkarhaKGurjdHFff1/ElgpLeC6HriJai2ht7fvQjToRV 4ZdoqeRhrJGJX8495YIF+ELwHjJHJmrHVhd6niqbf9qQ8k+SJ8fIIc38fOjq8/LFWSLx F2Hw== 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=jIZQ+/k+nPmUGrC47IQLxry/7K8dBhxqN1FljKfk8ZM=; b=AASkDLL8Ir9gw2QOZRuZdD77yYIqtYEtKS6kHyOjpdJDULhLcRprKmrZPNhjBIDq71 idHiebJPLpygiOV/dwpNOkHCz8AffLldetiQIvvAROgw4Wi4NaRKgDOLeuR9oJJojBPG GwztXxBIaLYbpaxzjEmfJmC1ysiMztUNeWIfmMDLG0pnQgqtwkzZoScbXRYQ2gp+zCjQ 1JYZQL7iItKy1hYOV6wkoRLFC17axTtO1OnkknTXThK779IWQUsu4hHXvhZZ0OlJAdJp yzaWqPFwN8LccC+NMy7J2wmp00xSBQnRnQhC778sHyJgyV6bz3GxkMH/4eYZT7f6y2Su CxYQ== X-Gm-Message-State: AGi0PubxDYspLbmDiNwhr2/xrX+7710xUyjQp0s85G1BNjP340FX/gLw P7CeERE4t4NCBr8WiSFvuZu67hdGNZSm/bnw2NYq+9TO45s9yg== X-Google-Smtp-Source: APiQypIx3NRzRZFO0QcrAGYqqn+ollsSVHgro9ND1MyWuolDtkvYB/4WsV6IMMgR940xIV57ZATacapbRY/sOJEDuLw= X-Received: by 2002:a92:bf06:: with SMTP id z6mr3275973ilh.191.1588953469364; Fri, 08 May 2020 08:57:49 -0700 (PDT) MIME-Version: 1.0 References: <20200506214611.GD3866@kib.kiev.ua> In-Reply-To: <20200506214611.GD3866@kib.kiev.ua> From: Damjan Jovanovic Date: Fri, 8 May 2020 17:57:24 +0200 Message-ID: Subject: Re: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...] To: Konstantin Belousov Cc: Hackers freeBSD X-Rspamd-Queue-Id: 49JZjV4Lxbz3ybB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CSeHyzqX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of damjanjov@gmail.com designates 2607:f8b0:4864:20::141 as permitted sender) smtp.mailfrom=damjanjov@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; IP_SCORE(0.00)[ip: (0.17), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.1.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]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; 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-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 15:57:51 -0000 On Wed, May 6, 2020 at 11:46 PM Konstantin Belousov wrote: > On Wed, May 06, 2020 at 08:32:08PM +0200, Damjan Jovanovic wrote: > > Hi > > > > Currently "procstat fd [pid]" cannot view anything, even for other > > processes owned by the user making the call, not even their current > working > > directory (CWD), unless it has PGET_CANDEBUG permission. > > > > linprocfs however allows reading the CWD for any process because it > doesn't > > perform that check (sys/compat/linprocfs/linprocfs.c, function > > linprocfs_doproccwd()). > > > > Applications use this, eg. xfce4-terminal relies on > > /compat/linux/proc//cwd to find the shell's CWD, so that when you > open > > a new tab, it starts in the same CWD as the tab you opened it from ( > > > https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343 > ). > > I would like to patch xfce4-terminal to use libprocstat for that instead > of > > needing linprocfs to be mounted, but since procstat is more restrictive, > it > > will break it. > > > > Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so you can > > view the CWD for processes you own? Maybe other open files still need to > be > > hidden, but the CWD doesn't seem like a major security concern. > Can you explain why CANDEBUG vs CANSEE matters for your case ? > Or better, why xfce4-terminal cannot debug shells it spawns ? > Is it suid ? > > xfce4-terminal is a normal process, no suid. It wants to read CWD of the current tab so the new tab opens in the same directory, which is often what you want. On Linux /proc//cwd is lrwxrwxrwx for all processes. On FreeBSD /compat/linux/proc//cwd is lrwxrwxrwx for all procesess. It works as intended at present, as long as you have linprocfs mounted. But I'd rather not have to mount linprocfs. If I patch xfce4-terminal to use libprocstat instead, then it will break, as it needs CANDEBUG to see the CWD, a restriction that seems extreme. > > My initial reaction was that linprocfs should be patched to match FreeBSD > native behaviour instead. > Why does Linux allow everyone to see CWD for all processes? > > > > > Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and only > > hides file descriptors for processes you don't own. > > > > A patch along the following lines could be a start: > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > index 423968b2e1cc..f487232d2cff 100644 > > --- a/sys/kern/kern_descrip.c > > +++ b/sys/kern/kern_descrip.c > > @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS) > > > > sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req); > > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > if (error != 0) { > > sbuf_delete(&sb); > > return (error); > > @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS) > > struct proc *p; > > > > name = (int *)arg1; > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > if (error != 0) > > return (error); > > fdp = fdhold(p); > > > > > > > > > > Thank you > > Damjan > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri May 8 16:14:34 2020 Return-Path: Delivered-To: freebsd-hackers@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 653A32DB643 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 49Jb4m2wjCz40mY 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: 49Jb4m2wjCz40mY 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-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Fri May 8 17:37:05 2020 Return-Path: Delivered-To: freebsd-hackers@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 C6AF62DD325 for ; Fri, 8 May 2020 17:37:05 +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 49Jcw06LBSz45lW; Fri, 8 May 2020 17:37:04 +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 048Hb2TX053937; Fri, 8 May 2020 10:37:02 -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 048Hb2CA053936; Fri, 8 May 2020 10:37:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202005081737.048Hb2CA053936@gndrsh.dnsmgr.net> Subject: Re: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...] In-Reply-To: To: Damjan Jovanovic Date: Fri, 8 May 2020 10:37:02 -0700 (PDT) CC: Konstantin Belousov , Hackers freeBSD 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: 49Jcw06LBSz45lW X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.86 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.29)[0.291,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.03)[ip: (0.12), ipnet: 69.59.192.0/19(0.06), asn: 13868(0.03), country: US(-0.05)]; NEURAL_SPAM_LONG(0.63)[0.633,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:37:05 -0000 > On Wed, May 6, 2020 at 11:46 PM Konstantin Belousov wrote: > > > On Wed, May 06, 2020 at 08:32:08PM +0200, Damjan Jovanovic wrote: > > > Hi > > > > > > Currently "procstat fd [pid]" cannot view anything, even for other > > > processes owned by the user making the call, not even their current > > working > > > directory (CWD), unless it has PGET_CANDEBUG permission. > > > > > > linprocfs however allows reading the CWD for any process because it > > doesn't > > > perform that check (sys/compat/linprocfs/linprocfs.c, function > > > linprocfs_doproccwd()). > > > > > > Applications use this, eg. xfce4-terminal relies on > > > /compat/linux/proc//cwd to find the shell's CWD, so that when you > > open > > > a new tab, it starts in the same CWD as the tab you opened it from ( > > > > > https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343 > > ). > > > I would like to patch xfce4-terminal to use libprocstat for that instead > > of > > > needing linprocfs to be mounted, but since procstat is more restrictive, > > it > > > will break it. > > > > > > Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so you can > > > view the CWD for processes you own? Maybe other open files still need to > > be > > > hidden, but the CWD doesn't seem like a major security concern. > > Can you explain why CANDEBUG vs CANSEE matters for your case ? > > Or better, why xfce4-terminal cannot debug shells it spawns ? > > Is it suid ? > > > > > xfce4-terminal is a normal process, no suid. It wants to read CWD of the > current tab so the new tab opens in the same directory, which is often what > you want. On Linux /proc//cwd is lrwxrwxrwx for all processes. On > FreeBSD /compat/linux/proc//cwd is lrwxrwxrwx for all procesess. It > works as intended at present, as long as you have linprocfs mounted. > > But I'd rather not have to mount linprocfs. If I patch xfce4-terminal to > use libprocstat instead, then it will break, as it needs CANDEBUG to see > the CWD, a restriction that seems extreme. > > > > > > My initial reaction was that linprocfs should be patched to match FreeBSD > > native behaviour instead. > > > > Why does Linux allow everyone to see CWD for all processes? Does that include a path that I should not even be able to see via file system protections? If so I would classify that as a data xfiltration security concern. > > > > > > > > > > Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and only > > > hides file descriptors for processes you don't own. > > > > > > A patch along the following lines could be a start: > > > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > > index 423968b2e1cc..f487232d2cff 100644 > > > --- a/sys/kern/kern_descrip.c > > > +++ b/sys/kern/kern_descrip.c > > > @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS) > > > > > > sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req); > > > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > > if (error != 0) { > > > sbuf_delete(&sb); > > > return (error); > > > @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS) > > > struct proc *p; > > > > > > name = (int *)arg1; > > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > > if (error != 0) > > > return (error); > > > fdp = fdhold(p); > > > > > > > > > > > > > > > Thank you > > > Damjan > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri May 8 17:50:09 2020 Return-Path: Delivered-To: freebsd-hackers@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 72EAD2DD8D1 for ; Fri, 8 May 2020 17:50:09 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 49JdC44jF1z46sm; Fri, 8 May 2020 17:50:08 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-io1-xd44.google.com with SMTP id w4so2630069ioc.6; Fri, 08 May 2020 10:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NEjosk1I0dEZKSs7TvLZlkwRClKz7uIMARgp1NLXEmE=; b=UufcFRVpoNEht5iBJF1nQekaWSq6fX6D4FVcD+amOpEUf/ujkykLJKPqIupeoTqsQw C4rD26ENpFIUy5pdosFNvod3gryVtlf0JGVgRegi0h5zWgQX+k9NxOscq9x+CO/40e2e 6EmD5Wxpu/sebeUT83TbmdDZckQ8OczAw/3+dGuKF/W08WCfIkvp05OnK/xt/7u0THJY NbDIRpA5TGdLEj3IQ63yis7VqjfbCeLSp7PL4cjj3Yc212SLOCmX3lCd7zarBmFT22/d 2QOEGG/12jLw1nOLgULtfsTzMxyWiDMHTvpBureyhAYOhb5EoPJEiNcLGwa07e5yNICe +IjQ== 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=NEjosk1I0dEZKSs7TvLZlkwRClKz7uIMARgp1NLXEmE=; b=LsmcMcUPjMXgIVUsBrCwVTd5BedJyX/gKLipNgh5/09OamatXip1gpHxeJAsSYPTl7 Qc7V1kRAKl9Dzk4Ule8DXFWPAya9/Log275RNVWnyINwnze7+pJ/sFDr8clrQ8O55oru rhfV6tBN+gFylfqnvk2n0nivfKyhxqK5FDePhGkWmZfKyOODrwnNWf5FHrw32zos9Hbq pOXNzxkQ3KPnznnnFBPMA2Ma7gBZiCP0Ki8+roDB0iWPCv/nLTxNjAnH7SAnDCM+TSkc V0sgKGBifp8l2akvI1AEGRpdFhwR7oIzVLq5IqKuTRiOrJ+BchbW+wfGPmYiBfs1PP/a 2l9Q== X-Gm-Message-State: AGi0PubcTmpT0bW1xAjzbkYmmAqudhiYmM3WG+QCL9pLBc5cy8w6aPe5 FWnxrFjR17jd751Nx4rZAAgmamk4GQCunNFCs8UdSXCk2Fm8xw== X-Google-Smtp-Source: APiQypKqdEKHVZ5jTd+uZPWtO5/bmC066WEQ1N1ckNG3E4P4wakhzWCxrUovHxHKAXJXysdmGiuha067A/QgBkgwnNI= X-Received: by 2002:a05:6638:614:: with SMTP id g20mr3799553jar.85.1588960207834; Fri, 08 May 2020 10:50:07 -0700 (PDT) MIME-Version: 1.0 References: <202005081737.048Hb2CA053936@gndrsh.dnsmgr.net> In-Reply-To: <202005081737.048Hb2CA053936@gndrsh.dnsmgr.net> From: Damjan Jovanovic Date: Fri, 8 May 2020 19:49:41 +0200 Message-ID: Subject: Re: Allow procstat to view current working directory? [xfce4-terminal, linprocfs, ...] To: "Rodney W. Grimes" Cc: Konstantin Belousov , Hackers freeBSD X-Rspamd-Queue-Id: 49JdC44jF1z46sm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=UufcFRVp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of damjanjov@gmail.com designates 2607:f8b0:4864:20::d44 as permitted sender) smtp.mailfrom=damjanjov@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[9]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (0.24), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_HAS_QUESTION(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)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; TAGGED_FROM(0.00)[]; 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]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.d.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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:50:09 -0000 On Fri, May 8, 2020 at 7:37 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Wed, May 6, 2020 at 11:46 PM Konstantin Belousov > wrote: > > > > > On Wed, May 06, 2020 at 08:32:08PM +0200, Damjan Jovanovic wrote: > > > > Hi > > > > > > > > Currently "procstat fd [pid]" cannot view anything, even for other > > > > processes owned by the user making the call, not even their current > > > working > > > > directory (CWD), unless it has PGET_CANDEBUG permission. > > > > > > > > linprocfs however allows reading the CWD for any process because it > > > doesn't > > > > perform that check (sys/compat/linprocfs/linprocfs.c, function > > > > linprocfs_doproccwd()). > > > > > > > > Applications use this, eg. xfce4-terminal relies on > > > > /compat/linux/proc//cwd to find the shell's CWD, so that when > you > > > open > > > > a new tab, it starts in the same CWD as the tab you opened it from ( > > > > > > > > https://github.com/xfce-mirror/xfce4-terminal/blob/master/terminal/terminal-screen.c#L2343 > > > ). > > > > I would like to patch xfce4-terminal to use libprocstat for that > instead > > > of > > > > needing linprocfs to be mounted, but since procstat is more > restrictive, > > > it > > > > will break it. > > > > > > > > Can we please downgrade PGET_CANDEBUG to at least PGET_CANSEE, so > you can > > > > view the CWD for processes you own? Maybe other open files still > need to > > > be > > > > hidden, but the CWD doesn't seem like a major security concern. > > > Can you explain why CANDEBUG vs CANSEE matters for your case ? > > > Or better, why xfce4-terminal cannot debug shells it spawns ? > > > Is it suid ? > > > > > > > > xfce4-terminal is a normal process, no suid. It wants to read CWD of the > > current tab so the new tab opens in the same directory, which is often > what > > you want. On Linux /proc//cwd is lrwxrwxrwx for all processes. On > > FreeBSD /compat/linux/proc//cwd is lrwxrwxrwx for all procesess. It > > works as intended at present, as long as you have linprocfs mounted. > > > > But I'd rather not have to mount linprocfs. If I patch xfce4-terminal to > > use libprocstat instead, then it will break, as it needs CANDEBUG to see > > the CWD, a restriction that seems extreme. > > > > > > > > > > My initial reaction was that linprocfs should be patched to match > FreeBSD > > > native behaviour instead. > > > > > > > Why does Linux allow everyone to see CWD for all processes? > > Does that include a path that I should not even be able to see > via file system protections? If so I would classify that as > a data xfiltration security concern. > You're right, on Linux the symlink /proc/1/cwd is there, but the link target is invisible, and "stat cwd" gives: File: 'cwd'stat: cannot read symbolic link 'cwd': Permission denied Size: 0 Blocks: 0 IO Block: 1024 symbolic link Device: 4h/4d Inode: 24821 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2020-05-08 18:10:45.485582443 +0200 Modify: 2020-05-08 18:10:45.441582441 +0200 Change: 2020-05-08 18:10:45.441582441 +0200 Birth: - > > > > > > > > > > > > > > > Linux's own /proc filesystem never hides the CWD (lrwxrwxrwx), and > only > > > > hides file descriptors for processes you don't own. > > > > > > > > A patch along the following lines could be a start: > > > > > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > > > index 423968b2e1cc..f487232d2cff 100644 > > > > --- a/sys/kern/kern_descrip.c > > > > +++ b/sys/kern/kern_descrip.c > > > > @@ -3692,7 +3692,7 @@ sysctl_kern_proc_filedesc(SYSCTL_HANDLER_ARGS) > > > > > > > > sbuf_new_for_sysctl(&sb, NULL, FILEDESC_SBUF_SIZE, req); > > > > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > > > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > > > if (error != 0) { > > > > sbuf_delete(&sb); > > > > return (error); > > > > @@ -3768,7 +3768,7 @@ sysctl_kern_proc_ofiledesc(SYSCTL_HANDLER_ARGS) > > > > struct proc *p; > > > > > > > > name = (int *)arg1; > > > > - error = pget((pid_t)name[0], PGET_CANDEBUG | PGET_NOTWEXIT, &p); > > > > + error = pget((pid_t)name[0], PGET_CANSEE | PGET_NOTWEXIT, &p); > > > > if (error != 0) > > > > return (error); > > > > fdp = fdhold(p); > > > > > > > > > > > > > > > > > > > > Thank you > > > > Damjan > > > > _______________________________________________ > > > > freebsd-hackers@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > > To unsubscribe, send any mail to " > > > freebsd-hackers-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-hackers@freebsd.org Sat May 9 03:58:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 149C72DB536 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 49Jthb6Sdmz4Bwj 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: 49Jthb6Sdmz4Bwj 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-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD 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-hackers@freebsd.org Sat May 9 04:50:15 2020 Return-Path: Delivered-To: freebsd-hackers@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 35E1F2DC5DA for ; Sat, 9 May 2020 04:50:15 +0000 (UTC) (envelope-from ip@unixway.org) Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) 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 49Jvrk1qHwz4Fnr for ; Sat, 9 May 2020 04:50:14 +0000 (UTC) (envelope-from ip@unixway.org) Received: by mail-ed1-x543.google.com with SMTP id r7so3079602edo.11 for ; Fri, 08 May 2020 21:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unixway-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=xTee0kRint18M3/Av05pM7Az5d1/cMa/MyYrhU3TlUI=; b=tjWTZ5olDunIf6ELaKm0i/Snfs2Hu5ntE3YQKJ9pNnLY8RSGyI6SBFQ0ODCuFS9Fuu h8PEKMcmVzZDeWBI3BKsoMsDm5TlQ7Q2TSc9ZuLSvxbS0wgjFzJkmv+uLR/t/5XvGbPA 9fzJ+wMyya66XZrY+ViNDB5nAsdvuBzynd0FnGirvTB97zt7vjo/1160btrdg6kjUY/C /obcaJ9OaGrblOeD3ipUCFDfmI2w+Ne9UHEJFdF6ZUTLdBnRGciCwDrMRY/Lnm/knOh1 +L5Y9xC5b+8SNVi63d8A1oWNb+BDSJijJRk91wslLnSPjJ0uAKEpLNBAZkI6+LqtiWLS lEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=xTee0kRint18M3/Av05pM7Az5d1/cMa/MyYrhU3TlUI=; b=msqmuCJzazuRj9D7PSBrAEm83kWc6PJCrYt4RvPPQzME6g7Og+1exUf1Erd/XnibZG llSC2KCe6Acd1AlY8zph5r965pAUSbd7nhbTV0qNaBTCs1j8+IU8ceyIcOMy4b0gm69I FCR3wMeS4/sVcVwOW+XP4YnZ6zrGt3q53rGaTN04Mb3k6sZZ7SWLsHoCKzDCFijqoTRC Hep9Q1h+hEjqKg3CR9zCsXqj1QKP06rUFw8zavYz0vjEt7Uk5Pejf1QdhUYGH8CeeEuG HXzijWVOYd6sKNSVlHIytr2/6MK3RTzH5Yrmpfx7+a3ynXAW/LP3YfMR9lrnV5mYXKn0 2reg== X-Gm-Message-State: AGi0PuadJIRpXzYJmSUV78dVXkbBYc1bPpOGfoN97dTqP/9wwcAKnHR7 Q+ShgbB5oeGMha29RCCMFv5kyLHEwAPqEw== X-Google-Smtp-Source: ABdhPJxqcZq/AQpWNY6k+gixz9vnTsJuRlBEATgQNbs84BMsm6jGX1xz5JZ3btq/lAgV7o9Bc4rvHg== X-Received: by 2002:a2e:8ed0:: with SMTP id e16mr3737916ljl.96.1588999391500; Fri, 08 May 2020 21:43:11 -0700 (PDT) Received: from [192.168.0.101] ([89.250.175.47]) by smtp.gmail.com with ESMTPSA id i3sm2677396ljg.82.2020.05.08.21.43.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 May 2020 21:43:10 -0700 (PDT) From: Igor Pokrovsky Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Laundry size is always 0 Message-Id: <4E47812D-6314-4DA7-8426-ADE3FA6B9530@unixway.org> Date: Sat, 9 May 2020 08:43:08 +0400 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Rspamd-Queue-Id: 49Jvrk1qHwz4Fnr X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixway-org.20150623.gappssmtp.com header.s=20150623 header.b=tjWTZ5ol; dmarc=none; spf=none (mx1.freebsd.org: domain of ip@unixway.org has no SPF policy when checking 2a00:1450:4864:20::543) smtp.mailfrom=ip@unixway.org X-Spamd-Result: default: False [6.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[unixway-org.20150623.gappssmtp.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.46)[ip: (0.46), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[47.175.250.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[47.175.250.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[unixway-org.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.04)[-0.037,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[unixway.org]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_LONG(1.00)[0.996,0]; RCVD_IN_DNSWL_NONE(0.00)[3.4.5.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]; R_SPF_NA(0.00)[]; GREYLIST(0.00)[pass,body]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 04:50:15 -0000 Hello! I=E2=80=99ve got strange values for vm laundry size on -STABLE. And these values do not change even under load. vm.domain.0.stats.laundry: 0 vm.stats.vm.v_laundry_count: 0 I cannot complete buildworld on this box, compiler throughs segmentation = core at some random points. Can it be connected to empty laundry? I tested RAM and hard disk for errors - none found. Has anyone seen this? Relevant boot messages follows. ---<>--- FreeBSD 12.1-STABLE r360207 GENERIC amd64 FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git = c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) VT(vga): resolution 640x480 CPU: AMD Athlon(tm) 64 Processor 3000+ (1890.05-MHz K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x10ff0 Family=3D0xf Model=3D0x1f = Stepping=3D0 = Features=3D0x78bfbff AMD Features=3D0xe2500800 AMD Features2=3D0x1 real memory =3D 2147155968 (2047 MB) avail memory =3D 2039795712 (1945 MB) Thanks,=20 ip= From owner-freebsd-hackers@freebsd.org Sat May 9 10:51:05 2020 Return-Path: Delivered-To: freebsd-hackers@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 A1F562E499A for ; Sat, 9 May 2020 10:51:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49K3s4307Pz4bXJ for ; Sat, 9 May 2020 10:51:04 +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 049AouWW032569 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2020 13:51:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 049AouWW032569 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 049AouCS032568; Sat, 9 May 2020 13:50:56 +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 13:50:56 +0300 From: Konstantin Belousov To: Igor Pokrovsky Cc: freebsd-hackers@freebsd.org Subject: Re: Laundry size is always 0 Message-ID: <20200509105056.GF44519@kib.kiev.ua> References: <4E47812D-6314-4DA7-8426-ADE3FA6B9530@unixway.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E47812D-6314-4DA7-8426-ADE3FA6B9530@unixway.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49K3s4307Pz4bXJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ip: (-3.08), ipnet: 2001:470::/32(-4.07), asn: 6939(-3.13), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 10:51:05 -0000 On Sat, May 09, 2020 at 08:43:08AM +0400, Igor Pokrovsky wrote: > Hello! > > I’ve got strange values for vm laundry size on -STABLE. > And these values do not change even under load. > > vm.domain.0.stats.laundry: 0 > vm.stats.vm.v_laundry_count: 0 > > I cannot complete buildworld on this box, compiler throughs segmentation core at some random points. > Can it be connected to empty laundry? > > I tested RAM and hard disk for errors - none found. > Has anyone seen this? Relevant boot messages follows. > > ---<>--- > FreeBSD 12.1-STABLE r360207 GENERIC amd64 > FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > VT(vga): resolution 640x480 > CPU: AMD Athlon(tm) 64 Processor 3000+ (1890.05-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x10ff0 Family=0xf Model=0x1f Stepping=0 > Features=0x78bfbff > AMD Features=0xe2500800 > AMD Features2=0x1 > real memory = 2147155968 (2047 MB) > avail memory = 2039795712 (1945 MB) This machine is quite interesting, it is the first generation of long mode capable CPUs without cmpxchg16b support. For me it is interesting that we boot at all, because I was not able to test some important implementation of pmap features on such CPU. Can you provide: - full verbose dmesg - output of "sysctl vm". I am mostly interested in the value of vm.disable_swapspace_pageouts. - output of ps -axlHww Do you ever have some processes hang on the machine, as opposed to faulting with SIGSEGV/SIGBUS ? From owner-freebsd-hackers@freebsd.org Sat May 9 15:30:03 2020 Return-Path: Delivered-To: freebsd-hackers@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 0CBAE2ECD21 for ; Sat, 9 May 2020 15:30:03 +0000 (UTC) (envelope-from ip@unixway.org) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 49KB2x6Mjlz3y5b for ; Sat, 9 May 2020 15:30:01 +0000 (UTC) (envelope-from ip@unixway.org) Received: by mail-lj1-x242.google.com with SMTP id j3so4796205ljg.8 for ; Sat, 09 May 2020 08:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unixway-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=/yg3yVeVu+uDHhUb3W+3Fji49cVEu4xgcYBFOlOqdLc=; b=LfcS4iD2P4iTWnw3Vtt5TC9AHotJl/6nTXei4dfezSI8f6tPqf6CyjonT9LrpqExRS 1KxS6r70lGwPFZOSs2DuRqnZPqV83I1Ri1M1H+5o8r4wU/WAaXol+vcYyCNRwQ8uns0M 0GZdJtrzXxohzGB88PM11xhqfhhyM8dyd3h1g1fzA2JpU8pkTWeYgt27R+d3d532wgx4 sgAYquIM6eSRjbzLpbEpkY0KtV4lfCwXYOVp5vrvvCH0yzJFjfSgCUxgwFhlTIOWatoO wJkYFprQG0o1lN7sTdNpx8GmMWfJ2hxsM+69HAycehWzbbyBWy3y+PdfdyudbGBz0v2n vhrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/yg3yVeVu+uDHhUb3W+3Fji49cVEu4xgcYBFOlOqdLc=; b=ADRbiPQcAMnQ9zupcMvUGtHbN2b+sfXF8KoOWsfjXR+DEvABCTnabrGsze1fhe7QhS YchZ1QHGn+ooCRPsJYcoE2jYsYkN64U1D8d6ApzcANPEB6BxgLg5fQ/7zzYq8Gx6IVfx ptCnIB0GgLbjFN1AcP4D6GeuZ9BC3ZqlHL+EbwWpNE9WR6j8ggxjwfwRJBPQkBsaOBn5 afouc+mpxeMkeJ25U03bSEfGxByLxuRD9SDRzPwADBLVHNUXl5mDdoKbeHnUkyJRFpFe P9CoQQjswOXq318Ykt/RJ9dRe9GrA7zujxZNqi51LD5So8g1M+n64LgsTcrgYXKyU9eH kX2Q== X-Gm-Message-State: AOAM531GGpc+cd4//3lkg/RVVf7pDE0UTApImkodum7+gTDFLaqHg+lZ Gtt8tJJDUP9QuWZ33FygDjAFqj25agZUvw== X-Google-Smtp-Source: ABdhPJyRVDoqpmLeGxBv9nkqyWAPUk0fckdh5aZAtdeG4QBeeCMPJ/6IJlJBVI9wShNeyCYoQ0lGvg== X-Received: by 2002:a2e:8949:: with SMTP id b9mr5157053ljk.108.1589038200152; Sat, 09 May 2020 08:30:00 -0700 (PDT) Received: from [192.168.0.101] ([89.250.175.47]) by smtp.gmail.com with ESMTPSA id f5sm4298957lfh.84.2020.05.09.08.29.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 May 2020 08:29:59 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Laundry size is always 0 From: Igor Pokrovsky In-Reply-To: <20200509105056.GF44519@kib.kiev.ua> Date: Sat, 9 May 2020 19:29:51 +0400 Cc: freebsd-hackers@freebsd.org Message-Id: <770AF493-E757-429B-8F8F-D8181D3BA2F6@unixway.org> References: <4E47812D-6314-4DA7-8426-ADE3FA6B9530@unixway.org> <20200509105056.GF44519@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-Rspamd-Queue-Id: 49KB2x6Mjlz3y5b X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unixway-org.20150623.gappssmtp.com header.s=20150623 header.b=LfcS4iD2; dmarc=none; spf=none (mx1.freebsd.org: domain of ip@unixway.org has no SPF policy when checking 2a00:1450:4864:20::242) smtp.mailfrom=ip@unixway.org X-Spamd-Result: default: False [7.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[unixway-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~,5:+]; IP_SCORE(-0.00)[ip: (2.75), ipnet: 2a00:1450::/32(-2.29), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[47.175.250.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[47.175.250.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; R_DKIM_ALLOW(0.00)[unixway-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[unixway.org]; NEURAL_SPAM_MEDIUM(0.73)[0.726,0]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.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]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; GREYLIST(0.00)[pass,meta] X-Spam: Yes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 15:30:03 -0000 --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 =D0=BC=D0=B0=D1=8F 2020 =D0=B3., at 14:50, Konstantin Belousov = wrote: >=20 > This machine is quite interesting, it is the first generation of long = mode > capable CPUs without cmpxchg16b support. For me it is interesting = that > we boot at all, because I was not able to test some important = implementation > of pmap features on such CPU. >=20 > Can you provide: > - full verbose dmesg > - output of "sysctl vm". I am mostly interested in the value of > vm.disable_swapspace_pageouts. > - output of ps -axlHww Yes, I had problems with booting it too. Loader hang on boot.=20 But I solved this by attaching hard drives to built-in Promise raid = controller. This is ASUS A8V motherboard. Older releases, such as 8.0, runs fine on = it without=20 problems at all. >=20 > Do you ever have some processes hang on the machine, as opposed to = faulting > with SIGSEGV/SIGBUS ? No, they always SIGSEGV. Sometimes with stack overflow. Logs are in attachments. --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C Content-Disposition: attachment; filename=dmesg Content-Type: application/octet-stream; name="dmesg" Content-Transfer-Encoding: 7bit ---<>--- Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.1-STABLE GENERIC amd64 FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) VT(vga): resolution 640x480 CPU: AMD Athlon(tm) 64 Processor 3000+ (1890.04-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x10ff0 Family=0xf Model=0x1f Stepping=0 Features=0x78bfbff AMD Features=0xe2500800 AMD Features2=0x1 real memory = 2147155968 (2047 MB) avail memory = 2039795712 (1945 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: random: unblocking device. MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard Timecounter "TSC" frequency 1890043237 Hz quality 800 random: entropy device external interface kbd1 at kbdmux0 000.000022 [4336] netmap_init netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0xffffffff810f2510, 0) error 19 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe0ff mem 0xe0000000-0xefffffff,0xfbf00000-0xfbf0ffff irq 16 at device 0.0 on pci1 vgapci0: Boot video device pci0: at device 7.0 (no driver attached) atapci0: port 0x8800-0x883f,0x8400-0x840f,0x8000-0x807f mem 0xfb800000-0xfb800fff,0xfb700000-0xfb71ffff irq 18 at device 8.0 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ata4: at channel 2 on atapci0 skc0: port 0x9800-0x98ff mem 0xfba00000-0xfba03fff irq 17 at device 10.0 on pci0 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:11:d8:a9:d6:f0 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto rl0: port 0x9000-0x90ff mem 0xfbb00000-0xfbb000ff irq 17 at device 12.0 on pci0 rl0: reset never completed! rl0: unknown device ID: ffff assuming 8139 rl0: attaching PHYs failed device_attach: rl0 attach returned 6 emu10kx0: port 0xa000-0xa01f irq 18 at device 13.0 on pci0 pcm0: on emu10kx0 pcm0: pcm1: on emu10kx0 pci0: at device 13.1 (no driver attached) atapci1: port 0xc400-0xc407,0xc000-0xc003,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f,0xa800-0xa8ff irq 20 at device 15.0 on pci0 ata5: at channel 0 on atapci1 ata6: at channel 1 on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: at channel 0 on atapci2 ata1: at channel 1 on atapci2 uhci0: port 0xc800-0xc81f irq 21 at device 16.0 on pci0 uhci0: LegSup = 0xa000 usbus0 on uhci0 uhci1: port 0xd000-0xd01f irq 21 at device 16.1 on pci0 uhci1: LegSup = 0xa000 usbus1 on uhci1 uhci2: port 0xd400-0xd41f irq 21 at device 16.2 on pci0 uhci2: LegSup = 0xa000 usbus2 on uhci2 uhci3: port 0xd800-0xd81f irq 21 at device 16.3 on pci0 uhci3: LegSup = 0xa000 usbus3 on uhci3 ehci0: mem 0xfbd00000-0xfbd000ff irq 21 at device 16.4 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 isab0: at device 17.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub0: on usbus4 ugen3.1: at usbus3 uhub1: on usbus3 ugen2.1: at usbus2 uhub2: on usbus2 ugen1.1: at usbus1 uhub3: on usbus1 ugen0.1: at usbus0 uhub4: on usbus0 Trying to mount root from zfs:zroot/ROOT/default []... Root mount waiting for: CAM usbus0 usbus1 usbus2 usbus3 usbus4 Starting laundry kthread...doLaundryLaunder is 0!uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered Root mount waiting for: CAM usbus4 ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number 9VPB9DS9 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors) ada1 at ata3 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number ZN1DDTSG ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada1: 953869MB (1953525168 512 byte sectors) ada1: quirks=0x1<4K> Root mount waiting for: usbus4 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus4 ugen1.2: at usbus1 Setting hostuuid: 005a9c08-1296-d911-9f66-0011d8a9d6f0. Setting hostid: 0x1440ba25. Starting file system checks: Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.30/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 Loading kernel modules: info: [drm] Initialized drm 1.1.0 20060810 drmn0: ======================================================= drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg drmn0: ======================================================= drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers drmn0: ======================================================= drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg drmn0: ======================================================= drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers drmn0: on vgapci0 info: [drm] RADEON_IS_AGP info: [drm] initializing kernel modesetting (RV670 0x1002:0x9515 0x174B:0x0028). info: [drm] register mmio base: 0xFBF00000 info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002, device=9515 info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000 info: [drm] igp_read_bios_from_vram: Map address: 0xfffff800e0000000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x0000 info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xfffff800000c0000 (131072 bytes) info: [drm] ATOM BIOS: drmn0: info: GTT: 64M 0xDC000000 - 0xDFFFFFFF drmn0: info: VRAM: 512M 0xBC000000 - 0xDBFFFFFF (512M used) info: [drm] Detected VRAM RAM=512M, BAR=256M info: [drm] RAM width 256bits DDR [TTM] Zone kernel: Available graphics memory: 1027192 kiB [TTM] Initializing pool allocator info: [drm] radeon: 512M of VRAM memory ready info: [drm] radeon: 64M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 16384, num gpu pages 16384 info: [drm] Loading RV670 Microcode drmn0: info: WB disabled drmn0: info: fence driver on ring 0 use gpu addr 0x00000000dc000004 and cpu addr 0x0xfffff800dc000004 drmn0: info: fence driver on ring 3 use gpu addr 0x00000000dc000c0c and cpu addr 0x0xfffff800dc000c0c info: [drm] ring test on 0 succeeded in 1 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 1 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xe0000000-0xf0000000 info: [drm] radeon_device_init: Taking over the fictitious range 0xdc000000-0xe0000000 radeon_iicbb0 on drmn0 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 radeon_iicbb1 on drmn0 iicbus1: on iicbb1 addr 0xff iic1: on iicbus1 radeon_iicbb2 on drmn0 iicbus2: on iicbb2 addr 0xff iic2: on iicbus2 radeon_iicbb3 on drmn0 iicbus3: on iicbb3 addr 0xff iic3: on iicbus3 radeon_iicbb4 on drmn0 iicbus4: on iicbb4 addr 0xff iic4: on iicbus4 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] DVI-I-1 info: [drm] HPD1 info: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 info: [drm] CRT2: INTERNAL_KLDSCP_DAC2 info: [drm] Connector 1: info: [drm] DIN-1 info: [drm] Encoders: info: [drm] TV1: INTERNAL_KLDSCP_DAC2 info: [drm] Connector 2: info: [drm] DVI-I-2 info: [drm] HPD2 info: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c info: [drm] Encoders: info: [drm] CRT1: INTERNAL_KLDSCP_DAC1 info: [drm] DFP2: INTERNAL_LVTM1 info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] Connector DVI-I-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DVI-I-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DIN-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DIN-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DVI-I-2: get mode from tunables: info: [drm] - kern.vt.fb.modes.DVI-I-2 info: [drm] - kern.vt.fb.default_mode info: [drm] fb mappable at 0xE0062000 info: [drm] vram apper at 0xE0000000 info: [drm] size 1228800 info: [drm] fb depth is 24 info: [drm] pitch is 2560 fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized radeon 2.29.0 20080528 for drmn0 on minor 0 Setting hostname: doom.homeunix.org. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . lo0: link state changed to UP sk0: link state changed to DOWN sk0: link state changed to UP Starting Network: lo0 sk0. lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 sk0: flags=8843 metric 0 mtu 1500 options=80009 ether 00:11:d8:a9:d6:f0 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 Starting devd. Starting dhclient. DHCPREQUEST on sk0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.104 -- renewal in 43200 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. Setting date via ntp. 9 May 19:01:20 ntpdate[497]: step time server 83.143.51.50 offset +2.149803 sec No core dumps found. Clearing /tmp. Mounting late filesystems:. Updating /var/run/os-release done. Configuring vt: keymap blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Sat May 9 19:01:23 +04 2020 --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C Content-Disposition: attachment; filename=ps Content-Type: application/octet-stream; name="ps" Content-Transfer-Encoding: 7bit UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -16 0 0 5680 swapin DLs - 0:30.83 [kernel/swapper] 0 0 0 0 -76 0 0 5680 - DLs - 0:00.00 [kernel/config_0] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/kqueue_ctx t] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/aiod_kick ta] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/thread taskq] 0 0 0 0 -76 0 0 5680 - DLs - 0:00.00 [kernel/if_io_tqg_0] 0 0 0 0 -76 0 0 5680 - DLs - 0:00.00 [kernel/softirq_0] 0 0 0 0 -76 0 0 5680 - DLs - 0:00.00 [kernel/if_config_tq] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/firmware tas] 0 0 0 0 -20 0 0 5680 - DLs - 0:00.00 [kernel/crypto] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/system_taskq] 0 0 0 0 -52 0 0 5680 - DLs - 0:00.00 [kernel/mca taskq] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/arc_prune] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/dbu_evict] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/z_vdev_file_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/zfsvfs] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/acpi_task_0] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/acpi_task_1] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/acpi_task_2] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/CAM taskq] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_null_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.04 [kernel/zio_null_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.02 [kernel/zio_read_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_read_int] 0 0 0 0 -12 0 0 5680 - DLs - 0:00.11 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.01 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_write_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_iss] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_free_int] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_claim_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_claim_in] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_ioctl_is] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/zio_ioctl_in] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/dp_sync_task] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/dp_zil_clean] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/zfs_vn_rele_] 0 0 0 0 -8 0 0 5680 - DLs - 0:00.00 [kernel/metaslab_gro] 0 0 0 0 8 0 0 5680 - DLs - 0:00.00 [kernel/radeon taskq] 0 0 0 0 -16 0 0 5680 - DLs - 0:00.00 [kernel/ttm swap] 0 1 0 0 20 0 9912 1052 wait ILs - 0:00.07 /sbin/init -- 0 2 0 0 -16 0 0 16 crypto_w DL - 0:00.00 [crypto] 0 3 0 0 -16 0 0 16 crypto_r DL - 0:00.00 [crypto returns 0] 0 4 0 0 -16 0 0 32 - DL - 0:00.06 [cam/doneq0] 0 4 0 0 -16 0 0 32 - DL - 0:02.57 [cam/scanner] 0 5 0 0 -8 0 0 176 t->zthr_ DL - 0:00.00 [zfskern/solthread 0] 0 5 0 0 -8 0 0 176 t->zthr_ DL - 0:00.00 [zfskern/solthread 0] 0 5 0 0 -8 0 0 176 arc_dnlc DL - 0:00.00 [zfskern/arc_dnlc_ev] 0 5 0 0 -8 0 0 176 dbuf_evi DL - 0:00.00 [zfskern/dbuf_evict_] 0 5 0 0 -8 0 0 176 l2arc_fe DL - 0:00.00 [zfskern/l2arc_feed_] 0 5 0 0 -8 0 0 176 spa->spa DL - 0:00.00 [zfskern/trim zroot] 0 5 0 0 -8 0 0 176 tx->tx_q DL - 0:00.00 [zfskern/txg_thread_] 0 5 0 0 -8 0 0 176 tx->tx_s DL - 0:00.03 [zfskern/txg_thread_] 0 5 0 0 -8 0 0 176 t->zthr_ DL - 0:00.00 [zfskern/solthread 0] 0 5 0 0 -8 0 0 176 t->zthr_ DL - 0:00.00 [zfskern/solthread 0] 0 6 0 0 -16 0 0 16 waiting_ DL - 0:00.00 [sctp_iterator] 0 7 0 0 -16 0 0 16 - DL - 0:00.01 [rand_harvestq] 0 8 0 0 -16 0 0 48 psleep DL - 0:00.01 [pagedaemon/dom0] 0 8 0 0 -16 0 0 48 launds DL - 0:00.00 [pagedaemon/laundry:] 0 8 0 0 -16 0 0 48 umarcl DL - 0:00.00 [pagedaemon/uma] 0 9 0 0 -16 0 0 16 psleep DL - 0:00.00 [vmdaemon] 0 10 0 0 -16 0 0 16 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 16 - RNL - 5:25.32 [idle] 0 12 0 0 -52 0 0 240 - WL - 0:00.00 [intr/swi6: task que] 0 12 0 0 -52 0 0 240 - WL - 0:00.00 [intr/swi6: Giant ta] 0 12 0 0 -56 0 0 240 - WL - 0:00.00 [intr/swi5: fast tas] 0 12 0 0 -64 0 0 240 - WL - 0:00.00 [intr/swi3: vm] 0 12 0 0 -72 0 0 240 - WL - 0:00.00 [intr/swi1: netisr 0] 0 12 0 0 -60 0 0 240 - WL - 0:00.78 [intr/swi4: clock (0] 0 12 0 0 -96 0 0 240 - WL - 0:00.40 [intr/irq18: emu10kx] 0 12 0 0 -92 0 0 240 - WL - 0:00.01 [intr/irq17: skc0] 0 12 0 0 -88 0 0 240 - WL - 0:00.00 [intr/irq20: atapci1] 0 12 0 0 -88 0 0 240 - WL - 0:00.00 [intr/irq14: ata0] 0 12 0 0 -88 0 0 240 - WL - 0:00.00 [intr/irq15: ata1] 0 12 0 0 -88 0 0 240 - WL - 0:00.00 [intr/irq21: uhci0 u] 0 12 0 0 -84 0 0 240 - WL - 0:00.00 [intr/irq1: atkbd0] 0 12 0 0 -76 0 0 240 - WL - 0:00.00 [intr/swi0: uart uar] 0 12 0 0 -84 0 0 240 - WL - 0:00.01 [intr/irq16: vgapci0] 0 13 0 0 -8 0 0 48 - DL - 0:00.00 [geom/g_event] 0 13 0 0 -8 0 0 48 - DL - 0:00.00 [geom/g_up] 0 13 0 0 -8 0 0 48 - DL - 0:00.00 [geom/g_down] 0 14 0 0 -16 0 0 16 seqstate DL - 0:00.00 [sequencer 00] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus0] 0 15 0 0 -76 0 0 400 - DL - 0:00.00 [usb/usbus0] 0 15 0 0 -72 0 0 400 - DL - 0:00.00 [usb/usbus0] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus0] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus0] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus1] 0 15 0 0 -76 0 0 400 - DL - 0:00.00 [usb/usbus1] 0 15 0 0 -72 0 0 400 - DL - 0:00.00 [usb/usbus1] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus1] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus1] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus2] 0 15 0 0 -76 0 0 400 - DL - 0:00.00 [usb/usbus2] 0 15 0 0 -72 0 0 400 - DL - 0:00.00 [usb/usbus2] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus2] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus2] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus3] 0 15 0 0 -76 0 0 400 - DL - 0:00.00 [usb/usbus3] 0 15 0 0 -72 0 0 400 - DL - 0:00.00 [usb/usbus3] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus3] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus3] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus4] 0 15 0 0 -76 0 0 400 - DL - 0:00.00 [usb/usbus4] 0 15 0 0 -72 0 0 400 - DL - 0:00.00 [usb/usbus4] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus4] 0 15 0 0 -68 0 0 400 - DL - 0:00.00 [usb/usbus4] 0 16 0 0 -16 0 0 32 qsleep DL - 0:00.01 [bufdaemon/bufdaemon] 0 16 0 0 -16 0 0 32 - DL - 0:00.00 [bufdaemon/bufspaced] 0 17 0 0 -16 0 0 16 vlruwt DL - 0:00.00 [vnlru] 0 18 0 0 16 0 0 16 syncer DL - 0:00.00 [syncer] 0 19 0 0 -16 0 0 16 - DL - 0:00.00 [soaiod1] 0 20 0 0 -16 0 0 16 - DL - 0:00.00 [soaiod2] 0 21 0 0 -16 0 0 16 - DL - 0:00.00 [soaiod3] 0 22 0 0 -16 0 0 16 - DL - 0:00.00 [soaiod4] 0 111 1 0 52 0 10812 2224 pause Is - 0:00.00 adjkerntz -i 0 366 1 0 52 0 11368 2620 select Is - 0:00.00 dhclient: system.syslog (dhclient) 0 369 1 0 52 0 11552 2760 select Is - 0:00.00 dhclient: sk0 [priv] (dhclient) 65 417 1 0 52 0 11720 2876 select ICs - 0:00.00 dhclient: sk0 (dhclient) 0 418 1 0 20 0 10536 1484 select Is - 0:00.00 /sbin/devd 0 489 1 0 20 0 11360 2716 select Ss - 0:00.01 /usr/sbin/syslogd -s 0 683 1 0 20 0 19680 8188 select Is - 0:00.00 /usr/sbin/sshd 0 686 1 0 20 0 17112 7088 select Ss - 0:00.01 sendmail: accepting connections (sendmail) 25 689 1 0 49 0 16848 6820 pause Is - 0:00.00 sendmail: Queue runner@00:10:00 for /var/spool/clientmqueue (sendmail) 0 693 1 0 20 0 11332 2600 nanslp Is - 0:00.00 /usr/sbin/cron -s 0 750 683 0 20 0 20268 9268 select Ss - 0:00.08 sshd: root@pts/0 (sshd) 0 742 1 0 52 0 10868 2316 ttyin Is+ v0 0:00.00 /usr/libexec/getty Pc ttyv0 0 743 1 0 52 0 10868 2316 ttyin Is+ v1 0:00.00 /usr/libexec/getty Pc ttyv1 0 744 1 0 52 0 10868 2316 ttyin Is+ v2 0:00.00 /usr/libexec/getty Pc ttyv2 0 745 1 0 52 0 10868 2316 ttyin Is+ v3 0:00.00 /usr/libexec/getty Pc ttyv3 0 746 1 0 52 0 10868 2316 ttyin Is+ v4 0:00.00 /usr/libexec/getty Pc ttyv4 0 747 1 0 52 0 10868 2316 ttyin Is+ v5 0:00.00 /usr/libexec/getty Pc ttyv5 0 748 1 0 52 0 10868 2316 ttyin Is+ v6 0:00.00 /usr/libexec/getty Pc ttyv6 0 749 1 0 52 0 10868 2316 ttyin Is+ v7 0:00.00 /usr/libexec/getty Pc ttyv7 0 752 750 0 20 0 13208 3836 pause Ss 0 0:00.04 -csh (csh) 0 774 752 0 20 0 12168 3408 - R+ 0 0:00.00 ps -axlHww --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C Content-Disposition: attachment; filename=vm Content-Type: application/octet-stream; name="vm" Content-Transfer-Encoding: 7bit vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 20) Virtual Memory: (Total: 277772K Active: 264808K) Real Memory: (Total: 34256K Active: 33700K) Shared Virtual Memory: (Total: 24768K Active: 11816K) Shared Real Memory: (Total: 10340K Active: 9792K) Free Memory: 1831516K vm.loadavg: { 0.24 0.52 0.31 } vm.v_free_min: 3217 vm.v_free_target: 10717 vm.v_free_reserved: 717 vm.v_inactive_target: 16075 vm.v_pageout_free_min: 34 vm.swap_enabled: 1 vm.overcommit: 0 vm.domain.0.pidctrl.kdd: 8 vm.domain.0.pidctrl.kid: 4 vm.domain.0.pidctrl.kpd: 3 vm.domain.0.pidctrl.bound: 171472 vm.domain.0.pidctrl.interval: 100 vm.domain.0.pidctrl.setpoint: 10717 vm.domain.0.pidctrl.ticks: 2147175782 vm.domain.0.pidctrl.output: 0 vm.domain.0.pidctrl.input: 457965 vm.domain.0.pidctrl.derivative: 0 vm.domain.0.pidctrl.integral: 0 vm.domain.0.pidctrl.olderror: -447248 vm.domain.0.pidctrl.error: -447248 vm.domain.0.stats.free_severe: 1967 vm.domain.0.stats.free_min: 3217 vm.domain.0.stats.free_reserved: 717 vm.domain.0.stats.free_target: 10717 vm.domain.0.stats.inactive_target: 16075 vm.domain.0.stats.unswppdpgs: 0 vm.domain.0.stats.unswappable: 0 vm.domain.0.stats.laundpdpgs: 0 vm.domain.0.stats.laundry: 0 vm.domain.0.stats.inactpdpgs: 0 vm.domain.0.stats.inactive: 4049 vm.domain.0.stats.actpdpgs: 1318 vm.domain.0.stats.active: 3707 vm.domain.0.stats.free_count: 457868 vm.kvm_free: 2198490574848 vm.kvm_size: 2199023251456 vm.pmap.kernel_maps: Recursive map: 0xffff804020100000-0xffff804020109000 rw-s- WB 0 0 9 0xffff8040201f0000-0xffff8040201f1000 rw-s- WB 0 0 1 0xffff8040201fc000-0xffff804020200000 rw-s- WB 0 0 4 0xffff80403e000000-0xffff80403e004000 rw-s- WB 0 0 4 0xffff80403f800000-0xffff80403f801000 rw-s- WB 0 0 1 0xffff80403fffe000-0xffff80403ffff000 rw-s- WB 0 0 1 0xffff807c00000000-0xffff807c00001000 rw-s- WB 0 0 1 0xffff807c00001000-0xffff807c00015000 rw-sg WB 0 0 20 0xffff807c00015000-0xffff807c00016000 rw-s- WB 0 0 1 0xffff807c00016000-0xffff807c00033000 rw-sg WB 0 0 29 0xffff807c00033000-0xffff807c00035000 rw-s- WB 0 0 2 0xffff807c00035000-0xffff807c00046000 rw-sg WB 0 0 17 0xffff807c00046000-0xffff807c00047000 rw-s- WB 0 0 1 0xffff807c00047000-0xffff807c0006b000 rw-sg WB 0 0 36 0xffff807c0006b000-0xffff807c0006c000 rw-s- WB 0 0 1 0xffff807c0006c000-0xffff807c00076000 rw-sg WB 0 0 10 0xffff807c00076000-0xffff807c00077000 rw-s- WB 0 0 1 0xffff807c00077000-0xffff807c006e0000 rw-sg WB 0 0 1641 0xffff807c006e0000-0xffff807c006e2000 rw-s- WB 0 0 2 0xffff807c006e2000-0xffff807c00700000 rw-sg WB 0 0 30 0xffff807c00700000-0xffff807c00701000 rw-s- WB 0 0 1 0xffff807c00701000-0xffff807c007db000 rw-sg WB 0 0 218 0xffff807c007db000-0xffff807c007e0000 rw-s- WB 0 0 5 0xffff807c007e0000-0xffff807c007f6000 rw-sg WB 0 0 22 0xffff807c007f6000-0xffff807c007f8000 rw-s- WB 0 0 2 0xffff807c007f8000-0xffff807c00800000 rw-sg WB 0 0 8 0xffff807f00000000-0xffff807f00001000 rw-s- WB 0 0 1 0xffff807f00001000-0xffff807f00002000 rw-sg WB 0 0 1 0xffff807f00002000-0xffff807f00004000 rw-s- WB 0 0 2 0xffff807f00004000-0xffff807f00007000 rw-sg WB 0 0 3 0xffff807f00007000-0xffff807f00008000 rw-s- WB 0 0 1 0xffff807f00008000-0xffff807f0000a000 rw-sg WB 0 0 2 0xffff807f0000a000-0xffff807f000d6000 rw-s- WB 0 0 204 0xffff807f000d6000-0xffff807f000d8000 rw-sg WB 0 0 2 0xffff807f000d8000-0xffff807f000d9000 rw-s- WB 0 0 1 0xffff807f000d9000-0xffff807f000da000 rw-sg WB 0 0 1 0xffff807f000da000-0xffff807f000dd000 rw-s- WB 0 0 3 0xffff807f000dd000-0xffff807f000de000 rw-sg WB 0 0 1 0xffff807f000de000-0xffff807f000df000 rw-s- WB 0 0 1 0xffff807f000df000-0xffff807f000e1000 rw-sg WB 0 0 2 0xffff807f000e1000-0xffff807f000e2000 rw-s- WB 0 0 1 0xffff807f000e2000-0xffff807f000e7000 rw-sg WB 0 0 5 0xffff807f000e7000-0xffff807f000e8000 rw-s- WB 0 0 1 0xffff807f000e8000-0xffff807f000f3000 rw-sg WB 0 0 11 0xffff807f000f3000-0xffff807f000f4000 rw-s- WB 0 0 1 0xffff807f000f4000-0xffff807f000f5000 rw-sg WB 0 0 1 0xffff807f000f5000-0xffff807f000f6000 rw-s- WB 0 0 1 0xffff807f000f6000-0xffff807f000fa000 rw-sg WB 0 0 4 0xffff807f000fa000-0xffff807f000fb000 rw-s- WB 0 0 1 0xffff807f000fb000-0xffff807f000fc000 rw-sg WB 0 0 1 0xffff807f000fc000-0xffff807f000fe000 rw-s- WB 0 0 2 0xffff807fffc00000-0xffff807fffc01000 rw-sg WB 0 0 1 0xffff807fffc01000-0xffff807fffc0d000 r--sg WB 0 0 12 0xffff807fffc0d000-0xffff807fffc15000 rw-sg WB 0 0 8 0xffff807fffc15000-0xffff807fffc36000 rw-s- WB 0 0 33 Large map: Direct map: 0xfffff80000000000-0xfffff800000a0000 rw-sg WB 0 0 160 0xfffff800000a0000-0xfffff80000100000 rw-sg UC 0 0 96 0xfffff80000100000-0xfffff80002b20000 rw-sg WB 0 20 544 0xfffff80002b20000-0xfffff80002b30000 rw-sg WC 0 0 16 0xfffff80002b30000-0xfffff80006765000 rw-sg WB 0 29 565 0xfffff80006765000-0xfffff80006766000 rw-sg UC 0 0 1 0xfffff80006766000-0xfffff80006777000 rw-sg WB 0 0 17 0xfffff80006777000-0xfffff80006800000 rw-sg WC 0 0 137 0xfffff80006800000-0xfffff80006801000 rw-sg WB 0 0 1 0xfffff80006801000-0xfffff80006802000 rw-sg WC 0 0 1 0xfffff80006802000-0xfffff80006803000 rw-sg WB 0 0 1 0xfffff80006803000-0xfffff80006840000 rw-sg WC 0 0 61 0xfffff80006840000-0xfffff80006841000 rw-sg WB 0 0 1 0xfffff80006841000-0xfffff80006900000 rw-sg WC 0 0 191 0xfffff80006900000-0xfffff80008c76000 rw-sg WB 0 17 374 0xfffff80008c76000-0xfffff80008c77000 rw-sg UC 0 0 1 0xfffff80008c77000-0xfffff8000d746000 rw-sg WB 0 36 719 0xfffff8000d746000-0xfffff8000d800000 rw-sg WC 0 0 186 0xfffff8000d800000-0xfffff8000ec00000 rw-sg WB 0 10 0 0xfffff8000ec00000-0xfffff8000edc0000 rw-sg WC 0 0 448 0xfffff8000edc0000-0xfffff800dc000000 rw-sg WB 0 1641 64 0xfffff800dc000000-0xfffff800dc221000 rw-sg WC 0 0 545 0xfffff800dc221000-0xfffff800e0000000 rw-sg WB 0 30 479 0xfffff800e0000000-0xfffff800e0040000 rw-sg UC 0 0 64 0xfffff800e0040000-0xfffff800e0060000 rw-sg WB 0 0 32 0xfffff800e0060000-0xfffff800e018e000 rw-sg WC 0 0 302 0xfffff800e018e000-0xfffff800fb700000 rw-sg WB 0 218 370 0xfffff800fb700000-0xfffff800fb720000 rw-sg UC 0 0 32 0xfffff800fb720000-0xfffff800fb800000 rw-sg WB 0 0 224 0xfffff800fb800000-0xfffff800fb801000 rw-sg UC 0 0 1 0xfffff800fb801000-0xfffff800fba00000 rw-sg WB 0 0 511 0xfffff800fba00000-0xfffff800fba04000 rw-sg UC 0 0 4 0xfffff800fba04000-0xfffff800fbd00000 rw-sg WB 0 0 764 0xfffff800fbd00000-0xfffff800fbd01000 rw-sg UC 0 0 1 0xfffff800fbd01000-0xfffff800fbf00000 rw-sg WB 0 0 511 0xfffff800fbf00000-0xfffff800fbf10000 rw-sg UC 0 0 16 0xfffff800fbf10000-0xfffff800fec00000 rw-sg WB 0 22 240 0xfffff800fec00000-0xfffff800fec01000 rw-sg UC 0 0 1 0xfffff800fec01000-0xfffff800fee00000 rw-sg WB 0 0 511 0xfffff800fee00000-0xfffff800fee01000 rw-sg UC 0 0 1 0xfffff800fee01000-0xfffff80100000000 rw-sg WB 0 8 511 Kernel map: 0xfffffe0000000000-0xfffffe0000200000 r--sg WB 0 0 512 0xfffffe0000200000-0xfffffe0000400000 rw-sg WB 0 1 0 0xfffffe0000402000-0xfffffe0000406000 rw-sg WB 0 0 4 0xfffffe0000407000-0xfffffe000040b000 rw-sg WB 0 0 4 0xfffffe000040c000-0xfffffe0000410000 rw-sg WB 0 0 4 0xfffffe0000411000-0xfffffe0000415000 rw-sg WB 0 0 4 0xfffffe0000416000-0xfffffe000041a000 rw-sg WB 0 0 4 0xfffffe000041b000-0xfffffe000041f000 rw-sg WB 0 0 4 0xfffffe0000420000-0xfffffe0000424000 rw-sg WB 0 0 4 0xfffffe0000425000-0xfffffe0000429000 rw-sg WB 0 0 4 0xfffffe000042a000-0xfffffe000042e000 rw-sg WB 0 0 4 0xfffffe000042f000-0xfffffe0000433000 rw-sg WB 0 0 4 0xfffffe0000434000-0xfffffe0000438000 rw-sg WB 0 0 4 0xfffffe0000439000-0xfffffe000043d000 rw-sg WB 0 0 4 0xfffffe000043e000-0xfffffe0000442000 rw-sg WB 0 0 4 0xfffffe0000443000-0xfffffe0000447000 rw-sg WB 0 0 4 0xfffffe0000448000-0xfffffe000044c000 rw-sg WB 0 0 4 0xfffffe000044d000-0xfffffe0000451000 rw-sg WB 0 0 4 0xfffffe0000452000-0xfffffe0000456000 rw-sg WB 0 0 4 0xfffffe0000457000-0xfffffe000045b000 rw-sg WB 0 0 4 0xfffffe000045c000-0xfffffe0000460000 rw-sg WB 0 0 4 0xfffffe0000461000-0xfffffe0000465000 rw-sg WB 0 0 4 0xfffffe0000466000-0xfffffe000046a000 rw-sg WB 0 0 4 0xfffffe000046b000-0xfffffe000046f000 rw-sg WB 0 0 4 0xfffffe0000470000-0xfffffe0000474000 rw-sg WB 0 0 4 0xfffffe0000475000-0xfffffe0000479000 rw-sg WB 0 0 4 0xfffffe000047a000-0xfffffe000047e000 rw-sg WB 0 0 4 0xfffffe000047f000-0xfffffe0000483000 rw-sg WB 0 0 4 0xfffffe0000484000-0xfffffe0000488000 rw-sg WB 0 0 4 0xfffffe0000489000-0xfffffe000048d000 rw-sg WB 0 0 4 0xfffffe000048e000-0xfffffe0000492000 rw-sg WB 0 0 4 0xfffffe0000493000-0xfffffe0000497000 rw-sg WB 0 0 4 0xfffffe0000498000-0xfffffe000049c000 rw-sg WB 0 0 4 0xfffffe000049d000-0xfffffe00004a1000 rw-sg WB 0 0 4 0xfffffe00004a2000-0xfffffe00004a6000 rw-sg WB 0 0 4 0xfffffe00004a7000-0xfffffe00004ab000 rw-sg WB 0 0 4 0xfffffe00004ac000-0xfffffe00004b0000 rw-sg WB 0 0 4 0xfffffe00004b1000-0xfffffe00004b5000 rw-sg WB 0 0 4 0xfffffe00004b6000-0xfffffe00004ba000 rw-sg WB 0 0 4 0xfffffe00004bb000-0xfffffe00004bf000 rw-sg WB 0 0 4 0xfffffe00004c0000-0xfffffe00004c4000 rw-sg WB 0 0 4 0xfffffe00004c5000-0xfffffe00004c9000 rw-sg WB 0 0 4 0xfffffe00004ca000-0xfffffe00004ce000 rw-sg WB 0 0 4 0xfffffe00004cf000-0xfffffe00004d3000 rw-sg WB 0 0 4 0xfffffe00004d4000-0xfffffe00004d8000 rw-sg WB 0 0 4 0xfffffe00004d9000-0xfffffe00004dd000 rw-sg WB 0 0 4 0xfffffe00004de000-0xfffffe00004e2000 rw-sg WB 0 0 4 0xfffffe00004e3000-0xfffffe00004e7000 rw-sg WB 0 0 4 0xfffffe00004e8000-0xfffffe00004ec000 rw-sg WB 0 0 4 0xfffffe00004ed000-0xfffffe00004f1000 rw-sg WB 0 0 4 0xfffffe00004f2000-0xfffffe00004f6000 rw-sg WB 0 0 4 0xfffffe00004f7000-0xfffffe00004fb000 rw-sg WB 0 0 4 0xfffffe00004fc000-0xfffffe0000500000 rw-sg WB 0 0 4 0xfffffe0000501000-0xfffffe0000505000 rw-sg WB 0 0 4 0xfffffe0000506000-0xfffffe000050a000 rw-sg WB 0 0 4 0xfffffe000050b000-0xfffffe000050f000 rw-sg WB 0 0 4 0xfffffe0000510000-0xfffffe0000514000 rw-sg WB 0 0 4 0xfffffe0000515000-0xfffffe0000519000 rw-sg WB 0 0 4 0xfffffe000051a000-0xfffffe000051e000 rw-sg WB 0 0 4 0xfffffe000051f000-0xfffffe0000523000 rw-sg WB 0 0 4 0xfffffe0000524000-0xfffffe0000528000 rw-sg WB 0 0 4 0xfffffe0000529000-0xfffffe000052d000 rw-sg WB 0 0 4 0xfffffe000052e000-0xfffffe0000532000 rw-sg WB 0 0 4 0xfffffe0000533000-0xfffffe0000537000 rw-sg WB 0 0 4 0xfffffe0000538000-0xfffffe000053c000 rw-sg WB 0 0 4 0xfffffe000053d000-0xfffffe0000541000 rw-sg WB 0 0 4 0xfffffe0000542000-0xfffffe0000546000 rw-sg WB 0 0 4 0xfffffe0000547000-0xfffffe000054b000 rw-sg WB 0 0 4 0xfffffe000054c000-0xfffffe0000550000 rw-sg WB 0 0 4 0xfffffe0000551000-0xfffffe0000555000 rw-sg WB 0 0 4 0xfffffe0000556000-0xfffffe000055a000 rw-sg WB 0 0 4 0xfffffe000055b000-0xfffffe000055f000 rw-sg WB 0 0 4 0xfffffe0000560000-0xfffffe0000564000 rw-sg WB 0 0 4 0xfffffe0000565000-0xfffffe0000569000 rw-sg WB 0 0 4 0xfffffe000056a000-0xfffffe000056e000 rw-sg WB 0 0 4 0xfffffe000056f000-0xfffffe0000573000 rw-sg WB 0 0 4 0xfffffe0000574000-0xfffffe0000578000 rw-sg WB 0 0 4 0xfffffe0000579000-0xfffffe000057d000 rw-sg WB 0 0 4 0xfffffe000057e000-0xfffffe0000582000 rw-sg WB 0 0 4 0xfffffe0000583000-0xfffffe0000587000 rw-sg WB 0 0 4 0xfffffe0000588000-0xfffffe000058c000 rw-sg WB 0 0 4 0xfffffe000058d000-0xfffffe0000591000 rw-sg WB 0 0 4 0xfffffe0000592000-0xfffffe0000596000 rw-sg WB 0 0 4 0xfffffe0000597000-0xfffffe000059b000 rw-sg WB 0 0 4 0xfffffe000059c000-0xfffffe00005a0000 rw-sg WB 0 0 4 0xfffffe00005a1000-0xfffffe00005a5000 rw-sg WB 0 0 4 0xfffffe00005a6000-0xfffffe00005aa000 rw-sg WB 0 0 4 0xfffffe00005ab000-0xfffffe00005af000 rw-sg WB 0 0 4 0xfffffe00005b0000-0xfffffe00005b4000 rw-sg WB 0 0 4 0xfffffe00005b5000-0xfffffe00005b9000 rw-sg WB 0 0 4 0xfffffe00005ba000-0xfffffe00005be000 rw-sg WB 0 0 4 0xfffffe00005bf000-0xfffffe00005c3000 rw-sg WB 0 0 4 0xfffffe00005c4000-0xfffffe00005c8000 rw-sg WB 0 0 4 0xfffffe00005c9000-0xfffffe00005cd000 rw-sg WB 0 0 4 0xfffffe00005ce000-0xfffffe00005d2000 rw-sg WB 0 0 4 0xfffffe00005d3000-0xfffffe00005d7000 rw-sg WB 0 0 4 0xfffffe00005d8000-0xfffffe00005dc000 rw-sg WB 0 0 4 0xfffffe00005dd000-0xfffffe00005e1000 rw-sg WB 0 0 4 0xfffffe00005e2000-0xfffffe00005e6000 rw-sg WB 0 0 4 0xfffffe00005e7000-0xfffffe00005eb000 rw-sg WB 0 0 4 0xfffffe00005ec000-0xfffffe00005f0000 rw-sg WB 0 0 4 0xfffffe00005f1000-0xfffffe00005f5000 rw-sg WB 0 0 4 0xfffffe00005f6000-0xfffffe00005fa000 rw-sg WB 0 0 4 0xfffffe00005fb000-0xfffffe00005ff000 rw-sg WB 0 0 4 0xfffffe0000600000-0xfffffe00007ff000 rw-sg WB 0 0 511 0xfffffe0000800000-0xfffffe0000fdc000 rw-sg WB 0 3 476 0xfffffe0000fdc000-0xfffffe0000fec000 rw-sg WC 0 0 16 0xfffffe0000fec000-0xfffffe0001400000 rw-sg WB 0 2 20 0xfffffe0018721000-0xfffffe0018725000 rw-sg WB 0 0 4 0xfffffe0018726000-0xfffffe001872a000 rw-sg WB 0 0 4 0xfffffe001872b000-0xfffffe001872f000 rw-sg WB 0 0 4 0xfffffe0018730000-0xfffffe0018734000 rw-sg WB 0 0 4 0xfffffe0018735000-0xfffffe0018739000 rw-sg WB 0 0 4 0xfffffe001873a000-0xfffffe001873e000 rw-sg WB 0 0 4 0xfffffe001873f000-0xfffffe0018743000 rw-sg WB 0 0 4 0xfffffe0018744000-0xfffffe0018748000 rw-sg WB 0 0 4 0xfffffe0018749000-0xfffffe001874d000 rw-sg WB 0 0 4 0xfffffe001874e000-0xfffffe0018752000 rw-sg WB 0 0 4 0xfffffe0018753000-0xfffffe0018757000 rw-sg WB 0 0 4 0xfffffe0018758000-0xfffffe001875c000 rw-sg WB 0 0 4 0xfffffe001875d000-0xfffffe0018761000 rw-sg WB 0 0 4 0xfffffe0018762000-0xfffffe0018766000 rw-sg WB 0 0 4 0xfffffe0018767000-0xfffffe001876b000 rw-sg WB 0 0 4 0xfffffe001876c000-0xfffffe0018770000 rw-sg WB 0 0 4 0xfffffe0018771000-0xfffffe0018775000 rw-sg WB 0 0 4 0xfffffe0018776000-0xfffffe001877a000 rw-sg WB 0 0 4 0xfffffe001877b000-0xfffffe001877f000 rw-sg WB 0 0 4 0xfffffe0018780000-0xfffffe0018784000 rw-sg WB 0 0 4 0xfffffe0018785000-0xfffffe0018789000 rw-sg WB 0 0 4 0xfffffe001878a000-0xfffffe001878e000 rw-sg WB 0 0 4 0xfffffe001878f000-0xfffffe0018793000 rw-sg WB 0 0 4 0xfffffe0018794000-0xfffffe0018798000 rw-sg WB 0 0 4 0xfffffe0018799000-0xfffffe001879d000 rw-sg WB 0 0 4 0xfffffe001879e000-0xfffffe00187a2000 rw-sg WB 0 0 4 0xfffffe00187a3000-0xfffffe00187a7000 rw-sg WB 0 0 4 0xfffffe00187a8000-0xfffffe00187ac000 rw-sg WB 0 0 4 0xfffffe00187ad000-0xfffffe00187b1000 rw-sg WB 0 0 4 0xfffffe00187b2000-0xfffffe00187b6000 rw-sg WB 0 0 4 0xfffffe00187b7000-0xfffffe00187bb000 rw-sg WB 0 0 4 0xfffffe00187bc000-0xfffffe00187c0000 rw-sg WB 0 0 4 0xfffffe00187c1000-0xfffffe00187c5000 rw-sg WB 0 0 4 0xfffffe00187c6000-0xfffffe00187ca000 rw-sg WB 0 0 4 0xfffffe00187cb000-0xfffffe00187cf000 rw-sg WB 0 0 4 0xfffffe00187d0000-0xfffffe00187d4000 rw-sg WB 0 0 4 0xfffffe00187d5000-0xfffffe00187d9000 rw-sg WB 0 0 4 0xfffffe00187da000-0xfffffe00187de000 rw-sg WB 0 0 4 0xfffffe00187df000-0xfffffe00187e3000 rw-sg WB 0 0 4 0xfffffe00187e4000-0xfffffe00187e8000 rw-sg WB 0 0 4 0xfffffe00187e9000-0xfffffe00187ed000 rw-sg WB 0 0 4 0xfffffe00187ee000-0xfffffe00187f2000 rw-sg WB 0 0 4 0xfffffe00187f3000-0xfffffe00187f7000 rw-sg WB 0 0 4 0xfffffe00187f8000-0xfffffe00187fd000 rw-sg WB 0 0 5 0xfffffe0018a85000-0xfffffe0018a86000 rw-sg WB 0 0 1 0xfffffe0018b06000-0xfffffe0018b07000 rw-sg WB 0 0 1 0xfffffe0018b87000-0xfffffe0018b88000 rw-sg WB 0 0 1 0xfffffe0018c48000-0xfffffe0018c4a000 rw-sg WB 0 0 2 0xfffffe0018c4c000-0xfffffe0018c4d000 rw-sg WB 0 0 1 0xfffffe001ac00000-0xfffffe001b1ff000 rw-sg WB 0 2 511 0xfffffe001b200000-0xfffffe001b400000 rw-sg WB 0 1 0 0xfffffe001b401000-0xfffffe001b405000 rw-sg WB 0 0 4 0xfffffe001b406000-0xfffffe001b40a000 rw-sg WB 0 0 4 0xfffffe001b40b000-0xfffffe001b40f000 rw-sg WB 0 0 4 0xfffffe001b410000-0xfffffe001b414000 rw-sg WB 0 0 4 0xfffffe001b415000-0xfffffe001b419000 rw-sg WB 0 0 4 0xfffffe001b41a000-0xfffffe001b41e000 rw-sg WB 0 0 4 0xfffffe001b41f000-0xfffffe001b423000 rw-sg WB 0 0 4 0xfffffe001b424000-0xfffffe001b428000 rw-sg WB 0 0 4 0xfffffe001b429000-0xfffffe001b42d000 rw-sg WB 0 0 4 0xfffffe001b42e000-0xfffffe001b432000 rw-sg WB 0 0 4 0xfffffe001b433000-0xfffffe001b437000 rw-sg WB 0 0 4 0xfffffe001b438000-0xfffffe001b43c000 rw-sg WB 0 0 4 0xfffffe001b43d000-0xfffffe001b441000 rw-sg WB 0 0 4 0xfffffe001b442000-0xfffffe001b446000 rw-sg WB 0 0 4 0xfffffe001b447000-0xfffffe001b44b000 rw-sg WB 0 0 4 0xfffffe001b44c000-0xfffffe001b450000 rw-sg WB 0 0 4 0xfffffe001b451000-0xfffffe001b455000 rw-sg WB 0 0 4 0xfffffe001b456000-0xfffffe001b45a000 rw-sg WB 0 0 4 0xfffffe001b45b000-0xfffffe001b45f000 rw-sg WB 0 0 4 0xfffffe001b460000-0xfffffe001b464000 rw-sg WB 0 0 4 0xfffffe001b465000-0xfffffe001b469000 rw-sg WB 0 0 4 0xfffffe001b46a000-0xfffffe001b46e000 rw-sg WB 0 0 4 0xfffffe001b46f000-0xfffffe001b473000 rw-sg WB 0 0 4 0xfffffe001b474000-0xfffffe001b478000 rw-sg WB 0 0 4 0xfffffe001b479000-0xfffffe001b47d000 rw-sg WB 0 0 4 0xfffffe001b47e000-0xfffffe001b482000 rw-sg WB 0 0 4 0xfffffe001b483000-0xfffffe001b487000 rw-sg WB 0 0 4 0xfffffe001b488000-0xfffffe001b48c000 rw-sg WB 0 0 4 0xfffffe001b48d000-0xfffffe001b491000 rw-sg WB 0 0 4 0xfffffe001b492000-0xfffffe001b496000 rw-sg WB 0 0 4 0xfffffe001b497000-0xfffffe001b49b000 rw-sg WB 0 0 4 0xfffffe001b49c000-0xfffffe001b4a0000 rw-sg WB 0 0 4 0xfffffe001b4a1000-0xfffffe001b4a5000 rw-sg WB 0 0 4 0xfffffe001b4a6000-0xfffffe001b4aa000 rw-sg WB 0 0 4 0xfffffe001b4ab000-0xfffffe001b4af000 rw-sg WB 0 0 4 0xfffffe001b4b0000-0xfffffe001b4b4000 rw-sg WB 0 0 4 0xfffffe001b4b5000-0xfffffe001b4b9000 rw-sg WB 0 0 4 0xfffffe001b4ba000-0xfffffe001b4be000 rw-sg WB 0 0 4 0xfffffe001b4bf000-0xfffffe001b4c3000 rw-sg WB 0 0 4 0xfffffe001b4c4000-0xfffffe001b4c8000 rw-sg WB 0 0 4 0xfffffe001b4c9000-0xfffffe001b4cd000 rw-sg WB 0 0 4 0xfffffe001b4ce000-0xfffffe001b4d2000 rw-sg WB 0 0 4 0xfffffe001b4d3000-0xfffffe001b4d7000 rw-sg WB 0 0 4 0xfffffe001b4d8000-0xfffffe001b4dc000 rw-sg WB 0 0 4 0xfffffe001b4dd000-0xfffffe001b4e1000 rw-sg WB 0 0 4 0xfffffe001b4e2000-0xfffffe001b4e6000 rw-sg WB 0 0 4 0xfffffe001b4e7000-0xfffffe001b4eb000 rw-sg WB 0 0 4 0xfffffe001b4ec000-0xfffffe001b4f0000 rw-sg WB 0 0 4 0xfffffe001b4f1000-0xfffffe001b4f5000 rw-sg WB 0 0 4 0xfffffe001b4f6000-0xfffffe001b4fa000 rw-sg WB 0 0 4 0xfffffe001b4fb000-0xfffffe001b4ff000 rw-sg WB 0 0 4 0xfffffe001b500000-0xfffffe001b504000 rw-sg WB 0 0 4 0xfffffe001b505000-0xfffffe001b509000 rw-sg WB 0 0 4 0xfffffe001b50a000-0xfffffe001b50e000 rw-sg WB 0 0 4 0xfffffe001b50f000-0xfffffe001b513000 rw-sg WB 0 0 4 0xfffffe001b514000-0xfffffe001b518000 rw-sg WB 0 0 4 0xfffffe001b519000-0xfffffe001b51d000 rw-sg WB 0 0 4 0xfffffe001b51e000-0xfffffe001b522000 rw-sg WB 0 0 4 0xfffffe001b523000-0xfffffe001b527000 rw-sg WB 0 0 4 0xfffffe001b528000-0xfffffe001b52c000 rw-sg WB 0 0 4 0xfffffe001b52d000-0xfffffe001b531000 rw-sg WB 0 0 4 0xfffffe001b532000-0xfffffe001b536000 rw-sg WB 0 0 4 0xfffffe001b537000-0xfffffe001b53b000 rw-sg WB 0 0 4 0xfffffe001b53c000-0xfffffe001b540000 rw-sg WB 0 0 4 0xfffffe001b541000-0xfffffe001b545000 rw-sg WB 0 0 4 0xfffffe001b546000-0xfffffe001b54a000 rw-sg WB 0 0 4 0xfffffe001b54b000-0xfffffe001b54f000 rw-sg WB 0 0 4 0xfffffe001b550000-0xfffffe001b554000 rw-sg WB 0 0 4 0xfffffe001b555000-0xfffffe001b559000 rw-sg WB 0 0 4 0xfffffe001b55a000-0xfffffe001b55e000 rw-sg WB 0 0 4 0xfffffe001b55f000-0xfffffe001b563000 rw-sg WB 0 0 4 0xfffffe001b564000-0xfffffe001b568000 rw-sg WB 0 0 4 0xfffffe001b569000-0xfffffe001b56d000 rw-sg WB 0 0 4 0xfffffe001b56e000-0xfffffe001b572000 rw-sg WB 0 0 4 0xfffffe001b573000-0xfffffe001b577000 rw-sg WB 0 0 4 0xfffffe001b578000-0xfffffe001b57c000 rw-sg WB 0 0 4 0xfffffe001b57d000-0xfffffe001b581000 rw-sg WB 0 0 4 0xfffffe001b582000-0xfffffe001b586000 rw-sg WB 0 0 4 0xfffffe001b587000-0xfffffe001b58b000 rw-sg WB 0 0 4 0xfffffe001b58c000-0xfffffe001b590000 rw-sg WB 0 0 4 0xfffffe001b591000-0xfffffe001b595000 rw-sg WB 0 0 4 0xfffffe001b596000-0xfffffe001b59a000 rw-sg WB 0 0 4 0xfffffe001b59b000-0xfffffe001b59f000 rw-sg WB 0 0 4 0xfffffe001b5a0000-0xfffffe001b5a4000 rw-sg WB 0 0 4 0xfffffe001b5a5000-0xfffffe001b5a9000 rw-sg WB 0 0 4 0xfffffe001b5aa000-0xfffffe001b5ae000 rw-sg WB 0 0 4 0xfffffe001b5af000-0xfffffe001b5b3000 rw-sg WB 0 0 4 0xfffffe001b5b4000-0xfffffe001b5b8000 rw-sg WB 0 0 4 0xfffffe001b5b9000-0xfffffe001b5bd000 rw-sg WB 0 0 4 0xfffffe001b5be000-0xfffffe001b5c2000 rw-sg WB 0 0 4 0xfffffe001b5c3000-0xfffffe001b5c7000 rw-sg WB 0 0 4 0xfffffe001b5c8000-0xfffffe001b5cc000 rw-sg WB 0 0 4 0xfffffe001b5cd000-0xfffffe001b5d1000 rw-sg WB 0 0 4 0xfffffe001b5d2000-0xfffffe001b5d6000 rw-sg WB 0 0 4 0xfffffe001b5d7000-0xfffffe001b5db000 rw-sg WB 0 0 4 0xfffffe001b5dc000-0xfffffe001b5e0000 rw-sg WB 0 0 4 0xfffffe001b5e1000-0xfffffe001b5e5000 rw-sg WB 0 0 4 0xfffffe001b5e6000-0xfffffe001b5ea000 rw-sg WB 0 0 4 0xfffffe001b5eb000-0xfffffe001b5ef000 rw-sg WB 0 0 4 0xfffffe001b5f0000-0xfffffe001b5f4000 rw-sg WB 0 0 4 0xfffffe001b5f5000-0xfffffe001b5f9000 rw-sg WB 0 0 4 0xfffffe001b5fa000-0xfffffe001b5fe000 rw-sg WB 0 0 4 0xfffffe001b601000-0xfffffe001b605000 rw-sg WB 0 0 4 0xfffffe001b606000-0xfffffe001b60a000 rw-sg WB 0 0 4 0xfffffe001b60b000-0xfffffe001b60f000 rw-sg WB 0 0 4 0xfffffe001b610000-0xfffffe001b614000 rw-sg WB 0 0 4 0xfffffe001b615000-0xfffffe001b619000 rw-sg WB 0 0 4 0xfffffe001b61a000-0xfffffe001b61e000 rw-sg WB 0 0 4 0xfffffe001b61f000-0xfffffe001b623000 rw-sg WB 0 0 4 0xfffffe001b624000-0xfffffe001b628000 rw-sg WB 0 0 4 0xfffffe001b629000-0xfffffe001b62d000 rw-sg WB 0 0 4 0xfffffe001b62e000-0xfffffe001b632000 rw-sg WB 0 0 4 0xfffffe001b633000-0xfffffe001b637000 rw-sg WB 0 0 4 0xfffffe001b638000-0xfffffe001b63c000 rw-sg WB 0 0 4 0xfffffe001b63d000-0xfffffe001b641000 rw-sg WB 0 0 4 0xfffffe001b642000-0xfffffe001b646000 rw-sg WB 0 0 4 0xfffffe001b647000-0xfffffe001b64b000 rw-sg WB 0 0 4 0xfffffe001b64c000-0xfffffe001b650000 rw-sg WB 0 0 4 0xfffffe001b651000-0xfffffe001b655000 rw-sg WB 0 0 4 0xfffffe001b656000-0xfffffe001b65a000 rw-sg WB 0 0 4 0xfffffe001b65b000-0xfffffe001b65f000 rw-sg WB 0 0 4 0xfffffe001b660000-0xfffffe001b664000 rw-sg WB 0 0 4 0xfffffe001b665000-0xfffffe001b669000 rw-sg WB 0 0 4 0xfffffe001b66a000-0xfffffe001b66e000 rw-sg WB 0 0 4 0xfffffe001b66f000-0xfffffe001b673000 rw-sg WB 0 0 4 0xfffffe001b674000-0xfffffe001b678000 rw-sg WB 0 0 4 0xfffffe001b679000-0xfffffe001b67d000 rw-sg WB 0 0 4 0xfffffe001b67e000-0xfffffe001b682000 rw-sg WB 0 0 4 0xfffffe001b683000-0xfffffe001b687000 rw-sg WB 0 0 4 0xfffffe001b688000-0xfffffe001b68c000 rw-sg WB 0 0 4 0xfffffe001b68d000-0xfffffe001b691000 rw-sg WB 0 0 4 0xfffffe001b692000-0xfffffe001b696000 rw-sg WB 0 0 4 0xfffffe001b697000-0xfffffe001b69b000 rw-sg WB 0 0 4 0xfffffe001b69c000-0xfffffe001b6a0000 rw-sg WB 0 0 4 0xfffffe001b6a1000-0xfffffe001b6a5000 rw-sg WB 0 0 4 0xfffffe001b6a6000-0xfffffe001b6aa000 rw-sg WB 0 0 4 0xfffffe001b6ab000-0xfffffe001b6af000 rw-sg WB 0 0 4 0xfffffe001b6b0000-0xfffffe001b6b4000 rw-sg WB 0 0 4 0xfffffe001b6b5000-0xfffffe001b6b9000 rw-sg WB 0 0 4 0xfffffe001b6ba000-0xfffffe001b6be000 rw-sg WB 0 0 4 0xfffffe001b6bf000-0xfffffe001b6c3000 rw-sg WB 0 0 4 0xfffffe001b6c4000-0xfffffe001b6c8000 rw-sg WB 0 0 4 0xfffffe001b6c9000-0xfffffe001b6cd000 rw-sg WB 0 0 4 0xfffffe001b6ce000-0xfffffe001b6d2000 rw-sg WB 0 0 4 0xfffffe001b6d3000-0xfffffe001b6d7000 rw-sg WB 0 0 4 0xfffffe001b6d8000-0xfffffe001b6dc000 rw-sg WB 0 0 4 0xfffffe001b6dd000-0xfffffe001b6e1000 rw-sg WB 0 0 4 0xfffffe001b6e2000-0xfffffe001b6e6000 rw-sg WB 0 0 4 0xfffffe001b6e7000-0xfffffe001b6eb000 rw-sg WB 0 0 4 0xfffffe001b6ec000-0xfffffe001b6f0000 rw-sg WB 0 0 4 0xfffffe001b6f1000-0xfffffe001b6f5000 rw-sg WB 0 0 4 0xfffffe001b6f6000-0xfffffe001b6fa000 rw-sg WB 0 0 4 0xfffffe001b6fb000-0xfffffe001b6ff000 rw-sg WB 0 0 4 0xfffffe001b700000-0xfffffe001b704000 rw-sg WB 0 0 4 0xfffffe001b705000-0xfffffe001b709000 rw-sg WB 0 0 4 0xfffffe001b70a000-0xfffffe001b70e000 rw-sg WB 0 0 4 0xfffffe001b70f000-0xfffffe001b713000 rw-sg WB 0 0 4 0xfffffe001b714000-0xfffffe001b718000 rw-sg WB 0 0 4 0xfffffe001b719000-0xfffffe001b71d000 rw-sg WB 0 0 4 0xfffffe001b71e000-0xfffffe001b722000 rw-sg WB 0 0 4 0xfffffe001b723000-0xfffffe001b727000 rw-sg WB 0 0 4 0xfffffe001b728000-0xfffffe001b72c000 rw-sg WB 0 0 4 0xfffffe001b72d000-0xfffffe001b731000 rw-sg WB 0 0 4 0xfffffe001b732000-0xfffffe001b736000 rw-sg WB 0 0 4 0xfffffe001b737000-0xfffffe001b73b000 rw-sg WB 0 0 4 0xfffffe001b73c000-0xfffffe001b740000 rw-sg WB 0 0 4 0xfffffe001b741000-0xfffffe001b745000 rw-sg WB 0 0 4 0xfffffe001b746000-0xfffffe001b74a000 rw-sg WB 0 0 4 0xfffffe001b74b000-0xfffffe001b74f000 rw-sg WB 0 0 4 0xfffffe001b750000-0xfffffe001b754000 rw-sg WB 0 0 4 0xfffffe001b755000-0xfffffe001b759000 rw-sg WB 0 0 4 0xfffffe001b75a000-0xfffffe001b75e000 rw-sg WB 0 0 4 0xfffffe001b75f000-0xfffffe001b763000 rw-sg WB 0 0 4 0xfffffe001b764000-0xfffffe001b768000 rw-sg WB 0 0 4 0xfffffe001b769000-0xfffffe001b76d000 rw-sg WB 0 0 4 0xfffffe001b76e000-0xfffffe001b772000 rw-sg WB 0 0 4 0xfffffe001b773000-0xfffffe001b777000 rw-sg WB 0 0 4 0xfffffe001b778000-0xfffffe001b77c000 rw-sg WB 0 0 4 0xfffffe001b77d000-0xfffffe001b781000 rw-sg WB 0 0 4 0xfffffe001b782000-0xfffffe001b786000 rw-sg WB 0 0 4 0xfffffe001b787000-0xfffffe001b78b000 rw-sg WB 0 0 4 0xfffffe001b78c000-0xfffffe001b790000 rw-sg WB 0 0 4 0xfffffe001b791000-0xfffffe001b795000 rw-sg WB 0 0 4 0xfffffe001b796000-0xfffffe001b79a000 rw-sg WB 0 0 4 0xfffffe001b79b000-0xfffffe001b79f000 rw-sg WB 0 0 4 0xfffffe001b7a0000-0xfffffe001b7a4000 rw-sg WB 0 0 4 0xfffffe001b7a5000-0xfffffe001b7a9000 rw-sg WB 0 0 4 0xfffffe001b7aa000-0xfffffe001b7ae000 rw-sg WB 0 0 4 0xfffffe001b7af000-0xfffffe001b7b3000 rw-sg WB 0 0 4 0xfffffe001b7b4000-0xfffffe001b7b8000 rw-sg WB 0 0 4 0xfffffe001b7b9000-0xfffffe001b7bd000 rw-sg WB 0 0 4 0xfffffe001b7be000-0xfffffe001b7c2000 rw-sg WB 0 0 4 0xfffffe001b7c3000-0xfffffe001b7c7000 rw-sg WB 0 0 4 0xfffffe001b7c8000-0xfffffe001b7cc000 rw-sg WB 0 0 4 0xfffffe001b7cd000-0xfffffe001b7d1000 rw-sg WB 0 0 4 0xfffffe001b7d2000-0xfffffe001b7d6000 rw-sg WB 0 0 4 0xfffffe001b7d7000-0xfffffe001b7db000 rw-sg WB 0 0 4 0xfffffe001b7dc000-0xfffffe001b7e0000 rw-sg WB 0 0 4 0xfffffe001b7e1000-0xfffffe001b7e5000 rw-sg WB 0 0 4 0xfffffe001b7e6000-0xfffffe001b7ea000 rw-sg WB 0 0 4 0xfffffe001b7eb000-0xfffffe001b7ef000 rw-sg WB 0 0 4 0xfffffe001b7f0000-0xfffffe001b7f4000 rw-sg WB 0 0 4 0xfffffe001b7f5000-0xfffffe001b7f9000 rw-sg WB 0 0 4 0xfffffe001b7fa000-0xfffffe001b7fe000 rw-sg WB 0 0 4 0xfffffe001b801000-0xfffffe001b805000 rw-sg WB 0 0 4 0xfffffe001b806000-0xfffffe001b80a000 rw-sg WB 0 0 4 0xfffffe001b80b000-0xfffffe001b80f000 rw-sg WB 0 0 4 0xfffffe001b810000-0xfffffe001b814000 rw-sg WB 0 0 4 0xfffffe001b815000-0xfffffe001b819000 rw-sg WB 0 0 4 0xfffffe001b81a000-0xfffffe001b81e000 rw-sg WB 0 0 4 0xfffffe001b81f000-0xfffffe001b823000 rw-sg WB 0 0 4 0xfffffe001b824000-0xfffffe001b828000 rw-sg WB 0 0 4 0xfffffe001b829000-0xfffffe001b82d000 rw-sg WB 0 0 4 0xfffffe001b82e000-0xfffffe001b832000 rw-sg WB 0 0 4 0xfffffe001b833000-0xfffffe001b837000 rw-sg WB 0 0 4 0xfffffe001b838000-0xfffffe001b83c000 rw-sg WB 0 0 4 0xfffffe001b83d000-0xfffffe001b841000 rw-sg WB 0 0 4 0xfffffe001b842000-0xfffffe001b846000 rw-sg WB 0 0 4 0xfffffe001b847000-0xfffffe001b84b000 rw-sg WB 0 0 4 0xfffffe001b84c000-0xfffffe001b850000 rw-sg WB 0 0 4 0xfffffe001b851000-0xfffffe001b855000 rw-sg WB 0 0 4 0xfffffe001b856000-0xfffffe001b85a000 rw-sg WB 0 0 4 0xfffffe001b85b000-0xfffffe001b85f000 rw-sg WB 0 0 4 0xfffffe001b860000-0xfffffe001b864000 rw-sg WB 0 0 4 0xfffffe001b865000-0xfffffe001b869000 rw-sg WB 0 0 4 0xfffffe001b86a000-0xfffffe001b86e000 rw-sg WB 0 0 4 0xfffffe001b86f000-0xfffffe001b873000 rw-sg WB 0 0 4 0xfffffe001b874000-0xfffffe001b878000 rw-sg WB 0 0 4 0xfffffe001b879000-0xfffffe001b87d000 rw-sg WB 0 0 4 0xfffffe001b87e000-0xfffffe001b882000 rw-sg WB 0 0 4 0xfffffe001b883000-0xfffffe001b887000 rw-sg WB 0 0 4 0xfffffe001b888000-0xfffffe001b88c000 rw-sg WB 0 0 4 0xfffffe001b88d000-0xfffffe001b891000 rw-sg WB 0 0 4 0xfffffe001b892000-0xfffffe001b896000 rw-sg WB 0 0 4 0xfffffe001b897000-0xfffffe001b89b000 rw-sg WB 0 0 4 0xfffffe001b89c000-0xfffffe001b8a0000 rw-sg WB 0 0 4 0xfffffe001b8a1000-0xfffffe001b8a5000 rw-sg WB 0 0 4 0xfffffe001b8a6000-0xfffffe001b8aa000 rw-sg WB 0 0 4 0xfffffe001b8ab000-0xfffffe001b8af000 rw-sg WB 0 0 4 0xfffffe001b8b0000-0xfffffe001b8b4000 rw-sg WB 0 0 4 0xfffffe001b8b5000-0xfffffe001b8b9000 rw-sg WB 0 0 4 0xfffffe001b8ba000-0xfffffe001b8be000 rw-sg WB 0 0 4 0xfffffe001b8bf000-0xfffffe001b8c3000 rw-sg WB 0 0 4 0xfffffe001b8c4000-0xfffffe001b8c8000 rw-sg WB 0 0 4 0xfffffe001b8c9000-0xfffffe001b8cd000 rw-sg WB 0 0 4 0xfffffe001b8ce000-0xfffffe001b8d2000 rw-sg WB 0 0 4 0xfffffe001b8d3000-0xfffffe001b8d7000 rw-sg WB 0 0 4 0xfffffe001b8d8000-0xfffffe001b8dc000 rw-sg WB 0 0 4 0xfffffe001b8dd000-0xfffffe001b8e1000 rw-sg WB 0 0 4 0xfffffe001b8e2000-0xfffffe001b8e6000 rw-sg WB 0 0 4 0xfffffe001b8e7000-0xfffffe001b8eb000 rw-sg WB 0 0 4 0xfffffe001b8ec000-0xfffffe001b8f0000 rw-sg WB 0 0 4 0xfffffe001b8f1000-0xfffffe001b8f5000 rw-sg WB 0 0 4 0xfffffe001b8f6000-0xfffffe001b8fa000 rw-sg WB 0 0 4 0xfffffe001b8fb000-0xfffffe001b8ff000 rw-sg WB 0 0 4 0xfffffe001b900000-0xfffffe001b904000 rw-sg WB 0 0 4 0xfffffe001b905000-0xfffffe001b909000 rw-sg WB 0 0 4 0xfffffe001b90a000-0xfffffe001b90e000 rw-sg WB 0 0 4 0xfffffe001b90f000-0xfffffe001b913000 rw-sg WB 0 0 4 0xfffffe001b914000-0xfffffe001b918000 rw-sg WB 0 0 4 0xfffffe001b919000-0xfffffe001b91d000 rw-sg WB 0 0 4 0xfffffe001b91e000-0xfffffe001b922000 rw-sg WB 0 0 4 0xfffffe001b923000-0xfffffe001b927000 rw-sg WB 0 0 4 0xfffffe001b928000-0xfffffe001b92c000 rw-sg WB 0 0 4 0xfffffe001b92d000-0xfffffe001b931000 rw-sg WB 0 0 4 0xfffffe001b932000-0xfffffe001b936000 rw-sg WB 0 0 4 0xfffffe001b937000-0xfffffe001b93b000 rw-sg WB 0 0 4 0xfffffe001b93c000-0xfffffe001b940000 rw-sg WB 0 0 4 0xfffffe001b941000-0xfffffe001b945000 rw-sg WB 0 0 4 0xfffffe001b946000-0xfffffe001b94a000 rw-sg WB 0 0 4 0xfffffe001b94b000-0xfffffe001b94f000 rw-sg WB 0 0 4 0xfffffe001b950000-0xfffffe001b954000 rw-sg WB 0 0 4 0xfffffe001b955000-0xfffffe001b959000 rw-sg WB 0 0 4 0xfffffe001b95a000-0xfffffe001b95e000 rw-sg WB 0 0 4 0xfffffe001b95f000-0xfffffe001b963000 rw-sg WB 0 0 4 0xfffffe001b964000-0xfffffe001b968000 rw-sg WB 0 0 4 0xfffffe001b969000-0xfffffe001b96d000 rw-sg WB 0 0 4 0xfffffe001b96e000-0xfffffe001b976000 rw-sg WB 0 0 8 0xfffffe001b977000-0xfffffe001b97b000 rw-sg WB 0 0 4 0xfffffe001b97c000-0xfffffe001b980000 rw-sg WB 0 0 4 0xfffffe001b981000-0xfffffe001b985000 rw-sg WB 0 0 4 0xfffffe001b986000-0xfffffe001b98a000 rw-sg WB 0 0 4 0xfffffe001b98b000-0xfffffe001b98f000 rw-sg WB 0 0 4 0xfffffe001b990000-0xfffffe001b994000 rw-sg WB 0 0 4 0xfffffe001b995000-0xfffffe001b999000 rw-sg WB 0 0 4 0xfffffe001b99a000-0xfffffe001b99e000 rw-sg WB 0 0 4 0xfffffe001b99f000-0xfffffe001b9a3000 rw-sg WB 0 0 4 0xfffffe001b9a4000-0xfffffe001b9a8000 rw-sg WB 0 0 4 0xfffffe001b9a9000-0xfffffe001b9ad000 rw-sg WB 0 0 4 0xfffffe001b9ae000-0xfffffe001b9b2000 rw-sg WB 0 0 4 0xfffffe001b9b3000-0xfffffe001b9b7000 rw-sg WB 0 0 4 0xfffffe001b9b8000-0xfffffe001b9bc000 rw-sg WB 0 0 4 0xfffffe001b9bd000-0xfffffe001b9c1000 rw-sg WB 0 0 4 0xfffffe001b9c2000-0xfffffe001b9c6000 rw-sg WB 0 0 4 0xfffffe001b9c7000-0xfffffe001b9cb000 rw-sg WB 0 0 4 0xfffffe001b9cc000-0xfffffe001b9d0000 rw-sg WB 0 0 4 0xfffffe001b9d1000-0xfffffe001b9d5000 rw-sg WB 0 0 4 0xfffffe001b9d6000-0xfffffe001b9da000 rw-sg WB 0 0 4 0xfffffe001b9db000-0xfffffe001b9df000 rw-sg WB 0 0 4 0xfffffe001b9e0000-0xfffffe001b9e4000 rw-sg WB 0 0 4 0xfffffe001b9e5000-0xfffffe001b9e9000 rw-sg WB 0 0 4 0xfffffe001b9ea000-0xfffffe001b9ee000 rw-sg WB 0 0 4 0xfffffe001b9ef000-0xfffffe001b9f3000 rw-sg WB 0 0 4 0xfffffe001b9f4000-0xfffffe001b9f8000 rw-sg WB 0 0 4 0xfffffe001b9f9000-0xfffffe001b9fd000 rw-sg WB 0 0 4 0xfffffe001ba00000-0xfffffe001bdff000 rw-sg WB 0 1 511 0xfffffe001be00000-0xfffffe001c3ff000 rw-sg WB 0 2 511 0xfffffe001c400000-0xfffffe001ce76000 rw-sg WB 0 5 118 0xfffffe001ce76000-0xfffffe001ce77000 rw-sg UC 0 0 1 0xfffffe001ce77000-0xfffffe001e7ff000 rw-sg WB 0 11 904 0xfffffe001e800000-0xfffffe001ebff000 rw-sg WB 0 1 511 0xfffffe001ec00000-0xfffffe001f400000 rw-sg WB 0 4 0 0xfffffe001f401000-0xfffffe001f405000 rw-sg WB 0 0 4 0xfffffe001f406000-0xfffffe001f40a000 rw-sg WB 0 0 4 0xfffffe001f40b000-0xfffffe001f40f000 rw-sg WB 0 0 4 0xfffffe001f410000-0xfffffe001f414000 rw-sg WB 0 0 4 0xfffffe001f415000-0xfffffe001f419000 rw-sg WB 0 0 4 0xfffffe001f600000-0xfffffe001f9ff000 rw-sg WB 0 1 511 0xfffffe001fa00000-0xfffffe001faba000 rw-sg WB 0 0 186 0xffffffff80000000-0xffffffff80200000 rwxsg WB 0 1 0 0xffffffff80200000-0xffffffff81200000 r-xsg WB 0 8 0 0xffffffff81200000-0xffffffff81a00000 r--sg WB 0 4 0 0xffffffff81a00000-0xffffffff82000000 rw-sg WB 0 3 0 0xffffffff82000000-0xffffffff82a00000 rwxsg WB 0 5 0 0xffffffff82a10000-0xffffffff82b10000 rw-sg WB 0 0 256 0xffffffff82b10000-0xffffffff82b20000 rw-sg UC 0 0 16 0xffffffff82b20000-0xffffffff82b21000 rw-sg WB 0 0 1 0xffffffff82b21000-0xffffffff82b9b000 r-xsg WB 0 0 122 0xffffffff82b9b000-0xffffffff82bc8000 r--sg WB 0 0 45 0xffffffff82bc8000-0xffffffff82bd2000 rw-sg WB 0 0 10 0xffffffff82bd2000-0xffffffff82c04000 r-xsg WB 0 0 50 0xffffffff82c04000-0xffffffff82c08000 r--sg WB 0 0 4 0xffffffff82c08000-0xffffffff82c0c000 rw-sg WB 0 0 4 0xffffffff82c0c000-0xffffffff82c17000 r--sg WB 0 0 11 0xffffffff82c17000-0xffffffff82c1a000 r-xsg WB 0 0 3 0xffffffff82c1a000-0xffffffff82c1b000 rw-sg WB 0 0 1 0xffffffff82c1b000-0xffffffff82c1c000 rwxsg WB 0 0 1 0xffffffff82c1c000-0xffffffff82c1d000 r-xsg WB 0 0 1 0xffffffff82c1d000-0xffffffff82c1f000 rwxsg WB 0 0 2 0xffffffff82c1f000-0xffffffff82c24000 rw-sg WB 0 0 5 0xffffffff82c24000-0xffffffff82c26000 rwxsg WB 0 0 2 vm.pmap.pdpe.demotions: 0 vm.pmap.pde.promotions: 90 vm.pmap.pde.p_failures: 1 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 21 vm.pmap.allow_2m_x_ept: 0 vm.pmap.di_locked: 1 vm.pmap.pcid_save_cnt: 0 vm.pmap.pti: 0 vm.pmap.invpcid_works: 0 vm.pmap.pcid_enabled: 0 vm.pmap.pg_ps_enabled: 1 vm.pmap.pat_works: 1 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.swap_idle_enabled: 0 vm.reserv.reclaimed: 0 vm.reserv.partpopq: DOMAIN LEVEL SIZE NUMBER 0, -1, 195208K, 106 vm.reserv.fullpop: 35 vm.reserv.freed: 1695 vm.reserv.broken: 0 vm.ndomains: 1 vm.phys_locality: 0: -1 vm.phys_segs: SEGMENT 0: start: 0x10000 end: 0x9f000 domain: 0 free list: 0xffffffff81ed1930 SEGMENT 1: start: 0x103000 end: 0x1000000 domain: 0 free list: 0xffffffff81ed1930 SEGMENT 2: start: 0x1000000 end: 0x283e000 domain: 0 free list: 0xffffffff81ed16c0 SEGMENT 3: start: 0x2848000 end: 0x287e000 domain: 0 free list: 0xffffffff81ed16c0 SEGMENT 4: start: 0x2b00000 end: 0x7cca8000 domain: 0 free list: 0xffffffff81ed16c0 vm.phys_free: DOMAIN 0: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 12 ( 16384K) | 98 | 0 11 ( 8192K) | 1 | 1 10 ( 4096K) | 2 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 1 | 1 7 ( 512K) | 0 | 1 6 ( 256K) | 2 | 0 5 ( 128K) | 1 | 1 4 ( 64K) | 5 | 0 3 ( 32K) | 11 | 4 2 ( 16K) | 19 | 4 1 ( 8K) | 37 | 8 0 ( 4K) | 25 | 1 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 11 ( 8192K) | 0 | 0 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 1 | 0 5 ( 128K) | 1 | 0 4 ( 64K) | 2 | 0 3 ( 32K) | 1 | 0 2 ( 16K) | 0 | 0 1 ( 8K) | 1 | 0 0 ( 4K) | 0 | 0 vm.oom_pf_secs: 10 vm.max_wired: 164107 vm.background_launder_max: 20480 vm.background_launder_rate: 4096 vm.act_scan_laundry_weight: 3 vm.pageout_oom_seq: 12 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.lowmem_period: 10 vm.pageout_update_period: 600 vm.panic_on_oom: 0 vm.page_blacklist: vm.tryrelock_restart: 0 vm.boot_pages: 5 vm.old_msync: 0 vm.mincore_mapped: 1 vm.old_mlock: 0 vm.stats.object.bypasses: 391 vm.stats.object.collapses: 1752 vm.stats.vm.v_pdpages: 1318 vm.stats.vm.v_tcached: 0 vm.stats.vm.v_cache_count: 0 vm.stats.vm.v_free_severe: 1967 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_laundry_count: 0 vm.stats.vm.v_inactive_count: 4049 vm.stats.vm.v_inactive_target: 16075 vm.stats.vm.v_active_count: 3707 vm.stats.vm.v_wire_count: 34748 vm.stats.vm.v_free_count: 457712 vm.stats.vm.v_free_min: 3217 vm.stats.vm.v_free_target: 10717 vm.stats.vm.v_free_reserved: 717 vm.stats.vm.v_page_count: 500279 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 110 vm.stats.vm.v_vforkpages: 6664 vm.stats.vm.v_forkpages: 37089 vm.stats.vm.v_kthreads: 22 vm.stats.vm.v_rforks: 2 vm.stats.vm.v_vforks: 196 vm.stats.vm.v_forks: 552 vm.stats.vm.v_tfree: 130000 vm.stats.vm.v_pfree: 34359 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_pdshortfalls: 0 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_reactivated: 0 vm.stats.vm.v_intrans: 0 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 4175 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 650 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 0 vm.stats.vm.v_zfod: 33341 vm.stats.vm.v_cow_optim: 85 vm.stats.vm.v_cow_faults: 23837 vm.stats.vm.v_io_faults: 747 vm.stats.vm.v_vm_faults: 66715 vm.stats.sys.v_soft: 5662 vm.stats.sys.v_intr: 23627 vm.stats.sys.v_syscall: 277768 vm.stats.sys.v_trap: 66969 vm.stats.sys.v_swtch: 86313 vm.v_free_severe: 1967 vm.aslr_restarts: 0 vm.cluster_anon: 1 vm.max_kernel_address: 18446744073709547520 vm.min_kernel_address: 18446741874686296064 vm.kstacks: 456 vm.kstack_cache_size: 128 vm.pfault_oom_wait: 10 vm.pfault_oom_attempts: 3 vm.zone_warnings: 1 vm.zone_count: 251 vm.uma_kmem_total: 117612544 vm.uma_kmem_limit: 2049142784 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_fragmentation: Free space on device ada1p2: number of maximal free ranges: 1 largest free range: 524286 average maximal free range size: 524286 number of maximal free ranges of different sizes: count | size range ----- | ---------- 1 | 524286 vm.swap_async_max: 4 vm.swap_maxpages: 4002464 vm.swzone: 34020944 vm.swap_total: 2147483648 vm.swap_reserved: 316588032 vm.phys_pager_cluster: 1024 vm.kmem_map_free: 1931513856 vm.kmem_map_size: 117628928 vm.kmem_size_scale: 1 vm.kmem_size_max: 1319413950874 vm.kmem_size_min: 0 vm.kmem_zmax: 65536 vm.kmem_size: 2049142784 vm.md_malloc_wait: 0 --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_6964887E-4A73-4708-B62E-D4972642BE2C-- From owner-freebsd-hackers@freebsd.org Sat May 9 16:41:30 2020 Return-Path: Delivered-To: freebsd-hackers@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 3DB622F03D9 for ; Sat, 9 May 2020 16:41:30 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49KCdP3yV2z44QQ for ; Sat, 9 May 2020 16:41:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mailman.nyi.freebsd.org (Postfix) id 87B582F03D5; Sat, 9 May 2020 16:41:29 +0000 (UTC) Delivered-To: hackers@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 876BB2F03D4 for ; Sat, 9 May 2020 16:41:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 49KCdN1jD7z44QM for ; Sat, 9 May 2020 16:41:28 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-io1-xd41.google.com with SMTP id e9so4993874iok.9 for ; Sat, 09 May 2020 09:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:from:date:message-id:subject:to; bh=JnMD2ztA+hlhM8sU5T2qTdysP3VEhwlV4q4GBJnAm10=; b=Quwu5hL58GVt1rcnYgk3CGOUyEX7kblwZeWfcyx4C0Wt71llSbY6vS5yEvQoMc9Wyd FUUThBZ9F5sBY/T2xxK8CFVOVqFeO9Yxtgu4+BR2VogAuEz6eqbVly49umnvftk9wqJN p2xbV5cd96yq+c/28kB2YBSunVzlZcw8hetUo= 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=JnMD2ztA+hlhM8sU5T2qTdysP3VEhwlV4q4GBJnAm10=; b=Uhf386YbUPlQHFoG0jFoudTWnuwnGqJTfePn8rkttTewHveReQBtuNsMW+Lc+uHxjl GZXOphqooY+qxz5/8RhiWaL9Y63oHGMh17NifoDZ1iW+VIdxB5UEV/PKxCYcnp+usANe b3G9gGsnQV33beMebNunCdPz//PrEx0QICm2Rv/InbbXYtHl0fXI0EvyJK8dkeWjTPU6 wCo8pJZxdmMsnUuRrNCXPmMW6MPyLGrlpOWz1b3G47g9IXuNTF9o7l91wLP1gDdebN13 9dBFg5fMjAqXBOr+YYDIPfxF/CO/XxwV/jJj2zFwX1B1/Jqq6gKlHTsk7SXAYzS18dVv edlw== X-Gm-Message-State: AGi0PuZdl/6x/pa4ukhDo/z3htsXamlwmvfewy507Q3fR3sK6u96Z0nV 1T02fliYJREZyfXoek5pryxk3pmfVT1edSMrzKnCMQ== X-Google-Smtp-Source: APiQypKpd1pc4C9KubcuHBjXfH6egp6Dk170WbxjMABGFsUL+hlSmmIw/HL+3ctTM7J2CiZovDDEgwzYNu8zsS32j+Q= X-Received: by 2002:a5d:9244:: with SMTP id e4mr7771587iol.133.1589042487153; Sat, 09 May 2020 09:41:27 -0700 (PDT) MIME-Version: 1.0 From: Mario Lobo Date: Sat, 9 May 2020 13:41:15 -0300 Message-ID: Subject: Find specific changes between revisions To: vbox@freebsd.org, hackers@freebsd.org, "freebsd-emulation@freebsd.org" X-Rspamd-Queue-Id: 49KCdN1jD7z44QM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsd.com.br header.s=capeta header.b=Quwu5hL5; dmarc=none; spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2607:f8b0:4864:20::d41 as permitted sender) smtp.mailfrom=lobo@bsd.com.br X-Spamd-Result: default: False [-2.61 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[bsd.com.br]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsd.com.br:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.d.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.12)[ip: (0.23), 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 16:41:30 -0000 Hi; I'm attempting to port VirtualBox 6.0.8 to FreeBSD. I managed do get it working perfectly up to 11.3-STABLE-amd64-r359971. After an svn up to 11.4-PRERELEASE-r360676M, VirtualBox 6.0.8 no longer works. Bringing world+kernel back to 11.3-STABLE-amd64-r359971 makes it work again, despite whatever ports I've got installed on my machines. This was tested on 2 physical machines (desktop and laptop) and it is true for both. When starting a VM on 11.4-PRERELEASE-r360676M, the VM console window shows up for 2 seconds and vanishes. Tha VM log shows this: -------------------------------------------------------------------------------------------------------- 00:00:02.343339 AssertLogRel /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(960) int VMMDev::i_guestPropLoadAndConfigure(): timestampsOut.size() == cProps 00:00:02.343365 AssertLogRel /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(1157) static int VMMDev::drvConstruct(PPDMDRVINS, PCFGMNODE, uint32_t): RT_SUCCESS_NP(rc) 00:00:02.343450 VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3. 00:00:02.345073 PDM: Failed to construct 'VMMDev'/0! VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3. 00:00:02.347293 GIM: HyperV: Resetting MMIO2 regions and MSRs 00:00:02.531769 VMSetError: /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/VMM/VMMR3/VM.cpp(328) int VMR3Create(uint32_t, PCVMM2USERMETHODS, PFNVMATERROR, void *, PFNCFGMCONSTRUCTOR, void *, PVM *, PUVM *); rc=VERR_INTERNAL_ERROR_3 00:00:02.531778 VMSetError: Internal error no. 3. 00:00:02.533693 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Internal error no. 3. (VERR_INTERNAL_ERROR_3)}, preserve=false aResultDetail=-227 00:00:02.534000 Console: Machine state changed to 'PoweredOff' -------------------------------------------------------------------------------------------------------- This is the same error that shows when trying to run it on 12.1-STABLE-amd64-r359985 by the way. I am no wiz. And on top of that, VBox is extremely complex but I don't think that the problem lies on the kernel or on vbox kernel modules. They all load correctly and without errors on both 11.4-PRERELEASE-r360676M and 12.1-STABLE-amd64-r359985. What looks like (to my poor lame eyes) is that some revision change in userland "broke" the connection between vbox and its modules/drivers. So my quest is to try to pinpoint the changes between 11.3-STABLE-amd64-r359971 and 11.4-PRERELEASE-r360676M that made VirtualBox 6.0.8 stop working, and I was wondering if anyone here could give me some direction on how to accomplish that. Thanks for any advice. -- Mario Lobo FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] From owner-freebsd-hackers@freebsd.org Sat May 9 18:20:39 2020 Return-Path: Delivered-To: freebsd-hackers@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 842E32F25CD for ; Sat, 9 May 2020 18:20:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49KFqq0Tn1z49xD for ; Sat, 9 May 2020 18:20:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: by mailman.nyi.freebsd.org (Postfix) id 105522F25C4; Sat, 9 May 2020 18:20:39 +0000 (UTC) Delivered-To: hackers@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 1001A2F25C3; Sat, 9 May 2020 18:20:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KFqp0KRGz49x4; Sat, 9 May 2020 18:20:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 049IKBMI004667 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 May 2020 18:20:13 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lobo@bsd.com.br Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 049IK9KR081413 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 May 2020 01:20:09 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Find specific changes between revisions To: Mario Lobo , vbox@freebsd.org, hackers@freebsd.org, "freebsd-emulation@freebsd.org" References: From: Eugene Grosbein Message-ID: Date: Sun, 10 May 2020 01:20:08 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 49KFqp0KRGz49x4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.90)[ip: (-5.31), ipnet: 2a01:4f8::/29(-2.67), asn: 24940(-1.50), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 18:20:39 -0000 09.05.2020 23:41, Mario Lobo wrote: > Hi; > > I'm attempting to port VirtualBox 6.0.8 to FreeBSD. I managed do get it > working perfectly up to > > 11.3-STABLE-amd64-r359971. > > After an svn up to 11.4-PRERELEASE-r360676M, VirtualBox 6.0.8 no longer > works. Bringing world+kernel back to 11.3-STABLE-amd64-r359971 makes it > work again, despite whatever ports I've got installed on my machines. This > was tested on 2 physical machines (desktop and laptop) and it is true for > both. > > When starting a VM on 11.4-PRERELEASE-r360676M, the VM console window shows > up for 2 seconds and vanishes. Tha VM log shows this: > > -------------------------------------------------------------------------------------------------------- > 00:00:02.343339 AssertLogRel > /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(960) > int VMMDev::i_guestPropLoadAndConfigure(): timestampsOut.size() == cProps > 00:00:02.343365 AssertLogRel > /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(1157) > static int VMMDev::drvConstruct(PPDMDRVINS, PCFGMNODE, uint32_t): > RT_SUCCESS_NP(rc) > 00:00:02.343450 VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3. > 00:00:02.345073 PDM: Failed to construct 'VMMDev'/0! VERR_INTERNAL_ERROR_3 > (-227) - Internal error no. 3. > 00:00:02.347293 GIM: HyperV: Resetting MMIO2 regions and MSRs > 00:00:02.531769 VMSetError: > /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/VMM/VMMR3/VM.cpp(328) > int VMR3Create(uint32_t, PCVMM2USERMETHODS, PFNVMATERROR, void *, > PFNCFGMCONSTRUCTOR, void *, PVM *, PUVM *); rc=VERR_INTERNAL_ERROR_3 > 00:00:02.531778 VMSetError: Internal error no. 3. > 00:00:02.533693 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) > aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} > aText={Internal error no. 3. (VERR_INTERNAL_ERROR_3)}, preserve=false > aResultDetail=-227 > 00:00:02.534000 Console: Machine state changed to 'PoweredOff' > -------------------------------------------------------------------------------------------------------- > > This is the same error that shows when trying to run it on > 12.1-STABLE-amd64-r359985 by the way. > > I am no wiz. And on top of that, VBox is extremely complex but I don't > think that the problem lies on the kernel or on vbox kernel modules. They > all load correctly and without errors on both 11.4-PRERELEASE-r360676M and > 12.1-STABLE-amd64-r359985. > > What looks like (to my poor lame eyes) is that some revision change in > userland "broke" the connection between vbox and its modules/drivers. > > So my quest is to try to pinpoint the changes between > 11.3-STABLE-amd64-r359971 and 11.4-PRERELEASE-r360676M that made VirtualBox > 6.0.8 stop working, and I was wondering if anyone here could give me some > direction on how to accomplish that. > > Thanks for any advice. You did not mention if you rebuild VirtualBox and its kernel modules after update of FreeBSD to 11.4-PRERELEASE. If not, such behaviour is expected and first thing you need is rebuild VirtualBox using sources of 11.4-PRERELEASE installed in /usr/src. If you already did that, you need to bisect revisions. Also, you may find useful output of "svnlite help diff" that documents a way to find differences betwheen revisions: cd /usr/src/sys/some-subdir && svnlite diff -r NNNNNN:MMMMMM From owner-freebsd-hackers@freebsd.org Sat May 9 18:25:58 2020 Return-Path: Delivered-To: freebsd-hackers@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 734572F2863 for ; Sat, 9 May 2020 18:25:58 +0000 (UTC) (envelope-from ypankov@fastmail.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 49KFxy1Ltfz4BLB for ; Sat, 9 May 2020 18:25:58 +0000 (UTC) (envelope-from ypankov@fastmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 2E59D2F2862; Sat, 9 May 2020 18:25:58 +0000 (UTC) Delivered-To: hackers@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 2E2352F2861 for ; Sat, 9 May 2020 18:25:58 +0000 (UTC) (envelope-from ypankov@fastmail.com) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 49KFxx0XPFz4BL9 for ; Sat, 9 May 2020 18:25:56 +0000 (UTC) (envelope-from ypankov@fastmail.com) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1EDAD5E7; Sat, 9 May 2020 14:25:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 09 May 2020 14:25:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=h pht66kuHqJjfGQLiKYkPLDpKEvoMh7uH4Mn1/9GS0Q=; b=hWnbKj2YrKSM9dwn+ J+t9kh86j7XuPfy3jAhnePSpgxxmjSD1/kiqzNdSpcV6qJka09YgnViO/GloolTC mdLN6Z3AdU1Qyig8Jn9ac/kdCbgH5nClVXZHpH9s7jSQfVxpSvIMC3ILzNINbibl 2fQHXzVk06KRpUbX4SFQVlauCQj1c7kCq7wVhazJa3v0QfmI7keoqeJ0QEHATgAv acczj8IV81G9aoGGX5YDgz9nDJ17kxXNuKL7mRSG3OSfG6WGQL9LEBkLJ5uzICvW 1kxYvi+7uhbCA8FVxBH+qmo8nZ+qEkx2aGoOMOkw/0F4wgpHvCZYa0QIaYaS95P6 NpLHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=hpht66kuHqJjfGQLiKYkPLDpKEvoMh7uH4Mn1/9GS 0Q=; b=PPhThEoe6wfyBN5f9101queoH2ronB2v1GkNFl1hOnlT1ys3MhdE0lljV u4CNhpvRmHiWuDxg6BH8+FS7A2trJJFikF5CR43RX3NZVdyjOjNUAoxiWwAorFmo Vy+3fM17xRbxttHeSzp6JrS+HWr+GsUm6oWz6MyO3MC+7pi80Y3L0xq41a9OdNb1 DsyP0bojaBib5kZ1jNi/hYGYjg5XiOSDb07umIS8b7h7WnKNC8IEjz+LK6rWrWpk 3JsnSLJ+Awq4yzLpMYFmzZf853bjnUGR/2BXyT2qOifxaaYxFgsxhAJ/RZcH65Tg wwV9GycFQR7fTZqOZ79gfDIhUIjMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeehgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepjghurhhi ucfrrghnkhhovhcuoeihphgrnhhkohhvsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepveetieelgffhffegffetfeeitddtgfduteeguddvtdfggfeuffdtieet lefhgeetnecukfhppeeivddrudekfedrudekrdeifeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihphgrnhhkohhvsehfrghsthhmrghilhdr tghomh X-ME-Proxy: Received: from [192.168.1.6] (unknown [62.183.18.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 1057C3066240; Sat, 9 May 2020 14:25:52 -0400 (EDT) Subject: Re: Find specific changes between revisions To: Mario Lobo , hackers@freebsd.org References: From: Yuri Pankov Message-ID: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> Date: Sat, 9 May 2020 21:25:47 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.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: 49KFxx0XPFz4BL9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fastmail.com header.s=fm2 header.b=hWnbKj2Y; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=PPhThEoe; dmarc=pass (policy=none) header.from=fastmail.com; spf=pass (mx1.freebsd.org: domain of ypankov@fastmail.com designates 64.147.123.25 as permitted sender) smtp.mailfrom=ypankov@fastmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[fastmail.com:s=fm2,messagingengine.com:s=fm2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; FREEMAIL_FROM(0.00)[fastmail.com]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fastmail.com:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fastmail.com,none]; IP_SCORE(0.00)[ip: (-9.84), ipnet: 64.147.123.0/24(-4.92), asn: 11403(-2.69), country: US(-0.05)]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[25.123.147.64.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[25.123.147.64.rep.mailspike.net : 127.0.0.19]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[fastmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 18:25:58 -0000 Eugene Grosbein wrote: > 09.05.2020 23:41, Mario Lobo wrote: > >> Hi; >> >> I'm attempting to port VirtualBox 6.0.8 to FreeBSD. I managed do get it >> working perfectly up to >> >> 11.3-STABLE-amd64-r359971. >> >> After an svn up to 11.4-PRERELEASE-r360676M, VirtualBox 6.0.8 no longer >> works. Bringing world+kernel back to 11.3-STABLE-amd64-r359971 makes it >> work again, despite whatever ports I've got installed on my machines. This >> was tested on 2 physical machines (desktop and laptop) and it is true for >> both. >> >> When starting a VM on 11.4-PRERELEASE-r360676M, the VM console window shows >> up for 2 seconds and vanishes. Tha VM log shows this: >> >> -------------------------------------------------------------------------------------------------------- >> 00:00:02.343339 AssertLogRel >> /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(960) >> int VMMDev::i_guestPropLoadAndConfigure(): timestampsOut.size() == cProps >> 00:00:02.343365 AssertLogRel >> /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/Main/src-client/VMMDevInterface.cpp(1157) >> static int VMMDev::drvConstruct(PPDMDRVINS, PCFGMNODE, uint32_t): >> RT_SUCCESS_NP(rc) >> 00:00:02.343450 VERR_INTERNAL_ERROR_3 (-227) - Internal error no. 3. >> 00:00:02.345073 PDM: Failed to construct 'VMMDev'/0! VERR_INTERNAL_ERROR_3 >> (-227) - Internal error no. 3. >> 00:00:02.347293 GIM: HyperV: Resetting MMIO2 regions and MSRs >> 00:00:02.531769 VMSetError: >> /Vmachines/ports/emulators/virtualbox-ose/work/VirtualBox-6.0.8/src/VBox/VMM/VMMR3/VM.cpp(328) >> int VMR3Create(uint32_t, PCVMM2USERMETHODS, PFNVMATERROR, void *, >> PFNCFGMCONSTRUCTOR, void *, PVM *, PUVM *); rc=VERR_INTERNAL_ERROR_3 >> 00:00:02.531778 VMSetError: Internal error no. 3. >> 00:00:02.533693 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) >> aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} >> aText={Internal error no. 3. (VERR_INTERNAL_ERROR_3)}, preserve=false >> aResultDetail=-227 >> 00:00:02.534000 Console: Machine state changed to 'PoweredOff' >> -------------------------------------------------------------------------------------------------------- >> >> This is the same error that shows when trying to run it on >> 12.1-STABLE-amd64-r359985 by the way. >> >> I am no wiz. And on top of that, VBox is extremely complex but I don't >> think that the problem lies on the kernel or on vbox kernel modules. They >> all load correctly and without errors on both 11.4-PRERELEASE-r360676M and >> 12.1-STABLE-amd64-r359985. >> >> What looks like (to my poor lame eyes) is that some revision change in >> userland "broke" the connection between vbox and its modules/drivers. >> >> So my quest is to try to pinpoint the changes between >> 11.3-STABLE-amd64-r359971 and 11.4-PRERELEASE-r360676M that made VirtualBox >> 6.0.8 stop working, and I was wondering if anyone here could give me some >> direction on how to accomplish that. >> >> Thanks for any advice. > > You did not mention if you rebuild VirtualBox and its kernel modules after update of FreeBSD to 11.4-PRERELEASE. > If not, such behaviour is expected and first thing you need is rebuild VirtualBox using sources of 11.4-PRERELEASE > installed in /usr/src. > > If you already did that, you need to bisect revisions. Also, you may find useful output of "svnlite help diff" > that documents a way to find differences betwheen revisions: cd /usr/src/sys/some-subdir && svnlite diff -r NNNNNN:MMMMMM And if you are looking for the specific revision that broke it, look into the 'git bisect' using github's git mirror; there's also devel/p5-App-SVN-Bisect, but I have never used it. From owner-freebsd-hackers@freebsd.org Sat May 9 22:53:12 2020 Return-Path: Delivered-To: freebsd-hackers@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 9E29D2F7FB9 for ; Sat, 9 May 2020 22:53:12 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49KMtH6hPNz4Qh7 for ; Sat, 9 May 2020 22:53:11 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mailman.nyi.freebsd.org (Postfix) id E51C82F7FB7; Sat, 9 May 2020 22:53:11 +0000 (UTC) Delivered-To: hackers@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 E4CE32F7FB5 for ; Sat, 9 May 2020 22:53:11 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 49KMtG3C7rz4Qh5 for ; Sat, 9 May 2020 22:53:10 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-il1-x131.google.com with SMTP id c16so4934391ilr.3 for ; Sat, 09 May 2020 15:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kzTwCLvO7VVzpECDYndUpBtKWyLCyE8f6UP48NBsmz4=; b=BCts9QiVi2GcXavW7XQtQxQwPwRl3M51Pbd/X6Xz6ze6zf+SpslfG01VtCt+D7/djT uoeMw/Q2E0F9ys8T7IsV7PlcJet61tGgHXKuweKe8NxHiT5ezpS+OqJnMRus0525K9QY un3fDoMFc29Vhju/yecfgnaByxKCkFK/fPoa8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kzTwCLvO7VVzpECDYndUpBtKWyLCyE8f6UP48NBsmz4=; b=OJnX2KRKT5NO1CPeKoNBr8eci+yc5mgmYeDANR2J1YqnWt6U37NHkEt4qDaPYDlj3o RIbm53WeeVWYjWjb+a4aVV2yCQB6izsJdXo3yE/AqgE7giYTFHzLUmDctuOxVRU41YW3 nMAtmGV//3DnKAB0OngA9epk0ZUaDad3Rrp3ToBFFBNRM4sLO7Gnm5BrL8MCPM8zBKJg xMBQByPe3FOxuj8NoM/0klYbrwU5aF3WHf12JpW7VAaeBB3FYw48rId9QGJu8W3IP9zM zE5TAjyEFDRs41v6Y94ycCC9YTCcSG+JA1aYj++Z1UbFsF4Izh0h8jISfvxC8EW2rZUE sBkQ== X-Gm-Message-State: AGi0Puai9snEJaPQO4SKxmUkRWgrY+ai12sW1nNqPSdwZrGOHz6Zwcnp eDB5hei5X0OhoutQgriBrt1tvX8G+goRMpVubkHDxORIyJw= X-Google-Smtp-Source: APiQypJGuUBUhkhoC79npc4cFk8JMFGQZdfGl0CKsmFv39irtPVQ7VUd4QCEOImmyR0kRIv3rDoQ2cum3Zp+bmePaDA= X-Received: by 2002:a92:8f49:: with SMTP id j70mr9289665ild.117.1589064788405; Sat, 09 May 2020 15:53:08 -0700 (PDT) MIME-Version: 1.0 References: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> In-Reply-To: <614e0ff9-1adc-1634-5711-ca032d6260bf@fastmail.com> From: Mario Lobo Date: Sat, 9 May 2020 19:52:56 -0300 Message-ID: Subject: Re: Find specific changes between revisions To: hackers@freebsd.org, vbox@freebsd.org, "freebsd-emulation@freebsd.org" X-Rspamd-Queue-Id: 49KMtG3C7rz4Qh5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsd.com.br header.s=capeta header.b=BCts9QiV; dmarc=none; spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2607:f8b0:4864:20::131 as permitted sender) smtp.mailfrom=lobo@bsd.com.br X-Spamd-Result: default: False [-3.24 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[bsd.com.br]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.5.128.228,0.5.126.35]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsd.com.br:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.1.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.74)[ip: (-7.87), 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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SH_EMAIL_ZRD(0.00)[0.5.126.35,0.5.128.228] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 22:53:12 -0000 On Sat, May 9, 2020 at 3:25 PM Yuri Pankov wrote: > Eugene Grosbein wrote: > > 09.05.2020 23:41, Mario Lobo wrote: > > > >> Hi; > >> > >> I'm attempting to port VirtualBox 6.0.8 to FreeBSD. I managed do get it > >> working perfectly up to > >> > >> 11.3-STABLE-amd64-r359971. > [snip..] >> Thanks for any advice. > > > > You did not mention if you rebuild VirtualBox and its kernel modules > after update of FreeBSD to 11.4-PRERELEASE. > > If not, such behaviour is expected and first thing you need is rebuild > VirtualBox using sources of 11.4-PRERELEASE > > installed in /usr/src. > > > > If you already did that, you need to bisect revisions. Also, you may > find useful output of "svnlite help diff" > > that documents a way to find differences betwheen revisions: cd > /usr/src/sys/some-subdir && svnlite diff -r NNNNNN:MMMMMM > > And if you are looking for the specific revision that broke it, look > into the 'git bisect' using github's git mirror; there's also > devel/p5-App-SVN-Bisect, but I have never used it. > > The command: svn diff https://svn.freebsd.org/base/stable/11@359971 https://svn.freebsd.org/base/stable/11@360676 yielded a 170 Mbytes file!! It will be like looking for a needle in a haystack, in the dark, with just a hunch of where the needle was dropped. Well ... at least I have the haystack. Thanks everyone for the tips! -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!]