From owner-freebsd-arch@FreeBSD.ORG Sun Dec 1 12:34:46 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D23463C; Sun, 1 Dec 2013 12:34:46 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 031321231; Sun, 1 Dec 2013 12:34:46 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 44A0FB80CF; Sun, 1 Dec 2013 13:34:43 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 31371CB4E; Sun, 1 Dec 2013 13:34:43 +0100 (CET) Date: Sun, 1 Dec 2013 13:34:43 +0100 From: Jilles Tjoelker To: Nathan Whitehorn Subject: Re: [CFT] bsdinstall and zfsboot enhancements Message-ID: <20131201123442.GA6818@stack.nl> References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> <5281441E.7060806@freebsd.org> <529A6862.7060308@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529A6862.7060308@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Teske, Devin" , Current Current , "freebsd-arch@freebsd.org" , Devin Teske , Peter Grehan , Michael Dexter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 12:34:46 -0000 On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote: > This took much longer than I'd anticipated, but the patch to init is > attached. I chose not to make the changes to init rather than > getttyent() and friends in libc, which I am open to revisiting. lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and will not allow root login on a "fake" TTY that getttynam() does not know. This module is enabled by default for the "login" service. So it is probably better to patch libc rather than init. > The behavior changes are as follows: > If the "console" device in /etc/ttys in marked "on", instead of opening > /dev/console, init will loop through the active kernel console devices, > and for each will: > 1. If the kernel console device is in /etc/ttys and marked "on", it > already has a terminal and will be ignored. > 2. If marked "off", that is an explicit statement that a console is not > wanted and so it will be ignored. > 3. If not present in /etc/ttys, init will run getty with whatever > parameters "console" has. This seems to make sense. > (3) is the main behavioral change. No changes in behavior will occur if > /etc/ttys is not modified. If we turn on "console" by default, it will > usually have no effect instead of trying to run multiple gettys, which > is new. If we then also comment out the ttyu0 line, instead of marking > it "off", the result will be the conditional presence of a login prompt > on the first serial port depending on whether it is an active console > device for the kernel. I believe this is the behavior we are going for. The terminal type for the console entry should probably be changed to something other than "unknown" to reduce annoyance. > Comments and test results would be appreciated. As a preparatory patch, you could remove se_index and session_index from init. They are only used to warn about a changed slot number in utmp(5) which is irrelevant with utmpx. This noise warning would also appear in most cases when changing from a "fake" console entry to a real line in /etc/ttys. Also, if you do decide to fake ttys entries in init rather than libc, the patch to init will be simpler. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Dec 6 04:13:00 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8051C914 for ; Fri, 6 Dec 2013 04:13:00 +0000 (UTC) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C074179C for ; Fri, 6 Dec 2013 04:13:00 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id nd7so134637qeb.31 for ; Thu, 05 Dec 2013 20:12:59 -0800 (PST) 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 :content-type; bh=DZMTjoK/vowYYVq+/GbP4Yydy16Q5Z1qSXnrR/S1NCM=; b=iZ6ywp04LviNQIKbaBsPFmEQV3Q5DlIlWdVHHkNXJpLxnbQoygWhZG/I5IUi31zTBH EdkzzUlpDG6kMdjEIZeoCRRbvEg9PsNikBknTYzycfWiBEGdYzFBzdgIr32xWdBltdHl 2K4X9T/bfxIPrVtFjlNZSffp5sVjheGawRXiU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=DZMTjoK/vowYYVq+/GbP4Yydy16Q5Z1qSXnrR/S1NCM=; b=Y0FLoy9eVHb1960ReilbC8+LSqjU96miUCnxoKksYsnw5tRW9LAjuTLM82TynEpWcB Gl9ghEiDio/l4Md4rjYAgDURwM++kc63al4vBL6agOYb6/gM8sLMd2ThABmqFJDojXl2 n5ilC+hUZRWP9DfipncP5TFGWVXxq6QzcTETjmPzhlwdY5AN77vqwkMBLaYmKq3JkyvD O1dEu7rZxE1o71tio51Ed0CCvOHRmPUbLqawmrxdFTptTNlK0PQGzJ/R0EG5Ofq39GwT vRZbyl1/IpPTBp8mGfjJbL30Rp7HYW5Sx2earRMzlEGPc+vekxgGLRyl2M9xJJK9SuoT HIHw== X-Gm-Message-State: ALoCoQl8ZDl9iDNMcFOevhz2meBt6aWUVKxJ7Z6lAnFoPdOOAXMoIBPwPtWP7SP24NffMwb4bxiO X-Received: by 10.224.61.198 with SMTP id u6mr2643929qah.41.1386303179433; Thu, 05 Dec 2013 20:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.86.42 with HTTP; Thu, 5 Dec 2013 20:12:29 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Thu, 5 Dec 2013 23:12:29 -0500 Message-ID: Subject: Fwd: hw.pci.do_power_nodriver=3 To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 04:13:00 -0000 I sent the following email to hackers@ - I was told to send to arch@ ---------- Forwarded message ---------- From: Eitan Adler Date: Sun, Nov 24, 2013 at 8:37 PM Subject: hw.pci.do_power_nodriver=3 To: "hackers@freebsd.org" Is there any reason we can not set hw.pci.do_power_nodriver=3 by default? My understanding is that there were problems with hardware being powered off and not being powered back on when drivers were loaded. Is this still a concern? If yes, can we flip the switch in HEAD and fix the drivers? -- Eitan Adler -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Fri Dec 6 05:44:04 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACDEF2BA for ; Fri, 6 Dec 2013 05:44:04 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75EAC1E05 for ; Fri, 6 Dec 2013 05:44:04 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id qd12so444617ieb.31 for ; Thu, 05 Dec 2013 21:43:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jwp/fDvfvD+GkvEUR6w6sMKiz6ADYpkmusPoVmKtAXQ=; b=b1WjEhivawkJkxXZcNWrUKw7FURuc+ls0f/SOJJmvWUAJ2NsQq4kDXKYA+4PqyOtvw EcdXWCkKyYaP6ZBdbDwx3E4pjaMIPHr2fef0pJdCA7z8wkamGDYAP5RcXdHpIfVj9l0o kTI+VcOWltB+pKtgyiH2v4kDV0Ys6KYaxVj8u+tvwQVOayhY7ZuRpuI8iGeB8nM1dT3a UxhJuvMi36dwfIPgIlgcFkOUq3LMHRoVyvPnE7yYsZJklh6HwpM7BkXzzNVfE0bp3t3v W6re1UPRCOlxtQPP+mmZHpVAmN6zdys1Wd31FNdWDZMvNgwE7Ix662t4pth6VxDQbTli HTtA== X-Gm-Message-State: ALoCoQm9sDPGI1JsIGhnnXmsSoaSzGCD47BSMo+6lbMmd27ysCje8STn00aTzMZDL1hCVWd/2D/f X-Received: by 10.50.30.166 with SMTP id t6mr901474igh.7.1386308637959; Thu, 05 Dec 2013 21:43:57 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qi3sm2028635igc.8.2013.12.05.21.43.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 21:43:57 -0800 (PST) Sender: Warner Losh Subject: Re: hw.pci.do_power_nodriver=3 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 5 Dec 2013 22:43:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eitan Adler X-Mailer: Apple Mail (2.1085) Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 05:44:04 -0000 On Dec 5, 2013, at 9:12 PM, Eitan Adler wrote: > Is there any reason we can not set hw.pci.do_power_nodriver=3D3 by = default? >=20 > My understanding is that there were problems with hardware being > powered off and not being powered back on when drivers were loaded. > Is this still a concern? If yes, can we flip the switch in HEAD and > fix the drivers? The reason it was for Adaptec RAID controllers. They had a weird topology: <-------------------- aac based card = --------------------------> pci bus ---- pci bridge ---- pci bus ---+----- some chip with = driver = +----- chip without driver so, when the enumeration code saw that there was no driver attached to = the second chip, it would power it down. Turns out, this chip, while it = didn't have a driver, was critical to the proper functioning of the RAID = card. Scott Long turned off the default power saving because he was = worried there were other parts like this. In addition, in an abundance = of caution, he also created stub drivers for the second chip for each of = the then known aac cards. Since then, it is unknown if others have followed this design or not, so = it is unknown our exposure if we were to flip this to have a different = default. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Dec 6 20:26:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B532BCC for ; Fri, 6 Dec 2013 20:26:21 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19CAF1DDF for ; Fri, 6 Dec 2013 20:26:20 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rB6KQHDC092412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 12:26:17 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rB6KQGPu092411; Fri, 6 Dec 2013 12:26:16 -0800 (PST) (envelope-from jmg) Date: Fri, 6 Dec 2013 12:26:16 -0800 From: John-Mark Gurney To: Warner Losh Subject: Re: hw.pci.do_power_nodriver=3 Message-ID: <20131206202616.GH55638@funkthat.com> Mail-Followup-To: Warner Losh , Eitan Adler , "freebsd-arch@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 06 Dec 2013 12:26:17 -0800 (PST) Cc: Eitan Adler , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:26:21 -0000 Warner Losh wrote this message on Thu, Dec 05, 2013 at 22:43 -0700: > > On Dec 5, 2013, at 9:12 PM, Eitan Adler wrote: > > Is there any reason we can not set hw.pci.do_power_nodriver=3 by default? > > > > My understanding is that there were problems with hardware being > > powered off and not being powered back on when drivers were loaded. > > Is this still a concern? If yes, can we flip the switch in HEAD and > > fix the drivers? > > The reason it was for Adaptec RAID controllers. > > They had a weird topology: > > <-------------------- aac based card --------------------------> > pci bus ---- pci bridge ---- pci bus ---+----- some chip with driver > +----- chip without driver > > so, when the enumeration code saw that there was no driver attached to the second chip, it would power it down. Turns out, this chip, while it didn't have a driver, was critical to the proper functioning of the RAID card. Scott Long turned off the default power saving because he was worried there were other parts like this. In addition, in an abundance of caution, he also created stub drivers for the second chip for each of the then known aac cards. > > Since then, it is unknown if others have followed this design or not, so it is unknown our exposure if we were to flip this to have a different default. Should we flip this on by default in HEAD to help expose these issues? It is expected that people running HEAD spend a little time helping us debug issues, and if they don't want to take the risk, they can change the default... Then maybe after a few years, maybe not 11, but for 12, we can keep it on by default for a release? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri Dec 6 20:52:16 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB902B41 for ; Fri, 6 Dec 2013 20:52:15 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3CAE1FE7 for ; Fri, 6 Dec 2013 20:52:15 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id at1so2181449iec.7 for ; Fri, 06 Dec 2013 12:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VL8+KTU/oVzRbyNgXyKs4U2b2FqLQRgzIWf3RriDLCI=; b=SJV4u0BBBoW/ikjPMnr82mdXuTLtRJh/pVcH/LlDLYKVmAKKMBzLmGSKcWsIv+HPgA oOU1Wqlany3re2i1SZymz3R03C/25Wu3aMX8eoIBkFjQFBohKSqDfRxGR5wpg6/T0ddk oO43lIYu/I06+YcrxuxxoUpZDfTTKOdFvRvqMNVVlzQ/vfL52k1CjCiBag6WGiRG+7MM 7e4tjhoM8SA7WiLR9lOCqX2CdO7yNJxwVF0Htitg+CeGPjwWT6jdibWOSM2GeW/U7j3y Ec1NY1WHPto79kTgV4/J65XE0YVxaHZeZkwLXvYmRJb5v1JRyuDeHcmx38yINYF10xJR 3/ow== X-Gm-Message-State: ALoCoQn2ic1w/FbOQfAbdL3HTVryJZpU/Xk136j2IgcaxDIMETx19dPdtCpLmOeBy+GmK9BIRzOB X-Received: by 10.50.1.102 with SMTP id 6mr4665907igl.0.1386363128496; Fri, 06 Dec 2013 12:52:08 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id o1sm5526729igh.9.2013.12.06.12.52.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 12:52:07 -0800 (PST) Sender: Warner Losh Subject: Re: hw.pci.do_power_nodriver=3 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20131206202616.GH55638@funkthat.com> Date: Fri, 6 Dec 2013 13:52:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91CBC153-C832-4350-8E19-24783A1CFA63@bsdimp.com> References: <20131206202616.GH55638@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: Eitan Adler , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:52:16 -0000 On Dec 6, 2013, at 1:26 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Thu, Dec 05, 2013 at 22:43 -0700: >>=20 >> On Dec 5, 2013, at 9:12 PM, Eitan Adler wrote: >>> Is there any reason we can not set hw.pci.do_power_nodriver=3D3 by = default? >>>=20 >>> My understanding is that there were problems with hardware being >>> powered off and not being powered back on when drivers were loaded. >>> Is this still a concern? If yes, can we flip the switch in HEAD and >>> fix the drivers? >>=20 >> The reason it was for Adaptec RAID controllers. >>=20 >> They had a weird topology: >>=20 >> <-------------------- aac based card = --------------------------> >> pci bus ---- pci bridge ---- pci bus ---+----- some chip with = driver >> = +----- chip without driver >>=20 >> so, when the enumeration code saw that there was no driver attached = to the second chip, it would power it down. Turns out, this chip, while = it didn't have a driver, was critical to the proper functioning of the = RAID card. Scott Long turned off the default power saving because he was = worried there were other parts like this. In addition, in an abundance = of caution, he also created stub drivers for the second chip for each of = the then known aac cards. >>=20 >> Since then, it is unknown if others have followed this design or not, = so it is unknown our exposure if we were to flip this to have a = different default. >=20 > Should we flip this on by default in HEAD to help expose these issues? > It is expected that people running HEAD spend a little time helping us > debug issues, and if they don't want to take the risk, they can change > the default... >=20 > Then maybe after a few years, maybe not 11, but for 12, we can keep it > on by default for a release? Scott and I talked about a possible solution that would be safe. Once I = have that implemented, we can likely switch things over... Warner From owner-freebsd-arch@FreeBSD.ORG Sat Dec 7 09:39:37 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8497E8F2; Sat, 7 Dec 2013 09:39:37 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 67F2D10C6; Sat, 7 Dec 2013 09:39:37 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version; b=dbB0Pb5/KNiL3Nk+8DxoNm3WdChERTYKetHOzOkipRQt4FFwxE/FRgJR2vx/HXdfStcmdG1Qe8rn pS2ckshRL1znf8PBEgacrpSq1AVdE2jappTu7AEYZtXkU1ndIUWi Received: from [192.168.11.5] (213.111.120.236 [213.111.120.236]) by mx.zohomail.com with SMTPS id 1386409171223646.3543062906579; Sat, 7 Dec 2013 01:39:31 -0800 (PST) Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: clutton To: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: <201311121354.03923.jhb@freebsd.org> References: <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> <20131112.134742.1669584178551946391.hrs@allbsd.org> <201311121354.03923.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Sat, 07 Dec 2013 11:39:27 +0200 Message-ID: <1386409167.1888.18.camel@eva02.mbsd> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 09:39:37 -0000 On Tue, 2013-11-12 at 13:54 -0500, John Baldwin wrote: Guys, it still doesn't work. Two days ago, when I changed my AP setup, in rc.conf and then run =C2=ABsudo service netif restart=C2=BB I'd observed= two copies of the wpa_supplicant. System is CURRENT b9061d4, I can't see the pgrep patch on it...