From owner-freebsd-current@freebsd.org Sat Dec 30 21:02:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD6F6EAC936 for ; Sat, 30 Dec 2017 21:02:49 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 D681B6D0F9 for ; Sat, 30 Dec 2017 21:02:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.209.229.136] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVOHE-0005LY-Eq for freebsd-current@freebsd.org; Sat, 30 Dec 2017 22:02:45 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id vBUL2hNB075905 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 30 Dec 2017 22:02:43 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id vBUL2hHD075904 for freebsd-current@freebsd.org; Sat, 30 Dec 2017 22:02:43 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Dec 2017 22:02:43 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20171230210243.GA75844@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.209.229.136 X-Mailman-Approved-At: Sun, 31 Dec 2017 00:45:56 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 21:02:50 -0000 --WYTEVAkct0FjGQmd Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >=20 > > $ vim sys/sys/libkern.h > > ... > > #define LIBKERN_LEN_BCD2BIN 154 > > #define LIBKERN_LEN_BIN2BCD 100 > > #define LIBKERN_LEN_HEX2ASCII 36 > >=20 > > static inline u_char > > bcd2bin(int bcd) > > { > >=20 > > KASSERT(bcd >=3D 0 && bcd < LIBKERN_LEN_BCD2BIN, > > ("invalid bcd %d", bcd)); > > return (bcd2bin_data[bcd]); > > } > >=20 > > Any idea what could be damaged the system and what to do or check before > > re-setup? >=20 > Show the backtrace. attached as JPG (sorry); matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --BXVAT5kNtrzKuDFl-- --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpH/vAACgkQR8z35Hb+ nRGUKg/+IQKn9QDKa9O2M/PtXZviHKHyYrpzkpFnRRjKzHuKX2uVtup5nsBM1ORu 06FxJvy7x2tzu51xbyuO4WvP/9/umNFxz8ym1lhLP+0SvdD9GpmzygFuDvGADxpG h185pxTflaVqk4r2M40CBoEXWDKs1yIMh6Bh6G9y+Pa44e/D04XmZGjCu/fk1TGx tEWIWVILhyCgWQbg4SF7IO6M3dIohJ1UUmQtgqDU/1XBQto7Mlv7vgM1Y1uWAN9y EwWezeLTe44XrMOqGjCFOiWJMPeIuod17OgiTr4SbcLI4DOR6taD/zFvmQbNjgAG xtOCUuAloJMv4REP+CUs4kqmmatQ24/QIhyCzNd8L45Lrj+YrqgzTIts8r2KzbK7 MCfMaBi3zpcSGwqEcXskLloRsu2eYS2Zkc1MMQzBtSBEzsEiEGCcnHbaa45ukHhY MPKKPRB1AYPh+YTSYpdxRiTdM+eOwaloJ5Q/UCQhEh8rolS11DBXR82L8CkbQeQp V5HvDZYyRJdc5IZaTARcKKKgqRYrx0Eaqgk6rVByN61zrmQIWejQS3KOe2eI0moD Z1A6feFkRg+O3G8VuQtxLzRzUTkyKPd7fZvLsyYGZ9lvmPj/UsBRE9P8atKhyXoX 8FHT1Lc6EpXjgFMOO50C7x9d+Xv+xX4LNQACjhkj2yTz3VfbeOk= =mlrl -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-current@freebsd.org Sun Dec 31 01:45:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82419EB9369 for ; Sun, 31 Dec 2017 01:45:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46D8079440 for ; Sun, 31 Dec 2017 01:45:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id d16so34863426itj.1 for ; Sat, 30 Dec 2017 17:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=08PFBGmyDrZFcFxXXIvgvjtzUunuhWmZkXbADpVZ+OA=; b=kCvurmRPP/xzcThph5imxmHI2rErqkmXjT8lURIDrHReAhQOX4kagj12qJEc/P90rz RaP8hQ0v3vB2gbvVGxabnLw9APY4S0pidHqy1jmyvs/6THT7HQOXD9VfhDDlZfTpahIS 19jvepeiwdkEVTAYEzQ8KQeYX19mGPBo6P7A+dRB8amlp3HCTJQJ0lIxxv30b5M0rljJ jKI752r5f0Valvuz5kWOEfJXiqXes1ccDvBNzriErywRXofKPK2zLB6QloRaYWvZtLfE r88531AGKwVLzavnPG2p4CJDv9XR2wNkcSYiBz1PxjujSHtLYFPq7UJL5mNukUxupsdr 5XIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=08PFBGmyDrZFcFxXXIvgvjtzUunuhWmZkXbADpVZ+OA=; b=Qdweo7tuxxmkoq7+Igl9uWz5tk5yeN/Ea53pnL7MRXO/EUCUsDBWZcBaY/JY8ob2UK iz7YVg1zIsf8oviH5zJ/sDopAn/cWFakmIAMxAXAJpuhalMD3/MbnIsKBE67Y29+KTAX iw04FvmeXkQfCyHadFVyx+sg1snEYQL6uFbbLheOdIHEZCn8LyAr7lsUtBrOR5s3bssX RtYk/142u+WUsqlgfbqSNLi4YGTg9YjN0WJdfwihZ5j/k5RLOOC3GQtl3mv3CaLOHJa8 dlB/cyRUkGtCiGmi9l5eGkYslMTb/3WZT64uN0DiHnCxRbFe81unJaf/PWqA7OMcDr8m hzmA== X-Gm-Message-State: AKGB3mI8pTfTwtS/DaF+pWmdyMZEC2Z+w5wuU60QyLUk8argUorv2tzb g/d6fA4L7HOsJTQu4i0YNPFGXCmhAqjjr8L9nGcMSA== X-Google-Smtp-Source: ACJfBourifYjoHMd1c69p6WW0t9IEIY5Z0Pf5Z4FG8j2z3jDbNn5nT4wAt66FAjIn8r6KPl1cLAQIJiPI6xKiELlGH0= X-Received: by 10.36.133.135 with SMTP id r129mr54428050itd.69.1514684735512; Sat, 30 Dec 2017 17:45:35 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 30 Dec 2017 17:45:34 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Sat, 30 Dec 2017 18:45:34 -0700 X-Google-Sender-Auth: psmpiAObyGyF1yfQ6nL5Tbt9ndQ Message-ID: Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 01:45:36 -0000 On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann wrote: > On most recent CURRENT I face the error shwon below on /tmp filesystem > (UFS2) residing > on a Samsung 850 Pro SSD: > > UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != > bp: 0xd9fba319 > handle_workitem_freefile: got error 5 while accessing filesystem > UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != bp: 0xd9fba319 > handle_workitem_freefile: got error 5 while accessing filesystem > UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != bp: 0xd9fba319 > handle_workitem_freefile: got error 5 while accessing filesystem > UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != bp: 0xd9fba319 > handle_workitem_freefile: got error 5 while accessing filesystem > UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > != bp: 0xd9fba319 > handle_workitem_freefile: got error 5 while accessing filesystem > > I've already formatted the /tmp filesystem, but obviously without any > success. > > Since I face such strange errors also on NanoBSD images dd'ed to SD cards, > I guess there > is something fishy ... It indicates a problem. We've seen these 'corruptions' on data in motion at work, but I hacked fsck to report checksum mismatches (it silently corrects them today) and we've not seen any mismatch when we unmount and fsck the filesystem. Warner From owner-freebsd-current@freebsd.org Sun Dec 31 08:36:36 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EBA7EAA89C for ; Sun, 31 Dec 2017 08:36:36 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 2E9E96901F; Sun, 31 Dec 2017 08:36:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.108.64] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVZ6d-0000qV-Fy; Sun, 31 Dec 2017 09:36:31 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id vBV8aP66002309 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Dec 2017 09:36:25 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id vBV8aOae002308; Sun, 31 Dec 2017 09:36:24 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 31 Dec 2017 09:36:24 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Cc: cem@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20171231083624.GA2175@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org, cem@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20171230214819.GA2191@c720-r314251> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.108.64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 08:36:36 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa s=C3=A1bado, diciembre 30, 2017 a las 10:48:19p. m. +0100, Matt= hias Apitz escribi=C3=B3: > El d=C3=ADa s=C3=A1bado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Ko= nstantin Belousov escribi=C3=B3: >=20 > > > > > static inline u_char > > > > > bcd2bin(int bcd) > > > > > { > > > > >=20 > > > > > KASSERT(bcd >=3D 0 && bcd < LIBKERN_LEN_BCD2BIN, > > > > > ("invalid bcd %d", bcd)); > > > > > return (bcd2bin_data[bcd]); > > > > > } > > > > >=20 > > For an immediate relief, enter the BIOS setup and set up the date. Try= to > > change it even if the BIOS date looks fine. > >=20 > > artc(4) should do more validation of the date read from CMOS, but this = is > > a known issue. >=20 > The problem with this hardware (Acer C720 Chromebook) is, there is no > BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older > CURRENT from an USB key r285885 boots fine. I have got a hint about that the problem showed up already in March this year, even with some comment of mine in this thread: http://freebsd.1045724.x6.nabble.com/panic-invalid-bcd-xxx-td6170480.html In this tread is mentioned a patch as: > cem@ posted this patch: > > http://dpaste.com/1K2W05E > > If someone can test it, I'll gladly commit it. The real-time clock will > likely be wrong, but it won't panic with INVARIANTS. but the link is expired. Has got someone this patch? I checked the SVN for the file sys/sys/libkern.h there is no relevant change since March 2017. (cc'ed cem@) I will let the C720 over night under power while sitting in the boot menu, maybe this will fix the RTC battery issue. Thanks matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpIoYIACgkQR8z35Hb+ nREclA/8Dmdz1l3xf9idYvmB/laFYWBu8C6Yv2aoVh5ibxnf0EM+jYLNsmVIrVTD JMK+vpBH43ood6bCXiYNW+Pkdi+uqPzqJI36+WjDDsggOd34bpat2mVIs6/TeS/u CY0J2myKJ/yRYLJv8tWiRtRVFucLnatEHvVZRlObYqtoGJvu76UGmoLzKD6JO+pV kaX1NBZJze8etRibLmk0lwdnYtYPcARTywdfdbeCzbtnXmtKFFcpIgVCKoixEAR6 bHte1klZTAiz3aJdgDYNOIZUoWXtS1PMYI64wZp/6X/Tkl5MrYZtMV8J3WVvIGrB sTZW2K4UK5K+nni/srHZ8id7titSbHXT6n8Ky7tblZm7va0l3r3WQrcquvhq3zRD P6A45R3MXlzCDiGDnyDNuJGAKk3KGYl2jFT3SHXaBsFVi5YXnZhzXAH22wPZWesr OY8fqd+H/7SXPrjUS3dlH9AgAtjRXlbScliSlvHIQ7Cj8IhksFZ8+sDMO5PnYyvn QphI1pYi/e+NnW3spkEeZLwSGxtmBMNvbWn5rXStpHofNHr/GXjeVjfY/4uciw9S D0VsNzlcqzPN0UpbIAVCrN7wp9F2Y3HB98bOgqUfKx76Lhr80wvssD/Hm++7PoXd OLIZ4u0Uwh81FbY+XHiYfy3MA1hf47MpnY6iDaQMVCqFmhqyo/o= =BOUA -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-current@freebsd.org Sun Dec 31 14:19:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 838BCEB70EF for ; Sun, 31 Dec 2017 14:19:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 51320746DA for ; Sun, 31 Dec 2017 14:19:31 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1514729961; bh=il3bO9KGySIgIUg6tyOWaVmT/AgNMJeaaG4isKP DnGo=; b=pEiBORuLJ3uNsJ98pTm4USjmoqVZX7wj/+OLnrbXariLvKen/los4k+ hmgjz5niu7chQFLhBecnt/v4ZNYzBdBWB7MacFFw48egR+djLjZYWN/grZ1VDVTC TEu2q/Tj9MAOe+iayqWaYkxEigbaGhuimiSQWxZIBbRwvQjw8RAc= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id EE4301F374 for ; Sun, 31 Dec 2017 09:19:21 -0500 (EST) To: freebsd-current From: Michael Butler Subject: SVN r327433 fails to build Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <8a05059f-5ece-7655-f661-4d53ebe760ee@protected-networks.net> Date: Sun, 31 Dec 2017 09:19:21 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 14:19:31 -0000 An include file change? I couldn't see the cause :-( The last successful build I have is at SVN r327392. ===> lib/libprocstat (obj,all,install) Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o In file included from /usr/src/lib/libprocstat/zfs.c:41: /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] #define curthread ((void *)(uintptr_t)thr_self()) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/pcpu.h:230:9: note: previous definition is here #define curthread (__curthread()) ^ In file included from /usr/src/lib/libprocstat/zfs.c:41: /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:236:9: error: 'curproc' macro redefined [-Werror,-Wmacro-redefined] #define curproc (&p0) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/pcpu.h:200:9: note: previous definition is here #define curproc (curthread->td_proc) ^ 2 errors generated. From owner-freebsd-current@freebsd.org Sun Dec 31 17:19:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41EC1E87E5C for ; Sun, 31 Dec 2017 17:19:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 269887B076 for ; Sun, 31 Dec 2017 17:19:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c70cde9c-ee4e-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c70cde9c-ee4e-11e7-8486-0934409070aa; Sun, 31 Dec 2017 17:19:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBVHJohu008329; Sun, 31 Dec 2017 10:19:50 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514740790.12000.20.camel@freebsd.org> Subject: Re: panic: invalid bcd 194 From: Ian Lepore To: Matthias Apitz , freebsd-current@freebsd.org Cc: cem@freebsd.org Date: Sun, 31 Dec 2017 10:19:50 -0700 In-Reply-To: <20171231083624.GA2175@c720-r314251> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 17:19:59 -0000 On Sun, 2017-12-31 at 09:36 +0100, Matthias Apitz wrote: > El día sábado, diciembre 30, 2017 a las 10:48:19p. m. +0100, Matthias Apitz escribió: > > > > > El día sábado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Konstantin Belousov escribió: > > > > > > > > > > > > > > > > > > > > > > > > > > static inline u_char > > > > > > bcd2bin(int bcd) > > > > > > { > > > > > > > > > > > >         KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN, > > > > > >             ("invalid bcd %d", bcd)); > > > > > >         return (bcd2bin_data[bcd]); > > > > > > } > > > > > > > > > > > > > > For an immediate relief, enter the BIOS setup and set up the date.  Try to > > > change it even if the BIOS date looks fine. > > > > > > artc(4) should do more validation of the date read from CMOS, but this is > > > a known issue. > > The problem with this hardware (Acer C720 Chromebook) is, there is no > > BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older > > CURRENT from an USB key r285885 boots fine. > > I have got a hint about that the problem showed up already in March this > year, even with some comment of mine in this thread: > > http://freebsd.1045724.x6.nabble.com/panic-invalid-bcd-xxx-td6170480.html > > In this tread is mentioned a patch as: > > > > > cem@ posted this patch: > > > > http://dpaste.com/1K2W05E > > > > If someone can test it, I'll gladly commit it.  The real-time clock will > > likely be wrong, but it won't panic with INVARIANTS. > but the link is expired. Has got someone this patch? I checked the SVN > for the file sys/sys/libkern.h there is no relevant change since March > 2017. (cc'ed cem@) > > I will let the C720 over night under power while sitting in the boot menu, > maybe this will fix the RTC battery issue. > Last time I worked on RTC stuff, cleaning this up got put on my "to-do some day" list.  I think maybe that day has arrived. -- Ian From owner-freebsd-current@freebsd.org Sun Dec 31 17:35:29 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89947E88B5B for ; Sun, 31 Dec 2017 17:35:29 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:191:217b::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A1237BDA2; Sun, 31 Dec 2017 17:35:29 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sun, 31 Dec 2017 18:35:24 +0100 Message-ID: <87h8s6kdgj.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Cc: Colin Percival Subject: Re: SVN r327433 fails to build In-Reply-To: <8a05059f-5ece-7655-f661-4d53ebe760ee@protected-networks.net> References: <8a05059f-5ece-7655-f661-4d53ebe760ee@protected-networks.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/27.0 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 17:35:29 -0000 On Sun, 31 Dec 2017 15:19:21 +0100, Michael Butler wrote: > > An include file change? I couldn't see the cause :-( > > The last successful build I have is at SVN r327392. > > ===> lib/libprocstat (obj,all,install) > Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o > In file included from /usr/src/lib/libprocstat/zfs.c:41: > /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: > error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] > #define curthread ((void *)(uintptr_t)thr_self()) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/machine/pcpu.h:230:9: note: > previous definition is here > #define curthread (__curthread()) > ^ > In file included from /usr/src/lib/libprocstat/zfs.c:41: > /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:236:9: > error: 'curproc' macro redefined [-Werror,-Wmacro-redefined] > #define curproc (&p0) > ^ > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/pcpu.h:200:9: note: > previous definition is here > #define curproc (curthread->td_proc) > ^ > 2 errors generated. This is caused by ------------------------------------------------------------------------ r327429 | cperciva | 2017-12-31 10:23:35 +0100 (Sun, 31 Dec 2017) | 2 lines Use the TSLOG framework to record entry/exit timestamps for VFS_MOUNT calls. ------------------------------------------------------------------------ -- Herbert From owner-freebsd-current@freebsd.org Sun Dec 31 14:52:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3073EB836C for ; Sun, 31 Dec 2017 14:52:07 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD22F75C40 for ; Sun, 31 Dec 2017 14:52:07 +0000 (UTC) (envelope-from roberthuff@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=J4Po10vS c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=L9H7d07YOLsA:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=ocR9PWop10UA:10 a=48faUk6PgeAA:10 a=6I5d2MoRAAAA:8 a=3LOkG46v6TquNeLeCnkA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=softfail; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received-SPF: softfail (smtp03.rcn.cmh.synacor.com: transitional domain rcn.com does not designate 209.6.230.48 as permitted sender) Received: from [209.6.230.48] ([209.6.230.48:20446] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id 7A/B2-29864-FD4F84A5; Sun, 31 Dec 2017 09:31:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23112.62686.547645.588013@jerusalem.litteratus.org> Date: Sun, 31 Dec 2017 09:31:58 -0500 To: Shawn Webb Cc: Michael Gmelin , freebsd-current@freebsd.org Subject: Re: evdev broken In-Reply-To: <20171229201207.hh7ghu2b7ca7ome4@mutt-hbsd> References: <20171229201207.hh7ghu2b7ca7ome4@mutt-hbsd> X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd12.0) X-Mailman-Approved-At: Sun, 31 Dec 2017 18:53:46 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 14:52:08 -0000 Shawn Webb writes: > > > > It looks like evdev support in the kernel is broken. > > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > > > different evdev-related symbols. > > > > > > > > I have the following options in my kernel config: > > > > > > > > options EVDEV_SUPPORT > > > > options EVDEV_DEBUG > > > > options UINPUT_DEBUG > > > > > > Did you add "device evdev"? > > > > Good catch! I did not. Adding now and I'll report back when > > buildkernel finishes. > > That did the trick. Thanks! > > Seems like evdev doesn't have a manpage, which is why I didn't > know to include it in my kernel config. On a system running: FreeBSD 12.0-CURRENT #0 r326723: Sat Dec 9 12:30:04 EST 2017 amd64 there is a man page, in section 4x. That's the good news. The bad news is I see no mention of needing to add anything to the kernel; it's presented as a Xorg input device. Reported as "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224793". Respectfully, Robert Huff From owner-freebsd-current@freebsd.org Sun Dec 31 20:24:22 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58703EA5D75 for ; Sun, 31 Dec 2017 20:24:22 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with ESMTP id 14D482918 for ; Sun, 31 Dec 2017 20:24:21 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 48623 invoked from network); 31 Dec 2017 20:12:50 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 31 Dec 2017 20:12:50 -0000 Received: (qmail 67579 invoked from network); 31 Dec 2017 20:17:33 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 31 Dec 2017 20:17:33 -0000 Subject: Re: SVN r327433 fails to build To: "Herbert J. Skuhra" , freebsd-current@freebsd.org, Michael Butler References: <8a05059f-5ece-7655-f661-4d53ebe760ee@protected-networks.net> <87h8s6kdgj.wl-herbert@gojira.at> From: Colin Percival Message-ID: <53dabd1e-b460-cb78-9279-5c42a441760f@freebsd.org> Date: Sun, 31 Dec 2017 12:17:33 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <87h8s6kdgj.wl-herbert@gojira.at> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 20:24:22 -0000 On 12/31/17 09:35, Herbert J. Skuhra wrote: > On Sun, 31 Dec 2017 15:19:21 +0100, > Michael Butler wrote: >> >> ===> lib/libprocstat (obj,all,install) >> Building /usr/obj/usr/src/amd64.amd64/lib/libprocstat/zfs/zfs.o >> In file included from /usr/src/lib/libprocstat/zfs.c:41: >> /usr/src/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:217:9: >> error: 'curthread' macro redefined [-Werror,-Wmacro-redefined] > > This is caused by > > ------------------------------------------------------------------------ > r327429 | cperciva | 2017-12-31 10:23:35 +0100 (Sun, 31 Dec 2017) | 2 lines > > Use the TSLOG framework to record entry/exit timestamps for VFS_MOUNT calls. > > ------------------------------------------------------------------------ Oops! It never occurred to me that I had to worry about userland programs defining _KERNEL and then including kernel headers... I think I know how to fix this, just testing now. Thanks, -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Sun Dec 31 21:02:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E92A9EA754A for ; Sun, 31 Dec 2017 21:02:59 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with ESMTP id A5F5F3D43 for ; Sun, 31 Dec 2017 21:02:58 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 49958 invoked from network); 31 Dec 2017 20:58:09 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 31 Dec 2017 20:58:09 -0000 Received: (qmail 67751 invoked from network); 31 Dec 2017 21:02:55 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 31 Dec 2017 21:02:55 -0000 Subject: Re: SVN r327433 fails to build To: "Herbert J. Skuhra" , freebsd-current@freebsd.org, Michael Butler References: <8a05059f-5ece-7655-f661-4d53ebe760ee@protected-networks.net> <87h8s6kdgj.wl-herbert@gojira.at> <53dabd1e-b460-cb78-9279-5c42a441760f@freebsd.org> From: Colin Percival Message-ID: Date: Sun, 31 Dec 2017 13:02:55 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <53dabd1e-b460-cb78-9279-5c42a441760f@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 21:03:00 -0000 On 12/31/17 12:17, Colin Percival wrote: > Oops! It never occurred to me that I had to worry about userland programs > defining _KERNEL and then including kernel headers... I think I know how to > fix this, just testing now. Should be fixed now. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Sun Dec 31 21:32:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90CA7EA871E for ; Sun, 31 Dec 2017 21:32:16 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6138364310; Sun, 31 Dec 2017 21:32:15 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1514755932; bh=c2e4rmCl1QVeMuSotqZQqnU6d+Fqk0RSR2Dovi9 TFMw=; b=kb2+pMyibDzqCkFhIBSL5WQOv61C5SSZjyw4SUaNp3OxN+sBDjtpa80 w3Q9XN6drdwafJHXVUMNiiwDicpERFdk74ZlDorctOLowIdBqn5f2CCx1BdJKoCi a4/70YbUvtI145s/sd934/oiHcbIU/yGB1elibcQsqeuSKpaQfW4= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id DF73C2A01D; Sun, 31 Dec 2017 16:32:12 -0500 (EST) To: freebsd-current , gonzo@freebsd.org From: Michael Butler Subject: SVN r327444 breaks current build Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> Date: Sun, 31 Dec 2017 16:32:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 21:32:16 -0000 Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o --- vt_termcolors.o --- /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many arguments to function call, expected 4, have 5 if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, &g, &b) == 0) { ~~~~~~~~~~~~~~~~~~~~ ^~ /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: 'vt_parse_rgb_triplet' declared here static int ^ 1 error generated. *** [vt_termcolors.o] Error code 1 .. second time today a commit wasn't tested before commit :-( imb From owner-freebsd-current@freebsd.org Sun Dec 31 21:54:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52D50EA9414 for ; Sun, 31 Dec 2017 21:54:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 3442A64D99 for ; Sun, 31 Dec 2017 21:54:19 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ef8018a2-ee74-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ef8018a2-ee74-11e7-93a5-cd02e7dc7692; Sun, 31 Dec 2017 21:52:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBVLrA0H008728; Sun, 31 Dec 2017 14:53:10 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514757190.12000.23.camel@freebsd.org> Subject: Re: SVN r327444 breaks current build From: Ian Lepore To: Michael Butler , freebsd-current , gonzo@freebsd.org Date: Sun, 31 Dec 2017 14:53:10 -0700 In-Reply-To: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 21:54:20 -0000 On Sun, 2017-12-31 at 16:32 -0500, Michael Butler wrote: > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > --- vt_termcolors.o --- > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > arguments to function call, expected 4, have 5 >                         if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > &g, &b) == 0) { >                             ~~~~~~~~~~~~~~~~~~~~ >   ^~ > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > 'vt_parse_rgb_triplet' declared here > static int > ^ > 1 error generated. > *** [vt_termcolors.o] Error code 1 > > .. second time today a commit wasn't tested before commit :-( > > imb Fixed in r327449. -- Ian From owner-freebsd-current@freebsd.org Sun Dec 31 22:22:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBDBDEAA719 for ; Sun, 31 Dec 2017 22:22:43 +0000 (UTC) (envelope-from gonzo@freebsd.org) 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 A0F5465FF3 for ; Sun, 31 Dec 2017 22:22:43 +0000 (UTC) (envelope-from gonzo@freebsd.org) 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.89 (FreeBSD)) (envelope-from ) id 1eVm03-000GKM-Ps; Sun, 31 Dec 2017 14:22:36 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id vBVMMZii062765; Sun, 31 Dec 2017 14:22:35 -0800 (PST) (envelope-from gonzo@freebsd.org) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@freebsd.org using -f Date: Sun, 31 Dec 2017 14:22:35 -0800 From: Oleksandr Tymoshenko To: Michael Butler Cc: freebsd-current Subject: Re: SVN r327444 breaks current build Message-ID: <20171231222235.GA62313@bluezbox.com> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) 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: Michael Butler (imb@protected-networks.net) wrote: > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > --- vt_termcolors.o --- > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: err [...] 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 22:22:43 -0000 Michael Butler (imb@protected-networks.net) wrote: > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > --- vt_termcolors.o --- > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > arguments to function call, expected 4, have 5 > if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > &g, &b) == 0) { > ~~~~~~~~~~~~~~~~~~~~ > ^~ > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > 'vt_parse_rgb_triplet' declared here > static int > ^ > 1 error generated. > *** [vt_termcolors.o] Error code 1 > > .. second time today a commit wasn't tested before commit :-( > > imb Should be fixed in r327449. It was a sloppy job, I was making iterative improvements to the original patch following review feedback and used out-of-tree testcases for actual testing. I appologize for the breakage. -- gonzo From owner-freebsd-current@freebsd.org Sun Dec 31 22:48:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7354CEAB854 for ; Sun, 31 Dec 2017 22:48:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 5E9A667D06 for ; Sun, 31 Dec 2017 22:48:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-75-82-218-62.socal.res.rr.com [75.82.218.62]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vBVMbWi7029488 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 31 Dec 2017 14:37:33 -0800 Subject: Re: SVN r327444 breaks current build To: freebsd-current@freebsd.org References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> <20171231222235.GA62313@bluezbox.com> From: Nathan Whitehorn Message-ID: Date: Sun, 31 Dec 2017 14:37:32 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171231222235.GA62313@bluezbox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVa2LlaHJCJ2e/nw2ICFt/7AuH7GyBv6mDW+JJS7ORJOQw7p1x/UayYo6yifQBB294uiEir/SpBu0SGrprj93s3+OyfVjrK2L9g= X-Sonic-ID: C;5uP3MHvu5xGsFc8r2KTi7g== M;4KhRMXvu5xGsFc8r2KTi7g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 22:48:03 -0000 On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > Michael Butler (imb@protected-networks.net) wrote: >> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o >> --- vt_termcolors.o --- >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many >> arguments to function call, expected 4, have 5 >> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, >> &g, &b) == 0) { >> ~~~~~~~~~~~~~~~~~~~~ >> ^~ >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: >> 'vt_parse_rgb_triplet' declared here >> static int >> ^ >> 1 error generated. >> *** [vt_termcolors.o] Error code 1 >> >> .. second time today a commit wasn't tested before commit :-( >> >> imb > Should be fixed in r327449. It was a sloppy job, I was making iterative > improvements to the original patch following review feedback and used > out-of-tree testcases for actual testing. I appologize for the breakage. > Still broken with GCC. /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function declaration isn't a prototype [-Wstrict-prototypes] *** [vt_termcolors.o] Error code 1 -Nathan From owner-freebsd-current@freebsd.org Sun Dec 31 23:53:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B3F0EADBB2 for ; Sun, 31 Dec 2017 23:53:34 +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 3030969A0B; Sun, 31 Dec 2017 23:53:33 +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.89 (FreeBSD)) (envelope-from ) id 1eVnQ2-000GUZ-O8; Sun, 31 Dec 2017 15:53:32 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id vBVNrURa063398; Sun, 31 Dec 2017 15:53:30 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 31 Dec 2017 15:53:30 -0800 From: Oleksandr Tymoshenko To: Nathan Whitehorn Cc: freebsd-current@freebsd.org Subject: Re: SVN r327444 breaks current build Message-ID: <20171231235330.GA63368@bluezbox.com> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> <20171231222235.GA62313@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) 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: Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > Michael Butler (imb@protected-networks.net) wrote: > >> Building /usr/obj/usr/src/amd64.amd64/ [...] 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 23:53:34 -0000 Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > Michael Butler (imb@protected-networks.net) wrote: > >> Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > >> --- vt_termcolors.o --- > >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > >> arguments to function call, expected 4, have 5 > >> if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > >> &g, &b) == 0) { > >> ~~~~~~~~~~~~~~~~~~~~ > >> ^~ > >> /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > >> 'vt_parse_rgb_triplet' declared here > >> static int > >> ^ > >> 1 error generated. > >> *** [vt_termcolors.o] Error code 1 > >> > >> .. second time today a commit wasn't tested before commit :-( > >> > >> imb > > Should be fixed in r327449. It was a sloppy job, I was making iterative > > improvements to the original patch following review feedback and used > > out-of-tree testcases for actual testing. I appologize for the breakage. > > > Still broken with GCC. > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function > declaration isn't a prototype [-Wstrict-prototypes] > *** [vt_termcolors.o] Error code 1 *sigh* Should be fixed in r327454. Thanks for reporting I wonder if we can get clang to be more strict about declarations/prototypes/etc to match gcc's expectations. I understand that it's developers' responsibility to make sure that kernel is GCC-buildable but if raising red flag for some of the cases when compiling with clang reduced number of these breakages that it'd be an improvement. -- gonzo From owner-freebsd-current@freebsd.org Mon Jan 1 00:00:08 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03BB7EAE022 for ; Mon, 1 Jan 2018 00:00:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 DA91C69BFF for ; Mon, 1 Jan 2018 00:00:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a9e539ad-ee86-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id a9e539ad-ee86-11e7-93a5-cd02e7dc7692; Sun, 31 Dec 2017 23:59:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w01005RJ008961; Sun, 31 Dec 2017 17:00:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514764805.12000.26.camel@freebsd.org> Subject: Re: SVN r327444 breaks current build From: Ian Lepore To: Oleksandr Tymoshenko , Nathan Whitehorn Cc: freebsd-current@freebsd.org Date: Sun, 31 Dec 2017 17:00:05 -0700 In-Reply-To: <20171231235330.GA63368@bluezbox.com> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> <20171231222235.GA62313@bluezbox.com> <20171231235330.GA63368@bluezbox.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 00:00:08 -0000 On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote: > Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > > > > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > > > > > Michael Butler (imb@protected-networks.net) wrote: > > > > > > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > > > > --- vt_termcolors.o --- > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > > > > arguments to function call, expected 4, have 5 > > > >                          if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > > > > &g, &b) == 0) { > > > >                              ~~~~~~~~~~~~~~~~~~~~ > > > >    ^~ > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > > > > 'vt_parse_rgb_triplet' declared here > > > > static int > > > > ^ > > > > 1 error generated. > > > > *** [vt_termcolors.o] Error code 1 > > > > > > > > .. second time today a commit wasn't tested before commit :-( > > > > > > > > imb > > > Should be fixed in r327449. It was a sloppy job, I was making iterative > > > improvements to the original patch following review feedback and used > > > out-of-tree testcases for actual testing. I appologize for the breakage. > > > > > Still broken with GCC. > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function  > > declaration isn't a prototype [-Wstrict-prototypes] > > *** [vt_termcolors.o] Error code 1 > *sigh* Should be fixed in r327454. Thanks for reporting > > I wonder if we can get clang to be more strict about > declarations/prototypes/etc to match gcc's expectations. I understand > that it's developers' responsibility to make sure that kernel > is GCC-buildable but if raising red flag for some of the cases > when compiling with clang reduced number of these breakages > that it'd be an improvement. > I think we can get clang to do that with -Wstrict-prototypes, but I'm not sure when that option appeared in terms of clang version, and the clang site doesn't seem to provide documentation for anything other than the current in-development version. -- Ian From owner-freebsd-current@freebsd.org Mon Jan 1 05:09:15 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6832AE80B59 for ; Mon, 1 Jan 2018 05:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E62B77AC94 for ; Mon, 1 Jan 2018 05:09:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id v21so35279579wrc.0 for ; Sun, 31 Dec 2017 21:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RW8qbthCmMErd7fqQCES+3Ewx4XCqJekmFsbGnZXGw4=; b=HFWW2WS131INepzEbIDKiQ240+o5YuzZcha0brSluLWhi3NuiDm6ICfad0oi7rIq0X xXOoKCTRVDDu+5u3bkWAUlmffn1LvWDbpGsX0wJnYDYTR5qJ+n/Vm2TH8fyO2+S7vqWc C2H44gIG0MI37vM6aGiRCCxwD1+a/W6AVouPirNR3GEE6+B9gk1tEON8D9hJ5e60WMEL uPIf3VkRPpNWRbegDh1yxPqw4C1cwKCfmAoyNuUD6JZ9TwZRYF9ELpKNb6yB4gZkX+Ox g40nte5H0LJFegyJlIb73KyX+q8RlEOyTRDYDMclU/8CbWyZXsNvB+g0nKy+RriH+4iB SOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RW8qbthCmMErd7fqQCES+3Ewx4XCqJekmFsbGnZXGw4=; b=l/MbwBYHjmV0c+MPT46nAAGpApvuzbKgm+gEOorrHg1Fp6xzINgp7ccbqRJ9mY30YA 2ecdPVh8bnJr4YNkylhrqJkBRUaovcnUK3hWkEd1J1xIj1HgTX6NnpHeeq4OlFCfIQUP xDsv6IMQJYAObYTittbHri4swB/Dltl0OAyzrGA5g4PgyAe407eP+6eJRewReOtzIWc+ udAr0U7Bspmg8ikgBjCmbX2FRBpIiaDOz7YUDGYK2VlqNx/47bJ56vbuSPEdbMpQeZrd bPcb4YwZ9hVOECnPZ3OfJYYuCNVqvLD2kOwG9644jPQe6BxBtbgdrLE2GCT67q5GKhX9 N+bg== X-Gm-Message-State: AKGB3mLlWuqiDNtYr7sChLqhF/tV/jZJuboI7yS5weT6fSb3rd2SgsOp FxJdTVgsDXE3W6+H6SvNb+KgUUAOPmtk3X1hVGQ= X-Google-Smtp-Source: ACJfBottwThFUjQZ1Vw5IVa34xpUYdcXDDUyvAUsvrura+ve+cRaBg7gyxn5L9qgsv/BAqpKqm41nKjjMi325Mm9wac= X-Received: by 10.223.177.143 with SMTP id q15mr10088981wra.42.1514783353277; Sun, 31 Dec 2017 21:09:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.213.11 with HTTP; Sun, 31 Dec 2017 21:09:12 -0800 (PST) In-Reply-To: <20171230082812.GL1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> From: Adrian Chadd Date: Sun, 31 Dec 2017 21:09:12 -0800 Message-ID: Subject: Re: Programmatically cache line To: Konstantin Belousov Cc: blubee blubeeme , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 05:09:15 -0000 On 30 December 2017 at 00:28, Konstantin Belousov wrote: > On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: >> Is there some way to programmatically get the CPU cache line sizes on >> FreeBSD? > > There are, all of them are MD. > > On x86, the CPUID instruction leaf 0x1 returns the information in > %ebx register. Hm, weird. Why don't we extend sysctl to include this info? -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jan 1 06:52:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0980EAE8EE for ; Mon, 1 Jan 2018 06:52:43 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93B6D1A0B for ; Mon, 1 Jan 2018 06:52:42 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from pc26.home (ABordeaux-656-1-1-174.w90-38.abo.wanadoo.fr [90.38.32.174]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w016qbSw061665 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 06:52:38 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host ABordeaux-656-1-1-174.w90-38.abo.wanadoo.fr [90.38.32.174] claimed to be pc26.home Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Programmatically cache line From: David Chisnall In-Reply-To: Date: Mon, 1 Jan 2018 06:52:37 +0000 Cc: Konstantin Belousov , blubee blubeeme , FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> References: <20171230082812.GL1684@kib.kiev.ua> To: Adrian Chadd X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 06:52:44 -0000 On 1 Jan 2018, at 05:09, Adrian Chadd wrote: >=20 > On 30 December 2017 at 00:28, Konstantin Belousov = wrote: >> On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: >>> Is there some way to programmatically get the CPU cache line sizes = on >>> FreeBSD? >>=20 >> There are, all of them are MD. >>=20 >> On x86, the CPUID instruction leaf 0x1 returns the information in >> %ebx register. >=20 > Hm, weird. Why don't we extend sysctl to include this info? It would be nice to expose this kind of information via VDSO or similar. = There are a lot of similar bits of info that people want to use for = ifunc and, SVE is going to have a bunch of similar requirements. David From owner-freebsd-current@freebsd.org Mon Jan 1 08:54:35 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 920CFE87D2A for ; Mon, 1 Jan 2018 08:54:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4AE0364806; Mon, 1 Jan 2018 08:54:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.127.132] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVvrW-0004vs-6H; Mon, 01 Jan 2018 09:54:26 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id w018sPYF002349 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 09:54:25 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id w018sPKx002348; Mon, 1 Jan 2018 09:54:25 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 1 Jan 2018 09:54:25 +0100 From: Matthias Apitz To: Ian Lepore Cc: freebsd-current@freebsd.org, cem@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180101085425.GA2301@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Ian Lepore , freebsd-current@freebsd.org, cem@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <1514740790.12000.20.camel@freebsd.org> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.127.132 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 08:54:35 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa domingo, diciembre 31, 2017 a las 10:19:50a. m. -0700, Ian Lepo= re escribi=C3=B3: > > I will let the C720 over night under power while sitting in the boot me= nu, > > maybe this will fix the RTC battery issue. > >=20 >=20 > Last time I worked on RTC stuff, cleaning this up got put on my "to-do > some day" list. =C2=A0I think maybe that day has arrived. >=20 > -- Ian For the moment we solved the issue by booting some older r28nnnn memstick, writing a correct date with ntpdate into the RTC and rebooted without poweroff. It seems that the RTC survives even some short powercyle. The CMOS battery is soldered on the motherboard of the Acer C720, i.e. no chance to be replaced. The issue must be fixed in FreeBSD, i.e. it should boot even with a broken RTC. Should I file a PR for this? I'm happy to test any patch for this. matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpJ9z4ACgkQR8z35Hb+ nRGvug//cA1VnSqV04xOPlIOd8paIJHrnoCeEgY0KoDjc2xYJbvDIk6tJ6Sv79tG LjsmdVVeQ5JLKPe9xc239YL9fNlEzo0HnXiQ3LRWowQdLS5UcZoGvQpn8xEXncw2 xpW9vMd+RrZdFzfWt1KRsGuhhtwlHei75/nfo2Jc5smOfYAaJorGjAPxjk9QeLfj 9L9lzfLctDHY/HJZNlfcmVyIkbcdr0ngfW1i/hCWrE2jA3sY76NqdhO0fYBASD6U zX6qkssvcPoXj+TWYe1vizlSrlDHmhCRz6V0wpmDI3sb6AxZLlgeO2w+IVuQIPtm VbUVO6QZpWdfdps8pyoy8SG3SNyBKSBaIuZ4HgGYyXoNz3097Ka6G0Uy8U9++eZQ df5eG8FG0vSlhLJDTn5B5rBgVBsYiXu3hfm/S/oDdOVtKCy92aT6i9vYPCXVl9dX aD49KaOFAEj+Ke4GuhxAO3sAyJfokbxpjOnTJehonesAL+TJ+rWXcRaq52O2lVfs X/aYOluJgdbnvQEzgzOpayqrCHiUNTGJaVkXAU18qyGNAZdWO1wthYqpkTbx0xEA MOdN4jd3d7cIUNOjs7TtrrlLN7PxmIK0l7qepqp+KmPsF/Z0KvYYK+nMZ5yINOic tZGNkLk3uGbGXDqdtWn0QjuzNPLm5PteHllISoGp4T+HiVDE9TQ= =of+u -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@freebsd.org Mon Jan 1 08:57:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A65A7E87FC7 for ; Mon, 1 Jan 2018 08:57:24 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 6D8B9649BA for ; Mon, 1 Jan 2018 08:57:24 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eVvuN-000HiG-BP; Mon, 01 Jan 2018 09:57:23 +0100 Date: Mon, 1 Jan 2018 09:57:23 +0100 From: Kurt Jaeger To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180101085723.GM2827@home.opsec.eu> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180101085425.GA2301@c720-r314251> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 08:57:24 -0000 Hi! > For the moment we solved the issue by booting some older r28nnnn > memstick, writing a correct date with ntpdate into the RTC and rebooted > without poweroff. It seems that the RTC survives even some short > powercyle. > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e. > no chance to be replaced. > > The issue must be fixed in FreeBSD, i.e. it should boot even with a > broken RTC. Should I file a PR for this? Yes, please file a PR. -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Mon Jan 1 09:12:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86CCBE88EAC for ; Mon, 1 Jan 2018 09:12:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 460166547C for ; Mon, 1 Jan 2018 09:12:14 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.127.132] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVw8h-00066l-LM; Mon, 01 Jan 2018 10:12:11 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id w019CATN002616 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 10:12:10 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id w019CASk002615; Mon, 1 Jan 2018 10:12:10 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 1 Jan 2018 10:12:10 +0100 From: Matthias Apitz To: Kurt Jaeger Cc: freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180101091210.GA2591@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Kurt Jaeger , freebsd-current@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <20180101085723.GM2827@home.opsec.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20180101085723.GM2827@home.opsec.eu> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.127.132 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 09:12:14 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa lunes, enero 01, 2018 a las 09:57:23a. m. +0100, Kurt Jaeger es= cribi=C3=B3: > Hi! >=20 > > For the moment we solved the issue by booting some older r28nnnn > > memstick, writing a correct date with ntpdate into the RTC and rebooted > > without poweroff. It seems that the RTC survives even some short > > powercyle. > >=20 > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e. > > no chance to be replaced. > >=20 > > The issue must be fixed in FreeBSD, i.e. it should boot even with a > > broken RTC. Should I file a PR for this? >=20 > Yes, please file a PR. done. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224813 --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpJ+2cACgkQR8z35Hb+ nRFWehAAmdUBkrnnQzU2ftzPidrvsj9WSJZ1y+u0VYNE4nIGbz2wnXVfyJFPX2ov MoAvyh/NOyuOE6N0ALbu/2F4WT6ElcxT2Vq9sAspSPBQjiLl9v2JBIEpOOHizxmp Uxr/RZHBlEUb8xB1oDD2Fe3AOi9Csj0W/QF4ZG3ovPHgKtGjHunILbt6X0Kw3KNr t0L6ZspjWt+WNuwJ0pb01IAhllHMG3EA3TRXoB18qOJx3XMqPPMC2awOqbL/R1GV uB/vGPSujjb5MqHzwOhUi32z2GxcMKrgM++FFx44stra94nSqr0ORRwz66OpfVDK Maq0Sp6+hfuGkX61ZqN04Ea87qU9QtnnHEBASP1s8awtFGZ+2ig8QLkdhQ4Ol0wB RBOzatLtatiYxnSx7IcZKldxNl/YOH0oUxx6ADaJwL2BS4MBZ0pgf0CnrKiors5R n/S054kQLNn6M+az/k3XKkNAkQeRR3WrhmPu8K721+v7R8GKivIdMm7TfaV5oXGz JUCt/W3I/o4BwT5JDkgsisYZkBWD7s1isa2ZJvI1Ul3ZCoPNOtS67oWyL7vI/Ec0 KLdgpAAiglzwbbCRiRNb3wTC3kJQsxe27gznHnH3tTYzUCtWVqwqjfqIdGk2+6JV l0+Sy2ZY8Axb8Oy/SWj1/NUrhObfqA+Wr/eaMWv6rPBwcVo21AA= =jcgD -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@freebsd.org Mon Jan 1 10:37:04 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84C37EA306E for ; Mon, 1 Jan 2018 10:37:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 00B9F68101; Mon, 1 Jan 2018 10:37:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w01AatWO047634 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 12:36:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w01AatWO047634 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w01Aat7Z047633; Mon, 1 Jan 2018 12:36:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Jan 2018 12:36:55 +0200 From: Konstantin Belousov To: David Chisnall Cc: Adrian Chadd , blubee blubeeme , FreeBSD current Subject: Re: Programmatically cache line Message-ID: <20180101103655.GF1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 10:37:04 -0000 On Mon, Jan 01, 2018 at 06:52:37AM +0000, David Chisnall wrote: > On 1 Jan 2018, at 05:09, Adrian Chadd wrote: > > > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: > >> On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: > >>> Is there some way to programmatically get the CPU cache line sizes on > >>> FreeBSD? > >> > >> There are, all of them are MD. > >> > >> On x86, the CPUID instruction leaf 0x1 returns the information in > >> %ebx register. > > > > Hm, weird. Why don't we extend sysctl to include this info? For the same reason we do not provide a sysctl to add two integers. > > It would be nice to expose this kind of information via VDSO or similar. There are a lot of similar bits of info that people want to use for ifunc and, SVE is going to have a bunch of similar requirements. > Is VDSO a new trendy word ? ifunc resolvers in usermode on FreeBSD/x86 get four arguments which are essentially cpu_features / cpu_features2 / cpu_stdext_features / cpu_stdext_features2. I suspect that only FreeBSD/x86 arches have the ifunc support, in rtld and coming shortly in kernel. Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3) interface exported from libc. ARM* did not implemented yet the ifunc stubs in rtld. I believe this is considered a low priority because there is no ready to use toolchain which allow to utilize ifuncs on FreeBSD, except if you use recent bfd ld externally. From owner-freebsd-current@freebsd.org Mon Jan 1 16:26:45 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3323EB1404 for ; Mon, 1 Jan 2018 16:26:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 5D39D72874 for ; Mon, 1 Jan 2018 16:26:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 86e3e4cf-ef10-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 86e3e4cf-ef10-11e7-8dac-d32f5c2d02ef; Mon, 01 Jan 2018 16:26:33 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w01GQTFL010561; Mon, 1 Jan 2018 09:26:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514823989.12000.30.camel@freebsd.org> Subject: Re: Programmatically cache line From: Ian Lepore To: Konstantin Belousov , David Chisnall Cc: Adrian Chadd , blubee blubeeme , FreeBSD current Date: Mon, 01 Jan 2018 09:26:29 -0700 In-Reply-To: <20180101103655.GF1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 16:26:45 -0000 On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote: > On Mon, Jan 01, 2018 at 06:52:37AM +0000, David Chisnall wrote: > > > > On 1 Jan 2018, at 05:09, Adrian Chadd wrote: > > > > > > > > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: > > > > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: > > > > > > > > > > Is there some way to programmatically get the CPU cache line sizes on > > > > > FreeBSD? > > > > There are, all of them are MD. > > > > > > > > On x86, the CPUID instruction leaf 0x1 returns the information in > > > > %ebx register. > > > Hm, weird. Why don't we extend sysctl to include this info? > For the same reason we do not provide a sysctl to add two integers. > > > > > > > It would be nice to expose this kind of information via VDSO or similar.  There are a lot of similar bits of info that people want to use for ifunc and, SVE is going to have a bunch of similar requirements. > > > Is VDSO a new trendy word ? > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which > are essentially cpu_features / cpu_features2 / cpu_stdext_features / > cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the > ifunc support, in rtld and coming shortly in kernel. > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3) > interface exported from libc. > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is > considered a low priority because there is no ready to use toolchain > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd > ld externally. Linux exports this info using getauxval(). I think we should support getauxval() and as many of the AT_* values that linux defines as makes sense for us to do. I think it was a mistake to give our version of the function a different name and different semantics, but this is something that affects mainly ports, and I don't yet have enough info to make the case that being linux-compatible will ease porting rather than complicate it (in some cases, patches will be needed either way). -- Ian From owner-freebsd-current@freebsd.org Mon Jan 1 16:33:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E2DEEB18DF for ; Mon, 1 Jan 2018 16:33:29 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 212C072D24 for ; Mon, 1 Jan 2018 16:33:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 73ed8a16-ef11-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 73ed8a16-ef11-11e7-8486-0934409070aa; Mon, 01 Jan 2018 16:33:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w01GXN8u010569; Mon, 1 Jan 2018 09:33:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514824403.12000.37.camel@freebsd.org> Subject: Re: panic: invalid bcd 194 From: Ian Lepore To: Matthias Apitz , Kurt Jaeger Cc: freebsd-current@freebsd.org Date: Mon, 01 Jan 2018 09:33:23 -0700 In-Reply-To: <20180101091210.GA2591@c720-r314251> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <20180101085723.GM2827@home.opsec.eu> <20180101091210.GA2591@c720-r314251> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 16:33:29 -0000 On Mon, 2018-01-01 at 10:12 +0100, Matthias Apitz wrote: > El día lunes, enero 01, 2018 a las 09:57:23a. m. +0100, Kurt Jaeger escribió: > > > > > Hi! > > > > > > > > For the moment we solved the issue by booting some older r28nnnn > > > memstick, writing a correct date with ntpdate into the RTC and rebooted > > > without poweroff. It seems that the RTC survives even some short > > > powercyle. > > > > > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e. > > > no chance to be replaced. > > > > > > The issue must be fixed in FreeBSD, i.e. it should boot even with a > > > broken RTC. Should I file a PR for this? > > Yes, please file a PR. > done. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224813 > FYI, I'm working on this, but I discovered yesterday afternoon that Eric van Gyzen already added code in r314936 to the atrtc driver to validate the data from the hardware before calling bcd2bin() .  The code looks correct to me, so why is this error still happening? I suspected a clang codegen bug, and the generated code does look a bit suspicious to me (things like ANDing with 0x0e where the C code uses 0x0f), but my x86 asm skills are 25 years out of date.  It's also very hard asm code to follow, because inlined functions that call other inlined functions are involved. I'm on the path of adding some new common routines that all RTC drivers can use to validate the BCD coming from the hardware without panicking.  But if I switch the atrtc code to use the new routines, that may amount to sweeping a clang bug under the rug. -- Ian From owner-freebsd-current@freebsd.org Mon Jan 1 20:47:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC6CCE800BC for ; Mon, 1 Jan 2018 20:47:49 +0000 (UTC) (envelope-from pdagog@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FF377D19F for ; Mon, 1 Jan 2018 20:47:49 +0000 (UTC) (envelope-from pdagog@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id b141so11844334wme.1 for ; Mon, 01 Jan 2018 12:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :jabber-id:user-agent; bh=ZOJxiKMPo2J2U8PohnFNwU41Flc31E/hsfMLmc2RCjY=; b=Qa14j2yCCNIrcNywqaGtFY77iKHT+lAbueJ701o0PseSzGj/rIQqeIQEFgtklQDZcd rCwBRECScLlA/9B3/CGRzDt/V3C7QcLB8T9Xut5EGq8bThD+sT+w8zJS11iq7WXOYFxg C6NVMcc1kPrIvjBIM2z50Gr/FZ21Nuw1i4XZn1+qvFlbJxw6Oz/TSHpDMN881d3SBXrE RABmWonu2jBAGRNDK32JwjkzEp3Ul5QjsJo2DMop7KLnR0EiRLbw/TPKe+PokI1UElbz 8qukiSXavaBpkazFV1RD5RUlM41byAAj/EDssBH48tP4LnjvAXiyhCGZDUvCFvDmeWMe NwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:jabber-id:user-agent; bh=ZOJxiKMPo2J2U8PohnFNwU41Flc31E/hsfMLmc2RCjY=; b=fT9GiH8hyzAZSp8yOznhDOo58Ws7+qLZnTAiNuCr7pVP1ARn1xkuzd4xSEz7Ql9aZL dzXba//7wKhL/UjHXP0TsC1SSVqnMJuRffgzOF1jF5IN44sklbFHOHy96jD7YAyJVV3V 49pxgev1cdHzz0cAej2J6h1hZ46Lnsmeh4Yii6GncwVuxYyGMVqeayFabtBmo2Fa7pxE xUrwvWfqzbJWDJIY0nNlVKAk9NjU4a3cCZ+ax7YHaIwp/yle8qjKmyMRwQAolh/c5R/C lHGzsCDgBEATDvmZfhZTnX/h2TWl8/Pn1OyZmCIcMBonLuZMlvdWcimvk5PjciQDi8um jwhA== X-Gm-Message-State: AKGB3mKb9qjKLuNtD44JVk79NyYFTZDzwcXnO1f0GMSfgj9gLcGVw9ZP eAxdbPZFNpUndQmw6R0grFjSCA== X-Google-Smtp-Source: ACJfBotJr9Gbjjk9X3VUaw2kjPo5loLlRIggystbeZk8l1Z+VBbuFfyeTU49MwBI3CyZD2rl8TcMJg== X-Received: by 10.28.142.193 with SMTP id q184mr31427589wmd.62.1514839667414; Mon, 01 Jan 2018 12:47:47 -0800 (PST) Received: from localhost ([2001:470:1f13:1334:41f8:9bee:9e92:34ef]) by smtp.gmail.com with ESMTPSA id j96sm6576671wrj.93.2018.01.01.12.47.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jan 2018 12:47:46 -0800 (PST) Date: Mon, 1 Jan 2018 21:47:40 +0100 From: Pierre DAVID To: freebsd-current@freebsd.org Subject: Problem with C11 _Atomic Message-ID: <20180101204740.GA15590@vagabond> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Jabber-ID: pdagog@gmail.com User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 20:47:49 -0000 Hi, I'm on a recent current: FreeBSD biceps.ma.maison 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327239: Wed Dec 27 18:25:46 CET 2017 pda@biceps.ma.maison:/usr/obj/usr/src/amd64.amd64/sys/BICEPS amd64 with clang 5.0.1: FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin I'm having a problem with the following source file: ------------------------------------------------------------------------------ #include struct foo { int f1 ; char f2 ; int f3 ; } ; _Atomic struct foo a ; struct foo b ; int main (int argc, char *argv []) { b = (struct foo) {.f1 = 5, .f2 = 7, .f3 = 9 } ; // atomic_store (&a, b) ; a = b ; } ------------------------------------------------------------------------------ This code does not compile/link with: % cc foo.c -lstdthreads /tmp/foo-a0ef26.o: In function `main': foo.c:(.text+0x63): undefined reference to `__sync_lock_test_and_set_16' cc: error: linker command failed with exit code 1 (use -v to see invocation) The gcc internal seems to be linked as "cc -v" told me: % cc -v foo.c -lstdthreads ... "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/foo-d7a21b.o -lstdthreads -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o The problem occurs with "atomic_store(&a, b)" as well as with "a = b". If I remove the f3 member, the struct foo is only 8 bytes and the code compiles/links. Did I missed something? Thanks in advance, Pierre From owner-freebsd-current@freebsd.org Mon Jan 1 21:09:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11472E81392 for ; Mon, 1 Jan 2018 21:09:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 8398E7E8B1 for ; Mon, 1 Jan 2018 21:09:20 +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 w01L97LF087888 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 23:09:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w01L97LF087888 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w01L97tl087887; Mon, 1 Jan 2018 23:09:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 1 Jan 2018 23:09:07 +0200 From: Konstantin Belousov To: Pierre DAVID Cc: freebsd-current@freebsd.org Subject: Re: Problem with C11 _Atomic Message-ID: <20180101210907.GG1684@kib.kiev.ua> References: <20180101204740.GA15590@vagabond> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180101204740.GA15590@vagabond> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 21:09:21 -0000 On Mon, Jan 01, 2018 at 09:47:40PM +0100, Pierre DAVID wrote: > Hi, > > I'm on a recent current: > FreeBSD biceps.ma.maison 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327239: Wed Dec 27 18:25:46 CET 2017 pda@biceps.ma.maison:/usr/obj/usr/src/amd64.amd64/sys/BICEPS amd64 > > with clang 5.0.1: > FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > > I'm having a problem with the following source file: > > ------------------------------------------------------------------------------ > #include > > struct foo > { > int f1 ; > char f2 ; > int f3 ; > } ; > > _Atomic struct foo a ; > struct foo b ; > > int main (int argc, char *argv []) > { > b = (struct foo) {.f1 = 5, .f2 = 7, .f3 = 9 } ; > // atomic_store (&a, b) ; > a = b ; > } > ------------------------------------------------------------------------------ > > This code does not compile/link with: > % cc foo.c -lstdthreads > /tmp/foo-a0ef26.o: In function `main': > foo.c:(.text+0x63): undefined reference to `__sync_lock_test_and_set_16' > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > The gcc internal seems to be linked as "cc -v" told me: > % cc -v foo.c -lstdthreads > ... > "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/foo-d7a21b.o -lstdthreads -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > > The problem occurs with "atomic_store(&a, b)" as well as with "a = b". > > If I remove the f3 member, the struct foo is only 8 bytes and the code > compiles/links. > > Did I missed something? clang issues a calls to libatomic, which we do not provide. As a workaround, use the following command to compile. The resulting binary works on all practically usable machines. $ cc -march=core2 source.c You might want to turn off sse3/4.1 if you are concerned about older pentium4. From owner-freebsd-current@freebsd.org Mon Jan 1 23:00:37 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BC6AE89B4C for ; Mon, 1 Jan 2018 23:00:37 +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 5EDEE2AEC; Mon, 1 Jan 2018 23:00:37 +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.89 (FreeBSD)) (envelope-from ) id 1eW94M-000LPK-VX; Mon, 01 Jan 2018 15:00:35 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w01N0YZr082293; Mon, 1 Jan 2018 15:00:34 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Mon, 1 Jan 2018 15:00:34 -0800 From: Oleksandr Tymoshenko To: Ian Lepore Cc: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: SVN r327444 breaks current build Message-ID: <20180101230034.GA82243@bluezbox.com> References: <0b8f0e34-7a39-fd59-7f66-b55f1af0e920@protected-networks.net> <20171231222235.GA62313@bluezbox.com> <20171231235330.GA63368@bluezbox.com> <1514764805.12000.26.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1514764805.12000.26.camel@freebsd.org> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) 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: Ian Lepore (ian@freebsd.org) wrote: > On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote: > > Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > > > > > > > > > > On 12/31/17 14:22, Ole [...] 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 23:00:37 -0000 Ian Lepore (ian@freebsd.org) wrote: > On Sun, 2017-12-31 at 15:53 -0800, Oleksandr Tymoshenko wrote: > > Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > > > > > > > > > > On 12/31/17 14:22, Oleksandr Tymoshenko wrote: > > > > > > > > Michael Butler (imb@protected-networks.net) wrote: > > > > > > > > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vt_font_default.o > > > > > --- vt_termcolors.o --- > > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:158:55: error: too many > > > > > arguments to function call, expected 4, have 5 > > > > >                          if (vt_parse_rgb_triplet(rgb, strlen(rgb), &r, > > > > > &g, &b) == 0) { > > > > >                              ~~~~~~~~~~~~~~~~~~~~ > > > > >    ^~ > > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:77:1: note: > > > > > 'vt_parse_rgb_triplet' declared here > > > > > static int > > > > > ^ > > > > > 1 error generated. > > > > > *** [vt_termcolors.o] Error code 1 > > > > > > > > > > .. second time today a commit wasn't tested before commit :-( > > > > > > > > > > imb > > > > Should be fixed in r327449. It was a sloppy job, I was making iterative > > > > improvements to the original patch following review feedback and used > > > > out-of-tree testcases for actual testing. I appologize for the breakage. > > > > > > > Still broken with GCC. > > > > > > /usr/src/sys/dev/vt/colors/vt_termcolors.c:148: warning: function  > > > declaration isn't a prototype [-Wstrict-prototypes] > > > *** [vt_termcolors.o] Error code 1 > > *sigh* Should be fixed in r327454. Thanks for reporting > > > > I wonder if we can get clang to be more strict about > > declarations/prototypes/etc to match gcc's expectations. I understand > > that it's developers' responsibility to make sure that kernel > > is GCC-buildable but if raising red flag for some of the cases > > when compiling with clang reduced number of these breakages > > that it'd be an improvement. > > > > I think we can get clang to do that with -Wstrict-prototypes, but I'm > not sure when that option appeared in terms of clang version, and the > clang site doesn't seem to provide documentation for anything other > than the current in-development version. -Wstrict-prototypes option was added in 5.0.0 and kernel build has this flag enabled. But this check works only for declaration and ignores definitions. -- gonzo From owner-freebsd-current@freebsd.org Tue Jan 2 00:02:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFBFBEA3CF2 for ; Tue, 2 Jan 2018 00:02:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 38FD664388 for ; Tue, 2 Jan 2018 00:02:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 427dcea6-ef50-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 427dcea6-ef50-11e7-8dac-d32f5c2d02ef; Tue, 02 Jan 2018 00:02:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w0202gFs011290; Mon, 1 Jan 2018 17:02:42 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1514851362.1759.8.camel@freebsd.org> Subject: Re: panic: invalid bcd 194 From: Ian Lepore To: Matthias Apitz Cc: freebsd-current@freebsd.org, cem@freebsd.org Date: Mon, 01 Jan 2018 17:02:42 -0700 In-Reply-To: <20180101085425.GA2301@c720-r314251> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> Content-Type: multipart/mixed; boundary="=-giyKQBl8zY1X6xbh409l" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 00:02:51 -0000 --=-giyKQBl8zY1X6xbh409l Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Mon, 2018-01-01 at 09:54 +0100, Matthias Apitz wrote: > El día domingo, diciembre 31, 2017 a las 10:19:50a. m. -0700, Ian Lepore escribió: > > > > > > > > > I will let the C720 over night under power while sitting in the boot menu, > > > maybe this will fix the RTC battery issue. > > > > > Last time I worked on RTC stuff, cleaning this up got put on my "to-do > > some day" list.  I think maybe that day has arrived. > > > > -- Ian > For the moment we solved the issue by booting some older r28nnnn > memstick, writing a correct date with ntpdate into the RTC and rebooted > without poweroff. It seems that the RTC survives even some short > powercyle. > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e. > no chance to be replaced. > > The issue must be fixed in FreeBSD, i.e. it should boot even with a > broken RTC. Should I file a PR for this? > > I'm happy to test any patch for this. > > matthias > Okay, I've created a pair of patches for this.  The first adds some common support routines usable by all RTC drivers with BCD hardware.  The second one converts the atrtc driver to use those routines.  The common code was tested using an i2c RTC chip, but I don't have an x86 testbed, so the atrtc patch is currently untested (it compiles). The patches are available in a pair of phabricator reviews, plus I'll attach them to this mail.  If the list scrubs the attachements, you can download the patches from the phab urls below, just hit the Actions button and look for Download Raw Diff. https://reviews.freebsd.org/D13730 https://reviews.freebsd.org/D13731 -- Ian --=-giyKQBl8zY1X6xbh409l Content-Disposition: attachment; filename="subr_clock_bcd.diff" Content-Type: text/x-patch; name="subr_clock_bcd.diff"; charset="ASCII" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9rZXJuL3N1YnJfY2xvY2suYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vybi9zdWJy X2Nsb2NrLmMJKHJldmlzaW9uIDMyNzQzOCkKKysrIHN5cy9rZXJuL3N1YnJfY2xvY2suYwkod29y a2luZyBjb3B5KQpAQCAtMTk5LDYgKzE5OSw1MiBAQCBjbG9ja19jdF90b190cyhzdHJ1Y3QgY2xv Y2t0aW1lICpjdCwgc3RydWN0IHRpbWVzcAogCXJldHVybiAoMCk7CiB9CiAKK2ludAorY2xvY2tf YmNkX3RvX3RzKHN0cnVjdCBiY2RfY2xvY2t0aW1lICpiY3QsIHN0cnVjdCB0aW1lc3BlYyAqdHMp Cit7CisJc3RydWN0IGNsb2NrdGltZSBjdDsKKworCS8qCisJICogWWVhciBtYXkgY29tZSBpbiBh cyAyLWRpZ2l0IG9yIDQtZGlnaXQuICBjbG9ja19jdF90b190cygpIGhhbmRsZXMgdGhlCisJICog Y2VudHVyeSBmb3IgMi1kaWdpdCwgYnV0IHdlIG5lZWQgdG8gZGVjb2RlIHRoZSBjZW50dXJ5IGZv ciA0LWRpZ2l0LgorCSAqLworCWlmICh2YWxpZGJjZChiY3QtPnllYXIpKSB7CisJCWlmIChiY3Qt PnllYXIgPD0gMHg5OSkKKwkJCWN0LnllYXIgPSBGUk9NQkNEKGJjdC0+eWVhcik7CisJCWVsc2UK KwkJCWN0LnllYXIgPSBGUk9NQkNEKGJjdC0+eWVhciA+PiA4KSAqIDEwMCArCisJCQkgICAgRlJP TUJDRChiY3QtPnllYXIgJiAweGZmKTsKKwl9IGVsc2UKKwkJY3QueWVhciA9IC0xOworCisJLyoK KwkgKiBFbnN1cmUgdGhhdCBhbGwgdmFsdWVzIGFyZSB2YWxpZCBCQ0QgbnVtYmVycywgdG8gYXZv aWQgYXNzZXJ0aW9ucyBpbgorCSAqIHRoZSBCQ0QtdG8tYmluYXJ5IGNvbnZlcnNpb24gcm91dGlu ZXMuICBjbG9ja19jdF90b190cygpIHdpbGwgZnVydGhlcgorCSAqIHZhbGlkYXRlIHRoZSBmaWVs ZCByYW5nZXMgKHN1Y2ggYXMgMCA8PSBtaW4gPD0gNTkpIGR1cmluZyBjb252ZXJzaW9uLgorCSAq LworCWlmICghdmFsaWRiY2QoYmN0LT5zZWMpICB8fCAhdmFsaWRiY2QoYmN0LT5taW4pIHx8CisJ ICAgICF2YWxpZGJjZChiY3QtPmhvdXIpIHx8ICF2YWxpZGJjZChiY3QtPmRheSkgfHwKKwkgICAg IXZhbGlkYmNkKGJjdC0+bW9uKSAgfHwgY3QueWVhciA9PSAtMSkgeworCQlpZiAoY3RfZGVidWcp IHsKKwkJCXByaW50ZigiY2xvY2tfYmNkX3RvX3RzOiBiYWQgQkNEOiAiCisJCQkgICAgIlslMDR4 LSUwMngtJTAyeCAlMDJ4OiUwMng6JTAyeF1cbiIsCisJCQkgICAgYmN0LT55ZWFyLCBiY3QtPm1v biwgYmN0LT5kYXksCisJCQkgICAgYmN0LT5ob3VyLCBiY3QtPm1pbiwgYmN0LT5zZWMpOworCQl9 CisJCXJldHVybiAoRUlOVkFMKTsKKwl9CisKKwljdC5tb24gID0gRlJPTUJDRChiY3QtPm1vbik7 CisJY3QuZGF5ICA9IEZST01CQ0QoYmN0LT5kYXkpOworCWN0LmhvdXIgPSBGUk9NQkNEKGJjdC0+ aG91cik7CisJY3QubWluICA9IEZST01CQ0QoYmN0LT5taW4pOworCWN0LnNlYyAgPSBGUk9NQkNE KGJjdC0+c2VjKTsKKwljdC5kb3cgID0gYmN0LT5kb3c7CisJY3QubnNlYyA9IGJjdC0+bnNlYzsK KworCXJldHVybiAoY2xvY2tfY3RfdG9fdHMoJmN0LCB0cykpOworfQorCiB2b2lkCiBjbG9ja190 c190b19jdChzdHJ1Y3QgdGltZXNwZWMgKnRzLCBzdHJ1Y3QgY2xvY2t0aW1lICpjdCkKIHsKQEAg LTI2MCw2ICszMDYsMjMgQEAgY2xvY2tfdHNfdG9fY3Qoc3RydWN0IHRpbWVzcGVjICp0cywgc3Ry dWN0IGNsb2NrdGkKIAkgICAgKCJzZWNvbmRzICVkIG5vdCBpbiAwLTYwIiwgY3QtPnNlYykpOwog fQogCit2b2lkCitjbG9ja190c190b19iY2Qoc3RydWN0IHRpbWVzcGVjICp0cywgc3RydWN0IGJj ZF9jbG9ja3RpbWUgKmJjdCkKK3sKKwlzdHJ1Y3QgY2xvY2t0aW1lIGN0OworCisJY2xvY2tfdHNf dG9fY3QodHMsICZjdCk7CisKKwliY3QtPnllYXIgPSBUT0JDRChjdC55ZWFyICUgMTAwKSB8IChU T0JDRChjdC55ZWFyIC8gMTAwKSA8PCA4KTsKKwliY3QtPm1vbiAgPSBUT0JDRChjdC5tb24pOwor CWJjdC0+ZGF5ICA9IFRPQkNEKGN0LmRheSk7CisJYmN0LT5ob3VyID0gVE9CQ0QoY3QuaG91cik7 CisJYmN0LT5taW4gID0gVE9CQ0QoY3QubWluKTsKKwliY3QtPnNlYyAgPSBUT0JDRChjdC5zZWMp OworCWJjdC0+ZG93ICA9IGN0LmRvdzsKKwliY3QtPm5zZWMgPSBjdC5uc2VjOworfQorCiBpbnQK IHV0Y19vZmZzZXQodm9pZCkKIHsKSW5kZXg6IHN5cy9zeXMvY2xvY2suaAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvc3lzL2Nsb2NrLmgJKHJldmlzaW9uIDMyNzQzOCkKKysrIHN5cy9zeXMvY2xvY2suaAko d29ya2luZyBjb3B5KQpAQCAtNjAsOSArNjAsMjIgQEAgZXh0ZXJuIGludCB0el9kc3R0aW1lOwog aW50IHV0Y19vZmZzZXQodm9pZCk7CiAKIC8qCi0gKiBTdHJ1Y3R1cmUgdG8gaG9sZCB0aGUgdmFs dWVzIHR5cGljYWxseSByZXBvcnRlZCBieSB0aW1lLW9mLWRheSBjbG9ja3MuCi0gKiBUaGlzIGNh biBiZSBwYXNzZWQgdG8gdGhlIGdlbmVyaWMgY29udmVyc2lvbiBmdW5jdGlvbnMgdG8gYmUgY29u dmVydGVkCi0gKiB0byBhIHN0cnVjdCB0aW1lc3BlYy4KKyAqIFN0cnVjdHVyZSB0byBob2xkIHRo ZSB2YWx1ZXMgdHlwaWNhbGx5IHJlcG9ydGVkIGJ5IHRpbWUtb2YtZGF5IGNsb2NrcywKKyAqIGV4 cHJlc3NlZCBhcyBiaW5hcnkgaW50ZWdlcnMgKHNlZSBiZWxvdyBmb3IgYSBCQ0QgdmVyc2lvbiku ICBUaGlzIGNhbiBiZQorICogcGFzc2VkIHRvIHRoZSBjb252ZXJzaW9uIGZ1bmN0aW9ucyB0byBi ZSBjb252ZXJ0ZWQgdG8vZnJvbSBhIHN0cnVjdCB0aW1lc3BlYy4KKyAqCisgKiBPbiBpbnB1dCwg dGhlIHllYXIgaXMgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czoKKyAqICAgICAgIDAgLSAgIDY5ID0g MjAwMCAtIDIwNjkKKyAqICAgICAgNzAgLSAgIDk5ID0gMTk3MCAtIDE5OTkKKyAqICAgICAxMDAg LSAgMTk5ID0gMjAwMCAtIDIwOTkgKFN1cHBvcnRzIGhhcmR3YXJlICJjZW50dXJ5IGJpdCIuKQor ICogICAgIDIwMCAtIDE5NjkgPSBJbnZhbGlkLgorICogICAgMTk3MCAtIDk5OTkgPSBGdWxsIDQt ZGlnaXQgY2VudHVyeSt5ZWFyLgorICoKKyAqIFRoZSBkb3cgZmllbGQgaXMgaWdub3JlZCAobm90 IGV2ZW4gdmFsaWRhdGVkKSBvbiBpbnB1dCwgYnV0IGlzIGFsd2F5cworICogcG9wdWxhdGVkIHdp dGggZGF5LW9mLXdlZWsgb24gb3V0cHV0LgorICoKKyAqIGNsb2NrX2N0X3RvX3RzKCkgcmV0dXJu cyBFSU5WQUwgaWYgYW55IHZhbHVlcyBhcmUgb3V0IG9mIHJhbmdlLiAgVGhlIHllYXIKKyAqIGZp ZWxkIHdpbGwgYWx3YXlzIGJlIDQtZGlnaXQgb24gb3V0cHV0LgogICovCiBzdHJ1Y3QgY2xvY2t0 aW1lIHsKIAlpbnQJeWVhcjsJCQkvKiB5ZWFyICg0IGRpZ2l0IHllYXIpICovCkBAIC03OSw2ICs5 MiwzNiBAQCBpbnQgY2xvY2tfY3RfdG9fdHMoc3RydWN0IGNsb2NrdGltZSAqLCBzdHJ1Y3QgdGlt ZQogdm9pZCBjbG9ja190c190b19jdChzdHJ1Y3QgdGltZXNwZWMgKiwgc3RydWN0IGNsb2NrdGlt ZSAqKTsKIAogLyoKKyAqIFN0cnVjdHVyZSB0byBob2xkIHRoZSB2YWx1ZXMgdHlwaWNhbGx5IHJl cG9ydGVkIGJ5IHRpbWUtb2YtZGF5IGNsb2NrcywKKyAqIGV4cHJlc3NlZCBhcyBCQ0QuICBUaGlz IGNhbiBiZSBwYXNzZWQgdG8gdGhlIGNvbnZlcnNpb24gZnVuY3Rpb25zIHRvIGJlCisgKiBjb252 ZXJ0ZWQgdG8vZnJvbSBhIHN0cnVjdCB0aW1lc3BlYy4KKyAqCisgKiBUaGUgY2xvY2tfYmNkX3Rv X3RzKCkgZnVuY3Rpb24gaW50ZXJwcmV0cyB0aGUgdmFsdWVzIGluIHRoZSB5ZWFyIHRocm91Z2gg c2VjCisgKiBmaWVsZHMgYXMgQkNEIG51bWJlcnMsIGFuZCByZXR1cm5zIEVJTlZBTCBpZiBhbnkg QkNEIHZhbHVlcyBhcmUgb3V0IG9mIHJhbmdlLgorICogQWZ0ZXIgY29udmVyc2lvbiB0byBiaW5h cnksIHRoZSB2YWx1ZXMgYXJlIHBhc3NlZCB0byBjbG9ja19jdF90b190cygpIGFuZAorICogdW5k ZXJnbyBmdXJ0aGVyIHZhbGlkYXRpb24gYXMgZGVzY3JpYmVkIGFib3ZlLiAgWWVhciBtYXkgYmUg MiBvciA0LWRpZ2l0IEJDRCwKKyAqIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBhYm92ZS4gIFRo ZSBuc2VjIGZpZWxkIGlzIGJpbmFyeS4KKyAqCisgKiBUaGUgY2xvY2tfdHNfdG9fYmNkKCkgZnVu Y3Rpb24gY29udmVydHMgdGhlIHRpbWVzcGVjIHRvIEJDRCB2YWx1ZXMgc3RvcmVkCisgKiBpbnRv IHllYXIgdGhyb3VnaCBzZWMuICBUaGUgdmFsdWUgaW4geWVhciB3aWxsIGJlIDQtZGlnaXQgQkNE IChlLmcuLAorICogMHgyMDE3KS4gVGhlIG1vbiB0aHJvdWdoIHNlYyB2YWx1ZXMgd2lsbCBiZSAy LWRpZ2l0IEJDRC4gIFRoZSBuc2VjIGZpZWxkIHdpbGwKKyAqIGJlIGJpbmFyeSwgYW5kIHRoZSBy YW5nZSBvZiBkb3cgbWFrZXMgaXRzIGJpbmFyeSBhbmQgQkNEIHZhbHVlcyBpZGVudGljYWwuCisg Ki8KK3N0cnVjdCBiY2RfY2xvY2t0aW1lIHsKKwlpbnQJeWVhcjsJCQkvKiB5ZWFyICg0IGRpZ2l0 IHllYXIpICovCisJaW50CW1vbjsJCQkvKiBtb250aCAoMSAtIDEyKSAqLworCWludAlkYXk7CQkJ LyogZGF5ICgxIC0gMzEpICovCisJaW50CWhvdXI7CQkJLyogaG91ciAoMCAtIDIzKSAqLworCWlu dAltaW47CQkJLyogbWludXRlICgwIC0gNTkpICovCisJaW50CXNlYzsJCQkvKiBzZWNvbmQgKDAg LSA1OSkgKi8KKwlpbnQJZG93OwkJCS8qIGRheSBvZiB3ZWVrICgwIC0gNjsgMCA9IFN1bmRheSkg Ki8KKwlsb25nCW5zZWM7CQkJLyogbmFubyBzZWNvbmRzICovCit9OworCitpbnQgY2xvY2tfYmNk X3RvX3RzKHN0cnVjdCBiY2RfY2xvY2t0aW1lICosIHN0cnVjdCB0aW1lc3BlYyAqKTsKK3ZvaWQg Y2xvY2tfdHNfdG9fYmNkKHN0cnVjdCB0aW1lc3BlYyAqLCBzdHJ1Y3QgYmNkX2Nsb2NrdGltZSAq KTsKKworLyoKICAqIFRpbWUtb2YtZGF5IGNsb2NrIGZ1bmN0aW9ucyBhbmQgZmxhZ3MuICBUaGVz ZSBmdW5jdGlvbnMgbWlnaHQgc2xlZXAuCiAgKgogICogY2xvY2tfcmVnaXN0ZXIgYW5kIGNsb2Nr X3VucmVnaXN0ZXIoKSBkbyB3aGF0IHRoZXkgc2F5LiAgVXBvbiByZXR1cm4gZnJvbQo= --=-giyKQBl8zY1X6xbh409l Content-Disposition: attachment; filename="atrtc_bcd.diff" Content-Type: text/x-patch; name="atrtc_bcd.diff"; charset="ASCII" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy94ODYvaXNhL2F0cnRjLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3g4Ni9pc2EvYXRy dGMuYwkocmV2aXNpb24gMzI3NDM4KQorKysgc3lzL3g4Ni9pc2EvYXRydGMuYwkod29ya2luZyBj b3B5KQpAQCAtMTA5LDE3ICsxMDksNiBAQCB3cml0ZXJ0YyhpbnQgcmVnLCB1X2NoYXIgdmFsKQog CVJUQ19VTkxPQ0s7CiB9CiAKLXN0YXRpYyBfX2lubGluZSBpbnQKLXJlYWRydGMoaW50IHBvcnQp Ci17Ci0JaW50IHJlYWR2YWw7Ci0KLQlyZWFkdmFsID0gcnRjaW4ocG9ydCk7Ci0JaWYgKHJlYWR2 YWwgPj0gMCAmJiAocmVhZHZhbCAmIDB4ZikgPCAweGEgJiYgKHJlYWR2YWwgJiAweGYwKSA8IDB4 YTApCi0JCXJldHVybiAoYmNkMmJpbihyZWFkdmFsKSk7Ci0JcmV0dXJuICgwKTsKLX0KLQogc3Rh dGljIHZvaWQKIGF0cnRjX3N0YXJ0KHZvaWQpCiB7CkBAIC0xNjksOSArMTU4LDkgQEAgYXRydGNf cmVzdG9yZSh2b2lkKQogc3RhdGljIHZvaWQKIGF0cnRjX3NldChzdHJ1Y3QgdGltZXNwZWMgKnRz KQogewotCXN0cnVjdCBjbG9ja3RpbWUgY3Q7CisJc3RydWN0IGJjZF9jbG9ja3RpbWUgYmN0Owog Ci0JY2xvY2tfdHNfdG9fY3QodHMsICZjdCk7CisJY2xvY2tfdHNfdG9fYmNkKHRzLCAmYmN0KTsK IAogCW10eF9sb2NrKCZhdHJ0Y190aW1lX2xvY2spOwogCkBAIC0xNzgsMTYgKzE2NywxNSBAQCBh dHJ0Y19zZXQoc3RydWN0IHRpbWVzcGVjICp0cykKIAkvKiBEaXNhYmxlIFJUQyB1cGRhdGVzIGFu ZCBpbnRlcnJ1cHRzLiAqLwogCXdyaXRlcnRjKFJUQ19TVEFUVVNCLCBSVENTQl9IQUxUIHwgUlRD U0JfMjRIUik7CiAKLQl3cml0ZXJ0YyhSVENfU0VDLCBiaW4yYmNkKGN0LnNlYykpOyAJCS8qIFdy aXRlIGJhY2sgU2Vjb25kcyAqLwotCXdyaXRlcnRjKFJUQ19NSU4sIGJpbjJiY2QoY3QubWluKSk7 IAkJLyogV3JpdGUgYmFjayBNaW51dGVzICovCi0Jd3JpdGVydGMoUlRDX0hSUywgYmluMmJjZChj dC5ob3VyKSk7CQkvKiBXcml0ZSBiYWNrIEhvdXJzICAgKi8KLQotCXdyaXRlcnRjKFJUQ19XREFZ LCBjdC5kb3cgKyAxKTsJCQkvKiBXcml0ZSBiYWNrIFdlZWtkYXkgKi8KLQl3cml0ZXJ0YyhSVENf REFZLCBiaW4yYmNkKGN0LmRheSkpOwkJLyogV3JpdGUgYmFjayBEYXkgKi8KLQl3cml0ZXJ0YyhS VENfTU9OVEgsIGJpbjJiY2QoY3QubW9uKSk7ICAgICAgICAgICAvKiBXcml0ZSBiYWNrIE1vbnRo ICAgKi8KLQl3cml0ZXJ0YyhSVENfWUVBUiwgYmluMmJjZChjdC55ZWFyICUgMTAwKSk7CS8qIFdy aXRlIGJhY2sgWWVhciAgICAqLworCXdyaXRlcnRjKFJUQ19TRUMsICAgYmN0LnNlYyk7IAkJLyog V3JpdGUgYmFjayBTZWNvbmRzICovCisJd3JpdGVydGMoUlRDX01JTiwgICBiY3QubWluKTsgCQkv KiBXcml0ZSBiYWNrIE1pbnV0ZXMgKi8KKwl3cml0ZXJ0YyhSVENfSFJTLCAgIGJjdC5ob3VyKTsJ CS8qIFdyaXRlIGJhY2sgSG91cnMgICAqLworCXdyaXRlcnRjKFJUQ19XREFZLCAgYmN0LmRvdyAr IDEpOwkvKiBXcml0ZSBiYWNrIFdlZWtkYXkgKi8KKwl3cml0ZXJ0YyhSVENfREFZLCAgIGJjdC5k YXkpOwkJLyogV3JpdGUgYmFjayBEYXkgKi8KKwl3cml0ZXJ0YyhSVENfTU9OVEgsIGJjdC5tb24p OyAgICAgICAgICAgLyogV3JpdGUgYmFjayBNb250aCAgICovCisJd3JpdGVydGMoUlRDX1lFQVIs ICBiY3QueWVhciAmIDB4ZmYpOwkvKiBXcml0ZSBiYWNrIFllYXIgICAgKi8KICNpZmRlZiBVU0Vf UlRDX0NFTlRVUlkKLQl3cml0ZXJ0YyhSVENfQ0VOVFVSWSwgYmluMmJjZChjdC55ZWFyIC8gMTAw KSk7CS8qIC4uLiBhbmQgQ2VudHVyeSAgICAqLworCXdyaXRlcnRjKFJUQ19DRU5UVVJZLCBiY3Qu eWVhciA+PiA4KTsJLyogLi4uIGFuZCBDZW50dXJ5ICAgICovCiAjZW5kaWYKIAogCS8qIFJlLWVu YWJsZSBSVEMgdXBkYXRlcyBhbmQgaW50ZXJydXB0cy4gKi8KQEAgLTM1MSw3ICszMzksNyBAQCBh dHJ0Y19zZXR0aW1lKGRldmljZV90IGRldiBfX3VudXNlZCwgc3RydWN0IHRpbWVzcAogc3RhdGlj IGludAogYXRydGNfZ2V0dGltZShkZXZpY2VfdCBkZXYsIHN0cnVjdCB0aW1lc3BlYyAqdHMpCiB7 Ci0Jc3RydWN0IGNsb2NrdGltZSBjdDsKKwlzdHJ1Y3QgYmNkX2Nsb2NrdGltZSBiY3Q7CiAKIAkv KiBMb29rIGlmIHdlIGhhdmUgYSBSVEMgcHJlc2VudCBhbmQgdGhlIHRpbWUgaXMgdmFsaWQgKi8K IAlpZiAoIShydGNpbihSVENfU1RBVFVTRCkgJiBSVENTRF9QV1IpKSB7CkBAIC0zNzAsMjQgKzM1 OCwyMSBAQCBhdHJ0Y19nZXR0aW1lKGRldmljZV90IGRldiwgc3RydWN0IHRpbWVzcGVjICp0cykK IAl3aGlsZSAocnRjaW4oUlRDX1NUQVRVU0EpICYgUlRDU0FfVFVQKQogCQljb250aW51ZTsKIAlj cml0aWNhbF9lbnRlcigpOwotCWN0Lm5zZWMgPSAwOwotCWN0LnNlYyA9IHJlYWRydGMoUlRDX1NF Qyk7Ci0JY3QubWluID0gcmVhZHJ0YyhSVENfTUlOKTsKLQljdC5ob3VyID0gcmVhZHJ0YyhSVENf SFJTKTsKLQljdC5kYXkgPSByZWFkcnRjKFJUQ19EQVkpOwotCWN0LmRvdyA9IHJlYWRydGMoUlRD X1dEQVkpIC0gMTsKLQljdC5tb24gPSByZWFkcnRjKFJUQ19NT05USCk7Ci0JY3QueWVhciA9IHJl YWRydGMoUlRDX1lFQVIpOworCWJjdC5zZWMgID0gcnRjaW4oUlRDX1NFQyk7CisJYmN0Lm1pbiAg PSBydGNpbihSVENfTUlOKTsKKwliY3QuaG91ciA9IHJ0Y2luKFJUQ19IUlMpOworCWJjdC5kYXkg ID0gcnRjaW4oUlRDX0RBWSk7CisJYmN0Lm1vbiAgPSBydGNpbihSVENfTU9OVEgpOworCWJjdC55 ZWFyID0gcnRjaW4oUlRDX1lFQVIpOwogI2lmZGVmIFVTRV9SVENfQ0VOVFVSWQotCWN0LnllYXIg Kz0gcmVhZHJ0YyhSVENfQ0VOVFVSWSkgKiAxMDA7Ci0jZWxzZQotCWN0LnllYXIgKz0gKGN0Lnll YXIgPCA4MCA/IDIwMDAgOiAxOTAwKTsKKwliY3QueWVhciB8PSBydGNpbihSVENfQ0VOVFVSWSkg PDwgODsKICNlbmRpZgogCWNyaXRpY2FsX2V4aXQoKTsKIAltdHhfdW5sb2NrKCZhdHJ0Y190aW1l X2xvY2spOwotCS8qIFNldCBkb3cgPSAtMSBiZWNhdXNlIHNvbWUgY2xvY2tzIGRvbid0IHNldCBp dCBjb3JyZWN0bHkuICovCi0JY3QuZG93ID0gLTE7Ci0JcmV0dXJuIChjbG9ja19jdF90b190cygm Y3QsIHRzKSk7CisJLyogZG93IGlzIHVudXNlZCBpbiB0aW1lc3BlYyBjb252ZXJzaW9uIGFuZCB3 ZSBoYXZlIG5vIG5zZWMgaW5mby4gKi8KKwliY3QuZG93ICA9IDA7CisJYmN0Lm5zZWMgPSAwOwor CXJldHVybiAoY2xvY2tfYmNkX3RvX3RzKCZiY3QsIHRzKSk7CiB9CiAKIHN0YXRpYyBkZXZpY2Vf bWV0aG9kX3QgYXRydGNfbWV0aG9kc1tdID0gewo= --=-giyKQBl8zY1X6xbh409l-- From owner-freebsd-current@freebsd.org Tue Jan 2 01:14:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5E93EA6F37 for ; Tue, 2 Jan 2018 01:14:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mx2.catspoiler.org (mx2.catspoiler.org [IPv6:2607:f740:16::d18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C839366CC9 for ; Tue, 2 Jan 2018 01:14:14 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org ([76.212.85.177]) by mx2.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w021EQPY012210 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 2 Jan 2018 01:14:28 GMT (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTPS id w021E5h3010748 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Jan 2018 17:14:07 -0800 (PST) (envelope-from truckman@FreeBSD.org) Date: Mon, 1 Jan 2018 17:14:00 -0800 (PST) From: Don Lewis Subject: more fallout from removal of lint To: freebsd-current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 01:14:15 -0000 Since lint was removed from 12.0-CURRENT, it is not possible to build 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick doesn't work when updating a 11.1-STABLE poudriere jail on a 12.0-CURRENT host. ===> usr.bin/xlint (install) ===> usr.bin/xlint/lint1 (install) install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g wheel -m 555 lint1 /var/poudriere/jails/111STABLEi386/usr/libexec/lint1 install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 lint1.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint1.debug install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 lint.7.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man7/ ===> usr.bin/xlint/lint2 (install) install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g wheel -m 555 lint2 /var/poudriere/jails/111STABLEi386/usr/libexec/lint2 install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 lint2.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint2.debug ===> usr.bin/xlint/xlint (install) install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g wheel -m 555 xlint /var/poudriere/jails/111STABLEi386/usr/bin/lint install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 lint.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/bin/lint.debug install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 lint.1.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man1/ ===> usr.bin/xlint/llib (install) lint -cghapbx -I/usr/obj/i386.i386/var/poudriere/jails/111STABLEi386/usr/src/tmp/usr/include -Cposix /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix sh: lint: not found *** [llib-lposix.ln] Error code 127 make[6]: stopped in /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib 1 error # ls -l /usr/bin/lint /usr/bin/true -r-xr-xr-x 1 root wheel 4976 Dec 30 12:37 /usr/bin/lint -r-xr-xr-x 1 root wheel 4976 Dec 29 21:13 /usr/bin/true From owner-freebsd-current@freebsd.org Tue Jan 2 01:27:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F41DEA7AD4 for ; Tue, 2 Jan 2018 01:27:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1337D67494; Tue, 2 Jan 2018 01:27:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x231.google.com with SMTP id c16so13222469itc.5; Mon, 01 Jan 2018 17:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OqH8zhDZnCu6Zysq5jYAoKvA+aypOyUHI2rlk1Oupp8=; b=eVqaXA9aEq+UaOYNYSpZMehtsbRNYnZT4qkS4HR7/n3mxBeL2m3ZQ+FVX65z4rW88I RZ5NAXZQtkAxkRDvAx7vNqsY33VjRsRiZClsMKZp9kLyJxrv7IhQfV8S4P8bmYZsyiPS Ru2M0dZDEWPSqhDFa03Uy0zfvBHKC/2X3CMli+jr1tb/R1QSNZOOye4btA8nYOwp7A2P OqWeuIPFgpPr7YtgNbz5XnWfwQ3qly+8yR5ODltnIJB/yJs9qCjcnumDzRtcRs2y/z+D dEy8ekZ1Ta/5Sg3JJ0XDRL824TsYTtraV68n1dgRztESFBEQq5J9rVfQC67aYLeI0yhW 5URg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OqH8zhDZnCu6Zysq5jYAoKvA+aypOyUHI2rlk1Oupp8=; b=PxDSTs+XWjieOqGrYqJOzsHonQtbUzFrWa2H/WnZVhLGB5AzcaK9jCsYvtWp7v8M1B xozAytWyD//rRWzCHRuXs671sEnH971PsnMobDBiSAZMiL1TSfaYSXG7XImLf/9r4dA5 WUwDeHOaQqj1yknYs1ZC/KhzBl+O+PlpM+Zy/osgYtWpiD2l28JjKJ9/oGAr9m0zJjIn liyIwiFi9SJE46fiD4fFGOrgVmxIQdpYgFSfn9byqY4ZXH/NJGtDkSeHweuQ8/FIva6U eQIR4xk+jID8qXweGTx7JVpMo/vS9UjB27BmZ4oyAZgMWNlm7MHRBflUmW6KuKLvFoIb 9Phg== X-Gm-Message-State: AKGB3mI94hDqYrRyESzoNshqPj9GhdHiZnNBD2EyHZOKuwmQsD9gdC9F hL+Z1sAI+z41+fdCkQZSD4nlnyo4embHJhGf8v3Fzm17 X-Google-Smtp-Source: ACJfBosCur2FW/qEyZKWnhKwtWCOQtinomep/Ru3Xhyqg90Gdyn/R9mEg6iNnHIh5zt48FfHJH33P5GlWCwkpjLZPxY= X-Received: by 10.36.221.147 with SMTP id t141mr56963359itf.140.1514856422197; Mon, 01 Jan 2018 17:27:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Mon, 1 Jan 2018 17:27:01 -0800 (PST) In-Reply-To: <1514823989.12000.30.camel@freebsd.org> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <1514823989.12000.30.camel@freebsd.org> From: blubee blubeeme Date: Tue, 2 Jan 2018 09:27:01 +0800 Message-ID: Subject: Re: Programmatically cache line To: Ian Lepore Cc: Konstantin Belousov , David Chisnall , Adrian Chadd , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 01:27:03 -0000 On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore wrote: > On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote: > > On Mon, Jan 01, 2018 at 06:52:37AM +0000, David Chisnall wrote: > > > > > > On 1 Jan 2018, at 05:09, Adrian Chadd wrote: > > > > > > > > > > > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: > > > > > > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: > > > > > > > > > > > > Is there some way to programmatically get the CPU cache line > sizes on > > > > > > FreeBSD? > > > > > There are, all of them are MD. > > > > > > > > > > On x86, the CPUID instruction leaf 0x1 returns the information in > > > > > %ebx register. > > > > Hm, weird. Why don't we extend sysctl to include this info? > > For the same reason we do not provide a sysctl to add two integers. > > > > > > > > > > > It would be nice to expose this kind of information via VDSO or > similar. There are a lot of similar bits of info that people want to use > for ifunc and, SVE is going to have a bunch of similar requirements. > > > > > Is VDSO a new trendy word ? > > > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which > > are essentially cpu_features / cpu_features2 / cpu_stdext_features / > > cpu_stdext_features2. I suspect that only FreeBSD/x86 arches have the > > ifunc support, in rtld and coming shortly in kernel. > > > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3) > > interface exported from libc. > > > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is > > considered a low priority because there is no ready to use toolchain > > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd > > ld externally. > > Linux exports this info using getauxval(). I think we should support > getauxval() and as many of the AT_* values that linux defines as makes > sense for us to do. > > I think it was a mistake to give our version of the function a > different name and different semantics, but this is something that > affects mainly ports, and I don't yet have enough info to make the case > that being linux-compatible will ease porting rather than complicate it > (in some cases, patches will be needed either way). > > -- Ian > FreeBSD implements hardware specific atomic instructions [man atomic] or look at: #include but implementing something that returns size of cache lines is somehow out of the question? If you're working with atomic data structures and want to ensure there's no false sharing the simplest method I know is to put some padding that's sizeof(cache_line) - sizeof(data_members) so that you can try to get them to live on different cache line. Do we have to go in and write inline assembly to grab the size of the cache line or wouldn't it be simpler to have atomic.h return this info? From owner-freebsd-current@freebsd.org Tue Jan 2 05:50:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45463EB4716 for ; Tue, 2 Jan 2018 05:50:00 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 CB080705BB; Tue, 2 Jan 2018 05:49:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w025nvwm089721; Mon, 1 Jan 2018 21:49:57 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w025nvEK089720; Mon, 1 Jan 2018 21:49:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801020549.w025nvEK089720@pdx.rh.CN85.dnsmgr.net> Subject: Re: panic: invalid bcd 194 In-Reply-To: <1514851362.1759.8.camel@freebsd.org> To: Ian Lepore Date: Mon, 1 Jan 2018 21:49:57 -0800 (PST) CC: Matthias Apitz , freebsd-current@freebsd.org, cem@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-Mailman-Approved-At: Tue, 02 Jan 2018 11:42:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 05:50:00 -0000 > On Mon, 2018-01-01 at 09:54 +0100, Matthias Apitz wrote: > > El d?a domingo, diciembre 31, 2017 a las 10:19:50a. m. -0700, Ian Lepore escribi?: > > > > > > > > > > > > > I will let the C720 over night under power while sitting in the boot menu, > > > > maybe this will fix the RTC battery issue. > > > > > > > Last time I worked on RTC stuff, cleaning this up got put on my "to-do > > > some day" list. ?I think maybe that day has arrived. > > > > > > -- Ian > > For the moment we solved the issue by booting some older r28nnnn > > memstick, writing a correct date with ntpdate into the RTC and rebooted > > without poweroff. It seems that the RTC survives even some short > > powercyle. > > > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e. > > no chance to be replaced. > > > > The issue must be fixed in FreeBSD, i.e. it should boot even with a > > broken RTC. Should I file a PR for this? > > > > I'm happy to test any patch for this. > > > > matthias > > > > Okay, I've created a pair of patches for this. ?The first adds some > common support routines usable by all RTC drivers with BCD hardware. > ?The second one converts the atrtc driver to use those routines. ?The > common code was tested using an i2c RTC chip, but I don't have an x86 > testbed, so the atrtc patch is currently untested (it compiles). Would the rtc.c emulation in bhyve work for testing? usr.sbin/bhyve/rtc.c > > The patches are available in a pair of phabricator reviews, plus I'll > attach them to this mail. ?If the list scrubs the attachements, you can > download the patches from the phab urls below, just hit the Actions > button and look for Download Raw Diff. > > https://reviews.freebsd.org/D13730 > https://reviews.freebsd.org/D13731 > > -- Ian -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Jan 2 13:00:36 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73863EA48C0 for ; Tue, 2 Jan 2018 13:00:36 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 311567E2ED; Tue, 2 Jan 2018 13:00:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.130.252] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eWMB8-0004qk-10; Tue, 02 Jan 2018 14:00:26 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id w02D0MJq002324 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jan 2018 14:00:22 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id w02D0K8E002323; Tue, 2 Jan 2018 14:00:20 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Jan 2018 14:00:20 +0100 From: Matthias Apitz To: Ian Lepore Cc: freebsd-current@freebsd.org, cem@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180102130020.GA2236@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Ian Lepore , freebsd-current@freebsd.org, cem@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <1514851362.1759.8.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <1514851362.1759.8.camel@freebsd.org> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.252 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 13:00:36 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa lunes, enero 01, 2018 a las 05:02:42p. m. -0700, Ian Lepore esc= ribi=C3=B3: > Okay, I've created a pair of patches for this. =C2=A0The first adds some > common support routines usable by all RTC drivers with BCD hardware. > =C2=A0The second one converts the atrtc driver to use those routines. =C2= =A0The > common code was tested using an i2c RTC chip, but I don't have an x86 > testbed, so the atrtc patch is currently untested (it compiles). >=20 > The patches are available in a pair of phabricator reviews, plus I'll > attach them to this mail. =C2=A0If the list scrubs the attachements, you = can > download the patches from the phab urls below, just hit the Actions > button and look for Download Raw Diff. >=20 > https://reviews.freebsd.org/D13730 > https://reviews.freebsd.org/D13731 Ian, I've applied your patches by hand to the kernel source r314251 and added in addition two printf's to atrtc.c to see the entry in atrtc_gettime() and atrtc_set(). I've compiled the kernel with # make buildworld -DNO_CLEAN and copied over the new kernel with=20 # cp /usr/obj/usr/src/sys/GENERIC/kernel /boot/kernel/kernel The kernel boots fine as: FreeBSD c720-r314251 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r314251M: Tue Jan= 2 12:53:31 CET 2018 guru@c720-r314251:/usr/obj/usr/src/sys/GENERIC a= md64 but: while the current date is read with the correct time, the year is 1970: # date Tue Jan 2 1970, 13:45:24 CET One can set the date/time with the date(1) command or ntpdate. The debug messages are (the first line is from boot, the others from the date or ntpdate): # grep DEBUG /var/log/messages Jan 2 13:43:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() entry Jan 2 13:43:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() entry Jan 2 13:44:00 c720-r314251 kernel: BCD DEBUG: atrtc_set() entry --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpLgl0ACgkQR8z35Hb+ nRHsyQ//cxV91HKEXAOYKLqEAiuf51a0p831jjMF2OCMC7IZ6QfKXbfgtUEQiNAp DUQzaptRr34Eo0fPftoR98goMQu5Ja3acCORkZrekub+IDD8O6wf3lxSbRHyNlFV P8AxQrFN2Ju4d0qN/3Jt47ie66EntjcDUfIQXH0GaqWhG0f1kQzMSIcOGX/neRjZ G4h7a1xjqqdmFuQRokCUhsiMAD4F1TWtcPfqUzgAe7U59h8zWhFiSq0Eqgmsfdlw HL+bK51/8KJBLU3oaFt0+YhtBTGywj9Lf2ygfNFNEXxojk0B7Y7IvF/K5lHam5xF tDFJcT+cJQPu27ePMkyhxmXkztEEjF9L6TUrNjWvWDgA6Lui88Jjh5FlGactZ8F0 l9CHKb1pLEhVRjg+HvHg/Cmv88sLH5z5bOJ6HSy6oWaVW11ACmyh9Cj/fpMdjOgc OenXtSIMZaNmz0oWQqG8NeJhOcLoHQ8fQA4so6CPfA90eAW/tsAenqjCtq+8oXqb NvxUxSZCCtJCBAmb4wanESreygICaKTexd+PdjRjRFvrSgx4LqDQnGfJossBuz32 hf05K1QIl8L9qlFFViJzW9QG07z/UKo7ipLpxvsNAKqvoQgaBopzOcbJiKJM8M9L tm4nB/vrHJoAiN5Jv6Dg9gUC4/PaeencoKKvuySRiUSdpsRCw3g= =20DS -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-current@freebsd.org Tue Jan 2 14:17:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15874EA7ACC for ; Tue, 2 Jan 2018 14:17:20 +0000 (UTC) (envelope-from pdagog@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BDB680B3E for ; Tue, 2 Jan 2018 14:17:19 +0000 (UTC) (envelope-from pdagog@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id f8so37841726wre.4 for ; Tue, 02 Jan 2018 06:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:jabber-id:user-agent; bh=L4VdoPA5UM58sKgDMHQf4xdymXMJwjGT9oECsYljlg0=; b=Gi6OYBK2wkWHHvYN2ETgV1LB/8jpBEgyd3Lxm5nclmfKQ63j25UZ97Ifpt0DzorSlE xzs58RV1ZXLvz/nPtahC9UXxoIPaGes/gkdg/KBGkAawSUU2MAwLnIVDx3bPKZD1scDA XJgeDk63Zo8J3TLpb65GRtegpG2PW2wLG8/Ohx0WWUG8w/SabXIV7Uhfnp5uHJ8mxBrz phGs6Cx6RxZvLHRFQsthPeoTtLK6x7iGY4Y7KRai6dRonj4TAn0S8gAT2goE0UdlUoPL 7JGiBb55sYXJ+2u21NTl6etZPjFNloqxbXvXrIQu9Rss9pvmoFRAJxaOzu8aqKlNEUw1 kp0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:jabber-id:user-agent; bh=L4VdoPA5UM58sKgDMHQf4xdymXMJwjGT9oECsYljlg0=; b=i6lVE0XF5FEXxulN/Hv9LTGUSGnDO8mO8EXd0+yjMQBVNe1cJBeIDs2SL2fgYPdfwn QTmmudKmQ9EETd8OxzaWGRV0WPsieY/HTi44+hCu20Y+bFphZFbJ170p8yLRrc7azr/S zLLmxs20O2qkbasZ4hrxAhqlVkA/hKMvsV2CBUBjXuzHMW7WW21CLeTA2A1pf188MX+4 ko+9ruHO/dFLp1IduXKdq9WstfZ98MDzeuG8nayOraJkaiUC2dIzIudAwZBsSbuC/oFr yCWO2BRNxGQWNLG6YgqhM88qeyeyqc2gUEPUI83xk2ofSURsTF4QepMrJe2q1n3HkGRF 9l9A== X-Gm-Message-State: AKGB3mIbfZIJA1C2XsYZBrkBeBB1/Vo+bzfZwE4INaO31/SEBbsEOGV3 FZDHxmG/PDPY06JRBcB+Ozw= X-Google-Smtp-Source: ACJfBosZtTpCRfLCSmrpxPJIUnn0mHzUzVmOCBYC6uURkRJ5j+1H5hNu2o+HMwdsKvpfc+M2edM5kA== X-Received: by 10.223.136.243 with SMTP id g48mr35458933wrg.247.1514902637849; Tue, 02 Jan 2018 06:17:17 -0800 (PST) Received: from localhost ([2001:470:1f13:1334:16a:5483:36cd:d8b]) by smtp.gmail.com with ESMTPSA id m68sm56614715wmi.28.2018.01.02.06.17.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 06:17:17 -0800 (PST) Date: Tue, 2 Jan 2018 15:17:14 +0100 From: Pierre DAVID To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Problem with C11 _Atomic Message-ID: <20180102141714.GA16473@vagabond> References: <20180101204740.GA15590@vagabond> <20180101210907.GG1684@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180101210907.GG1684@kib.kiev.ua> Jabber-ID: pdagog@gmail.com User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 14:17:20 -0000 On Mon, Jan 01, 2018 at 11:09:07PM +0200, Konstantin Belousov wrote: >On Mon, Jan 01, 2018 at 09:47:40PM +0100, Pierre DAVID wrote: >> Hi, >> >> I'm on a recent current: >> FreeBSD biceps.ma.maison 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327239: Wed Dec 27 18:25:46 CET 2017 pda@biceps.ma.maison:/usr/obj/usr/src/amd64.amd64/sys/BICEPS amd64 >> >> with clang 5.0.1: >> FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 5.0.1) >> Target: x86_64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> >> I'm having a problem with the following source file: >> >> ------------------------------------------------------------------------------ >> #include >> >> struct foo >> { >> int f1 ; >> char f2 ; >> int f3 ; >> } ; >> >> _Atomic struct foo a ; >> struct foo b ; >> >> int main (int argc, char *argv []) >> { >> b = (struct foo) {.f1 = 5, .f2 = 7, .f3 = 9 } ; >> // atomic_store (&a, b) ; >> a = b ; >> } >> ------------------------------------------------------------------------------ >> >> This code does not compile/link with: >> % cc foo.c -lstdthreads >> /tmp/foo-a0ef26.o: In function `main': >> foo.c:(.text+0x63): undefined reference to `__sync_lock_test_and_set_16' >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> >> The gcc internal seems to be linked as "cc -v" told me: >> % cc -v foo.c -lstdthreads >> ... >> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/foo-d7a21b.o -lstdthreads -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >> >> The problem occurs with "atomic_store(&a, b)" as well as with "a = b". >> >> If I remove the f3 member, the struct foo is only 8 bytes and the code >> compiles/links. >> >> Did I missed something? > >clang issues a calls to libatomic, which we do not provide. >As a workaround, use the following command to compile. The resulting >binary works on all practically usable machines. > $ cc -march=core2 source.c >You might want to turn off sse3/4.1 if you are concerned about older pentium4. > Thanks for your help. I wish that the C11 status of FreeBSD will soon be complete out of the box, without the help of such a hack. Pierre From owner-freebsd-current@freebsd.org Tue Jan 2 14:33:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35335EA859E for ; Tue, 2 Jan 2018 14:33:19 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9DAE175D for ; Tue, 2 Jan 2018 14:33:18 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x233.google.com with SMTP id i11so61115455wmf.4 for ; Tue, 02 Jan 2018 06:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fzAK+W5krYj0hfy2dJBnt0gyl8zkAeSJawKpTPN1hiA=; b=XQdg4ZqBv4TaI4S4NMuspp4DcTl2AE+vXXEyhJ0oydzEvTukOkt5q/RxkJySDBUvsg J38yj30iU6EfbFWv3DUtZkL+78EWVleRJsdN7k9J9o27GZ6R1kU/5JYayYAUIRBZn6pQ NVLIs80WUdVLcpaIa5bRlrJL6++oxCKKuDdl5zTFbJy8FV9zfvEfKHEVhCgFkdrb5bC9 djJnTBq6j3QQhktHvI/rJqrlPH55XAmuFsqiDXmR/XldjJgZ4kxOs2ZTEEdNXKRAcpMa qNn19M9JzYd+sMlZbCEDWo0ZV8G+bkQJJbk6PG/IlZCBl4tBKVwR0mKdFPSid5PGgdfj UpNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fzAK+W5krYj0hfy2dJBnt0gyl8zkAeSJawKpTPN1hiA=; b=JpfRrVfU/qIYo3mP5Hm4y31UU01CHOcCPJdWP+FApP6w+9OrOFwJKhK836u9tdq/u2 oKy4FZLFXrlYmjabT/NhFX4KwECt3V02lKJZdE9oK5dLW0jogxjxOqDUbzKq+wS1jd7w 2DCiAjro11JVkFYysXaba89Pt5kg1vqrslWagHvNynKtj0heIfstTs4mjtQFJQyrgxS6 3B+yo6d22mUrv/bx2oPQze7kdPULoRBY3piEQU65HsiWMCigYDPluXI6MAuVoSWdCYxm DC71D+JVE87b6D3Q5vDCmgyeW/q2+pXSigjCdiU9xHdU0Ri4VZEK68hASU7dDClGZK09 MF/A== X-Gm-Message-State: AKGB3mL5P+JOB+IuUZ5SluS5ZgXZElhm/IyvA+JCCoZSW5qRL2q21f8P 6vv4nzqGSyUGJO54abm47XUTtg== X-Google-Smtp-Source: ACJfBotZTIqroRtgGRsCkYPf6B4DXeZwx3KOtsy5YfxzEQhgoJz6nRC82D+v1a3Cd5EmmCkx5xQ8vg== X-Received: by 10.28.160.6 with SMTP id j6mr37842736wme.125.1514903597072; Tue, 02 Jan 2018 06:33:17 -0800 (PST) Received: from mutt-hbsd (lumumba.torservers.net. [77.247.181.163]) by smtp.gmail.com with ESMTPSA id i33sm36798612wri.90.2018.01.02.06.33.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Jan 2018 06:33:16 -0800 (PST) Date: Tue, 2 Jan 2018 09:33:08 -0500 From: Shawn Webb To: Don Lewis Cc: freebsd-current@FreeBSD.org Subject: Re: more fallout from removal of lint Message-ID: <20180102143308.3dmv7sdqccuehrid@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nv5xpc7pav5wci7g" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171208 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 14:33:19 -0000 --nv5xpc7pav5wci7g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: > Since lint was removed from 12.0-CURRENT, it is not possible to build > 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that > by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick > doesn't work when updating a 11.1-STABLE poudriere jail on a > 12.0-CURRENT host. >=20 > =3D=3D=3D> usr.bin/xlint (install) > =3D=3D=3D> usr.bin/xlint/lint1 (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g = wheel -m 555 lint1 /var/poudriere/jails/111STABLEi386/usr/libexec/lint1 > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g whe= el -m 444 lint1.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr= /libexec/lint1.debug > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g whe= el -m 444 lint.7.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man7/ > =3D=3D=3D> usr.bin/xlint/lint2 (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g = wheel -m 555 lint2 /var/poudriere/jails/111STABLEi386/usr/libexec/lint2 > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g whe= el -m 444 lint2.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr= /libexec/lint2.debug > =3D=3D=3D> usr.bin/xlint/xlint (install) > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g = wheel -m 555 xlint /var/poudriere/jails/111STABLEi386/usr/bin/lint > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g whe= el -m 444 lint.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/= bin/lint.debug > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g whe= el -m 444 lint.1.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man1/ > =3D=3D=3D> usr.bin/xlint/llib (install) > lint -cghapbx -I/usr/obj/i386.i386/var/poudriere/jails/111STABLEi386/usr/= src/tmp/usr/include -Cposix /var/poudriere/jails/111STABLEi386/usr/src/usr.= bin/xlint/llib/llib-lposix > sh: lint: not found > *** [llib-lposix.ln] Error code 127 >=20 > make[6]: stopped in /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xl= int/llib > 1 error >=20 >=20 > # ls -l /usr/bin/lint /usr/bin/true > -r-xr-xr-x 1 root wheel 4976 Dec 30 12:37 /usr/bin/lint > -r-xr-xr-x 1 root wheel 4976 Dec 29 21:13 /usr/bin/true I had filed[1] a bug report about this a little over a month ago and FreeBSD was disinterested in even discussing it. HardenedBSD worked around the issue by disabling the build of lint in its 11-STABLE and 10-STABLE trees. [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223892 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --nv5xpc7pav5wci7g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlpLmCAACgkQaoRlj1JF bu7fbA//W3/zdjHNcZu3lhxpF9IE36yIip7khankatELedHYqaSqh0Aq6vA7pwEy V0ORHfxTnSgeW4ut63MdxaTiGq5UuY+aTo6eQeq3bpCvGxgZO1tbeZGIVPrYUKIQ dAxH4odrkmHWfWs9fSq6ZYcWyR96H3YRQy2QyZ2c18J/d3Fed5nv+Kl4nIgD4NKo Hg20/1T/XYivXor0CjswsXXBZBItlrrM8e4+Kn3yhtsQ6YmeP1rlGAy9MWkfpqU9 AsCGQg3nOR/Vk7EALddjlw/VsNA7LPFx6dkhcw4sBbVVz/QShbl/kgyuJn9VZhTZ vKdUZOGi9adRXY0Z8UIJU/5aRc49BWxVzesd8NdXr7NHQBYlLPd+evtNRgNL4EEa a922iG9Q9LJhUB3quXXerimtQBJAz6RLpqvbw46YPVC8Jb7qyx15AHAHdh2/fVZk FWJFfaEiFiqhp8bfGmG8wALO7FPDaChmS8dbzSt4MLshqzYIwThlpADRqL6lwpwl XNJkIGCdVw4QpPH3dwsMMBavrrlZgP+BWD1oQIxWl9bINtaUi3e0ITve7kRhAafS vmy2BvQlfB6qj0W2uQZNsT1ufEy+Aa0+VIeAgjJYdaz+u+gwcljWTD+oKUt6zu9D oRXeIckPlawUgxVy33m0bPmr9ct33TS93+CjTbhCIznc4nAnIuc= =xJLP -----END PGP SIGNATURE----- --nv5xpc7pav5wci7g-- From owner-freebsd-current@freebsd.org Tue Jan 2 14:34:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C81D5EA874A for ; Tue, 2 Jan 2018 14:34:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 60124192B for ; Tue, 2 Jan 2018 14:34:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w02EYTeh022285 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jan 2018 16:34:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w02EYTeh022285 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w02EYT5I022284; Tue, 2 Jan 2018 16:34:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Jan 2018 16:34:29 +0200 From: Konstantin Belousov To: Pierre DAVID Cc: freebsd-current@freebsd.org Subject: Re: Problem with C11 _Atomic Message-ID: <20180102143429.GK1684@kib.kiev.ua> References: <20180101204740.GA15590@vagabond> <20180101210907.GG1684@kib.kiev.ua> <20180102141714.GA16473@vagabond> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180102141714.GA16473@vagabond> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 14:34:38 -0000 On Tue, Jan 02, 2018 at 03:17:14PM +0100, Pierre DAVID wrote: > On Mon, Jan 01, 2018 at 11:09:07PM +0200, Konstantin Belousov wrote: > >clang issues a calls to libatomic, which we do not provide. > >As a workaround, use the following command to compile. The resulting > >binary works on all practically usable machines. > > $ cc -march=core2 source.c > >You might want to turn off sse3/4.1 if you are concerned about older pentium4. > > > > Thanks for your help. I wish that the C11 status of FreeBSD will soon > be complete out of the box, without the help of such a hack. This is not FreeBSD but clang. Also I looked at the generated reference, and the referenced symbol was absent in the gcc' 7.2.0 libatomic. Same common problem with i386 and same cmpxchg8b is popular because the default arch is i486. This is a clang way of operations. From owner-freebsd-current@freebsd.org Tue Jan 2 14:37:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5178EEA8A18 for ; Tue, 2 Jan 2018 14:37:46 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 0E4B51DCC; Tue, 2 Jan 2018 14:37:45 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [89.204.130.252] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eWNhG-0002eL-GI; Tue, 02 Jan 2018 15:37:42 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id w02EbcrN002370 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jan 2018 15:37:38 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id w02EbcRU002369; Tue, 2 Jan 2018 15:37:38 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Jan 2018 15:37:37 +0100 From: Matthias Apitz To: Ian Lepore , freebsd-current@freebsd.org, cem@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180102143737.GA2286@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Ian Lepore , freebsd-current@freebsd.org, cem@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <1514851362.1759.8.camel@freebsd.org> <20180102130020.GA2236@c720-r314251> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20180102130020.GA2236@c720-r314251> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.252 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 14:37:46 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa martes, enero 02, 2018 a las 02:00:20p. m. +0100, Matthias Apit= z escribi=C3=B3: > # cp /usr/obj/usr/src/sys/GENERIC/kernel /boot/kernel/kernel >=20 > The kernel boots fine as: >=20 > FreeBSD c720-r314251 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r314251M: Tue J= an 2 12:53:31 CET 2018 guru@c720-r314251:/usr/obj/usr/src/sys/GENERIC = amd64 >=20 > but: while the current date is read with the correct time, the year is 19= 70: >=20 > # date > Tue Jan 2 1970, 13:45:24 CET >=20 > One can set the date/time with the date(1) command or ntpdate. >=20 > The debug messages are (the first line is from boot, the others from the > date or ntpdate): >=20 > # grep DEBUG /var/log/messages > Jan 2 13:43:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() entry > Jan 2 13:43:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() entry > Jan 2 13:44:00 c720-r314251 kernel: BCD DEBUG: atrtc_set() entry I've added one more printf to see what is coming as year from BCD. The code is attached below and bcd.year comes out as 24 (decimal) which is 0x18. I.e= =2E it seems that the year from 2018 is stored in hex as 0x18, or? Jan 2 15:08:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() entry witho= ut USE_RTC_CENTURY Jan 2 15:08:02 c720-r314251 kernel: BCD DEBUG: atrtc_gettime() bct.year=3D= 24 Jan 2 15:13:00 c720-r314251 kernel: BCD DEBUG: atrtc_set() entry without U= SE_RTC_CENTURY Jan 2 15:14:34 c720-r314251 kernel: BCD DEBUG: atrtc_set() entry without U= SE_RTC_CENTURY static int atrtc_gettime(device_t dev, struct timespec *ts) { struct bcd_clocktime bct; #ifdef USE_RTC_CENTURY printf("BCD DEBUG: atrtc_gettime() entry with USE_RTC_CENTURY\n"); #else printf("BCD DEBUG: atrtc_gettime() entry without USE_RTC_CENTURY\n"); #endif /* Look if we have a RTC present and the time is valid */ if (!(rtcin(RTC_STATUSD) & RTCSD_PWR)) { device_printf(dev, "WARNING: Battery failure indication\n"); return (EINVAL); } /* * wait for time update to complete * If RTCSA_TUP is zero, we have at least 244us before next update. * This is fast enough on most hardware, but a refinement would be * to make sure that no more than 240us pass after we start reading, * and try again if so. */ while (rtcin(RTC_STATUSA) & RTCSA_TUP) continue; critical_enter(); bct.sec =3D rtcin(RTC_SEC); bct.min =3D rtcin(RTC_MIN); bct.hour =3D rtcin(RTC_HRS); bct.day =3D rtcin(RTC_DAY); bct.mon =3D rtcin(RTC_MONTH); bct.year =3D rtcin(RTC_YEAR); #ifdef USE_RTC_CENTURY bct.year |=3D rtcin(RTC_CENTURY) << 8; #endif critical_exit(); /* dow is unused in timespec conversion and we have no nsec info. */ bct.dow =3D 0; bct.nsec =3D 0; printf("BCD DEBUG: atrtc_gettime() bct.year=3D%d\n", bct.year); return (clock_bcd_to_ts(&bct, ts)); } --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpLmS8ACgkQR8z35Hb+ nRHuMhAAl0DON2T2bsrKNS1uoGweMKFhvZFinw1azVgfOM/1CEcWZRLMAxctuO2A R279bkJzbHaL2+c+uYF9Y1EXK0F5uNcb4hilJxaKTlg8Wgs3vIBnUGUDVsJZAudM wkKgn62Rf/7s5MaxoKLJgT36o9KSmnFdoRYdi5WOBJO8eb2p34HZGtISGwWrYMNw DJAg1wS9gclW+G4a2OnTyPb4Y4NAiMzxt6fA1QE2cjhZCjeSXqaE8WSw5i4BzI9b Md+pUkKOQBXBjPIthCrlHCzfZhGQzLJdrIyTF5yB+i6xgb+5aMfO6vCYKdd2PwtD ah+eU0V9jQIFM3xFLrm/x3uJhv9TX2eIyt6pkHPVCP7jmn+2wuaYZ5XoBTNWrsLX IqjnuMqETUbjNIWbsHypFHL+SDMdNjdfcl5XdQTKrxfK76Z/INzQaaHyuofyEYLz FioQfVBPxSDoOJo6fcg33AEugNVyLxhF/LrTkWoUpew8sc0Bpn1t2qVLxKm7Z41b yuS7DqdsF8Nv6AB0Ue8hUxMvKhgrE9VQ2sFSklNRMBV2mROzGNdjXy9OrrsgXnoJ YQtgHyM2gvlUQb/fpjLUv3txYVugQGNMTfu6AbuJWRnkro12VHpkRlVlp8hLLeDc NNu4WX/ip2iUvCQZQh2QFaEOreTUX+xcqMxic0ou71W9Sxfaem4= =IcwO -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@freebsd.org Tue Jan 2 15:26:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05B24EAABFD for ; Tue, 2 Jan 2018 15:26:32 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 BD6A03E90 for ; Tue, 2 Jan 2018 15:26:31 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eWOSV-000PSo-Mr; Tue, 02 Jan 2018 16:26:31 +0100 Date: Tue, 2 Jan 2018 16:26:31 +0100 From: Kurt Jaeger To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20180102152631.GN2827@home.opsec.eu> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <1514851362.1759.8.camel@freebsd.org> <20180102130020.GA2236@c720-r314251> <20180102143737.GA2286@c720-r314251> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180102143737.GA2286@c720-r314251> X-Mailman-Approved-At: Tue, 02 Jan 2018 15:28:24 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 15:26:32 -0000 Hi! > I've added one more printf to see what is coming as year from BCD. The code > is attached below and bcd.year comes out as 24 (decimal) which is 0x18. I.e. it > seems that the year from 2018 is stored in hex as 0x18, or? It's actually BCD code: https://en.wikipedia.org/wiki/Binary-coded_decimal -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Tue Jan 2 16:41:46 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 927C7EAE32A for ; Tue, 2 Jan 2018 16:41:46 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 5A92D683F1 for ; Tue, 2 Jan 2018 16:41:45 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [2.247.253.86] (helo=[10.250.117.86]) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eWPdG-0000PX-Kb; Tue, 02 Jan 2018 17:41:42 +0100 From: Matthias Apitz To: Kurt Jaeger Cc: Subject: Re: panic: invalid bcd 194 Date: Tue, 02 Jan 2018 17:41:41 +0100 User-Agent: Dekko/0.6.20; Qt/5.4.1; ubuntumirclient; Linux; MIME-Version: 1.0 Message-ID: <52f65ec7-af4e-4a80-950b-eada769d7430@unixarea.de> In-Reply-To: <20180102152631.GN2827@home.opsec.eu> References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> <20171230214819.GA2191@c720-r314251> <20171231083624.GA2175@c720-r314251> <1514740790.12000.20.camel@freebsd.org> <20180101085425.GA2301@c720-r314251> <1514851362.1759.8.camel@freebsd.org> <20180102130020.GA2236@c720-r314251> <20180102143737.GA2286@c720-r314251> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 2.247.253.86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 16:41:46 -0000 On Tuesday, 2 January 2018 16:26:31 CET, Kurt Jaeger wrote: > Hi! >=20 >> I've added one more printf to see what is coming as year from=20 >> BCD. The code >> is attached below and bcd.year comes out as 24 (decimal) which=20 >> is 0x18. I.e. it >> seems that the year from 2018 is stored in hex as 0x18, or? >=20 > It's actually BCD code: >=20 > https://en.wikipedia.org/wiki/Binary-coded_decimal >=20 So something must be wrong in the conversion into binary because the date=20 ends up as in year 1970. --=20 Sent from my Ubuntu phone http://www.unixarea.de/ From owner-freebsd-current@freebsd.org Tue Jan 2 19:48:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F95DEB5945 for ; Tue, 2 Jan 2018 19:48:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-153.reflexion.net [208.70.210.153]) (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 123AB6F7C9 for ; Tue, 2 Jan 2018 19:48:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2444 invoked from network); 2 Jan 2018 19:48:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jan 2018 19:48:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 02 Jan 2018 14:48:43 -0500 (EST) Received: (qmail 18158 invoked from network); 2 Jan 2018 19:48:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jan 2018 19:48:43 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C8A6CEC7B31; Tue, 2 Jan 2018 11:48:42 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: rpi2 head -r327485 (e.g.): rpi2 leaves one "CPU n" always idle for some boots Message-Id: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> Date: Tue, 2 Jan 2018 11:48:42 -0800 To: Freebsd-arm , FreeBSD Hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:48:51 -0000 I've seen this over many versions of head for months but have never managed to find a way to force it to happen. It just shows up once and a while. Thus, I'm just dumping out some top and kernel information here for reference. I've used: openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & to give the rpi2 4 active processes. Various outputs are from different times without a reboot between. top -CaePores shows the likes of: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 614 root 1 20 0 10452K 10480K 0K select 1 0:00 = 0.03% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift 661 root 1 52 0 9984K 6132K 0K select 1 0:00 = 0.00% /usr/sbin/sshd 751 root 1 101 0 7256K 4276K 0K RUN 1 0:28 = 99.57% openssl speed 750 root 1 100 0 7256K 4276K 0K CPU0 0 0:32 = 94.83% openssl speed 753 root 1 86 0 7256K 4276K 0K RUN 3 0:13 = 52.36% openssl speed 752 root 1 86 0 7256K 4276K 0K CPU3 3 0:14 = 46.54% openssl speed 363 root 1 20 0 6428K 3840K 0K select 3 0:00 = 0.00% /sbin/devd . . . and: last pid: 754; load averages: 3.70, 2.38, 1.58 = = up 0+00:16:50 01:59:37 21 processes: 5 running, 16 sleeping CPU 0: 94.9% user, 0.0% nice, 0.0% system, 5.1% interrupt, 0.0% idle CPU 1: 99.6% user, 0.0% nice, 0.0% system, 0.4% interrupt, 0.0% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 3: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 12M Active, 1136K Inact, 56M Wired, 30M Buf, 722M Free Swap: 1536M Total, 6M Free =46rom problem boot to problem boot, the CPU that stays idle has varied but usually has been CPU 2. I've never seen 2 or more stuck in idle. show allpcpu shows the likes of: db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x3d2540 curthread =3D 0xd8478ae0: pid 2032 tid 100150 "openssl" curpcb =3D 0xd852ae98 fpcurthread =3D 0xd8478ae0: pid 2032 "openssl" idlethread =3D 0xc376fae0: tid 100002 "idle: cpu0" curpmap =3D 0xd8e43bf4 curvnet =3D 0 cpuid =3D 1 dynamic pcpu =3D 0x3998540 curthread =3D 0xd7e5b3a0: pid 2031 tid 100173 "openssl" curpcb =3D 0xda7e0e98 fpcurthread =3D 0xd7e5b3a0: pid 2031 "openssl" idlethread =3D 0xc376f740: tid 100003 "idle: cpu1" curpmap =3D 0xd8e43ec4 curvnet =3D 0 cpuid =3D 2 dynamic pcpu =3D 0x3999540 curthread =3D 0xc376f3a0: pid 10 tid 100004 "idle: cpu2" curpcb =3D 0xc378ae98 fpcurthread =3D none idlethread =3D 0xc376f3a0: tid 100004 "idle: cpu2" curpmap =3D 0 curvnet =3D 0 cpuid =3D 3 dynamic pcpu =3D 0x399a540 curthread =3D 0xd8477000: pid 2034 tid 100167 "openssl" curpcb =3D 0xd876de98 fpcurthread =3D 0xd8477000: pid 2034 "openssl" idlethread =3D 0xc376f000: tid 100005 "idle: cpu3" curpmap =3D 0xc377ab04 curvnet =3D 0 In other words: it appears that the cpuN (here cpu2) is left with idle scheduled all the time for some reason. ps from db> shows things like: db> ps pid ppid pgrp uid state wmesg wchan cmd 2034 714 2034 0 R+ openssl 2033 714 2033 0 R+ CPU 3 openssl 2032 714 2032 0 R+ CPU 0 openssl 2031 714 2031 0 R+ CPU 1 openssl (then later:) db> ps pid ppid pgrp uid state wmesg wchan cmd 2034 714 2034 0 R+ CPU 3 openssl 2033 714 2033 0 R+ openssl 2032 714 2032 0 R+ CPU 0 openssl 2031 714 2031 0 R+ CPU 1 openssl There is also: 10 0 0 0 RL (threaded) [idle] 100002 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] =20 These are from: # uname -apKU FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 = 1200054 1200054 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jan 2 19:59:20 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80788EB6438 for ; Tue, 2 Jan 2018 19:59:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-101.reflexion.net [208.70.210.101]) (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 3F597701DA for ; Tue, 2 Jan 2018 19:59:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10071 invoked from network); 2 Jan 2018 19:59:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jan 2018 19:59:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 02 Jan 2018 14:59:13 -0500 (EST) Received: (qmail 13481 invoked from network); 2 Jan 2018 19:59:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jan 2018 19:59:13 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4E89DEC94C7; Tue, 2 Jan 2018 11:59:12 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 head -r327485 (e.g.): rpi2 leaves one "CPU n" always idle for some boots Date: Tue, 2 Jan 2018 11:59:11 -0800 References: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> To: Freebsd-arm , FreeBSD Hackers , FreeBSD Current In-Reply-To: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> Message-Id: <422E2742-7170-4D1A-894F-F310EE819E3A@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:59:20 -0000 On 2018-Jan-2, at 11:48 AM, Mark Millard wrote: > I've seen this over many versions of head for months > but have never managed to find a way to force it to > happen. It just shows up once and a while. >=20 > Thus, I'm just dumping out some top and kernel information > here for reference. I've used: >=20 > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & >=20 > to give the rpi2 4 active processes. Various outputs > are from different times without a reboot between. >=20 > top -CaePores shows the likes of: >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 614 root 1 20 0 10452K 10480K 0K select 1 0:00 = 0.03% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 661 root 1 52 0 9984K 6132K 0K select 1 0:00 = 0.00% /usr/sbin/sshd > 751 root 1 101 0 7256K 4276K 0K RUN 1 0:28 = 99.57% openssl speed > 750 root 1 100 0 7256K 4276K 0K CPU0 0 0:32 = 94.83% openssl speed > 753 root 1 86 0 7256K 4276K 0K RUN 3 0:13 = 52.36% openssl speed > 752 root 1 86 0 7256K 4276K 0K CPU3 3 0:14 = 46.54% openssl speed > 363 root 1 20 0 6428K 3840K 0K select 3 0:00 = 0.00% /sbin/devd > . . . >=20 > and: >=20 > last pid: 754; load averages: 3.70, 2.38, 1.58 = = up 0+00:16:50 01:59:37 > 21 processes: 5 running, 16 sleeping > CPU 0: 94.9% user, 0.0% nice, 0.0% system, 5.1% interrupt, 0.0% = idle > CPU 1: 99.6% user, 0.0% nice, 0.0% system, 0.4% interrupt, 0.0% = idle > CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% = idle > CPU 3: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% = idle > Mem: 12M Active, 1136K Inact, 56M Wired, 30M Buf, 722M Free > Swap: 1536M Total, 6M Free >=20 > =46rom problem boot to problem boot, the CPU that stays > idle has varied but usually has been CPU 2. I've never > seen 2 or more stuck in idle. >=20 > show allpcpu shows the likes of: >=20 > db> show allpcpu > Current CPU: 0 >=20 > cpuid =3D 0 > dynamic pcpu =3D 0x3d2540 > curthread =3D 0xd8478ae0: pid 2032 tid 100150 "openssl" > curpcb =3D 0xd852ae98 > fpcurthread =3D 0xd8478ae0: pid 2032 "openssl" > idlethread =3D 0xc376fae0: tid 100002 "idle: cpu0" > curpmap =3D 0xd8e43bf4 > curvnet =3D 0 >=20 > cpuid =3D 1 > dynamic pcpu =3D 0x3998540 > curthread =3D 0xd7e5b3a0: pid 2031 tid 100173 "openssl" > curpcb =3D 0xda7e0e98 > fpcurthread =3D 0xd7e5b3a0: pid 2031 "openssl" > idlethread =3D 0xc376f740: tid 100003 "idle: cpu1" > curpmap =3D 0xd8e43ec4 > curvnet =3D 0 >=20 > cpuid =3D 2 > dynamic pcpu =3D 0x3999540 > curthread =3D 0xc376f3a0: pid 10 tid 100004 "idle: cpu2" > curpcb =3D 0xc378ae98 > fpcurthread =3D none > idlethread =3D 0xc376f3a0: tid 100004 "idle: cpu2" > curpmap =3D 0 > curvnet =3D 0 >=20 > cpuid =3D 3 > dynamic pcpu =3D 0x399a540 > curthread =3D 0xd8477000: pid 2034 tid 100167 "openssl" > curpcb =3D 0xd876de98 > fpcurthread =3D 0xd8477000: pid 2034 "openssl" > idlethread =3D 0xc376f000: tid 100005 "idle: cpu3" > curpmap =3D 0xc377ab04 > curvnet =3D 0 >=20 > In other words: it appears that the cpuN (here cpu2) is > left with idle scheduled all the time for some reason. >=20 > ps from db> shows things like: >=20 >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 2034 714 2034 0 R+ openssl > 2033 714 2033 0 R+ CPU 3 openssl > 2032 714 2032 0 R+ CPU 0 openssl > 2031 714 2031 0 R+ CPU 1 openssl >=20 > (then later:) >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 2034 714 2034 0 R+ CPU 3 openssl > 2033 714 2033 0 R+ openssl > 2032 714 2032 0 R+ CPU 0 openssl > 2031 714 2031 0 R+ CPU 1 openssl >=20 > There is also: >=20 > 10 0 0 0 RL (threaded) [idle] > 100002 CanRun [idle: cpu0] > 100003 CanRun [idle: cpu1] > 100004 CanRun [idle: cpu2] > 100005 CanRun [idle: cpu3] >=20 >=20 > These are from: >=20 > # uname -apKU > FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 = 1200054 1200054 I probably should have reported that as I remember the following sort of thing is true for the problem cpuN (here cpu2): 100074 D - 0xd6f5be80 [softirq_0] 100075 D - 0xd6f5be00 [softirq_1] 100076 RunQ [softirq_2] 100077 D - 0xd6f5bd00 [softirq_3] 100078 D - 0xd6f5bc80 [if_io_tqg_0] 100079 D - 0xd6f5bc00 [if_io_tqg_1] 100080 RunQ [if_io_tqg_2] 100081 D - 0xd6f5bb00 [if_io_tqg_3] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Jan 2 23:13:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A58DEBE667 for ; Tue, 2 Jan 2018 23:13:48 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9C3B780A4 for ; Tue, 2 Jan 2018 23:13:47 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1514934825; bh=whesU6LCPS4BA+Qc2WUK4LT7VEtTU9Vc8cMMAtC TOVc=; b=i1W0GmtvVA5dCV3aXRlLqM2y4Wk30XgEg/q1T9RA6ApELNYp8oXEeHO bXu240OIClJ/CntCpda6xsghNvehjwfHfr14Tov8Y3Bg26IsLfpt/lWY0YmHm4Y1 zOOrsbO3FPUoVN5b16vdDH6Q5Oig4TiNUhDMJ0fDeUdW3U5Nz2ag= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id A130E35EA9 for ; Tue, 2 Jan 2018 18:13:45 -0500 (EST) To: FreeBSD Current From: Michael Butler Subject: Intel CPU design flaw - FreeBSD affected? Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> Date: Tue, 2 Jan 2018 18:13:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:13:48 -0000 Has any impact assessment been made as to FreeBSD's exposure or mitigation strategies? 'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign - The Register Other OSes will need an update, performance hits loom A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.… Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce necessary changes to its Windows operating system in this month's Patch Tuesday ... https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ imb From owner-freebsd-current@freebsd.org Tue Jan 2 23:50:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55020E80E0B for ; Tue, 2 Jan 2018 23:50:00 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAAB5794AF for ; Tue, 2 Jan 2018 23:49:59 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id g75so6026wme.0 for ; Tue, 02 Jan 2018 15:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+EMr8bfaJDn6o8vyDq0IqBextpp0MGK77r9Wklk+WkA=; b=tE/8+htv3cyKgrPftr07DOKs/cl2VZgbHeG4iTI58hibCn+yoxlwcl6BmszT1+D7L8 RCuMau24I3vP1WNlUqVOrZkTFEIX9poikDvx8PsmJm2GW22kO5MkrsP0YiLGdBq5vg7S BokDxiWTu2gxY+QfGya8vG9lyhcYN4hdezMoMsowNWwXOe44kQy0V5qjYIy0Lq77/EKw NmoHVbB7Q7UU93jzTV1m+viIWmoFh2Epv5ndmIUMlHi+XL+SSWJTFjHc3ji5WLsXxPLS 3//ajGV2l/YebaQDxLLqy07DKbMwiJgg6ZYxbEXPimEKF7/B+BubXJIMWxBnaX+W7xjc PCAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+EMr8bfaJDn6o8vyDq0IqBextpp0MGK77r9Wklk+WkA=; b=BkIICnsjnZeqMDTIDbirW1jSIXFRNFqQbSPs6BXeuHS4K5vpjLfpRtMMTM5sqU/rOa hETa2jKCncr4CgXRxI519a6E11F09e9q/pnwXYtuMPdg54eVzAmwllp1fFFj1pgpDyXH sNful6eAyIf6G9M2r6HISiOC2fD69uVtCJV7aErr+45yO9QT4k1eiLWCPDzp2/xLs7vm GHnMq+ydss/KPMsc2+jyGmzGM6HTAmVeRftCEczEFau9i2obE7mxuwMLxbOeEccjs17F tHoOO1Hk47xiZMfgtq7Ii2mB7KFuTtKCVJ+CxjIe96BHDmV1I/9CIO/xMXPz3O3IHnfB V/TQ== X-Gm-Message-State: AKGB3mLI/x68JmtxgWKnGmQiWXpVuF7xethNJzX30idnaWtK1gjVnetY xeSB+DVZqEM2YX72ShqbFIBpfCDiGSa6j9yHHw== X-Google-Smtp-Source: ACJfBotZECQauDC+XALdgD/rFnXim6JsKPsS3zU6COz/wxdcdN3gYJSI71WWLGcFaTo713siOaRb1xze6c6N6PFzB94= X-Received: by 10.80.165.109 with SMTP id z42mr74419edb.18.1514936998261; Tue, 02 Jan 2018 15:49:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.181.59 with HTTP; Tue, 2 Jan 2018 15:49:57 -0800 (PST) In-Reply-To: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: Zaphod Beeblebrox Date: Tue, 2 Jan 2018 18:49:57 -0500 Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Michael Butler Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:50:00 -0000 >From the information that was leaked by AMD claiming that their processors didn't have the flaws, it would seem any OS in which the kernel occupies the same address space as the userland would be vulnerable. The AMD post implied that Intel's speculative execution of code did not check the validity of the operands before speculatively executing the code. I suppose the implication is that the security check "catches up" with the speculative execution at some point ... and that their (AMD's) microcode did check. Anyways... for those keeping score at home, this is a privilege escalation bug... so it's only really useful in concert with other bugs ... but still pretty huge. Some estimate that between 5% and 30% performance degradation may be unavoidable. Some say it's worse or can't be fully fixed. Certainly, the sunk cost of current CPUs is a huge issue for server farm vendors like Amazon and/or google. On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler wrote: > Has any impact assessment been made as to FreeBSD's exposure or > mitigation strategies? > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > Windows redesign - The Register > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > From owner-freebsd-current@freebsd.org Wed Jan 3 00:05:19 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F843E81AF6 for ; Wed, 3 Jan 2018 00:05:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02B3F79DDA for ; Wed, 3 Jan 2018 00:05:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x243.google.com with SMTP id f6so434456ioh.8 for ; Tue, 02 Jan 2018 16:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UcjIy+8/B6Hp/fqvYVSoJueVN7eocRlULaBOtAIjmME=; b=oymxg/DA/z8XLkFisKCUI4BV0EsOtZ4//9q3t/9byFzB7mw3v39zR7lzk3MCmPGmhR ns0CBz1YMnqr6KL8Sbu/4XNJgtI1oN12KaVbALdkwaHWqXkBzdfAHAIHMFADWiqAmHyE Enug2xji94kJTbfO+LtnL8w1nUMuDbcYNMbJMiC8ZDmiiLRWJ8jRSRvOY14VudGCxPNN Bw3I1NMFxfzEIf7c4n13GeiznFFqN5EdooAmZBNd2Qcc95qx3DUp+qty+38yd+yTimyW FlGEY1DJELtSUKSSazyOei8CHnrK59aB+AJ1TslX4QFSxXrUM9R7sCNsGvhUOgf9ZLr/ aWgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UcjIy+8/B6Hp/fqvYVSoJueVN7eocRlULaBOtAIjmME=; b=gj9osNdnf34cF+PWJXeutv8CMs8a+bx2LuDUR7Hs5CFsobMJZgvkMbe10sToCngx+Z h6NL4BBSsPMUnRHXhI5hp8hP+jVFGocUtdFI7DafLjHWlDtzsDt7DZ4Gtto3hvRkh22B fiyk6WRWbWBnZcSFYuXNyniA2L348Wc5m7CMV4bkgSsrRymZexYGwwtZNhTl/ksjCG3r baIozpTrUx80Nd1yp3gCDllaZmQifClNk21mGlXy5sEC5PaLAU79fqdN0GA5AYlVuPFS 4JsfZSkwsz7zoZT5UD8fkgmXzhiTI+koipHMn7BTuB+86NYTHwCg9kWFc2gg9c363Idf bXjA== X-Gm-Message-State: AKGB3mJc9w56PR4InxED4NyQxE+fVEy05S5aaIr8ke84m0DGQTpz1G5y a7fD6G8AhpWxhCn4iefd/P/QyvBrTSFLU2Cg8pi9SQ== X-Google-Smtp-Source: ACJfBovshODhj6R5olJvfwje7BG7X2nBE8a4vrIwdeY/C/wLdoGVzKS5dlxOBJ3x4u4eC5CIwymMbkLQ+Heh579vnaA= X-Received: by 10.107.174.159 with SMTP id n31mr8554301ioo.136.1514937918191; Tue, 02 Jan 2018 16:05:18 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 2 Jan 2018 16:05:17 -0800 (PST) X-Originating-IP: [50.235.217.130] In-Reply-To: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: Warner Losh Date: Tue, 2 Jan 2018 17:05:17 -0700 X-Google-Sender-Auth: jO4NgBYjZzStBlLgNRL7cdX1M54 Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Michael Butler Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:05:19 -0000 The register article says the specifics are under embargo still. That would make it hard for anybody working with Intel to comment publicly on the flaw and any mitigations that may be underway. It would be unwise to assume that all the details are out until the embargo lifts. Warner On Jan 2, 2018 4:13 PM, "Michael Butler" wrote= : > Has any impact assessment been made as to FreeBSD's exposure or > mitigation strategies? > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > Windows redesign - The Register > > Other OSes will need an update, performance hits loom A fundamental > design flaw in Intel's processor chips has forced a significant redesign > of the Linux and Windows kernels to defang the chip-level security bug.= =E2=80=A6 > Programmers are scrambling to overhaul the open-source Linux kernel's > virtual memory system. Meanwhile, Microsoft is expected to publicly > introduce necessary changes to its Windows operating system in this > month's Patch Tuesday ... > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > imb > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@freebsd.org Wed Jan 3 00:19:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3D75E8268E for ; Wed, 3 Jan 2018 00:19:55 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 799BB7A46E for ; Wed, 3 Jan 2018 00:19:55 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WWmbeqoKGYy1iWWmdeNmsZ; Tue, 02 Jan 2018 17:19:53 -0700 X-Authority-Analysis: v=2.2 cv=f8g4PK6M c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=D19gQVrFAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=zxA2vyXaAAAA:8 a=DjmawdlsAAAA:8 a=7_L7dAYydk1ZARjlEjIA:9 a=rwgfiOSe-ZWq3uYu:21 a=7vCVVMijtMd7Exd9:21 a=QEXdDO2ut3YA:10 a=5wbvVQt16wSoSp6GMG0A:9 a=zQO9_-0KBcOaqJae:21 a=ohmKH1GSGUTl60CL:21 a=1zlxYZcvTtwue11F:21 a=_W_S_7VecoQA:10 a=W4TVW4IDbPiebHqcZpNg:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=nK2txNHJmq7TfjpuLlwI:22 a=9WNRskb1zeeanTosM84Z:22 Received: from [25.172.217.252] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 6AF4F2C9; Tue, 2 Jan 2018 16:19:49 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel CPU design flaw - FreeBSD affected? Date: Tue, 2 Jan 2018 16:20:00 -0800 To: Warner Losh , Michael Butler CC: FreeBSD Current Message-Id: <20180103001949.6AF4F2C9@spqr.komquats.com> X-CMAE-Envelope: MS4wfOZwIkIztMI0ALwhp4uD3fj2c4QhTpZ2VScJwpnv3pf6K0MdqT0yMFC2wo4I0o8S+npwicB75fY4uakIyi5E0pPE4ZKuzEG2dVAbbKxus/kXCa/mi2xi 7cTibobhCleaRjd4WKfpF5q2yjeG5FJAQpX1Eek0EqHO3o96KI3Y0zDOElMzIvbLQHAyp7R74YM2ZcVILY1GcmsjxaxBI0UuRtsRMw1nMWAPxJS+nvQi3gxp Xg0VMUdkcmxCG7nfuupsmcAbGmUJMyTEDKyJlAcBLU0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:19:55 -0000 This Linux commit gives us a hint. https://lkml.org/lkml/2017/12//27/2 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Warner Losh Sent: 02/01/2018 16:05 To: Michael Butler Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? The register article says the specifics are under embargo still. That would= =0A= make it hard for anybody working with Intel to comment publicly on the flaw= =0A= and any mitigations that may be underway. It would be unwise to assume that= =0A= all the details are out until the embargo lifts.=0A= =0A= Warner=0A= =0A= On Jan 2, 2018 4:13 PM, "Michael Butler" wrote= :=0A= =0A= > Has any impact assessment been made as to FreeBSD's exposure or=0A= > mitigation strategies?=0A= >=0A= > 'Kernel memory leaking' Intel processor design flaw forces Linux,=0A= > Windows redesign - The Register=0A= >=0A= > Other OSes will need an update, performance hits loom A fundamental=0A= > design flaw in Intel's processor chips has forced a significant redesign= =0A= > of the Linux and Windows kernels to defang the chip-level security bug.= =E2=80=A6=0A= > Programmers are scrambling to overhaul the open-source Linux kernel's=0A= > virtual memory system. Meanwhile, Microsoft is expected to publicly=0A= > introduce necessary changes to its Windows operating system in this=0A= > month's Patch Tuesday ...=0A= >=0A= > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/=0A= >=0A= > imb=0A= >=0A= > _______________________________________________=0A= > freebsd-current@freebsd.org mailing list=0A= > https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= "=0A= >=0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= =0A= From owner-freebsd-current@freebsd.org Wed Jan 3 00:29:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FE7EE82E84 for ; Wed, 3 Jan 2018 00:29:02 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6359D7AAE4 for ; Wed, 3 Jan 2018 00:29:02 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WWqlezOMyS7BpWWqmeNfGq; Tue, 02 Jan 2018 17:24:10 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=zxA2vyXaAAAA:8 a=DjmawdlsAAAA:8 a=6pCwMFOjS23r3FQTQlgA:9 a=pg4Z6IyG5yruRzWy:21 a=qC-V7iTMPdGOpj0R:21 a=CjuIK1q_8ugA:10 a=VNsLjGsGOZnTcv74ccgA:9 a=ZhtNsbIxDLB1L36W:21 a=BYMB9Ud3sxP5vqAt:21 a=8qy8v9n4PZQ8CTHH:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=nK2txNHJmq7TfjpuLlwI:22 a=9WNRskb1zeeanTosM84Z:22 Received: from [25.172.217.252] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 07E942E0; Tue, 2 Jan 2018 16:24:06 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel CPU design flaw - FreeBSD affected? Date: Tue, 2 Jan 2018 16:24:17 -0800 To: Zaphod Beeblebrox , Michael Butler CC: FreeBSD Current Message-Id: <20180103002407.07E942E0@spqr.komquats.com> X-CMAE-Envelope: MS4wfHDQeK+UiXBmsXE+eg8KDvH5FXkzhlG9G2jQrdVS1ITCjR/YZ54l4aN74J2nV35/cbI3JeBSu98f5gT5hVDOHCAMgsFv1mZ8+kxr+HVRATXvcmbNj+Yc 7H+P2HeVPHttUNE5hQCWVaUWmdrIXotfChRGV536EndbD/GG5FpEXGUSRaksdcBAnzeqPxCyfbW9kFHLRJSTq+pyRaf1SrEAld0zVa/wzPGEHWfo+SFkG9zW oZgGHMLc+PBPIHxFg/DhhA2Gjp0bz1Y8A6dcOzAQ2y4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:29:02 -0000 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Zaphod Beeblebrox Sent: 02/01/2018 15:50 To: Michael Butler Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? >From the information that was leaked by AMD claiming that their processors didn't have the flaws, it would seem any OS in which the kernel occupies the same address space as the userland would be vulnerable. The AMD post implied that Intel's speculative execution of code did not check the validity of the operands before speculatively executing the code. I suppose the implication is that the security check "catches up" with the speculative execution at some point ... and that their (AMD's) microcode did check. Anyways... for those keeping score at home, this is a privilege escalation bug... so it's only really useful in concert with other bugs ... but still pretty huge. Some estimate that between 5% and 30% performance degradation may be unavoidable. Some say it's worse or can't be fully fixed. Certainly, the sunk cost of current CPUs is a huge issue for server farm vendors like Amazon and/or google. On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler wrote: > Has any impact assessment been made as to FreeBSD's exposure or > mitigation strategies? > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > Windows redesign - The Register > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Jan 3 00:29:32 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D431E82FE5 for ; Wed, 3 Jan 2018 00:29:32 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FAD97AC23 for ; Wed, 3 Jan 2018 00:29:32 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WWrNezOYrS7BpWWrOeNfQb; Tue, 02 Jan 2018 17:24:47 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=JqEG_dyiAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=zxA2vyXaAAAA:8 a=DjmawdlsAAAA:8 a=6pCwMFOjS23r3FQTQlgA:9 a=auw6umvNwWJygQJf:21 a=8YSTmlPk9en_XcJY:21 a=CjuIK1q_8ugA:10 a=VNsLjGsGOZnTcv74ccgA:9 a=y6OPyGDXYSBE_OHj:21 a=_63tR6kpCF8vg-MS:21 a=8qy8v9n4PZQ8CTHH:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=nK2txNHJmq7TfjpuLlwI:22 a=9WNRskb1zeeanTosM84Z:22 Received: from [25.172.217.252] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 2F9292E8; Tue, 2 Jan 2018 16:24:45 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel CPU design flaw - FreeBSD affected? Date: Tue, 2 Jan 2018 16:24:55 -0800 To: Zaphod Beeblebrox , Michael Butler CC: FreeBSD Current Message-Id: <20180103002445.2F9292E8@spqr.komquats.com> X-CMAE-Envelope: MS4wfCYWspq6I6hkkihQr6jp9lO1c/ZzGulWF0+LvrHo7CYDGnYj+/2sBoyo9fLWBgPHcU+mOxhkXC7RAcW/BBpZtFr1slDQPjlLchHTKTual22szFcpFuk2 ofLkukAjT3V+17Hn2CHf2rHXQHqznnmhnadupFdob6KW/10Tasen6osaKJTT8PGCt48h5umfyngA4kJI8QsxxlIW9WcWZUR+IBR7Tcj4Wgsn8yNxLyU2FW5i g/bDD3q0+TTsZ9acOwWqCac5njibaJiP9h6z8iqx798= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:29:32 -0000 https://mobile.twitter.com/grsecurity/status/948170302286172160?p=3Dv --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Zaphod Beeblebrox Sent: 02/01/2018 15:50 To: Michael Butler Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? >From the information that was leaked by AMD claiming that their processors didn't have the flaws, it would seem any OS in which the kernel occupies the same address space as the userland would be vulnerable. The AMD post implied that Intel's speculative execution of code did not check the validity of the operands before speculatively executing the code. I suppose the implication is that the security check "catches up" with the speculative execution at some point ... and that their (AMD's) microcode did check. Anyways... for those keeping score at home, this is a privilege escalation bug... so it's only really useful in concert with other bugs ... but still pretty huge. Some estimate that between 5% and 30% performance degradation may be unavoidable. Some say it's worse or can't be fully fixed. Certainly, the sunk cost of current CPUs is a huge issue for server farm vendors like Amazon and/or google. On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler wrote: > Has any impact assessment been made as to FreeBSD's exposure or > mitigation strategies? > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > Windows redesign - The Register > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Wed Jan 3 00:56:28 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5478E874C7 for ; Wed, 3 Jan 2018 00:56:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5E27BA12 for ; Wed, 3 Jan 2018 00:56:28 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WXLxeqzakYy1iWXLyeNuXc; Tue, 02 Jan 2018 17:56:22 -0700 X-Authority-Analysis: v=2.2 cv=f8g4PK6M c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=BWvPGDcYAAAA:8 a=JqEG_dyiAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=zxA2vyXaAAAA:8 a=DjmawdlsAAAA:8 a=VwQbUJbxAAAA:8 a=HoJSghi9AAAA:8 a=zI7Yf533FpMDvwFUVt8A:9 a=fL1G9Pg1z1vS0I4W:21 a=ZHVkXNEHumvy1K2O:21 a=QEXdDO2ut3YA:10 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=nK2txNHJmq7TfjpuLlwI:22 a=9WNRskb1zeeanTosM84Z:22 a=AjGcO6oz07-iQ99wixmX:22 a=LeoNfjWMn6diZIv87PBK:22 Received: from [10.168.3.109] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id A356F31F; Tue, 2 Jan 2018 16:56:20 -0800 (PST) Date: Tue, 02 Jan 2018 16:56:16 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20180103002445.2F9292E8@spqr.komquats.com> References: <20180103002445.2F9292E8@spqr.komquats.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: RE: Intel CPU design flaw - FreeBSD affected? To: freebsd-current@freebsd.org, Zaphod Beeblebrox , Michael Butler CC: FreeBSD Current From: Cy Schubert Message-ID: <3720C563-77D8-4B9C-BFA7-082B91575506@cschubert.com> X-CMAE-Envelope: MS4wfE+PehQcwerC07VeY0lS3B5zGZF+3M6TKrsU70CazhwgEF9s92wfB/MTB6vjA8AvseQhaG2lEmGv8RrJU1j0bN7NApqRzcv0KoN0qL/uXXc+aLuvuljI +pcyKGg8SjY7SN7nb9+BqvdmVgGC5xd+TG/5ppClXSdzL4AxMkxiJ9vt3sBtigBOBKBa+Su22iyw5ZOsderOXaOLspNr9A+NOhaidUCVnu2blU+ZszGyzIN2 Z1guQUEp6tBlDV2exls03bZJLVKbs8Hfw/zESBGDS00= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:56:28 -0000 On January 2, 2018 4:24:55 PM PST, Cy Schubert wrote: >https://mobile=2Etwitter=2Ecom/grsecurity/status/948170302286172160?p=3Dv > >--- >Sent using a tiny phone keyboard=2E >Apologies for any typos and autocorrect=2E >Also, this old phone only supports top post=2E Apologies=2E > >Cy Schubert > or >The need of the many outweighs the greed of the few=2E >--- > >-----Original Message----- >From: Zaphod Beeblebrox >Sent: 02/01/2018 15:50 >To: Michael Butler >Cc: FreeBSD Current >Subject: Re: Intel CPU design flaw - FreeBSD affected? > >>From the information that was leaked by AMD claiming that their >processors >didn't have the flaws, it would seem any OS in which the kernel >occupies >the same address space as the userland would be vulnerable=2E The AMD >post >implied that Intel's speculative execution of code did not check the >validity of the operands before speculatively executing the code=2E I >suppose the implication is that the security check "catches up" with >the >speculative execution at some point =2E=2E=2E and that their (AMD's) >microcode >did check=2E > >Anyways=2E=2E=2E for those keeping score at home, this is a privilege >escalation >bug=2E=2E=2E so it's only really useful in concert with other bugs =2E=2E= =2E but >still >pretty huge=2E > >Some estimate that between 5% and 30% performance degradation may be >unavoidable=2E Some say it's worse or can't be fully fixed=2E > >Certainly, the sunk cost of current CPUs is a huge issue for server >farm >vendors like Amazon and/or google=2E > >On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler > >wrote: > >> Has any impact assessment been made as to FreeBSD's exposure or >> mitigation strategies? >> >> 'Kernel memory leaking' Intel processor design flaw forces Linux, >> Windows redesign - The Register >> >> https://www=2Etheregister=2Eco=2Euk/2018/01/02/intel_cpu_design_flaw/ >> >> >_______________________________________________ >freebsd-current@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd=2Eorg" > >_______________________________________________ >freebsd-current@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd=2Eorg" No need for invpcid, https://patchwork=2Ekernel=2Eorg/patch/10081791/=2E --- Cy Schubert or -- small keyboard in use, apologies for typos and autocorrect -- From owner-freebsd-current@freebsd.org Wed Jan 3 00:56:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A51CBE875FF for ; Wed, 3 Jan 2018 00:56:51 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FB287BC34 for ; Wed, 3 Jan 2018 00:56:51 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject; s=201508; t=1514941009; bh=cNqblEln eyRGwryzKjElZoH9+efPFkm5RkANx7FB6IE=; b=SO5lbS/ZVf73MUhvg8cnf5be 98dCk8opZxVa0+WjsMVdGl0xJdKxqkure62GRpzvjKHMKtuaYieP+QamyC8FBhKr ytD2HgGiIWZOz/H4MiT7fU4GW/DYpe+csOoCUloSFqvNjdTfSrN3evDh67J1T9TT eJbtxMqkAjET9GaPL6Q= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id B1CC636E7A; Tue, 2 Jan 2018 19:56:49 -0500 (EST) Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Cy Schubert , Warner Losh Cc: FreeBSD Current References: <20180103001949.6AF4F2C9@spqr.komquats.com> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> Date: Tue, 2 Jan 2018 19:56:48 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180103001949.6AF4F2C9@spqr.komquats.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:56:51 -0000 On 01/02/18 19:20, Cy Schubert wrote: > This Linux commit gives us a hint. > > https://lkml.org/lkml/2017/12//27/2 Sadly, the articles I've read to date make no mention of which Intel silicon revs are vulnerable. However, the use of the PCID feature, which is only available on more recent CPUs, does seem to afford a slightly lesser performance hit when completely splitting the kernel and user address space mappings :-( imb From owner-freebsd-current@freebsd.org Wed Jan 3 01:12:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 913C4E8A356 for ; Wed, 3 Jan 2018 01:12:01 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67E9D7C64F for ; Wed, 3 Jan 2018 01:12:01 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WXb4ezcPTS7BpWXb6eNok1; Tue, 02 Jan 2018 18:12:00 -0700 X-Authority-Analysis: v=2.2 cv=NKylwwyg c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=IkcTkHD0fZMA:10 a=RgaUWeydRksA:10 a=zxA2vyXaAAAA:8 a=D19gQVrFAAAA:8 a=HoJSghi9AAAA:8 a=6I5d2MoRAAAA:8 a=1GLJFC1j3x44-mMT14YA:9 a=QEXdDO2ut3YA:10 a=nK2txNHJmq7TfjpuLlwI:22 a=W4TVW4IDbPiebHqcZpNg:22 a=LeoNfjWMn6diZIv87PBK:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [10.168.3.109] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 81E25371; Tue, 2 Jan 2018 17:11:58 -0800 (PST) Date: Tue, 02 Jan 2018 17:11:54 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> References: <20180103001949.6AF4F2C9@spqr.komquats.com> <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Michael Butler , Cy Schubert , Warner Losh CC: FreeBSD Current From: Cy Schubert Message-ID: <227070B7-561C-420E-BE0B-F75DD3D4D6EE@cschubert.com> X-CMAE-Envelope: MS4wfEaww4TNgu/cO1yMy1VRkodCUzpP1e9xM9re0vmoLODXtSuZDtvXISmzgNjppPf38KcUXvN658F14biebGVs5rgwRx3/UUgwiSjQOhzNqnkaDIRaIn5W U6K6Pejb0d2nR7AzZOS0blb5BFxQsnXFrodxgfx8jwRL9yvj0+5oXVexqz7qcghMvJJXhKEZApjxxpRfolav6vpSfqSqXMWolaw3gOk/STgYt4ppp4x/+aFd LHQfciRvMVRQa9i8mKQ/g2nwle51BqR01ubZBcc102U= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 01:12:01 -0000 On January 2, 2018 4:56:48 PM PST, Michael Butler wrote: >On 01/02/18 19:20, Cy Schubert wrote: >> This Linux commit gives us a hint=2E >>=20 >> https://lkml=2Eorg/lkml/2017/12//27/2 > >Sadly, the articles I've read to date make no mention of which Intel >silicon revs are vulnerable=2E However, the use of the PCID feature, >which >is only available on more recent CPUs, does seem to afford a slightly >lesser performance hit when completely splitting the kernel and user >address space mappings :-( > > imb Yes=2E You can see if your cpu supports pcid using cpuinfo from ports=2E Then loo= k at input line 0x07 in the hexdump=2E Bit 0x0a of rbx will indicate if in= vpcid is available=2E We simply need to manipulate a copy of cr3 and reload= it=2E My amd gear in my basement isn't affected but my laptop is=2E It supports = pcid but not invpcid=2E There will be a performance hit=2E Looking at the Linux patch, looks like = the workaround is optional=2E I would suspect not through a sysctl, that wo= uld be silly=2E --- Cy Schubert or -- small keyboard in use, apologies for typos and autocorrect -- From owner-freebsd-current@freebsd.org Wed Jan 3 05:39:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EBB6EADAB2 for ; Wed, 3 Jan 2018 05:39:59 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 23E6764C9D for ; Wed, 3 Jan 2018 05:39:59 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eWbmP-0004d9-8J; Wed, 03 Jan 2018 06:39:57 +0100 Date: Wed, 3 Jan 2018 06:39:57 +0100 From: Kurt Jaeger To: Cy Schubert Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? Message-ID: <20180103053957.GP2827@home.opsec.eu> References: <20180103001949.6AF4F2C9@spqr.komquats.com> <5787e63c-9a88-c807-c132-572e8454a4d0@protected-networks.net> <227070B7-561C-420E-BE0B-F75DD3D4D6EE@cschubert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <227070B7-561C-420E-BE0B-F75DD3D4D6EE@cschubert.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 05:39:59 -0000 Hi! > You can see if your cpu supports pcid using cpuinfo from ports. portfind cpuinfo finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo command ? -- pi@opsec.eu +49 171 3101372 2 years to go ! From owner-freebsd-current@freebsd.org Wed Jan 3 06:05:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6C8FEAEB63 for ; Wed, 3 Jan 2018 06:05:25 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ABD9B65B73 for ; Wed, 3 Jan 2018 06:05:25 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WcAueIRfBb3YIWcAveZf4w; Tue, 02 Jan 2018 23:05:19 -0700 X-Authority-Analysis: v=2.2 cv=J/va1EvS c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=JqEG_dyiAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=adqX0pXGAAAA:8 a=VoFzOySMKdiBq0rub64A:9 a=lhTMTo2zwdGskEip:21 a=q3uxMnCK58BAh97c:21 a=CjuIK1q_8ugA:10 a=fAouFcOKkmgthFq3ck8A:9 a=nytemtLxZ2muz5Xa:21 a=6IBSgpoiGa7eaOuj:21 a=MMMfobqlGp7YcYc0:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=0l7XRIR7vdP6TgInZwrD:22 Received: from [25.172.217.252] (unknown [24.114.27.5]) by spqr.komquats.com (Postfix) with ESMTPSA id 407CC1C8; Tue, 2 Jan 2018 22:05:16 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel CPU design flaw - FreeBSD affected? Date: Tue, 2 Jan 2018 22:05:28 -0800 To: Kurt Jaeger CC: FreeBSD Current Message-Id: <20180103060516.407CC1C8@spqr.komquats.com> X-CMAE-Envelope: MS4wfEApJHjwGyzEtomnUf31SRvSgQnDN8rNg6p109SUuhQxpyezg+/N3k+E5v5ltIPkcp6lqcLO6zm1voelSMYyd5uGzd8VRA13uu1T57Sr0ovSpVAVykfU DuPFEIVz01wMhYejMx/sezBzAUtOBgUI5V+oZ3BH0L0M4MaRKk6zdNIegu4b1hK8d/p2+TbrwQ+Qfw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 06:05:25 -0000 More food for thought. https://mobile.twitter.com/pwnallthethings/status/947978927284383744 --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Kurt Jaeger Sent: 02/01/2018 21:41 To: Cy Schubert Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? Hi! > You can see if your cpu supports pcid using cpuinfo from ports. portfind cpuinfo finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo command ? --=20 pi@opsec.eu +49 171 3101372 2 years to g= o ! From owner-freebsd-current@freebsd.org Wed Jan 3 06:05:25 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6639EAEB62 for ; Wed, 3 Jan 2018 06:05:25 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ABDE865B74 for ; Wed, 3 Jan 2018 06:05:25 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id WcAueIRfCb3YIWcAweZf4y; Tue, 02 Jan 2018 23:05:19 -0700 X-Authority-Analysis: v=2.2 cv=J/va1EvS c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=RgaUWeydRksA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=adqX0pXGAAAA:8 a=VoFzOySMKdiBq0rub64A:9 a=b5NKUVClZKskcM8I:21 a=sjQDjPxzyfQ2nWA5:21 a=CjuIK1q_8ugA:10 a=fAouFcOKkmgthFq3ck8A:9 a=5YBYamX1noHTuYor:21 a=Ff0qx1Xp12TPAcau:21 a=e1fQtxgZ-4rG_Hz7:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=0l7XRIR7vdP6TgInZwrD:22 Received: from [25.172.217.252] (unknown [24.114.27.5]) by spqr.komquats.com (Postfix) with ESMTPSA id D522D1C7; Tue, 2 Jan 2018 22:05:15 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Intel CPU design flaw - FreeBSD affected? Date: Tue, 2 Jan 2018 22:05:27 -0800 To: Kurt Jaeger CC: FreeBSD Current Message-Id: <20180103060515.D522D1C7@spqr.komquats.com> X-CMAE-Envelope: MS4wfEApJHjwGyzEtomnUf31SRvSgQnDN8rNg6p109SUuhQxpyezg+/N3k+E5v5ltIPkcp6lqcLO6zm1voelSMYyd5uGzd8VRA13uu1T57Sr0ovSpVAVykfU DuPFEIVz01wMhYejMx/sezBzAUtOBgUI5V+oZ3BH0L0M4MaRKk6zdNIegu4b1hK8d/p2+TbrwQ+Qfw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 06:05:25 -0000 Sorry, cpuid. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Kurt Jaeger Sent: 02/01/2018 21:41 To: Cy Schubert Cc: FreeBSD Current Subject: Re: Intel CPU design flaw - FreeBSD affected? Hi! > You can see if your cpu supports pcid using cpuinfo from ports. portfind cpuinfo finds sysutils/p5-Linux-Cpuinfo, but this does not provide a cpuinfo command ? --=20 pi@opsec.eu +49 171 3101372 2 years to g= o ! From owner-freebsd-current@freebsd.org Wed Jan 3 09:41:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D5FAEB66F4 for ; Wed, 3 Jan 2018 09:41:42 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 387F36C0DC; Wed, 3 Jan 2018 09:41:42 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-pg0-x233.google.com with SMTP id i5so503396pgq.11; Wed, 03 Jan 2018 01:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aegDIOmqRLSKtApc268aSp5rycucmG3hwrFMBY3gqe8=; b=D33x/gHy9SJvHdFwX7pC070XSJ0ahg7agtvtyEfS2K2d56sUGU62JrEx0tdQLE/7x8 eYedFhYsvyYQMwZx4l3ZE3HdY+nYlhv0lNrXWO3z7ZoDf8mGro/ZeiIDZbqWbQdAYtAD 2bUhDR/bgWxWSZY0vfwu9m8vvgeI9BFqCjTnTa+JWiaXOReaCIGwEQRcYIITFlloFPQ7 g5j/G0KOGd61hMDgfRM0LO8gn8ULMHgSbp3VsBIY83hqkfAEy9z6QIoNVrqrdUTFtEV1 e0UaIiAszTAQ3C3dRixXK7HLcoTw3GEuODAnwmrF433BWaG7mCTmwwYS1jV/MwiWED86 8GdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aegDIOmqRLSKtApc268aSp5rycucmG3hwrFMBY3gqe8=; b=SvwbGIHJhOAOqdmSSaJ5Nc7Zn4izOdztlMgfkn0PxFkEd5iyvXvFIPYZZVz4QC+sRG dYhpAx65xj0mlyD8+0qd81XUo6wHknv7eOBjLZuh3GSlmkWkimDFIKIAchCwUOi/qKpN CLvBfrUn0wi1F+i7a04vo8x3XHWDy/WTiyTZETWHexZLav0OX38EsG+YezHq1DxKhVOs +bwv2HC7Fcnh4RiteEN+UGthl+VIQESKp2jrSYx3chZEXJmXJK+yVgEC/HmoZCRQWyh9 O9tAtq5YKFObyx8ogF+1afCgo8bGKlnNxqqKKSD78czyMNyVcwVLsbhBtggwuA7TRQir ucFw== X-Gm-Message-State: AKGB3mIZAJUBQ1RKW/qf+ZDWHuPRrCo1ZNIlmg0nNj7CK00AsF9SzCrT Uv6SvSPKfq2ON0q8ZqLj3wenYq/ARN9tBcGuItZE/w== X-Google-Smtp-Source: ACJfBovEziYKRUUV9me6BO2I6A0roMh1G3PQYBXYqqWve3bu2JTGcVnxgeQqamLihWtQM25bRyG+IKeaMb/rWsf1H70= X-Received: by 10.98.19.202 with SMTP id 71mr865759pft.181.1514972501666; Wed, 03 Jan 2018 01:41:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.138.130 with HTTP; Wed, 3 Jan 2018 01:41:41 -0800 (PST) In-Reply-To: References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <1514823989.12000.30.camel@freebsd.org> From: Maurizio Vairani Date: Wed, 3 Jan 2018 10:41:41 +0100 Message-ID: Subject: Re: Programmatically cache line To: blubee blubeeme Cc: Ian Lepore , Konstantin Belousov , David Chisnall , Adrian Chadd , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 09:41:42 -0000 2018-01-02 2:27 GMT+01:00 blubee blubeeme : > On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore wrote: > > > On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote: > > > On Mon, Jan 01, 2018 at 06:52:37AM +0000, David Chisnall wrote: > > > > > > > > On 1 Jan 2018, at 05:09, Adrian Chadd > wrote: > > > > > > > > > > > > > > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: > > > > > > > > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: > > > > > > > > > > > > > > Is there some way to programmatically get the CPU cache line > > sizes on > > > > > > > FreeBSD? > > > > > > There are, all of them are MD. > > > > > > > > > > > > On x86, the CPUID instruction leaf 0x1 returns the information in > > > > > > %ebx register. > > > > > Hm, weird. Why don't we extend sysctl to include this info? > > > For the same reason we do not provide a sysctl to add two integers. > > > > > > > > > > > > > > > It would be nice to expose this kind of information via VDSO or > > similar. There are a lot of similar bits of info that people want to use > > for ifunc and, SVE is going to have a bunch of similar requirements. > > > > > > > Is VDSO a new trendy word ? > > > > > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which > > > are essentially cpu_features / cpu_features2 / cpu_stdext_features / > > > cpu_stdext_features2. I suspect that only FreeBSD/x86 arches have the > > > ifunc support, in rtld and coming shortly in kernel. > > > > > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3) > > > interface exported from libc. > > > > > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is > > > considered a low priority because there is no ready to use toolchain > > > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd > > > ld externally. > > > > Linux exports this info using getauxval(). I think we should support > > getauxval() and as many of the AT_* values that linux defines as makes > > sense for us to do. > > > > I think it was a mistake to give our version of the function a > > different name and different semantics, but this is something that > > affects mainly ports, and I don't yet have enough info to make the case > > that being linux-compatible will ease porting rather than complicate it > > (in some cases, patches will be needed either way). > > > > -- Ian > > > FreeBSD implements hardware specific atomic instructions [man atomic] or > look at: #include > > but implementing something that returns size of cache lines is somehow out > of the question? > > If you're working with atomic data structures and want to ensure there's no > false sharing the > simplest method I know is to put some padding that's sizeof(cache_line) - > sizeof(data_members) > so that you can try to get them to live on different cache line. > > Do we have to go in and write inline assembly to grab the size of the cache > line or wouldn't it > be simpler to have atomic.h return this info? > > You can use CPUCTL(4). From owner-freebsd-current@freebsd.org Wed Jan 3 10:31:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07DD5EB8671 for ; Wed, 3 Jan 2018 10:31:56 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5A5E6DEF9 for ; Wed, 3 Jan 2018 10:31:55 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id u62so1262618ita.2 for ; Wed, 03 Jan 2018 02:31:55 -0800 (PST) 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=12WTDoLFNnTZa4fZXHGudsHjHSEE7inGJVJIchrXXqk=; b=P/nlbBEHUpDiOrBms9FX9K/HUU2z8iC73+UmyPeDxHS6fPPBo/FvuYzUK+UIjrxpta pkxSfMIb8MOrwSfLlF/nApBmHPev9JujmJKewgsjJCwq5GnMIzUY0V1yBoHum+L8ByK6 geAP4sm3GUzgzAHmlQ2RLrIVfPBozVw3JB9csiTHJHUCnadhCXyRTews888r03V6WDbY dYUiel7RyCJv1JTzm2aGIgr+TXBTu/mkOrKEGssQGJxuV9AirRlCxvI9ozAmfgobf32E VezBRvOMumIoe5XKVZWE3V/zsEehk+KUVuhG3hCBqcYI7exde8IS44ujb1Eg0k85zgFH nx8g== 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=12WTDoLFNnTZa4fZXHGudsHjHSEE7inGJVJIchrXXqk=; b=VvijqDFSIdpeOBXgt/0T2RdP2j622fuHXfcrkMPUKeY3xTsE8m+LHkOUr4xFabWxy1 K+m+RifgD51GcUMyiYfH0Dbk6njThyva38WcZt+ZNKgjzH1eFbSfx0bCRZTGy1sTn8YH 3noHURc7slc5bARKvzxdfzTBVXexjF9hIEGwGrMJtVfyKK2DqUOdrVZneGeQlIReZNZL G5GP8hSdBg/D5nCcrG72TvkmJxjo2NeQ5jdX7mGdkYPqf0dtYEZetXl04svVbjOSitHY YoWcsXBYqjjRsOrD55qZmR/X4rpdKDVr6zSupOFrhT/Vsu3Af6GpeVUXdFIPrFygUjJl B54w== X-Gm-Message-State: AKGB3mK7zuPmrVEnpGVJXtQw4KkOAcvVuQ2yV+Rxc4AlO/3nQvHx9dGU EyE0cQ/kGzL2WK8sTk9aao4UQXP5zRgWT5msrvfchw== X-Google-Smtp-Source: ACJfBov1DHMsIZo9UxJDUVPMed/kG65SBSGLO30WZzA51lJgFpe00TCvNQRpjbmoRiHrkSbrdVKv+hsGBwu3tzfrS0c= X-Received: by 10.36.167.77 with SMTP id s13mr1232609iti.51.1514975514999; Wed, 03 Jan 2018 02:31:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Wed, 3 Jan 2018 02:31:54 -0800 (PST) From: blubee blubeeme Date: Wed, 3 Jan 2018 18:31:54 +0800 Message-ID: Subject: USB stack To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 10:31:56 -0000 Does FreeBSD current USB stack support usb >= 2.0 devices? Testing out the USB devices support I get about 7.2-7.8 megabytes per second which seems odd. From owner-freebsd-current@freebsd.org Wed Jan 3 10:56:27 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53A6DEB92E6 for ; Wed, 3 Jan 2018 10:56:27 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD5D6E9B4 for ; Wed, 3 Jan 2018 10:56:27 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x236.google.com with SMTP id c16so1316564itc.5 for ; Wed, 03 Jan 2018 02:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6S6fqGOTcEOywWO7tdcZxJeDUlBYWYCu2gBaBWBYEu0=; b=ZS+TqiPfAeBN1ABDYbd/WR+OFKxLojkQSwg3mfiq54pxYSKLsQqrkyb40cK5C9XWwz IqkEP5bFenbF6j6IrvBhIPcWHYiHC9/kRdH4huTefZv+kTcj3B3G5bPsHnBlTekfSn1d sgxkxH6fnS9Zyx3LYwSwgpKt9VemK5peKEY+BJkdyxQwWcl6GxB78c2tdyG1sWHCLwMO 9jFPFC517AYmJaCyqNZkkgztp5wujsK9BKaTdsz/N9LKGfLcjQdetMt9tFIVtyNqdskV zpQc0nMvH7Ara13rfHahrWvncDrfYIEe2eQplvrB5q2cWH9BoVuAWGs9uh2wc8+8bhPM Jjmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6S6fqGOTcEOywWO7tdcZxJeDUlBYWYCu2gBaBWBYEu0=; b=Kks2tNIe6UCCzAxYfqRTipQ1IG2BA/s8p2kndADZP4Veowzu+yZH2BzbCa9sE4fGF9 jtaNt2sJuCTBeUWXjmIvvAbrP8MuYpv0v3wH3lGIwjNDowjlGN9Gf3Wd+5OOv6E0Is1S 9uFdZSqwsqTrYMoxU40nhu4582ZmFzhQnFhCKgLYBwaMvcHX44vO3lFQI+iUxWhdzon+ DnIo0zOMsqaS3F5AKgHAaGKw+eKV9bA2iA4EKR9ppzuJxWtdsUFboCTxIza9rGW5ngW9 L+fqLKi1gOh6pZPFiKNrm6tBoFjTxwAPQJBslvGMKZDrOj2Gt1Ibb3FECvoZw3lLzVxV ULTg== X-Gm-Message-State: AKGB3mIdBA0ky9T8UTzFFEhCKbGZqpIvcuiJ9BXPnY2vWn6DM1pLa6iG O/Rx8CbOCu9KZ5zDRN6TU92NlR3TUOoyarFXrAxPhokS X-Google-Smtp-Source: ACJfBou1vFubC/3ea2zHxycswgrawztctGPr3jf/wy6o1RUIrXU95WjghoBKT2omlEAhepuG2EoLjmv4jI8jgOGizSo= X-Received: by 10.36.151.198 with SMTP id k189mr1371950ite.100.1514976986411; Wed, 03 Jan 2018 02:56:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Wed, 3 Jan 2018 02:56:25 -0800 (PST) In-Reply-To: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> From: blubee blubeeme Date: Wed, 3 Jan 2018 18:56:25 +0800 Message-ID: Subject: Re: USB stack To: "O'Connor, Daniel" Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 10:56:27 -0000 On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel wrote: > > > > On 3 Jan 2018, at 11:31, blubee blubeeme wrote: > > Does FreeBSD current USB stack support usb >= 2.0 devices? > > Absolutely. > > > Testing out the USB devices support I get about 7.2-7.8 megabytes per > > second which seems odd. > > What sort of test? What sort of device? What sort of port? > > What is the output of dmesg and usbconfig? > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > I transferred about 30GB of audio from laptop to Samsung usb class 10 usb device connected to LG v30. current usbconfig shows this: ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) From owner-freebsd-current@freebsd.org Wed Jan 3 10:59:03 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7FBFEB94C1 for ; Wed, 3 Jan 2018 10:59:03 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3065F6EB40 for ; Wed, 3 Jan 2018 10:59:02 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-169-232-53.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.169.232.53]) by ipmail06.adl2.internode.on.net with ESMTP; 03 Jan 2018 21:23:52 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w03Ard1c060383 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 3 Jan 2018 21:23:41 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w03AfRNA053734 for ; Wed, 3 Jan 2018 21:11:27 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [192.168.0.14] (tru75-16-78-196-125-127.fbx.proxad.net [78.196.125.127]) by 124-169-232-53.dyn.iinet.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w03AfGLJ053731; Wed, 03 Jan 2018 21:11:27 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: USB stack From: "O'Connor, Daniel" In-Reply-To: Date: Wed, 3 Jan 2018 11:41:15 +0100 Cc: FreeBSD current Content-Transfer-Encoding: 7bit Message-Id: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> References: To: blubee blubeeme X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Score: 0.4 () No, score=0.4 required=5.0 tests=HELO_MISC_IP, RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 10:59:03 -0000 > On 3 Jan 2018, at 11:31, blubee blubeeme wrote: > Does FreeBSD current USB stack support usb >= 2.0 devices? Absolutely. > Testing out the USB devices support I get about 7.2-7.8 megabytes per > second which seems odd. What sort of test? What sort of device? What sort of port? What is the output of dmesg and usbconfig? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Wed Jan 3 19:58:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80031EAC930 for ; Wed, 3 Jan 2018 19:58:56 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [150.101.137.143]) by mx1.freebsd.org (Postfix) with ESMTP id 075FB3FB0 for ; Wed, 3 Jan 2018 19:58:55 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-169-232-53.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.169.232.53]) by ipmail03.adl6.internode.on.net with ESMTP; 04 Jan 2018 06:23:43 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w03JrbX3023698 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Jan 2018 06:23:38 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w03JTNW1005386 for ; Thu, 4 Jan 2018 05:59:23 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [192.168.0.14] (tru75-16-78-196-125-127.fbx.proxad.net [78.196.125.127]) by 124-169-232-53.dyn.iinet.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w03JTApc005377; Thu, 04 Jan 2018 05:59:23 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: USB stack From: "O'Connor, Daniel" In-Reply-To: Date: Wed, 3 Jan 2018 20:29:08 +0100 Cc: FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> To: blubee blubeeme X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Score: 0.4 () No, score=0.4 required=5.0 tests=HELO_MISC_IP, RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 19:58:56 -0000 > On 3 Jan 2018, at 11:56, blubee blubeeme wrote: > On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel = wrote: >=20 >=20 > > On 3 Jan 2018, at 11:31, blubee blubeeme = wrote: > > Does FreeBSD current USB stack support usb >=3D 2.0 devices? >=20 > Absolutely. >=20 > > Testing out the USB devices support I get about 7.2-7.8 megabytes = per > > second which seems odd. >=20 > What sort of test? What sort of device? What sort of port? >=20 > What is the output of dmesg and usbconfig? >=20 > I transferred about 30GB of audio from laptop to Samsung usb class 10 = usb device connected to LG v30. >=20 > current usbconfig shows this: > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER= (5.0Gbps) pwr=3DSAVE (0mA) > ugen0.3: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) > ugen0.2: at usbus0, cfg=3D0 md=3DHOST = spd=3DFULL (12Mbps) pwr=3DON (100mA) Ugh, your mail client has mangled things, oh well. You missed posting the output of dmesg.. What is an "LG v30"? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Wed Jan 3 21:37:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D3EDEB07C0 for ; Wed, 3 Jan 2018 21:37:53 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2D3679BD for ; Wed, 3 Jan 2018 21:37:53 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22e.google.com with SMTP id k80so1072991ywe.0 for ; Wed, 03 Jan 2018 13:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BSM2oWEEI18581/xZRqFgASO0Ujbc+FzaobHytLv/Bc=; b=u3X4HmS309RAjCst5CTVXWymKFMW3Bn5BHTA0vHI92dNOfYrgyeZmaOPtH2oHmUCYm hD5aGecGZT7/OXCw7I4Zb6wpNXwoJaxcHQIBDvrnUFiIiFKhRnY+mEYryRRa7br/UYlS izSOj3Cj/j7X9v11Mdd2BLEv2k6EiA4VjFgAP1ALu67TpftkfejUPHy0bJBsrudNCsnC RBZRGb2oR2gbcTHTRo1XP5BFdxrwXymRmq+ASiDgv8Dyy3PxwwwXK4MeDIs4XvbowPZj 7JZwxjrRvdUCOlovaG5qq/LoeIkoXuYO54juxN/d0R1N/zTisMLtUxHiLrcQMbrsCdL2 3F/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BSM2oWEEI18581/xZRqFgASO0Ujbc+FzaobHytLv/Bc=; b=gLauqw8sspcFIuuwN+mN95Ju+na8EcMKQMGjIqxio+Y4DUr5eaiCmTpW3zhyfRrNm1 2d/PS+YF2Vj1dfPLr7wd42Bd8fd0E/HBkmFvxQcz5b2KcK/WbCxPbzDG8GKpy8Gb4/qJ HnYJeYxuY6HkdETjFKBoOpj7f0p+TEXnmq3Yf0he12a/zLeNUbKg74MM9j/y6QXX4fEy l6zbe7bwSkJSPY5pEqSu06ahm/Qjt6nsfrD3RpIfrX+XNI+vUXj04zzXpuw+voK/UqFy mxw1fxbwjXXgrTOSOjdUjdL1G+aFALSYkML+fi+KMUW+ll7/QGMWzA385HzkzWRbxWQP VQpA== X-Gm-Message-State: AKGB3mJOWac8IVmFeHjMn014kQCsOg1Ivh4QBgbgFFePW0+i0OPEpGQf vbPadMWMeqHWZRS0TLiLP0oGKK8M1PlhfH4YUob6rw== X-Google-Smtp-Source: ACJfBouChMcygTdeoFOf1LQBCbfty7y9XTPQM/MeoyqnA6G/u9HO3cnC0Clo9pw5X8o8L2IbCwGtTH/zS+UvA80hM2Q= X-Received: by 10.129.200.14 with SMTP id n14mr2438719ywi.367.1515015472178; Wed, 03 Jan 2018 13:37:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.85.17 with HTTP; Wed, 3 Jan 2018 13:37:21 -0800 (PST) In-Reply-To: <20180101103655.GF1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> From: Ed Schouten Date: Wed, 3 Jan 2018 22:37:21 +0100 Message-ID: Subject: Re: Programmatically cache line To: Konstantin Belousov Cc: David Chisnall , Adrian Chadd , blubee blubeeme , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 21:37:53 -0000 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : >> >> On x86, the CPUID instruction leaf 0x1 returns the information in >> >> %ebx register. >> > >> > Hm, weird. Why don't we extend sysctl to include this info? > > For the same reason we do not provide a sysctl to add two integers. I strongly agree with Kostik on this one. Why add stuff to the kernel, if userspace is already capable of extracting this? Adding that stuff to sysctl has the downside that it will effectively introduce yet another FreeBSDism, whereas something generic already exists. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-current@freebsd.org Wed Jan 3 22:23:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15626EB2A71 for ; Wed, 3 Jan 2018 22:23:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 F32F269A53 for ; Wed, 3 Jan 2018 22:23:08 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from helicon.physics.ucla.edu (helicon.physics.ucla.edu [169.232.156.253]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w03MC1aq015857 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Jan 2018 14:12:01 -0800 Subject: Re: Programmatically cache line To: freebsd-current@freebsd.org References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> From: Nathan Whitehorn Message-ID: <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> Date: Wed, 3 Jan 2018 14:12:00 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYa2bLoqrZ8FeaCaolfaddV2aKU8xyWiNOmaPGl9PjKbfMyZ3jh1TbpNDPmm1cbj41jSYmgCcv7GZbBf+yJUkMFxrnaQHnXdMo= X-Sonic-ID: C;DrNnH9Pw5xGmNUdJEUQrEw== M;4CeoH9Pw5xGmNUdJEUQrEw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 22:23:09 -0000 On 01/03/18 13:37, Ed Schouten wrote: > 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : >>>>> On x86, the CPUID instruction leaf 0x1 returns the information in >>>>> %ebx register. >>>> Hm, weird. Why don't we extend sysctl to include this info? >> For the same reason we do not provide a sysctl to add two integers. > I strongly agree with Kostik on this one. Why add stuff to the kernel, > if userspace is already capable of extracting this? Adding that stuff > to sysctl has the downside that it will effectively introduce yet > another FreeBSDism, whereas something generic already exists. > Well, kind of. The userspace version is platform-dependent and not always available: for example, on PPC, you can't do this from userland and we provide a sysctl machdep.cacheline_size to userland. It would be nice to have an MI API. -Nathan From owner-freebsd-current@freebsd.org Thu Jan 4 00:51:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98C4EEB854F for ; Thu, 4 Jan 2018 00:51:42 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 611076EE45 for ; Thu, 4 Jan 2018 00:51:42 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-ot0-x22f.google.com with SMTP id q5so122412oth.2 for ; Wed, 03 Jan 2018 16:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8DJ+LXAv8Hc1c9PjRoDa1MJi7DXVOAcbze9tVt8oGRk=; b=Di1lTIfsw9s2vGl3KTxZJqhbQ6rpX0/Yck4MKc57x6xi5YS8on8XWiAo3vPDFpPFUW GWQOmnWS7Vg03fOJqV83TkYSb4RMGTkBKrbqfmmOd130G8sA43lZODP3lIoWHrOJ5pah 08hhDU6NSL0IH0qgbhBcAwIRoQbYOw7Vi9g67vYLFG2QrX4RSS4i1AN2BvNMpoKTePzQ tiSxzkDh0xTd76fQHfz9cbE2vgStYcbtE6UPeh9QL80MDn+TEqvTpEXRuhc5VMoos9NN 7Z3R1JGzQUeK46869OCYjhrZePFxQtojbW2ruNbX4yL/PlVJhE5RgRJXLpVUt3VPTDdS +NIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8DJ+LXAv8Hc1c9PjRoDa1MJi7DXVOAcbze9tVt8oGRk=; b=iNMoeB9zcfJpWmb/R1x6QXAz0cv5e8b/ifUaE0z5TjwXrVi/UtPUyMtnWLQ0CFmB8y 8J7mde7BEcl8sxyvpM2HsxEvqifBy1YI4sw9GElYaRs5ylPxuQzSO85BhWLqLxsr9VAI nLQcYDbIRaxNax5m4na9j48fHyaFjDLCzc+XmpY85yVtaA1K9iYBbsCQ0+VYGbu8mI8n Nr9YWFte1fxgPWKq++U/b/0uUYllDtB0AW1Yu6YhdSL+2sPNcmWL9ZOSN/fiLFY1yGsK mpb4O/HGhRiEI31wNv/MbJMtL99EOiDj8xZSvH7/q4lTs78d2QBkaUJck4dJQGqcpKT5 l4dg== X-Gm-Message-State: AKGB3mJoGU0ttMl+p9AvBAbwOGVMF0Rj/4/ljxMIzWJ7MsVhP2BBhjpM iQqzmwVisSeyfyJ2PnR/Y4hAmk+eWp7EEKI1ceK2w81L X-Google-Smtp-Source: ACJfBovBkZpLeg7+eUgbMI6OEhXE05Fxy5iyyTGz8ZBx5mjHjqtvk663BxZKXk7jL6K+vNTJ/Ny9kh6pNhe8xyks5uI= X-Received: by 10.157.37.55 with SMTP id k52mr2124291otb.80.1515027101578; Wed, 03 Jan 2018 16:51:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.22.183 with HTTP; Wed, 3 Jan 2018 16:51:40 -0800 (PST) X-Originating-IP: [71.70.173.127] Received: by 10.157.22.183 with HTTP; Wed, 3 Jan 2018 16:51:40 -0800 (PST) In-Reply-To: References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: Mark Heily Date: Wed, 3 Jan 2018 19:51:40 -0500 Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Warner Losh Cc: Michael Butler , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 00:51:42 -0000 On Jan 2, 2018 19:05, "Warner Losh" wrote: The register article says the specifics are under embargo still. That would make it hard for anybody working with Intel to comment publicly on the flaw and any mitigations that may be underway. It would be unwise to assume that all the details are out until the embargo lifts. Details of the flaws are now published at: https://meltdownattack.com Warner On Jan 2, 2018 4:13 PM, "Michael Butler" wrote= : > Has any impact assessment been made as to FreeBSD's exposure or > mitigation strategies? > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > Windows redesign - The Register > > Other OSes will need an update, performance hits loom A fundamental > design flaw in Intel's processor chips has forced a significant redesign > of the Linux and Windows kernels to defang the chip-level security bug.= =E2=80=A6 > Programmers are scrambling to overhaul the open-source Linux kernel's > virtual memory system. Meanwhile, Microsoft is expected to publicly > introduce necessary changes to its Windows operating system in this > month's Patch Tuesday ... > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > imb > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Jan 4 01:39:51 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24D9EEBBD25 for ; Thu, 4 Jan 2018 01:39:51 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC590713B1 for ; Thu, 4 Jan 2018 01:39:50 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id m11so161002iti.1 for ; Wed, 03 Jan 2018 17:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YgWTQY961clYZ+0IMwVbOEIaxWSZoll9kBETEAprkA0=; b=ANeQPRW/cNaUYOK/2rDdZUuFpdpVaCscwFsAeZ0ZtRX7dUJToniSstDpQDcLRPrpNc 4I5Umvo+l+VXEanMPSN0ea0rOnDSJV+zBsnkm2vHaWPl7B/MNYQOwbzs4yPlqlb9B3JL 6eL0dvQzICq3nWBjDOTxcKGSsGLjAaHtdVuxfAfx6w/Elo5b5dE9G+MLzpYv5M3N6OAG ZR1I+rK0RKSFGgoinxKH1dBo5LbmawJ7nHqICUDG7PnP0PN3qzZVE5zsfOhq4J3nbGwX jl16Hi9x4JbwnKG17IYpyWXYrVWGrIhgDejwVBk8Q3ZPAoBLM66hU0uIf+Zch2+C1Da/ upmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YgWTQY961clYZ+0IMwVbOEIaxWSZoll9kBETEAprkA0=; b=HE08dfgsnIl7K7ggInLQPVU8GOqUvAt2XzNirH4sOPj2cl0H/DlKMBbvEfmdRqd4Lz kri1f4wWJ7ptZtV7raEx643g4Ko31rZJx3gAOTBow3K+HM4cBT7lVLda9i2guFypTxi7 zL41msoPwGdDs+2RTK/OxUWVhw2Cfvao8jRIrsbk++9r6U9ZwS+qvpPWE+c6+EtTADqM Vp7qGnELb1cQo79ijeVe0SmzLCklcONc7tQ2TEaXLEy5dNlM1MH5bTwpWzMpaQzcaHSt 7Z29F2HmG6scQ0dxdEVngIOMk+18GBJ3WIDHyQo0IkavSwKi4wPpslNdSIh/URWux1te bWuQ== X-Gm-Message-State: AKGB3mKX/4lKnLWmh4HWB78XIKirscikLcHtgkCbnTERQ1Uas7Y13lFA c5hgiA3u5tPIR9iBTe1BrIkeMSbIWMrHk9LirVC0cw== X-Google-Smtp-Source: ACJfBouJH+SaEhmEWRw8PpT9Ww3WXMfsgyCciRnf34GzBf4Cz4JreqxLEe0oHIbjQlU/1KRn13dGk3+dzwWinrkvXsQ= X-Received: by 10.36.221.147 with SMTP id t141mr3959351itf.140.1515029990219; Wed, 03 Jan 2018 17:39:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Wed, 3 Jan 2018 17:39:49 -0800 (PST) In-Reply-To: References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: blubee blubeeme Date: Thu, 4 Jan 2018 09:39:49 +0800 Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Mark Heily Cc: Warner Losh , Michael Butler , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 01:39:51 -0000 On Thu, Jan 4, 2018 at 8:51 AM, Mark Heily wrote: > On Jan 2, 2018 19:05, "Warner Losh" wrote: > > The register article says the specifics are under embargo still. That wou= ld > make it hard for anybody working with Intel to comment publicly on the fl= aw > and any mitigations that may be underway. It would be unwise to assume th= at > all the details are out until the embargo lifts. > > > Details of the flaws are now published at: > > https://meltdownattack.com > > > Warner > > On Jan 2, 2018 4:13 PM, "Michael Butler" > wrote: > > > Has any impact assessment been made as to FreeBSD's exposure or > > mitigation strategies? > > > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > > Windows redesign - The Register > > > > Other OSes will need an update, performance hits loom A fundamental > > design flaw in Intel's processor chips has forced a significant redesig= n > > of the Linux and Windows kernels to defang the chip-level security bug.= =E2=80=A6 > > Programmers are scrambling to overhaul the open-source Linux kernel's > > virtual memory system. Meanwhile, Microsoft is expected to publicly > > introduce necessary changes to its Windows operating system in this > > month's Patch Tuesday ... > > > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > > > imb > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > This is insane... And to think a few months ago people were complaining that Ryzen processors and specifically Threadripper might be insecure in data centers, ha. This is a massive clusterfk From owner-freebsd-current@freebsd.org Thu Jan 4 05:09:31 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46CE9E8AA3F; Thu, 4 Jan 2018 05:09:31 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 ADA7E79E56; Thu, 4 Jan 2018 05:09:30 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-339ff700000004d1-c5-5a4db590d190 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AE.FC.01233.195BD4A5; Thu, 4 Jan 2018 00:03:14 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w04539wO021612; Thu, 4 Jan 2018 00:03:10 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w04535SA013744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jan 2018 00:03:08 -0500 Date: Wed, 3 Jan 2018 23:03:05 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Second Call for 2017Q4 quarterly status reports Message-ID: <20180104050305.GL50827@kduck.kaduk.org> References: <20171226002716.GG59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20171226002716.GG59505@kduck.kaduk.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsUixG6nrjtpq2+UQcNFFYs5bz4wWWzf/I/R gcljxqf5LAGMUVw2Kak5mWWpRfp2CVwZv/+uYinYK1ZxddtllgbGacJdjBwcEgImEu97KroY uTiEBBYzSezo2c7excgJ5GxglJh6IhoicYVJYteUTawgCRYBFYmebd/YQGw2ATWJ9SuuMYPY IgLyEvua3oM1MwPZv7Y2gdnCAhYS1x88YASxeYGWbW/4xAyxwERiyak1UHFBiZMzn7CAHMQs UCYx55UDhCktsfwfB0gFp4CpxKONe8G2igooS+ztO8Q+gVFgFpLmWQjNsxCaZ4GdoyVx499L JgxhbYllC18zQ9i2EuvWvWdZwMi+ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQT IzjkXVR2MHb3eB9iFOBgVOLhbbjhEyXEmlhWXJl7iFGSg0lJlDcn1TtKiC8pP6UyI7E4I76o NCe1+BCjCtCuRxtWX2CUYsnLz0tVEuF1ywJq5U1JrKxKLcqHKZPmYFES5/Uw0Y4SEkhPLEnN Tk0tSC2CyWpwcAi0XDx5kAlqiARvxhbfKCHBotT01Iq0zJwShFImDs5DjBIcPECL7EFqeIsL EnOLM9Mh8qcYdTmezXzdwCwENkhKnNcWpEgApCijNA9uDii1SWTvr3nFKA70rjCvM0gVDzAt wk16BbSECWjJn/OeIEtKEhFSUg2MYqvmrZv6L/2SXp3NtPP9MQu9d3bP5XThSm3d/nORpNbW 5ZkzvE0Nrn8yYd9udEdMNXTZxwnzbZ9lvNixvz/ZoNnjd7XZqpDQeF2LBHZ/CaGtH3IXBqso n8r3eL57EbPhAfHDLsrLTYU6rjPkZBkeXWtcsev0+c/ffz4XMX3h5hh//X/gsScrlFiKMxIN tZiLihMBhpYdc0gDAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 05:09:31 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Happy new year, and I hope that meltdown and spectre are not taking too much of everyone's time. That said, the submission deadline is still January 14th, so please do send in your status report entries to us! Thanks, Ben On Mon, Dec 25, 2017 at 06:27:16PM -0600, Benjamin Kaduk wrote: > Dear FreeBSD Community, >=20 > The deadline for the next FreeBSD Quarterly Status update is January 14, > 2018, for work done in October through December. >=20 > Status report submissions do not need to be very long. They may be > about anything happening in the FreeBSD project and community, and > provide a great way to inform FreeBSD users and developers about > work that is underway and completed. Submission of reports is not > restricted to committers; anyone doing anything interesting and > FreeBSD related can -- and should -- write one! >=20 > The preferred and easiest submission method is to use the XML > generator [1] with the results emailed to the status report team at > monthly@FreeBSD.org . (Do be sure, though, to save the form output > and not the form itself! In particular, the Google Chrome "save as" > function does not save the generated output for some reason.) There > is also an XML template [2] that can be filled out manually and > attached if preferred. For the expected content and style, please > study our guidelines on how to write a good status report [3]. You > can also review previous issues [4][5] for ideas on the style and > format. >=20 > We look forward to seeing your 2017Q4 reports! >=20 > Thanks, >=20 > Ben (on behalf of monthly@) >=20 > [1] https://www.FreeBSD.org/cgi/monthly.cgi > [2] https://www.FreeBSD.org/news/status/report-sample.xml > [3] https://www.FreeBSD.org/news/status/howto.html > [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html > [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html >=20 >=20 --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpNtYMACgkQKNmm82Tr dRIlmgweLJpJVe7eOt7L3M7R0C50IcufXsJy3NvVxymHExOgeh6Izxn6HWmaL2+H ByrJLZkp8k2jQpvSICyakoIA/PPlo6troZUBAzNJqDeN+VEH35TB8b64SdJFBRtr /rQ5c9pJNDL6/KfPWajPIYc80lPUyhIYZgQKuc7UkW4d/He0JBgAuOTOQP6drxsw 71P0qpnm8vzN8AH6jQWhwDT9yINPn2s0JSprVJTW7w5don7EtXuLLhtnZk/T2pWd 0o5pot0KqyeqU/5DFvciZHEvcK1M/BXSVvN4wfu+Hopibc6quHEwosTW45qA19WL fRGUbApiTlT8AxnuB0Z197Z4QVE9CBaMdj22jWLViez93snBvnEoHAAyioScHmyQ W4/c6bxzku2o3Ql9szOyH/rVlYjnBJUQGsbBQUyMzGSw+nejdwo6WQ7nXtza4BIl 8iYnszR02ThEwRylYLpc3fnN0S69gqGuhu1mIhE6Svlf4sPW1nY8yJABf97nQ5I/ YMcMmXiJ3X0gew== =flZ4 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@freebsd.org Thu Jan 4 08:10:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DC94EA633F for ; Thu, 4 Jan 2018 08:10:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E91727EDF0 for ; Thu, 4 Jan 2018 08:10:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [10.0.1.108] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B65767213BA4C; Thu, 4 Jan 2018 09:10:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> From: Michael Tuexen In-Reply-To: Date: Thu, 4 Jan 2018 09:10:37 +0100 Cc: "O. Hartmann" , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> To: Warner Losh X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 08:10:42 -0000 > On 31. Dec 2017, at 02:45, Warner Losh wrote: >=20 > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann = wrote: >=20 >> On most recent CURRENT I face the error shwon below on /tmp = filesystem >> (UFS2) residing >> on a Samsung 850 Pro SSD: >>=20 >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 !=3D >> bp: 0xd9fba319 >> handle_workitem_freefile: got error 5 while accessing filesystem >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >> !=3D bp: 0xd9fba319 >> handle_workitem_freefile: got error 5 while accessing filesystem >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >> !=3D bp: 0xd9fba319 >> handle_workitem_freefile: got error 5 while accessing filesystem >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >> !=3D bp: 0xd9fba319 >> handle_workitem_freefile: got error 5 while accessing filesystem >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >> !=3D bp: 0xd9fba319 >> handle_workitem_freefile: got error 5 while accessing filesystem >>=20 >> I've already formatted the /tmp filesystem, but obviously without any >> success. >>=20 >> Since I face such strange errors also on NanoBSD images dd'ed to SD = cards, >> I guess there >> is something fishy ... >=20 >=20 > It indicates a problem. We've seen these 'corruptions' on data in = motion at > work, but I hacked fsck to report checksum mismatches (it silently = corrects > them today) and we've not seen any mismatch when we unmount and fsck = the > filesystem. Not sure this helps: But we have seen this also after system panics when having soft update journaling enabled. Having soft update = journaling disabled, we do not observed this after several panics. Just to be clear: The panics are not related to this issue, but to other network development we do. You can check using tunefs -p devname if soft update journaling is = enabled or not. Best regards Michael >=20 > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Jan 4 08:23:52 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BC19EA6A0F for ; Thu, 4 Jan 2018 08:23:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BE0B7F75E for ; Thu, 4 Jan 2018 08:23:52 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id g130so1098858wme.0 for ; Thu, 04 Jan 2018 00:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=DhVg4X36L6VXSYEiOorGO2QVqdb0J29wQIJkWttteMk=; b=F7l3dEM25SEsM9R2fb5py32vrzqcSnXElN2kayvx272ouqbREAo/0bgJZjEt/OXy3r gGP7my1vtLAFBP8HSGwFBw+RtluYmqIXHLv7zMnaLsTo7t7jHjCF+Inyn6Z+ZFf3n0zP pjjhpxf8UhMHdCnKCtBJRhCOrK6IDdavfH/QjUl8U1Ysi04jt6ssjxaJ9/IQc5XiZK/2 s2ClnZ30ozRBCzaFt1N2t+9D21gfVSjEo1U+cqv5oIVT2NxDxKp1xFuJ//XShq8Bt0S2 GOBxNepFxrUALy/PMMCrBAV46YZC2rqd2RU2n0M2Thwou1Yg9THHxXfv+EEvHLwufF5T NepA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=DhVg4X36L6VXSYEiOorGO2QVqdb0J29wQIJkWttteMk=; b=rqDX+0wIr+6u/SDLvpHMufHII/t1bNs7URhTicCHJWkO6OPuh8fYX0Sx7gpkZzq3sx 3lSBKFGzvbtpKc7u5hi82GXJXF4BAX0Smwi+yOowJONqBys7nFKUciKJIfyw0M+6TGX4 7gcNOkW3D4I3lnTKC4mzKBQJgDNVLBN4T4NxQ1qAQwgA4hUZTyFuHz1M8C76LdpHpNQN 2DtAvCamqPuGrlNKjsIbi7hEeb+Ek+q4p7JlRcgVoMBEH5Rxh0ZZ4yqqvAOKx2fU6x7e oY3VAP2fhlJrHfapQhWvneAzS+aR1FTX3qY1ZhDwQX+kqdgCWfHvTSEFMQ04GM4ouxN2 H07w== X-Gm-Message-State: AKGB3mJag7X+XcNr0qjI9yNQcbjaTMwdmibBRgms5w0CiKfvfzKwyOK2 pisoJdAqtTdpB4hq4kEMunHrKQ== X-Google-Smtp-Source: ACJfBouQ4khQehvvBgPbUGCz1UlVB51+2dp2DxpOdei+HaaxCNJjoZpEW9WwBu/Gb5pMkkVI9gkTew== X-Received: by 10.28.73.196 with SMTP id w187mr3349133wma.17.1515054230749; Thu, 04 Jan 2018 00:23:50 -0800 (PST) Received: from ernst.home (p5B023419.dip0.t-ipconnect.de. [91.2.52.25]) by smtp.gmail.com with ESMTPSA id o98sm9622531wrb.40.2018.01.04.00.23.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Jan 2018 00:23:49 -0800 (PST) Date: Thu, 4 Jan 2018 09:23:49 +0100 From: Gary Jennejohn To: "O'Connor, Daniel" Cc: blubee blubeeme , FreeBSD current Subject: Re: USB stack Message-ID: <20180104092349.2821f9f9@ernst.home> In-Reply-To: <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 08:23:52 -0000 On Wed, 3 Jan 2018 20:29:08 +0100 "O'Connor, Daniel" wrote: > > On 3 Jan 2018, at 11:56, blubee blubeeme wrote: > > On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel wrote: > > > > > > > On 3 Jan 2018, at 11:31, blubee blubeeme wrote: > > > Does FreeBSD current USB stack support usb >= 2.0 devices? > > > > Absolutely. > > > > > Testing out the USB devices support I get about 7.2-7.8 megabytes per > > > second which seems odd. > > > > What sort of test? What sort of device? What sort of port? > > > > What is the output of dmesg and usbconfig? > > > > I transferred about 30GB of audio from laptop to Samsung usb class 10 usb device connected to LG v30. > > > > current usbconfig shows this: > > ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) > > ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) > > Ugh, your mail client has mangled things, oh well. > > You missed posting the output of dmesg.. > > What is an "LG v30"? > It's a smartphone from LG and only supports USB2 speed. The reported transfer rate is no big surprise. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Thu Jan 4 10:03:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EE11EA8BD1 for ; Thu, 4 Jan 2018 10:03:42 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F14212A00; Thu, 4 Jan 2018 10:03:41 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w04A3XQg070523 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Jan 2018 10:03:33 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Programmatically cache line From: David Chisnall In-Reply-To: <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> Date: Thu, 4 Jan 2018 10:03:32 +0000 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 10:03:42 -0000 On 3 Jan 2018, at 22:12, Nathan Whitehorn = wrote: >=20 > On 01/03/18 13:37, Ed Schouten wrote: >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : >>>>>> On x86, the CPUID instruction leaf 0x1 returns the information in >>>>>> %ebx register. >>>>> Hm, weird. Why don't we extend sysctl to include this info? >>> For the same reason we do not provide a sysctl to add two integers. >> I strongly agree with Kostik on this one. Why add stuff to the = kernel, >> if userspace is already capable of extracting this? Adding that stuff >> to sysctl has the downside that it will effectively introduce yet >> another FreeBSDism, whereas something generic already exists. >>=20 >=20 > Well, kind of. The userspace version is platform-dependent and not = always available: for example, on PPC, you can't do this from userland = and we provide a sysctl machdep.cacheline_size to userland. It would be = nice to have an MI API. On ARMv8, similarly, sometimes the kernel needs to advertise the wrong = size. A few big.LITTLE cores have 64-byte cache lines on one cluster = and 32-byte on the other. If you query the size from userspace while = running on a 64-byte cluster, then issue the zero-cache-line instruction = while migrated to the 32-byte cluster, you only clear half the size. = Linux works around this by trapping and emulating the instruction to = query the cache size and always reporting the size for the smallest = cache lines. ARM tells people not to build systems like this, but it = doesn=E2=80=99t always stop them. Trapping and emulating is much slower = than just providing the information in a shared page, elf aux args = vector, or even (often) a system call. To give another example, Linux provides a very cheap way for a userspace = process to enquire which core it=E2=80=99s running on. Some more recent = high-performance mallocs use this to have a second-layer per-core cache = after the per-thread cache for free blocks. Unlike the per-thread = cache, the per-core cache does need a lock, but it=E2=80=99s very = unlikely to be contended (it will only be contended if either a thread = is migrated in between checking and locking, so acquires the wrong = CPU=E2=80=99s lock, or if a thread is preempted in the middle of middle = of the very brief fill operation). The author of the SuperMalloc paper = tried doing this with CPUID and found that it was slower by a sufficient = margin to almost entirely offset the benefits of the extra layer of = caching. =20 Just because userspace can get at the information directly from the = hardware doesn=E2=80=99t mean that this is the most efficient or best = way for userspace to get at it. Oh, and some of these things are useful in portable code, so having to = write some assembly for every target to get information that the kernel = already knows is wasteful. David From owner-freebsd-current@freebsd.org Thu Jan 4 10:59:01 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEDB7EA9808 for ; Thu, 4 Jan 2018 10:59:01 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 2A26C3F06 for ; Thu, 4 Jan 2018 10:59:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-169-232-53.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.169.232.53]) by ipmail03.adl2.internode.on.net with ESMTP; 04 Jan 2018 21:23:49 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPS id w04Arcex029167 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Jan 2018 21:23:39 +1030 (CST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.1/8.14.9/Submit) id w04AjCfv023601 for ; Thu, 4 Jan 2018 21:15:12 +1030 (CST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [192.168.0.14] (tru75-16-78-196-125-127.fbx.proxad.net [78.196.125.127]) by 124-169-232-53.dyn.iinet.net.au (envelope-sender ) (MIMEDefang) with ESMTP id w04Aj1hn022464; Thu, 04 Jan 2018 21:15:12 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: USB stack From: "O'Connor, Daniel" In-Reply-To: <20180104092349.2821f9f9@ernst.home> Date: Thu, 4 Jan 2018 11:44:59 +0100 Cc: blubee blubeeme , FreeBSD current Content-Transfer-Encoding: 7bit Message-Id: <18F01F2F-8907-4CF8-A80A-B6B5C16593B7@dons.net.au> References: <1FD1FE97-D25C-4BAC-A3E0-F22509FB0C2B@dons.net.au> <6A4FF1B9-D98B-4E73-9E3E-E951749E0C21@dons.net.au> <20180104092349.2821f9f9@ernst.home> To: gljennjohn@gmail.com X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Score: 0.4 () No, score=0.4 required=5.0 tests=HELO_MISC_IP, RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 10:59:01 -0000 > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: >> What is an "LG v30"? >> > It's a smartphone from LG and only supports USB2 speed. The reported > transfer rate is no big surprise. OK thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@freebsd.org Thu Jan 4 11:15:00 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93B0BEAA534 for ; Thu, 4 Jan 2018 11:15:00 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA3963C49; Thu, 4 Jan 2018 11:14:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ldcv0-1fEfxV19Qw-00ilSr; Thu, 04 Jan 2018 12:14:55 +0100 Date: Thu, 4 Jan 2018 12:14:47 +0100 From: "O. Hartmann" To: Michael Tuexen Cc: Warner Losh , "O. Hartmann" , FreeBSD CURRENT Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Message-ID: <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:J4ASdeIuaRdvPxDD4+/L7VsgBlFbcJcXQLTE2rFFA/r8oS94Nja 5xNM6eDM3v4Qgzy84RYWHH1YbmLyDDaHgFKm2975ATFryNWJRWRS0MrNAaRhMixmcWufOL+ rtP9+SSDX8WRFhfDIDN1bQd5CvzhJQzLJB86o+HUWI2zVF3V363ohqsJjdpSMyhrFW+Y8tJ Jr5YLG87rtSml3js8pDvg== X-UI-Out-Filterresults: notjunk:1;V01:K0:mNDqVR2hFMc=:Z0RgrNKaJy9hu78V0pTwdK x0B6lUkMinjd8p8/SlhzpJqe9PfTmkt8IVSwqxNt4mQEEAl/KDadFkNrUQFFmJENXGq/6P4IQ ijZCzuPrKFxvnOj3G5bkqnJo7zfvpmy62lzOH7giy1/+7B0u8lo8Yy2TdqlflkqOcYbRm1bqJ prXwQv/lwUtRzrBiaWfSjY3touQvmzZfw81WWyBWeCYiUkW4nGuLe4JFg0V/O17vJkh8ST56l G6B+5tweygCCf1kNtyo9shEDiN/eey01Rdu4ftRIit5FCNc8wzRmEPmaLMjvZlwpD/7Pl694A itjaQDr9XjNNUHVXacRDwMySlflM2+oY/3/56hTlhCP3/AhObHEpTKYNjkHHujdW6lja5S3xz bhNTcOOmplfW+Jl0DTUGbejdBb/29uCLexs4Jhh+knwPXVQTbvdXD2rJ4Bk3DKA8wL09c6aTl B+rYGSgEX0BPkwtLrmCtg9L0OAL0yG2LD3euupcFpoaLFf6BiRGm9nuw0aTphDnSg9o/ZkMSB aWCY1awxN7pLKUgpWlqKcZSxll+D3z7gw9w/UDDtVfq+03Dgd8wFu4wTURWpnI8OaT/BSelWT bAW7pjtib4tSzTxYqZWe7j7+fc3BbjakyO+STfKxIYbpSrLdICIg+r9LVP2rKQ5nECeluxKfy 3UNoAlLWyeWuWFQhogV+3gNBG4HkzxaAIPQR4cWxFRZIwyIH5c6Ys6uL00OhSqaaHXmfmH4TW ehcPusJyMWYaDbYrxm7F94VxGBdhaNqgtVzOKgKhMsFLYoLqWn4e8Os4Xnbq7bFvckUGCtfLs JCXI3Y+132e79DasEFCqqh9WTCHec8deYtmoY6w+AeIISs6S30= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 11:15:00 -0000 On Thu, 4 Jan 2018 09:10:37 +0100 Michael Tuexen wrote: > > On 31. Dec 2017, at 02:45, Warner Losh wrote: > > > > On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann wrote: > > > >> On most recent CURRENT I face the error shwon below on /tmp filesystem > >> (UFS2) residing > >> on a Samsung 850 Pro SSD: > >> > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != > >> bp: 0xd9fba319 > >> handle_workitem_freefile: got error 5 while accessing filesystem > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > >> != bp: 0xd9fba319 > >> handle_workitem_freefile: got error 5 while accessing filesystem > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > >> != bp: 0xd9fba319 > >> handle_workitem_freefile: got error 5 while accessing filesystem > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > >> != bp: 0xd9fba319 > >> handle_workitem_freefile: got error 5 while accessing filesystem > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 > >> != bp: 0xd9fba319 > >> handle_workitem_freefile: got error 5 while accessing filesystem > >> > >> I've already formatted the /tmp filesystem, but obviously without any > >> success. > >> > >> Since I face such strange errors also on NanoBSD images dd'ed to SD cards, > >> I guess there > >> is something fishy ... > > > > > > It indicates a problem. We've seen these 'corruptions' on data in motion at > > work, but I hacked fsck to report checksum mismatches (it silently corrects > > them today) and we've not seen any mismatch when we unmount and fsck the > > filesystem. > Not sure this helps: But we have seen this also after system panics > when having soft update journaling enabled. Having soft update journaling > disabled, we do not observed this after several panics. > Just to be clear: The panics are not related to this issue, > but to other network development we do. > > You can check using tunefs -p devname if soft update journaling is enabled or > not. In all cases I reported in earlier and now, softupdates ARE ENABLED on all partitions in question (always GPT, in my cases also all on flash based devices, SD card and/or SSD). > > Best regards > Michael > > > > Warner > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Jan 4 11:17:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7052EAA913 for ; Thu, 4 Jan 2018 11:17:59 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48A0E63E79; Thu, 4 Jan 2018 11:17:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MaW7Z-1eDahb2Jnl-00K6oR; Thu, 04 Jan 2018 12:17:50 +0100 Date: Thu, 4 Jan 2018 12:17:49 +0100 From: "O. Hartmann" To: Shawn Webb Cc: Don Lewis , freebsd-current@FreeBSD.org Subject: Re: more fallout from removal of lint Message-ID: <20180104121735.18f2387f@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180102143308.3dmv7sdqccuehrid@mutt-hbsd> References: <20180102143308.3dmv7sdqccuehrid@mutt-hbsd> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:leWaEC3rCfQXQXcr4YnPPr+zrnqxCtwgle1ERGs8Nx1zWQzj9J5 L6vbvtWBG44YJdGe/1F+lbZCLWfGnrWYTweVSTdnCa25Ml5SZiKCp44zuKyMtChT8RMtO9R YhGd7VS1fANU2f4/vh1wPHPdyWypBtC45P2k55CR0S5zqYc8fLp7RoElX9IR8V2ewpe9Hax hhpYKoYWJVjSjoWRQpbGA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+6L1TxROYig=:nOtlSyakUvgHy8T1PD032a qXjNriOGnI1eCoLa7E0xIPMte6CKNXmu08+PsPsW4xeO/WL71tOr3qpxqob2uk1vAGP0QniXm yyXd6A2AtNNcpxdlhuMs9LXiSy40qQp8CR32dVi8pA3ux3GxEolI3ooEMjMwibACnasJn3u0W smuc1PJlMkBYV6UYgd/f/ff/im6XZSRpA8EePY0ruI287Z7jOW6sXrfo+0z58LsdfwdA88+b2 S4PlK/8R3/qO8c2XdQ0GqFwxHhQ311Vrjp+O6AL0uYN+5EBkDZ2VrA8Nsqj802GrIPm0SkAk8 KRoosDs/obfF94FehAmLoheuB/f7E0whdVpuDflp2Z7fFJPsEsHa1BnzQac71UymUfKzWEtKW 8i8kwEdSmLx41ya2kEAzU7FhRee/Zs/L8FukAjuh7Yu1PpbOOEqOvlv5YOMde59RVI7Z+dO7x oQ/8HnO/Ok0OZc2tuiOrHgtP3H8WpMSSmg8eCV2WWGKI8ISGR5T/azhFuzdmNP5vz9H5klW0Y JEUCBSRYDw981xELl1UuQG/7k8dU0oB0DZJDTmUKZGW9brriB1EAcmbdYuppjhXZSLELtVrfG JtaTtvINtq6bKZ8BXENKn/9frdOYvMOAn1/CVeRQvrKIIn279qsjS6SJkk+YnpOdrAA0fZg8J TN+YQfiQJn725tOVxX6340NhO9l42kTi0TodAcbvppG+jFQsQJp0eKw+sis8UW1pqkOzHKi4A QM1NoRlvxuKOw6tbU0UyBMtINQZyOKNdk00b7Rz6k89H+TEzPeJeIhSsPu2hjcyC88kLQz9hK svJRb8YDteJIsk5pXDD7qaDMqWT3qRFG+S0FV8LUxqnU7Yhgbg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 11:17:59 -0000 On Tue, 2 Jan 2018 09:33:08 -0500 Shawn Webb wrote: > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: > > Since lint was removed from 12.0-CURRENT, it is not possible to build > > 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that > > by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick > > doesn't work when updating a 11.1-STABLE poudriere jail on a > > 12.0-CURRENT host. > > > > ===> usr.bin/xlint (install) > > ===> usr.bin/xlint/lint1 (install) > > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g > > wheel -m 555 lint1 /var/poudriere/jails/111STABLEi386/usr/libexec/lint1 > > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > > -m 444 > > lint1.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint1.debug > > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > > -m 444 lint.7.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man7/ > > ===> usr.bin/xlint/lint2 (install) install > > -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g wheel -m > > 555 lint2 /var/poudriere/jails/111STABLEi386/usr/libexec/lint2 install > > -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 > > lint2.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/libexec/lint2.debug > > ===> usr.bin/xlint/xlint (install) install > > -N /var/poudriere/jails/111STABLEi386/usr/src/etc -s -o root -g wheel -m > > 555 xlint /var/poudriere/jails/111STABLEi386/usr/bin/lint install > > -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel -m 444 > > lint.debug /var/poudriere/jails/111STABLEi386/usr/lib/debug/usr/bin/lint.debug > > install -N /var/poudriere/jails/111STABLEi386/usr/src/etc -o root -g wheel > > -m 444 lint.1.gz /var/poudriere/jails/111STABLEi386/usr/share/man/man1/ > > ===> usr.bin/xlint/llib (install) lint -cghapbx > > -I/usr/obj/i386.i386/var/poudriere/jails/111STABLEi386/usr/src/tmp/usr/include > > -Cposix /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib/llib-lposix > > sh: lint: not found *** [llib-lposix.ln] Error code 127 > > > > make[6]: stopped > > in /var/poudriere/jails/111STABLEi386/usr/src/usr.bin/xlint/llib 1 error > > > > > > # ls -l /usr/bin/lint /usr/bin/true > > -r-xr-xr-x 1 root wheel 4976 Dec 30 12:37 /usr/bin/lint > > -r-xr-xr-x 1 root wheel 4976 Dec 29 21:13 /usr/bin/true > > I had filed[1] a bug report about this a little over a month ago and > FreeBSD was disinterested in even discussing it. HardenedBSD worked > around the issue by disabling the build of lint in its 11-STABLE and > 10-STABLE trees. > > [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223892 > > Thanks, > I ran also into this problem and for security reasons, I HAVE TO update several hosts to 11.1-RELENG-p6. I can not, because the building host (poudriere, also the binary packages for a binary update of base) is on CURRENT. I hope this issue gets fixed soon. Regards, Oliver From owner-freebsd-current@freebsd.org Thu Jan 4 11:56:29 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E181EAD70A for ; Thu, 4 Jan 2018 11:56:29 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 60BCF65D8C for ; Thu, 4 Jan 2018 11:56:28 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4274420BE3 for ; Thu, 4 Jan 2018 06:56:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 04 Jan 2018 06:56:22 -0500 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=81/QIx ICm+eL7A5oyul8FS6yU1Ubo6R8luZKFw6JW6Q=; b=koekU0w2SQHMI4k3FMv7nS aJIPvBRYu6E7DqT/m+ZcJ5afcqvDUmAnFatnsYI9tuKFGTtr7zH+YJKAB6koWrK1 ebiNaPyfxIWBFRv7gTD2z+JwwlRhr84J8dvEFOBsCSzT51HxpKDsB37njJGg7ZZi u6b90Zx04V/tkrPnI07b6bEsLW3kz2WgRTgxkypmaHlM0S5rCRlfd2hBBEUWp0b7 2ZvsqA8fX/l6OYDmlChgS5PvYqIm7KuwaL4o1rssG3B6jPs8AYlsBfoDQSeFWbxw gBZc3S6Wm152Q2/t6kQrf8Ur96Gh/I1I45b4oBGZ466jG7NGipnFHRO+DwpKf/Ig == X-ME-Sender: Received: from [192.168.1.31] (202-129-124-76.perm.iinet.net.au [202.129.124.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 903C67E2C9 for ; Thu, 4 Jan 2018 06:56:21 -0500 (EST) Subject: Re: Intel CPU design flaw - FreeBSD affected? To: freebsd-current@freebsd.org References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: Darren Reed Message-ID: <5A4E165B.6040809@freebsd.org> Date: Thu, 4 Jan 2018 22:56:11 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 11:56:29 -0000 On 4/01/2018 11:51 AM, Mark Heily wrote: > On Jan 2, 2018 19:05, "Warner Losh" wrote: > > The register article says the specifics are under embargo still. That would > make it hard for anybody working with Intel to comment publicly on the flaw > and any mitigations that may be underway. It would be unwise to assume that > all the details are out until the embargo lifts. > > > Details of the flaws are now published at: > > https://meltdownattack.com The web page has both: meltdown and spectre. Most people are only talking about meltdown which doesn't hit AMD. spectre impacts *both* Intel and AMD. SuSE are making available a microcode patch for AMD 17h processors that disables branch prediction: https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html Kind Regards, Darren From owner-freebsd-current@freebsd.org Thu Jan 4 14:06:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 595EBEB6A75 for ; Thu, 4 Jan 2018 14:06:18 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB596ACC2 for ; Thu, 4 Jan 2018 14:06:18 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-oi0-x22c.google.com with SMTP id 184so1075179oii.2 for ; Thu, 04 Jan 2018 06:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d9wooc4E+p2IAzypEMqPv2T4Rhg3H5dUZDQHYIPx0qE=; b=HUSnfxIwFx0Erya3mI6m77Z20ciGIj0mvcxzVP34F3M8murCuRoO3zMjRspP2CjHAm ZjKOsFLR6YePcvzAJLV1ljhtH+rsuV5NSR4l/dDhRUIpYmvVNN2Ft6B/baOcEzpFlIrP ZNlBYznmvVQutN+5KfgQY0CdhgoYs++GoPGFnsHxSlFIGa6icbCamZ5ZxUZk24zwE/JK Lo4OVXspExqopsGSEj1BmwalRBZaSYTEsAI9KTtMd9CZZxRZri8yNKNLegnQ9Wdq4TVJ qtWV4U5fr7BTWz1Jb/+5JIYfU7o9XKcMZ9a3zeZk/c+n2HM1WQYCK27/F9PuvmMvobRv J6qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d9wooc4E+p2IAzypEMqPv2T4Rhg3H5dUZDQHYIPx0qE=; b=Dc/xyOcOCc6+DQrsymHX3XJBlnA1/7SrG1AYbRJDDxCa8lNnr3FhD6OvZ9g6sygiMT CNAuJXRNnbuHVS3IMOZwFEBKeXkcxr0IeZSxmAnzBOkQCpKSjICiUdGV9j6JZq3rnOqP q8f4voNNBWfq1rrsOA1FKuUxm089KhtyFGcT3JKBAu6PE3JswBcCyB4NBXF4uuSvSzNC S8CQXfWcUpqVUKOVKbpbI24n2I2hvbaaWo7ganGSJN2ZC6vbiI4MscUy0cGyGvekSADw OdY1KojBSNaLJ9rl/NVEbgKXx85bhEk6HbOh9Gv+5JPI84ZT1uKDtrW+/LXqiadWpVGb qxjQ== X-Gm-Message-State: AKGB3mLhPuZsich6HCr96HUs9JpoDgD2M6x4iFGy31hcPR2/ZgNdXs5q E+gccX+1RgmmYF1gqKGPi0czK6bBlZO4a88953OrmA== X-Google-Smtp-Source: ACJfBouV7WVCjWZUxwnC0L4hNqGKLRCzl9nh/4OgBBFb+uPl7smjmIC6y/hKPyxOkEE+dRidvP2sdqbxj5hfzH6upw8= X-Received: by 10.202.245.136 with SMTP id t130mr2638599oih.356.1515074777143; Thu, 04 Jan 2018 06:06:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.22.183 with HTTP; Thu, 4 Jan 2018 06:06:16 -0800 (PST) X-Originating-IP: [71.70.173.127] In-Reply-To: <20180104121735.18f2387f@freyja.zeit4.iv.bundesimmobilien.de> References: <20180102143308.3dmv7sdqccuehrid@mutt-hbsd> <20180104121735.18f2387f@freyja.zeit4.iv.bundesimmobilien.de> From: Mark Heily Date: Thu, 4 Jan 2018 09:06:16 -0500 Message-ID: Subject: Re: more fallout from removal of lint To: "O. Hartmann" Cc: Shawn Webb , Don Lewis , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:06:18 -0000 On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann wrote: > On Tue, 2 Jan 2018 09:33:08 -0500 > Shawn Webb wrote: > > > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: > > > Since lint was removed from 12.0-CURRENT, it is not possible to build > > > 11.1-STABLE on a 12.0-CURRENT host > There is a big difference between what is "possible" and what is "supported". Since CURRENT is branched off of STABLE, there is always a period of time where the two build systems are compatible. During this time, it is *possible* to build STABLE on a CURRENT host. However, the build system for CURRENT can be changed in ways that make it incompatible with building STABLE. This is normal and expected behavior for a development branch. It has never been a *supported* option to mix and match source code from different branches on a single host. Can you try creating a 11.1-STABLE jail on your 12-CURRENT host, and perform the build within the jail? I'm not clear on what role Poudriere plays in all of this, so that may take some additional work to straighten out. Regards, - Mark From owner-freebsd-current@freebsd.org Thu Jan 4 14:26:41 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8701EEB80A4 for ; Thu, 4 Jan 2018 14:26:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 26DCC6BA0A for ; Thu, 4 Jan 2018 14:26:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-70-98.dz.commufa.jp [124.18.70.98]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id w04EQVDc047310 for ; Thu, 4 Jan 2018 23:26:32 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 4 Jan 2018 23:26:31 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Intel CPU design flaw - FreeBSD affected? Message-Id: <20180104232631.3d163448d7ac2a3bc82fe5af@dec.sakura.ne.jp> In-Reply-To: References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:26:41 -0000 And now official announcement from Intel... https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr On Wed, 3 Jan 2018 19:51:40 -0500 Mark Heily wrote: > On Jan 2, 2018 19:05, "Warner Losh" wrote: > > The register article says the specifics are under embargo still. That would > make it hard for anybody working with Intel to comment publicly on the flaw > and any mitigations that may be underway. It would be unwise to assume that > all the details are out until the embargo lifts. > > > Details of the flaws are now published at: > > https://meltdownattack.com > > > Warner > > On Jan 2, 2018 4:13 PM, "Michael Butler" wrote: > > > Has any impact assessment been made as to FreeBSD's exposure or > > mitigation strategies? > > > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > > Windows redesign - The Register > > > > Other OSes will need an update, performance hits loom A fundamental > > design flaw in Intel's processor chips has forced a significant redesign > > of the Linux and Windows kernels to defang the chip-level security bug.$B!D(B > > Programmers are scrambling to overhaul the open-source Linux kernel's > > virtual memory system. Meanwhile, Microsoft is expected to publicly > > introduce necessary changes to its Windows operating system in this > > month's Patch Tuesday ... > > > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > > > imb > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Thu Jan 4 14:43:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB7D4EB93CC for ; Thu, 4 Jan 2018 14:43:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from sonic311-44.consmr.mail.ir2.yahoo.com (sonic311-44.consmr.mail.ir2.yahoo.com [77.238.176.176]) (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 69E936C480 for ; Thu, 4 Jan 2018 14:43:58 +0000 (UTC) (envelope-from se@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1515077036; bh=8dD6Iyx7XTShKAVSC3TY24Ys5hU/UG0vnb1+XpaH/xE=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=TkOSf+NRSH3MlODOylqEHec1Zy7MJGO1QGBZmGQ7I69IuPhYw2psy4f11m3oMwbtqPt0GR1Z2p1am8LbVrMAMFKODpbHfwThJ7s+pHsWdmkGcatD9qCV6U3rM/Tc/cNGLy1tby0GXA8r9glkxxuZeAOb9GBwOQJSlYP3BaylmRT2wyVBTGLlV5EGUB0A2iGWRh5GXJ18FjrXq0rujx9cX6THhztcmWQ/5lHNUMDzVLe91R699L8ZBDjzM5P3Xc3VP3MuJH7CaqJNZ/RnYWEBaVWCPf/lE22iCVbd6Ed37N/G75vowA7dlPmkApMvcg+OfN6ytvA//LmHqJRS+vjDXg== X-YMail-OSG: zXghkbAVM1mjt8AjUP0EOkIG7JT4d6pwzQC3c9PsQLf17PES8czopYsJAFF8U.W Pcgwj7umYpFIXVyFMN4GKo.dwy.PHVT4jQnbxI6LBgcEPMxHqh2Pd4r5wSrW_FrBR0XroVKcGkdv T2cj1nmleQ7RUVvl4GsP1nwURsiR3HhnMWfcrvaDeFODP1nFM0j6iG2A79K5NR9GJ03Xs2EEP9ly FQEEVJ6NWSjNkD5wDBgEONcVYr3G3FcHRivD8d6w2XpyEcKLcmb1.FKqEU3L1bGSY1cGMjeEQvm_ BNw6ombCS_JSbesWkZKU_uNNHRmJrv2ppo0w1Ug8nryPJ6dgCL5pzhODPVrrhUbHd0ni0eFyku_B Vih0rwYoqqhFM6d787DfjSzLaQMHv.tZec8v09Et._WKH1HoS51zATj.2QpjTM5gPKbtlD_hjNgF Qz10flb841tEH3hm89mUbeplZNBSqK1nziWhQaejvS_hay.VrlyN0rEBFpYllOIZ_B7JM8xIxa3W crJTD Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Thu, 4 Jan 2018 14:43:56 +0000 Received: from smtp173.mail.ir2.yahoo.com (EHLO Stefans-MBP-LAN.fritz.box) ([46.228.39.40]) by smtp416.mail.ir2.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 874695c029da76230379335eba512b96; Thu, 04 Jan 2018 14:33:47 +0000 (UTC) Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Darren Reed , freebsd-current@freebsd.org References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <5A4E165B.6040809@freebsd.org> From: Stefan Esser Message-ID: Date: Thu, 4 Jan 2018 15:33:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5A4E165B.6040809@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:43:59 -0000 Am 04.01.18 um 12:56 schrieb Darren Reed: > On 4/01/2018 11:51 AM, Mark Heily wrote: >> On Jan 2, 2018 19:05, "Warner Losh" wrote: >> >> The register article says the specifics are under embargo still. That would >> make it hard for anybody working with Intel to comment publicly on the flaw >> and any mitigations that may be underway. It would be unwise to assume that >> all the details are out until the embargo lifts. >> >> >> Details of the flaws are now published at: >> >> https://meltdownattack.com > > The web page has both: meltdown and spectre. > Most people are only talking about meltdown which doesn't hit AMD. > spectre impacts *both* Intel and AMD. > > SuSE are making available a microcode patch for AMD 17h processors that > disables branch prediction: > > https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html Disabling branch prediction will have a very noticeable effect on execution speed in general (while split page tables only affect programs that perform system calls at a high frequency). I have not fully read the Meltdown and Spectre papers, yet, but I do assume, that the attack at the branch prediction tries to counter KASLR, which we do not support at all in FreeBSD. So, I guess, we do not have to bother with disabling of branch prediction in FreeBSD for the time being? Regards, STefan From owner-freebsd-current@freebsd.org Thu Jan 4 14:50:53 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F2B7EB9AFC; Thu, 4 Jan 2018 14:50:53 +0000 (UTC) (envelope-from srs0=fypj=d7=freebsd.org=kp@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E07526C91F; Thu, 4 Jan 2018 14:50:52 +0000 (UTC) (envelope-from srs0=fypj=d7=freebsd.org=kp@codepro.be) Received: from [172.16.2.10] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D24884506C; Thu, 4 Jan 2018 15:50:49 +0100 (CET) From: "Kristof Provost" To: freebsd-arch@freebsd.org Cc: freebsd-hackers , "FreeBSD Current" Subject: RFC: mallocarray() Date: Thu, 04 Jan 2018 15:51:09 +0100 X-Mailer: MailMate (2.0BETAr6102) Message-ID: <070C0DEB-E70C-42D9-B734-E0735A6C9B8E@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:50:53 -0000 Hi, I’d like to make it easier to avoid integer overflow issues in the kernel. It’d be a lot nicer to have a malloc function figure this out for us, so I’d like mallocarray(). https://reviews.freebsd.org/D13766 Are there any objections to this? Regards, Kristof From owner-freebsd-current@freebsd.org Thu Jan 4 14:59:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14BE6EBA904 for ; Thu, 4 Jan 2018 14:59:56 +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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E99776D353 for ; Thu, 4 Jan 2018 14:59:55 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id w04ExuGP035993 for ; Thu, 4 Jan 2018 07:00:02 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: Subject: Re: Intel CPU design flaw - FreeBSD affected? Date: Thu, 04 Jan 2018 07:00:02 -0800 Message-Id: <39abfc53763a4a83142af49e2d56aa59@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:59:56 -0000 On Thu, 4 Jan 2018 15:33:46 +0100 "Stefan Esser" said > Am 04=2E01=2E18 um 12:56 schrieb Darren Reed: > > On 4/01/2018 11:51 AM, Mark Heily wrote: > >> On Jan 2, 2018 19:05, "Warner Losh" wrote: > >> > >> The register article says the specifics are under embargo still=2E That = would > >> make it hard for anybody working with Intel to comment publicly on the= flaw > >> and any mitigations that may be underway=2E It would be unwise to assume= that > >> all the details are out until the embargo lifts=2E > >> > >> > >> Details of the flaws are now published at: > >> > >> https://meltdownattack=2Ecom > >=20 > > The web page has both: meltdown and spectre=2E > > Most people are only talking about meltdown which doesn't hit AMD=2E > > spectre impacts *both* Intel and AMD=2E > >=20 > > SuSE are making available a microcode patch for AMD 17h processors that > > disables branch prediction: > >=20 > > https://lists=2Eopensuse=2Eorg/opensuse-security-announce/2018-01/msg00004=2E= html >=20 > Disabling branch prediction will have a very noticeable effect on executi= on > speed in general (while split page tables only affect programs that perfo= rm > system calls at a high frequency)=2E OUCH! That was the whole point of these; drop cores, and frequency, for hug= e cache lines, and branch prediction=2E You eliminate that branch prediction, a= nd these become near useless=2E :-( Glad I waited, before getting one! >=20 > I have not fully read the Meltdown and Spectre papers, yet, but I do assu= me, > that the attack at the branch prediction tries to counter KASLR, which we= do > not support at all in FreeBSD=2E >=20 > So, I guess, we do not have to bother with disabling of branch prediction= in > FreeBSD for the time being? >=20 > Regards, STefan --Chris From owner-freebsd-current@freebsd.org Thu Jan 4 16:29:18 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C085EC1AAF for ; Thu, 4 Jan 2018 16:29:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2B1472426 for ; Thu, 4 Jan 2018 16:29:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id g70so2765980ioj.6 for ; Thu, 04 Jan 2018 08:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g0iLvCv8liFRtM0U39Nuo3jjS9KTokmiqVlCy2WewFA=; b=tok0ElwBW9hhzjFwccjrkG2dP/AHSK4A3OT5JMA2Zd/VTBQSAbo8ZxEmnWIoF2mQY7 ye1qqGxHAAQT7finju5pg0vgkPJv18kki/bTHIdp0VgWQOAxjdj68SPIJiL+4Hj0wDrI 6LWCyiztsuN31px0fVacv7oPN0Nig8I96u2qMDBZxSUM+hdrUbPmtP+yEGMHweLGswZt Nc94kZV4LCNVS4bQIl/pk1GgSGqCAdbK7TyPLkwxY89Fj/h24BHBuAkRV8etOSfvSzPH SIUGrAOv/mIkA97S3C/ZiDo1ug1UFWipSLNcYe8OOSmHbhqrBwMRgKndhtZQxzYQgiCY A+fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=g0iLvCv8liFRtM0U39Nuo3jjS9KTokmiqVlCy2WewFA=; b=mWd3mNHm+wss6D0wfEaXVEAe96arKos/REj9W+HvqTB2VJ8KhwMsD6W0ub0EHmBKao eniIJE8QDYxfDm81bpZWzSnWaxX/+PtqIOC8IKmIQNSXHYTGFaC5pvL0jaOSebav3H9Z 3Hn0B3iekD/fhQvXvTnXo7+ksqpQ1zCOffffwEEiEFOX2R5bFIaTZjlh+LDGiRnqeQnD a9z7fH3Y9rwW8JeD+rp7u9n3quampdfHnPrSo84s/i3fKinanJRPuMUC1+SGz1mgB3oR sgDUtE7k2lMROpPUSFwRYus02Zu9jbr/TPzzY0jgt+MdakA+3e3UOmChBxMYjRFRReWl tslw== X-Gm-Message-State: AKwxyteAfa2zanOikbJfiNB/ioQcakyx+KXvac/5z/DLG+B2XbDuo5Pg JsMyo1QEOPLDw9L9FrcuTjezaR2bhe4WdHNjHFjIBg== X-Google-Smtp-Source: ACJfBouAyvQuhEZ/JxAZhBIIM+W1zZ3jTd5tttdn7melnSk6byXQU7Cav3ScjseC7NESBEfP+3zb+uHM6/WYlE5S/5A= X-Received: by 10.107.12.36 with SMTP id w36mr112370ioi.291.1515083356775; Thu, 04 Jan 2018 08:29:16 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Thu, 4 Jan 2018 08:29:16 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <5A4E165B.6040809@freebsd.org> From: Warner Losh Date: Thu, 4 Jan 2018 09:29:16 -0700 X-Google-Sender-Auth: JEseTAlfQvQyyw-A796ObzPlVeo Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? To: Stefan Esser Cc: Darren Reed , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 16:29:18 -0000 On Thu, Jan 4, 2018 at 7:33 AM, Stefan Esser wrote: > Am 04.01.18 um 12:56 schrieb Darren Reed: > > On 4/01/2018 11:51 AM, Mark Heily wrote: > >> On Jan 2, 2018 19:05, "Warner Losh" wrote: > >> > >> The register article says the specifics are under embargo still. That > would > >> make it hard for anybody working with Intel to comment publicly on the > flaw > >> and any mitigations that may be underway. It would be unwise to assume > that > >> all the details are out until the embargo lifts. > >> > >> > >> Details of the flaws are now published at: > >> > >> https://meltdownattack.com > > > > The web page has both: meltdown and spectre. > > Most people are only talking about meltdown which doesn't hit AMD. > > spectre impacts *both* Intel and AMD. > > > > SuSE are making available a microcode patch for AMD 17h processors that > > disables branch prediction: > > > > https://lists.opensuse.org/opensuse-security-announce/ > 2018-01/msg00004.html > > Disabling branch prediction will have a very noticeable effect on execution > speed in general (while split page tables only affect programs that perform > system calls at a high frequency). > > I have not fully read the Meltdown and Spectre papers, yet, but I do > assume, > that the attack at the branch prediction tries to counter KASLR, which we > do > not support at all in FreeBSD. > > So, I guess, we do not have to bother with disabling of branch prediction > in > FreeBSD for the time being? > Branch prediction has nothing to do with defeating KASLR. It's rather the whole crux of the attack. Disabling it is one way to prevent Specter. The only thing that will help Meltdown, though, is separate page tables. It's only an incidental foot note that these methods don't care about KASLR and KASLR isn't at all effective in blunting these attacks. Warner From owner-freebsd-current@freebsd.org Thu Jan 4 18:25:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F071CEABFE0 for ; Thu, 4 Jan 2018 18:25:54 +0000 (UTC) (envelope-from k@7he.at) Received: from smtp-02.sil.at (smtp-02-5.sil.at [78.142.186.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A875877E0F for ; Thu, 4 Jan 2018 18:25:54 +0000 (UTC) (envelope-from k@7he.at) Received: from mx.7he.at ([86.59.13.138]) by smtp-02.sil.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1eXAD9-0002Ew-97 for freebsd-current@freebsd.org; Thu, 04 Jan 2018 19:25:51 +0100 Received: from [192.168.6.60] ([93.83.242.219]) by mx.7he.at (8.15.2/8.15.2) with ESMTPS id w04IPoCf082164 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Jan 2018 19:25:50 +0100 (CET) (envelope-from k@7he.at) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx.7he.at Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC From: "Klaus P. Ohrhallinger" To: freebsd-current@freebsd.org References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> Message-ID: <52b2f48c-332c-8984-838f-4902da0ebc81@7he.at> Date: Thu, 4 Jan 2018 19:25:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.5 required=5.0 tests=HELO_MISC_IP,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.7he.at X-Scan-Signature: a358776562af27d729c379ba6e4ac908 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:25:55 -0000 On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote: > Hello, > > I disabled the ldtsc and ldtscp instructions for usermode on one of my > production servers: > Oops, RDTSC of course. From owner-freebsd-current@freebsd.org Thu Jan 4 18:26:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 838CBEAC229 for ; Thu, 4 Jan 2018 18:26:49 +0000 (UTC) (envelope-from k@7he.at) Received: from smtp-02.sil.at (smtp-02-5.sil.at [78.142.186.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A239781E6 for ; Thu, 4 Jan 2018 18:26:48 +0000 (UTC) (envelope-from k@7he.at) Received: from mx.7he.at ([86.59.13.138]) by smtp-02.sil.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1eXABD-0001pt-5e for freebsd-current@freebsd.org; Thu, 04 Jan 2018 19:23:51 +0100 Received: from [192.168.6.60] ([93.83.242.219]) by mx.7he.at (8.15.2/8.15.2) with ESMTPS id w04INoVF082019 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 4 Jan 2018 19:23:50 +0100 (CET) (envelope-from k@7he.at) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx.7he.at Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: freebsd-current@freebsd.org References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> From: "Klaus P. Ohrhallinger" Message-ID: <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> Date: Thu, 4 Jan 2018 19:23:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> Content-Type: multipart/mixed; boundary="------------80572298F8A81184E6F60AC9" Content-Language: en-GB X-Spam-Status: No, score=1.5 required=5.0 tests=HELO_MISC_IP,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.7he.at X-Scan-Signature: a9e6f2831941bf5918a12936d4a2f968 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:26:49 -0000 This is a multi-part message in MIME format. --------------80572298F8A81184E6F60AC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, I disabled the ldtsc and ldtscp instructions for usermode on one of my production servers: % ./spectre Reading 40 bytes: Bus error (core dumped) All PoC code I have seen today relies on those instructions. Is there any other way to measure the memory/cache access times ? On 10.4-RELEASE I had to rebuild world and some ports, but now everything seems to be working fine. Patches attached. Regards, Klaus --------------80572298F8A81184E6F60AC9 Content-Type: text/plain; charset=UTF-8; name="rdtsc-sys-02.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rdtsc-sys-02.diff" ZGlmZiAtYXVwciBzcmMub3JpZy9zeXMvYW1kNjQvYW1kNjQvaW5pdGNwdS5jIHNyYy9zeXMv YW1kNjQvYW1kNjQvaW5pdGNwdS5jCi0tLSBzcmMub3JpZy9zeXMvYW1kNjQvYW1kNjQvaW5p dGNwdS5jCTIwMTctMDktMjkgMDI6MjA6MDUuMDAwMDAwMDAwICswMjAwCisrKyBzcmMvc3lz L2FtZDY0L2FtZDY0L2luaXRjcHUuYwkyMDE4LTAxLTA0IDE1OjE5OjMyLjc0MTcyOTAwMCAr MDEwMApAQCAtMjEwLDYgKzIxMCw3IEBAIGluaXRpYWxpemVjcHUodm9pZCkKIAl9CiAJaWYg KGNwdV9zdGRleHRfZmVhdHVyZSAmIENQVUlEX1NUREVYVF9GU0dTQkFTRSkKIAkJY3I0IHw9 IENSNF9GU0dTQkFTRTsKKwljcjQgfD0gQ1I0X1RTRDsKIAogCS8qCiAJICogUG9zdHBvbmUg ZW5hYmxpbmcgdGhlIFNNRVAgb24gdGhlIGJvb3QgQ1BVIHVudGlsIHRoZSBwYWdlCmRpZmYg LWF1cHIgc3JjLm9yaWcvc3lzL3g4Ni94ODYvdHNjLmMgc3JjL3N5cy94ODYveDg2L3RzYy5j Ci0tLSBzcmMub3JpZy9zeXMveDg2L3g4Ni90c2MuYwkyMDE3LTA5LTI5IDAyOjIwOjA2LjAw MDAwMDAwMCArMDIwMAorKysgc3JjL3N5cy94ODYveDg2L3RzYy5jCTIwMTgtMDEtMDQgMTU6 MTk6MzIuNzU2MTIzMDAwICswMTAwCkBAIC02NTgsNiArNjU4LDcgQEAgdHNjX2ZyZXFfY2hh bmdlZCh2b2lkICphcmcsIGNvbnN0IHN0cnVjdAogc3RhdGljIGludAogc3lzY3RsX21hY2hk ZXBfdHNjX2ZyZXEoU1lTQ1RMX0hBTkRMRVJfQVJHUykKIHsKKyNpZiAwCiAJaW50IGVycm9y OwogCXVpbnQ2NF90IGZyZXE7CiAKQEAgLTY3MSw2ICs2NzIsOSBAQCBzeXNjdGxfbWFjaGRl cF90c2NfZnJlcShTWVNDVExfSEFORExFUl9BCiAJCSAgICBmcmVxID4+IChpbnQpKGludHB0 cl90KXRzY190aW1lY291bnRlci50Y19wcml2KTsKIAl9CiAJcmV0dXJuIChlcnJvcik7Cisj ZWxzZQorCXJldHVybiAoRU9QTk9UU1VQUCk7CisjZW5kaWYKIH0KIAogU1lTQ1RMX1BST0Mo X21hY2hkZXAsIE9JRF9BVVRPLCB0c2NfZnJlcSwgQ1RMVFlQRV9VNjQgfCBDVExGTEFHX1JX LAo= --------------80572298F8A81184E6F60AC9 Content-Type: text/plain; charset=UTF-8; name="rdtsc-libc-02.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rdtsc-libc-02.diff" ZGlmZiAtYXVwciBzcmMub3JpZy9saWIvbGliYy9hbWQ2NC9zeXMvX192ZHNvX2dldHRjLmMg c3JjL2xpYi9saWJjL2FtZDY0L3N5cy9fX3Zkc29fZ2V0dGMuYwotLS0gc3JjLm9yaWcvbGli L2xpYmMvYW1kNjQvc3lzL19fdmRzb19nZXR0Yy5jCTIwMTctMDktMjkgMDI6MjA6MTMuMDAw MDAwMDAwICswMjAwCisrKyBzcmMvbGliL2xpYmMvYW1kNjQvc3lzL19fdmRzb19nZXR0Yy5j CTIwMTgtMDEtMDQgMTY6NTM6MzEuNTkwOTYxMDAwICswMTAwCkBAIC0zMCwxNyArMzAsMjIg QEAgX19GQlNESUQoIiRGcmVlQlNEOiByZWxlbmcvMTAuNC9saWIvbGliYwogI2luY2x1ZGUg PHN5cy9lbGYuaD4KICNpbmNsdWRlIDxzeXMvdGltZS5oPgogI2luY2x1ZGUgPHN5cy92ZHNv Lmg+CisjaW5jbHVkZSA8ZXJybm8uaD4KICNpbmNsdWRlIDxtYWNoaW5lL2NwdWZ1bmMuaD4K ICNpbmNsdWRlICJsaWJjX3ByaXZhdGUuaCIKIAogc3RhdGljIHVfaW50CiBfX3Zkc29fZ2V0 dGNfbG93KGNvbnN0IHN0cnVjdCB2ZHNvX3RpbWVoYW5kcyAqdGgpCiB7CisjaWYgMAogCXVp bnQzMl90IHJ2OwogCiAJX19hc20gX192b2xhdGlsZSgicmR0c2M7IHNocmQgJSVjbCwgJSVl ZHgsICUwIgogCSAgICA6ICI9YSIgKHJ2KSA6ICJjIiAodGgtPnRoX3g4Nl9zaGlmdCkgOiAi ZWR4Iik7CiAJcmV0dXJuIChydik7CisjZWxzZQorCXJldHVybiAoMCk7CisjZW5kaWYKIH0K IAogI3ByYWdtYSB3ZWFrIF9fdmRzb19nZXR0YwpAQCAtNDgsNyArNTMsMTEgQEAgdV9pbnQK IF9fdmRzb19nZXR0Yyhjb25zdCBzdHJ1Y3QgdmRzb190aW1laGFuZHMgKnRoKQogewogCisj aWYgMAogCXJldHVybiAodGgtPnRoX3g4Nl9zaGlmdCA+IDAgPyBfX3Zkc29fZ2V0dGNfbG93 KHRoKSA6IHJkdHNjMzIoKSk7CisjZWxzZQorCXJldHVybiAoMCk7CisjZW5kaWYKIH0KIAog I3ByYWdtYSB3ZWFrIF9fdmRzb19nZXR0aW1la2VlcApAQCAtNTYsNSArNjUsOSBAQCBpbnQK IF9fdmRzb19nZXR0aW1la2VlcChzdHJ1Y3QgdmRzb190aW1la2VlcCAqKnRrKQogewogCisj aWYgMAogCXJldHVybiAoX2VsZl9hdXhfaW5mbyhBVF9USU1FS0VFUCwgdGssIHNpemVvZigq dGspKSk7CisjZWxzZQorCXJldHVybiAoRU5PU1lTKTsKKyNlbmRpZgogfQpkaWZmIC1hdXBy IHNyYy5vcmlnL2xpYi9saWJjL2kzODYvc3lzL19fdmRzb19nZXR0Yy5jIHNyYy9saWIvbGli Yy9pMzg2L3N5cy9fX3Zkc29fZ2V0dGMuYwotLS0gc3JjLm9yaWcvbGliL2xpYmMvaTM4Ni9z eXMvX192ZHNvX2dldHRjLmMJMjAxNy0wOS0yOSAwMjoyMDoxNC4wMDAwMDAwMDAgKzAyMDAK KysrIHNyYy9saWIvbGliYy9pMzg2L3N5cy9fX3Zkc29fZ2V0dGMuYwkyMDE4LTAxLTA0IDE3 OjAzOjAzLjA5NjcyNDAwMCArMDEwMApAQCAtMzAsMTcgKzMwLDIyIEBAIF9fRkJTRElEKCIk RnJlZUJTRDogcmVsZW5nLzEwLjQvbGliL2xpYmMKICNpbmNsdWRlIDxzeXMvZWxmLmg+CiAj aW5jbHVkZSA8c3lzL3RpbWUuaD4KICNpbmNsdWRlIDxzeXMvdmRzby5oPgorI2luY2x1ZGUg PGVycm5vLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CiAjaW5jbHVkZSAibGli Y19wcml2YXRlLmgiCiAKIHN0YXRpYyB1X2ludAogX192ZHNvX2dldHRjX2xvdyhjb25zdCBz dHJ1Y3QgdmRzb190aW1laGFuZHMgKnRoKQogeworI2lmIDAKIAl1aW50MzJfdCBydjsKIAog CV9fYXNtIF9fdm9sYXRpbGUoInJkdHNjOyBzaHJkICUlY2wsICUlZWR4LCAlMCIKIAkgICAg OiAiPWEiIChydikgOiAiYyIgKHRoLT50aF94ODZfc2hpZnQpIDogImVkeCIpOwogCXJldHVy biAocnYpOworI2Vsc2UKKwlyZXR1cm4gKDApOworI2VuZGlmCiB9CiAKICNwcmFnbWEgd2Vh ayBfX3Zkc29fZ2V0dGMKQEAgLTQ4LDcgKzUzLDExIEBAIHVfaW50CiBfX3Zkc29fZ2V0dGMo Y29uc3Qgc3RydWN0IHZkc29fdGltZWhhbmRzICp0aCkKIHsKIAorI2lmIDAKIAlyZXR1cm4g KHRoLT50aF94ODZfc2hpZnQgPiAwID8gX192ZHNvX2dldHRjX2xvdyh0aCkgOiByZHRzYzMy KCkpOworI2Vsc2UKKwlyZXR1cm4gKDApOworI2VuZGlmCiB9CiAKICNwcmFnbWEgd2VhayBf X3Zkc29fZ2V0dGltZWtlZXAKQEAgLTU2LDUgKzY1LDkgQEAgaW50CiBfX3Zkc29fZ2V0dGlt ZWtlZXAoc3RydWN0IHZkc29fdGltZWtlZXAgKip0aykKIHsKIAorI2lmIDAKIAlyZXR1cm4g KF9lbGZfYXV4X2luZm8oQVRfVElNRUtFRVAsIHRrLCBzaXplb2YoKnRrKSkpOworI2Vsc2UK KwlyZXR1cm4gKEVOT1NZUyk7CisjZW5kaWYKIH0K --------------80572298F8A81184E6F60AC9-- From owner-freebsd-current@freebsd.org Thu Jan 4 18:27:42 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FDAEEAC3BE for ; Thu, 4 Jan 2018 18:27:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00E0A783AE for ; Thu, 4 Jan 2018 18:27:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x233.google.com with SMTP id v30so3155469iov.7 for ; Thu, 04 Jan 2018 10:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4nux0pmwRDvJ360AaflPd5Vhtn3M+M2iB902u9DCz/g=; b=VR0CcxGB9X52rCzbN67jIYbajkoKSdB0G6Z0+M/9Zywl4Hf/5jAaxdoBUUYBbaLuJQ YQRW45McQZXw7eQ+bq0PZ+rhq21M0YoZR/UUM/arqCUZ1DxrYqB+MhxbRBs1xaUBzHiE RtGNWI97TcNs332etBbwx0QMTA4nXdq//oPP5ZH0p+uOBPYs9WqyQUZ6mhSowJWIfnrH +FxAVVlWeBXTm2hAGg+UR34rv5KtiALZc6rn+kVUIzD5aLE8U+4SDCWwMJMJsYn/ndqQ vbIN/ihxr3TsbKlW65yn6HtBTEKTzY1ovlcmUJnsy1YHhLc5mFPRMNfv+Cc0e4y0BWpg EJsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4nux0pmwRDvJ360AaflPd5Vhtn3M+M2iB902u9DCz/g=; b=dv9Osaj094XdBTupb/HpcoA8LXhybgK7ZMMwhUWwyp7MGZOHQHWoedpT0ojgeSO5z1 chg4W371ohEFxXa2PCPIngUvqFs0Qul8k6knSbgkm0ylS8yxo5nx+FWYalm3bJ0VuLoU 1jn87XhWBmMdhfCim3aI9LpPBHsjGT3gZE0wIKnLFzgsrGy6hHYpjv0H+Ufxzvc8zkZH lGrNbQUZDvjnx8Jw68W83NlhXfqouJ8xjN1m2V7Z0FLHpL7LHENDypqFqGNuX3+EUkzT 9ck8AD+e//w42tz+ynvvsXDCLdHeprECKgnTtb/ZY2zb1y8RnWsOc8l2jC0dHjmi825S vwPw== X-Gm-Message-State: AKwxytcwEa32upsz8OYh3TEFWS2Pa9786OKhl2+3gqZ9tSKLWPeXS1VX mONQf/UP8FpK+otuOlNW/5VtKIAJUZqfFTqKvBmjfg== X-Google-Smtp-Source: ACJfBosMP45t0I5mwT6RWDo7W8SigU9NX6/HRYZwO2cbulJO052o8N/44IAA9J4BOUpKWK6KopuRweNsgY+jHWnfW6U= X-Received: by 10.107.7.67 with SMTP id 64mr522103ioh.296.1515090461328; Thu, 04 Jan 2018 10:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Thu, 4 Jan 2018 10:27:40 -0800 (PST) In-Reply-To: <52b2f48c-332c-8984-838f-4902da0ebc81@7he.at> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <52b2f48c-332c-8984-838f-4902da0ebc81@7he.at> From: blubee blubeeme Date: Fri, 5 Jan 2018 02:27:40 +0800 Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC To: "Klaus P. Ohrhallinger" Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:27:42 -0000 On Fri, Jan 5, 2018 at 2:25 AM, Klaus P. Ohrhallinger wrote: > On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote: > > Hello, > > > > I disabled the ldtsc and ldtscp instructions for usermode on one of my > > production servers: > > > > Oops, RDTSC of course. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I'd love to see if RISC-V is vulnerable to this? I think they are in the best position to capitalize on this clusterfk... From owner-freebsd-current@freebsd.org Thu Jan 4 18:29:50 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1158EEAC6B0 for ; Thu, 4 Jan 2018 18:29:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 AD6F7785ED; Thu, 4 Jan 2018 18:29:49 +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 w04ITefS085064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Jan 2018 20:29:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w04ITefS085064 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w04ITeFk085063; Thu, 4 Jan 2018 20:29:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 Jan 2018 20:29:40 +0200 From: Konstantin Belousov To: David Chisnall Cc: Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: Programmatically cache line Message-ID: <20180104182940.GY1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:29:50 -0000 On Thu, Jan 04, 2018 at 10:03:32AM +0000, David Chisnall wrote: > On 3 Jan 2018, at 22:12, Nathan Whitehorn wrote: > > > > On 01/03/18 13:37, Ed Schouten wrote: > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : > >>>>>> On x86, the CPUID instruction leaf 0x1 returns the information in > >>>>>> %ebx register. > >>>>> Hm, weird. Why don't we extend sysctl to include this info? > >>> For the same reason we do not provide a sysctl to add two integers. > >> I strongly agree with Kostik on this one. Why add stuff to the kernel, > >> if userspace is already capable of extracting this? Adding that stuff > >> to sysctl has the downside that it will effectively introduce yet > >> another FreeBSDism, whereas something generic already exists. > >> > > > > Well, kind of. The userspace version is platform-dependent and not always available: for example, on PPC, you can't do this from userland and we provide a sysctl machdep.cacheline_size to userland. It would be nice to have an MI API. > > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong size. A few big.LITTLE cores have 64-byte cache lines on one cluster and 32-byte on the other. If you query the size from userspace while running on a 64-byte cluster, then issue the zero-cache-line instruction while migrated to the 32-byte cluster, you only clear half the size. Linux works around this by trapping and emulating the instruction to query the cache size and always reporting the size for the smallest cache lines. ARM tells people not to build systems like this, but it doesn???t always stop them. Trapping and emulating is much slower than just providing the information in a shared page, elf aux args vector, or even (often) a system call. Of course MD way is the best way to get such information, just because the meaning of the 'cache line size' exists only in context of the given CPU (micro)architecture. For instance, on PowerPC and ARM you are often concerned with the granularity of the instruction cache flush, but also you might be concerned with the DMA, and these are different concepts of cache. Even on x86, you may care about alignment to avoid false sharing or about CLFLUSH granularity, and these can be different legitimately. Which one to report as 'cache line' ? And you cannot bail out with the max among all constants, because sometimes you really need the min size (for CLFLUSH), and sometime max size (for false sharing). > > To give another example, Linux provides a very cheap way for a userspace process to enquire which core it???s running on. Some more recent high-performance mallocs use this to have a second-layer per-core cache after the per-thread cache for free blocks. Unlike the per-thread cache, the per-core cache does need a lock, but it???s very unlikely to be contended (it will only be contended if either a thread is migrated in between checking and locking, so acquires the wrong CPU???s lock, or if a thread is preempted in the middle of middle of the very brief fill operation). The author of the SuperMalloc paper tried doing this with CPUID and found that it was slower by a sufficient margin to almost entirely offset the benefits of the extra layer of caching. There, RDTSCP is the intended way to get cpu id in userspace, but the use of this instruction requires some minimal OS support. It should be faster than CPUID, since it is not fully serializing. We do not support it only because nobody asked so far. > > Just because userspace can get at the information directly from the hardware doesn???t mean that this is the most efficient or best way for userspace to get at it. > It depends, but single instruction (!) vs syscall comparision makes this discussion silly. > Oh, and some of these things are useful in portable code, so having to write some assembly for every target to get information that the kernel already knows is wasteful. > Required work is to provide the definitions of these interfaces, then they can be implemented in the best way for each architecture. But nobody did that. From owner-freebsd-current@freebsd.org Thu Jan 4 18:38:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 794BFEAD0D8 for ; Thu, 4 Jan 2018 18:38:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39F5278D87; Thu, 4 Jan 2018 18:38:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x236.google.com with SMTP id r6so3413550itr.3; Thu, 04 Jan 2018 10:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iqk5d4Jtldn8bo/CtFrU8kqZobm1MAbISFgR5+e6EEo=; b=g2bCj7tp/9IVLkQVN5gC4vJRBWlSGZywBth/zvadUt3KnuloMiVA9NNgvuuco7wr31 CndZs7nMmfVxavf36fCUPQM19ax6NE840oK3b/haGrzXcj3FMcH+g8BjGZqinVW7o1m4 1ZW/1aTMwi9qdT5agE34cPgsTs1oCNjnL1/bM0aiGo8OfXoW1MmK5SlxjDepy/QWF3wy l2UScPibz4PP7sZ/F23MNAXoBNohjgt9TOCyh6c1T2YTumpZsPQ9jI4s7hnn/CDGXB4Y s7nmZ5V/S7QBaUU80EPwfd8D/WFHYXsx4LT+QEmiGlZ6gddzjCr+y3m6Gv347kZx605u 4sgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iqk5d4Jtldn8bo/CtFrU8kqZobm1MAbISFgR5+e6EEo=; b=fwy51nuAYF/5j/14atUzEBpDSppCPQ253gTTB6gSMNfDpn450cpBPDSGPBIDimpX7n nZrXllLmrtV10bc45OUXKuYlkmOUAd+allJ3jBP3IPf7NjKZamWgBd1lCdlq+BvloQSj gEg0auDPyVlDXUNTCEcSJ/gLJETZAXy9v7GrtaxUpJWLrXZhW1V/JumExPz94nOO+8M0 NQpf7RES2a0TXKKLIhsIYKRmtmQFsk65SWTl6jxVoGqMQuUfRfkEV9o1cP7mLBHyvYIg CUs0GecZo0F3pvPCwXlsm61I4C0uq+eZCvitYMy1KntcXsRjka5KN86BKi+/di8krjXj y7Mg== X-Gm-Message-State: AKGB3mKaOtHcAeuh9xAJ0Yv2erz970x+Zgyi4jm02mNiKPAwXXCVPx6R ejwhpIIRcvWddZKzmT7cVNSjXsfK31yD/TmB+K9LS3Mi X-Google-Smtp-Source: ACJfBot4RZN01u2Bv+SCF13d7y4bQ4QG8MA6TC6zT86Ugt14tRepwDuZzcRxyO1BVdsNFAvwnlHqh6Y2LjO8EeKXij8= X-Received: by 10.36.89.135 with SMTP id p129mr502341itb.100.1515091093408; Thu, 04 Jan 2018 10:38:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.203 with HTTP; Thu, 4 Jan 2018 10:38:12 -0800 (PST) In-Reply-To: <20180104182940.GY1684@kib.kiev.ua> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> <20180104182940.GY1684@kib.kiev.ua> From: blubee blubeeme Date: Fri, 5 Jan 2018 02:38:12 +0800 Message-ID: Subject: Re: Programmatically cache line To: Konstantin Belousov Cc: David Chisnall , Nathan Whitehorn , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:38:14 -0000 On Fri, Jan 5, 2018 at 2:29 AM, Konstantin Belousov wrote: > On Thu, Jan 04, 2018 at 10:03:32AM +0000, David Chisnall wrote: > > On 3 Jan 2018, at 22:12, Nathan Whitehorn > wrote: > > > > > > On 01/03/18 13:37, Ed Schouten wrote: > > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : > > >>>>>> On x86, the CPUID instruction leaf 0x1 returns the information in > > >>>>>> %ebx register. > > >>>>> Hm, weird. Why don't we extend sysctl to include this info? > > >>> For the same reason we do not provide a sysctl to add two integers. > > >> I strongly agree with Kostik on this one. Why add stuff to the kernel, > > >> if userspace is already capable of extracting this? Adding that stuff > > >> to sysctl has the downside that it will effectively introduce yet > > >> another FreeBSDism, whereas something generic already exists. > > >> > > > > > > Well, kind of. The userspace version is platform-dependent and not > always available: for example, on PPC, you can't do this from userland and > we provide a sysctl machdep.cacheline_size to userland. It would be nice to > have an MI API. > > > > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong > size. A few big.LITTLE cores have 64-byte cache lines on one cluster and > 32-byte on the other. If you query the size from userspace while running > on a 64-byte cluster, then issue the zero-cache-line instruction while > migrated to the 32-byte cluster, you only clear half the size. Linux works > around this by trapping and emulating the instruction to query the cache > size and always reporting the size for the smallest cache lines. ARM tells > people not to build systems like this, but it doesn???t always stop them. > Trapping and emulating is much slower than just providing the information > in a shared page, elf aux args vector, or even (often) a system call. > > Of course MD way is the best way to get such information, just because the > meaning of the 'cache line size' exists only in context of the given CPU > (micro)architecture. For instance, on PowerPC and ARM you are often > concerned > with the granularity of the instruction cache flush, but also you might be > concerned with the DMA, and these are different concepts of cache. > > Even on x86, you may care about alignment to avoid false sharing or > about CLFLUSH granularity, and these can be different legitimately. > Which one to report as 'cache line' ? > > And you cannot bail out with the max among all constants, because sometimes > you really need the min size (for CLFLUSH), and sometime max size (for > false sharing). > > > > > To give another example, Linux provides a very cheap way for a userspace > process to enquire which core it???s running on. Some more recent > high-performance mallocs use this to have a second-layer per-core cache > after the per-thread cache for free blocks. Unlike the per-thread cache, > the per-core cache does need a lock, but it???s very unlikely to be > contended (it will only be contended if either a thread is migrated in > between checking and locking, so acquires the wrong CPU???s lock, or if a > thread is preempted in the middle of middle of the very brief fill > operation). The author of the SuperMalloc paper tried doing this with > CPUID and found that it was slower by a sufficient margin to almost > entirely offset the benefits of the extra layer of caching. > > There, RDTSCP is the intended way to get cpu id in userspace, but the use > of this instruction requires some minimal OS support. It should be faster > than CPUID, since it is not fully serializing. We do not support it only > because nobody asked so far. > > > > > Just because userspace can get at the information directly from the > hardware doesn???t mean that this is the most efficient or best way for > userspace to get at it. > > > It depends, but single instruction (!) vs syscall comparision makes this > discussion silly. > > > Oh, and some of these things are useful in portable code, so having to > write some assembly for every target to get information that the kernel > already knows is wasteful. > > > Required work is to provide the definitions of these interfaces, then they > can be implemented in the best way for each architecture. But nobody did > that. > Initially I was "asking" to see if these facilities were available so that I didn't have to go do some hack job that would be brittle or reinvent the wheel. My use case for getting the cache lines was to prevent false sharing. I should've been more clear about that in my initial email but, I didn't know all these other people were interested in this issue as well. since I'd like the cache line sizes to prevent false sharing that's my use case. Does anyone else have any use cases that they would like to propose? Once we have come to some agreement on what features they need, then we can work out the interfaces and get the work done on implementation? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Jan 4 18:51:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 533FEEAE018 for ; Thu, 4 Jan 2018 18:51:16 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D64A27958E for ; Thu, 4 Jan 2018 18:51:15 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id p6so2390548wrd.0 for ; Thu, 04 Jan 2018 10:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+sewNVnwHl36GsZl7mLuHIsmaJYzN5Tyz8K6Is9tnnA=; b=WkI4V+iiikNisK3yblKb6ZeAkapQr+/faRepJnFRHGxcjZifhwyGTdcL6PdaqWaUdC mFP3nHd+H5O7dKZFFj1YlslA4YFiqCI6eLpq5RvfEUx0eXgpHuSW84xCKAtviz1y2GOO uFGVcijDaEDudCTF7eWnmK6RTA3UiZpfJ4s4mYkBoMAOSvndwkocgsddFYbL/cLSXuxm nmfgFaD1VvDFpFG5CgbUm3tgXDUpaOO7UC8gHprO0btYZOjoSz0oxK/7ZLV5w8r6irdT 3eDAiaYGmF1dN1pMy2x4iddyeumzQBmE7jFE9qx2ZFQ5csZSG0TZESrbQBF4AxAZKtMF 6f3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+sewNVnwHl36GsZl7mLuHIsmaJYzN5Tyz8K6Is9tnnA=; b=Liq22TJVNQzInHTwp1bk6y4A7tHk4l+nzsAZnzkPk1tH9CK5XmDiHkFacPcRdM+DY2 L3ZtDAtFI+P1r6s64joNuO1nantGoM+jGMlLiQUG9x/0zd3+bNWqraRZFB6u0uK7P3p9 KXdn9MXkBdM8Cz8Df/TmlJoQwnSDkiPpBeaBlsaDJ9gwCN3cdLqjl/IkWsPlEklSTFeS TswT8S0XooE9BV7M58EuVTdErftjt2cV9j18VqHXuJiHDyz922ietPTGnmYilSTx/Ahq T+v1pN4laJ5n6dBbZkZ62uVdjPtQ4Tu5OyoaeLZP426KlwzVS17pSiAqsjGMBGhobLFl dtKw== X-Gm-Message-State: AKGB3mLD0psf9h+D2B55xAnK5OyGFtVm9GJPkWhmSFAbGRY+0rYRnLpQ t5SXgCPB30f86TlrWDhHvGUwzg== X-Google-Smtp-Source: ACJfBosgy5rMzdVPDBeyiJmmKEQzQYomJWzzTqEQffLMcPJbWXLqccQcBE8jTvHUihlatBWzy9kg0Q== X-Received: by 10.223.176.131 with SMTP id i3mr495436wra.120.1515091873932; Thu, 04 Jan 2018 10:51:13 -0800 (PST) Received: from [192.168.178.20] (p5B36C250.dip0.t-ipconnect.de. [91.54.194.80]) by smtp.googlemail.com with ESMTPSA id o18sm3193536wrg.59.2018.01.04.10.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 10:51:13 -0800 (PST) Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: "Klaus P. Ohrhallinger" , freebsd-current@freebsd.org References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= Message-ID: Date: Thu, 4 Jan 2018 19:51:12 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:51:16 -0000 On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote: > All PoC code I have seen today relies on those instructions. > Is there any other way to measure the memory/cache access times ? It is possible to emulate a high resolution counter with a thread that continuously increments a variable [1]. This is the reason why browser vendors are currently disabling the SharedArrayBuffer feature [2]. [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156 [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ From owner-freebsd-current@freebsd.org Thu Jan 4 18:52:34 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ADEAEAE1DD for ; Thu, 4 Jan 2018 18:52:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDFF97990A for ; Thu, 4 Jan 2018 18:52:33 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6bed:b00:8d8b:6d16:fc66:6692] (p200300CD6BED0B008D8B6D16FC666692.dip0.t-ipconnect.de [IPv6:2003:cd:6bed:b00:8d8b:6d16:fc66:6692]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C667F72106C26; Thu, 4 Jan 2018 19:52:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> From: Michael Tuexen In-Reply-To: <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> Date: Thu, 4 Jan 2018 19:52:19 +0100 Cc: Warner Losh , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <6C2F2C0A-D075-4DF1-88E3-64CE31E016F9@freebsd.org> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:52:34 -0000 > On 4. Jan 2018, at 12:14, O. Hartmann wrote: >=20 > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen wrote: >=20 >>> On 31. Dec 2017, at 02:45, Warner Losh wrote: >>>=20 >>> On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann = wrote: >>>=20 >>>> On most recent CURRENT I face the error shwon below on /tmp = filesystem >>>> (UFS2) residing >>>> on a Samsung 850 Pro SSD: >>>>=20 >>>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 !=3D >>>> bp: 0xd9fba319 >>>> handle_workitem_freefile: got error 5 while accessing filesystem >>>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >>>> !=3D bp: 0xd9fba319 >>>> handle_workitem_freefile: got error 5 while accessing filesystem >>>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >>>> !=3D bp: 0xd9fba319 >>>> handle_workitem_freefile: got error 5 while accessing filesystem >>>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >>>> !=3D bp: 0xd9fba319 >>>> handle_workitem_freefile: got error 5 while accessing filesystem >>>> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: = 0x4515d2a3 >>>> !=3D bp: 0xd9fba319 >>>> handle_workitem_freefile: got error 5 while accessing filesystem >>>>=20 >>>> I've already formatted the /tmp filesystem, but obviously without = any >>>> success. >>>>=20 >>>> Since I face such strange errors also on NanoBSD images dd'ed to SD = cards, >>>> I guess there >>>> is something fishy ... =20 >>>=20 >>>=20 >>> It indicates a problem. We've seen these 'corruptions' on data in = motion at >>> work, but I hacked fsck to report checksum mismatches (it silently = corrects >>> them today) and we've not seen any mismatch when we unmount and fsck = the >>> filesystem. =20 >> Not sure this helps: But we have seen this also after system panics >> when having soft update journaling enabled. Having soft update = journaling >> disabled, we do not observed this after several panics. >> Just to be clear: The panics are not related to this issue, >> but to other network development we do. >>=20 >> You can check using tunefs -p devname if soft update journaling is = enabled or >> not. >=20 > In all cases I reported in earlier and now, softupdates ARE ENABLED on = all > partitions in question (always GPT, in my cases also all on flash = based > devices, SD card and/or SSD). OK. That seems to be consistent. Here is the config I'm using on m-SATA = SSDs and I'm NOT experiencing the problem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) =20 This was the config I was experiencing the problem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) =20 So "soft updates" are enabled on both configs, but "soft update = journaling" is different. Maybe this helps in nailing down the problem. Best regards Michael >=20 >>=20 >> Best regards >> Michael >>>=20 >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" =20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@freebsd.org Thu Jan 4 19:59:54 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4A48EB262D for ; Thu, 4 Jan 2018 19:59:54 +0000 (UTC) (envelope-from k@7he.at) Received: from smtp-01.sil.at (smtp-01-5.sil.at [78.142.186.29]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A355B7CD75 for ; Thu, 4 Jan 2018 19:59:54 +0000 (UTC) (envelope-from k@7he.at) Received: from mx.7he.at ([86.59.13.138]) by smtp-01.sil.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1eXBg7-00079a-K8; Thu, 04 Jan 2018 20:59:51 +0100 Received: from [192.168.6.60] ([93.83.242.219]) by mx.7he.at (8.15.2/8.15.2) with ESMTPS id w04Jxn04044317 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Jan 2018 20:59:50 +0100 (CET) (envelope-from k@7he.at) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx.7he.at Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: freebsd-current@freebsd.org, jan.kokemueller@gmail.com References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> From: "Klaus P. Ohrhallinger" Message-ID: Date: Thu, 4 Jan 2018 20:59:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.5 required=5.0 tests=HELO_MISC_IP,RDNS_NONE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.7he.at X-Scan-Signature: 2eb3c689388ef5a45072784d1e8a9ce2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:59:55 -0000 On 04.01.2018 19:51, Jan Kokemüller wrote: > It is possible to emulate a high resolution counter with a thread that > continuously increments a variable [1]. This is the reason why browser > vendors are currently disabling the SharedArrayBuffer feature [2]. > > [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156 > [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ I tried the phtread example from [1] but even with some tweaking is does not work at all. This is a multiprocessor system, with moderate load. As far as I understand the matter, it can only work if both threads share the same cpu cache, otherwise the counter variable is either never up-to-date, or has to be fetched and stored from/to memory, which is way too slow for this purpose. Any suggestions ? --- CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) From owner-freebsd-current@freebsd.org Thu Jan 4 21:07:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 201B6EB731D for ; Thu, 4 Jan 2018 21:07:33 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE99F17B4 for ; Thu, 4 Jan 2018 21:07:32 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject; s=201508; t=1515100050; bh=jMDl2asf UZjV2UtagU83SwXEq7WMrDn0IxrxwIsCgCs=; b=RCKYR6QYg0aV0PanPu+WJJFP bRt/jXkk3BFRoiIxA1OthISjVc5lVJt1NbYuJ44rDvux1B3n1j4SB/SHWd0nn/CA F2aib8rB+hEORqSWCat9IGiRN4hsPnz1C1MvUnIexj92tZ6A1zOtNeuK5aH2tnm7 SVZavEe7RYPjaykfgVw= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 9F3AC934C; Thu, 4 Jan 2018 16:07:30 -0500 (EST) Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: "Klaus P. Ohrhallinger" , freebsd-current@freebsd.org, jan.kokemueller@gmail.com References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492; url=0442D492 Message-ID: <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> Date: Thu, 4 Jan 2018 16:07:19 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 21:07:33 -0000 On 01/04/18 14:59, Klaus P. Ohrhallinger wrote: > On 04.01.2018 19:51, Jan Kokemüller wrote: > >> It is possible to emulate a high resolution counter with a thread that >> continuously increments a variable [1]. This is the reason why browser >> vendors are currently disabling the SharedArrayBuffer feature [2]. >> >> [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156 >> [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ > > I tried the phtread example from [1] but even with some tweaking is does > not work at all. > > This is a multiprocessor system, with moderate load. > > As far as I understand the matter, it can only work if both threads > share the same cpu cache, otherwise the counter variable is either never > up-to-date, or has to be fetched and stored from/to memory, which is way > too slow for this purpose. > > Any suggestions ? > > --- > > CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz > K8-class CPU) > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) Interestingly, the Xeon 5400 series is not listed as vulnerable in the Intel documentation where the 5500 and 5600s are; I checked as I have a bunch of E5440s in service. https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr imb From owner-freebsd-current@freebsd.org Thu Jan 4 20:43:06 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 625BDEB5B73 for ; Thu, 4 Jan 2018 20:43:06 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 2D097804FA for ; Thu, 4 Jan 2018 20:43:05 +0000 (UTC) (envelope-from leonardofogel@yahoo.com.br) X-YMail-OSG: RbmyjDUVM1kJIDKJJzK_Aizm7rCEaVE7FjcKOxUEGQGJPkfcDnAy.JXg_l.nmBX MCsfeF7P_qkSYgFvwksaMyPiBpYMRWQYTaqoKDgG1_Xpbw9JBUAGnxzhrmtXnaN_UjNrShpts7Ih hnskEyPmqrx.3vwpeBXwbOp43G1iibcx0TBtHm59PUipkz1zr.x267J_ahO4uRPfbfvgq.EQ7flo z7npNMgeEHkVLv7AI4LYWevwZXLpkDSn_wv11_m7QxzaCeD2LpFJddTq4zPXxc2fvCpK06WY_foS g7vzBPbB5jar8w.IHWwaCeLaUi5_ySo0LZoE243KUuS7fz9Ny4hrD5kiXD6ukFxD8eFFiX3XAJCt 9plPcALsnUep0IPP4LLcNDIT8LA_N5RRIVdrl83oVTwMQgbTVLVP_3B3vCBI8sCiTEPKkzyj98Cv to_1eVGOqeOwz0SGuQs16BIbHE5l6ZVszs6U1MagjxVzLADW.89Oe1QGhWsKJhi1SmsQA01ipoPh 7JEjPWFpxVg.odsdKPw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Jan 2018 20:43:03 +0000 Date: Thu, 4 Jan 2018 20:42:58 +0000 (UTC) From: Leonardo Fogel Reply-To: Leonardo Fogel To: Message-ID: <1106737441.618504.1515098578398@mail.yahoo.com> Subject: To which list should I submit a patch? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1106737441.618504.1515098578398.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11150 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 X-Mailman-Approved-At: Thu, 04 Jan 2018 21:17:09 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 20:43:06 -0000 Hi, I have written a short patch that replaces the legacy interface make_dev(9) with the newer one make_dev_s(9) in the DEV_MODULE(9) man page and in an example that is included in the base. I do not know if I should submit it as a PR to "Base System" (since they are in the base tree) or to "Documentation". Please, could you kindly give me some suggestion? Thank you for your time. Index: src/share/examples/kld/cdev/module/cdevmod.c =================================================================== --- src/share/examples/kld/cdev/module/cdevmod.c (revision 327530) +++ src/share/examples/kld/cdev/module/cdevmod.c (working copy) @@ -109,6 +109,7 @@ cdev_load(module_t mod, int cmd, void *arg) { int err = 0; + struct make_dev_args mda; switch (cmd) { case MOD_LOAD: @@ -120,9 +121,15 @@ printf("Copyright (c) 1998\n"); printf("Rajesh Vaidheeswarran\n"); printf("All rights reserved\n"); - sdev = make_dev(&my_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "cdev"); - break; /* Success*/ + make_dev_args_init(&mda); + mda.mda_devsw = &my_devsw; + mda.mda_uid = UID_ROOT; + mda.mda_gid = GID_WHEEL; + mda.mda_mode = 0600; + err = make_dev_s(&mda, &sdev, "cdev"); + break; + case MOD_UNLOAD: printf("Unloaded kld character device driver\n"); destroy_dev(sdev); Index: src/share/man/man9/DEV_MODULE.9 =================================================================== --- src/share/man/man9/DEV_MODULE.9 (revision 327530) +++ src/share/man/man9/DEV_MODULE.9 (working copy) @@ -58,11 +58,13 @@ .Xr DECLARE_MODULE 9 for more information). The event handler is supposed to create the device with -.Fn make_dev +.Fn make_dev_s on load and to destroy it when it is unloaded using .Fn destroy_dev . .Sh EXAMPLES .Bd -literal +#include +#include #include #include @@ -74,11 +76,17 @@ foo_load(module_t mod, int cmd, void *arg) { int err = 0; + struct make_dev_args mda; switch (cmd) { case MOD_LOAD: - sdev = make_dev(&foo_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo"); - break; /* Success*/ + make_dev_args_init(&mda); + mda.mda_devsw = &foo_devsw; + mda.mda_uid = UID_ROOT; + mda.mda_gid = GID_WHEEL; + mda.mda_mode = 0600; + err = make_dev_s(&mda, &sdev, "foo"); + break; case MOD_UNLOAD: case MOD_SHUTDOWN: From owner-freebsd-current@freebsd.org Thu Jan 4 21:43:43 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C077EB9757 for ; Thu, 4 Jan 2018 21:43:43 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E93B23218 for ; Thu, 4 Jan 2018 21:43:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f45.google.com with SMTP id d16so3988202itj.1 for ; Thu, 04 Jan 2018 13:43:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=p2DL1tsuQhfQn36PK12GvRfigyQoV/9DuqLHg0d8YVQ=; b=VCWVWqUS7Ml9UMCd2D8XVuK1ZXfE1aobtQYdJKFsgTD/0o/A3+gZm/ug0MikbNWrq1 PuMZIKsdz9KEhC5b2YG97J12btt5d0WR1ojoqSWcp8+X243zVO+AsZz9Dv5I75ntjhjo xBeWbJrLMDpIUOYRNkCw28Ycw0vitrDINJOxT1mZTGx0xjt3aOLCLNF0WuEPp2mgjOVK WdTYHW8nr5HljwXte/vyA8QHyK+bs+kYPV5I/mBoguXXPumxk0+YJ4FhGl9RAKEAHxYJ DV+KhKdNDSMcjFhyB9ZsDka7I41B8IARPZ7sfGrXwgoRmZCAGQyT6rW/0t8km0jIoKBP q0Dg== X-Gm-Message-State: AKGB3mLUxNFPqujOOT1QrQEgsfyLAq6CZ93qKoGrPbrBmFTuWvr77Np2 6h3aH1vc9We9ZuFH7ua5J1cd0Z3E X-Google-Smtp-Source: ACJfBotQ7Gt62N/7vPyAR6ar+/vFfh21juVcW9ufhGgKCHqica0Dn7OlsKkusK/IZbVZraSxM8SMeQ== X-Received: by 10.36.92.79 with SMTP id q76mr1067080itb.153.1515102216221; Thu, 04 Jan 2018 13:43:36 -0800 (PST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id x82sm2692240itb.36.2018.01.04.13.43.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 13:43:35 -0800 (PST) Received: by mail-io0-f175.google.com with SMTP id 14so3720212iou.2 for ; Thu, 04 Jan 2018 13:43:35 -0800 (PST) X-Received: by 10.107.132.88 with SMTP id g85mr1113146iod.117.1515102215612; Thu, 04 Jan 2018 13:43:35 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.15.193 with HTTP; Thu, 4 Jan 2018 13:43:35 -0800 (PST) In-Reply-To: <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> From: Conrad Meyer Date: Thu, 4 Jan 2018 13:43:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: Michael Butler Cc: "Klaus P. Ohrhallinger" , freebsd-current , jan.kokemueller@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 21:43:43 -0000 Possibly because Xeon 5400 dates to 2007 =E2=80=94 it may have less advance= d speculative / out-of-order execution and may not have the same branch prediction algorithm as Haswell. On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler wrote: > On 01/04/18 14:59, Klaus P. Ohrhallinger wrote: >> On 04.01.2018 19:51, Jan Kokem=C3=BCller wrote: >> >>> It is possible to emulate a high resolution counter with a thread that >>> continuously increments a variable [1]. This is the reason why browser >>> vendors are currently disabling the SharedArrayBuffer feature [2]. >>> >>> [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb= 6#gistcomment-2311156 >>> [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-n= ew-class-timing-attack/ >> >> I tried the phtread example from [1] but even with some tweaking is does >> not work at all. >> >> This is a multiprocessor system, with moderate load. >> >> As far as I understand the matter, it can only work if both threads >> share the same cpu cache, otherwise the counter variable is either never >> up-to-date, or has to be fetched and stored from/to memory, which is way >> too slow for this purpose. >> >> Any suggestions ? >> >> --- >> >> CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz >> K8-class CPU) >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> FreeBSD/SMP: 2 package(s) x 4 core(s) > > Interestingly, the Xeon 5400 series is not listed as vulnerable in the > Intel documentation where the 5500 and 5600s are; I checked as I have a > bunch of E5440s in service. > > https://security-center.intel.com/advisory.aspx?intelid=3DINTEL-SA-00088&= languageid=3Den-fr > > imb > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Thu Jan 4 21:44:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8034EB98BB for ; Thu, 4 Jan 2018 21:44:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 924D4339E for ; Thu, 4 Jan 2018 21:44:55 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f52.google.com with SMTP id m11so2740064iti.1 for ; Thu, 04 Jan 2018 13:44:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=e2rXx4vRf4nUDlPA8b0/m7JQtVKF30q56+e3MywJ2wU=; b=rG9A66EuNFX4p8Cgc4O15bIdkdzibJGzbkLWz5NONcN+hcmAUE/WjmVVAll10DUMcJ 5ebA/jrI27VrRuNSDg9Uch+BV8kYLJuepm+/Q0YswKbhuuoHuSybrezfWEUBaa3nl8Q2 7Rg9ok1W3Y8gnMU6Hmea890lTgZGqRQAOAMOrDMAd3daEW5nm2QJVjHfe+BJzsI2LULE hbqXFPm8bYnwIDOfQQve5g/d2gGqBOIMeuBmkBDKw2akbHKvCLH6fVpeCaEG62EAPqf/ /z33xDx9wMpGuMY/0uSS43wZPCRoSFMoc7crknOvOgbVJD2fEKn/QZMgFEfAHS3/IzVZ 85Rw== X-Gm-Message-State: AKGB3mIUCAUkQcisTY7G3U4c2/KEBUF5BHpeNKoqHUwSzoN/ht36uUoq 0K/wrkl9YfSgfjEUj47RQ+OWAprP X-Google-Smtp-Source: ACJfBosCH1tQswstkROUX5JAoZO5peTB3FyDJS7KJe0O7sbsGexrMHympXtQp5U/YjoohUNYkxwD6w== X-Received: by 10.36.69.164 with SMTP id c36mr1079786itd.27.1515102289124; Thu, 04 Jan 2018 13:44:49 -0800 (PST) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id 15sm2546657iti.15.2018.01.04.13.44.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 13:44:48 -0800 (PST) Received: by mail-it0-f50.google.com with SMTP id d16so3991356itj.1 for ; Thu, 04 Jan 2018 13:44:48 -0800 (PST) X-Received: by 10.36.20.73 with SMTP id 70mr1030236itg.55.1515102288327; Thu, 04 Jan 2018 13:44:48 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.15.193 with HTTP; Thu, 4 Jan 2018 13:44:47 -0800 (PST) In-Reply-To: <1106737441.618504.1515098578398@mail.yahoo.com> References: <1106737441.618504.1515098578398.ref@mail.yahoo.com> <1106737441.618504.1515098578398@mail.yahoo.com> From: Conrad Meyer Date: Thu, 4 Jan 2018 13:44:47 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: To which list should I submit a patch? To: Leonardo Fogel Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 21:44:56 -0000 IMO, either is fine. I think documentation may refer to docs outside of the src tree, whereas this is in the src tree. Thanks for the submission. Best, Conrad On Thu, Jan 4, 2018 at 12:42 PM, Leonardo Fogel wrote: > > > Hi, > I have written a short patch that replaces the legacy interface make_dev(= 9) with the newer one make_dev_s(9) in the DEV_MODULE(9) man page and in an= example that is included in the base. I do not know if I should submit it = as a PR to "Base System" (since they are in the base tree) or to "Documenta= tion". > Please, could you kindly give me some suggestion? > Thank you for your time. > > Index: src/share/examples/kld/cdev/module/cdevmod.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- src/share/examples/kld/cdev/module/cdevmod.c (revision 327530) > +++ src/share/examples/kld/cdev/module/cdevmod.c (working copy) > @@ -109,6 +109,7 @@ > cdev_load(module_t mod, int cmd, void *arg) > { > int err =3D 0; > + struct make_dev_args mda; > > switch (cmd) { > case MOD_LOAD: > @@ -120,9 +121,15 @@ > printf("Copyright (c) 1998\n"); > printf("Rajesh Vaidheeswarran\n"); > printf("All rights reserved\n"); > - sdev =3D make_dev(&my_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "cdev"= ); > - break; /* Success*/ > > + make_dev_args_init(&mda); > + mda.mda_devsw =3D &my_devsw; > + mda.mda_uid =3D UID_ROOT; > + mda.mda_gid =3D GID_WHEEL; > + mda.mda_mode =3D 0600; > + err =3D make_dev_s(&mda, &sdev, "cdev"); > + break; > + > case MOD_UNLOAD: > printf("Unloaded kld character device driver\n"); > destroy_dev(sdev); > Index: src/share/man/man9/DEV_MODULE.9 > =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 > --- src/share/man/man9/DEV_MODULE.9 (revision 327530) > +++ src/share/man/man9/DEV_MODULE.9 (working copy) > @@ -58,11 +58,13 @@ > .Xr DECLARE_MODULE 9 > for more information). > The event handler is supposed to create the device with > -.Fn make_dev > +.Fn make_dev_s > on load and to destroy it when it is unloaded using > .Fn destroy_dev . > .Sh EXAMPLES > .Bd -literal > +#include > +#include > #include > #include > > @@ -74,11 +76,17 @@ > foo_load(module_t mod, int cmd, void *arg) > { > int err =3D 0; > + struct make_dev_args mda; > > switch (cmd) { > case MOD_LOAD: > - sdev =3D make_dev(&foo_devsw, 0, UID_ROOT, GID_WHEEL, 0600, "foo= "); > - break; /* Success*/ > + make_dev_args_init(&mda); > + mda.mda_devsw =3D &foo_devsw; > + mda.mda_uid =3D UID_ROOT; > + mda.mda_gid =3D GID_WHEEL; > + mda.mda_mode =3D 0600; > + err =3D make_dev_s(&mda, &sdev, "foo"); > + break; > > case MOD_UNLOAD: > case MOD_SHUTDOWN: > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Fri Jan 5 02:46:59 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D5B0EA92EA for ; Fri, 5 Jan 2018 02:46:59 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (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 2B9FE6F729; Fri, 5 Jan 2018 02:46:58 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BhqBFt/KTUPgWaRcfaZ0vYFAbN4dQSYZ8n9si4Inx2s=; b=oOcVbJqBi+kBaNiYwXn2HtuVjZ Qts/qJ1DhMHNQEXgBDi4IPG4FR0z2AYtxJGYBqusx1lpUBH9rv3WXq23sbEWMTML633a34D0G5QqN Zk6bldyjgn9NYTLppf+luNDLhXZFRnbyU85t903aRNmIm9NPcPtqqpL412nGSRPr3pOJjheDQdneY HUd3CWZDf+i2BHT8ogir1I8M+uDID2UPu/iFKi8CcfTa5CLXG5bo51Ru0eSNvklt2Sb3P633dZZvQ maXvSKVRUAgfzNGwvbHa9Ykb53/5btgWCusIGKnpfXl4cLArrVEEV9BeYQViPaFh5EijfOTjSwo1/ 2kja0LVQ==; Received: from [136.62.171.86] (port=49797 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eXI25-002Po6-AD; Thu, 04 Jan 2018 21:46:57 -0500 From: Jon Brawn Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_02CA1613-A45C-4ED5-BEAA-8CE17DA6E9BB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Programmatically cache line Date: Thu, 4 Jan 2018 20:46:55 -0600 In-Reply-To: <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> Cc: Nathan Whitehorn , freebsd-current@freebsd.org To: David Chisnall References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 02:46:59 -0000 --Apple-Mail=_02CA1613-A45C-4ED5-BEAA-8CE17DA6E9BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 4, 2018, at 4:03 AM, David Chisnall = wrote: >=20 > On 3 Jan 2018, at 22:12, Nathan Whitehorn = wrote: >>=20 >> On 01/03/18 13:37, Ed Schouten wrote: >>> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov = : >>>>>>> On x86, the CPUID instruction leaf 0x1 returns the information = in >>>>>>> %ebx register. >>>>>> Hm, weird. Why don't we extend sysctl to include this info? >>>> For the same reason we do not provide a sysctl to add two integers. >>> I strongly agree with Kostik on this one. Why add stuff to the = kernel, >>> if userspace is already capable of extracting this? Adding that = stuff >>> to sysctl has the downside that it will effectively introduce yet >>> another FreeBSDism, whereas something generic already exists. >>>=20 >>=20 >> Well, kind of. The userspace version is platform-dependent and not = always available: for example, on PPC, you can't do this from userland = and we provide a sysctl machdep.cacheline_size to userland. It would be = nice to have an MI API. >=20 > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong = size. A few big.LITTLE cores have 64-byte cache lines on one cluster = and 32-byte on the other. If you query the size from userspace while = running on a 64-byte cluster, then issue the zero-cache-line instruction = while migrated to the 32-byte cluster, you only clear half the size. = Linux works around this by trapping and emulating the instruction to = query the cache size and always reporting the size for the smallest = cache lines. ARM tells people not to build systems like this, but it = doesn=E2=80=99t always stop them. Trapping and emulating is much slower = than just providing the information in a shared page, elf aux args = vector, or even (often) a system call. >=20 > To give another example, Linux provides a very cheap way for a = userspace process to enquire which core it=E2=80=99s running on. Some = more recent high-performance mallocs use this to have a second-layer = per-core cache after the per-thread cache for free blocks. Unlike the = per-thread cache, the per-core cache does need a lock, but it=E2=80=99s = very unlikely to be contended (it will only be contended if either a = thread is migrated in between checking and locking, so acquires the = wrong CPU=E2=80=99s lock, or if a thread is preempted in the middle of = middle of the very brief fill operation). The author of the SuperMalloc = paper tried doing this with CPUID and found that it was slower by a = sufficient margin to almost entirely offset the benefits of the extra = layer of caching. =20 >=20 > Just because userspace can get at the information directly from the = hardware doesn=E2=80=99t mean that this is the most efficient or best = way for userspace to get at it. >=20 > Oh, and some of these things are useful in portable code, so having to = write some assembly for every target to get information that the kernel = already knows is wasteful. >=20 > David This idea of Arm big.LITTLE systems having cache lines of different = lengths really, really bothers me - how on earth is the cache coherency = supposed to work in such a system? I doubt the usual cache coherency = protocols would work - probably need a really MESSY protocol to deal = with this config :-) Jon.= --Apple-Mail=_02CA1613-A45C-4ED5-BEAA-8CE17DA6E9BB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAx MDUwMjQ2NTVaMCMGCSqGSIb3DQEJBDEWBBR5wxRVO7kA0kX2OvnGE3W7yByRRTCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBAFhOFrWp h4kOEQR6OD5azqDg1ZM3B8nG2VS6zlKMRBhGQ2UGXRSuy1nzHTQ8Caed+3uX3W8O4s3GCNQSrpJl Z44OW+DUDp4rKpSqAp2KVY9x9ttGrMcV8Mb+Fl5FjZ39YEPlj9GPkr+sTklSVnJEugS7Ry9iWA/P K1VFB8kSgbE7cq3p4+RC62Reqhhl4ldAYO/lKBXBEtX0e+rgWSs2Hj+/u7XeIydydNOpdFU5N+9G ABCb37ALh9n8s0Q7eZ7w3vFWPKTW1YG/rePXe1X0YhYw+ls4494ZrI0FGc6j+Qcsf7b6rs/0GtoI ZgDCdPOkQrlhT3pcH0f1zl3AgwMP+RMAAAAAAAA= --Apple-Mail=_02CA1613-A45C-4ED5-BEAA-8CE17DA6E9BB-- From owner-freebsd-current@freebsd.org Fri Jan 5 03:09:09 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E35C7EAAD08 for ; Fri, 5 Jan 2018 03:09:09 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (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 AA1B170F62 for ; Fri, 5 Jan 2018 03:09:09 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=Message-Id:In-Reply-To:To:References:Date:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0to1dXh7zu6iQHC2HahMe8BH+G7HBDEvGCJ8whuQaYE=; b=BTchLD8K5Jqw/5VVbBX3qQ5FYu kzRY9GnQiRx6Qk3KSkJCshDStXISNBHA/2vz8dTP6vva4p/x+98iORAFQtGk3iJwxSgO5DQ8CWuHd sBet8vLNRkDA0MjwrVGdFMfHvO5Y18tdvp9MNBVUUzjMBZGirXco7G4KC2EcBnif4PKfQsmiAoHit hicb2ysoLNnxyCSt1/r0czqnlTePrrFS/P527/gWSqQb2gJTLbH9Rh+a+5cosCIu48WnTxOIdYSxc 5VlQjb3me77o1guXue+0jcOLWY82jk7HsaF6qJZv/potAsArSZG/2udr+hluXFQq4H2bW3sG61Sds PwSItN6g==; Received: from [136.62.171.86] (port=49549 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eXHZ9-002LGv-Vg for freebsd-current@freebsd.org; Thu, 04 Jan 2018 21:17:04 -0500 From: Jon Brawn Content-Type: multipart/signed; boundary="Apple-Mail=_AFD6C8DB-1309-4187-BB27-80B2AAD7A71E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Intel CPU design flaw - FreeBSD affected? Information from Arm Date: Thu, 4 Jan 2018 20:17:01 -0600 References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> To: freebsd-current In-Reply-To: Message-Id: <722BFCC9-7EF8-4C07-8B9B-5538C032F629@brawn.org> X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 03:09:10 -0000 --Apple-Mail=_AFD6C8DB-1309-4187-BB27-80B2AAD7A71E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wotcha! My employer, Arm, have made the following website available to help with = deciding what to do about this security issue. http://www.arm.com/security-update Note: I am not writing here as a representative of Arm, and cannot = provide further information about this issue. I would encourage you to = read all the pages and the white paper thoroughly to best understand = this issue as it relates to working with Arm processors. Jon.= --Apple-Mail=_AFD6C8DB-1309-4187-BB27-80B2AAD7A71E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAx MDUwMjE3MDJaMCMGCSqGSIb3DQEJBDEWBBRILOjs9lnsDbbQxIOy9TjGCRKxkDCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBAEXSMalo kMQ8banmriTi2wNWmdx4TT5/FJvwMDWC1332SpMe0mN6+lBym8dMA+K0h7fMu5AqPrG5gfYs9XC3 fbwJyDkMvjswezopBTGSJ4G/AdugHIUzCdBHGe4h4Ovh5FfHJMMeV6lYfCYZJEGlX9BauTTpI76J SJEhqLVEtkKtmu6efXN1tsN6jIxnQ8Rux613LXP4HdIdJCymckj1dQnGuJIwW76Gcte0FzTTa+8t QA98c++CiEmx0haZqZpXjGWRuuVkmSiflNCwH12xcWNly/J15tZQCQ9kDIyuCGpKMOZUI12QyArQ 0+F964rBVeF7yiix+LGL9KMWNVHVDocAAAAAAAA= --Apple-Mail=_AFD6C8DB-1309-4187-BB27-80B2AAD7A71E-- From owner-freebsd-current@freebsd.org Fri Jan 5 03:13:14 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DFF0EAB393 for ; Fri, 5 Jan 2018 03:13:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-97.reflexion.net [208.70.210.97]) (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 CF9CB714DB for ; Fri, 5 Jan 2018 03:13:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17594 invoked from network); 5 Jan 2018 03:13:06 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 03:13:06 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 22:13:06 -0500 (EST) Received: (qmail 9416 invoked from network); 5 Jan 2018 03:13:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 03:13:05 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 276D9EC953C; Thu, 4 Jan 2018 19:13:05 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: more fallout from removal of lint Message-Id: Date: Thu, 4 Jan 2018 19:13:04 -0800 To: "O. Hartmann" , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 03:13:14 -0000 Mark Heily mark at heily.com wrote on Thu Jan 4 14:06:18 UTC 2018 : > the build system for CURRENT can be changed in > ways that make it incompatible with building STABLE. This is normal = and > expected behavior for a development branch. It has never been a = *supported* > option to mix and match source code from different branches on a = single > host. If I understand right, at the transition from stable/11 to release/12.0 and stable/12, stable/11 is supposed to be able to build 12 as part of a source based upgrade. (Normally the most recent release/11.? should be able to as well? The oldest supported release/11.? as well?) So at certain times one direction of mixing seems to be supported for specific versions in order to allow progressing forward. That does not mean that the other direction is supported. On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann = wrote: > On Tue, 2 Jan 2018 09:33:08 -0500 > Shawn Webb wrote: > > > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: > > > Since lint was removed from 12.0-CURRENT, it is not possible to = build > > > 11.1-STABLE on a 12.0-CURRENT host It does seem to me that having a head/ based system set up to do the stable/?? builds is backwards generally under the normal principles of operation. The other direction seems to be the general intent. Even having stable/11 try to build, say, stable/10 would seem to be backwards on the general principles if I've understood right. head/ is not actually essential to the issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Jan 5 03:32:22 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF085EAC6FA for ; Fri, 5 Jan 2018 03:32:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-160.reflexion.net [208.70.210.160]) (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 64E5F72048 for ; Fri, 5 Jan 2018 03:32:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13679 invoked from network); 5 Jan 2018 03:32:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 03:32:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 22:32:15 -0500 (EST) Received: (qmail 31663 invoked from network); 5 Jan 2018 03:32:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 03:32:15 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 53BE1EC8E80 for ; Thu, 4 Jan 2018 19:32:14 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Intel CPU design flaw - FreeBSD affected? Message-Id: <05382876-0605-424D-9BDD-CE1BF6C744CF@dsl-only.net> Date: Thu, 4 Jan 2018 19:32:13 -0800 To: FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 03:32:22 -0000 Darren Reed darrenr at freebsd.org wrote on Thu Jan 4 11:56:29 UTC 2018 : > Most people are only talking about meltdown which doesn't hit AMD. > spectre impacts *both* Intel and AMD. > > SuSE are making available a microcode patch for AMD 17h processors that > disables branch prediction: > > > https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html https://www.amd.com/en/corporate/speculative-execution reports. . . For the Bounds Check Bypass Spectre variant (#1): Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected. For the Branch Target Injection Spectre variant (#2): Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date. For the Rogue Data Cache Load Meltdown variant (#3): Zero AMD vulnerability due to AMD architecture differences. How long #2 will have a "has not been demonstrated" status is yet to be seen. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Jan 5 05:39:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DD0CEB3CFD for ; Fri, 5 Jan 2018 05:39:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-98.reflexion.net [208.70.210.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0F4476DA5 for ; Fri, 5 Jan 2018 05:39:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22594 invoked from network); 5 Jan 2018 05:39:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 05:39:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 05 Jan 2018 00:39:04 -0500 (EST) Received: (qmail 5607 invoked from network); 5 Jan 2018 05:39:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 05:39:04 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F0196EC7A6E; Thu, 4 Jan 2018 21:39:03 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: more fallout from removal of lint Date: Thu, 4 Jan 2018 21:39:03 -0800 References: To: "O. Hartmann" , FreeBSD Current In-Reply-To: Message-Id: <455DB593-4A32-4B0C-960E-5AE135DA5252@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 05:39:13 -0000 [I need to be more careful about identifying the context I'm referring to.] On 2018-Jan-4, at 7:13 PM, Mark Millard wrote: > Mark Heily mark at heily.com wrote on > Thu Jan 4 14:06:18 UTC 2018 : >=20 >> the build system for CURRENT can be changed in >> ways that make it incompatible with building STABLE. This is normal = and >> expected behavior for a development branch. It has never been a = *supported* >> option to mix and match source code from different branches on a = single >> host. The original material below was tied to buildworld buildkernel activity of itself. This is somewhat different than having COMPAT_FREEBSD*'s in the live kernel and running an already correctly built, older world in a jail based on such a newer kernel and world. > If I understand right, at the transition from > stable/11 to release/12.0 and stable/12, > stable/11 is supposed to be able to build 12 > as part of a source based upgrade. (Normally > the most recent release/11.? should be able > to as well? The oldest supported release/11.? > as well?) >=20 > So at certain times one direction of mixing > seems to be supported for specific versions > in order to allow progressing forward. >=20 > That does not mean that the other direction > is supported. This can have implications for poudriere, needing to use "pre-built distribution options" instead of "build from source options". There would be source around that "will not be built from" but for which the source tree is used in the jail, at least to build ports that contain modules. (This is another case of having sources from multiple branches on a single host. But the usage is not for buildworld buildkernel in this context.) For custom configurations, one might have to use, say, stable/11/ to build a world that is then to be put in a head/ context for use in poudriere. This avoids building stable/11/ from a head/ context. More direct jail use may be similar. (I've only used jails via poudriere.) Unlike for, say, stable/11/ vs. stable/10/ there could be temporary periods for head/ for which some COMPAT_FREEBSD*'s might not work, even if such is normally avoided. This is a risk vs., say, stable/11/ running a jail that has a stable/10/ world. > On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann wrote: >> On Tue, 2 Jan 2018 09:33:08 -0500 >> Shawn Webb wrote: >>=20 >>> On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote: >>>> Since lint was removed from 12.0-CURRENT, it is not possible to = build >>>> 11.1-STABLE on a 12.0-CURRENT host >=20 The below is tied to buildworld buildkernel activity of itself. > It does seem to me that having a head/ based > system set up to do the stable/?? builds is > backwards generally under the normal principles > of operation. The other direction seems to be > the general intent. >=20 > Even having stable/11 try to build, say, > stable/10 would seem to be backwards on > the general principles if I've understood > right. head/ is not actually essential to > the issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Jan 5 09:40:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7F50EC05D8 for ; Fri, 5 Jan 2018 09:40:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7748680370; Fri, 5 Jan 2018 09:40:01 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id w059dtWf003943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Jan 2018 09:39:55 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: mail: Host host86-154-8-90.range86-154.btcentralplus.com [86.154.8.90] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Programmatically cache line From: David Chisnall In-Reply-To: Date: Fri, 5 Jan 2018 09:39:50 +0000 Cc: Nathan Whitehorn , freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F3E7B40-1166-4045-AB9D-17D6FD70362F@FreeBSD.org> References: <20171230082812.GL1684@kib.kiev.ua> <08038E36-9679-4286-9083-FCEDD637ADCC@FreeBSD.org> <20180101103655.GF1684@kib.kiev.ua> <35d2d373-92f1-499f-f470-e4528b08b937@freebsd.org> <71E8D6E7-F833-4B7E-B1F1-AD07A49CAF98@FreeBSD.org> To: Jon Brawn X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 09:40:02 -0000 On 5 Jan 2018, at 02:46, Jon Brawn wrote: > This idea of Arm big.LITTLE systems having cache lines of different = lengths really, really bothers me - how on earth is the cache coherency = supposed to work in such a system? I doubt the usual cache coherency = protocols would work - probably need a really MESSY protocol to deal = with this config :-) I believe that the systems that have different cache line sizes (which = ARM explicitly tells partners not to do) don=E2=80=99t allow cores from = both the big and little clusters to be active at the same time - the OS = is supposed to migrate everything entirely from one cluster to the = other. The more complex designs, that allow mixes of cores from two or = three different clusters that I=E2=80=99m aware of all have the same = cache line size. David From owner-freebsd-current@freebsd.org Fri Jan 5 12:00:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63132EA410C for ; Fri, 5 Jan 2018 12:00:38 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from mx12-out5.antispamcloud.com (mx12-out5.antispamcloud.com [46.165.232.175]) (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 6AEEA652FE; Fri, 5 Jan 2018 12:00:37 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from [153.92.8.106] (helo=srv31.niagahoster.com) by mx18.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eXQfm-0002MQ-0X; Fri, 05 Jan 2018 13:00:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=F/SYQIEzWWD3Kr79R7WlogZ87Ws8OUFnHe13XgBiBlg=; b=Ykh5oJOzmUap+oabCBuAZS4b2z dka+fhkl1EuawzhnowV7X379Bdg7nbpvnLXVe15JEkRGQSQAWLGDHCwsZTPWVqPunxIOUfTpm3PNE tE693Qosla+61rLZfH6hSBlO824Hh/p9n7pfsHyXawDGZndGVG7tJCbw+YeVJbPVBieeoCPOjB7Zx JfQ2XxqWioOTUdTOGI/M3Ja7NytJHMPVzdfoX1ZC2hs679qCgjWTo1eP6Z3B5V3VJbkMLCaKOmsPf 4BP7oUTDqmKgpNbHstlUGMLYIhs8ZmNBAf8lmgSSTzAfl39nMqL2f0tpTAPatL97xyLiUeeLkSp0f VR6FLEgA==; Received: from subs08-103-10-67-172.three.co.id ([103.10.67.172]:7457 helo=X220.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eXQf0-0004Sr-2O; Fri, 05 Jan 2018 18:59:42 +0700 Date: Fri, 5 Jan 2018 19:59:36 +0800 From: Erich Dollansky To: Stefan Esser Cc: Darren Reed , freebsd-current@freebsd.org Subject: Re: Intel CPU design flaw - FreeBSD affected? Message-ID: <20180105195936.1ee7d010.freebsd.ed.lists@sumeritec.com> In-Reply-To: References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <5A4E165B.6040809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-AntiSpamCloud-Domain: out.niagahoster.com X-AntiSpamCloud-Username: niaga Authentication-Results: antispamcloud.com; auth=pass (login) smtp.auth=niaga@out.niagahoster.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jgJcvih9WPiZMxRl2c6Esfj1g3/PwYZaTCzSym8uE9HzIbxPIVqjxy7 7ut5T1JsZKYawDn/enV6ZOCLci35UYiEhFubuj47Ea+dR4yDS11UXAQiOAisNwrWhTdeG2lEVgwD nwHNwZgIJoSpWzjYl5d9/HimTUzho/rtpZDweBND8jRMB3uQYVVWSEEANGLyrd7G7JKC7Asx24pl PPXK992H9J9aF7x5U6d+zBlSt7Smv0jyP/hzA/BwFfCEJZxGiyVhjKI1mv7/gl8TuLbpjpy09lQ/ NiVM5N3BzRSwrp9YiuHKVLmpZEAjfPZha+Ic1Rw1CrwEq8BERyizrpQHoGmzMHBHN7zTjT43l4xq lenFgQvuD2UNksTg40BEhfECNwHjGN9mut8PUYrNlSG41Vc3/eFdiE4MkeaGU5VJ/8zFmz1KZ33e OV11Gqa7cLdWCPjz7BY+om/60JF3AmF7Wwo/e5HdHjGVIhFOYAOocn3reYOpkmIkkJyYEVaLX77r VRqZR3KVQgqF/fPYYAfEfshBg9wrN/YiktVyZ+iypN/pUKvhn1TeAR98jj1tnrGcQt8JfdM1EPxb GKDnxOtqDWWjwa6WqpeDCYh7wv5KVmNyK4o+6Zr1C1QaJOl4+/iG4+MRZOqWznTWYsnDz/791Ntu LpPzeWJloZPW+PJIga0yotnGdM8b9HvKTt+ASTDbqZ8KKs8vCPWUJhAr4GGiXmqsGEoBj4KdAYA6 D2KCGmEHbh081pFzipnBgdBNypYk/vUf9oDBqtClgM5jH/om1Q4Dp/8j196Ow66OyXl4ADhpOxZR LsWBrUA5TxiFmKpqXHAuaNhcOyss2ayLfHSIwpjwBTL1+6vDOMemz/4I88NDfFh8W8PouInOS3zz s5ZsyfdCnoIsa5jK4+8oVSkVJaKPvI4UsM402VFVXfqRB7JdMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine1.antispamcloud.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 12:00:38 -0000 Hi, On Thu, 4 Jan 2018 15:33:46 +0100 Stefan Esser wrote: > Am 04.01.18 um 12:56 schrieb Darren Reed: > > On 4/01/2018 11:51 AM, Mark Heily wrote: > >> On Jan 2, 2018 19:05, "Warner Losh" wrote: > >> > >> The register article says the specifics are under embargo still. > >> That would make it hard for anybody working with Intel to comment > >> publicly on the flaw and any mitigations that may be underway. It > >> would be unwise to assume that all the details are out until the > >> embargo lifts. > >> > >> > >> Details of the flaws are now published at: > >> > >> https://meltdownattack.com > > > > The web page has both: meltdown and spectre. > > Most people are only talking about meltdown which doesn't hit AMD. > > spectre impacts *both* Intel and AMD. > > > > SuSE are making available a microcode patch for AMD 17h processors > > that disables branch prediction: > > > > https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html > > Disabling branch prediction will have a very noticeable effect on > execution speed in general (while split page tables only affect > programs that perform system calls at a high frequency). > > I have not fully read the Meltdown and Spectre papers, yet, but I do > assume, that the attack at the branch prediction tries to counter > KASLR, which we do not support at all in FreeBSD. > > So, I guess, we do not have to bother with disabling of branch > prediction in FreeBSD for the time being? > an attack on KASLR will not work, but any other attack will be get data from the kernel out. So, FreeBSD is affected but not by the attacks which will work on the other operating systems. Information still can be extracted. Erich From owner-freebsd-current@freebsd.org Sat Jan 6 03:39:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6913EB5F48 for ; Sat, 6 Jan 2018 03:39:16 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta10p.bpe.bigpond.com (nsstlmta10p.bpe.bigpond.com [203.38.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB12E6FE26 for ; Sat, 6 Jan 2018 03:39:13 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep16p-svc.bpe.nexus.telstra.com.au with ESMTP id <20180106023034.GMTR30649.nsstlfep16p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sat, 6 Jan 2018 13:30:34 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtuddrjeekgdegkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheptehnughrvgifucftvghilhhlhicuoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqnecukfhppeduvdegrdduledtrdegtddrudekvdenucfrrghrrghmpehhvghlohepkggvnhdrrggtqdhrrdhnuhdpihhnvghtpeduvdegrdduledtrdegtddrudekvddpmhgrihhlfhhrohhmpeeorghrvghilhhlhiessghighhpohhnugdrnhgvthdr X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from Zen.ac-r.nu (124.190.40.182) by smtp.telstra.com (9.0.019.22-1) (authenticated as areilly@bigpond.net.au) id 5A204A960C02FABD; Sat, 6 Jan 2018 13:30:34 +1100 Date: Sat, 6 Jan 2018 13:30:29 +1100 From: Andrew Reilly To: blubee blubeeme Cc: "Klaus P. Ohrhallinger" , FreeBSD current Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC Message-ID: <20180106015852.GA46842@Zen.ac-r.nu> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <52b2f48c-332c-8984-838f-4902da0ebc81@7he.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 03:39:16 -0000 On Fri, Jan 05, 2018 at 02:27:40AM +0800, blubee blubeeme wrote: > I'd love to see if RISC-V is vulnerable to this? > > I think they are in the best position to capitalize on this clusterfk... It's a micro-architecture flaw, not an instruction set flaw, so just as for ARM and amd64, it will depend on the specific version. The only RISC-V hardware that I'm aware of is in-order (no speculation) so unlikely to be affected. There aren't any data-centre-scale RISC-V systems yet, but some are being worked-on. Will be interesting to see if they suddenly push out roadmaps while they go back to re-design to avoid this... Cheers, Andrew From owner-freebsd-current@freebsd.org Sat Jan 6 10:31:55 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5A48EB1ADE for ; Sat, 6 Jan 2018 10:31:55 +0000 (UTC) (envelope-from k@7he.at) Received: from smtp-02.sil.at (smtp-02-5.sil.at [78.142.186.6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A44EB6827A for ; Sat, 6 Jan 2018 10:31:54 +0000 (UTC) (envelope-from k@7he.at) Received: from mx.7he.at ([86.59.13.138]) by smtp-02.sil.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1eXllR-0001pI-6O; Sat, 06 Jan 2018 11:31:45 +0100 Received: from [192.168.6.60] ([93.83.242.219]) by mx.7he.at (8.15.2/8.15.2) with ESMTPS id w06AVdum045692 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 6 Jan 2018 11:31:40 +0100 (CET) (envelope-from k@7he.at) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mx.7he.at Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC To: Michael Butler References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> Cc: freebsd-current@freebsd.org From: "Klaus P. Ohrhallinger" Message-ID: <2dc62b9f-3ff2-227b-be0f-b3d873d332e2@7he.at> Date: Sat, 6 Jan 2018 11:31:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.8 required=5.0 tests=DATE_IN_FUTURE_24_48, HELO_MISC_IP,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.7he.at X-Scan-Signature: 9d02a3267670e8bb77f537b38fda5a39 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 10:31:56 -0000 On 04.01.2018 22:07, Michael Butler wrote: > > Interestingly, the Xeon 5400 series is not listed as vulnerable in the > Intel documentation where the 5500 and 5600s are; I checked as I have a > bunch of E5440s in service. > > https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr > Thanks for the link. Seems this was not available when I searched for a list of vulnerable CPUs. I'm not sure about Xeon W5590, it is on the list but the spectre poc does not read anything. For meltdown, somewhere in the news I read that all Intel CPUs since 1995 are vulnerable, which is rubbish. The paper says Intel CPUs since 2010. I tried different approaches to get meltdown working on Xeon E5420 and W5590 (launched Q3/2009) ... just nothing. So I am really happy that my 10 HP Proliant DL360 G5 are still safe. At least for me, a lot of panic for nothing. From owner-freebsd-current@freebsd.org Sat Jan 6 22:02:48 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C989DF53D7 for ; Sat, 6 Jan 2018 22:02:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-168.reflexion.net [208.70.210.168]) (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 4D47D1187 for ; Sat, 6 Jan 2018 22:02:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11054 invoked from network); 6 Jan 2018 22:02:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2018 22:02:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 06 Jan 2018 17:02:41 -0500 (EST) Received: (qmail 10812 invoked from network); 6 Jan 2018 22:02:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2018 22:02:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 523ABEC8BF3; Sat, 6 Jan 2018 14:02:40 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Intel CPU design flaw - FreeBSD affected? [AMD family Zen/17h status] Date: Sat, 6 Jan 2018 14:02:39 -0800 References: <05382876-0605-424D-9BDD-CE1BF6C744CF@dsl-only.net> To: FreeBSD Current , freebsd-amd64@freebsd.org In-Reply-To: <05382876-0605-424D-9BDD-CE1BF6C744CF@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:02:48 -0000 On 2018-Jan-4, at 7:32 PM, Mark Millard wrote: > Darren Reed darrenr at freebsd.org wrote on > Thu Jan 4 11:56:29 UTC 2018 : >=20 >> Most people are only talking about meltdown which doesn't hit AMD. >> spectre impacts *both* Intel and AMD. >>=20 >> SuSE are making available a microcode patch for AMD 17h processors = that >> disables branch prediction: >>=20 >>=20 >> = https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.htm= l >=20 > https://www.amd.com/en/corporate/speculative-execution >=20 > reports. . . >=20 > For the Bounds Check Bypass Spectre variant (#1): >=20 > Resolved by software / OS updates to be made available > by system vendors and manufacturers. Negligible performance > impact expected. >=20 > For the Branch Target Injection Spectre variant (#2): >=20 > Differences in AMD architecture mean there is a near zero > risk of exploitation of this variant. Vulnerability to > Variant 2 has not been demonstrated on AMD processors to > date. >=20 > For the Rogue Data Cache Load Meltdown variant (#3): >=20 > Zero AMD vulnerability due to AMD architecture differences. >=20 >=20 >=20 > How long #2 will have a "has not been demonstrated" status > is yet to be seen. = https://www.phoronix.com/scan.php?page=3Dnews_item&px=3DAMD-Branch-Predict= ion-Still reports that SUSE's microcode update for AMD's Zen/17h does not disable branch prediction, despite SUSE's existing description: QUOTE I reached out to AMD and on Friday heard back. They wrote in an email to Phoronix that this Zen/17h microcode update does not disable branch prediction. They'll be working with SUSE to re-clarify this microcode update description... But as far as what this microcode update does in the wake of SPECTRE they have yet to clarify or why this microcode binary has yet to make it to other Linux distributions. If/when I hear anything more, I'll certainly post about it but doesn't appear to be anything as dramatic as disabling branch prediction, which could have slaughtered their CPU performance. END QUOTE =3D=3D=3D Mark Millard markmi at dsl-only.net