From owner-freebsd-hackers@freebsd.org Sun May 13 02:50:36 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 903BDFE1771 for ; Sun, 13 May 2018 02:50:36 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32D5F81F25 for ; Sun, 13 May 2018 02:50:36 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x22f.google.com with SMTP id s83-v6so2320526qke.7 for ; Sat, 12 May 2018 19:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RYqWUl9MClmPzkwCYTbZW4NDmebp2Tvhkgy7x88Mp+Y=; b=fF1OryofpuKf/zc9J0xdyqq5oIqFBECLxOeqlk445agbLWHsKDDBsAPANEIg0kJhqN YA8mofbVlda5x8KQ7H1Du6a+2SxJWJd7TwO89s7j6zVLXO/Hg7qrTcYhxOyuipO/bIWS he9Zg9Fe/6RGkZcMOZ+gIrWzUx9LjIZqtZYajYYchgZ/a0/aL3Ah//74OAO1tE8NINvj tMw6nlmqQxKGw+LbEHJGJNcW934O4GixiyIurf/KJY7R5nHvGsj4CNauGMcrsg82zuDE oOjUjfFjGLxmF+MaWkw566dq7Gsom6orXN51csMstt/kwOOJOn76xE0xfXwDN8pkbEqo 1jdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RYqWUl9MClmPzkwCYTbZW4NDmebp2Tvhkgy7x88Mp+Y=; b=HWN0IS+VGPOGfgdwRZpOLpH3alwaU+k2aPY98+qw+h3Vxo1bOLzEBBbz0emb+UzXdY nLkznwT1ROQQfCtVeI8XLEyochZeN2Q15dZKnoArsdLHePffuqnVRH3FksYX3MQa/Kon 8Gc8Wg1JLypMY/92DimnQewJr4clDLE7sXYM6pFls5CS6gVhlyQc9BqCQidWruwnR4Mc ocwCRpjFVEoQCB68v3EbqQw+L58yPOX0j3C9PTrbZRB1WUzgE5+vtAn3vuhrsk90f5g8 27fsMlh4tb8NlgIyetSDb2w5c6SIKfvB6xOX67I2Ebmfa/2Xt6J2ZFe+fvhlyxvbR8o5 jPew== X-Gm-Message-State: ALKqPwerJtVgzCpTx636MyyNmYz5ehjAa04ubru8MmIQo1YS1dza/Idf UAbl4PnWpBibY6OB7n6V3n5BUL8S8b1UVLF4VI0= X-Google-Smtp-Source: AB8JxZpK+ps7DvrJ8/bfHKsEcmli+UB8kVZ/Yw7Y/QO4jPbl/5m5iMbfjweofLhLUu5J0jOrRQnLXTvpkF4UNLPsUXA= X-Received: by 2002:a37:9044:: with SMTP id s65-v6mr3652100qkd.73.1526179835698; Sat, 12 May 2018 19:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.28.74 with HTTP; Sat, 12 May 2018 19:50:35 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Sun, 13 May 2018 04:50:35 +0200 Message-ID: Subject: Re: including a checksum of the diff in uname To: Eitan Adler Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 02:50:36 -0000 On Sun, May 13, 2018 at 4:41 AM, Eitan Adler wrote: > Hi all, > > I often have several variants of the same revision that I'm testing or > working on at any given time. > > What do you y'all think of something like this: > > Index: sys/conf/newvers.sh > =================================================================== > --- sys/conf/newvers.sh (revision 333575) > +++ sys/conf/newvers.sh (working copy) > @@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then > [0-9]*[MSP]|*:*) > svn=" r${svn}" > modified=true > + ck="$(svn diff | cksum | cut -w -f 1)" > + svn="$svn-$ck" > ;; > [0-9]*) > svn=" r${svn}" > > to help differentiate. > > You end up with a version that looks like: r333575M-4294967295? > > Don't develop with svn. get yourself a git or hg setup and a tmp branch. The branch name is always included along with the commit hash. The benefit is that not only know you know what the change is, you can always refer back to it later and diff against something else. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Sun May 13 03:04:03 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 9E55BFE255D for ; Sun, 13 May 2018 03:04:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 DFFC785028 for ; Sun, 13 May 2018 03:04:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w4D33vFF030790; Sun, 13 May 2018 03:03:57 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w4D33vBj030789; Sat, 12 May 2018 20:03:57 -0700 (PDT) (envelope-from david) Date: Sat, 12 May 2018 20:03:57 -0700 From: David Wolfskill To: Eitan Adler Cc: FreeBSD Hackers Subject: Re: including a checksum of the diff in uname Message-ID: <20180513030357.GK34631@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Eitan Adler , FreeBSD Hackers References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aSbZTaX27kKPUTye" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 03:04:03 -0000 --aSbZTaX27kKPUTye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 12, 2018 at 07:41:31PM -0700, Eitan Adler wrote: > Hi all, >=20 > I often have several variants of the same revision that I'm testing or > working on at any given time. >=20 > What do you y'all think of something like this: > .... Well.... The variant of newvers.sh that I use addresses this (among other things) by sourcing a file (through a symlink) that defines a shell function named "get_version_from_vcs()," and invokes that function in order to obtain a suitable "version string." The primary rationale for this is that I don't believe the various quirks of VCSen or installations ought to be in newvers.sh proper: it adds a fair amount of complexity that is difficult to test completely to code that has a fairly critical (and fundamentally simple) function. I created a few sample such functions, though I don't use all of the VCSen currently supported by base newvers.sh, so I haven't been able to test them all. (Sorry about the name. I'm lousy at naming things, and have no "investment" in the names used. I'd be pleased if someone would take the idea and get something based on it implemented, though.) Anyway, using such a mechanism, you could easily extend to version string to include just about anything you wanted -- with minimal risk of breaking newvers.sh (either for yourslef or others). Peace, david --=20 David H. Wolfskill david@catwhisker.org Mr. Trump: Just how does reneging on the Iran nuclear deal make the US "saf= er?" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --aSbZTaX27kKPUTye Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlr3qx1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7hcgHQf+OJBvv9Wl5N2YX3pesj4AwPUaWjNa1MFfF7OSJdWmcO9x6EbY6k7VzGEu ajSq5XZHa0nQ2KjdIhfIrTjUAW4d2X0s6QZGRFO5v22pn+7PNCWJy6D1azpLYk2b WTpzzNac/3rJLYEyi8WqhW7R1ua1G/u+I6mKlFmlaZa4/CmwvPvB1VSanEonY/mg /pHtQGeEPhoXLDnadAzUKx1mrp1HvqeJvFPVfWAv/hA6XYENuI6ltiN15FJT7Qqs zjA7dMo+UhmJkzBuuNrJWMqTT4qvT2REClTovuy9FYmRkH8UZ0ouiI699xPlrD9J ZaLpuB3Vrjzm0BjB7sd+yyrPWWP5Wg== =6ipr -----END PGP SIGNATURE----- --aSbZTaX27kKPUTye-- From owner-freebsd-hackers@freebsd.org Sun May 13 02:42:03 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 4AFF5FE10B7 for ; Sun, 13 May 2018 02:42:03 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E564B81B0E for ; Sun, 13 May 2018 02:42:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id w14-v6so3080079ybm.5 for ; Sat, 12 May 2018 19:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=hvQT9ygbF7Q8zFEDBo/IrngYQz4vMgscadlepiFi0U0=; b=RmpEk0Mwl/cDFWa6UeJcdwBjvuprxLghwxdmJ27k5jomF7atGlKZ693OFeJeYT9kD7 NV3+m6xrQnh+LinMmYtyNfnOa4//fuhWIkH637R/9F1MqF8PquY0o3KAw5rBtkkjPk1l he4Y63sn0gAauB0zzNkEmOg1stadr6/di0+lo= 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=hvQT9ygbF7Q8zFEDBo/IrngYQz4vMgscadlepiFi0U0=; b=UhhvCjrVEqyp4F88oCjlI4p8IIRxJyDHgiR4D0s9ELgNJGMWrJNa99AJmFXMa7rhY0 wqeTX4J0bxUkpcEY5Gy46wLf7kCWQGWJF5sQFJSqEHtjtXBt2DrHOTqso6YYyb9zQ4A2 9S+prwmKdv+QfH1Avuc7K8MlncJJxwCi1KzqCObz1o/Ec95H26xnQrzTf+Vyf5fyoF0A NrLADjA9E+D6WuEir0NWGXpRQD6KZIWGMWL1cjv8jDxqQZsCdfQzYyBUpwLgpG3+56z3 pEwkX3ubKnsV1AxdMJjtei3dY4OTx/F+CbOAUJ3VHTnEo7p4yw6mLmkrtbKrRX8TFszO fsgA== X-Gm-Message-State: ALKqPwdVF3wRE0Y19CCQsVu6Hs7w6YxR5iyCVQDb4C/lFal0noncZLPT bXsVFJCHLdlPiV3KNxgjYGkYIf7Lh+dOrIG1OgbgOZsx X-Google-Smtp-Source: AB8JxZpF+exJPkfUbgYPl6LZAhjk/lzvKmbWg9FTUmK5MHyI2FChSZOBG7Lt8sbZLbVkpQsFkOdMN7sMfEcVrmjD3Io= X-Received: by 2002:a25:5644:: with SMTP id k65-v6mr4199198ybb.479.1526179321892; Sat, 12 May 2018 19:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:c709:0:0:0:0:0 with HTTP; Sat, 12 May 2018 19:41:31 -0700 (PDT) From: Eitan Adler Date: Sat, 12 May 2018 19:41:31 -0700 Message-ID: Subject: including a checksum of the diff in uname To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 02:42:03 -0000 Hi all, I often have several variants of the same revision that I'm testing or working on at any given time. What do you y'all think of something like this: Index: sys/conf/newvers.sh =================================================================== --- sys/conf/newvers.sh (revision 333575) +++ sys/conf/newvers.sh (working copy) @@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then [0-9]*[MSP]|*:*) svn=" r${svn}" modified=true + ck="$(svn diff | cksum | cut -w -f 1)" + svn="$svn-$ck" ;; [0-9]*) svn=" r${svn}" to help differentiate. You end up with a version that looks like: r333575M-4294967295? -- Eitan Adler From owner-freebsd-hackers@freebsd.org Wed May 16 18:04:21 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 96438EF0BAD for ; Wed, 16 May 2018 18:04:21 +0000 (UTC) (envelope-from qdk@quickdekay.net) Received: from francine.edoropolis.org (francine.edoropolis.org [IPv6:2a01:7c8:fffb:2d1::2:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF78B741F4 for ; Wed, 16 May 2018 18:04:20 +0000 (UTC) (envelope-from qdk@quickdekay.net) Received: from francine.edoropolis.org (francine.edoropolis.org [37.97.242.148]) by francine.edoropolis.org (OpenSMTPD) with ESMTP id 401c2e42 for ; Wed, 16 May 2018 20:04:13 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on francine.edoropolis.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.1 Received: from Seska.fritz.box (powered-by.xenosite.net [188.240.24.123]) by francine.edoropolis.org (OpenSMTPD) with ESMTPSA id dbf0f827 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Wed, 16 May 2018 20:04:12 +0200 (CEST) Date: Wed, 16 May 2018 22:04:18 +0200 From: K Staring To: freebsd-hackers@freebsd.org Subject: snd_hda(4) pin patches WIP (was: Re: new laptop, no sound in spite of driver attaching) Message-Id: <20180516220418.1b7c25454c1d30bf2dbf9cbe@quickdekay.net> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Wed__16_May_2018_22_04_19_+0200_tqVtnb=hcM56Zes3" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 18:04:21 -0000 --Signature=_Wed__16_May_2018_22_04_19_+0200_tqVtnb=hcM56Zes3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After initial success with getting the jack plug output on my Dell XPS 9650= to work (since been merged into -CURRENT), I've been busy to port some of = the pin patches from Linux to FreeBSD's snd_hda(4) driver. Apparently Intel's HDA specification is very difficult to implement correct= ly, or "we'll fix it in software" prevails: there are a *lot* of patches to= make hardware work in the Linux source... There are three kinds of patches present in snd_hda (and similarly in the h= da Linux code) : - pin patches - GPIO patches - "other" (manual fiddling in code) I've been focussing on pin patches for now, for Realtek chipsets. So if you= run CURRENT, have problems with the snd_hda(4) driver and your system has = a Realtek audio chipset, this github branch might be useful: https://github= .com/kstaring/freebsd/tree/hda_pin_fixes_realtek . At the moment, most pin = patches for the Realtek ALC260, ALC268, ALC269, ALC271, ACL280 and ALC880 a= re ported (barring some unclear or strange entries in the Linux source). I'd appreciate all feedback! --=20 K Staring --Signature=_Wed__16_May_2018_22_04_19_+0200_tqVtnb=hcM56Zes3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEQdP3BANRX65TrEyuO++4CB4086wFAlr8jsMACgkQO++4CB40 86x2IggAt9JBExUmlWGZPIziQgRXtsXGOK1kZ9ggMwrbdGCrpTpt8+1A8yM7uHFu XfBMR5Ts8IV706vG8uX/L7ZP8O/jecb+koE4io607JBQV3yTN2HWg6O4qOenIIbI VvZHqM1S5H1Oakpm7uQ+vFmZFjtKreaR2QOXmOn6HvkXciuRc5PmyHP77JIp0pLs n7YEresAcT6uSQRUjmg4GxOAERBhS3iu02KLq7Jo18YJ/8z8caw3q+yvzEz9oLqE FSM727t/XifR5MXaMKgI6cBZirn1wKinCSLOWokGytqYQkWu3uMe5DTAYw37BD9d vmD5/QIbZIYQhRWinFhsU/IN3+Yz0g== =2ff4 -----END PGP SIGNATURE----- --Signature=_Wed__16_May_2018_22_04_19_+0200_tqVtnb=hcM56Zes3-- From owner-freebsd-hackers@freebsd.org Thu May 17 06:38:17 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 532D6EB1F67 for ; Thu, 17 May 2018 06:38:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E75676E962 for ; Thu, 17 May 2018 06:38:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x241.google.com with SMTP id q7-v6so1007865ywd.9 for ; Wed, 16 May 2018 23:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ORl3WPO4+V4i0QTYQndtezbrzq0M5FzAGwyT69BzFvU=; b=P78Mq1Y1X8aS11KkHcABaBhFE5kMmhNnrYdCmSf5iiffqDHmD1dj9fn+6m2PChUVdE TWnTpY264grI4OKC8JQb7fmG+MBgX0odof4DbVx3YIJKhdSRNuOz3BHO+qrh1tZunX9r wzuKuBZLF5/aDeMj4BKoYcoOeVuITMTOtDoXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ORl3WPO4+V4i0QTYQndtezbrzq0M5FzAGwyT69BzFvU=; b=cI8rDfHF8jYmNFUPC4SjrACZinGQPAc9VT543lBgxBe86OuYzuJHSpvZxpJI7OwDsj d6oDDowW0Jyxid3ZdN+Cpm22Mall55y2pvsqIyckK9BBS2m1nSU+exow6to9B6X9nTg6 3UYtftNNSGWYCyPKg20YZdGx19C/MmX5K04QWNcZRtAhak9pOFHWh0/C/+T1Ul/N5ghD iYwSjeRoyW/yrMgZqNsVpVFbuxlE19THIR0rbn8KoHWd85uDR9u9l0DX/NDW1HWrkmyh 15Njbkr4OKnBxbPJQ80wzu8KZKUZmzNSQJN7l9zLwfWIPtYm4V6hHRgyRN9JwlOhLOdS bPsw== X-Gm-Message-State: ALKqPwc+q4j8HepbMGrZt8oOF6as0eh76qo5G9LGZgj/4xAcFVxRfg3n agDHb3Kw9cIeHGSbZ1N6Ud8Cv8l+okO9cGV+oSD+XQ== X-Google-Smtp-Source: AB8JxZoB8gaf6cfFSPr3tnUQx1Tm84WH+h9aaBRQyVV2DSORpMSW9bRRhPh6sTnD3mCY0WDigQ/k6+xpgSFXLlSqOHg= X-Received: by 2002:a81:8605:: with SMTP id w5-v6mr1840103ywf.162.1526539096146; Wed, 16 May 2018 23:38:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:c709:0:0:0:0:0 with HTTP; Wed, 16 May 2018 23:37:45 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Wed, 16 May 2018 23:37:45 -0700 Message-ID: Subject: Re: including a checksum of the diff in uname To: Mateusz Guzik Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 06:38:17 -0000 On 12 May 2018 at 19:50, Mateusz Guzik wrote: > On Sun, May 13, 2018 at 4:41 AM, Eitan Adler wrote: >> >> Hi all, >> >> I often have several variants of the same revision that I'm testing or >> working on at any given time. >> >> What do you y'all think of something like this: >> >> Index: sys/conf/newvers.sh >> =================================================================== >> --- sys/conf/newvers.sh (revision 333575) >> +++ sys/conf/newvers.sh (working copy) >> @@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then >> [0-9]*[MSP]|*:*) >> svn=" r${svn}" >> modified=true >> + ck="$(svn diff | cksum | cut -w -f 1)" >> + svn="$svn-$ck" >> ;; >> [0-9]*) >> svn=" r${svn}" >> >> to help differentiate. >> >> You end up with a version that looks like: r333575M-4294967295? >> > > Don't develop with svn. get yourself a git or hg setup and a tmp branch. > The branch name is always included along with the commit hash. That makes sense, and I might do that in the future. In the past adding files was more painful with git, though I'm told this is no longer the case. In any case, is there any reason not to add the above patch? -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu May 17 06:46:16 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 06DB4ED6ACA for ; Thu, 17 May 2018 06:46:16 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 950D76EF94 for ; Thu, 17 May 2018 06:46:15 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x243.google.com with SMTP id b39-v6so2768453qkb.5 for ; Wed, 16 May 2018 23:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k6qlBEy3PifYxHmv7rTfdkmtjvwjtSynZYCDnKZ1Uk4=; b=q7GgaAlvgsz38cDGwCvW4JnAHQZk9BfajVh8bA3JhU/cjQx/TlSScbJHI3hOELcHTl Mq67OSLoIC46PGgKnJFEhEUTnjZ59GDyJbrGbS4YV2BjGsQAIOzc7jmRJH00bnnYPt9T pMh1RTMDh6w97KsAzSqEQ3oh60/vTiH6bhLRnn++/6Po7uNpevewHwNjJQZc2TXVJ8CQ 6cb/WuJtnOtWlDRoRWPDEcdDCvrD8UwTalW+bA9ceqE6oBJhkrzqYtm84aMD4asfWemE FVJutY3PqYu0ArIGZxPAXec5UzYZwgwQAuCB43QFkV7Jnr6ssjZKektsT7FJOusO5V/p LBnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k6qlBEy3PifYxHmv7rTfdkmtjvwjtSynZYCDnKZ1Uk4=; b=XvcwEt5z/Q4mMBjaSTLP90nD7EvhxGEBbxgSSdxgGo15MoR22kZlKXNkf9bG6RXIBF Cutv8N48z7amWBfW2a8ygNofeT77h7/ZgaeClB7Lk/6e5tn3lfJYC0twh+kwf5530Rkd ZNOHQb4wDYnzry2Io50j8tvS0a7CkJbk8pNN28NGODARF4IQm7rE7C1XgH0fKgPLKPBy eVG+8AUv4Xp/dOo103mvA9af2CN/8WcP88lbRLAKHkXbFOsLVGMCaMDkBYEpkY2LPxdv RJPcl+qn/aQGTSicEt7CGs7zHaSXpImTkmof3RCFEZR8su/NcO9rj1npTUfYw1sR4oPd z4ZA== X-Gm-Message-State: ALKqPweoexCEaVlgYBrv/BFhs3OgYOcNVm8cgKMSMH7Q30ISAdSWsRPh uoy7jgrbYj/aLaDwHvMKLSDuvyyRdszybnEMqzc= X-Google-Smtp-Source: AB8JxZoxqsSfBrma/lGrIJ62Xq/WVeD6sJNHaUGLE+puiRB1PVsxWsYCrdgmSV/20LWj8xnrKuZPx8/8KUlwYwfscbE= X-Received: by 2002:ae9:f40c:: with SMTP id y12-v6mr3712361qkl.311.1526539575247; Wed, 16 May 2018 23:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.28.74 with HTTP; Wed, 16 May 2018 23:46:14 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Thu, 17 May 2018 08:46:14 +0200 Message-ID: Subject: Re: including a checksum of the diff in uname To: Eitan Adler Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 06:46:16 -0000 On Thu, May 17, 2018 at 8:37 AM, Eitan Adler wrote: > On 12 May 2018 at 19:50, Mateusz Guzik wrote: > > On Sun, May 13, 2018 at 4:41 AM, Eitan Adler > wrote: > >> > >> Hi all, > >> > >> I often have several variants of the same revision that I'm testing or > >> working on at any given time. > >> > >> What do you y'all think of something like this: > >> > >> Index: sys/conf/newvers.sh > >> =================================================================== > >> --- sys/conf/newvers.sh (revision 333575) > >> +++ sys/conf/newvers.sh (working copy) > >> @@ -203,6 +203,8 @@ if [ -n "$svnversion" ] ; then > >> [0-9]*[MSP]|*:*) > >> svn=" r${svn}" > >> modified=true > >> + ck="$(svn diff | cksum | cut -w -f 1)" > >> + svn="$svn-$ck" > >> ;; > >> [0-9]*) > >> svn=" r${svn}" > >> > >> to help differentiate. > >> > >> You end up with a version that looks like: r333575M-4294967295? > >> > > > > Don't develop with svn. get yourself a git or hg setup and a tmp branch. > > The branch name is always included along with the commit hash. > > That makes sense, and I might do that in the future. In the past > adding files was more painful with git, though I'm told this is no > longer the case. > > In any case, is there any reason not to add the above patch? > > I don't see any added value of doing so. So far it just looks like patching up a deficient development process. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Thu May 17 07:54:48 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 7F7E7EDC28F; Thu, 17 May 2018 07:54:48 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8788718A6; Thu, 17 May 2018 07:54:47 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f50.google.com with SMTP id r25-v6so7348681lfd.1; Thu, 17 May 2018 00:54:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=kPiGJk4V4oEhvP+TKNTJAyYpAR3uuMX5XlAvvHS16pk=; b=ef19HWaOsm6TdZZItAFRELFWE9a+bCwVVF2J2T8KwhZkmLrbTmyF1RShecdF1lcqSA ghSLPQNOqAeGHC41gbD+1Ok7DYY3k4oTvuGa2Ynumptn/gS0LXoJlg/ht5zM2tExB4i6 mIRiFpsOH8zXkYDlqs+QR/i3s0cTGkMvUKlsXQaXh2IjqJ8aq3Q3x28bNanwhtfVDAkf k0r0NyRP/xo3ku5EOXbfSRpNO4sdDkXbD0hvr/tO/2I+qWFmXyqv0FmHnJFXNuuOOrU2 GyORfQPbv5hpUCdlDkbSwHVMV/GDGUsBmYO19C2ANefwSvcHDjvNWqwPwz3cPbyc3MeW zC2g== X-Gm-Message-State: ALKqPwfQjGnNgLwWYEKRyMKDV7V/AXCBynfRNKbH/QmHqacSvlq99dnr E608O0AZ/4FaSzkE0NMvzpHYXYSi X-Google-Smtp-Source: AB8JxZrrqPt1Ob4wk5TlhoAGCHCDfXmqt/92fMrAyDr0ZZsddcZ0tpNgzuJ8EK10oQAzIkf2dVLFQQ== X-Received: by 2002:a19:ead6:: with SMTP id y83-v6mr16447218lfi.117.1526543679677; Thu, 17 May 2018 00:54:39 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q18-v6sm1068333lfi.97.2018.05.17.00.54.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 00:54:39 -0700 (PDT) To: freebsd-hackers , FreeBSD Current From: Andriy Gapon Subject: serial console vs suspend Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> Date: Thu, 17 May 2018 10:54:38 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 07:54:48 -0000 It seems that the serial console, or rather a UART used by it, may require re-initialization after waking up (from suspend to RAM). At least one of my systems fails to wake up properly if I configure the serial console. I've done some experimenting with cu (and without the console) and the UART seems to be in some weird state, it echoes back the input and does not send anything on the wire. I guess that trying to print to the serial console while the UART is in that state results in a hang. To test the theory I made this hack and it does help: Index: sys/dev/uart/uart_tty.c =================================================================== --- sys/dev/uart/uart_tty.c (revision 333667) +++ sys/dev/uart/uart_tty.c (working copy) @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp) uart_init(di); } +void uart_resume(void); +void +uart_resume(void) +{ + uart_init(&uart_console); +} + static void uart_cnterm(struct consdev *cp) { Index: sys/x86/acpica/acpi_wakeup.c =================================================================== --- sys/x86/acpica/acpi_wakeup.c (revision 333667) +++ sys/x86/acpica/acpi_wakeup.c (working copy) @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc) } #endif +extern void uart_resume(void); + int acpi_sleep_machdep(struct acpi_softc *sc, int state) { @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat #else npxresume(susppcbs[0]->sp_fpususpend); #endif + uart_resume(); } return (1); /* wakeup successfully */ =================================================================== This is quick and dirty, of course. I think that this should go through the console layer. And, obviously, not all consoles actually need such a reinit. So, maybe: cnresume() { for each console { if cn->cn_ops->cn_resume != NULL cn->cn_ops->cn_resume(cn) } } uart_resume(struct consdev *cp) { uart_init(cp->cn_arg); } What do you think? Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method. So, will I have to add a dummy resume to all console drivers? -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu May 17 13:26:05 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 11DB8EF118C for ; Thu, 17 May 2018 13:26:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93E927F565 for ; Thu, 17 May 2018 13:26:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d247bfed-59d5-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id d247bfed-59d5-11e8-afd2-4ddcc8249dd4; Thu, 17 May 2018 13:25:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w4HDPq3M083860; Thu, 17 May 2018 07:25:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1526563552.32688.47.camel@freebsd.org> Subject: Re: serial console vs suspend From: Ian Lepore To: Andriy Gapon , freebsd-hackers , FreeBSD Current Date: Thu, 17 May 2018 07:25:52 -0600 In-Reply-To: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> References: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:26:05 -0000 On Thu, 2018-05-17 at 10:54 +0300, Andriy Gapon wrote: > > It seems that the serial console, or rather a UART used by it, may require > re-initialization after waking up (from suspend to RAM).  At least one of my > systems fails to wake up properly if I configure the serial console.  I've done > some experimenting with cu (and without the console) and the UART seems to be in > some weird state, it echoes back the input and does not send anything on the > wire.  I guess that trying to print to the serial console while the UART is in > that state results in a hang. > > To test the theory I made this hack and it does help: > Index: sys/dev/uart/uart_tty.c > =================================================================== > --- sys/dev/uart/uart_tty.c (revision 333667) > +++ sys/dev/uart/uart_tty.c (working copy) > @@ -114,6 +114,13 @@ uart_cninit(struct consdev *cp) >   uart_init(di); >  } > > +void uart_resume(void); > +void > +uart_resume(void) > +{ > + uart_init(&uart_console); > +} > + >  static void >  uart_cnterm(struct consdev *cp) >  { > Index: sys/x86/acpica/acpi_wakeup.c > =================================================================== > --- sys/x86/acpica/acpi_wakeup.c (revision 333667) > +++ sys/x86/acpica/acpi_wakeup.c (working copy) > @@ -204,6 +205,8 @@ acpi_wakeup_cpus(struct acpi_softc *sc) >  } >  #endif > > +extern void uart_resume(void); > + >  int >  acpi_sleep_machdep(struct acpi_softc *sc, int state) >  { > @@ -300,6 +303,7 @@ acpi_sleep_machdep(struct acpi_softc *sc, int stat >  #else >   npxresume(susppcbs[0]->sp_fpususpend); >  #endif > + uart_resume(); >   } > >   return (1); /* wakeup successfully */ > > > =================================================================== > > This is quick and dirty, of course. > I think that this should go through the console layer. > And, obviously, not all consoles actually need such a reinit. > > So, maybe: > cnresume() > { > for each console { > if cn->cn_ops->cn_resume != NULL > cn->cn_ops->cn_resume(cn) > } > } > > uart_resume(struct consdev *cp) > { > uart_init(cp->cn_arg); > } > > What do you think? > > Hmm, it looks like CONSOLE_DRIVER() does not allow to omit a console method. > So, will I have to add a dummy resume to all console drivers? Why should it go through the console layer? If the uart hardware needs some re-init on resume, won't that be true whether the uart is serving as a console, a dial-in terminal, or the interface to wifi or bluetooth chip? -- Ian From owner-freebsd-hackers@freebsd.org Thu May 17 13:28: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 3FBB2EF147F; Thu, 17 May 2018 13:28:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99AF57FA13; Thu, 17 May 2018 13:28:51 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f54.google.com with SMTP id b18-v6so8756180lfa.9; Thu, 17 May 2018 06:28: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:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xiW/oUiGJsHv95mXAGlg8nzZjReZ0wqnAplT+Vjfkp8=; b=LsA7qghI1PCb/XWgeqEgVzRrNqHK7cKEMpG+WL0NzAtZNablpctP9DyW2uQGaDYoLC OqsbQCEQzXQcmTUoX4DgevRn607IwW5p8epISBICnJxlwEh5/L+4EDfmn1CnqcRfHywe YKPc/H2fvm4XhtXFT8uVj9rEiJ2G16yMltbNs2HpEhjxX+SjfEpdPmUpikRVo8tupqmI eIdGfAjVrEpI6QEnsDd5Nwg5rImzxEqkUb2ly1tXHazO7p4ohXX2wuubGLSVPWvumRwH lrUaytia7IJ55ZmR/H5utv6kzWfIZBC/jK/omBl+LUI9/8bKIPN1efhryWIG6h568fzc D6qw== X-Gm-Message-State: ALKqPwfFV5XsgEsH0wv9TdN8SkokEK3R5jLKAxFeheabQ2KEpPjl2Zns /UDcD9xLwxCsIE+WUak5mDRsS1Ro X-Google-Smtp-Source: AB8JxZr1XRtiBp/EV0j58F8gTnkyPjy9Zy+2o6YVWaFrKgCtmCZuwPqQY+kSPt+K4S7RrPLynZaJGQ== X-Received: by 2002:a19:4e1c:: with SMTP id c28-v6mr17287004lfb.61.1526563729465; Thu, 17 May 2018 06:28:49 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id v9-v6sm1227354lfa.30.2018.05.17.06.28.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 06:28:48 -0700 (PDT) Subject: Re: serial console vs suspend To: Ian Lepore , freebsd-hackers , FreeBSD Current References: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> <1526563552.32688.47.camel@freebsd.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Thu, 17 May 2018 16:28:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526563552.32688.47.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:28:52 -0000 On 17/05/2018 16:25, Ian Lepore wrote: > Why should it go through the console layer? If the uart hardware needs > some re-init on resume, won't that be true whether the uart is serving > as a console, a dial-in terminal, or the interface to wifi or bluetooth > chip? I think that for those things a normal device resume should do. console gets used very early, so it may require a special resume. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu May 17 14:59: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 0F0DCEAAFC0 for ; Thu, 17 May 2018 14:59:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94EC38396B for ; Thu, 17 May 2018 14:59:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id 70-v6so9247455ity.2 for ; Thu, 17 May 2018 07:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SWA8guDu/EEAqWB6dQPgZ5VBMKLP4AxtihbKV7/947M=; b=DVRszpDE3tBqnGcG6dzmsiwhqsfMlWiXm3lTnHHtKSgGQMMB8Z6CyfyKDNBVdB8/AX m+qrsK5kugojgE65U15E50x2IcINWYwv5S6vY8DX2/BQZEpC3RS3lDB2soQMfsUDDbN4 xaLoHfP0tBfwhaXOvUHx5E9CNbCpC2a/IogtAioah8XbPIWKQTrwHF/zp2Q8uzr8c+F+ 6LTKDHKHL7T8jW8PRyEz+pTfbXhc39nH5dHyml1MSwOqv2NvVT+m+haXO1786l2uUF+K O9QAn75oaz2uPq32Bk5isQ7yubYxbvFgZLhLtuVI5sXYjBShdC5b0u5JjOsfIzTbdANV EMtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SWA8guDu/EEAqWB6dQPgZ5VBMKLP4AxtihbKV7/947M=; b=k8Uh/9NzwzjddHCitVO28OJ/5t+auqmMyP0ZXZqeWiyOqZRFyHsGw7d1BmXJDeo9oY NRtzYGy+aGLziOxoxgFFX4C0K1jVc99I5BstLM9aqRTJcE8zJ71u8aj+DaYvwBgDZPXK YKFVqJzk/G1WRlhuFs5MLgkPoOo31+5TYC78EW8h9t9pwmlqThIny4uwbuV5ysJEkCnC 6pLg2ZSR4y4k5pvEw/OHW/MtplY3f6KtVDqwZ5kIDAu6M1kmBHfUU5Hz6/qExwa24wND cvfgGJ4a8TFovW4GOjgYgUze1ttIlW5Ghq32Byp5wgT9ywfC4Ui/shIztUML7NdlH4Qt M35A== X-Gm-Message-State: ALKqPwfkBF84nxa3T6z5juMBC2VA0EUmCJ5PJy5dvAkZVQWYy3ujuukE dA7B3UfwDy/gV7M75pQuTcliy2FS0k0+xq47XLIK2w== X-Google-Smtp-Source: AB8JxZpE5rUA/S59ZANxtyX8/ZIVD6PvrLbOStbyKj+tEn+Z6UqGMth5Qz5XNCCPEBG8v+xLJ41zdk0a1Bd8/qc49fg= X-Received: by 2002:a24:4c55:: with SMTP id a82-v6mr2926477itb.1.1526569168004; Thu, 17 May 2018 07:59:28 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a649:0:0:0:0:0 with HTTP; Thu, 17 May 2018 07:59:27 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <0e1d5601-f792-0708-3bcf-7153bea8f679@FreeBSD.org> <1526563552.32688.47.camel@freebsd.org> From: Warner Losh Date: Thu, 17 May 2018 08:59:27 -0600 X-Google-Sender-Auth: MbM5vind_VP0OzOtzw_oxqu9Vhk Message-ID: Subject: Re: serial console vs suspend To: Andriy Gapon Cc: Ian Lepore , freebsd-hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:59:29 -0000 On Thu, May 17, 2018 at 7:28 AM, Andriy Gapon wrote: > On 17/05/2018 16:25, Ian Lepore wrote: > > Why should it go through the console layer? If the uart hardware needs > > some re-init on resume, won't that be true whether the uart is serving > > as a console, a dial-in terminal, or the interface to wifi or bluetooth > > chip? > > I think that for those things a normal device resume should do. > console gets used very early, so it may require a special resume. > We should re-init both places (maybe with a flag to prevent double if that's harmful). The console is needed very early after the resume, often earlier than the accidental location in the device tree the console device_t node lives. That way we don't lose output. The console layer gives us a convenient hook early in resume to cope. It's yet another reason, though, it should be restricted to true console devices, but that's another conversation. Warner From owner-freebsd-hackers@freebsd.org Thu May 17 17:52: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 36913EDB5D4; Thu, 17 May 2018 17:52:38 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.physik.tu-berlin.de (mail.physik-pool.tu-berlin.de [130.149.50.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8EA46CE0D; Thu, 17 May 2018 17:52:36 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from [192.168.119.1] (wlan-141-23-160-161.tubit.tu-berlin.de [141.23.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id 51E5561FD0; Thu, 17 May 2018 17:43:59 +0000 (UTC) From: "Fabian Freyer" To: freebsd-jail@freebsd.org, freebsd-hackers@freebsd.org Subject: sizeof jail parameter value strings Date: Thu, 17 May 2018 19:43:57 +0200 X-Mailer: MailMate (1.11.2r5479) Message-ID: <6BDE831C-48AC-4FA3-B0EC-C4B7D275AFFE@physik.tu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_A00A7A58-F35D-4F7C-AEB5-82B656D8CD52_="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 17:52:38 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_A00A7A58-F35D-4F7C-AEB5-82B656D8CD52_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello lists, =46rom jail(3): > The jail_getv() function takes a null-terminated list of name and v= alue > strings, and passes it to jail_get(2). It is the caller's responsi= bility > to ensure that the value strings point to buffers large enough to h= old > the string representation of the returned parameters. What exactly does =E2=80=9Clarge enough=E2=80=9D mean here? Is there a wa= y to query the size of the corresponding kernel buffers at runtime? Is there a maximum length =C3= =A0 la MAX_JAIL_PARAM_LEN that the string representations of the returned parame= ters are guaranteed to be shorter than? I=E2=80=99m currently implementing a rust wrapper[1] around the jail(2) i= nterface, and am not sure how large buffers for the string parameters I=E2=80=99m querying= with jail_get jail_set have to be. Fabian (I=E2=80=99m not on the freebsd-jail mailing list, so I=E2=80=99d appreci= ate being kept in the CC) [1] https://github.com/fubarnetes/libjail-rs --=_MailMate_A00A7A58-F35D-4F7C-AEB5-82B656D8CD52_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJWBAEBCgBAFiEEX6JoxdmEemcFacQZmealkcs85+YFAlr9v10iHGZhYmlhbi5m cmV5ZXJAcGh5c2lrLnR1LWJlcmxpbi5kZQAKCRCZ5qWRyzzn5vs9D/40QAEzqkm2 BCyUzh4lJ1uihMPU8x1u1L+pef7ocBJ8zVX/atLAroX5+08zlT8crZqMmz7fvzaa Ba4M3xwIrg0n5OHVWoskPlLs7T0N1WazfIzd733/S5FKfAp8c6GMn1QnMEmTHzzw 45vA0XlIb+0AeiDn+ydcb2AMrpFE6KMq33MmI5qBWzrzsfbRl3rj9jjATcnCZbGq IR11+LAk/jbJgOHEiWWuM2ErFrzsZ1Gv/OI+hiNYiqb7hRM9waTRzLBoQmOdMbUq CgfCuF780mFJxUfLSRv466ISssmmyyA4npv4QKBzVB19raltoJeP0hTn/vIUYcKn bVte/QouOlVJgGFI63zOFBLYY+W6P/7Cq+MlYQADRg3VSWZwekUgr/Ptjc7UpJiV k1PZGSXmh1Vv+soK0b2CbXj/WxuA3hOaFt4cT60R7QmNlVoYDrRNOQ60OEOB/nO8 pm/grbM2ECFn1CpaRWJfp3BDJ9/3tfbvDh/hFa1IDMaWhf6QkJlEpYpzYVDVxrL6 m9SGtPA4RQ1d/FYUJWU3xMf0k6gSe9tLSBz/D2SQ38THDO9+035I85To7aChtav5 AVdWob4OCBLwOKsp594uQkyVHuHKS3d3rf2Piu+hOtioBRcPfJJlUvCgERx6dRoY VOtU+YhlDyso81qzvq4s+oLptmOjf1inRQ== =J/MM -----END PGP SIGNATURE----- --=_MailMate_A00A7A58-F35D-4F7C-AEB5-82B656D8CD52_=-- From owner-freebsd-hackers@freebsd.org Fri May 18 02:31:51 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 21DF6EE679F for ; Fri, 18 May 2018 02:31:51 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc14.plala.or.jp (msc14.plala.or.jp [60.36.166.24]) by mx1.freebsd.org (Postfix) with ESMTP id 575E07FE22 for ; Fri, 18 May 2018 02:31:49 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from localhost ([2400:4050:9320:7a00::8]) by msc14.plala.or.jp with ESMTP id <20180518023141.BQCE5015.msc14.plala.or.jp@localhost> for ; Fri, 18 May 2018 11:31:41 +0900 Date: Fri, 18 May 2018 11:30:09 +0900 (JST) Message-Id: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> To: freebsd-hackers@freebsd.org Subject: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? From: Masachika ISHIZUKA X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_May_18_11_30_09_2018_552)--" Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; mvir-ac14; Fri, 18 May 2018 11:31:41 +0900 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 02:31:51 -0000 ----Next_Part(Fri_May_18_11_30_09_2018_552)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. I use a nootbook machine. As this machine has no internal nic, I use a USB ethernet adapter(ue0). I want to configure lagg0 of ue0 and iwm0, but I must wait to start /etc/rc.d/netif until appearing the ue0. I'm using patched netif as follows, but I must keep it whenever 'mergemaster -Ui' is run. Is there a more elegant way? -- Masachika ISHIZUKA ----Next_Part(Fri_May_18_11_30_09_2018_552)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netif.diff" --- /etc/rc.d.inactive/netif.org 2018-05-18 10:11:57.204047000 +0900 +++ /etc/rc.d/netif 2018-05-18 10:44:02.017318000 +0900 @@ -53,11 +53,45 @@ netif_start() { - local _if + local _if count wait_if output got_if any_error # Set the list of interfaces to work on. # cmdifn=$* + + if [ ${netif_wait_timeout} -lt 1 ]; then + err 1 "netif_wait_timeout must be >= 1" + fi + + if [ -n "${netif_wait_if}" ]; then + any_error=0 + for wait_if in ${netif_wait_if}; do + echo -n "Waiting for ${wait_if}" + got_if=0 + count=1 + # Handle SIGINT (Ctrl-C); force abort of while() loop + trap break SIGINT + while [ ${count} -le ${netif_wait_timeout} ]; do + if output=`/sbin/ifconfig ${wait_if} 2>/dev/null`; then + echo -n ", interface present" + got_if=1 + break + fi + sleep 1 + count=$((count+1)) + done + # Restore default SIGINT handler + trap - SIGINT + if [ ${got_if} -eq 0 ]; then + echo ", wait failed: interface never appeared." + any_error=1 + fi + done + if [ ${any_error} -eq 1 ]; then + warn "Continuing with startup, but be aware you may not have " + warn "a fully functional networking layer at this point." + fi + fi if [ -z "$cmdifn" ]; then # ----Next_Part(Fri_May_18_11_30_09_2018_552)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="add-to-rc.conf" netif_wait_timeout=60 netif_wait_if="ue0" ----Next_Part(Fri_May_18_11_30_09_2018_552)---- From owner-freebsd-hackers@freebsd.org Fri May 18 03:08:34 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 680FCEE775C for ; Fri, 18 May 2018 03:08:34 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF4DA81CEB for ; Fri, 18 May 2018 03:08:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w4I38LZ2085733 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 05:08:22 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ish@amail.plala.or.jp Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w4I38IJs097056 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 May 2018 10:08:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? To: Masachika ISHIZUKA , freebsd-hackers@freebsd.org References: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> From: Eugene Grosbein Message-ID: <5AFE439D.4000801@grosbein.net> Date: Fri, 18 May 2018 10:08:13 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 03:08:34 -0000 18.05.2018 9:30, Masachika ISHIZUKA wrote: > I use a nootbook machine. > As this machine has no internal nic, I use a USB ethernet adapter(ue0). > I want to configure lagg0 of ue0 and iwm0, but I must wait to start > /etc/rc.d/netif until appearing the ue0. > I'm using patched netif as follows, but I must keep it whenever > 'mergemaster -Ui' is run. > Is there a more elegant way? Yes. In fact, you do not need to wait but "hook" on the event of ue0 creation. We have several ways to do that and simpliest one for network interface is using /etc/start_if.ue0 script like this: #!/bin/sh ifconfig ue0 up ifconfig lagg0 addm ue0 # EOF From owner-freebsd-hackers@freebsd.org Fri May 18 03:10:09 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 0C1DCEE77DE for ; Fri, 18 May 2018 03:10:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8175181DC6 for ; Fri, 18 May 2018 03:10:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w4I39xNn085743 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 05:09:59 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ish@amail.plala.or.jp Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w4I39tlm097083 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 May 2018 10:09:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? To: Masachika ISHIZUKA , freebsd-hackers@freebsd.org References: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> <5AFE439D.4000801@grosbein.net> From: Eugene Grosbein Message-ID: <5AFE43FF.8020800@grosbein.net> Date: Fri, 18 May 2018 10:09:51 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5AFE439D.4000801@grosbein.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 03:10:09 -0000 18.05.2018 10:08, Eugene Grosbein wrote: >> I use a nootbook machine. >> As this machine has no internal nic, I use a USB ethernet adapter(ue0). >> I want to configure lagg0 of ue0 and iwm0, but I must wait to start >> /etc/rc.d/netif until appearing the ue0. >> I'm using patched netif as follows, but I must keep it whenever >> 'mergemaster -Ui' is run. >> Is there a more elegant way? > > Yes. In fact, you do not need to wait but "hook" on the event of ue0 creation. > We have several ways to do that and simpliest one for network interface is > using /etc/start_if.ue0 script like this: > > #!/bin/sh > > ifconfig ue0 up > ifconfig lagg0 addm ue0 Sorry, this should be "ifconfig lagg0 laggport ue0" From owner-freebsd-hackers@freebsd.org Fri May 18 06:47:05 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 5B015EEC4EB for ; Fri, 18 May 2018 06:47:05 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc12.plala.or.jp (msc12.plala.or.jp [60.36.166.22]) by mx1.freebsd.org (Postfix) with ESMTP id 705D769916 for ; Fri, 18 May 2018 06:47:04 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from localhost ([126.74.209.183]) by msc12.plala.or.jp with ESMTP id <20180518064656.CAWL27377.msc12.plala.or.jp@localhost> for ; Fri, 18 May 2018 15:46:56 +0900 Date: Fri, 18 May 2018 15:46:51 +0900 (JST) Message-Id: <20180518.154651.1245356276560904866.ish@amail.plala.or.jp> To: freebsd-hackers@freebsd.org Subject: Re: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? From: Masachika ISHIZUKA In-Reply-To: <5AFE43FF.8020800@grosbein.net> References: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> <5AFE439D.4000801@grosbein.net> <5AFE43FF.8020800@grosbein.net> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; mvir-ac12; Fri, 18 May 2018 15:46:56 +0900 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 06:47:05 -0000 >>> I use a nootbook machine. >>> As this machine has no internal nic, I use a USB ethernet adapter(ue0). >>> I want to configure lagg0 of ue0 and iwm0, but I must wait to start >>> /etc/rc.d/netif until appearing the ue0. >>> I'm using patched netif as follows, but I must keep it whenever >>> 'mergemaster -Ui' is run. >>> Is there a more elegant way? >> >> Yes. In fact, you do not need to wait but "hook" on the event of ue0 creation. >> We have several ways to do that and simpliest one for network interface is >> using /etc/start_if.ue0 script like this: >> >> #!/bin/sh >> >> ifconfig ue0 up >> ifconfig lagg0 addm ue0 > > Sorry, this should be "ifconfig lagg0 laggport ue0" Thank you, Eugene. I wrote /etc/start_if.ue0 on 12-current r333704 as follows % cat /etc/start_if.ue0 #!/bin/sh ifconfig ue0 ether xx:xx:xx:xx:xx:xx up # set iwm0's mac address ifconfig lagg0 -laggport wlan0 laggport ue0 laggport wlan0 /etc/rc.d/wpa_supplicant start wlan0 Now, it works well. Thank you very much. -- Masachika ISHIZUKA From owner-freebsd-hackers@freebsd.org Fri May 18 17:01:31 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 B6F3CEAE45C; Fri, 18 May 2018 17:01:31 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gritton.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F3BC7F0CB; Fri, 18 May 2018 17:01:30 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) by gritton.org (8.15.2/8.15.2) with ESMTP id w4IGnFl5033855; Fri, 18 May 2018 10:49:15 -0600 (MDT) (envelope-from jamie@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 May 2018 10:49:15 -0600 From: James Gritton To: freebsd-jail@freebsd.org Cc: freebsd-hackers@freebsd.org, Fabian Freyer Subject: Re: sizeof jail parameter value strings Message-ID: X-Sender: jamie@freebsd.org User-Agent: Roundcube Webmail/1.3.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:01:31 -0000 [Sorry about bad headers and formatting - I took this off the archive page] "Fabian Freyer" wrote: > From jail(3): > >> The jail_getv() function takes a null-terminated list of name and >> value >> strings, and passes it to jail_get(2). It is the caller's >> responsibility >> to ensure that the value strings point to buffers large enough to >> hold >> the string representation of the returned parameters. > > What exactly does "large enough" mean here? Is there a way to query the > size of > the corresponding kernel buffers at runtime? Is there a maximum length > a la > MAX_JAIL_PARAM_LEN that the string representations of the returned > parameters > are guaranteed to be shorter than? > > I'm currently implementing a rust wrapper[1] around the jail(2) > interface, and am > not sure how large buffers for the string parameters I'm querying with > jail_get > jail_set have to be. There is a way to find the length of a string parameter, though there isn't a good library interface for it. The security.jail.param.* sysctls describe the form of the parameters, giving the type. The "contents" of these sysctls are generally unused (and set to zero), but for string parameters there's actually the max length of the string (itself in string form). For non-string parameters, the length in string form depends on the type of the parameters, so for an int you'll need as long as the string representation of an ant can be, etc. I don't know how much good C code will do for you for Rust work, but you might want to take a look at jailparam_type() in the libjail source code. It gets more complicated with array parameters, those that can hold an arbitrary number of values. The IP addresses are the best example of that. jail_getv() just isn't a good fit for such a parameter. I would recommend skipping out on jail_getv(), which is really only good for getting a few well-known parameters, and instead use the more complete but more complex jailparam_init/get/export/free. Again, if C helps, take a glance at the jls source. - Jamie From owner-freebsd-hackers@freebsd.org Fri May 18 17:19:47 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 17547EAEE83 for ; Fri, 18 May 2018 17:19:47 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 739217FBA8 for ; Fri, 18 May 2018 17:19:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id r2-v6so15053310lff.4 for ; Fri, 18 May 2018 10:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VEf/shxNvRx0+ZwD4xvN/t4TQMn0F5vs3lEwlPbXTc=; b=QioHw5DB/d7218hmyvhk42z9Okjp5bzEMVk7Lbo1xhnTPtjMzaGnGFmxoHoHbiY/ZS JasJNlYwVDI9INff1FBqigj81jjE+MTSMo44Y5KWDbO6ucZCtZyUwFBdYOpVlEQqOSGp IrKZVUOTGAdpJyI75jzq2UZph7YcPWZKYjTxlk2C2M41AMWqWGupglTizj6r1zk0sYid tJB4OAcf2WALCCp6TmCBBIRg5IW3+z8yiEcBmDNmvjdcpiG/cnzlN2RQ8jkp1EIYS0D7 2dVB1afkh0DTN9xmgNoAn6WgUBnOjNO+6N+J6F6HGWaPR73mrLdIMBaVr0C1F7p4FmWv ipvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VEf/shxNvRx0+ZwD4xvN/t4TQMn0F5vs3lEwlPbXTc=; b=fsmHmdHH0iHbclDtdjpStZvOBkS/3x55PY687/m5T4i0vFB2Qkhxk2qTdpclXMnQqO q5vyFmauh1iADRCMyHH3mzhYXVf9GZ/xh9/bHm6Ecp0KkrvxupcdArbMFR6lOWmECuAk w684OXkLXjlMTxcnCvgYGYWgn15J8gI2gB5O/w42Drx7eL+m5zM+XJw7VqunElD/u/ZC 6d9idx+B6AIqPQtGGLbVHvTzZzle8RwDyrbKgEKwpOB072qW7wbdzgU3XzHMafGifsT0 yFYsOgz7Q2b7EnBsbGEnz/SLA3+wChdxGeDhXA5vtiU8yZUWAHzylNzxWzBUnC+KbIo4 FBtw== X-Gm-Message-State: ALKqPwcxeBeLlzuvV21xiVM78sDnEO62Zav0X1YNcy8pxtLdlwzHoQhL qRW75KXomSoeVN+mf8qKKaDep/Vof/cuHc800oEtDg== X-Google-Smtp-Source: AB8JxZqAiAzk5p7XMW07vGssumQyTid7iIKMThlVw5Ki6Xz6wByslXzkdljtVkONBT9w4G8ZfgUS/nMectW2Cu5lqNM= X-Received: by 2002:a2e:9d07:: with SMTP id t7-v6mr5311138lji.7.1526663985001; Fri, 18 May 2018 10:19:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:219:0:0:0:0:0 with HTTP; Fri, 18 May 2018 10:19:44 -0700 (PDT) In-Reply-To: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> References: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> From: Freddie Cash Date: Fri, 18 May 2018 10:19:44 -0700 Message-ID: Subject: Re: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? To: Masachika ISHIZUKA Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:19:47 -0000 On Thu, May 17, 2018 at 7:30 PM, Masachika ISHIZUKA wrote: > Hi. > > I use a nootbook machine. > As this machine has no internal nic, I use a USB ethernet adapter(ue0). > I want to configure lagg0 of ue0 and iwm0, but I must wait to start > /etc/rc.d/netif until appearing the ue0. > I'm using patched netif as follows, but I must keep it whenever > 'mergemaster -Ui' is run. > Is there a more elegant way? > =E2=80=8BYour situation is pretty much the entire reason for the existence = of =E2=80=8B/etc/rc.d/netwait Read through the comments in that script for mo= re information. And the comments in /etc/defaults/rc.conf for netwait. Something along these lines in /etc/rc.conf is what you want (along with your normal ifconfig_* and wpa_* entries): netwait_if=3D"ue0 iwm0" That will cause the boot process to pause and wait for those two interfaces to appear before continuing on with the network configuration. There are various other netwait_* configuration entries that can used as well. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@freebsd.org Fri May 18 23:07:21 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 9DBD9EDF663 for ; Fri, 18 May 2018 23:07:21 +0000 (UTC) (envelope-from toasty@dragondata.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 20EB06E1D3 for ; Fri, 18 May 2018 23:07:21 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: by mailman.ysv.freebsd.org (Postfix) id D4E1FEDF652; Fri, 18 May 2018 23:07:20 +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 B0BBBEDF651 for ; Fri, 18 May 2018 23:07:20 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FA4B6E1CE for ; Fri, 18 May 2018 23:07:20 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: by mail-io0-x243.google.com with SMTP id e20-v6so8056601iof.4 for ; Fri, 18 May 2018 16:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fqauz3DAVJ/ulc8xirpk7NkzgRGTxGRjdVT1/6UI0Rg=; b=iLjY5q3XFgmx/mw0eeRQOwLAmUrLbsR6pmlrGggo0SsRbefqKj2cz+KxnV+ZIO2CWc 91zvLLc3cprHXXR2LFuEGWcWeC0r3kkeNZVa9QrW+unnDU116zQ5swC3XG9p5+F53tVb anqbVPFlfvyLz6/MTsOYftcSPEyCPpBfPPKiI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fqauz3DAVJ/ulc8xirpk7NkzgRGTxGRjdVT1/6UI0Rg=; b=bRnEx+nQpMhMOH0tLM+eekCwDZFOIzOFbv9bnu4ov8YYfmdW0eO1HTQnnjWHsdnpBs +navUhfZd3mL4Zj+H5ODrkFx8nBo7zUzdLC7s4fNZViVBVUIG3Hzg9giypYLb//31SiE tjGIKYZO8afU7liMLX0ovGqavX4tDsYU1t/lGd8ly/UjJ0nsOTvp7etQUU5iJBHetUkm STcTMZ3IgmRa0lnxSpIXX/eiLhDxRdUdAJtYzrJkDGuxuL7HRTytp0QTkWHo9/Rzo3QW MoNoISMuF5ebksT1fBU1MzGX0j3jcMkd0JckGcRL7pCTr4d7Rt9KH482/MyDKKUOW5yh jGPg== X-Gm-Message-State: ALKqPwd9hrxze8GaVj0YfzV1SYCyWMxHt/nxdxYE9WGZP0TFcgVw5QFl tPGhMDFU8FYtD9E2Sb/09F5OTQ== X-Google-Smtp-Source: AB8JxZqRo8SD1qSqsevTe6RtADovo/vamKBQuKv5hFN4HNllEJRGglOjY3+PqwFs2nxpPoLPZZRZgg== X-Received: by 2002:a6b:998d:: with SMTP id b135-v6mr13559251ioe.122.1526684839445; Fri, 18 May 2018 16:07:19 -0700 (PDT) Received: from unassigned.v6.your.org ([2001:4978:1:45:f036:4a7b:4b23:e977]) by smtp.gmail.com with ESMTPSA id t4-v6sm5284278ita.29.2018.05.18.16.07.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 16:07:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Current panic on boot on H11DSI motherboard with epyc cpu (nexus_add_irq: failed) From: Kevin Day In-Reply-To: <1616582.sIejGazfcv@ralph.baldwin.cx> Date: Fri, 18 May 2018 18:07:16 -0500 Cc: Vitalij Satanivskij , freebsd-current@freebsd.org, Stephen Hurd , cem@freebsd.org, Matthew Macy , "freebsd-hackers@freebsd.org" , Stephen Hurd Content-Transfer-Encoding: quoted-printable Message-Id: <40C20F1C-A3D7-4847-A365-DC94679E8ABF@dragondata.com> References: <20180416102710.GA90028@hell.ukr.net> <3628282.XVdngBdGlp@ralph.baldwin.cx> <20180418105649.GA9989@hell.ukr.net> <1616582.sIejGazfcv@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 23:07:21 -0000 > On Apr 18, 2018, at 1:42 PM, John Baldwin wrote: >>=20 >> Chenged made for it was >>=20 >> Index: sys/x86/x86/nexus.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/x86/x86/nexus.c (revision 332663) >> +++ sys/x86/x86/nexus.c (working copy) >> @@ -698,7 +698,7 @@ >> { >>=20 >> if (rman_manage_region(&irq_rman, irq, irq) !=3D 0) >> - panic("%s: failed", __func__); >> + panic("%s: failed irq is: %lu", __func__, irq); >> } >=20 > Ohhhh, this is a different issue. Sorry. As a hack, try changing > 'FIRST_MSI_INT' to 512 in sys/amd64/include/intr_machdep.h. The issue > is that some systems now include more than 256 interrupt pins on I/O > APICs, so IRQ 256 is already reserved for use by one of those > interrupt pins. The real fix is that I need to make FIRST_MSI_INT > dynamic instead of a constant and just define it as the first free IRQ > after the I/O APICs have probed. I'm testing a very large AMD Epyc system, and I had to change = FIRST_MSI_INT to 768, but that fixed this issue for me. From owner-freebsd-hackers@freebsd.org Sat May 19 00:05:35 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 528BAEE157D for ; Sat, 19 May 2018 00:05:35 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc13.plala.or.jp (msc13.plala.or.jp [60.36.166.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8C91970FE1 for ; Sat, 19 May 2018 00:05:34 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from localhost ([126.74.209.183]) by msc13.plala.or.jp with ESMTP id <20180519000320.DYQQ19885.msc13.plala.or.jp@localhost> for ; Sat, 19 May 2018 09:03:20 +0900 Date: Sat, 19 May 2018 09:03:15 +0900 (JST) Message-Id: <20180519.090315.2005975682115340886.ish@amail.plala.or.jp> To: freebsd-hackers@freebsd.org Subject: Re: How can I wait for a USB Ethernet adapter to appear to configure lagg on startup? From: Masachika ISHIZUKA In-Reply-To: References: <20180518.113009.439302765921485452.ish@amail.plala.or.jp> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 X-VirusScan: Outbound; mvir-ac13; Sat, 19 May 2018 09:03:20 +0900 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 00:05:35 -0000 Pj4gQXMgdGhpcyBtYWNoaW5lIGhhcyBubyBpbnRlcm5hbCBuaWMsIEkgdXNlIGEgVVNCIGV0aGVy bmV0IGFkYXB0ZXIodWUwKS4NCj4+IEkgd2FudCB0byBjb25maWd1cmUgbGFnZzAgb2YgdWUwIGFu ZCBpd20wLCBidXQgSSBtdXN0IHdhaXQgdG8gc3RhcnQNCj4+IC9ldGMvcmMuZC9uZXRpZiB1bnRp bCBhcHBlYXJpbmcgdGhlIHVlMC4NCj4+IEknbSB1c2luZyBwYXRjaGVkIG5ldGlmIGFzIGZvbGxv d3MsIGJ1dCBJIG11c3Qga2VlcCBpdCB3aGVuZXZlcg0KPj4gJ21lcmdlbWFzdGVyIC1VaScgaXMg cnVuLg0KPj4gSXMgdGhlcmUgYSBtb3JlIGVsZWdhbnQgd2F5Pw0KPj4NCj4g4oCLWW91ciBzaXR1 YXRpb24gaXMgcHJldHR5IG11Y2ggdGhlIGVudGlyZSByZWFzb24gZm9yIHRoZSBleGlzdGVuY2Ug b2YNCj4g4oCLL2V0Yy9yYy5kL25ldHdhaXQgIFJlYWQgdGhyb3VnaCB0aGUgY29tbWVudHMgaW4g dGhhdCBzY3JpcHQgZm9yIG1vcmUNCj4gaW5mb3JtYXRpb24uICBBbmQgdGhlIGNvbW1lbnRzIGlu IC9ldGMvZGVmYXVsdHMvcmMuY29uZiBmb3IgbmV0d2FpdC4NCj4gDQo+IFNvbWV0aGluZyBhbG9u ZyB0aGVzZSBsaW5lcyBpbiAvZXRjL3JjLmNvbmYgaXMgd2hhdCB5b3Ugd2FudCAoYWxvbmcgd2l0 aA0KPiB5b3VyIG5vcm1hbCBpZmNvbmZpZ18qIGFuZCB3cGFfKiBlbnRyaWVzKToNCj4gDQo+IG5l dHdhaXRfaWY9InVlMCBpd20wIg0KPiANCj4gVGhhdCB3aWxsIGNhdXNlIHRoZSBib290IHByb2Nl c3MgdG8gcGF1c2UgYW5kIHdhaXQgZm9yIHRob3NlIHR3byBpbnRlcmZhY2VzDQo+IHRvIGFwcGVh ciBiZWZvcmUgY29udGludWluZyBvbiB3aXRoIHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24uDQo+ IA0KPiBUaGVyZSBhcmUgdmFyaW91cyBvdGhlciBuZXR3YWl0XyogY29uZmlndXJhdGlvbiBlbnRy aWVzIHRoYXQgY2FuIHVzZWQgYXMNCj4gd2VsbC4NCg0KICBUaGFuayB5b3UgZm9yIHJlcGx5LCBG cmVkZGllLg0KDQogICdsYWdnMCcgaXMgY3JlYXRlZCBpbiAnbmV0aWYnLCBidXQgJ25ldHdhaXQn IGlzIGludm9rZWQgYWZ0ZXIgJ25ldGlmJywNCnNvICduZXR3YWl0JyBpcyBub3Qgc3VpdGFibGUg dG8gdGhpcyBjYXNlLiAgTXkgcGF0Y2hlZCAnbmV0aWYnIG9mIGZpcnN0DQptYWlsIGlzIGNyZWF0 ZWQgcmVmZXJyaW5nIHRvICduZXR3YWl0Jy4NCi0tIA0KTWFzYWNoaWthIElTSElaVUtBDQoNCiAg DQo=