From owner-freebsd-hackers@freebsd.org Mon Sep 17 20:35:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9664A10A6CC4 for ; Mon, 17 Sep 2018 20:35:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 300D98C2AC for ; Mon, 17 Sep 2018 20:35:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zsDuwxwVM1kbVPBRKhdnz_aX_b43Bv_givosqtwWjT3Rt9UrQXRalwgyUeWnpHK jQmDJQvRyZMhClRMi_fRv2RzIGqEHmDMP5Rk8yM.LbBeVImMsyKw8jQEZEQCdFq.5ir5oofclwPP 16H.ZRqzGpxhKoke_5mN1I_wDZ.un9KW.lbk2uwSYUP8QahYXU8_nuOPhmtKqJQx4mLtU54pmY3P kDskhLUbpgJDcX4Vic1Q8BMfNpPil__YshJUaQnNL9H3Wh9K4cFlhY_ER_e_hEuIqZRWxsrpjEke nt8S3ko7TuNgSGid82ZEwIUPEUkUcy_HsN7JD.AkiPhKxErX27hesXxOCHNVPvKc2q0NRAM.oOLC B.eJnpX3RGwugCHFO3Kfx2ebsYmUJKPfDiKMEnVN5p6qCjLwW5oYcw8xMmL99H9q_byRk_nZ4icn TQmK6cCXPI8wNVEYcwiPW2BGZ1EP36dGBxn_QHS0SUW0jWifV6ysPhrD7714AiDh0RhEVVf.LMmH C2TwFxJQyDDXL8w5QKSo.3av.Um0wlmhpmw1Jgf4AD6u5bIeGN1Xou1pXh1yU_fE_ExIVUtNYiWE rLD7e0ZZ8LlYQeduAubaj9hqctgJIp4VI93fyMNOfOPOjGmrB6_X_UeBQSfy29E4Q9KLoYbEJIHB wv.aWhUn1ool_Mbj3mFvOhZwn6iX9PfF7xAoKmH3w1lkjWFZ_JWj1MEw7iD4qrtJiI5aNVp9VDH6 SPGJMftgYYMVgq9CKJUFqpClgqRniiQv13e3twcOx3oJLTJIt_EDoRS8an1IQ.K_FbmCFqC1GTGl QiJ6NnpV5m2PFC898x4hiNk1njdM5lGy_yAHw7vTF6C1wnm6Gq4h4foUSSqTKAfuoh_Sw5VY8YW9 smYtNJWJTANZw2XxnMb0BnrLm4U5s2JZVOPyLT9xuv4o3wHKguGtGodAKID_0c.VINygKq32l7XU Se1ilGDCYg0hZG0YooBCzCpe6u..d9CZZoIhbIFnzQxUNlaTz.Mv4CW_D9WXIn1_4Fuh9qPKgXQW XHmVPl4wHEtuE Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Mon, 17 Sep 2018 20:35:17 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp406.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 25a4b4b42780b2c31cc8ffe067ddea17; Mon, 17 Sep 2018 20:35:15 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: An experiment in enabling discard with e.MMC trim on a Pine64+ 2GB (based on head -r338675) Message-Id: <670AF48A-77BF-4246-BD80-9D067CB05DE3@yahoo.com> Date: Mon, 17 Sep 2018 13:35:14 -0700 To: freebsd-hackers@freebsd.org, freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 20:35:19 -0000 As stands this is just investigatory material. Also, I first had to enable using an e.MMC on a microsd card adapter on the Pine64+ 2GB, so those changes are listed too. The goal was for e.MMC 4.5+ to enable the discard bit with the trim bit to allow an e.MMC to not necessarily force the trim'ed data to become all zeros or all ones: the performance command trim variant that does not require data removal (but allows it). (I did nothing about discard from the modern sd card material. I doubt that I have any test context for that.) Unfortunately I have a very narrow range as far as test environments go currently: just Pine64+ 2GB and just one type of e.MMC in use. But for the context that I have it seems to be working. The discard-enabling related changes are in: /usr/src/sys/dev/mmc/mmcreg.h (an additional #define) /usr/src/sys/dev/mmc/mmcsd.c As stands I have nothing for overriding e.MMC 4.5+ using discard with trim (when trim is enabled via the historical criteria). If trim without discard worked but with discard did not for some device this could be a problem. Also: if trim without discard is desired for security reasons it would be a problem. But what I have here is sufficient for my basic testing. The Pine64+ 2GB e.MMC-on-adapter enabling changes are in: /usr/src/sys/dev/mmc/mmcreg.h (a renamed #define as a form of = commentary) /usr/src/sys/dev/mmc/mmc.c (not really Pine64+ 2GB or A64 specific) /usr/src/sys/arm/allwinner/aw_mmc.c (MMC_CAP_SIGNALING_180 part: Pine64+ = 2GB or A64 specific) (So mmcreg.h has something for each part.) I expect the mmc.c change is a generic correction to more accurately follow the e.MMC DDR52 definition as far as voltage requirements go. But it was driven by the Pine64+ 2GB properties leading to wanting the change. The changes for discard ( and mmcreg.h ) are: Index: /usr/src/sys/dev/mmc/mmcreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmcreg.h (revision 338675) +++ /usr/src/sys/dev/mmc/mmcreg.h (working copy) @@ -463,7 +463,7 @@ =20 #define EXT_CSD_CARD_TYPE_HS_26 0x0001 #define EXT_CSD_CARD_TYPE_HS_52 0x0002 -#define EXT_CSD_CARD_TYPE_DDR_52_1_8V 0x0004 +#define EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V 0x0004 #define EXT_CSD_CARD_TYPE_DDR_52_1_2V 0x0008 #define EXT_CSD_CARD_TYPE_HS200_1_8V 0x0010 #define EXT_CSD_CARD_TYPE_HS200_1_2V 0x0020 @@ -493,6 +493,7 @@ #define EXT_CSD_INAND_CMD38 113 #define EXT_CSD_INAND_CMD38_ERASE 0x00 #define EXT_CSD_INAND_CMD38_TRIM 0x01 +#define EXT_CSD_INAND_CMD38_DISCARD_WITH_MMC_TRIM = 0x03 #define EXT_CSD_INAND_CMD38_SECURE_ERASE 0x80 #define EXT_CSD_INAND_CMD38_SECURE_TRIM1 0x81 #define EXT_CSD_INAND_CMD38_SECURE_TRIM2 0x82 Index: /usr/src/sys/dev/mmc/mmcsd.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 --- /usr/src/sys/dev/mmc/mmcsd.c (revision 338675) +++ /usr/src/sys/dev/mmc/mmcsd.c (working copy) @@ -136,6 +136,7 @@ #define MMCSD_USE_TRIM 0x0002 #define MMCSD_FLUSH_CACHE 0x0004 #define MMCSD_DIRTY 0x0008 +#define MMCSD_USE_DISCARD_WITH_MMC_TRIM 0x0010 uint32_t cmd6_time; /* Generic switch timeout [us] */ uint32_t part_time; /* Partition switch timeout [us] */ off_t enh_base; /* Enhanced user data area slice base = ... */ @@ -297,6 +298,8 @@ device_printf(dev, "taking advantage of = TRIM\n"); sc->flags |=3D MMCSD_USE_TRIM; sc->erase_sector =3D 1; + if (6 <=3D ext_csd[EXT_CSD_REV]) // e.MMC 4.5 or later + sc->flags |=3D MMCSD_USE_DISCARD_WITH_MMC_TRIM; } else sc->erase_sector =3D mmc_get_erase_sector(dev); =20 @@ -1251,7 +1254,7 @@ device_t dev, mmcbus; u_int erase_sector, sz; int err; - bool use_trim; + bool use_trim, use_discard_with_mmc_trim; =20 sc =3D part->sc; dev =3D sc->dev; @@ -1261,6 +1264,7 @@ sz =3D part->disk->d_sectorsize; end =3D bp->bio_pblkno + (bp->bio_bcount / sz); use_trim =3D sc->flags & MMCSD_USE_TRIM; + use_discard_with_mmc_trim =3D sc->flags & = MMCSD_USE_DISCARD_WITH_MMC_TRIM; if (use_trim =3D=3D true) { start =3D block; stop =3D end; @@ -1289,8 +1293,10 @@ =20 if ((sc->flags & MMCSD_INAND_CMD38) !=3D 0) { err =3D mmc_switch(mmcbus, dev, sc->rca, = EXT_CSD_CMD_SET_NORMAL, - EXT_CSD_INAND_CMD38, use_trim =3D=3D true ? - EXT_CSD_INAND_CMD38_TRIM : = EXT_CSD_INAND_CMD38_ERASE, + EXT_CSD_INAND_CMD38, + use_discard_with_mmc_trim ? = EXT_CSD_INAND_CMD38_DISCARD_WITH_MMC_TRIM + : use_trim ? EXT_CSD_INAND_CMD38_TRIM + : EXT_CSD_INAND_CMD38_ERASE, sc->cmd6_time, true); if (err !=3D MMC_ERR_NONE) { device_printf(dev, As for enabling the Pine64+ 2GB e.MMC use (parts of which may be more general): Index: /usr/src/sys/dev/mmc/mmc.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 --- /usr/src/sys/dev/mmc/mmc.c (revision 338675) +++ /usr/src/sys/dev/mmc/mmc.c (working copy) @@ -1814,10 +1814,10 @@ setbit(&ivar->timings, = bus_timing_mmc_ddr52); setbit(&ivar->vccq_120, = bus_timing_mmc_ddr52); } - if ((card_type & EXT_CSD_CARD_TYPE_DDR_52_1_8V) = !=3D 0 && - (host_caps & MMC_CAP_SIGNALING_180) !=3D 0) = { + if ((card_type & = EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V) !=3D 0) { setbit(&ivar->timings, = bus_timing_mmc_ddr52); - setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); + if ((host_caps & MMC_CAP_SIGNALING_180) = !=3D 0) + setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); } if ((card_type & EXT_CSD_CARD_TYPE_HS200_1_2V) = !=3D 0 && (host_caps & MMC_CAP_SIGNALING_120) !=3D 0) = { Index: /usr/src/sys/arm/allwinner/aw_mmc.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 --- /usr/src/sys/arm/allwinner/aw_mmc.c (revision 338675) +++ /usr/src/sys/arm/allwinner/aw_mmc.c (working copy) @@ -509,7 +509,7 @@ MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | MMC_CAP_MMC_DDR52; =20 - sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330 | = MMC_CAP_SIGNALING_180; + sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330; // | = MMC_CAP_SIGNALING_180; not used on Pine64+ 2GB =20 if (bus_width >=3D 4) sc->aw_host.caps |=3D MMC_CAP_4_BIT_DATA; @@ -1308,17 +1308,20 @@ =20 sc =3D device_get_softc(bus); =20 - if (sc->aw_reg_vqmmc =3D=3D NULL) - return EOPNOTSUPP; - switch (sc->aw_host.ios.vccq) { case vccq_180: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; uvolt =3D 1800000; break; case vccq_330: + if (sc->aw_reg_vqmmc =3D=3D NULL) // implicitly already = stuck at vccq_330 + return 0; // avoid calling code treating the = assignment attempt as an error uvolt =3D 3300000; break; default: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; return EINVAL; } =20 I wonder if the sc->aw_reg_vqmmc =3D=3D NULL handling change may be more general than the Pine64+ 2GB (A64) context. Anyway that is what I have so far. See any problems? Would FreeBSD even want to support e.MMC 4.5+'s discard with trim (probably with more control over if it was used)? If yes, I'd presume not until 13.0 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Wed Sep 19 12:12:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D41F41098F5E for ; Wed, 19 Sep 2018 12:12:07 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 772D17DFB0 for ; Wed, 19 Sep 2018 12:12:07 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 386D51098F5C; Wed, 19 Sep 2018 12:12:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 273151098F5B for ; Wed, 19 Sep 2018 12:12:07 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 D1B2E7DFAF for ; Wed, 19 Sep 2018 12:12:06 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id w8JCBxEq045246 for ; Wed, 19 Sep 2018 08:12:00 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id w8JCBxpg045245 for hackers@freebsd.org; Wed, 19 Sep 2018 08:11:59 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 19 Sep 2018 08:11:59 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: wanted: old photo of jkh with "dolly" Message-ID: <20180919121159.GA45223@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 19 Sep 2018 08:12:00 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 12:12:08 -0000 Hi, Not really technical, but it's the only audience I can imagine would have this: Many years ago, jkh was gifted with a special friend named Dolly. A fairly famous photo was taken of the event. I need a copy of this pic. Seriously. And it doesn't seem to be on Google Images. Can anyone point me at a copy? Thanks, ==ml -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc... From owner-freebsd-hackers@freebsd.org Wed Sep 19 22:40:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D28F10A9229 for ; Wed, 19 Sep 2018 22:40:38 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C2B195BEC for ; Wed, 19 Sep 2018 22:40:38 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-ua1-x92c.google.com with SMTP id u11-v6so3539540uan.13 for ; Wed, 19 Sep 2018 15:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=rfYclXEABKYoqZFTJ8fREuWv+qttTu4JPo5V5gsVlKw=; b=k7Kj582TIR4YLadyaUuKNDjGe8ITI63Qs5BJS7YWGKUxdcDnB/sDQdVB5qhxx0Qc6W ImNRAZQae9lSWZot3xfrMOGrHSlTfB1Wx62rXy6Cf79eJtpBcDl2OBYGOBfsNZzNeNed uNrIuNorh/ZAIbXcvHLJKfGx2/MlxzLgxm2OyOCd1PLVseCghesCLYYQ15zd5lgQe6oW oHpV/aGWFTclMNCBbwIhgd4WcYQE4HyaiR0nUt4Nw/qvXlzjA905bslEmRqAGktoVAft aj0L2LBw6yErVFNxqnXoAleKvph5xv0ZR97LLAjfzByyceeXktCmpKH1goCsXkq2woKZ NQ7Q== 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:cc; bh=rfYclXEABKYoqZFTJ8fREuWv+qttTu4JPo5V5gsVlKw=; b=dcBRbFuzMGYYEwDOFxV6A7HI3qgr9L1XL+myuym5gV1+Mwh0gQTqGJk/KNsanz5hmn d8RBrLv6SF+eOBQUUgrmneTgwpUQ9tIXmMxH0Z1/TMFjrxi+jNV44wID7FwW7IVoBaFi X7GduU9+jQKu/d7tEeyaF8Yis8eDCOiJSVwoqI1marobjP+BGtk3bu8Mh8r+H1NT2O5L C9mLZZvQPQiJm2p4KDIAn98fCjEBzLmPidumXUsWuPU66jr9BHvAkYQQPCJY7scPu7rZ Q6PIzYz+dS4TLjGLNiop7hJDyvk7+2nju7JsPTguDq0P6iWRaGwQq6QAEYeHEdg7coff f+1A== X-Gm-Message-State: APzg51BqgecKzEfbj3k0F45k3wVc884MUDXflRVjKKwkVwDjo5JKRd+H do8OoGC2/ZwdR8E4KG9x+N7SsZVh0wcRwsb7fFRGQrYF X-Google-Smtp-Source: ANB0Vda93Syr8KVHu1PokvvdhTH/tqE3ic6eMXjtdbbCYXbkJhK1WhgADb/q90DDeLEEvfTTBIbO0ET6FnYxav4QTSo= X-Received: by 2002:a9f:3d6f:: with SMTP id m47-v6mr11173546uai.19.1537396837077; Wed, 19 Sep 2018 15:40:37 -0700 (PDT) MIME-Version: 1.0 From: Shrikanth Kamath Date: Wed, 19 Sep 2018 15:40:24 -0700 Message-ID: Subject: Use of msleep after system has reset 'cold' and before SI_SUB_CLOCKS To: freebsd-hackers@freebsd.org Cc: Sreekanth Rupavatharam , hackagadget@gmail.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 22:40:38 -0000 Referring to the following snippet (MFC 309148 in stable/11)in the function callout_when in kern_timeout.c, @@ -981,6 +981,8 @@ callout_when(sbintime_t sbt, sbintime_t precision, int flags, spinlock_exit(); #endif #endif + if (cold && to_sbt == 0) + to_sbt = sbinuptime(); if ((flags & C_HARDCLOCK) == 0) to_sbt += tick_sbt; } else If someone were to use msleep during the window where system has reset "cold" to zero post SI_SUB_CONFIGURE and before clocks are available (after SI_SUB_CLOCKS is processed) then msleep which default has C_HARDCLOCK set would get a wrong timeout set which would lead to erroneous EWOULDBLOCK return from sleepq_check_timeout. In my scenario the value of DPCPU_GET(hardclocktime) which is referenced in callout_when was zero hence to_sbt was zero but the 'adjustment' for that failed because the above check is doing a if(cold && to_sbt) to do that. Should the check be just if (to_sbt == 0) then set to_sbt to sbinuptime? -- Shrikanth R K From owner-freebsd-hackers@freebsd.org Fri Sep 21 03:57:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E983C10B1D83 for ; Fri, 21 Sep 2018 03:57:11 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DAE28C841 for ; Fri, 21 Sep 2018 03:57:11 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-it1-x136.google.com with SMTP id j198-v6so169438ita.0 for ; Thu, 20 Sep 2018 20:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=B30Kk9Iy2ZdedGX8p+G/ceDNqSDomjbeN5LtPkp5Zzc=; b=KW9P3jvDTkfA8tH9Z27BlQDikN14JcbApcuFNJOUy87MSDjVhJPccKKD4gMGo89kwy CIGGfx3wlNK9UIlg4ILeqGvIyBR6JfVO2jKEig6e1WmlRylZHbShns1cr92JwMymRGzN biHbn6dDJocMuSPrP7XhKV+pDfN/TxEDi+WOy+kH/mCX6u8DI3eA60XqX8LU+hGrar8K Y+LnValmU5IfooGiAUNI4ESLeEWq06xPoXBO7Nh/EtBEnAQ0ZGBAo/1J3ad+GeVjOLuX LcYNrZlpl6IcC9dFZrSgt68rLUfmO4EpipuEqe+gR8oxTuv2MHo9auGnEwMmRDAPAxJX EAnA== 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=B30Kk9Iy2ZdedGX8p+G/ceDNqSDomjbeN5LtPkp5Zzc=; b=He2Vi7932uM9LVwNbFvdri3vCqyLOPndczZE4l48/qxkeUo7dTlWwq7OqVw6u9da6o HD8iNaAfLsqvSE5rmFdAN3WKPC/05t7bKavKkBYOi2nrqSVMf4+VwEjufrEaEUfFUWpl WaqO0eZOBxN9dqZymPM4FTct1jLj15EOlCY99SSlgij+HRN92fDmzTcMVxoc//FdjQZu fy47xJik/OgO0VvEgMiZqXznNpqA4irm6Ht+UQqylW4OEOazFKk95t67Xp5Q9kbDfZVP XoOpt7X/tVQq6L40Ns9Q4ckfG2ip9MCTtACQegmNMdF3F2Y4u/rbnAN1JjkLaOW4NJFS 9HYg== X-Gm-Message-State: APzg51BflU+nHocaoTS/RsBitmznXqcagppZXYFi3p7XQfyjjBUoV4yz tZCqj4fgyjQ9fJBPlikOdKeZSVuNCvcKYJxfXq6JhGSAJhGafg== X-Google-Smtp-Source: ANB0VdaiFx8kzAGXT+W2ZrsoN1Vtprtt0zOqfH+1WhXJNy4Rz/dNZWbruX+WSZrRMVOWrre+ZAoEVu+leEjXs0SEfWs= X-Received: by 2002:a24:da47:: with SMTP id z68-v6mr2270208itg.59.1537502230374; Thu, 20 Sep 2018 20:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:d025:0:0:0:0:0 with HTTP; Thu, 20 Sep 2018 20:57:09 -0700 (PDT) From: Lee Brown Date: Thu, 20 Sep 2018 20:57:09 -0700 Message-ID: Subject: Can't get pidfile to work in rc script To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 03:57:12 -0000 I'm trying to get 2 separate sshd's running. I've created /etc/rc.d/sshd_alternate but it always uses /var/run/sshd.pid and not /var/run/sshd_alternate.pid. I tried sshd_alternate_pidfile="${pidfile}" and procname="sshd" / procname="/usr/sbin/sshd" to no avail. Can somebody provide some assistance, I'm sure this is simple but I just can't fathom it. TIA #!/bin/sh # PROVIDE: sshd_alternate # REQUIRE: LOGIN FILESYSTEMS # KEYWORD: shutdown . /etc/rc.subr name="sshd_alternate" desc="Secure Shell Daemon (Alternate)" rcvar="sshd_alternate_enable" command="/usr/sbin/sshd" start_precmd="sshd_alternate_precmd" reload_precmd="sshd_alternate_configtest" restart_precmd="sshd_alternate_configtest" configtest_cmd="sshd_alternate_configtest" pidfile="/var/run/${name}.pid" extra_commands="configtest reload" sshd_alternate_configtest() { echo "Performing sanity check on ${name} configuration." eval ${command} ${sshd_alternate_flags} -t } sshd_alternate_precmd() { run_rc_command configtest } load_rc_config $name run_rc_command "$1" From owner-freebsd-hackers@freebsd.org Fri Sep 21 04:02:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1F1D108A14E for ; Fri, 21 Sep 2018 04:02:41 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 741388CCB7 for ; Fri, 21 Sep 2018 04:02:41 +0000 (UTC) (envelope-from steevanxperia@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id b15-v6so10277529oib.10 for ; Thu, 20 Sep 2018 21:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Oms0VjEDflM2eIybsHGp5516CrAmnHagJBJ2su/Bxyg=; b=HGpjS6FOzk8KWhhRlqPCbuXNh61GsxxVVdG4MP8LVzgR91kpITEcmT8NekeXMXR99a +Rt9HqrP+vI2LzUtTZYwsVGZQQ4Pay9U9a1WMeH6o2Ky5eMbFuha3dEXfRIIno1psZAc 0KjjCeEFv5YrsBUOgvxf9ZnbJkMSq0ar82Equdt+3XZbj04wFn/RXHmwwXG45lu60P4A TXhSBgYEj0sL7NVP0T/gaSackwtA0z8C83Tl6jF5ES2emoV5od3PVNQasWm7439IsgRc n/wHfE8aujNPOQ9YEYcq03T+cj9qgvTo+evTZ961cVive7PLg+8Dv/1nJOc2SMKLREhT tDaQ== 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=Oms0VjEDflM2eIybsHGp5516CrAmnHagJBJ2su/Bxyg=; b=K2bXos4oZ2X3O5qZQcMVA+unpjmEogIP2fztC/ETJk3vamQ+zf+OTbubySW2GjiLwN fj7d847eU0CKjduoOyRbm79WgGQ/gxzeFhsOXUqYMKQNWTVf7qN447y1t1v74OWpOkin geyQzdRxm4DAnX9Oxe4TcaflntF4o3GZO3siGbY4X0teF7OkAP0rkJiGKBgFPP57ST+m L92D+qhc3UQ/rqdNCmcJWOMXKU/1rGjuHw00YnSCDFqsmN/Ebywz14KWJFzBiJSHyvBC xNknJs0prLkgP8MhJKFxZ/gSHPfoapWXmt2VU4bwVwPS6j+RBMIfqnu/m8dW5G6SjVmB vqZg== X-Gm-Message-State: APzg51DF4I0blzAfaymRgDYOnVQkBAvLfj/uOogCXz/xXFeigmsZGLdP uS9tQWu/HjIyzlskCebQlIUoZTpkLFxWLkmXj3uhdYEd X-Google-Smtp-Source: ANB0VdZC97qnbPN5rcW+BSWdXyyb8sz8+abOnq1yDyJ9tUocXUg/5YBk77xBr1qejByNX3oiModAfe2q4rfTOnB6jCI= X-Received: by 2002:aca:5d86:: with SMTP id r128-v6mr506127oib.243.1537502560455; Thu, 20 Sep 2018 21:02:40 -0700 (PDT) MIME-Version: 1.0 From: Steevan Rodrigues Date: Fri, 21 Sep 2018 09:32:35 +0530 Message-ID: Subject: PCI Express card driver load and unload takes too much time ( up to 30 minutes) To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 04:02:42 -0000 Hello Folks, We have a PCI express card for data processing to achieve 25 to 30 Gbps . Recently we have been facing a issue in one of the server at customer site. System information: Supermicro motherboard-X11DPH-TQ motherboard hw.model: Intel(R) Xeon(R) Gold 5115 CPU @ 2.40GHz ( Dual CPU with total 20 cores) 16 GB RAM In this system the same PCIe card works fine in RHEL 7.5 and the driver load and unload also works fine. Our driver usually takes about 20 seconds to load and approx 20 seconds to unload. However, on this particular system when FreeBSD ( tried with 11.1 and 11.2 Release) is used it takes about 2 to 4 minutes to load and about 8 to 30 minutes to unload. During unload it looks like the system freezes completely and I can not run any commands to find out what is happening . The same driver works fine in our lab servers Dell T620 ( Xeon 12 core CPUs) and desktops with FreeBSD 11.1 and 11.2 and 10.4 . Also I ran couple of Phoronix tests on this SuperMicro server. In one particular test I see that the time taken is too much. The test suite is OsBench. In this, the thread creation test shows average time taken to create threads is 9000 usec . On the other hand we have servers and desktops in our lab and in that this same thread creation takes only 20 to 30 usec . Any pointers about what could be wrong with the system or our PCIe card driver ? Thanks Steevan From owner-freebsd-hackers@freebsd.org Fri Sep 21 05:06:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81EA2108E8F9 for ; Fri, 21 Sep 2018 05:06:28 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE9DA8E5B3 for ; Fri, 21 Sep 2018 05:06:27 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from [192.168.1.202] (unknown [82.208.134.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 7621C915A for ; Fri, 21 Sep 2018 05:06:25 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/7621C915A; dkim=none; dkim-atps=neutral Subject: Re: Can't get pidfile to work in rc script To: freebsd-hackers@freebsd.org References: From: Matthew Seaman Openpgp: preference=signencrypt Autocrypt: addr=matthew@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFJIL80BEADi7/VbnnErDU6pjEhI/SzEZ/HbDRkJ5g7HroAtqIRm6nj8ZwOAgZ/2ZnWn 5F+fXTuLsG0FLNtkd17FoVcuCi5e/GPliXI5cmamV7E1Yz4T8UsJ7RQolimyxVexccKd16Tc AA7B9bFlJSKkBUSD0buj7VjT07xWhRzu6Vgi5r0UjLALYJz977uZA0F1aOGOXREDEAOhdcNc kSNjynqAwDA6dCT1Elpi4key1fYjv4jyDF+GU/YXul2Y/rguA8FCkHd9vyym5eAsLQ5mG00V V9fkEHIpH5KorNVnl/ufHXnkZqmHAZVpFDcrshb7aZ/pL45PXyWgLj+e6etelgj3a2bZi0JF cVdXCnBZVP2oIyYblM11ugTbfCwodORU8a5KfPeztMdAtDr4e+32NTrPdPi5rLT+GUsYz+PL 3A3m3u8bdsFp40DlIrBtSByVjqERxcfhphrEB4J8BXHUG7OAtXkZMlW/PGKDwXJq0O6Z5Tcg YHAoEiSWbXiexHgXNJyP+sqnIlhLWhSJGeJ+C83wqI6oYlZUCW00NkPxcIHnQPV/z+5wQVci TMyaWC2YCIHz4Ljs+TnwWMz0E8PNFDfHVbQ0W4PRGV7gRAqxfL+yKufauIEGbEq8rNDbSwL3 bcUCxR4ZDlaUEUwT4J8naf7rjdgiEYHs2Ig3jeK1+ER4FPG1sQARAQABzTBNYXR0aGV3IFNl YW1hbiA8bS5zZWFtYW5AaW5mcmFjYW5pbm9waGlsZS5jby51az7CwZcEEwEKAEECGwMFCwkI BwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQRyz6whebywJLW1RZADb2ye5/OevwUCWttU4QUJ DFmAlAAKCRADb2ye5/Oevwb5EACipbOazgwl5IbqkQI4gELpCh5dqDASS9DQqAD35n/cI91P 0lrYcdyCQbOXadQi5bswnP4AcJqX83mITXbcApDdxVxHujw7VODI069eV3/I9Qz72mHYYAAj w0CHNx4bKED2YCSVS6+jV5hq2sywNEUxL+4I218Oc+IsLts62m4tQ8UxX9fQ2H1kQOvdrYpj x7je5qJX/yujLc+9WWZ8ZBSdP/HVJUEdRgQotwAlgfMp3mRQEE73MAJisG/olj/dSxd+oHIP NbJt1yxMqhZekuEGqZpm3tWvqYgpGcEXdhphJSxeK6oLpTLghuAb7/WdOBrpfL7c2OQYBgOw DK+7Io9NBt/d/rCxL39jmUONW8ohrhnNQ2SALnyYTvZgruxA4tXxOOyM9up0/8mB5E8YC9ML 5YuxRPNTXYeWCexa0zktnkCgT7PhS33evf5gsA0B9Snv7TFCFN9adPAdHlsppZIWfTHDG8e2 Jik8PmvsUG34XNif5k6Ui3++2ZA8ZoKvOyLeomuno1hN8yk1APw8SbX1SPNz9UVbl8W/YgGj 3GhYOuQt4HcMiLyTby6R4lC4nsBaHS1MX+57f6Zxzf2wNjSKxiJK9qS7azbu/GxpafNhbz1Z +iUDIaJkRWA1Gs8C7SMcfVsI5zDtvqHGYtTCgooVMYJ6vRyB68M4bljUYMxRTs7BTQRSUUK4 ARAA1FhWoOejtwmsnGshoIbda2FmM+z/f97OzpagLhACHfP5Es/I18wG/0G+rdNuO2tjA9IM Z44GUMtjokDrDk63N9S+rVKy1QEy+UN6CiIfYTpTTAPnEY7IGN1JjGksPhn7aeuBCQwUMAV1 k+wklBCcOD6s8DD4kx0ZJqkH83XzWoBSVamdHvnM56C8yPVr5HHMC1tZInAWBMrF+cjl1EPf z3CqkVnG8Sxc5ydeibMS9Q3lHLeVkVlMRAmNqzNLfgJDUWtzac7JIjFEsxYYhpiaPcsstUUu Ha4zIRJ/yHDNbDttWRf1lrlFZLpeuap4BZ2hQw0UOZVNwGoFoS4ZqaZiv8mm0lX6s9/AdQD6 AVrpXWKa7JU2wDiay9sRbYh+5vVWGz9mhncK/Vfwtu5IjVp5v5WMz/WfnUxZMcNlfgTo4i1s www+qRBO2A4Yj8qKKWnTsl7aCX92itTiPgwbt6YgQPwgww72r67jPt5o8VMXDqPMPKzGicw1 AyxtMjsoSlnn91FuZctwil3vPpvzGXtBmrzQSbdDmy0KT5p5/W9pD/8UtLLLM6PLs5X0jIho vQHnQKEUO7xV3yNDAW9DPICeh7f/o9W+QJfQAXngNz0brvmgScAUXRaeAFeQbAmtEG92qlSV D7gb7WOemllgfbEn0Nanrv5aEcZCWx4WjybMLHEAEQEAAcLBZQQYAQoADwUCUlFCuAIbDAUJ Adf5AAAKCRADb2ye5/Oev8CLD/40aQCRpHTfydtq6sEVHFdpQCgGIE/47r46kr2x15C2wYPY m9JJ1lHvjpKt6N2gGfmiMfq8+PX1ppWp+qkZP4KF2PSxJJ6sjPNMne9+UhPEX5Xn3Z1vjRXJ t7BV0vhsB7WrI8jI9arpYkwVOkQyyjFxWeL0jvfGYYABttvlG/hjxuwI01vipuTfr89zjRYc C5hY1sg2bOn/tIe/V15Sj13Uo/JuFn7Aim91iEYrp5668qbWbLM/8hNqtECH6qLEhtoeoLlL bq6D3HIi00bYvcbBpig/azUasHio3gf4GNklQ5bVvWgIwV0Ue4TjXMCokpaLCq+CNaIqEO9v qJcEa4t0d7oXFHj6U9l6iSVPYRgXsCj/pBgYFPrdV6V8WNGHqa+yQBBtV9bSPNKF8xAjHQ5B KGardo1fBsF7P1CVE3SSr5IzZwk5DIeyCWGJjB8NGGaPWNPIvNyC9v5N9KpFe7WAOyAdEjR7 81ly0veYnFEFcVAmvW3FgzlEXQXw4M4FuniETd3idSJZpRBmq2jvxyfF3b69AdiLddcOAffR jGOBTezLtqxJstJhj7/s4yCuwQhUTpJzwoNBbPLqxmQ/THmdwx6VYAPIqOHBkSQj14nGyX5R vkfvZFq9OBKiVBSQi94jaaWZswqMfGeqZIOuZit+Q2TFTyS8b0R0dDaUUw32DMLBZQQYAQoA DwIbDAUCVCEGdQUJA7D3PQAKCRADb2ye5/Oev1gnD/4wJs6iWJrm2p7/7A0vt+ldL7j/ZaLw dl6XGiTvDY13qISfRwsl6yhsKgwqeAM5zOm1E6gzIdf7VwWx2/4KnQJ83nfBmU8KReUX3udT bVIk8Jo3sMYvPsWtNjRIHCLcXn54/Ajljp1cXihzQ0oXpFxn9sbZll4iE6TcKbPuBBFEsrbI xbjdtG7PNzjnhKkkwrORp2JsScWMcpvqq0/AvPeMKMbQ8SAkOZH20aWdw4wDbcm1bTrxSGYf bFsDmMXxueySeIWbDCwimeMFdWSItsCvHTKX8BIwDM6NP2sQY9Qya3p48HCmFGDpmHdZoU4f xp9+lZFvbNlG+gtY1up3HNYZ9pIbOOdKDjkKtymYX+F2gNflgD/Jp/Fa2EXDzk/iQ73gdT66 2TP9C0WOkFiM17bv5HmmFMGxG0Ap6Ntt8dcqZb2/XoBjR88ssrgDaSbFtpDkUIMy6OarXCii ioMF+bgpPDIffOFPRSFsB+jmMcGu2r3q5I6C3fpTgHh9towgJLhw0pfl08Vr+q3oODcOcXwk NbTrBtM3T5SrLv/lQqWtZmCppWDuRuFt02/jbMaVmWCnpQJN89Z+44H+Fu2ZL+sZSDhsBE0w O7iGAfgP1yIIiK/zunx6IMuNMf5v1y6StOHO/PqJ4+q8IWKBLzjWzEnpNiT5CA/Hdk7v+Va1 Ypd9XsLBfAQYAQoAJgIbDBYhBHLPrCF5vLAktbVFkANvbJ7n856/BQJa21VJBQkMUG4RAAoJ EANvbJ7n856/mAcP/0ybQAvXfxWEEBykIP0DhJHAC/EMeBwNkiAp4Sqr+uIz3GCFGKHDjvEG sofiFQ2ujBpG7FncHlBbnsTLFvte3ahE30I1AKcd9k1MBeOFoCBHwES1ts0XUXF37E+ANrEC QrzSayZx95csIiYvlfOPEOLAt7EiURKXCXdO6HNo8UimcmGdQwT3ytTMosHAbdrhQk13chTI WptmmCwz9iWLxT9PLY01ACCoXuAdGz07ZXQn+bB+avMa6Wh5yh39J+6jJiuzbRlv/Uelogq7 ojbC5zveX5rNbcyinwOEFyGAhFpfF7ESsKedR2Q40LvysT7I5ugS+Hk4Z2nvbd2bOSdC4j8a BWzfqVu2p37d2AnnswfPoLrOyNUZ+ciTEcmEUVR7WWUwQ0H6A6h4C2NeBmLRRjk9CEfzrgM2 DNQqDL1RMYKlVosQ8BeUR9ThztUwDakxnK0ZtZb2rAliKYaaEFbZDePz1xmvjYc7EZq/3OTl GMUDa6BPHHbCvJjiAUc/Q9iaRe3dp69V/rwOM5NiS+tWgp3OtgX0mDWVoQnDjyWVIRU/QagJ HsNJJCc0N48BxgIX3H6M0x6BbA9PKgFtDlK4hLR/hDl5fnWG45TVIxT4ybuPXGW7af9U6bGD gXTBNUCzNUz2p2F2u7W/iK0WTfjovYvVVcptegyu6ttZN49KkQtL Message-ID: <06325ee3-e920-d924-4c37-1bff6ec1e2c6@FreeBSD.org> Date: Fri, 21 Sep 2018 08:04:42 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RP9eDrLnNLV5flvccD39zw04LLfWMjItR" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 05:06:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RP9eDrLnNLV5flvccD39zw04LLfWMjItR Content-Type: multipart/mixed; boundary="f80LwHv1gIHTbub7WhYUZdJhUC1ySbt7X"; protected-headers="v1" From: Matthew Seaman To: freebsd-hackers@freebsd.org Message-ID: <06325ee3-e920-d924-4c37-1bff6ec1e2c6@FreeBSD.org> Subject: Re: Can't get pidfile to work in rc script References: In-Reply-To: --f80LwHv1gIHTbub7WhYUZdJhUC1ySbt7X Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 21/09/2018 06:57, Lee Brown wrote: > I'm trying to get 2 separate sshd's running. I've created > /etc/rc.d/sshd_alternate but it always uses /var/run/sshd.pid and not > /var/run/sshd_alternate.pid. I tried >=20 > sshd_alternate_pidfile=3D"${pidfile}" > and > procname=3D"sshd" / procname=3D"/usr/sbin/sshd" >=20 > to no avail. Can somebody provide some assistance, I'm sure this is si= mple > but I just can't fathom it. Did you create /etc/ssh/sshd_config.alternate? In there you'll need to at minimum configure sshd to use a different pidfile and to listen on alternate IPs / port numbers. It's the pidfile setting in the config file that sshd will use -- the setting in the rc.d script just tell the rc system where it can read the daemon's PID in order to signal it. Then you'll need the alternate rc.d startup script which you already seem to have in hand. Cheers, Matthew --f80LwHv1gIHTbub7WhYUZdJhUC1ySbt7X-- --RP9eDrLnNLV5flvccD39zw04LLfWMjItR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAluke+pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDE5 RjE1NEVDQkYxMTJFNTA1NDRFM0YzMDAwNTEzRjEwRTBBOUU0RTcACgkQAFE/EOCp 5OeSlg/+PHYKVE772kEfP+Oc2T91kZ/Mdp4Wzh1KpExbCW+pgoMJ4AmUn+1dnGiT S6bhbdZiTs+xNWIgNo+DQyLZlDmhS6HNZTir0v/Jomn1aB1r3a32yZTx7ZhYUMvd kkxDEKiNv+AifIimdYZbjXtB5fpUO3Lt4GovQhrVI4CXDvY9D8pd7RTYSCIony2e 1wvGNb7VtNfSu2PFARfou3DKijhnxuPlHDGLIfG67vvpfdhJ/ILYFek5P+390wlZ efkRKsDgVb77bJRMVjGuoQs2x+cvZoK/UV2nkBanaggBgjz7zlygRUVMu7JrsOTV 5fGQFVnYWjeRcpGeY75eMgWEPvRnRk3Nik8gQ0Xjwqrc7ZUBLflgGSapK99fgumN mQX9LhSF9163LsidgWEJVVpPXS+ovhz3IQAGq9YfO55EUKTssqE+DkERIoFevWfD NfPlULhaaZMilItln64bjIYuhiRzxILQIiZY8Hb9/foqhXaoYzB+rTu3iF/xbQEJ 1++E4DUJAZ/Nb292EH4mvrWDGV1CujtahiaUSGv9u1tzhYqDgV/aeYd5CL+iHhQx Z9mzwN+WyIPV9J1MoXS5MCyfduu4KQwfLELotO1wxD6IjJSdULwEu66W3kc9wzK4 2I4rMfaFRJsNjTUxQvQmQDudGKbl5S5NTBLocxluxD7sy19ac3Q= =0SDT -----END PGP SIGNATURE----- --RP9eDrLnNLV5flvccD39zw04LLfWMjItR-- From owner-freebsd-hackers@freebsd.org Fri Sep 21 05:38:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3FA8108F77B for ; Fri, 21 Sep 2018 05:38:48 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 765E88F8CF for ; Fri, 21 Sep 2018 05:38:48 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-io1-xd35.google.com with SMTP id r196-v6so11063856iod.0 for ; Thu, 20 Sep 2018 22:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q/ViqiD/7nGbk+Q7hV2mOp68nPf7cAykmT5tH2AnKHw=; b=o1RB8GD88if+Sgy4hdK3YpMq83u3+45bYzusaVdD9Ff2ZjAUTBmj9uVv3BHskM87Kq 9gEwrTsiRX13FyhC7EJ3ApVqQyAl6P9FRcADqpkUJwoVTg2lhTgYazc78xUN5lwhy6Ew k1dm1bjSHhPoZfDRF0cmd13qhrO1Jy2gg+Gq4rBbUv3F303/bcq8ALsrJOvhWRq6Vg0n 8cl/tffYXGIhplokwlyBP/DbcNFlhKtSI5Dt0rh4D8OznjX4a0NBHH8sWC/8Pd2H34M0 POJ+/Lfd1BSLWpEec6QMt4AxT8ZPlqRRJuoguqnOGcD+xFJHgl3i28kKIdePOqJaE8cL ZIPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q/ViqiD/7nGbk+Q7hV2mOp68nPf7cAykmT5tH2AnKHw=; b=dt2JUr+HMS63Q/4VSid3prjonxWE9xObS5N0lus8WN0NGqhieOjtxr/XTdkDHmjt1E vzBZku9RDWEum9VgRv7sk04ZiZxYZCsQYjw83AB0FJF0x0mAgDufnSknzbQzbyptY4j1 MIrnNuBzES9dZzx7Vgy67EgNV6AixCRzYr1xPK9r5+Pl4vST+8RQcvLh7FzP4ezOGVcX Md4GbUsFGSyc/Khp/1ln/uUpGlDqQAr5NWc3Dq/kdnQtjoL2AzKGC1uzA99lr02KpV3I zY/v5IGt/2Mi7HmMPBsZ5MOn9/a9mtxWKoJPalJIxuqsGFWgTrpuXfQHFyN+9ePnBVJJ WeUA== X-Gm-Message-State: APzg51BRqD1+wbFffeHG5U2a4x1ygb8VlHGxn9jF6D7GuNSfc/I4shWE j3HIts4CZ0jHupeTEqhGeJtIpVBemwsNVMOJSsGMcQWT X-Google-Smtp-Source: ANB0VdbHfhJEMbp8t6vANzbPS1lTRgdHWPaIDXfRE9dN/AxbbJ5558CqaYgSNmSse0SaxdamkaPDNx0BftLvSX58TLI= X-Received: by 2002:a6b:f609:: with SMTP id n9-v6mr37634936ioh.259.1537508327708; Thu, 20 Sep 2018 22:38:47 -0700 (PDT) MIME-Version: 1.0 References: <06325ee3-e920-d924-4c37-1bff6ec1e2c6@FreeBSD.org> In-Reply-To: <06325ee3-e920-d924-4c37-1bff6ec1e2c6@FreeBSD.org> From: Lee Brown Date: Thu, 20 Sep 2018 22:38:35 -0700 Message-ID: Subject: Re: Can't get pidfile to work in rc script To: Matthew Seaman Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 05:38:49 -0000 On Thu, Sep 20, 2018, 10:06 PM Matthew Seaman wrote: > On 21/09/2018 06:57, Lee Brown wrote: > > I'm trying to get 2 separate sshd's running. I've created > > /etc/rc.d/sshd_alternate but it always uses /var/run/sshd.pid and not > > /var/run/sshd_alternate.pid. I tried > > > > sshd_alternate_pidfile="${pidfile}" > > and > > procname="sshd" / procname="/usr/sbin/sshd" > > > > to no avail. Can somebody provide some assistance, I'm sure this is > simple > > but I just can't fathom it. > > Did you create /etc/ssh/sshd_config.alternate? In there you'll need to > at minimum configure sshd to use a different pidfile and to listen on > alternate IPs / port numbers. It's the pidfile setting in the config > file that sshd will use -- the setting in the rc.d script just tell the > rc system where it can read the daemon's PID in order to signal it. > > Then you'll need the alternate rc.d startup script which you already > seem to have in hand. > > Cheers, > > Matthew > Thank you Matthew, Yes a separate port and config as you correctly surmise. My assumption was that the rc framework created the pidfile. I'm going to re-read the rc.subr manpage tomorrow as I obviously misunderstood how it works. Thanks to all - lee > > From owner-freebsd-hackers@freebsd.org Fri Sep 21 10:46:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 663D51095A6F for ; Fri, 21 Sep 2018 10:46:42 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [IPv6:2a01:4f8:d0a:2645::2]) (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 DBCD87878B for ; Fri, 21 Sep 2018 10:46:41 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1g3IxE-0007sg-KB for freebsd-hackers@freebsd.org; Fri, 21 Sep 2018 12:46:32 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1g3IxD-000Dbh-NX for freebsd-hackers@freebsd.org; Fri, 21 Sep 2018 12:46:32 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 91CFC2A165C for ; Fri, 21 Sep 2018 12:47:05 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WSPMELRzWg7t for ; Fri, 21 Sep 2018 12:47:03 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 5C0032A167E for ; Fri, 21 Sep 2018 12:47:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SeauUA43TbEO for ; Fri, 21 Sep 2018 12:47:03 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 2FBA42A165C for ; Fri, 21 Sep 2018 12:47:03 +0200 (CEST) Subject: Re: epoch(9) background information? From: Sebastian Huber To: FreeBSD References: Message-ID: Date: Fri, 21 Sep 2018 12:46:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.1/24965/Fri Sep 21 07:57:08 2018) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 10:46:43 -0000 Hello, I ported the epoch API to RTEMS. You can find the implementation here: https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/sys/epoch.h https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-epoch= .c I tested it also on low end uniprocessor targets and it works fine, e.g. * Microchip ATSAM V71 (ARMv7-M) * NXP MCF548x (ColdFire) * NXP MPC860 (PowerPC 32-bit) I tested it also on a 24-core T4240. It scales pretty well. See also: https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c If someone has ideas for good test cases, then please let me know. I modified the CK a bit to better support RTEMS targets: https://git.rtems.org/rtems-libbsd/commit/?id=3Dbaf1ca76290f43e054e5182c1= 47ca332cb59890f https://git.rtems.org/rtems-libbsd/commit/?id=3D3becda1fef854cbe39e462a17= 74b860e1455c8ef https://git.rtems.org/rtems-libbsd/commit/?id=3D1af372a5eeaba3115f139e4ef= c0204e2cd7208bb https://git.rtems.org/rtems-libbsd/commit/?id=3Dbe6515d2c1086c76ee965c630= 0cc5873c76afab9 --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Fri Sep 21 14:07:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F50F109B432 for ; Fri, 21 Sep 2018 14:07:56 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E69A480B8D for ; Fri, 21 Sep 2018 14:07:55 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-qk1-x733.google.com with SMTP id z186-v6so565892qkb.13 for ; Fri, 21 Sep 2018 07:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firepipe-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=en5PuwX8aJ4xx4T5wDZi2ZHeqd+hqKCWTIbmBAtllBw=; b=bp755jdk0bpUwcM6cuCN5DQ9n3bZMuHqjVFrxdtl0gLW2uUg7Cr99dx3c97VTuxLcr R6Ukfrp7u/te19wjBBLw3apXzj4UytCCLO+xkovZQQxQnzAGsO5Z5fHrIRJ0Osbb83Lw vjq73GdSwY6T9pzqKMDoGYqS6KCADOEv+pBwj71weJMnZlncRus4mUY8udT4Sx7GD1j+ s8umH8zlyFVmNv0rzgt0GZsitlzFnaFGw1zTSbIE9YBwgHH8/hHoGq1GEl4QBhLpQX1M icvsK4TmdaPynE0jxmOgFBPwowEeN2ug4flqH3scMV168e8YjnIUVCTehxdUA+5YTgsk ag8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=en5PuwX8aJ4xx4T5wDZi2ZHeqd+hqKCWTIbmBAtllBw=; b=r+K1JsP2bWXxSgVuWTKaamUKn/5PPEfEBz88FlM+5G6BUT6zcNzfTMsehsdOQC608M j6BSmSzvP3jjq+akCNioUmpb439D9NB/eFXGVdSDEI2RQLDf2VDwOCiZGcu0cLGLNAdt qLhd8lXZxPZulX30JQQGlQtDCnLvV6XvTpBRtStFqV9LifVLKE13s0eaPx3NsuVZlEBE 8UmEBOPsImJnCa4yFtw20ASDoOF4CqO86Yin3ptKkPdqLBB3U/9Yab0/RvMeWvd7Ma5N mfllHr7zJIjLjQU4p3qdK/mFPsse4104FC+sRbtNKCisn81rcQimNd4AxVdQdOVMLKxh rUJg== X-Gm-Message-State: APzg51CKg8HZpueTU7s6Jy7XRvP/bQg2uva9yB1sSpWbAFa2QOvXeGWL jry8MAw1dqns9jXv4HUMGJuzwA/zIXRpmYtTXr1kYxYVfr0= X-Google-Smtp-Source: ANB0VdZa/N+2I9yPDVjxGZr0LTvuioLOKPKmyS9Y6Mx4TkIp9QSm8zSneOzJmV5Rp0DCxtVifawnTa3c9yR72H0toXM= X-Received: by 2002:a37:7a86:: with SMTP id v128-v6mr30637441qkc.218.1537538874859; Fri, 21 Sep 2018 07:07:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Will Andrews Date: Fri, 21 Sep 2018 09:07:43 -0500 Message-ID: Subject: Re: epoch(9) background information? To: sebastian.huber@embedded-brains.de Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 14:07:56 -0000 On Fri, Sep 21, 2018 at 5:47 AM Sebastian Huber < sebastian.huber@embedded-brains.de> wrote: > I modified the CK a bit to better support RTEMS targets: > > > https://git.rtems.org/rtems-libbsd/commit/?id=baf1ca76290f43e054e5182c147ca332cb59890f > > https://git.rtems.org/rtems-libbsd/commit/?id=3becda1fef854cbe39e462a1774b860e1455c8ef > > https://git.rtems.org/rtems-libbsd/commit/?id=1af372a5eeaba3115f139e4efc0204e2cd7208bb > > https://git.rtems.org/rtems-libbsd/commit/?id=be6515d2c1086c76ee965c6300cc5873c76afab9 Hi, You should open pull requests at http://github.com/concurrencykit/ck - the maintainers routinely review and integrate. --Will. From owner-freebsd-hackers@freebsd.org Fri Sep 21 14:21:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7262E109BB33 for ; Fri, 21 Sep 2018 14:21:52 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 029458157D for ; Fri, 21 Sep 2018 14:21:51 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm1-x336.google.com with SMTP id n11-v6so3477180wmc.2 for ; Fri, 21 Sep 2018 07:21:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uCtHD0uoKCMKHXRGwF/db9p/xyWx76ksQQ9+gOEbIhI=; b=dJzIQMtelDdCmTiO4OGfKmfWqX4xojNKGTA3iEQT85APH816dg6m4Zt0cxqGi9uWbz bW3SAv4P6JYvDOlRoEM9QBwH/HjSR9gTNVMFt4Vn5qrPtZEDYpFyNMtypQn8GypyXy1q yJy6T4fpncYJqBveCwHhLqGAcqWt+6r2vwFK0KC4kYI6i6ZZ+vAOlVjrRx65DQ5ymdSQ JwsR3qnFp0zvI5F7W74eTn+TJUtHHZ2oD6S68/kr5buBrPG/Op2PJi+I+9q9eBJfkpWF tReLtXDQPa9wEqTDKXqrMJRyln5IYNFODIPt02nvf6RNO3S0XTXGyxNsbvU5CoZ1Swo9 G1bg== X-Gm-Message-State: APzg51B82nVPtxQOj1DWhVUmQ9Yi7Ayjve+3HtdsXQuU4+aGDga/OsLn 4rYWIxRjIhSzwRKBmwtn7B4iP/nO X-Google-Smtp-Source: ACcGV602kLbJqREGTBqjaYwdURcVS5nJXQ0rjFmpHb1zs/xJ4lAHG4bhbXDt5Fx/Qbj9voL4yGEDyw== X-Received: by 2002:a1c:ba46:: with SMTP id k67-v6mr7110655wmf.37.1537539710534; Fri, 21 Sep 2018 07:21:50 -0700 (PDT) Received: from gumby.homeunix.com ([2.125.48.184]) by smtp.gmail.com with ESMTPSA id y5-v6sm31124184wrd.5.2018.09.21.07.21.49 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 21 Sep 2018 07:21:50 -0700 (PDT) Date: Fri, 21 Sep 2018 15:21:48 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Can't get pidfile to work in rc script Message-ID: <20180921152148.562c2771@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 14:21:52 -0000 On Thu, 20 Sep 2018 20:57:09 -0700 Lee Brown wrote: > I'm trying to get 2 separate sshd's running. I've created > /etc/rc.d/sshd_alternate but it always uses /var/run/sshd.pid and not > /var/run/sshd_alternate.pid. I tried > > sshd_alternate_pidfile="${pidfile}" Usually the pid file specified in an rc file is telling the script what the daemon is using. sshd doesn't seem to have a direct way of setting the pid file path, I think you would have to create an alternate sshd_config and pass that as an argument to sshd. From owner-freebsd-hackers@freebsd.org Fri Sep 21 18:28:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F7A10A0845 for ; Fri, 21 Sep 2018 18:28:22 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 382E18ACA3 for ; Fri, 21 Sep 2018 18:28:22 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w8LIS4AA055489 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 21 Sep 2018 20:28:04 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w8LIRx2s055486 for ; Fri, 21 Sep 2018 20:27:59 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Fri, 21 Sep 2018 20:27:59 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: attempt to make UEFI bootable pendrive Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 18:28:22 -0000 i've made pendrive with GPT as for UEFI boot gpart da0 shows => 40 30998448 da0 GPT (15G) 40 1600 1 efi (800K) 1640 24 - free - (12K) 1664 30996800 2 freebsd-ufs (15G) 30998464 24 - free - (12K) efi partition filled from /boot/boot1.efifat, partition 2 with FreeBSD installed, /boot populated etc. all done as per https://wiki.freebsd.org/UEFI tried with qemu as in this tutorial the result is as follows: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: \EFI\BOOT\BOOTX64.EFI Load Device: PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,GPT,2C0157FF-BDC7-11E8-A22C-3C52820D28A6,0x28,0x640) BootCurrent: 0004 BootOrder: 0000 0001 0002 0003 0004[*] 0005 0006 0007 Probing 6 block devices......*.. done ZFS found no pools UFS found 1 partition Failed to start image provided by UFS (9) !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 I:0 R:0 U:0 W:0 P:0 PK:0 S:0 RIP - 0000000007F16F6F, CS - 0000000000000038, RFLAGS - 0000000000000202 RAX - 0000000000000001, RCX - 0000000000000010, RDX - 0000000007F0A75C RBX - 000000000000000E, RSP - 0000000007F0A690, RBP - 0000000007F0A75C RSI - 0000000007F0A75C, RDI - 000000000000000E R8 - 0000000000000000, R9 - 00000000068A7270, R10 - 000000008010E640 R11 - 0000000000000000, R12 - 00000000068AF420, R13 - 0000000000000001 R14 - 0000000007F0A75C, R15 - 0000000000000000 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - FFFFFFFFFFFFFFF6, CR3 - 0000000007C01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000 IDTR - 00000000072BF018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 0000000007F0A2F0 !!!! Find image based on IP(0x7F16F6F) /home/jenkins/workspace/edk2/rpms/build/edk2-g4423f0bc61/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePk what i am doing wrong? From owner-freebsd-hackers@freebsd.org Fri Sep 21 18:33:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FCD710A0B18 for ; Fri, 21 Sep 2018 18:33:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.34]) (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 DD4618B0B0 for ; Fri, 21 Sep 2018 18:33:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fIxfl5MVM1k.U2UxY64958KGOA26cwYN79FOSdT2JYNvhXlfUQ_nDYi3KizfOvt _3wIVMjtZG2eSCTe4fZZzAaHVKUUpThe3Qb3q7iAFKuAzroYwVu7TKYTS2pco7W5ahc7U05DN.OX FJwQ3j2Lj_MTcanRtqtXXN9Mtk3iuvrwfttyLjozw8gLqLnWeUE_ZFj9kEsPiwsDAm563_IwI71W GYPhtFuLyp1IxKy7SR4oSYI4TY6P.PAn9O26vqrWkTClpj3do41rxVEiCF3krHuI0Jhu9Mwwv38T CTZSAfN.MLMLzJsKb6S0Nv0CYhEqyctG9CbCNS6R9vEn35GY4SY0Q8sE_GZvmwexvhcMt7nft17I Fdc_5Zg2N2ViPGiiO2APfU_U.WHK0GgB8ZZZ8oBtBZ0U84A3U5b2RLET65Om31WAOHn0KuUZ87PB 7Ia1i0DE1MMnpYMLzYVrEV2TDR5CZ.eQRvQWPaQLMw8IzSjBBFJsEN14WALVvyq6tNLwJBtaREqs rlYqTsrqcAI2sOhEyPeIT1DFGl6qDp.Z0sRB9cMBUK64Qh3P17vJFq5nPB5xbPUWQ7Q0bxN2RNuM Tq_Gv2TszbFBArlsE1vRyGB1TK30nzrjUStb37iN17dZuHDcfl8CxU67OYjhemd.ZEJcnoO591F4 eu9HB0LPPYHuhRft4R9ucVKFzirU1CFge89EEw2.ojhAzAa6dSYvbyhvcawwqf7ULgW.yMrL8XXi oHwU3nmJ8JX4ljjrGJcq2_84W8p4scLOgoq2rapk2lrTzOGhpN2WjhUIIfRELGHfSyjsOpuaoQEf xLW71Z93vmiftRA61hvT1GEsivUEu6n43Dzf_OmPEGvyyiK6Bql.eylLrqSASqedm0pCHg6I1854 _ai1BE6kFlVY6fisWeQjGHHTkZNRvJwj_37riQ1ITaLu8AaiunB5xZkGWB4aor7pzLed7EEuFU4S ld4XmXWg_5HDsXMpU.XNFDUxihTi2BHn3mgW9dlW7uKJXC06.opjEJsZeTsv93.5xjEY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 21 Sep 2018 18:33:50 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0412e9fab9b86c812583c99f0d201529 for ; Fri, 21 Sep 2018 18:33:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? Date: Fri, 21 Sep 2018 11:33:44 -0700 References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> To: freebsd-hackers@freebsd.org In-Reply-To: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> Message-Id: <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 18:33:52 -0000 [I decided that freebsd-hackers might be better for this, under a different wording.] sys/dev/fxp/if_fxp.c uses the statement: cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << 16); But sys/dev/fxp/if_fxpreg.h has the types involved as: struct fxp_cb_tx { uint16_t cb_status; uint16_t cb_command; uint32_t link_addr; uint32_t tbd_array_addr; uint16_t byte_count; uint8_t tx_threshold; uint8_t tbd_number; /* * The following structure isn't actually part of the TxCB, * unless the extended TxCB feature is being used. In this * case, the first two elements of the structure below are * fetched along with the TxCB. */ union { struct fxp_ipcb ipcb; struct fxp_tbd tbd[FXP_NTXSEG + 1]; } tx_cb_u; }; So cbp->tbd is not pointing into the middle of an array. Thus the cbp->tbd[-1].tb_size =3D . . . assignment trashes memory from what I can tell. /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: /* Configure TSO. */ if (m->m_pkthdr.csum_flags & CSUM_TSO) { cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << = 16); cbp->tbd[1].tb_size |=3D htole32(tcp_payload << 16); cbp->ipcb_ip_schedule |=3D FXP_IPCB_LARGESEND_ENABLE | FXP_IPCB_IP_CHECKSUM_ENABLE | FXP_IPCB_TCP_PACKET | FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; } This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. This is also when the "+ 1" was added to the: struct fxp_tbd tbd[FXP_NTXSEG + 1] above. clang 7 via xtoolchain-llvm70 reported: --- if_fxp.o --- /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before = the beginning of the array [-Werror,-Warray-bounds] cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << = 16); ^ ~~ /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared here struct fxp_tbd tbd[FXP_NTXSEG + 1]; ^ 1 error generated. *** [if_fxp.o] Error code 1 It does look odd to me. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Sep 21 19:22:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70B0310A1CEF for ; Fri, 21 Sep 2018 19:22:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10D1E8CCF5 for ; Fri, 21 Sep 2018 19:22:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io1-xd2c.google.com with SMTP id y3-v6so13257217ioc.5 for ; Fri, 21 Sep 2018 12:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XkdSF852DSIiArO9DHc8b4GLUjSsj0qpCt+BgSSM0Qo=; b=g1QDKLrAFWB7hOGmZZXSmLwa2klyD1REHKZPQ1TDuF7X9Ieqkruq2J2pNspFkTKqT/ XIpsOFNOEhgRUyZxunI5wGv+MIPBCJq0QPgqWJy0ozS0xS0Ix/YYiCIQK1Zl1T30Mu3X G8DAgq0JJEIA7E3klaibLT3rLqpY2Tcq6bGfldz4C2beoMO6jRShuUC+XXLMpWxkNMM2 u8VNr9CAyG+CCfsN9dFn4cwHNwOYbBrzDwrZAiUPPco1BqTUxKYpXAnVgYszpceax8Aa I9IX61UNNaIvr2YKBdRTuoHpMpH8pRsBTGZejU95vR4fjxvhfjPMk2BC05c32NgWF+Po 3+LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XkdSF852DSIiArO9DHc8b4GLUjSsj0qpCt+BgSSM0Qo=; b=Wb3P632aOPpyAf8/Tfgl2oPYGfOzDj/gBFmv5smyFFK7xNmcPr4Av3xlzJ9+w+dHSn DOAjwqycfdO+PfqVyzZ+kz+K2P51zTwSAY6dnJnEVEy6T+sPD+EJGLpqCkKkTmhOD+C6 V/1ZBnG0DVjNmqRGCMEeG0ZabAQDqlvUfrTvjEKjCb0MKsfWZLBRHJ4UU87NaPlXZ99z b75D1RUidtaYxFjHJdGaAeCHYFqc1rU09CEakJO6IQXqJmbcvIqELYotj08nfTz/Cx3x 8Z5bWrgUTIJ4EO1PoJr5mNO/VZ3s6uCJvE5k9flMS/wvaKtYFyJabgP4dpG2WYmVvsvB vAXQ== X-Gm-Message-State: APzg51A/P/le+nr91DgULZUfyZzAJHzx0VfcRT9B+2CbI/lmTak/x9xb UIE++2jCSUaN1BArTLUxCR+ReWammEhIUEr9rbRD3w== X-Google-Smtp-Source: ANB0VdaRPaOgyaIjo7w2dnunftJhm2ODNtyRTuWGFcXtui0QnLyMjOkGbPc68urmcOzXZ5aDMDkXHYC/ORteQDEfxcc= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr38283050ioa.168.1537557730848; Fri, 21 Sep 2018 12:22:10 -0700 (PDT) MIME-Version: 1.0 References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> In-Reply-To: <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> From: Warner Losh Date: Fri, 21 Sep 2018 13:21:59 -0600 Message-ID: Subject: Re: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? To: Mark Millard Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 19:22:12 -0000 On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers < freebsd-hackers@freebsd.org> wrote: > [I decided that freebsd-hackers might be better for this, > under a different wording.] > > sys/dev/fxp/if_fxp.c uses the statement: > > cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16); > > But sys/dev/fxp/if_fxpreg.h has the types involved as: > > struct fxp_cb_tx { > uint16_t cb_status; > uint16_t cb_command; > uint32_t link_addr; > uint32_t tbd_array_addr; > uint16_t byte_count; > uint8_t tx_threshold; > uint8_t tbd_number; > > /* > * The following structure isn't actually part of the TxCB, > * unless the extended TxCB feature is being used. In this > * case, the first two elements of the structure below are > * fetched along with the TxCB. > */ > union { > struct fxp_ipcb ipcb; > struct fxp_tbd tbd[FXP_NTXSEG + 1]; > } tx_cb_u; > }; > > So cbp->tbd is not pointing into the middle of an array. > Thus the cbp->tbd[-1].tb_size = . . . assignment trashes memory > from what I can tell. > > /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: > > /* Configure TSO. */ > if (m->m_pkthdr.csum_flags & CSUM_TSO) { > cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16); > cbp->tbd[1].tb_size |= htole32(tcp_payload << 16); > cbp->ipcb_ip_schedule |= FXP_IPCB_LARGESEND_ENABLE | > FXP_IPCB_IP_CHECKSUM_ENABLE | > FXP_IPCB_TCP_PACKET | > FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; > } > > This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. > > This is also when the "+ 1" was added to the: > > struct fxp_tbd tbd[FXP_NTXSEG + 1] > > above. > > clang 7 via xtoolchain-llvm70 reported: > > --- if_fxp.o --- > /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before the > beginning of the array [-Werror,-Warray-bounds] > cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16); > ^ ~~ > /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared here > struct fxp_tbd tbd[FXP_NTXSEG + 1]; > ^ > 1 error generated. > *** [if_fxp.o] Error code 1 > > It does look odd to me. > So I did some digging into this a few months ago. It turns out the code is right, kinda. So, what's it's doing with the [-1] is as follows: the sizeof tbd is 8 bytes long. So, we're dereferencing 8 before the array, which points to tbd_array_addr. However tb_size is the second element of that, so that points us at count + tx_threshold + tbd_number. So, this code is setting count = 0 and tx_threshold to the low order bits of the segment size and tbd_number to the high order bits. We set the count = 0 later anyway, so that part of it isn't so bad. Since this is in hardware, it may be special meanings for these bits, and this 'trick' is used to just do one write rather than two. I've not looked for the hardware manual to see if this is kosher, but that's what we're doing. It's not as crazy stupid as it sounds at first blush. Warner From owner-freebsd-hackers@freebsd.org Fri Sep 21 20:05:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03C2010A2B0F for ; Fri, 21 Sep 2018 20:05:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-9.consmr.mail.gq1.yahoo.com (sonic315-9.consmr.mail.gq1.yahoo.com [98.137.65.33]) (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 675E18E03B for ; Fri, 21 Sep 2018 20:05:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: md.fQ2UVM1nGSDuPm1OGy7ZGQB9VUxbT8QANwFGTHZmxSJ8BVPjXKVN8_f_bZEO w5HqR6X6ItHZrj1MRcsxDdIYR2cJGSPtG8xJbvsVzoxwb3RXaLbhpSnGAoLwDPLXOP88R2kliqFl IJwLvp1i1R9PG3o1G6CnlR5YrrAJjcXuEnmpMVh15cNg_OuvSZOi2YchZcYKIDsZBqr2u_67osu7 G.e3bqPl924.Jg8TE.dl.E3iFoSoZgCPDS9Mn836NpkaBLVVEmYmO_m8P2R2fpBRcoX9YtxBSiGU 6.9gnBACp8L1hg2vK.KHqyREO3tTa5JVVmVwGDIzYpxkEmU9yjdvJF1HrpFnUCjS1f1VSRGucJRZ WfGktc3.dUztzHVfF3EyCy7PEQAnsc53scwb31hncNrEtNanLPUh4AduYLUyP9TAnlDUC3UEiIg. 1Q3xaLuEnzIEn8F5lzN8fbdVF.OxOobyQHUpbxOG8LHXEA6pZ5v4.hWV4PJvnS8lgvKu1pkRPJrd wz1ejgM_FOU20lI5nEz_Meo5yqPipXXgEsvEU3C6ihUYselpo.Pg_ocO2_jUGD1Q9hu6KhGLY7qF oPDyOWmrFyx.QTgifG_Qz68MTuaMs0HBR6fcO4SONxsWJJr9OlVI6KqbMJAe9.yPqZp_kVaTE9tF 45ThAX6oBiWKXlhlSyHyOwTQuch3TDr5cCvAuwXlkVtCzjkorfH4HH_aT3ub3zp5_mRogvRpjUTX GfPJsq_X1sSM11XWUp5J0XuLxnr7IcascMKZWIMpbpfxPeQ7nuYYGYCjE0D5nqO3KuP1wb7WK2HA c5cG7yDqTx6zyyWY71Zi420KVqrdxjH5fnoQ8P7NoNlq0mdm.KWObvCrrT1YalyoFd2mL6jUfwV9 0x75kmBMlGiVqtoX6RpxKY.RTpaXw5_uw9BO3A297D4r6.Fp_TAMA15N2FD3s3Zm_pZJxtTzv6zG IsNWHpjcgBpCdhCtXu1aMptDzxx9eqddJOjX2bvzTFwVe2PvnqVaRXCFQUGcCCKZstsJ7tDgztJJ 5Nv8iaL6T2w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Sep 2018 20:05:21 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ddb9285f827cbf93eed35fe4292197d7; Fri, 21 Sep 2018 19:55:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? From: Mark Millard In-Reply-To: Date: Fri, 21 Sep 2018 12:55:11 -0700 Cc: "freebsd-hackers@freebsd.org" , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 20:05:29 -0000 On 2018-Sep-21, at 12:21 PM, Warner Losh wrote: >> On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers = wrote: >> [I decided that freebsd-hackers might be better for this, >> under a different wording.] >>=20 >> sys/dev/fxp/if_fxp.c uses the statement: >>=20 >> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << 16); >>=20 >> But sys/dev/fxp/if_fxpreg.h has the types involved as: >>=20 >> struct fxp_cb_tx { >> uint16_t cb_status; >> uint16_t cb_command; >> uint32_t link_addr; >> uint32_t tbd_array_addr; >> uint16_t byte_count; >> uint8_t tx_threshold; >> uint8_t tbd_number; >>=20 >> /* >> * The following structure isn't actually part of the TxCB, >> * unless the extended TxCB feature is being used. In this >> * case, the first two elements of the structure below are >> * fetched along with the TxCB. >> */ >> union { >> struct fxp_ipcb ipcb; >> struct fxp_tbd tbd[FXP_NTXSEG + 1]; >> } tx_cb_u; >> }; >>=20 >> So cbp->tbd is not pointing into the middle of an array. >> Thus the cbp->tbd[-1].tb_size =3D . . . assignment trashes memory >> from what I can tell. >>=20 >> /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: >>=20 >> /* Configure TSO. */ >> if (m->m_pkthdr.csum_flags & CSUM_TSO) { >> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz = << 16); >> cbp->tbd[1].tb_size |=3D htole32(tcp_payload << 16); >> cbp->ipcb_ip_schedule |=3D FXP_IPCB_LARGESEND_ENABLE | >> FXP_IPCB_IP_CHECKSUM_ENABLE | >> FXP_IPCB_TCP_PACKET | >> FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; >> } >>=20 >> This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. >>=20 >> This is also when the "+ 1" was added to the: >>=20 >> struct fxp_tbd tbd[FXP_NTXSEG + 1] >>=20 >> above. >>=20 >> clang 7 via xtoolchain-llvm70 reported: >>=20 >> --- if_fxp.o --- >> /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before = the beginning of the array [-Werror,-Warray-bounds] >> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz = << 16); >> ^ ~~ >> /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared = here >> struct fxp_tbd tbd[FXP_NTXSEG + 1]; >> ^ >> 1 error generated. >> *** [if_fxp.o] Error code 1 >>=20 >> It does look odd to me. >>=20 > So I did some digging into this a few months ago. >=20 > It turns out the code is right, kinda. >=20 > So, what's it's doing with the [-1] is as follows: >=20 > the sizeof tbd is 8 bytes long. So, we're dereferencing 8 before the = array, which points to tbd_array_addr. However tb_size is the second = element of that, so that points us at count + tx_threshold + tbd_number. = So, this code is setting count =3D 0 and tx_threshold to the low order = bits of the segment size and tbd_number to the high order bits. We set = the count =3D 0 later anyway, so that part of it isn't so bad. >=20 > Since this is in hardware, it may be special meanings for these bits, = and this 'trick' is used to just do one write rather than two. I've not = looked for the hardware manual to see if this is kosher, but that's what = we're doing. It's not as crazy stupid as it sounds at first blush. Thanks for the explanation. Too bad the code does not document the hack. Looks like xtoolchain-llvm70 use will require avoiding reporting this as an error that stops buildkernel, a change for the build environment. Of course, that may well wait for head to be 13 instead of 12. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Sep 21 20:14:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AE5510A2F47 for ; Fri, 21 Sep 2018 20:14:58 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 3B0408E6E1 for ; Fri, 21 Sep 2018 20:14:58 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7991B3C4760; Fri, 21 Sep 2018 20:14:57 +0000 (UTC) Date: Fri, 21 Sep 2018 20:14:57 +0000 From: Brooks Davis To: Warner Losh Cc: Mark Millard , "freebsd-hackers@freebsd.org" Subject: Re: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? Message-ID: <20180921201457.GB47693@spindle.one-eyed-alien.net> References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 20:14:58 -0000 --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2018 at 01:21:59PM -0600, Warner Losh wrote: > On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers < > freebsd-hackers@freebsd.org> wrote: >=20 > > [I decided that freebsd-hackers might be better for this, > > under a different wording.] > > > > sys/dev/fxp/if_fxp.c uses the statement: > > > > cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << 16); > > > > But sys/dev/fxp/if_fxpreg.h has the types involved as: > > > > struct fxp_cb_tx { > > uint16_t cb_status; > > uint16_t cb_command; > > uint32_t link_addr; > > uint32_t tbd_array_addr; > > uint16_t byte_count; > > uint8_t tx_threshold; > > uint8_t tbd_number; > > > > /* > > * The following structure isn't actually part of the TxCB, > > * unless the extended TxCB feature is being used. In this > > * case, the first two elements of the structure below are > > * fetched along with the TxCB. > > */ > > union { > > struct fxp_ipcb ipcb; > > struct fxp_tbd tbd[FXP_NTXSEG + 1]; > > } tx_cb_u; > > }; > > > > So cbp->tbd is not pointing into the middle of an array. > > Thus the cbp->tbd[-1].tb_size =3D . . . assignment trashes memory > > from what I can tell. > > > > /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: > > > > /* Configure TSO. */ > > if (m->m_pkthdr.csum_flags & CSUM_TSO) { > > cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz <<= 16); > > cbp->tbd[1].tb_size |=3D htole32(tcp_payload << 16); > > cbp->ipcb_ip_schedule |=3D FXP_IPCB_LARGESEND_ENABLE | > > FXP_IPCB_IP_CHECKSUM_ENABLE | > > FXP_IPCB_TCP_PACKET | > > FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; > > } > > > > This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. > > > > This is also when the "+ 1" was added to the: > > > > struct fxp_tbd tbd[FXP_NTXSEG + 1] > > > > above. > > > > clang 7 via xtoolchain-llvm70 reported: > > > > --- if_fxp.o --- > > /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before t= he > > beginning of the array [-Werror,-Warray-bounds] > > cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz <<= 16); > > ^ ~~ > > /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared here > > struct fxp_tbd tbd[FXP_NTXSEG + 1]; > > ^ > > 1 error generated. > > *** [if_fxp.o] Error code 1 > > > > It does look odd to me. > > >=20 > So I did some digging into this a few months ago. >=20 > It turns out the code is right, kinda. >=20 > So, what's it's doing with the [-1] is as follows: >=20 > the sizeof tbd is 8 bytes long. So, we're dereferencing 8 before the arra= y, > which points to tbd_array_addr. However tb_size is the second element of > that, so that points us at count + tx_threshold + tbd_number. So, this co= de > is setting count =3D 0 and tx_threshold to the low order bits of the segm= ent > size and tbd_number to the high order bits. We set the count =3D 0 later > anyway, so that part of it isn't so bad. >=20 > Since this is in hardware, it may be special meanings for these bits, and > this 'trick' is used to just do one write rather than two. I've not looked > for the hardware manual to see if this is kosher, but that's what we're > doing. It's not as crazy stupid as it sounds at first blush. WG14 is discussing making this definitly UB in the next C standard (many members think it already is, but this would make it more explict). If this is required we need to find a better way to express it. -- Brooks --DBIVS5p969aUjpLe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbpVFAAAoJEKzQXbSebgfATwcH/iWq3SQ0Fx/PT5Loj5YWUM6A Hy/i4X2fuEoDvdIekU1DbxBefwILtvL3NAxj4n64/hV8aNQeroQq8hwAh23wqG8P +q2izscYeGf0BNGWIjEVXB55D1XG7o71K3ZCguA/J6UN5gNy+soqXwwgJz5YDwBn 8kOCUKWS/uk+tjbK/FoDDzcwojFcXEyw5x78mVlAWzJNDsZvJjda7m4bCY/Vu2OK QWjUvaKGLfQTP4hgQ2Vgg9UUnKObfj1OiNHHbkb0nHN8jjTfgf5l24olwCa/P+Js XcuRLzjzs40Lki4WbPOnRymxVlsCvUrOnxINrcDVGHZd+qhWQ0tYdswQolsCRXw= =yySh -----END PGP SIGNATURE----- --DBIVS5p969aUjpLe-- From owner-freebsd-hackers@freebsd.org Fri Sep 21 21:22:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9947210A492E for ; Fri, 21 Sep 2018 21:22:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-9.consmr.mail.gq1.yahoo.com (sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.33]) (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 2373970FC5 for ; Fri, 21 Sep 2018 21:22:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OIZ1xO4VM1kpBp9F8VU1zsIL.qjWlHhyb5jpLlCB2Q1hWoL_32ZuW5X8FI03cW8 GVNILgrSHrrs5WQywxr70BFehyZYBgdW.5_FruAaIFGRtXY2cwGwHQLdllr5NIkbfcCb1XMFdXaM cIMIxXowtSfabLPfKFm_x_KrIpS2AJ6v42Skz8XAaqVY.IjVa31dXOlhJLUcOry7TgUEweiiBkMG P4TvJmteimk_v_hfFstA5XqnO7D3GEBvL9F92HRju5z0BQp8G0ynYw4DevObrZ_F9LCPM10RjiyS _n2GhNL2.VmraVONTneMU06jf3CVq_LApmxsw4ADH7HZltNXnVDSa2P7YmCZZBoBY9cQG40VoJsr ES0UWu78OSaF6QOV6.KccGGh0znRxJBr_1sAbeRBQtp.y.D.50FTS6BvbY.Chp6VeVogUu5rNf0_ xD3AE995iZ5W62j_si8kuSi_ND01BEplYYTJWOMWZooERd2X_EfaXNBhdqAxYcpZl4fNrvqjyZSA V_deAVP4mNkngOnP7CwOaN031WVzm13XCDFG057beh2XmeMwbSl6ZlATJirkuP6O5ntsVmaE.afk pX9pR2RWSBPRNhtSdz.oEPwYBWYQ27KyNPYwa7v2GWX7U4NEto08Et.vw6YasH2GEIEAdyJaJi_2 Shk3meaqH2guiVwHF_sbU5aK2OzxTxasgsPRpdYBGlyO5gXq74D9z7vvxqv4QTMeSzaHsRmxJ7Yo b0txkfQRrDCir9lplm6URIcdNqtbA8E0KWQfeRX42SY.WPKN_HJEZQ.ewe0ORyKyhATkRjhdTlaW Faf03KXKxcME5NIeIIhqQaoqi3.Wt1cNuNjkuqoUKzY_G_Ecfz6pU5nOP36Wjjh1P_3D69v3h5hm n5T6sElwTa1d6NvJ2_xxauEGjrPcM.rKILZkNNz9zwI5hE3HG9rdG6nzVimeUEh5LhM__kRb1h_H 5cSwT1SzMdqY1xdW_vlaU.CxOmXFwTh9Re1KelGF4qGLuj3As4t5h6eLQ9IRJOOl2ko1u2NyJmIm 8NvCabqC9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Sep 2018 21:22:35 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9015c8dae306f8c6d88e7c38e885d1f5; Fri, 21 Sep 2018 21:22:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? From: Mark Millard In-Reply-To: <20180921201457.GB47693@spindle.one-eyed-alien.net> Date: Fri, 21 Sep 2018 14:22:33 -0700 Cc: Warner Losh , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8AB15D63-664F-4B88-B37F-0900717AA2B9@yahoo.com> References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> <20180921201457.GB47693@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 21:22:44 -0000 On 2018-Sep-21, at 1:14 PM, Brooks Davis wrote: > On Fri, Sep 21, 2018 at 01:21:59PM -0600, Warner Losh wrote: >> On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers < >> freebsd-hackers@freebsd.org> wrote: >>=20 >>> [I decided that freebsd-hackers might be better for this, >>> under a different wording.] >>>=20 >>> sys/dev/fxp/if_fxp.c uses the statement: >>>=20 >>> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz << 16); >>>=20 >>> But sys/dev/fxp/if_fxpreg.h has the types involved as: >>>=20 >>> struct fxp_cb_tx { >>> uint16_t cb_status; >>> uint16_t cb_command; >>> uint32_t link_addr; >>> uint32_t tbd_array_addr; >>> uint16_t byte_count; >>> uint8_t tx_threshold; >>> uint8_t tbd_number; >>>=20 >>> /* >>> * The following structure isn't actually part of the TxCB, >>> * unless the extended TxCB feature is being used. In this >>> * case, the first two elements of the structure below are >>> * fetched along with the TxCB. >>> */ >>> union { >>> struct fxp_ipcb ipcb; >>> struct fxp_tbd tbd[FXP_NTXSEG + 1]; >>> } tx_cb_u; >>> }; >>>=20 >>> So cbp->tbd is not pointing into the middle of an array. >>> Thus the cbp->tbd[-1].tb_size =3D . . . assignment trashes memory >>> from what I can tell. >>>=20 >>> /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: >>>=20 >>> /* Configure TSO. */ >>> if (m->m_pkthdr.csum_flags & CSUM_TSO) { >>> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz = << 16); >>> cbp->tbd[1].tb_size |=3D htole32(tcp_payload << 16); >>> cbp->ipcb_ip_schedule |=3D FXP_IPCB_LARGESEND_ENABLE | >>> FXP_IPCB_IP_CHECKSUM_ENABLE | >>> FXP_IPCB_TCP_PACKET | >>> FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; >>> } >>>=20 >>> This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. >>>=20 >>> This is also when the "+ 1" was added to the: >>>=20 >>> struct fxp_tbd tbd[FXP_NTXSEG + 1] >>>=20 >>> above. >>>=20 >>> clang 7 via xtoolchain-llvm70 reported: >>>=20 >>> --- if_fxp.o --- >>> /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is = before the >>> beginning of the array [-Werror,-Warray-bounds] >>> cbp->tbd[-1].tb_size =3D htole32(m->m_pkthdr.tso_segsz = << 16); >>> ^ ~~ >>> /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared = here >>> struct fxp_tbd tbd[FXP_NTXSEG + 1]; >>> ^ >>> 1 error generated. >>> *** [if_fxp.o] Error code 1 >>>=20 >>> It does look odd to me. >>>=20 >>=20 >> So I did some digging into this a few months ago. >>=20 >> It turns out the code is right, kinda. >>=20 >> So, what's it's doing with the [-1] is as follows: >>=20 >> the sizeof tbd is 8 bytes long. So, we're dereferencing 8 before the = array, >> which points to tbd_array_addr. However tb_size is the second element = of >> that, so that points us at count + tx_threshold + tbd_number. So, = this code >> is setting count =3D 0 and tx_threshold to the low order bits of the = segment >> size and tbd_number to the high order bits. We set the count =3D 0 = later >> anyway, so that part of it isn't so bad. >>=20 >> Since this is in hardware, it may be special meanings for these bits, = and >> this 'trick' is used to just do one write rather than two. I've not = looked >> for the hardware manual to see if this is kosher, but that's what = we're >> doing. It's not as crazy stupid as it sounds at first blush. >=20 > WG14 is discussing making this definitly UB in the next C standard = (many > members think it already is, but this would make it more explict). If > this is required we need to find a better way to express it. Looks to me like the members that think it involves undefined behavior already (as far as C is concerned) get that via (using ISO/IEC 98999:2011 text): E1[E2] is equivalent to (*((E1)+(E2))) via 6.5.2.1 Array subscripting. "6.5.6 Additive Operators" in its semantics section for when a pointer and an integer type are involved says, in part: QUOTE If both the pointer operand and the result point elements of the same array object, or one past the last element of the array object, the evaluation shall not produce overflow; otherwise the behavior is undefined. END QUOTE "6.5.3.1 Address and indirection operators" in its semantics section, says in part: QUOTE If the operand had type "pointer type type", the result has type "type". If an invalid value has been assigned to the pointer, the behavior of = the unary * operator is undefined. END QUOTE That leaves the question if an undefined pointer arithmetic behavior leads to a known-to-be "invalid value" status for the pointer in order to connect the two quotes. I can see room for clarification. But it seems fairly clear that "implementation defined" for the overall classification is not the intent. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Sep 21 21:50:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B42710A54D5 for ; Fri, 21 Sep 2018 21:50:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C4C671F98 for ; Fri, 21 Sep 2018 21:50:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x130.google.com with SMTP id d10-v6so3783218itj.5 for ; Fri, 21 Sep 2018 14:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZe3M4Tl1bYGuz81FOMUVBZCSbAYwT13Q7LczgJ+yBs=; b=oIcZHqDTlCWjglULhmctxXEsHEdRn+Y0dFpI7New/6AVE015ebI3JrO/5z55TdjbOE Gz0HDrGneuQcICYfmZo62k5fbkYR3j5W7sWAjRuNfLXfTw0OhZWD0m4PSr70Pl5/zFN5 5AY3tx4b4B2KFwB/YZdxUjFk/deKj0NpC0XFrjeaRCpRWEkkUgNfVYpCJoFT3DnNNWM0 QtZ1wL6g7ct2dj7r6yDsz3hzNyzPTzTYDbq7cVryoN0I2itlku38ea4DY5LLN3bFmt96 52YR26FaYCKWU5mX8Pl5wZV3SlgHIYvYeDJ01Z6P0xkSa37q7OCfGTvjuvTCdx820S3a yk5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZe3M4Tl1bYGuz81FOMUVBZCSbAYwT13Q7LczgJ+yBs=; b=t2CsivWbNSZmZ+jCr2Er5PQ50vj/EEXYy1wiPlHcyYBVKFLDXhUVdXIUywh4tpaRDN VLMy/UswQJSld9KIv/FE4tjUn117MRuoyUXewID0wuSAD8pFQY5o2fJq9P5h3MIhw4NF 6ubXq3UGbnyOEotq/pbAxRr+p++CRzvedS+5BFPMAaImvSMVV7+IL6oO8zqTsQVjZvl7 tI4MFg6f71bNyRMDwgJ5u4sTWteZoSZ7xlIeDjC+f7XKLyUDo6WplXsRd117G9Nkjum+ OX/qkn+MslKTKzZsXZk469Je47FxzdR6hh8dFTjbN7CHshiimQD7iYquR7TgzY8oGLxv CrDQ== X-Gm-Message-State: APzg51AvNMyAm9wLuOMB5VrVubHaQqfvRq8xb2Me83XjWlYP48O7Hb8x P4dpeZmCwtiY2T7JU4YZgkKaV+lUQa0f2FpLxXdzhg== X-Google-Smtp-Source: ANB0VdbDSQjtKZnSpiXsHwpprua8BxMF7SDPWHTaSn//eqQQ8J1I2CG5oHwgTKJ3WXVS1F3SX3sTjwzZ5fouQsCpHJU= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr7361650ite.39.1537566620746; Fri, 21 Sep 2018 14:50:20 -0700 (PDT) MIME-Version: 1.0 References: <3EBF1660-6CD5-4C80-A36D-4DE945073006@yahoo.com> <3E0252F3-3E65-4A2B-B17A-3BBFBAFFD5F6@yahoo.com> <20180921201457.GB47693@spindle.one-eyed-alien.net> <8AB15D63-664F-4B88-B37F-0900717AA2B9@yahoo.com> In-Reply-To: <8AB15D63-664F-4B88-B37F-0900717AA2B9@yahoo.com> From: Warner Losh Date: Fri, 21 Sep 2018 14:50:08 -0700 Message-ID: Subject: Re: Does sys/dev/fxp/if_fxp.c using cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16) make any sense? To: Mark Millard Cc: Brooks Davis , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 21:50:22 -0000 On Fri, Sep 21, 2018, 3:22 PM Mark Millard wrote: > On 2018-Sep-21, at 1:14 PM, Brooks Davis wrote: > > > On Fri, Sep 21, 2018 at 01:21:59PM -0600, Warner Losh wrote: > >> On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers < > >> freebsd-hackers@freebsd.org> wrote: > >> > >>> [I decided that freebsd-hackers might be better for this, > >>> under a different wording.] > >>> > >>> sys/dev/fxp/if_fxp.c uses the statement: > >>> > >>> cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16); > >>> > >>> But sys/dev/fxp/if_fxpreg.h has the types involved as: > >>> > >>> struct fxp_cb_tx { > >>> uint16_t cb_status; > >>> uint16_t cb_command; > >>> uint32_t link_addr; > >>> uint32_t tbd_array_addr; > >>> uint16_t byte_count; > >>> uint8_t tx_threshold; > >>> uint8_t tbd_number; > >>> > >>> /* > >>> * The following structure isn't actually part of the TxCB, > >>> * unless the extended TxCB feature is being used. In this > >>> * case, the first two elements of the structure below are > >>> * fetched along with the TxCB. > >>> */ > >>> union { > >>> struct fxp_ipcb ipcb; > >>> struct fxp_tbd tbd[FXP_NTXSEG + 1]; > >>> } tx_cb_u; > >>> }; > >>> > >>> So cbp->tbd is not pointing into the middle of an array. > >>> Thus the cbp->tbd[-1].tb_size = . . . assignment trashes memory > >>> from what I can tell. > >>> > >>> /usr/src/sys/dev/fxp/if_fxp.c has the [-1] assignment in: > >>> > >>> /* Configure TSO. */ > >>> if (m->m_pkthdr.csum_flags & CSUM_TSO) { > >>> cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << > 16); > >>> cbp->tbd[1].tb_size |= htole32(tcp_payload << 16); > >>> cbp->ipcb_ip_schedule |= FXP_IPCB_LARGESEND_ENABLE | > >>> FXP_IPCB_IP_CHECKSUM_ENABLE | > >>> FXP_IPCB_TCP_PACKET | > >>> FXP_IPCB_TCPUDP_CHECKSUM_ENABLE; > >>> } > >>> > >>> This cbp->tbd[-1].tb_size use goes back to -r185330 in 2008-Nov-26. > >>> > >>> This is also when the "+ 1" was added to the: > >>> > >>> struct fxp_tbd tbd[FXP_NTXSEG + 1] > >>> > >>> above. > >>> > >>> clang 7 via xtoolchain-llvm70 reported: > >>> > >>> --- if_fxp.o --- > >>> /usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before > the > >>> beginning of the array [-Werror,-Warray-bounds] > >>> cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << > 16); > >>> ^ ~~ > >>> /usr/src/sys/dev/fxp/if_fxpreg.h:297:3: note: array 'tbd' declared here > >>> struct fxp_tbd tbd[FXP_NTXSEG + 1]; > >>> ^ > >>> 1 error generated. > >>> *** [if_fxp.o] Error code 1 > >>> > >>> It does look odd to me. > >>> > >> > >> So I did some digging into this a few months ago. > >> > >> It turns out the code is right, kinda. > >> > >> So, what's it's doing with the [-1] is as follows: > >> > >> the sizeof tbd is 8 bytes long. So, we're dereferencing 8 before the > array, > >> which points to tbd_array_addr. However tb_size is the second element of > >> that, so that points us at count + tx_threshold + tbd_number. So, this > code > >> is setting count = 0 and tx_threshold to the low order bits of the > segment > >> size and tbd_number to the high order bits. We set the count = 0 later > >> anyway, so that part of it isn't so bad. > >> > >> Since this is in hardware, it may be special meanings for these bits, > and > >> this 'trick' is used to just do one write rather than two. I've not > looked > >> for the hardware manual to see if this is kosher, but that's what we're > >> doing. It's not as crazy stupid as it sounds at first blush. > > > > WG14 is discussing making this definitly UB in the next C standard (many > > members think it already is, but this would make it more explict). If > > this is required we need to find a better way to express it. > > Looks to me like the members that think it involves undefined behavior > already (as far as C is concerned) get that via (using ISO/IEC > 98999:2011 text): > > E1[E2] is equivalent to (*((E1)+(E2))) via 6.5.2.1 Array subscripting. > > "6.5.6 Additive Operators" in its semantics section for when a pointer > and an integer type are involved says, in part: > > QUOTE > If both the pointer operand and the result point elements of the same > array object, or one past the last element of the array object, the > evaluation shall not produce overflow; otherwise the behavior is > undefined. > END QUOTE > > "6.5.3.1 Address and indirection operators" in its semantics section, > says in part: > > QUOTE > If the operand had type "pointer type type", the result has type "type". > If an invalid value has been assigned to the pointer, the behavior of the > unary * operator is undefined. > END QUOTE > > That leaves the question if an undefined pointer arithmetic behavior > leads to a known-to-be "invalid value" status for the pointer in order > to connect the two quotes. I can see room for clarification. > > But it seems fairly clear that "implementation defined" for the overall > classification is not the intent. > I think the intent of the code is my explanation. At the time the code was written, it was what the common compiler interpretation would have been. If that is changed under the rubric of pedantry, then we'll need to change the code. But we'll need to get the data sheet. NetBSD doesn't implement this feature. Linux's driver is a bit opaque at first glance, but it might be a source of details as well. I only spent a minute or two looking. Warner >