From owner-svn-src-head@freebsd.org Mon Mar 12 15:56:29 2018 Return-Path: Delivered-To: svn-src-head@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 7D6E3F50D91; Mon, 12 Mar 2018 15:56:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0776582626; Mon, 12 Mar 2018 15:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w2CFuIqj034698 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 17:56:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w2CFuIqj034698 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w2CFuHAB034697; Mon, 12 Mar 2018 17:56:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Mar 2018 17:56:17 +0200 From: Konstantin Belousov To: Ian Lepore Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r330780 - in head/sys: amd64/include isa x86/isa Message-ID: <20180312155617.GF76926@kib.kiev.ua> References: <201803111922.w2BJMwr8043084@repo.freebsd.org> <20180311195800.GC76926@kib.kiev.ua> <1520799639.84937.154.camel@freebsd.org> <20180311212539.GD76926@kib.kiev.ua> <1520868891.84937.177.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1520868891.84937.177.camel@freebsd.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 15:56:29 -0000 On Mon, Mar 12, 2018 at 09:34:51AM -0600, Ian Lepore wrote: > On Sun, 2018-03-11 at 23:25 +0200, Konstantin Belousov wrote: > > On Sun, Mar 11, 2018 at 02:20:39PM -0600, Ian Lepore wrote: > > > > > > On Sun, 2018-03-11 at 21:58 +0200, Konstantin Belousov wrote: > > > > > > > > On Sun, Mar 11, 2018 at 07:22:58PM +0000, Ian Lepore wrote: > > > > > > > > > > > > > > > [...] > > > > > > Unfortunately, this reverts one type of wrong locking back to another. > > > šThe need is to prevent access to the atrtc hardware if efi is > > > accessing it, and the locking I just reverted to that uses a sleepable > > > mutex only protects against inittodr()/resettodr() access, but not > > > against nvram(4) or if the atrtc is being used as an eventtimer (of > > > course nobody uses it for that, but the driver supports it). > > > > > > I have some pending changes that cause the atrtc driver to just not > > > attach at all if the efirtc driver attached, but they're stacked up > > > behind some other changes in phab. šAnd that still doesn't fix the > > > nvram(4) part of it. > > Not attaching atrtc if efirtc is attached sounds reasonable. But then > > you should also disable efirt attach if atrtc is on. One possible issue > > is that efirt is typicall loadable, while atrtc is compiled into the > > kernel, which means that efirt would become virtually unusable. > > > > Even if efirt is loaded (in loader(8)) the efirtc driver will still > attach instead of atrtc, because it's a direct child of nexus and gets > the first opportunity to probe and attach. šBut you raise a good point, > I should make it handle the case where it gets kldload'd when atrtc is > already attached. > > > For nvram(4), you can take the atrtc_time_lock around accesses in addition > > to the atrtc_lock, instead of providing exclusivity on the level of drivers > > attach. > > It occurs to me that an even better fix for all of this would be to > remove support for atrtc being an eventtimer. šThat allows removing the > interrupt filter handler, and then there's no need for a spinlock at > all, a sleepable mutex works fine for all accesses. > > Does anybody really need an eventtimer that runs only at a fixed > periodic rate of 32khz in 2018? Problem is that atrtc is what old machines use. If we have HPET or better LAPIC timers, then we do not need atrtc at all, of course. But e.g. 486 do not have them. I am not even sure about early amd64 machines. Definitely any machine that needs EFIRT has both HPET and LAPIC, I like the idea of not providing eventtimer backed by atrtc if feasible. Might be, make this a compile or runtime option, unless this over-complicates the code.