From owner-freebsd-hackers@freebsd.org Sun Mar 10 01:01:10 2019 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 00FDC153EA98 for ; Sun, 10 Mar 2019 01:01:10 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id 9208383758 for ; Sun, 10 Mar 2019 01:01:01 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Mar 2019 11:30:54 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2A10gA7004312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 10 Mar 2019 11:30:48 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2A0bsmF086296 for ; Sun, 10 Mar 2019 11:07:54 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2A0bptj086290; Sun, 10 Mar 2019 11:07:54 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <6dd8fe5f-6835-d98a-7592-0293406ccd63@selasky.org> Date: Sun, 10 Mar 2019 11:07:51 +1030 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <9E316D45-3538-4070-A8B0-05F9B71BC480@dons.net.au> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <6dd8fe5f-6835-d98a-7592-0293406ccd63@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 9208383758 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.09 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[midget.dons.net.au]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; IP_SCORE(0.75)[ip: (2.42), ipnet: 150.101.0.0/16(1.03), asn: 4739(0.33), country: AU(-0.04)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_IN_DNSWL_LOW(-0.10)[131.137.101.150.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.954,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.998,0]; DMARC_NA(0.00)[dons.net.au]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 01:01:10 -0000 > On 10 Mar 2019, at 01:55, Hans Petter Selasky wrote: > On 3/9/19 11:29 AM, O'Connor, Daniel wrote: >> If I hold the user space process in gdb 'forever' (eg over night) = usbconfig doesn't see the device, but the moment I quit the user space = process it can be seen again. >=20 > Check the output from "procstat -ak". Likely your application is not = closing the USB handle during device detach and so a deadlock happens. I ran it while stopped in the debugger.. [maarsytest 23:34] ~> procstat -k 20033 PID TID COMM TDNAME KSTACK 20033 100135 tclsh8.6 - mi_switch = thread_suspend_switch ptracestop cursig ast doreti_ast Then continued it and ran it a few more times.. [maarsytest 23:34] ~> procstat -k 20033 PID TID COMM TDNAME KSTACK 20033 100135 tclsh8.6 - mi_switch = sleepq_catch_signals sleepq_wait_sig _sleep pipe_read dofileread = kern_readv sys_read amd64_syscall fast_syscall_common [maarsytest 23:34] ~> procstat -k 20033 PID TID COMM TDNAME KSTACK 20033 100135 tclsh8.6 - mi_switch = sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt = seltdwait kern_select sys_select amd64_syscall fast_syscall_common > Also see: > libusb20_dev_check_connected() . Poll this function regularly to = figure out if disconnect is needed. Hmm, is this exposed in the libusb10 interface? The code I am using uses = that to talk to the device (although I have the source for it so can = modify it) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Sun Mar 10 10:15:54 2019 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 BBCAA152E83B for ; Sun, 10 Mar 2019 10:15:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4DCCB6F1B0 for ; Sun, 10 Mar 2019 10:15:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 087D7260209; Sun, 10 Mar 2019 11:15:51 +0100 (CET) Subject: Re: USB stack getting confused To: Konstantin Belousov Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> From: Hans Petter Selasky Message-ID: <3be2ea6e-f819-90e1-6e8b-56a5ed62d274@selasky.org> Date: Sun, 10 Mar 2019 11:15:28 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190310094758.GP2492@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DCCB6F1B0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.974,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 10:15:55 -0000 On 3/10/19 10:47 AM, Konstantin Belousov wrote: > On Sat, Mar 09, 2019 at 10:35:28PM +0100, Hans Petter Selasky wrote: >> On 3/9/19 8:23 PM, Konstantin Belousov wrote: >>> On Sat, Mar 09, 2019 at 11:41:31AM -0700, Warner Losh wrote: >>>> >>>> Is there a form of destroy_dev() that does a revoke on all open instances? >>>> Eg, this is gone, you can't use it anymore, and all further attempts to use >>>> the device will generate an error, but in the mean time we destroy the >>>> device and let the detach routine get on with life. waiting may make sense >>>> when you are merely unloading the driver (and getting to the detach routine >>>> that way), but when the device is gone, I've come around to the point of >>>> view that we should just destroy it w/o waiting for closes and anybody that >>>> touches it afterwards gets an error and has to cope with the error. But >>>> even in the unload case, we maybe we shouldn't get to the detach routine >>>> unless we're forcing and/or the detach routine just returns EBUSY since the >>>> only one that knows what dev_t's are associated with the device_t is the >>>> driver itself. >>> You are asking very basic questions about devfs there. >>> >>> destroy_dev(9) waits for two things: >>> - that all threads left the cdevsw methods for the given device; >>> - that all cdevpriv destructors finished running. >> >> Hi, >> >>> To facilitate waking up threads potentially sleeping inside the cdevsw >>> methods, drivers might implement d_purge method which must weed out sleeping >>> threads from inside the code in the bound time. >> >> USB will purge all callers before calling destroy_dev(). This is not the >> problem. >> >>> After that we return from destroy_dev(9) and guarantee that no new calls >>> into cdevsw is done for this device. devfs magic consumes the fo_ and >>> VOP_ calls and does not allow them to reach into the driver. >> >> When I designed the current USB devfs it was important to me to keep >> open() and close() calls balanced to avoid situations where an open call >> may setup some resource and then close(), which free this resource >> again, never gets called. destroy_dev(9) makes no such guarantee, and I >> think that is a failure of destroy_dev(9). That's when I started using >> the cdev's destructor callback function. > Lets correct the terminology first. > Are you referring to the d_open/d_close pairing ? > > Without D_TRACKCLOSE, d_close() is only called on the last close of > the device. With D_TRACKCLOSE, devfs _tries_ to call d_close each time > it sees the VOP_CLOSE() operation from VFS, but due to way VFS works > VOP_CLOSE() could be missed. Also, d_open vs d_close are not synchronized, > so a driver might get call to d_open in parallel to last d_close. Hi, I'm using D_TRACKCLOSE. > > What do you mean by cdev destructor callback function ? Do you mean > callback from destroy_dev_cb(), or do you actually reference the > destructors from devfs_set_cdevpriv(9) ? Yes, I mean the use of devfs_set_cdevpriv(9). > If the later, then destroy_dev() guarantees that all cdevpriv destructors > for all file descriptors opened against the destroyed cdev are finished > before destroy_dev() returns. In other words, if you use cdevpriv, you > can remove the drain for your refcount and everything should just work. Using devfs_set_cdevpriv(9), means destroy_dev() will be called after the last close() on the file descriptor in question. Is this strictly needed? You see this in the code that devfs_close_f() calls devfs_fpdrop(). > >> >>> So what usb does there is actively defeating existing mechanism by >>> keeping internal refcount on opens and refusing to call destroy_dev() >>> until the count goes to zero >> >> The FreeBSD USB stack also is used in environments w/o DEVFS and need >> own refcounts. > > I completely disagree with use of code sharing as excuse for FreeBSD bugs. > Like said, using devfs_set_cdevpriv(9), which the USB stack needs, basically means we are waiting for the final user-space close() or "struct file" refcount drop. This behaviour is not like announced. I would like to have the cdevpriv's destructor executed before destroy_dev() returns. Again, the USB stack needs paired operation. An open() call must always be followed by a close() call on the same FD. Else memory resources will leak simply. --HPS From owner-freebsd-hackers@freebsd.org Sun Mar 10 08:55:48 2019 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 7B56C152AF6B for ; Sun, 10 Mar 2019 08:55:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 508EB6C448 for ; Sun, 10 Mar 2019 08:55:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5B953260209; Sun, 10 Mar 2019 09:55:44 +0100 (CET) Subject: Re: USB stack getting confused To: "O'Connor, Daniel" Cc: FreeBSD Hackers References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <6dd8fe5f-6835-d98a-7592-0293406ccd63@selasky.org> <9E316D45-3538-4070-A8B0-05F9B71BC480@dons.net.au> From: Hans Petter Selasky Message-ID: <65e9e2dc-2c39-ad91-bc40-751cf40c3840@selasky.org> Date: Sun, 10 Mar 2019 09:55:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <9E316D45-3538-4070-A8B0-05F9B71BC480@dons.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 508EB6C448 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-6.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.71)[-0.708,0]; IP_SCORE(-3.28)[ip: (-9.49), ipnet: 88.99.0.0/16(-4.66), asn: 24940(-2.22), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 08:55:48 -0000 On 3/10/19 1:37 AM, O'Connor, Daniel wrote: > Hmm, is this exposed in the libusb10 interface? The code I am using uses that to talk to the device (although I have the source for it so can modify it) See libusb_check_connected(). --HPS From owner-freebsd-hackers@freebsd.org Sun Mar 10 10:26:53 2019 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 0DA88152EB56 for ; Sun, 10 Mar 2019 10:26:53 +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 48FA86F4F1 for ; Sun, 10 Mar 2019 10:26:52 +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 x2AAQTEh046271 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Mar 2019 12:26:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2AAQTEh046271 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2AAQTsI046270; Sun, 10 Mar 2019 12:26:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2019 12:26:29 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" Subject: Re: USB stack getting confused Message-ID: <20190310102629.GQ2492@kib.kiev.ua> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 10:26:53 -0000 On Sun, Mar 10, 2019 at 11:18:36AM +0100, Hans Petter Selasky wrote: > On 3/10/19 10:47 AM, Konstantin Belousov wrote: > >> Yes, I can do that if destroy_dev() ensures that d_close is called for > >> all open file handles once and only once before it returns. I think this > >> is where the problem comes from. > > See above. For d_close it is impossible, for cdevpriv dtr it is already > > there by design. > > > > Yes, cdevpriv_dtr will wait for the final close() from user-space > unfortunately. Or am I mistaken? You are mistaken. Cdevpriv destructors are called either on the file close (not the last close in d_close sense, just file close) OR during destroy_dev(). Each destructor/file pair is called exactly once, regardless of the cause. From owner-freebsd-hackers@freebsd.org Sun Mar 10 15:52:58 2019 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 7EDF01537C38 for ; Sun, 10 Mar 2019 15:52:58 +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 CD4C082966 for ; Sun, 10 Mar 2019 15:52:57 +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 x2AFqTwZ027727 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Mar 2019 17:52:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2AFqTwZ027727 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2AFqSM9027726; Sun, 10 Mar 2019 17:52:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2019 17:52:28 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" Subject: Re: USB stack getting confused Message-ID: <20190310155228.GR2492@kib.kiev.ua> References: <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 15:52:58 -0000 On Sun, Mar 10, 2019 at 02:10:23PM +0100, Hans Petter Selasky wrote: > On 3/10/19 11:26 AM, Konstantin Belousov wrote: > > On Sun, Mar 10, 2019 at 11:18:36AM +0100, Hans Petter Selasky wrote: > >> On 3/10/19 10:47 AM, Konstantin Belousov wrote: > >>>> Yes, I can do that if destroy_dev() ensures that d_close is called for > >>>> all open file handles once and only once before it returns. I think this > >>>> is where the problem comes from. > >>> See above. For d_close it is impossible, for cdevpriv dtr it is already > >>> there by design. > >>> > >> > >> Yes, cdevpriv_dtr will wait for the final close() from user-space > >> unfortunately. Or am I mistaken? > > > > You are mistaken. Cdevpriv destructors are called either on the file close > > (not the last close in d_close sense, just file close) OR during destroy_dev(). > > Each destructor/file pair is called exactly once, regardless of the cause. > > > > Can you try the attached patch? If you are asking me, then my testing would take too much time and I am not even sure when to declare success. As I noted, apcupsd closes the descriptor after access, so it is very hard to reproduce the problem. OTOH Daniel' setup sounds good for testing. > > --HPS > Index: sys/dev/usb/controller/usb_controller.c > =================================================================== > --- sys/dev/usb/controller/usb_controller.c (revision 344575) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -664,6 +664,33 @@ > USB_BUS_LOCK(bus); > } > } > + > +void > +usb_device_cleanup(struct usb_device *udev) > +{ > + struct usb_fs_privdata *pd; > + struct usb_bus *bus; > + int bus_index; > + int dev_index; > + > + bus = udev->bus; > + bus_index = device_get_unit(bus->bdev); > + dev_index = udev->device_index; > + > +retry: > + USB_BUS_LOCK(bus); > + LIST_FOREACH(pd, &bus->pd_cleanup_list, pd_next) { > + if (pd->bus_index != bus_index || > + pd->dev_index != dev_index) > + continue; > + LIST_REMOVE(pd, pd_next); > + USB_BUS_UNLOCK(bus); > + > + usb_destroy_dev_sync(pd); > + goto retry; > + } > + USB_BUS_UNLOCK(bus); > +} > #endif > > static void > Index: sys/dev/usb/usb_device.c > =================================================================== > --- sys/dev/usb/usb_device.c (revision 344575) > +++ sys/dev/usb/usb_device.c (working copy) > @@ -2322,6 +2322,13 @@ > &udev->cs_msg[0], &udev->cs_msg[1]); > USB_BUS_UNLOCK(udev->bus); > > +#if USB_HAVE_UGEN > + /* > + * Destroy character devices belonging to this > + * device synchronously: > + */ > + usb_device_cleanup(udev); > +#endif > /* wait for all references to go away */ > usb_wait_pending_refs(udev); > > Index: sys/dev/usb/usb_device.h > =================================================================== > --- sys/dev/usb/usb_device.h (revision 344575) > +++ sys/dev/usb/usb_device.h (working copy) > @@ -309,6 +309,7 @@ > usb_error_t usb_suspend_resume(struct usb_device *udev, > uint8_t do_suspend); > void usb_devinfo(struct usb_device *udev, char *dst_ptr, uint16_t dst_len); > +void usb_device_cleanup(struct usb_device *); > void usb_free_device(struct usb_device *, uint8_t); > void usb_linux_free_device(struct usb_device *dev); > uint8_t usb_peer_can_wakeup(struct usb_device *udev); From owner-freebsd-hackers@freebsd.org Sun Mar 10 09:48:30 2019 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 BC37C152D8A2 for ; Sun, 10 Mar 2019 09:48:30 +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 D95746E121 for ; Sun, 10 Mar 2019 09:48:29 +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 x2A9m0vA037253 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Mar 2019 11:48:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2A9m0vA037253 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2A9lwm0037252; Sun, 10 Mar 2019 11:47:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Mar 2019 11:47:58 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" Subject: Re: USB stack getting confused Message-ID: <20190310094758.GP2492@kib.kiev.ua> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 09:48:31 -0000 On Sat, Mar 09, 2019 at 10:35:28PM +0100, Hans Petter Selasky wrote: > On 3/9/19 8:23 PM, Konstantin Belousov wrote: > > On Sat, Mar 09, 2019 at 11:41:31AM -0700, Warner Losh wrote: > >> > >> Is there a form of destroy_dev() that does a revoke on all open instances? > >> Eg, this is gone, you can't use it anymore, and all further attempts to use > >> the device will generate an error, but in the mean time we destroy the > >> device and let the detach routine get on with life. waiting may make sense > >> when you are merely unloading the driver (and getting to the detach routine > >> that way), but when the device is gone, I've come around to the point of > >> view that we should just destroy it w/o waiting for closes and anybody that > >> touches it afterwards gets an error and has to cope with the error. But > >> even in the unload case, we maybe we shouldn't get to the detach routine > >> unless we're forcing and/or the detach routine just returns EBUSY since the > >> only one that knows what dev_t's are associated with the device_t is the > >> driver itself. > > You are asking very basic questions about devfs there. > > > > destroy_dev(9) waits for two things: > > - that all threads left the cdevsw methods for the given device; > > - that all cdevpriv destructors finished running. > > Hi, > > > To facilitate waking up threads potentially sleeping inside the cdevsw > > methods, drivers might implement d_purge method which must weed out sleeping > > threads from inside the code in the bound time. > > USB will purge all callers before calling destroy_dev(). This is not the > problem. > > > After that we return from destroy_dev(9) and guarantee that no new calls > > into cdevsw is done for this device. devfs magic consumes the fo_ and > > VOP_ calls and does not allow them to reach into the driver. > > When I designed the current USB devfs it was important to me to keep > open() and close() calls balanced to avoid situations where an open call > may setup some resource and then close(), which free this resource > again, never gets called. destroy_dev(9) makes no such guarantee, and I > think that is a failure of destroy_dev(9). That's when I started using > the cdev's destructor callback function. Lets correct the terminology first. Are you referring to the d_open/d_close pairing ? Without D_TRACKCLOSE, d_close() is only called on the last close of the device. With D_TRACKCLOSE, devfs _tries_ to call d_close each time it sees the VOP_CLOSE() operation from VFS, but due to way VFS works VOP_CLOSE() could be missed. Also, d_open vs d_close are not synchronized, so a driver might get call to d_open in parallel to last d_close. What do you mean by cdev destructor callback function ? Do you mean callback from destroy_dev_cb(), or do you actually reference the destructors from devfs_set_cdevpriv(9) ? If the later, then destroy_dev() guarantees that all cdevpriv destructors for all file descriptors opened against the destroyed cdev are finished before destroy_dev() returns. In other words, if you use cdevpriv, you can remove the drain for your refcount and everything should just work. > > > So what usb does there is actively defeating existing mechanism by > > keeping internal refcount on opens and refusing to call destroy_dev() > > until the count goes to zero > > The FreeBSD USB stack also is used in environments w/o DEVFS and need > own refcounts. I completely disagree with use of code sharing as excuse for FreeBSD bugs. > > > (I did not read the usb code, but I believe > > that I am not too wrong). > >Would usb core just destroy_dev() when the > > physical device goes away, then at worst the existing file descriptors > > opened against the lost devices would become dead (not same dead as > > terminals after revoke(2), but very similar). > > Yes, I can do that if destroy_dev() ensures that d_close is called for > all open file handles once and only once before it returns. I think this > is where the problem comes from. See above. For d_close it is impossible, for cdevpriv dtr it is already there by design. > > > > > If the problem is due to keeping some instance data for the opened device, > > then cdevpriv might be the better fit (at least the KPI was designed > > to be) than blocking destroy until all users are gone. > > > > The USB stack does not use MMAP, so this is not a problem. I do not follow, why does it matter ? On Sat, Mar 09, 2019 at 10:40:02PM +0100, Hans Petter Selasky wrote: > On 3/9/19 8:28 PM, Rozhuk Ivan wrote: > > On Sat, 9 Mar 2019 18:26:40 +0200 > > Konstantin Belousov wrote: > > > >> In fact I saw something similar with apcupsd and either usb/com > >> adapters or native usb control card for APC UPSes. For reasons I do > >> not understand, these devices are often disconnected. For older > >> versions of apcupsd, it required restart for newly reattached device > >> to be recreated in /dev. Sometimes it hangs whole usb stack. > >> > >> Newer apcupsd seems to open /dev/ugen only for the duration of the > >> query, which makes the erratic behaviour is much less likely, but > >> could still cause breakage when device disappear while apcupsd has it > >> opened. > >> > > > > Same problem with usb sound cards. > > I try to fix it, but fail with dsp, only mixer can be fixed with small code change. > > https://reviews.freebsd.org/D11140 > > > > Hi, > > How will these apps detect that they need to open the new /dev/mixer node? > > I mean, after hang is fixed, mixer app will still try to query the old > file handle forever? Userspace gets either ENXIO or EIO from syscalls. For polls, it gets POLLIN | POLLHUP immediately. From owner-freebsd-hackers@freebsd.org Sun Mar 10 10:17:48 2019 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 15AA1152E877 for ; Sun, 10 Mar 2019 10:17:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 A1B056F1C6 for ; Sun, 10 Mar 2019 10:17:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C7DC9260209; Sun, 10 Mar 2019 11:17:45 +0100 (CET) Subject: Re: USB stack getting confused To: Konstantin Belousov Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> From: Hans Petter Selasky Message-ID: <3c249477-fc95-6e02-abcd-ceda09f5cdc4@selasky.org> Date: Sun, 10 Mar 2019 11:17:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190310094758.GP2492@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A1B056F1C6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 10:17:48 -0000 On 3/10/19 10:47 AM, Konstantin Belousov wrote: >> Hi, >> >> How will these apps detect that they need to open the new /dev/mixer node? >> >> I mean, after hang is fixed, mixer app will still try to query the old >> file handle forever? > Userspace gets either ENXIO or EIO from syscalls. For polls, it gets > POLLIN | POLLHUP immediately. > It is likely that the app doesn't check the return value from the mixer IOCTL at all. --HPS From owner-freebsd-hackers@freebsd.org Sun Mar 10 17:27:31 2019 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 C477C153A9DE for ; Sun, 10 Mar 2019 17:27:31 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from mail.bithabitat.de (mail.bithabitat.de [84.200.61.29]) (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 CD75B85FCD for ; Sun, 10 Mar 2019 17:27:29 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 55350 invoked from network); 10 Mar 2019 18:18:59 -0000 Received: from mail.bithabitat.de (HELO mail.bithabitat.de) (erdgeist@erdgeist.org) by mail.bithabitat.de with ESMTPS (ECDHE-RSA-AES128-GCM-SHA256 encrypted); 10 Mar 2019 18:18:59 -0000 To: "" From: Dirk Engling Subject: Upgrading discontinued ports Openpgp: preference=signencrypt Autocrypt: addr=erdgeist@erdgeist.org; keydata= mQINBFjRKwsBEAC/F5QZPccZbcCuGmMG5TvjNSeaAZcRJSxKEC4hz8OPYyaPdxnFyq8qoeAB 9ou6oqmdBoNfkZHuByC9fZ2aa7OB1RKIKcwGanb1yp86Re4BZWtGXbXODGCR1I98E7z9klNM ZP8OQrPhi8GijpsWMOr6LDNEg/nWpnhMaGBvyrDTLzzm0u5w8cNWv/A+khQWIJPwR1sS+Jy/ 3aqiNTlkpweR/v6ElXcipKz4Ki/SYwmEfiYkicm63JRRetXu5s8+HTNMwJvfb+rb3e0TaHPL J1Wu68PFf8vogGBIOJIDRJBgmYOX7P4dTPJS7Xe99JUbUWEs0wlEWuv/5GU/QPfTBoBgCGG5 EGEc8SDEBMjef5O2RUubBxYgMSvw1ermYuonoNrBCqQh7Lj7aWEk0CwDj31hul52uGZneAEO TG1fg85S3h5vIRgwwBHbPkH+3HFLeCplmFeyR+wPNU6OulAOHvXLH1U+7yESMY4uN7Y95u+l MgVfIpLbGwfgOdmlVssqF5aSL0ScvMm0eoLToTYBroNwQ94M6as18ltQPIVsMMUlbwzzf8eo mBe56imYwtrqjKtAsqgwWNz42FqLq3mZC29zIdjGdwf8yPFnyvKK7CLyKT+Uir05YVc8Gw2P 0cuQ3WLlbQ6J8i1HpHFHPB0HaZx1YcaV65M9U+DgJDam+0JJzQARAQABtCREaXJrIEVuZ2xp bmcgPGVyZGdlaXN0QGVyZGdlaXN0Lm9yZz6JAkIEEwEIACwCGwMFCQeGH4AHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCWNErXAIZAQAKCRDy9hMrwy+yn2OYD/4kcNTqYd55y9axC3gD XQYNEttdWzC+OaTn5VeW82KKd3IGeO0oRjxi4FxfTyYH9qhk6rOnG0OdH/mYywEp1cNwOKAA hlumuQKFoKPxaQxIP+VTmp06BWLov46fWE+5hZNdoDawii6LRJ+sKK84nx9Y8v6Jb5IWeGcu PWhRIdqew6j9WJgWKa5cuVgj+h7/n0/4P3CcjhH2sXUs1Fw80xXfsTGNA4emAHf1xelplj+8 LUgK9VOftuuWsmSZtg7PzsgWcEAwVwxJQCUj7pwKGitBq4rOLMXV39aC7Spmz8oif/HBOmI2 BbM527xI36D6r6/S0Y1RqWqBZAOP7qslkG/wYcjd1wt+qKrRZUeeuO86U5/6vuKtO2a3Gyaj RbGQoxFiHNjZY18svcPqloT5geqCTfZDpZIz5zUj7mcBKPmbA1pO0nvg2ly7JaqdIeyZCdX2 +iYxuwbMesKQfB5GSF7oOOuWKOBDB9WH+8F+fKXJf++86eUqfcrHpNK6kXXVnrAh7QE7yWYq 5oONAH4iazX/7PSsOcOJuKyQCHmtEBgo83rb6H7hVMu6U+7SeVVslXv6aZQ0fF1YQ3dqAqoB 1QQIa4YLN0l60T4fHQqQmruzo4HtLvPEfq8rfL10fvEs45A/DsfMIsiRCzJTOoMTZ/hDYytr TzwR+KgcpM/8z4pMHbkCDQRY0SsLARAA0EG3+5KajPEkZr+YwTpuHKlC/9zwsrFlslep2Wr+ uQYvN5FH878aft0al25Arhx66Ac30hCTTqwA3ixa8AiwkF8sPhPhFKcEIDkWQvfNE5CA+Ljg h2Baeo6YizYRk6uoeHW8onYFvewIba4rsjpGClU6mzV9sP0VqJ2SZI/gUf+sL4vMHeEcnsX2 ipmKvtR5hsBWTS2ttobxLgNZBlQUuMaZHGUw9drG7AILjFrPnPp3nFIvYhT4zHqjqRhuyfcr 6SBO7bBPJJs82szrOa6pz8Bi4n6L6WhXRahnZsIfMYIXoczW4OvmCWdrX3oy8NqlD/SkxbwG 1jrIsdQQD5ecwsF94PvNpY53pXWIcZUCGzTzHVnZbAPvfNZgTpXLTf6Z6XvTxT/6fqbs7HjY KieZSsedg4fVHCGDADiRONHMnmqlkgyQ8PD0tIIT21GQaX6yrqnLlny/A2GpfygwkLz1LSCR 857633U6kMOYEqwE0SisTa6viugHfeA/9UEzU413KbEvIQA/UKPT1QWcN5Bln8iDFjlovE2g WKMwf93oOP0+uNcPIVdWcybWVyLh2qkCMpi/4gTq/+C8SrbMU5OKRrVuPBkjRwtukuOdVazA trB39wzQszsbEkFKuLXcroe+BAUIuJCIh+HK7UJcKeyYDJxSdnWucbHU7JUorkYEhq0AEQEA AYkCJQQYAQgADwUCWNErCwIbDAUJB4YfgAAKCRDy9hMrwy+yn8e+EACOc04tHvoO2piSmi0M bE3t7WadMseeP2LyVpZmttAauSmi00gLNXS6YSQsnNWsQ+JcEJfUdZOvrDREwqkCxKyhrU/9 hCJVruQzb8YHJsDHQPAc+BTvbVR8dlc/vUQyHuA8x2CjTGjybspyGTnDOY10f49Yc2MPeTeF x7Tsc4mnPQVHKWuBmfAVdM8OlDMCS5Q0C6dsb3nPrCJjYTwcsrT94gd6ra9xHF9bLQQO52VZ Vze7PZ10SJxoy7ry09au8mW0Q4PBtEvcra02TipeiaIzdMmt+X8l5HL3Vba60l9zHnr+I4Jx TpP/8i8Bm95W+7sNWUcIjRJGl1iif/CiaGp8PVyprTjrqYFzjSHkDdbm/tOekTQU6h0f+Clp t96h4qu8fLNdw/HLp+BCYnYwF37sgWY95Qw1cqmL21R9RDBArFJrlm2N1l8YZdw6jk35Bcbu H84H7Rwm7a5vmHIa9bH2WNz1ml34pPITuMMG85abF/dVEf81+zaW12VDzs43hZiaYieWrAQe A2/JSgdDGIPZx68Ysw5kojw53TC9/w3tMyIx82JgbvbbgY7gqsfPW0bv5B79mJeE3tUpDDPO Nl7VAtqnOWvPbbQFdOTMZz36Y/WBolx/bOqglPIGHHRt6t0i9LupLluhuIDSCQk7hOaQorSf YmbwUxzknuL+GhEDnw== Message-ID: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> Date: Sun, 10 Mar 2019 18:20:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CD75B85FCD X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.986,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[erdgeist.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.952,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.22)[asn: 31400(1.09), country: DE(-0.01)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.erdgeist.org]; NEURAL_SPAM_LONG(0.94)[0.943,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31400, ipnet:84.200.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 17:27:32 -0000 Hey, after upgrading 10.4->11.2 tonight I noticed some stale php56 packages still lingering around after pkg upgrade. Unfortunately it only occured to me after upgrading 25 of around 50 jails, meaning I had to start over checking for them. Is there a way to upgrade a system with warnings about old packages and successor recommendations? erdgeist From owner-freebsd-hackers@freebsd.org Sun Mar 10 10:19:02 2019 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 7BD54152E8A5 for ; Sun, 10 Mar 2019 10:19:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 185B76F1D8 for ; Sun, 10 Mar 2019 10:19:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D744C260209; Sun, 10 Mar 2019 11:18:59 +0100 (CET) Subject: Re: USB stack getting confused To: Konstantin Belousov Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> From: Hans Petter Selasky Message-ID: <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> Date: Sun, 10 Mar 2019 11:18:36 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190310094758.GP2492@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 185B76F1D8 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 10:19:02 -0000 On 3/10/19 10:47 AM, Konstantin Belousov wrote: >> Yes, I can do that if destroy_dev() ensures that d_close is called for >> all open file handles once and only once before it returns. I think this >> is where the problem comes from. > See above. For d_close it is impossible, for cdevpriv dtr it is already > there by design. > Yes, cdevpriv_dtr will wait for the final close() from user-space unfortunately. Or am I mistaken? --HPS From owner-freebsd-hackers@freebsd.org Sun Mar 10 13:10:51 2019 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 6B5A01532E6D for ; Sun, 10 Mar 2019 13:10:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1FB275929 for ; Sun, 10 Mar 2019 13:10:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6EF6B260297; Sun, 10 Mar 2019 14:10:47 +0100 (CET) Subject: Re: USB stack getting confused To: Konstantin Belousov Cc: Warner Losh , FreeBSD Hackers , "O'Connor, Daniel" References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> From: Hans Petter Selasky Message-ID: <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> Date: Sun, 10 Mar 2019 14:10:23 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190310102629.GQ2492@kib.kiev.ua> Content-Type: multipart/mixed; boundary="------------0E1FE1B809FEA2746CA2885F" Content-Language: en-US X-Rspamd-Queue-Id: E1FB275929 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 13:10:51 -0000 This is a multi-part message in MIME format. --------------0E1FE1B809FEA2746CA2885F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/10/19 11:26 AM, Konstantin Belousov wrote: > On Sun, Mar 10, 2019 at 11:18:36AM +0100, Hans Petter Selasky wrote: >> On 3/10/19 10:47 AM, Konstantin Belousov wrote: >>>> Yes, I can do that if destroy_dev() ensures that d_close is called for >>>> all open file handles once and only once before it returns. I think this >>>> is where the problem comes from. >>> See above. For d_close it is impossible, for cdevpriv dtr it is already >>> there by design. >>> >> >> Yes, cdevpriv_dtr will wait for the final close() from user-space >> unfortunately. Or am I mistaken? > > You are mistaken. Cdevpriv destructors are called either on the file close > (not the last close in d_close sense, just file close) OR during destroy_dev(). > Each destructor/file pair is called exactly once, regardless of the cause. > Can you try the attached patch? --HPS --------------0E1FE1B809FEA2746CA2885F Content-Type: text/x-patch; name="usb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="usb.diff" Index: sys/dev/usb/controller/usb_controller.c =================================================================== --- sys/dev/usb/controller/usb_controller.c (revision 344575) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -664,6 +664,33 @@ USB_BUS_LOCK(bus); } } + +void +usb_device_cleanup(struct usb_device *udev) +{ + struct usb_fs_privdata *pd; + struct usb_bus *bus; + int bus_index; + int dev_index; + + bus = udev->bus; + bus_index = device_get_unit(bus->bdev); + dev_index = udev->device_index; + +retry: + USB_BUS_LOCK(bus); + LIST_FOREACH(pd, &bus->pd_cleanup_list, pd_next) { + if (pd->bus_index != bus_index || + pd->dev_index != dev_index) + continue; + LIST_REMOVE(pd, pd_next); + USB_BUS_UNLOCK(bus); + + usb_destroy_dev_sync(pd); + goto retry; + } + USB_BUS_UNLOCK(bus); +} #endif static void Index: sys/dev/usb/usb_device.c =================================================================== --- sys/dev/usb/usb_device.c (revision 344575) +++ sys/dev/usb/usb_device.c (working copy) @@ -2322,6 +2322,13 @@ &udev->cs_msg[0], &udev->cs_msg[1]); USB_BUS_UNLOCK(udev->bus); +#if USB_HAVE_UGEN + /* + * Destroy character devices belonging to this + * device synchronously: + */ + usb_device_cleanup(udev); +#endif /* wait for all references to go away */ usb_wait_pending_refs(udev); Index: sys/dev/usb/usb_device.h =================================================================== --- sys/dev/usb/usb_device.h (revision 344575) +++ sys/dev/usb/usb_device.h (working copy) @@ -309,6 +309,7 @@ usb_error_t usb_suspend_resume(struct usb_device *udev, uint8_t do_suspend); void usb_devinfo(struct usb_device *udev, char *dst_ptr, uint16_t dst_len); +void usb_device_cleanup(struct usb_device *); void usb_free_device(struct usb_device *, uint8_t); void usb_linux_free_device(struct usb_device *dev); uint8_t usb_peer_can_wakeup(struct usb_device *udev); --------------0E1FE1B809FEA2746CA2885F-- From owner-freebsd-hackers@freebsd.org Sun Mar 10 23:22:28 2019 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 EE1441545F26 for ; Sun, 10 Mar 2019 23:22:27 +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 3FA236C3C7 for ; Sun, 10 Mar 2019 23:22:26 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1552260139; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=gL5WVG0o8bd+gn4Bh8BWnaaCjiCQrX9EVol58O2pN9jSBcvUkfBAs6kM1yOa8fqoXU6IMQ0eHr9tk GDRwJfaujgeXoIDdbOjQb6C8hzbtXMjoV6k1SpSVFln/BsXIHSFj2RQq3abkipGiLiJbP17eBQvJL4 0M1ev9p5dnIOzDIO9i4LG9OxvLXnsSywDuPsj0BJUgMtxiyPIyL1HZgJyBAbfpbGYLPFVkWo5yz8Pm LcWtUmLP62grsNgTyusqTnKEsJwvyxFiDrfU4NLsD7vf5w5ICQhMf/Qp45Y58VAbSUqTzKivpFkVdc Bj1frODyKVflPWPnSLZOxa/1ykRJVww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:dkim-signature:from; bh=XoUUtYhqD62B4KEiNxmYupQHL2lcmjTKe/tcy6KejHA=; b=DuvMadPYDkokbbkr648debxqnbFR47PWxserJUAqFzah5VYhxlXCpD1MmAjn23QL2rBa+qazA1wue W0n4+OK+RQPa2JxNhEi7OqwqhQnbmT7CGFiSokT5Snm3+4PePHVonjmfFv0g1JpkJcUkGTYnPq8xMK rDDZyk9qC6yyifBNNiUUJu+YPPd62zOH07cJn8QBkcREJvS4xeAjzatkbeAIMBkCFrGDnNvt4HTVur HDHBcjynX7rY+WoJ1vzOWfbHNyBgpNIKR7UO0kt0Htv+3oIFPTvT+6kiIYAf01RBB7GyjZxK+Oh6kx 4SSKeRXQbQqrDZpneIfQkp+1HtDmTrA== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:from; bh=XoUUtYhqD62B4KEiNxmYupQHL2lcmjTKe/tcy6KejHA=; b=a25uxYqFZBTeuRCl+3ZjlLkIq1W5sKdQuwHQAyZXO6D0Ia6xfajZLETMT9VZuJ2984g5EohPi+CZJ CMOxLMSOQ2Me9qGCCIPlnM6VQJJql5GLj349xrXm9XN8I1CgNMFGaeIL07Exm4vDeCZkJAyy40X0Vm C/iKczTH5ZdMnWxYd6hEuxD9K2YqJ7Ciuc9HkGmSEouXtiv3l7kQ0YJ3hmtKCoK5az9Il1YiqhXjDP ROI8T+98COb05B5DtgydMB8DqmE8XUDO1h6CUbYVHesdmN4JnfXUxY9l2Dk4wuVTM0K4qfO95dsDBV JZdp6Yli3GDOZE8GjFAkEbaYU8sc+Hg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 56fcf45a-438b-11e9-803b-31925da7267c 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 outbound2.eu.mailhop.org (Halon) with ESMTPSA id 56fcf45a-438b-11e9-803b-31925da7267c; Sun, 10 Mar 2019 23:22:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2ANME55041065; Sun, 10 Mar 2019 17:22:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Device-independent labels for geom_flashmap slices From: Ian Lepore To: FreeBSD Hackers , freebsd-embedded@freebsd.org Date: Sun, 10 Mar 2019 17:22:14 -0600 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3FA236C3C7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 23:22:28 -0000 geom_flashmap is inherently based on label names, but it creates devfs entries for each slice which include the hardware device name. I've added support for geom_flashmap to the geom_label class, so that the labels are also created in /dev/flash without reference to the device name, similar to how labels work for GPT partitions and filesystems. I've created a review for the proposed changes at https://reviews.freebsd.org/D19535 -- Ian From owner-freebsd-hackers@freebsd.org Mon Mar 11 06:48:25 2019 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 7EEFE1532DFD for ; Mon, 11 Mar 2019 06:48:25 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from mail.bithabitat.de (mail.bithabitat.de [84.200.61.29]) (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 5ED648557E for ; Mon, 11 Mar 2019 06:48:24 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 18114 invoked from network); 11 Mar 2019 07:42:34 -0000 Received: from mail.bithabitat.de (HELO mail.bithabitat.de) (erdgeist@erdgeist.org) by mail.bithabitat.de with ESMTPS (ECDHE-RSA-AES128-GCM-SHA256 encrypted); 11 Mar 2019 07:42:34 -0000 Subject: Re: Upgrading discontinued ports To: Robert Ayrapetyan Cc: "" References: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> From: Dirk Engling Openpgp: preference=signencrypt Autocrypt: addr=erdgeist@erdgeist.org; keydata= mQINBFjRKwsBEAC/F5QZPccZbcCuGmMG5TvjNSeaAZcRJSxKEC4hz8OPYyaPdxnFyq8qoeAB 9ou6oqmdBoNfkZHuByC9fZ2aa7OB1RKIKcwGanb1yp86Re4BZWtGXbXODGCR1I98E7z9klNM ZP8OQrPhi8GijpsWMOr6LDNEg/nWpnhMaGBvyrDTLzzm0u5w8cNWv/A+khQWIJPwR1sS+Jy/ 3aqiNTlkpweR/v6ElXcipKz4Ki/SYwmEfiYkicm63JRRetXu5s8+HTNMwJvfb+rb3e0TaHPL J1Wu68PFf8vogGBIOJIDRJBgmYOX7P4dTPJS7Xe99JUbUWEs0wlEWuv/5GU/QPfTBoBgCGG5 EGEc8SDEBMjef5O2RUubBxYgMSvw1ermYuonoNrBCqQh7Lj7aWEk0CwDj31hul52uGZneAEO TG1fg85S3h5vIRgwwBHbPkH+3HFLeCplmFeyR+wPNU6OulAOHvXLH1U+7yESMY4uN7Y95u+l MgVfIpLbGwfgOdmlVssqF5aSL0ScvMm0eoLToTYBroNwQ94M6as18ltQPIVsMMUlbwzzf8eo mBe56imYwtrqjKtAsqgwWNz42FqLq3mZC29zIdjGdwf8yPFnyvKK7CLyKT+Uir05YVc8Gw2P 0cuQ3WLlbQ6J8i1HpHFHPB0HaZx1YcaV65M9U+DgJDam+0JJzQARAQABtCREaXJrIEVuZ2xp bmcgPGVyZGdlaXN0QGVyZGdlaXN0Lm9yZz6JAkIEEwEIACwCGwMFCQeGH4AHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCWNErXAIZAQAKCRDy9hMrwy+yn2OYD/4kcNTqYd55y9axC3gD XQYNEttdWzC+OaTn5VeW82KKd3IGeO0oRjxi4FxfTyYH9qhk6rOnG0OdH/mYywEp1cNwOKAA hlumuQKFoKPxaQxIP+VTmp06BWLov46fWE+5hZNdoDawii6LRJ+sKK84nx9Y8v6Jb5IWeGcu PWhRIdqew6j9WJgWKa5cuVgj+h7/n0/4P3CcjhH2sXUs1Fw80xXfsTGNA4emAHf1xelplj+8 LUgK9VOftuuWsmSZtg7PzsgWcEAwVwxJQCUj7pwKGitBq4rOLMXV39aC7Spmz8oif/HBOmI2 BbM527xI36D6r6/S0Y1RqWqBZAOP7qslkG/wYcjd1wt+qKrRZUeeuO86U5/6vuKtO2a3Gyaj RbGQoxFiHNjZY18svcPqloT5geqCTfZDpZIz5zUj7mcBKPmbA1pO0nvg2ly7JaqdIeyZCdX2 +iYxuwbMesKQfB5GSF7oOOuWKOBDB9WH+8F+fKXJf++86eUqfcrHpNK6kXXVnrAh7QE7yWYq 5oONAH4iazX/7PSsOcOJuKyQCHmtEBgo83rb6H7hVMu6U+7SeVVslXv6aZQ0fF1YQ3dqAqoB 1QQIa4YLN0l60T4fHQqQmruzo4HtLvPEfq8rfL10fvEs45A/DsfMIsiRCzJTOoMTZ/hDYytr TzwR+KgcpM/8z4pMHbkCDQRY0SsLARAA0EG3+5KajPEkZr+YwTpuHKlC/9zwsrFlslep2Wr+ uQYvN5FH878aft0al25Arhx66Ac30hCTTqwA3ixa8AiwkF8sPhPhFKcEIDkWQvfNE5CA+Ljg h2Baeo6YizYRk6uoeHW8onYFvewIba4rsjpGClU6mzV9sP0VqJ2SZI/gUf+sL4vMHeEcnsX2 ipmKvtR5hsBWTS2ttobxLgNZBlQUuMaZHGUw9drG7AILjFrPnPp3nFIvYhT4zHqjqRhuyfcr 6SBO7bBPJJs82szrOa6pz8Bi4n6L6WhXRahnZsIfMYIXoczW4OvmCWdrX3oy8NqlD/SkxbwG 1jrIsdQQD5ecwsF94PvNpY53pXWIcZUCGzTzHVnZbAPvfNZgTpXLTf6Z6XvTxT/6fqbs7HjY KieZSsedg4fVHCGDADiRONHMnmqlkgyQ8PD0tIIT21GQaX6yrqnLlny/A2GpfygwkLz1LSCR 857633U6kMOYEqwE0SisTa6viugHfeA/9UEzU413KbEvIQA/UKPT1QWcN5Bln8iDFjlovE2g WKMwf93oOP0+uNcPIVdWcybWVyLh2qkCMpi/4gTq/+C8SrbMU5OKRrVuPBkjRwtukuOdVazA trB39wzQszsbEkFKuLXcroe+BAUIuJCIh+HK7UJcKeyYDJxSdnWucbHU7JUorkYEhq0AEQEA AYkCJQQYAQgADwUCWNErCwIbDAUJB4YfgAAKCRDy9hMrwy+yn8e+EACOc04tHvoO2piSmi0M bE3t7WadMseeP2LyVpZmttAauSmi00gLNXS6YSQsnNWsQ+JcEJfUdZOvrDREwqkCxKyhrU/9 hCJVruQzb8YHJsDHQPAc+BTvbVR8dlc/vUQyHuA8x2CjTGjybspyGTnDOY10f49Yc2MPeTeF x7Tsc4mnPQVHKWuBmfAVdM8OlDMCS5Q0C6dsb3nPrCJjYTwcsrT94gd6ra9xHF9bLQQO52VZ Vze7PZ10SJxoy7ry09au8mW0Q4PBtEvcra02TipeiaIzdMmt+X8l5HL3Vba60l9zHnr+I4Jx TpP/8i8Bm95W+7sNWUcIjRJGl1iif/CiaGp8PVyprTjrqYFzjSHkDdbm/tOekTQU6h0f+Clp t96h4qu8fLNdw/HLp+BCYnYwF37sgWY95Qw1cqmL21R9RDBArFJrlm2N1l8YZdw6jk35Bcbu H84H7Rwm7a5vmHIa9bH2WNz1ml34pPITuMMG85abF/dVEf81+zaW12VDzs43hZiaYieWrAQe A2/JSgdDGIPZx68Ysw5kojw53TC9/w3tMyIx82JgbvbbgY7gqsfPW0bv5B79mJeE3tUpDDPO Nl7VAtqnOWvPbbQFdOTMZz36Y/WBolx/bOqglPIGHHRt6t0i9LupLluhuIDSCQk7hOaQorSf YmbwUxzknuL+GhEDnw== Message-ID: <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> Date: Mon, 11 Mar 2019 07:48:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5ED648557E X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.81 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.893,0]; IP_SCORE(0.21)[asn: 31400(1.08), country: DE(-0.01)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[erdgeist.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.958,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.erdgeist.org]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.85)[0.851,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31400, ipnet:84.200.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 06:48:25 -0000 On 11.03.19 04:56, Robert Ayrapetyan wrote: > Are you sure you've used a "force" flag, e.g. "pkg-static upgrade > -f"? Yes. But all that does is force reinstall installed packages. However the old package just isn't in the pkg repo anymore, so there's nothing to re-install. erdgeist From owner-freebsd-hackers@freebsd.org Mon Mar 11 03:56:46 2019 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 10E94152D397 for ; Mon, 11 Mar 2019 03:56:46 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2FA377ADC for ; Mon, 11 Mar 2019 03:56:44 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-oi1-x22c.google.com with SMTP id z14so2552304oid.0 for ; Sun, 10 Mar 2019 20:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T1k2YJwErVp8e/khSo7InsqgoxTNlSvkJvXEiA66W+4=; b=ODvNwGEN9Z6aNCEsVndrhVo0KCHbKcZPpDl7dmtxLj9bKeAGQoeYNiTw7mv2OyKNfu ldCrrIj/yInk0xTnNDq3dqAoGicrTIuGn/sXWkjdnoG2yCcqPhnxfnk6vTA3y91McRSH CrLhvq0a9h0iO/E3oKdMMbSC8r3Hyk5ogt8aYp69i8qRxZKjVM5fbrgXstfyPXHIAB/m rlv2AgvyBSpumzGIrJsLSg4WAfDvQMwzAla778H29C+jgWfygwejvOS1LhYzG7cRLkQQ HHx/kykIFnpaKQS7oCbku4TOkz4KMBVsCWZIArCxLS1J0/bnB/2zOEAHrxuQXMslQ+T0 OS3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T1k2YJwErVp8e/khSo7InsqgoxTNlSvkJvXEiA66W+4=; b=bDOlUT51HHVzbhOTkesbss7EBTzA3EMVaKZ41mCMQzR8G7A/e5aJYt9mb1rGZZkEMW u+tbUPEzrwdMN6ag6zUliKa6Jup2IcyeN5U/j6OLIAMp2okS1F3gY2iyHHBgAXpem/Nq J2iWBWbWJNzpQxzM8ZhiCfejN9LYRxlLW8dWE4HOuX7ZW9g8y2snoRjrXy+py253MwNG z5FlvER3sm+vhdRK7czZh6vuYlNxgAaERtATlZFqub0+4xaUV8hmL1JoQTOkN8qcM06F 5P5+MOPWdZhfczA7dFzy9ocFNw9vprTYR4vP9Rz5accPhRaeAQGRgfXKLHS428qqxAOd bCzw== X-Gm-Message-State: APjAAAX4M9a+CpHqoS4Qnyl/01OcDiTf55ud4ayRgGtzJ20LNIhgHy75 RWLzQipTUCOYy4Cst1K/b1X5RhIaGlISRe3DP5en X-Google-Smtp-Source: APXvYqzWYx95jReGclBqEzOkwIwCktSaZIblxBPMCqADfPsH0wMlPWI7r6T72TzmsR+s8a3/5fTNZxYDHp5KlZJJtcQ= X-Received: by 2002:aca:45d4:: with SMTP id s203mr15768105oia.107.1552276603693; Sun, 10 Mar 2019 20:56:43 -0700 (PDT) MIME-Version: 1.0 References: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> In-Reply-To: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> From: Robert Ayrapetyan Date: Sun, 10 Mar 2019 20:56:07 -0700 Message-ID: Subject: Re: Upgrading discontinued ports To: Dirk Engling Cc: "" X-Rspamd-Queue-Id: A2FA377ADC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ODvNwGEN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robertayrapetyan@gmail.com designates 2607:f8b0:4864:20::22c as permitted sender) smtp.mailfrom=robertayrapetyan@gmail.com X-Spamd-Result: default: False [-6.83 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.85)[ip: (-9.39), ipnet: 2607:f8b0::/32(-2.74), asn: 15169(-2.07), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 03:56:46 -0000 Are you sure you've used a "force" flag, e.g. "pkg-static upgrade -f"? On Sun, Mar 10, 2019 at 5:53 PM Dirk Engling wrote: > Hey, > > after upgrading 10.4->11.2 tonight I noticed some stale php56 packages > still lingering around after pkg upgrade. Unfortunately it only occured > to me after upgrading 25 of around 50 jails, meaning I had to start over > checking for them. > > Is there a way to upgrade a system with warnings about old packages and > successor recommendations? > > erdgeist > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Mar 11 04:31:08 2019 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 828A1152E556 for ; Mon, 11 Mar 2019 04:31:08 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by mx1.freebsd.org (Postfix) with ESMTP id 424B880A5A for ; Mon, 11 Mar 2019 04:31:05 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Mar 2019 15:00:57 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2B4UhJJ085726 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Mar 2019 15:00:53 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2B4U6OZ083127 for ; Mon, 11 Mar 2019 15:00:06 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2B4U68r083118; Mon, 11 Mar 2019 15:00:06 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> Date: Mon, 11 Mar 2019 15:00:06 +1030 Cc: Konstantin Belousov , Warner Losh , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 424B880A5A X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.01 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: midget.dons.net.au]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; IP_SCORE(0.70)[ip: (2.23), ipnet: 150.101.0.0/16(0.99), asn: 4739(0.33), country: AU(-0.04)]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[131.137.101.150.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.93)[0.926,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.994,0]; DMARC_NA(0.00)[dons.net.au]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 04:31:08 -0000 > On 11 Mar 2019, at 14:27, O'Connor, Daniel wrote: > I can dig into the kernel part if you want but will need some guidance = where to look.. Note that I put a dtrace probe on ugen_open and usb_fifo_open and it = does not fire for 0.5, eg.. [maarsytest 4:28] ~> sudo dtrace -s ~/usb_fifo.d 2324 Password: dtrace: script '/home/radar/usb_fifo.d' matched 4 probes CPU ID FUNCTION:NAME 2 65418 openat:entry Open: = /home/radar/ud3/run/experiment.stemp 0 65418 openat:entry Open: = /local0/Measurements/Phasetest/20190311-0428.noise 2 65418 openat:entry Open: = /home/radar/ud3/lib/acquisition//integrate.plugin 3 65418 openat:entry Open: /dev/ugsio0.ud 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff822946a0 3 12031 usb_fifo_open:return Return: 0 Errno: 9 3 65418 openat:entry Open: /dev/ussio0.ud 0 65418 openat:entry Open: /dev/usbctl 0 65418 openat:entry Open: /dev/ugen0.1 0 12030 usb_fifo_open:entry Ugen: ugen0.1 f_open: = ffffffff8093fd00 0 12102 ugen_open:return Return: 0 Errno: 0 0 12031 usb_fifo_open:return Return: 0 Errno: 0 0 12030 usb_fifo_open:entry Ugen: ugen0.1 f_open: = ffffffff8093fd00 0 12102 ugen_open:return Return: 0 Errno: 0 0 12031 usb_fifo_open:return Return: 0 Errno: 0 3 65418 openat:entry Open: /dev/ugen0.2 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff8093fd00 3 12102 ugen_open:return Return: 0 Errno: 0 3 12031 usb_fifo_open:return Return: 0 Errno: 0 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff8093fd00 3 12102 ugen_open:return Return: 0 Errno: 0 3 12031 usb_fifo_open:return Return: 0 Errno: 0 3 65418 openat:entry Open: /dev/ugen0.3 3 12030 usb_fifo_open:entry Ugen: ugen0.3 f_open: = ffffffff8093fd00 3 12102 ugen_open:return Return: 0 Errno: 0 3 12031 usb_fifo_open:return Return: 0 Errno: 0 3 12030 usb_fifo_open:entry Ugen: ugen0.3 f_open: = ffffffff8093fd00 3 12102 ugen_open:return Return: 0 Errno: 0 3 12031 usb_fifo_open:return Return: 0 Errno: 0 1 65418 openat:entry Open: /dev/ugen0.4 1 12030 usb_fifo_open:entry Ugen: ugen0.4 f_open: = ffffffff8093fd00 1 12102 ugen_open:return Return: 0 Errno: 0 1 12031 usb_fifo_open:return Return: 0 Errno: 0 1 12030 usb_fifo_open:entry Ugen: ugen0.4 f_open: = ffffffff8093fd00 1 12102 ugen_open:return Return: 0 Errno: 0 1 12031 usb_fifo_open:return Return: 0 Errno: 0 1 65418 openat:entry Open: /dev/ugen0.5 Dtrace script is.. fbt:kernel:usb_fifo_open:entry { printf("Ugen: %s f_open: %p", ((struct usb_fifo = *)arg1)->udev->ugen_name, ((struct usb_fifo *)arg1)->methods->f_open); } fbt:kernel:usb_fifo_open:return { printf("Return: %d Errno: %d", arg1, errno); } fbt:kernel:ugen_open:return { printf("Return: %d Errno: %d", arg1, errno); } syscall:freebsd:openat:entry / pid =3D=3D $1 / { printf("Open: %s", copyinstr(arg1)); } -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Mar 11 06:36:25 2019 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 C4E021532507 for ; Mon, 11 Mar 2019 06:36:25 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id E05BB84D3E for ; Mon, 11 Mar 2019 06:36:22 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Mar 2019 17:01:11 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2B6Uh1R071231 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Mar 2019 17:01:06 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2B6RDVd067480 for ; Mon, 11 Mar 2019 16:57:13 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2B6RD8O067476; Mon, 11 Mar 2019 16:57:13 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> Date: Mon, 11 Mar 2019 16:57:12 +1030 Cc: Konstantin Belousov , Warner Losh , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: E05BB84D3E X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.39 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: midget.dons.net.au]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[129.137.101.150.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.91)[0.908,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.09)[ip: (4.20), ipnet: 150.101.0.0/16(0.97), asn: 4739(0.33), country: AU(-0.04)]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; NEURAL_SPAM_MEDIUM(1.00)[0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 06:36:26 -0000 > On 11 Mar 2019, at 15:00, O'Connor, Daniel wrote: >=20 >=20 >=20 >> On 11 Mar 2019, at 14:27, O'Connor, Daniel = wrote: >> I can dig into the kernel part if you want but will need some = guidance where to look.. >=20 > Note that I put a dtrace probe on ugen_open and usb_fifo_open and it = does not fire for 0.5, eg.. > [maarsytest 4:28] ~> sudo dtrace -s ~/usb_fifo.d 2324 > Password: > dtrace: script '/home/radar/usb_fifo.d' matched 4 probes > CPU ID FUNCTION:NAME > 2 65418 openat:entry Open: = /home/radar/ud3/run/experiment.stemp > 0 65418 openat:entry Open: = /local0/Measurements/Phasetest/20190311-0428.noise > 2 65418 openat:entry Open: = /home/radar/ud3/lib/acquisition//integrate.plugin > 3 65418 openat:entry Open: /dev/ugsio0.ud > 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff822946a0 > 3 12031 usb_fifo_open:return Return: 0 Errno: 9 > 3 65418 openat:entry Open: /dev/ussio0.ud > 0 65418 openat:entry Open: /dev/usbctl > 0 65418 openat:entry Open: /dev/ugen0.1 > 0 12030 usb_fifo_open:entry Ugen: ugen0.1 f_open: = ffffffff8093fd00 > 0 12102 ugen_open:return Return: 0 Errno: 0 > 0 12031 usb_fifo_open:return Return: 0 Errno: 0 > 0 12030 usb_fifo_open:entry Ugen: ugen0.1 f_open: = ffffffff8093fd00 > 0 12102 ugen_open:return Return: 0 Errno: 0 > 0 12031 usb_fifo_open:return Return: 0 Errno: 0 > 3 65418 openat:entry Open: /dev/ugen0.2 > 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff8093fd00 > 3 12102 ugen_open:return Return: 0 Errno: 0 > 3 12031 usb_fifo_open:return Return: 0 Errno: 0 > 3 12030 usb_fifo_open:entry Ugen: ugen0.2 f_open: = ffffffff8093fd00 > 3 12102 ugen_open:return Return: 0 Errno: 0 > 3 12031 usb_fifo_open:return Return: 0 Errno: 0 > 3 65418 openat:entry Open: /dev/ugen0.3 > 3 12030 usb_fifo_open:entry Ugen: ugen0.3 f_open: = ffffffff8093fd00 > 3 12102 ugen_open:return Return: 0 Errno: 0 > 3 12031 usb_fifo_open:return Return: 0 Errno: 0 > 3 12030 usb_fifo_open:entry Ugen: ugen0.3 f_open: = ffffffff8093fd00 > 3 12102 ugen_open:return Return: 0 Errno: 0 > 3 12031 usb_fifo_open:return Return: 0 Errno: 0 > 1 65418 openat:entry Open: /dev/ugen0.4 > 1 12030 usb_fifo_open:entry Ugen: ugen0.4 f_open: = ffffffff8093fd00 > 1 12102 ugen_open:return Return: 0 Errno: 0 > 1 12031 usb_fifo_open:return Return: 0 Errno: 0 > 1 12030 usb_fifo_open:entry Ugen: ugen0.4 f_open: = ffffffff8093fd00 > 1 12102 ugen_open:return Return: 0 Errno: 0 > 1 12031 usb_fifo_open:return Return: 0 Errno: 0 > 1 65418 openat:entry Open: /dev/ugen0.5 I just realised I can check procstat for open file, derp. [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc 64 640 4928 So I guess that is why it is giving ENOMEM, I'm leaking FDs! -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Mar 11 08:28:31 2019 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 6F33415371F3 for ; Mon, 11 Mar 2019 08:28:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 186CD89EE0 for ; Mon, 11 Mar 2019 08:28:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 98B1C26011B; Mon, 11 Mar 2019 09:28:20 +0100 (CET) Subject: Re: USB stack getting confused To: "O'Connor, Daniel" Cc: Konstantin Belousov , FreeBSD Hackers References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> From: Hans Petter Selasky Message-ID: <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> Date: Mon, 11 Mar 2019 09:27:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 186CD89EE0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-6.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.turbocat.net]; NEURAL_HAM_SHORT(-0.94)[-0.942,0]; IP_SCORE(-3.28)[ip: (-9.49), ipnet: 88.99.0.0/16(-4.67), asn: 24940(-2.21), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 08:28:31 -0000 On 3/11/19 7:27 AM, O'Connor, Daniel wrote: > I just realised I can check procstat for open file, derp. > > [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc > 64 640 4928 > > So I guess that is why it is giving ENOMEM, I'm leaking FDs! That looks like a bug in your application?? Which USB API are you using? --HPS From owner-freebsd-hackers@freebsd.org Mon Mar 11 08:35:24 2019 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 96A9B15375A1 for ; Mon, 11 Mar 2019 08:35:24 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE608A60A for ; Mon, 11 Mar 2019 08:35:23 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qk1-x734.google.com with SMTP id n6so2198349qkf.1 for ; Mon, 11 Mar 2019 01:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m+q2GQObguL+4V8sNF9RM4VFdlQStOagmq6ejfw/Wr4=; b=OjDNekRdXDXT/wpHYnZyj8a/hKPR5qch2In9TTHFDKKJtIu6d6xXMPmGyxQlYM81mF WXE2iUn+CsN2lXUdx2vCUy5inxqyaxWSleiXmt1cCb1WiPjpU2dsA09xLO5pAxZB/yzN JxDRibvS+r3fz41VywSF1rK0ujZmxXbuIimiLn/vi7wUJZKdqQbDIprfNxMpYauE6qlh a8c10CA0DDaY6okZ6amaVmak6y0MY01ni1m82r4r/axADNgvavJreqTNMH4OZPCvk9Ac oTwFCTVzP0bVL+8SmdP2qku+MhIkv+OB5kS8mCRWeedg1l9oMVboR8+Z3Hst35JJxjMA QA6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m+q2GQObguL+4V8sNF9RM4VFdlQStOagmq6ejfw/Wr4=; b=M34y/FagyTfxwuCyJgLM+TNxF9kD39Xmf78xmthP68IA0p34a9P3tERrUQlK5z19Qy JQAXd3X2LqH1a1LhnvwFAHby25buknE5KLrB8cpgL2be+0aCOcoMcwpDY2BVhu1Go2tH dpZyaD7NEq2DW6ByTo4PCeIGe6q+L7UTphw3yjSxNx/xI4DWu6hxxVU/Ov3/Dt2bKzJd +D5welUEFkFeVULtGjCQkEvoTBvrFWTUlLUz23l/tFPW7xafJ2diyQxRR02z5kHOkOlu E32L6r4gIBQ/LKW6T4JN813jYmyZvUgIVPd5WgbLmVgj5jLjdFPkHqFbY9TWTkYoNVTn 40Cw== X-Gm-Message-State: APjAAAXf/9m+ToNlA+3LH5HcIIZ7OqjKxQ/ze14OqOU3Aalz+4iejXs6 ejrQqIJ1P0SbYBrQQ0rJT3VlRT5Vc3x3mAkD8S0M/A== X-Google-Smtp-Source: APXvYqwFJ2utru3PKH+z0Sn7GS0FiYgWuWfiFnzAmZVvet7lHa88iAwbhk9taPaXcE0ftefKCG5HNDTtxYQmHg2b+ow= X-Received: by 2002:a37:b105:: with SMTP id a5mr23047025qkf.298.1552293322323; Mon, 11 Mar 2019 01:35:22 -0700 (PDT) MIME-Version: 1.0 References: <79CC79B9-81AF-4563-BABE-429E6A57F476@bmalum.com> <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazonses.com> <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazo> <1548182399.2864.0@smtp.migadu.com> <1552255580.21373.0@unrelenting.technology> In-Reply-To: <1552255580.21373.0@unrelenting.technology> From: Marcin Wojtas Date: Mon, 11 Mar 2019 09:35:11 +0100 Message-ID: Subject: Re: ARM Graviton AWS Processor (AMI Image) To: Greg V Cc: Martin Karrer , "Matushevsky, Alexander" , =?UTF-8?Q?Micha=C5=82_Krawczyk?= , =?UTF-8?B?UmFmYcWCIEtvemlr?= , freebsd-arm@freebsd.org, freebsd-cloud@freebsd.org, freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 1BE608A60A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=OjDNekRd X-Spamd-Result: default: False [-5.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[ASPMX2.GOOGLEMAIL.com,ALT2.ASPMX.L.GOOGLE.com,ASPMX.L.GOOGLE.com,ALT1.ASPMX.L.GOOGLE.com,ASPMX3.GOOGLEMAIL.com]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_IN_DNSWL_NONE(0.00)[4.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.93)[-0.935,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.74)[ip: (-8.80), ipnet: 2607:f8b0::/32(-2.74), asn: 15169(-2.07), country: US(-0.07)] X-Mailman-Approved-At: Mon, 11 Mar 2019 10:32:22 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 08:35:24 -0000 +FreeBSD ENA maintainers W dniu pon., 11.03.2019 o 00:40 Greg V napisa=C5=82(a): > > On Tue, Jan 22, 2019 at 9:39 PM, Greg V > wrote: > > On Mon, Jan 21, 2019 at 1:11 PM, Martin Karrer > > wrote: > >> My question is if there are any plans yet to support the Graviton > >> ARM instances of AWS? > >> > >> We have a heavy load on FreeBSD and would also use the ARM > >> instances. Are there any other interested parties? > > > > I have tried this. It should work very well in theory, e.g. the > > network card driver (if_ena) compiles with no changes for aarch64, > > and in fact NetBSD has ported this driver and is up and running on > > these instances: https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D462= 3 > > > > But my result with FreeBSD was: nothing on the console after > > loader.efi hands control to the kernel. > > [=E2=80=A6] > > Hello everyone, big update: > > FreeBSD/aarch64 on Amazon EC2 a1 (AWS Graviton) instances WORKS! > > https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D4813 > > And you can try it (well, my -CURRENT build, NO WARRANTY etc) right now: > > ami-0c2829a0b82a62ca6 in eu-west-1 (Ireland) > > ----- > > So, what I had to do / what should be done / how others can help get > this into a finished state: > > 1. Serial console: > - I fixed it: https://reviews.freebsd.org/D19507 > - (I learned some things about UARTs and their support in FreeBSD, > should write a blog post about that) > > 2. aarch64 build configuration: > - if_ena network driver module should be enabled: > https://reviews.freebsd.org/D18372 > - NVMe driver should be enabled in the GENERIC kernel config (device > nvme, device nvd) > - BTW, why not also go with hw.nvme.use_nvd=3D"0" by default on > aarch64, IIRC that was done on powerpc64 > > 3. VM image build system: > - GPT+EFI should be used (amd64 was GPT with no EFI, and aarch64 was > MBR with EFI (???)): https://reviews.freebsd.org/D18371 > - bsdec2-image-upload --arm64 flag should be supported: included > above ^^ > - ec2.conf: amazon-ssm-agent shouldn't be installed when building > for aarch64 TARGET, since that's written in Go, and Go isn't ported to > FreeBSD/aarch64 yet: > > https://github.com/myfreeweb/freebsd/commit/5b530ebf7385d8320b9076cf84f50= aad01689bc > (untested patch, I actually used an interactive shell in between the > image build commands) > - qemu-aarch64-static should be used for preinstalling pkgs when > chrooting into the image: rough version included above ^^ > > 4. ENA (Elastic Network Adapter) driver: > - it works > - except there's something funky with interrupt activation, and it > hits panic("Attempt to double activation of resource id: %u\n", res_id) > (for the management IRQ) on boot, so I applied the obvious silly > workaround of "don't panic": > > https://github.com/myfreeweb/freebsd/commit/a7e7c6e48cdbdb0fdc6c4e0ba6339= 2262938e62c > - but still, it doesn't properly reactivate interrupts (and the box > becomes unreachable over the net) after going down and up again =E2=80=94 > guess what does that on boot? dhclient applying the big jumbo MTU =E2=80= =94 > so I set dhclient.conf to reject MTU changes: > > https://github.com/myfreeweb/freebsd/commit/03ec4d417b0b4252285baaf4e294c= c6d8c870f7f > > > Would be great if someone familiar with interrupts and stuff could help > debug the ena driver and make it work without these hacks :) > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Mar 11 04:01:08 2019 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 B392C152D46E for ; Mon, 11 Mar 2019 04:01:08 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [150.101.137.133]) by mx1.freebsd.org (Postfix) with ESMTP id F355D77B9B for ; Mon, 11 Mar 2019 04:01:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail01.adl2.internode.on.net with ESMTP; 11 Mar 2019 14:30:50 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2B40hmB064344 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Mar 2019 14:30:43 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2B3vUaI060685 for ; Mon, 11 Mar 2019 14:27:30 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2B3vTJn060679; Mon, 11 Mar 2019 14:27:30 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> Date: Mon, 11 Mar 2019 14:27:29 +1030 Cc: Konstantin Belousov , Warner Losh , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: F355D77B9B X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.18 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[midget.dons.net.au]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[133.137.101.150.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.76)[0.757,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.26)[ipnet: 150.101.0.0/16(1.01), asn: 4739(0.33), country: AU(-0.04)]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; NEURAL_SPAM_MEDIUM(0.93)[0.932,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.85)[0.846,0]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 04:01:09 -0000 > On 10 Mar 2019, at 23:40, Hans Petter Selasky wrote: > On 3/10/19 11:26 AM, Konstantin Belousov wrote: >> On Sun, Mar 10, 2019 at 11:18:36AM +0100, Hans Petter Selasky wrote: >>> On 3/10/19 10:47 AM, Konstantin Belousov wrote: >>>>> Yes, I can do that if destroy_dev() ensures that d_close is called = for >>>>> all open file handles once and only once before it returns. I = think this >>>>> is where the problem comes from. >>>> See above. For d_close it is impossible, for cdevpriv dtr it is = already >>>> there by design. >>>>=20 >>>=20 >>> Yes, cdevpriv_dtr will wait for the final close() from user-space >>> unfortunately. Or am I mistaken? >> You are mistaken. Cdevpriv destructors are called either on the file = close >> (not the last close in d_close sense, just file close) OR during = destroy_dev(). >> Each destructor/file pair is called exactly once, regardless of the = cause. >=20 > Can you try the attached patch? I tried it but it didn't help the problem. I put a break point at ugen20_enumerate at libusb20_ugen20.c:149 I can = see it try and open /dev/ugenX.Y but 0.5 (my device) fails with errno = set to 12 (ENOMEM). I can dig into the kernel part if you want but will need some guidance = where to look.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Mar 11 09:52:02 2019 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 91B4B153A676 for ; Mon, 11 Mar 2019 09:52:02 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E6508DDCB for ; Mon, 11 Mar 2019 09:52:02 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DDD2613337 for ; Mon, 11 Mar 2019 09:52:01 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.212.184.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id BB60215BF9 for ; Mon, 11 Mar 2019 09:52:00 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk/BB60215BF9; dkim=none; dkim-atps=neutral From: Matthew Seaman Subject: Re: Upgrading discontinued ports To: freebsd-hackers@freebsd.org References: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> Message-ID: <418648ad-5f10-1cfb-1f2a-1809a7a5e959@FreeBSD.org> Date: Mon, 11 Mar 2019 09:52:00 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2E6508DDCB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 09:52:02 -0000 On 11/03/2019 06:48, Dirk Engling wrote: > On 11.03.19 04:56, Robert Ayrapetyan wrote: > >> Are you sure you've used a "force" flag, e.g. "pkg-static upgrade >> -f"? > Yes. But all that does is force reinstall installed packages. However > the old package just isn't in the pkg repo anymore, so there's nothing > to re-install. pkg(8) does know about successor packages for many of these cases, but only for what is mentioned in MOVED. Unfortunately, in the specific case of upgrading from php56 to php72, pkg(8) has no idea of the equivalence between php56-foo and php72-foo packages. All it knows is that php56-foo and php72-foo conflict on installation, so when you install an updated php application compiled to depend on php72 modules it will install the php72 dependencies for that application, replacing the php56 equivalents. If you've still got php56 modules left over, then one of two things has happened. Either you've installed a php56 module directly, because (for instance) it was needed by some not-packaged PHP application you're running, or else you've still got an old version of some PHP app package installed that still depends on those php56 modules. It's usually fairly easy to sort either of those two situations out, but it does require manual intervention. The best approach here is to run: pkg version -vRL= whenever you're doing an upgrade with a significant change to something with a big module library (PHP, perl, python, etc). This should highlight anything you have installed with no corresponding package in the repo, so that you can take appropriate action. Cheers, Matthew From owner-freebsd-hackers@freebsd.org Sun Mar 10 22:06:36 2019 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 5E96C1543AA6 for ; Sun, 10 Mar 2019 22:06:36 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B24A69BA3 for ; Sun, 10 Mar 2019 22:06:33 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 10 Mar 2019 22:06:24 +0000 Received: from [192.168.1.141] ([62.122.208.146]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 226BFB91-4C7C-49EE-8C50-5BD0BC0F0D4F.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 10 Mar 2019 22:06:24 +0000 Date: Mon, 11 Mar 2019 01:06:20 +0300 From: Greg V Subject: Re: ARM Graviton AWS Processor (AMI Image) To: Martin Karrer Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-cloud@freebsd.org Message-Id: <1552255580.21373.0@unrelenting.technology> In-Reply-To: <1548182399.2864.0@smtp.migadu.com> References: <79CC79B9-81AF-4563-BABE-429E6A57F476@bmalum.com> <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazonses.com> <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazo> X-Mailer: geary/master~gfcf07ad4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; bh=yFeukkt+RUN+oEqF1Ne+PZL5JrtX8FnxvXapLRyw2ig=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=bO0c5gqCPwVq1Ip/7e9PLoCHqgYYn+WFSTytDddDRgn8sznjfCFWXKFXpa9DhrllgGrw463zaQfRMiT/1OlO7SQzvzRa2NHj6dm1G77lvRPWfWrgsf8hSF5S6rGRDWLq9jlwNuVmlxOttP38e/z9gyPeZOt4iqwvejLF6Rlf8FU= X-Rspamd-Queue-Id: 3B24A69BA3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=bO0c5gqC; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-6.63 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; MX_GOOD(-0.01)[aspmx1.migadu.com,aspmx2.migadu.com]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.63)[ip: (-9.89), ipnet: 91.121.0.0/16(-4.08), asn: 16276(0.84), country: FR(-0.01)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Mon, 11 Mar 2019 10:31:51 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 22:06:36 -0000 On Tue, Jan 22, 2019 at 9:39 PM, Greg V =20 wrote: > On Mon, Jan 21, 2019 at 1:11 PM, Martin Karrer =20 > wrote: >> My question is if there are any plans yet to support the Graviton=20 >> ARM =7Finstances of AWS? >>=20 >> We have a heavy load on FreeBSD and would also use the ARM=20 >> instances. =7FAre there any other interested parties? >=20 > I have tried this. It should work very well in theory, e.g. the=20 > network card driver (if_ena) compiles with no changes for aarch64,=20 > and in fact NetBSD has ported this driver and is up and running on=20 > these instances: https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D4623 >=20 > But my result with FreeBSD was: nothing on the console after=20 > loader.efi hands control to the kernel. > [=E2=80=A6] Hello everyone, big update: FreeBSD/aarch64 on Amazon EC2 a1 (AWS Graviton) instances WORKS! https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D4813 And you can try it (well, my -CURRENT build, NO WARRANTY etc) right now: ami-0c2829a0b82a62ca6 in eu-west-1 (Ireland) ----- So, what I had to do / what should be done / how others can help get=20 this into a finished state: 1. Serial console: - I fixed it: https://reviews.freebsd.org/D19507 - (I learned some things about UARTs and their support in FreeBSD,=20 should write a blog post about that) 2. aarch64 build configuration: - if_ena network driver module should be enabled:=20 https://reviews.freebsd.org/D18372 - NVMe driver should be enabled in the GENERIC kernel config (device=20 nvme, device nvd) - BTW, why not also go with hw.nvme.use_nvd=3D"0" by default on=20 aarch64, IIRC that was done on powerpc64 3. VM image build system: - GPT+EFI should be used (amd64 was GPT with no EFI, and aarch64 was=20 MBR with EFI (???)): https://reviews.freebsd.org/D18371 - bsdec2-image-upload --arm64 flag should be supported: included=20 above ^^ - ec2.conf: amazon-ssm-agent shouldn't be installed when building=20 for aarch64 TARGET, since that's written in Go, and Go isn't ported to=20 FreeBSD/aarch64 yet:=20 https://github.com/myfreeweb/freebsd/commit/5b530ebf7385d8320b9076cf84f50aa= d01689bc=20 (untested patch, I actually used an interactive shell in between the=20 image build commands) - qemu-aarch64-static should be used for preinstalling pkgs when=20 chrooting into the image: rough version included above ^^ 4. ENA (Elastic Network Adapter) driver: - it works - except there's something funky with interrupt activation, and it=20 hits panic("Attempt to double activation of resource id: %u\n", res_id)=20 (for the management IRQ) on boot, so I applied the obvious silly=20 workaround of "don't panic":=20 https://github.com/myfreeweb/freebsd/commit/a7e7c6e48cdbdb0fdc6c4e0ba633922= 62938e62c - but still, it doesn't properly reactivate interrupts (and the box=20 becomes unreachable over the net) after going down and up again =E2=80=94=20 guess what does that on boot? dhclient applying the big jumbo MTU =E2=80=94= =20 so I set dhclient.conf to reject MTU changes:=20 https://github.com/myfreeweb/freebsd/commit/03ec4d417b0b4252285baaf4e294cc6= d8c870f7f Would be great if someone familiar with interrupts and stuff could help=20 debug the ena driver and make it work without these hacks :) = From owner-freebsd-hackers@freebsd.org Mon Mar 11 10:58:11 2019 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 3B152153D253 for ; Mon, 11 Mar 2019 10:58:11 +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 76F1690D08 for ; Mon, 11 Mar 2019 10:58:10 +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 x2BAvmrE025976 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Mar 2019 12:57:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2BAvmrE025976 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2BAvltO025974; Mon, 11 Mar 2019 12:57:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Mar 2019 12:57:47 +0200 From: Konstantin Belousov To: Hans Petter Selasky Cc: "O'Connor, Daniel" , FreeBSD Hackers Subject: Re: USB stack getting confused Message-ID: <20190311105747.GT2492@kib.kiev.ua> References: <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 10:58:11 -0000 On Mon, Mar 11, 2019 at 09:27:56AM +0100, Hans Petter Selasky wrote: > On 3/11/19 7:27 AM, O'Connor, Daniel wrote: > > I just realised I can check procstat for open file, derp. > > > > [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc > > 64 640 4928 > > > > So I guess that is why it is giving ENOMEM, I'm leaking FDs! If I am interpreting the output right, it is only 634 (or close) file descriptors opened. Too many fds errors are ENFILE when too many file descriptors in the system already exist, limited by kern.maxfiles, and EMFILE when per-process lmit is exceeded (resource RLIMIT_NOFILE). So your ENOMEM must come from something else. > > That looks like a bug in your application?? > > Which USB API are you using? > > --HPS From owner-freebsd-hackers@freebsd.org Mon Mar 11 13:01:25 2019 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 7796C1542054 for ; Mon, 11 Mar 2019 13:01:25 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [150.101.137.136]) by mx1.freebsd.org (Postfix) with ESMTP id 869FD94F6B for ; Mon, 11 Mar 2019 13:01:23 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Mar 2019 23:31:21 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2BD0hfB049363 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Mar 2019 23:31:17 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2BCXmcM027928 for ; Mon, 11 Mar 2019 23:03:48 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2BCXm6A027925; Mon, 11 Mar 2019 23:03:48 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <20190311105747.GT2492@kib.kiev.ua> Date: Mon, 11 Mar 2019 23:03:47 +1030 Cc: Hans Petter Selasky , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <89BDC841-5549-4F52-9204-8B08171B08AF@dons.net.au> References: <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> <20190311105747.GT2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 869FD94F6B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:01:25 -0000 > On 11 Mar 2019, at 21:27, Konstantin Belousov = wrote: >=20 > On Mon, Mar 11, 2019 at 09:27:56AM +0100, Hans Petter Selasky wrote: >> On 3/11/19 7:27 AM, O'Connor, Daniel wrote: >>> I just realised I can check procstat for open file, derp. >>>=20 >>> [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc >>> 64 640 4928 >>>=20 >>> So I guess that is why it is giving ENOMEM, I'm leaking FDs! > If I am interpreting the output right, it is only 634 (or close) file > descriptors opened. It's 64 descriptors for that particular USB device (/dev/usb/0.5.0) - I = am guessing there is some hard limit in the USB stack related to that. The system definitely isn't out of FDs generally -> [maarsytest 12:33] ~> sysctl kern.openfiles kern.maxfiles kern.openfiles: 386 kern.maxfiles: 521571 > Too many fds errors are ENFILE when too many file descriptors in the = system > already exist, limited by kern.maxfiles, and EMFILE when per-process > lmit is exceeded (resource RLIMIT_NOFILE). >=20 > So your ENOMEM must come from something else. Yes, I think it must be a limit in the USB stack. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Mar 11 07:14:54 2019 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 114C31534368 for ; Mon, 11 Mar 2019 07:14:54 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2FD386C80 for ; Mon, 11 Mar 2019 07:14:52 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-ot1-x333.google.com with SMTP id n71so3023123ota.10 for ; Mon, 11 Mar 2019 00:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iV/dlK1UGl2O5Hl+eq6Pr8C6V5UFdN2HJ9DM+e9xXI4=; b=kVaXYD2ywvzxgdxew2WFwZ/0E1v8Yish8Y06idJ/sdNqDbBEFJtvCj3CffUB+vQikl UAZ217Mr2pjCVJjVPZEMF/J7rxynpyCpuBsmYm58HO5eVgtUalVd5VIWzY3kTUkcJQQB J9SFk3xb2tsJt5GHOaG7BDfVZl0ccaKiCwgiEHwDGXdg8nN1cV/LzA03RyB/+63t2J2U iIXUzUt19l42jFCASxAmmc/FhEv18xaiUYW9NzjilnC/hmQSXNrmJLNM8G8HzPrenO5d dL9Tk5sliuCgmf0GbZ/iNwS9N29AwzheTNZiflw/ORCy2Y0XFLEltByeDdmPeAohXjYa aheA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iV/dlK1UGl2O5Hl+eq6Pr8C6V5UFdN2HJ9DM+e9xXI4=; b=tj/rG2rokgHtOZwAVoJzGyhrb+t8dBVlAy6W/TvjylHr80qXF5346gnY6kyEecvCAK EQP/S+GlFgEupdjvcJjFrEU/bL3+yedFc72J9MFk850Z/Zoqr/J0XTQQ9NB7midlWHNW fAzMcfQ1jsp9Y20A5qS9pZCWtVWSTpdd0aOy4uOWoP3wGcPaOiXQqJEEiRh5pygpxAZ5 Yn2F55ZuCDoXQuDH3llacRNadZ/zmCxIe2mzrTdbBQrvypQLtpsciIbH+RxwvWduiB8r v4lsPr9hbM1O5/66gD+PT3rESXTEpg7YtkT1wYXAWf5oJSuOwW7SR+bBA/ofUsipmrOg /7pA== X-Gm-Message-State: APjAAAU3BIhuZTGUfAnYD1LBw8hCX6UmjKYv4pLoAEuNnBkmBwmtv/fh cjOCtZAO1aA4CHvF2iLrrzlaUovJraQujATp0Aho X-Google-Smtp-Source: APXvYqxNuslPRgpBiV6Bja7LAs1J1n6YOFDIRt0O5iet1OFFCsyQQye8pY/MtTe/UhMPwtEE8SKRfBjN/HwFWfUCHAM= X-Received: by 2002:a05:6830:1c1:: with SMTP id r1mr19420771ota.229.1552288491562; Mon, 11 Mar 2019 00:14:51 -0700 (PDT) MIME-Version: 1.0 References: <3445abe8-11a9-5810-b244-87c0d2751dd0@erdgeist.org> <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> In-Reply-To: <03fcd350-56b3-9724-1fdc-491a5228e2ac@erdgeist.org> From: Robert Ayrapetyan Date: Mon, 11 Mar 2019 00:14:15 -0700 Message-ID: Subject: Re: Upgrading discontinued ports To: Dirk Engling Cc: "" X-Rspamd-Queue-Id: B2FD386C80 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=kVaXYD2y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robertayrapetyan@gmail.com designates 2607:f8b0:4864:20::333 as permitted sender) smtp.mailfrom=robertayrapetyan@gmail.com X-Spamd-Result: default: False [-6.62 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.89)[-0.891,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.72)[ip: (-8.72), ipnet: 2607:f8b0::/32(-2.74), asn: 15169(-2.07), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 07:14:54 -0000 Could you specify some php56 package which was in 10.4 and not in 11.2? On Sun, Mar 10, 2019 at 11:48 PM Dirk Engling wrote: > On 11.03.19 04:56, Robert Ayrapetyan wrote: > > > Are you sure you've used a "force" flag, e.g. "pkg-static upgrade > > -f"? > Yes. But all that does is force reinstall installed packages. However > the old package just isn't in the pkg repo anymore, so there's nothing > to re-install. > > erdgeist > From owner-freebsd-hackers@freebsd.org Mon Mar 11 13:06:10 2019 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 B4D0115425A4 for ; Mon, 11 Mar 2019 13:06:10 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [150.101.137.136]) by mx1.freebsd.org (Postfix) with ESMTP id 3754E953EC for ; Mon, 11 Mar 2019 13:06:07 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Mar 2019 23:30:57 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2BD0hf1049363 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Mar 2019 23:30:44 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2BCaAWi031306 for ; Mon, 11 Mar 2019 23:06:10 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2BCa6r8031301; Mon, 11 Mar 2019 23:06:10 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> Date: Mon, 11 Mar 2019 23:06:06 +1030 Cc: Konstantin Belousov , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 3754E953EC X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.23 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: midget.dons.net.au]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; RCVD_IN_DNSWL_LOW(-0.10)[136.137.101.150.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.82)[0.821,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.25)[ipnet: 150.101.0.0/16(0.95), asn: 4739(0.32), country: AU(-0.04)]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; NEURAL_SPAM_MEDIUM(0.93)[0.931,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.85)[0.845,0]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:06:11 -0000 > On 11 Mar 2019, at 18:57, Hans Petter Selasky wrote: >=20 > On 3/11/19 7:27 AM, O'Connor, Daniel wrote: >> I just realised I can check procstat for open file, derp. >> [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc >> 64 640 4928 >> So I guess that is why it is giving ENOMEM, I'm leaking FDs! >=20 > That looks like a bug in your application?? Yes, I think it is. I thought it was something else because usbconfig didn't see the device. > Which USB API are you using? The libusb10 interface - I didn't write the code (the vendor supplied a = Linux version that was trivially compilable on FreeBSD). I have the source code and I can see what the issue is so I'll fix that, = although I am surprised the limit for USB devices is so much lower than = the system limit for file descriptors generally. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Mar 11 13:42:10 2019 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 A3D7315438E5 for ; Mon, 11 Mar 2019 13:42:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 BB19096822 for ; Mon, 11 Mar 2019 13:42:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 44E8E260297; Mon, 11 Mar 2019 14:42:07 +0100 (CET) Subject: Re: USB stack getting confused To: "O'Connor, Daniel" Cc: Konstantin Belousov , FreeBSD Hackers References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> From: Hans Petter Selasky Message-ID: <991d10df-b42d-b557-1b47-37db5bfb4d42@selasky.org> Date: Mon, 11 Mar 2019 14:41:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BB19096822 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-6.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; IP_SCORE(-3.26)[ip: (-9.48), ipnet: 88.99.0.0/16(-4.67), asn: 24940(-2.13), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 13:42:11 -0000 On 3/11/19 1:36 PM, O'Connor, Daniel wrote: > > >> On 11 Mar 2019, at 18:57, Hans Petter Selasky wrote: >> >> On 3/11/19 7:27 AM, O'Connor, Daniel wrote: >>> I just realised I can check procstat for open file, derp. >>> [maarsytest 6:26] ~> procstat -f 2324|grep 0.5.0| wc >>> 64 640 4928 >>> So I guess that is why it is giving ENOMEM, I'm leaking FDs! >> >> That looks like a bug in your application?? > > Yes, I think it is. > I thought it was something else because usbconfig didn't see the device. > >> Which USB API are you using? > > The libusb10 interface - I didn't write the code (the vendor supplied a Linux version that was trivially compilable on FreeBSD). > > I have the source code and I can see what the issue is so I'll fix that, although I am surprised the limit for USB devices is so much lower than the system limit for file descriptors generally. > Hi, USB has a limit on open FD's per USB device, (USB_FIFO_MAX = 128) / 2 = 64. --HPS From owner-freebsd-hackers@freebsd.org Mon Mar 11 21:29:01 2019 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 AAE4F152F53D for ; Mon, 11 Mar 2019 21:29:01 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) 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 2B75884AB8 for ; Mon, 11 Mar 2019 21:29:01 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id DD9CD152F53C; Mon, 11 Mar 2019 21:29:00 +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 CB3AE152F53B for ; Mon, 11 Mar 2019 21:29:00 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B38D684AB7 for ; Mon, 11 Mar 2019 21:28:59 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2BLSuGI011759 for ; Mon, 11 Mar 2019 14:28:56 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2BLSuHB011758 for hackers@freebsd.org; Mon, 11 Mar 2019 14:28:56 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201903112128.x2BLSuHB011758@gndrsh.dnsmgr.net> Subject: Anyone else attending Netdevops or ietf/104 in Prauge March 20 to 29 To: hackers@freebsd.org Date: Mon, 11 Mar 2019 14:28:56 -0700 (PDT) Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: B38D684AB7 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.19 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[rgrimes@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.496,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.85)[0.853,0]; DMARC_NA(0.00)[dnsmgr.net]; NEURAL_SPAM_MEDIUM(0.95)[0.947,0]; R_SPF_NA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (0.05), ipnet: 69.59.192.0/19(0.03), asn: 13868(0.01), country: US(-0.07)] X-Mailman-Approved-At: Mon, 11 Mar 2019 21:41:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:29:01 -0000 Hello, I have been invited to attend both Netdevops and ietf/104 in Prauge from March 20th to March 29th. I should be arriving a few days early on the 17th, and leaving a few days late on the 31st. Anyone else going to be there? Thanks, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Mar 12 03:58:39 2019 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 DD0E1154233F for ; Tue, 12 Mar 2019 03:58:38 +0000 (UTC) (envelope-from Shbh96@hotmail.com) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065054.outbound.protection.outlook.com [40.92.65.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D23770BA9 for ; Tue, 12 Mar 2019 03:58:36 +0000 (UTC) (envelope-from Shbh96@hotmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y5uUCNVlZHDf1GVmnYutymOrZhiZDGftSQRc4uDGcWA=; b=CvTcyGAvAEkAT5lEJ6KZIEsJS1ZarfUMd1hqVk6QX7lhsSCmH16ZPhY/ZjSwGsWpZuX8TVRgpGyH6CAVFWyaaIgorpqh/B+DGHkhv2SZJiurGhPzglHfCeGp9cSbB3ohAXTS3Zi7rhvA8cGANmkqjPYGL5elXfdNVqH0GYcTKxbRq892EqF/FaAZ9AmxyE/2QHdumxHutw+FlD/hhZjd7g7y0G9EijWq7iyFUBkGXO4leSQawg1D/rRkjA/w2a+naRS8kmTYL3UQerWuk4ywZ8VpX7yLb13Kyozrz5r+cFTgf3M7OqisTu3pG9Q7iBY7j9Uh/LEwSPC6h1qc6UR5nQ== Received: from DB5EUR01FT054.eop-EUR01.prod.protection.outlook.com (10.152.4.53) by DB5EUR01HT160.eop-EUR01.prod.protection.outlook.com (10.152.5.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.19; Tue, 12 Mar 2019 03:58:34 +0000 Received: from AM6PR0102MB3653.eurprd01.prod.exchangelabs.com (10.152.4.55) by DB5EUR01FT054.mail.protection.outlook.com (10.152.5.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.19 via Frontend Transport; Tue, 12 Mar 2019 03:58:34 +0000 Received: from AM6PR0102MB3653.eurprd01.prod.exchangelabs.com ([fe80::5d99:79bd:426b:668c]) by AM6PR0102MB3653.eurprd01.prod.exchangelabs.com ([fe80::5d99:79bd:426b:668c%4]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 03:58:34 +0000 From: Humaid Bin Haroon To: "freebsd-hackers@freebsd.org" Subject: Easyfix Bugs Thread-Topic: Easyfix Bugs Thread-Index: AQHU2IdnpBMkHgmB80qC1TQ0t/GcPA== Date: Tue, 12 Mar 2019 03:58:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:DAF05EEC7A9A0615DC09E732962BDAFA55EF83A1FDDF0E5BE03B0A7176D6B9E6; UpperCasedChecksum:9C36A6B5811976CDBE5CA780C3A195ED72F284111513E8D2EBD837ADA3D7F090; SizeAsReceived:6583; Count:41 x-tmn: [kkqJ67LYGhAK+C6Iv1g7x3M3k/vL9UuD] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:DB5EUR01HT160; x-ms-traffictypediagnostic: DB5EUR01HT160: x-microsoft-antispam-message-info: MoUmZ2BIzuq1KrfYEgoF8TeHoOeQVeudgrOOPgGJ5YJoqlk9A9klyL+Ix9FsMYRV MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 245d0f83-86de-409b-ed7c-08d6a69effaf X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 03:58:34.2966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT160 X-Rspamd-Queue-Id: 7D23770BA9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hotmail.com header.s=selector1 header.b=CvTcyGAv; dmarc=pass (policy=none) header.from=hotmail.com; spf=pass (mx1.freebsd.org: domain of Shbh96@hotmail.com designates 40.92.65.54 as permitted sender) smtp.mailfrom=Shbh96@hotmail.com X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; FREEMAIL_FROM(0.00)[hotmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-0.92)[ipnet: 40.64.0.0/10(-2.34), asn: 8075(-2.21), country: US(-0.07)]; MX_GOOD(-0.01)[hotmail-com.olc.protection.outlook.com,hotmail-com.olc.protection.outlook.com]; DKIM_TRACE(0.00)[hotmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[54.65.92.40.list.dnswl.org : 127.0.3.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.71)[-0.708,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[hotmail.com]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[hotmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 03:58:39 -0000 Hello, Can anyone please suggest where can I find easyfix bugs or similar stuff fo= r beginners to getting started with contributing to the FreeBSD project. Thank you Syed Humaid From owner-freebsd-hackers@freebsd.org Tue Mar 12 11:11:24 2019 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 1CAC2152CEDB for ; Tue, 12 Mar 2019 11:11:24 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (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 DD7F789991 for ; Tue, 12 Mar 2019 11:11:22 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.bultmann.eu (unknown [IPv6:2a00:c380:c0d5:1:8dac:d802:614a:3721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id B6CFD99D0 for ; Tue, 12 Mar 2019 11:11:12 +0000 (UTC) Subject: Re: Easyfix Bugs To: freebsd-hackers@freebsd.org References: From: Jan Bramkamp Message-ID: Date: Tue, 12 Mar 2019 12:11:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DD7F789991 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-3.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_SPAM_SHORT(0.08)[0.079,0]; MX_GOOD(-0.01)[mail.rlwinm.de]; IP_SCORE(-0.82)[ipnet: 2a01:4f8::/29(-2.19), asn: 24940(-1.93), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 11:11:24 -0000 On 12.03.19 04:58, Humaid Bin Haroon wrote: > Hello, > > Can anyone please suggest where can I find easyfix bugs or similar stuff for beginners to getting started with contributing to the FreeBSD project. What is your background? There lots of things that a motivated newcomer could do e.g.: * Go through bug reports and reproduce them as few steps a possible * Port new software to FreeBSD * Improve unmaintained or outdatated ports. * Go through the FreeBSD wiki looking for low hanging fruits (e.g. https://wiki.freebsd.org/Networking?highlight=%28low%29%7C%28hanging%29%7C%28fruit%29) * ... -- Jan Bramkamp From owner-freebsd-hackers@freebsd.org Wed Mar 13 00:35:36 2019 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 25D1A1544F49 for ; Wed, 13 Mar 2019 00:35:36 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3FC78DF29 for ; Wed, 13 Mar 2019 00:35:34 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id h99so56809wrh.12 for ; Tue, 12 Mar 2019 17:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=aP1DXhDbAmA/VF6JxFBZIdaRDFmHvHWuu+/bYWNraLg=; b=p0npqsrCOrjXtCnr0o0/5g+XdRmPRLl3wu9l6/InThPMebwvfcVh6fzzJo9W8yVTuw BCtf3xKgsg7VJ8zkv31HbOMz8eVi2HnT68gF2MD40KDJ9uRKnv/IR775oQVIHw+N/eqj Sq6fWyJG4qfNyOU/1HFEYQqEvuR0KeDwirvDIu4lEs28lTIjzeylhVxOuGGhgQyhIukd j8StsWDpIA6iz34sUCDhXYas3qDg3cV6OVWA+F54Z0yYyfMgv2UuUS6aDkweNL+sXBub OxpVivDoCV9XG3NjbyxzzITkG39o9dkYNTlmKhgpxMH10gfsrP2JFykocW24rVlsq5xR nLQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=aP1DXhDbAmA/VF6JxFBZIdaRDFmHvHWuu+/bYWNraLg=; b=Hda7TiqURIguvUZnhdrXi1UCmTb6ojulZwTr63MBTo30V2TH7k76Bkkgju7loFIN6U +cYioAL7JJMFmRiFwYwgIO0EqGPpNFciQZ5Al/YtxjeFAYVKmo+RO96GX8PrluCIa5If Q51meSp4HqCye270qb2CKxXwLf6ejvuxXwKPSiI8w5SZx+zf/6fIAbpAWy4//5WGA/PY aLMCANeKf9zn756ftL0HYyrdpt8JGkIrJL4L1M12WE9wjG5jcu+beAr/5AdUh25pCPhA BNHzCaCyBQUb70NwFjouwlSFJ+tl2cRxgivh31DY2Z6w3uMDKnp+XlQPG+3udp+teFrt 3roQ== X-Gm-Message-State: APjAAAVmFEHCK0IXbmWlcxMCdgJpUsELfwhAc1yKbxHuY85lfIjQtDZr ylo3L+5Xy/vv6pmoB4cKYc94tqsE X-Google-Smtp-Source: APXvYqwCC5X976tnlTzLPLVjj6miD3l9cijhqmrFKG2JM1nBaCHv6Lfa7zRlpVlbKT8eoNFkWSCoGQ== X-Received: by 2002:adf:b601:: with SMTP id f1mr26877112wre.158.1552437333166; Tue, 12 Mar 2019 17:35:33 -0700 (PDT) Received: from alfdeb (host164-193-dynamic.19-79-r.retail.telecomitalia.it. [79.19.193.164]) by smtp.gmail.com with ESMTPSA id j13sm8570976wrx.74.2019.03.12.17.35.31 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 12 Mar 2019 17:35:32 -0700 (PDT) Date: Wed, 13 Mar 2019 01:35:30 +0100 From: Alfonso Siciliano To: freebsd-hackers@freebsd.org Subject: kern_sysctl.c interface Message-Id: <20190313013530.d96fc84c362bb489178357eb@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F3FC78DF29 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=p0npqsrC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-4.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; RBL_SEM_IPV6(1.00)[e.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.bl.ipv6.spameatingmonkey.net]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; IP_SCORE(-2.69)[ip: (-8.97), ipnet: 2a00:1450::/32(-2.35), asn: 15169(-2.08), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[e.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 00:35:36 -0000 Hi hackers! kern_sysctl.c provides an interface to get the members of a 'struct sysctl_oid' from the kernel to userland (it is needful to write a sysctl-like utility). A comment tells * This interface is under work and consideration, and should probably * be killed with a big axe by the first person who can find the time. * (be aware though, that the proper interface isn't as obvious as it * may seem, there are various conflicting requirements. Where can I find documentation/discussion/tips about it? I'm coding an interface https://gitlab.com/alfix/kernel-sysctlmibinfo for my ports. Regards, Alfonso Siciliano From owner-freebsd-hackers@freebsd.org Wed Mar 13 08:11:46 2019 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 86ED71529B3A for ; Wed, 13 Mar 2019 08:11:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 02A466D41D for ; Wed, 13 Mar 2019 08:11:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6DE56202563A; Wed, 13 Mar 2019 08:11:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x2D8BZ9r078360 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 08:11:35 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x2D8BYBb078359; Wed, 13 Mar 2019 08:11:34 GMT (envelope-from phk) To: Alfonso Siciliano cc: freebsd-hackers@freebsd.org Subject: Re: kern_sysctl.c interface In-reply-to: <20190313013530.d96fc84c362bb489178357eb@gmail.com> From: "Poul-Henning Kamp" References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78357.1552464694.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Mar 2019 08:11:34 +0000 Message-ID: <78358.1552464694@critter.freebsd.dk> X-Rspamd-Queue-Id: 02A466D41D X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.50 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.42)[0.415,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.790,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[phk.freebsd.dk]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.91)[0.909,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; IP_SCORE(0.10)[ip: (0.17), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.23), country: EU(-0.00)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 08:11:46 -0000 -------- In message <20190313013530.d96fc84c362bb489178357eb@gmail.com>, Alfonso Si= cilia no writes: >A comment tells > > * This interface is under work and consideration, and should probably > * be killed with a big axe by the first person who can find the time. > * (be aware though, that the proper interface isn't as obvious as it > * may seem, there are various conflicting requirements. I think that is a comment I added more than 20 years ago because we, or at least I, wondered if the sysctl-OID tree should be moved to something SNMP-OID compatible. I dont know of anything happening after that. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Wed Mar 13 11:50:40 2019 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 8CAAE152FB08 for ; Wed, 13 Mar 2019 11:50:40 +0000 (UTC) (envelope-from jhs@berklix.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 0C12273912 for ; Wed, 13 Mar 2019 11:50:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id C10C6152FB07; Wed, 13 Mar 2019 11:50:39 +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 9E9C5152FB06 for ; Wed, 13 Mar 2019 11:50:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39A5F7390A for ; Wed, 13 Mar 2019 11:50:36 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C2D5.dip0.t-ipconnect.de [46.82.194.213]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id x2DBoPCJ057077 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2019 12:50:34 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id x2DBoPjV033714; Wed, 13 Mar 2019 12:50:25 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id x2DBo75m071495; Wed, 13 Mar 2019 12:50:25 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201903131150.x2DBo75m071495@fire.js.berklix.net> To: hackers@freebsd.org cc: "Julian H. Stacey" Subject: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-From: http://www.berklix.eu/~jhs/ Date: Wed, 13 Mar 2019 12:50:07 +0100 X-Rspamd-Queue-Id: 39A5F7390A X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.60)[-0.603,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.088,0]; NEURAL_HAM_LONG(-0.71)[-0.705,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: slim.berklix.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.15)[asn: 33824(-0.76), country: DE(-0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[213.194.82.46.zen.spamhaus.org : 127.0.0.10] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 11:50:40 -0000 Hi hackers@freebsd.org, Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as uid=123 not root on 12.0, the process runs, But fails to correct the time ! Next thing to diagnose it, would be a kill of ntpd & restart direct as root, I'm not root there so I'll wait for that. Are others 12 systems slipping time too ? ------------------------------------------------------------------------------- The bad host: 12.0-p3 grep ntp /etc/rc.conf ntpd_enable="YES" Identical: /etc/ntp.conf /usr/src/usr.sbin/ntp/ntpd/ntp.conf ps -laxww | grep ntp| grep -v grep UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 123 17872 1 0 20 0 19424 19520 select Ss - 0:01.59 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift ntpd is running not as root, but as 123 ntpd:*:123:123:NTP Daemon:/var/db/ntp:/usr/sbin/nologin -r-xr-xr-x 1 root wheel 842896 Dec 7 05:16 /usr/sbin/ntpd ntpd has no s or g bits, so can not set time I presume, /var/log/messages has nothing since admin started it : Mar 11 20:51:53 hostname [16744]: ntpd 4.2.8p12-a (1): Starting Mar 11 20:51:54 hostname [16745]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature Mar 11 20:51:54 hostname [16745]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2019-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 Mar 11 21:37:46 hostname [16745]: ntpd exiting on signal 15 (Terminated) Mar 11 22:39:10 hostname [17871]: ntpd 4.2.8p12-a (1): Starting Mar 11 22:39:10 hostname [17872]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature Mar 11 22:39:10 hostname [17872]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2019-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 ls -l /var/db/ntpd* -rw-r--r-- 1 root wheel 10663 Dec 31 02:30 /var/db/ntpd.leap-seconds.list ------------------------------------------------------------------------------- A good host for comparison : 10.3-STABLE on time with radio wall clock: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 580 1 0 20 0 21900 13812 select Ss - 0:45.10 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift -r-xr-xr-x 1 root wheel 763888 Aug 17 2016 /usr/sbin/ntpd* Non root manual invocation of ntpd command above: must be run as root, not uid 200 grep ntp /etc/rc* /etc/rc.conf:ntpd_enable="YES" /etc/rc.conf:ntpd_sync_on_start="YES" # Sync time on ntpd startup, even if offset is high /etc/rc.conf:ntpdate_enable="YES" # Sync time on boot # as ntpd later refuses to compensate > 1 hour ls -l /var/db/ntpd* -rw-r--r-- 1 root wheel 8 Mar 13 10:14 /var/db/ntpd.drift -rw-r--r-- 1 root wheel 10663 Oct 27 14:10 /var/db/ntpd.leap-seconds.list Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent Brexit now minority: 2.1 M now over 18, More Remainers; 1.5 M died, less Leavers; 700 K votes Stolen from British Remainers in EU; + 3 M globaly dis- franchised; + drift to Remain + avoid chaos. MPs should urge Queen: Dismiss May, appoint new PM for unity government & 2nd Referendum. Revoke Art. 50, plan better, refile Art.50 later? http://ExitBrexit.UK/#email_an_mp From owner-freebsd-hackers@freebsd.org Wed Mar 13 12:06:15 2019 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 C39C91531044 for ; Wed, 13 Mar 2019 12:06:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) 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 40F1A74B0B for ; Wed, 13 Mar 2019 12:06:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id EEF61153103E; Wed, 13 Mar 2019 12:06:14 +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 CA8C0153103D for ; Wed, 13 Mar 2019 12:06:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A0FB74B08 for ; Wed, 13 Mar 2019 12:06:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.1.32] (92-111-45-98.static.v4.ziggozakelijk.nl [92.111.45.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E1447577B5; Wed, 13 Mar 2019 13:06:12 +0100 (CET) From: Dimitry Andric Message-Id: <19EB99F0-20E9-4FB9-98CF-118E3CDDE154@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E45711CD-3753-435C-A970-56A572965FE3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails Date: Wed, 13 Mar 2019 13:06:12 +0100 In-Reply-To: <201903131150.x2DBo75m071495@fire.js.berklix.net> Cc: hackers@freebsd.org To: "Julian H. Stacey" References: <201903131150.x2DBo75m071495@fire.js.berklix.net> X-Mailer: Apple Mail (2.3445.102.3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 12:06:16 -0000 --Apple-Mail=_E45711CD-3753-435C-A970-56A572965FE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Mar 2019, at 12:50, Julian H. Stacey wrote: > Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as > uid=3D123 not root on 12.0, the process runs, But fails to correct > the time ! Next thing to diagnose it, would be a kill of ntpd & > restart direct as root, I'm not root there so I'll wait for that. >=20 > Are others 12 systems slipping time too ? My systems are working fine, even though ntpd is running as user ntpd. There's this new part in /etc/rc.d/ntpd, which may be the reason it is not working for you: # Try to set up the the MAC ntpd policy so ntpd can run with = reduced # privileges. Detect whether MAC is compiled into the kernel, = load # the policy module if not already present, then check whether = the # policy has been disabled via tunable or sysctl. [ -n "$(sysctl -qn security.mac.version)" ] || return 1 sysctl -qn security.mac.ntpd >/dev/null || kldload -qn mac_ntpd = || return 1 [ "$(sysctl -qn security.mac.ntpd.enabled)" =3D=3D "1" ] || = return 1 So it tries to setup that MAC policy, which shows up in syslog like: kernel: Security policy loaded: MAC/ntpd (mac_ntpd) ntpd[810]: ntpd 4.2.8p12-a (1): Starting ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash = signature ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, = expire=3D2019-06-28T00:00:00Z last=3D2017-01-01T00:00:00Z ofs=3D37 Maybe on your system something goes wrong loading the mac_ntpd module, or setting the sysctl, but it still continues to attempt to run ntpd as non-root? I would run /etc/rc.d/ntpd with sh -x to see what is doing exactly. -Dimitry --Apple-Mail=_E45711CD-3753-435C-A970-56A572965FE3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXIjyNAAKCRCwXqMKLiCW o2f7AJ9RogZWGItHgLh1LQ1qaCUuAcBTeQCcCQ4AFcIRSA3MZxUPPqMBCvBI7Gs= =dBOj -----END PGP SIGNATURE----- --Apple-Mail=_E45711CD-3753-435C-A970-56A572965FE3-- From owner-freebsd-hackers@freebsd.org Wed Mar 13 12:13:18 2019 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 0652A1531717 for ; Wed, 13 Mar 2019 12:13:18 +0000 (UTC) (envelope-from jhs@berklix.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 79DCC750A7 for ; Wed, 13 Mar 2019 12:13:17 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 332B81531713; Wed, 13 Mar 2019 12:13:17 +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 0BD061531712 for ; Wed, 13 Mar 2019 12:13:17 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A418750A6 for ; Wed, 13 Mar 2019 12:13:14 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C2D5.dip0.t-ipconnect.de [46.82.194.213]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id x2DCD4Wp057478 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2019 13:13:12 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id x2DCD3BU033849; Wed, 13 Mar 2019 13:13:03 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id x2DCCj08071884; Wed, 13 Mar 2019 13:13:03 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201903131213.x2DCCj08071884@fire.js.berklix.net> to: hackers@freebsd.org cc: "Julian H. Stacey" Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Wed, 13 Mar 2019 12:50:07 +0100." <201903131150.x2DBo75m071495@fire.js.berklix.net> Date: Wed, 13 Mar 2019 13:12:45 +0100 X-Rspamd-Queue-Id: 2A418750A6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-0.27 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.56)[-0.561,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.20)[0.202,0]; NEURAL_HAM_LONG(-0.66)[-0.659,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: slim.berklix.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[213.194.82.46.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.14)[asn: 33824(-0.71), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 12:13:18 -0000 Hi, Reference: > From: "Julian H. Stacey" > Date: Wed, 13 Mar 2019 12:50:07 +0100 "Julian H. Stacey" wrote: > Hi hackers@freebsd.org, > Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as > uid=123 not root on 12.0, the process runs, But fails to correct > the time ! Next thing to diagnose it, would be a kill of ntpd & > restart direct as root, I'm not root there so I'll wait for that. > > Are others 12 systems slipping time too ? > > ------------------------------------------------------------------------------- > > The bad host: 12.0-p3 > grep ntp /etc/rc.conf > ntpd_enable="YES" > Identical: /etc/ntp.conf /usr/src/usr.sbin/ntp/ntpd/ntp.conf > ps -laxww | grep ntp| grep -v grep > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 123 17872 1 0 20 0 19424 19520 select Ss - 0:01.59 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift > ntpd is running not as root, but as 123 > ntpd:*:123:123:NTP Daemon:/var/db/ntp:/usr/sbin/nologin > -r-xr-xr-x 1 root wheel 842896 Dec 7 05:16 /usr/sbin/ntpd > ntpd has no s or g bits, so can not set time I presume, > /var/log/messages has nothing since admin started it : > Mar 11 20:51:53 hostname [16744]: ntpd 4.2.8p12-a (1): Starting > Mar 11 20:51:54 hostname [16745]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature > Mar 11 20:51:54 hostname [16745]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2019-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 > Mar 11 21:37:46 hostname [16745]: ntpd exiting on signal 15 (Terminated) > Mar 11 22:39:10 hostname [17871]: ntpd 4.2.8p12-a (1): Starting > Mar 11 22:39:10 hostname [17872]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature > Mar 11 22:39:10 hostname [17872]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2019-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 > ls -l /var/db/ntpd* > -rw-r--r-- 1 root wheel 10663 Dec 31 02:30 /var/db/ntpd.leap-seconds.list > > ------------------------------------------------------------------------------- > > A good host for comparison : 10.3-STABLE on time with radio wall clock: > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 580 1 0 20 0 21900 13812 select Ss - 0:45.10 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift > -r-xr-xr-x 1 root wheel 763888 Aug 17 2016 /usr/sbin/ntpd* > Non root manual invocation of ntpd command above: > must be run as root, not uid 200 > grep ntp /etc/rc* > /etc/rc.conf:ntpd_enable="YES" > /etc/rc.conf:ntpd_sync_on_start="YES" # Sync time on ntpd startup, even if offset is high > /etc/rc.conf:ntpdate_enable="YES" # Sync time on boot # as ntpd later refuses to compensate > 1 hour > ls -l /var/db/ntpd* > -rw-r--r-- 1 root wheel 8 Mar 13 10:14 /var/db/ntpd.drift > -rw-r--r-- 1 root wheel 10663 Oct 27 14:10 /var/db/ntpd.leap-seconds.list PS A CURRENT host built Sunday 13.0-CURRENT #13944 also runs as 123, not root UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 123 89944 1 0 23 0 18656 18752 select Ss - 0:00.12 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift (that box is currently inside a firewall though but that host is currently on time (with timed), on line inside a firewall, though if necessary to test ntpd, I could move it outside firewall & disrupt the time to see if ntpd corrects it. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent Brexit now minority: 2.1 M now over 18, More Remainers; 1.5 M died, less Leavers; 700 K votes Stolen from British Remainers in EU; + 3 M globaly dis- franchised; + drift to Remain + avoid chaos. MPs should urge Queen: Dismiss May, appoint new PM for unity government & 2nd Referendum. Revoke Art. 50, plan better, refile Art.50 later? http://ExitBrexit.UK/#email_an_mp From owner-freebsd-hackers@freebsd.org Wed Mar 13 13:02:07 2019 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 0F3521532C8B for ; Wed, 13 Mar 2019 13:02:07 +0000 (UTC) (envelope-from eugen@grosbein.net) 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 6B8A876A12 for ; Wed, 13 Mar 2019 13:02:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: by mailman.ysv.freebsd.org (Postfix) id 2AB451532C8A; Wed, 13 Mar 2019 13:02:06 +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 165771532C89 for ; Wed, 13 Mar 2019 13:02:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [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 8BA1076A0E; Wed, 13 Mar 2019 13:02:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x2DD1qPT097289 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Mar 2019 14:01:54 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: dim@FreeBSD.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x2DD1pDv005300 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2019 20:01:52 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails To: Dimitry Andric , "Julian H. Stacey" References: <201903131150.x2DBo75m071495@fire.js.berklix.net> <19EB99F0-20E9-4FB9-98CF-118E3CDDE154@FreeBSD.org> Cc: hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Wed, 13 Mar 2019 20:01:51 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <19EB99F0-20E9-4FB9-98CF-118E3CDDE154@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 8BA1076A0E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:02:07 -0000 13.03.2019 19:06, Dimitry Andric wrote: > On 13 Mar 2019, at 12:50, Julian H. Stacey wrote: >> Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as >> uid=123 not root on 12.0, the process runs, But fails to correct >> the time ! Next thing to diagnose it, would be a kill of ntpd & >> restart direct as root, I'm not root there so I'll wait for that. >> >> Are others 12 systems slipping time too ? > > My systems are working fine, even though ntpd is running as user ntpd. > > There's this new part in /etc/rc.d/ntpd, which may be the reason it is > not working for you: > > # Try to set up the the MAC ntpd policy so ntpd can run with reduced > # privileges. Detect whether MAC is compiled into the kernel, load > # the policy module if not already present, then check whether the > # policy has been disabled via tunable or sysctl. > [ -n "$(sysctl -qn security.mac.version)" ] || return 1 > sysctl -qn security.mac.ntpd >/dev/null || kldload -qn mac_ntpd || return 1 > [ "$(sysctl -qn security.mac.ntpd.enabled)" == "1" ] || return 1 > > So it tries to setup that MAC policy, which shows up in syslog like: > > kernel: Security policy loaded: MAC/ntpd (mac_ntpd) > ntpd[810]: ntpd 4.2.8p12-a (1): Starting > ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature > ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2019-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37 > > Maybe on your system something goes wrong loading the mac_ntpd module, Loading mac_XXX modules requires options MAC in running kernel. GENERIC has options but custom kernel may lack it. From owner-freebsd-hackers@freebsd.org Wed Mar 13 13:37:37 2019 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 A83D01533AAB for ; Wed, 13 Mar 2019 13:37:37 +0000 (UTC) (envelope-from jhs@berklix.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 2542277C58 for ; Wed, 13 Mar 2019 13:37:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id D35A91533AAA; Wed, 13 Mar 2019 13:37:36 +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 ABC2F1533AA9 for ; Wed, 13 Mar 2019 13:37:36 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 24E0077C56; Wed, 13 Mar 2019 13:37:31 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C2D5.dip0.t-ipconnect.de [46.82.194.213]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id x2DDbKmT058752 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2019 14:37:28 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id x2DDbJDQ034449; Wed, 13 Mar 2019 14:37:20 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id x2DDb1do072976; Wed, 13 Mar 2019 14:37:19 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201903131337.x2DDb1do072976@fire.js.berklix.net> To: Dimitry Andric cc: hackers@FreeBSD.org Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Wed, 13 Mar 2019 13:06:12 +0100." <19EB99F0-20E9-4FB9-98CF-118E3CDDE154@FreeBSD.org> Date: Wed, 13 Mar 2019 14:37:01 +0100 X-Rspamd-Queue-Id: 24E0077C56 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.11 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: slim.berklix.com]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[213.194.82.46.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.35)[-0.348,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.11)[0.114,0]; NEURAL_SPAM_SHORT(0.59)[0.586,0]; IP_SCORE(-0.13)[asn: 33824(-0.67), country: DE(-0.01)]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:37:38 -0000 > On 13 Mar 2019, at 12:50, Julian H. Stacey wrote: > > Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as > > uid=3D123 not root on 12.0, the process runs, But fails to correct > > the time ! Next thing to diagnose it, would be a kill of ntpd & > > restart direct as root, I'm not root there so I'll wait for that. > >=20 > > Are others 12 systems slipping time too ? > > My systems are working fine, even though ntpd is running as user ntpd. > > There's this new part in /etc/rc.d/ntpd, which may be the reason it is > not working for you: > > # Try to set up the the MAC ntpd policy so ntpd can run with = > reduced > # privileges. Detect whether MAC is compiled into the kernel, = > load > # the policy module if not already present, then check whether = > the > # policy has been disabled via tunable or sysctl. > [ -n "$(sysctl -qn security.mac.version)" ] || return 1 > sysctl -qn security.mac.ntpd >/dev/null || kldload -qn mac_ntpd = > || return 1 > [ "$(sysctl -qn security.mac.ntpd.enabled)" =3D=3D "1" ] || = > return 1 > > So it tries to setup that MAC policy, which shows up in syslog like: > > kernel: Security policy loaded: MAC/ntpd (mac_ntpd) > ntpd[810]: ntpd 4.2.8p12-a (1): Starting > ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash = > signature > ntpd[811]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, = > expire=3D2019-06-28T00:00:00Z last=3D2017-01-01T00:00:00Z ofs=3D37 > > Maybe on your system something goes wrong loading the mac_ntpd module, > or setting the sysctl, but it still continues to attempt to run ntpd as > non-root? > > I would run /etc/rc.d/ntpd with sh -x to see what is doing exactly. > > -Dimitry > Loading mac_XXX modules requires options MAC in running kernel. > GENERIC has options but custom kernel may lack it. > -Dimitry config -x /boot/kernel/kernel > ~/tmp/config options CONFIG_AUTOGENERATED ident GENERIC sysctl -qn security.mac.version 4 kldstat Id Refs Address Size Name 1 19 0xffffffff80200000 243cd00 kernel 5 1 0xffffffff82c47000 acf mac_ntpd.ko grep mac /boot/loader.conf # so probably the kernel module was loaded by ntpd # _ntp_default_dir ls -la /var/db/ntp total 10 drwxr-xr-x 2 ntpd ntpd 4 Mar 11 23:39 . drwxr-xr-x 15 root wheel 21 Feb 15 03:58 .. -rw-r--r-- 1 ntpd ntpd 6 Mar 11 23:39 ntpd.drift -rw-r--r-- 1 ntpd ntpd 5 Mar 13 13:53 ntpd.pid cd /etc; ls -ls | grep ntp drwx------ 2 root wheel 3 Dec 7 05:16 ntp -rw-r--r-- 1 root wheel 3997 Dec 7 05:16 ntp.conf ls -l /var/run/ntpd.leap-seconds.list ls: /var/run/ntpd.leap-seconds.list: No such file or directory I have bcc'd the owner & will wait for him to try as root: sh -x /etc/rc.d/ntpd restart sh -x /etc/rc.d/ntpd stop If he doesnt see clues with that, maybe I will soon when my current laptop will be travelling & also using ntpd. Thanks Dimitry Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent Brexit now minority: 2.1 M now over 18, More Remainers; 1.5 M died, less Leavers; 700 K votes Stolen from British Remainers in EU; + 3 M globaly dis- franchised; + drift to Remain + avoid chaos. MPs should urge Queen: Dismiss May, appoint new PM for unity government & 2nd Referendum. Revoke Art. 50, plan better, refile Art.50 later? http://ExitBrexit.UK/#email_an_mp From owner-freebsd-hackers@freebsd.org Wed Mar 13 13:46:51 2019 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 8E2C71533FA1 for ; Wed, 13 Mar 2019 13:46:51 +0000 (UTC) (envelope-from mail@osfux.nl) 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 CE82D80301 for ; Wed, 13 Mar 2019 13:46:50 +0000 (UTC) (envelope-from mail@osfux.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 886531533FA0; Wed, 13 Mar 2019 13:46:50 +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 470881533F9F for ; Wed, 13 Mar 2019 13:46:50 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.osfux.nl (vm1982.osfux.nl [IPv6:2a03:5500:1724:55:79:99:187:212]) (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 CAD5280300 for ; Wed, 13 Mar 2019 13:46:49 +0000 (UTC) (envelope-from mail@osfux.nl) Received: from vm1982.osfux.nl (localhost [127.0.0.1]) by vm1982.osfux.nl (Postfix) with ESMTP id 4A79E2036F; Wed, 13 Mar 2019 14:46:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1552484787; bh=UgkTRayc6tXsacQXFIs8f1CrOAHDkzvxpkY/Zx3ADiM=; h=Subject:To:References:From:Date:In-Reply-To; b=L98RwxJQ5NEEVa0JNExU7rKT6zwG9A/+PiNtzh4GAH3cW/IhPcsYVm0xxLFftxlLK g76l0WS4MF5zbxEFSnconiJ+/b7kKM76+00Rey+2lIEgqCgPKjUM7+MSkXHk4+YqpD EALVpZVAJ4z02YjMxdMF4in0u7NsyrKYll3ET2AC8fPnVIsSyZP1Wopxlan6W0zdIG 24tgKRsSxbx649WUhWJRcYC0uCI+86ScflwaDDGzPDY7z73iGOe796CNaXVU3wEBdU 6/oRaAtdZZ+16zYsf2dl/Fs5cRZjy4+jjtsNlOsacCg7wczRorp/9TC+UrnIXJxdFI kJ47GJ/Q0emEsPKdPBtRH35emkHY5IDLsdM31pFazX4gYc4oAHM1pl/msabTl2VZtl 9flK5AJ1UiV9TCkt63c+pDw5tPK1o82qiLvJ3yC3yGL6atYd8Hp0wSEr/3i3dEqAPd QNwl8GgWNnrU170Oksf+vwOw+xI42jcR69lMIWuZiejC2/pX/2JSjAx5r2c660v8mi 9VBcjfowtOtXjsI8hQzf1EA8PGR6NsLesFwExMtov5p0vPiuXuOzzB89ePfYfF0QXS TijoRnY9+AEa5KCFRbLRX7AdkI8eIgUwlrTigpR0onPJFN7/2jM8DIyEj01SY0G7+n 39YTcErChbovZkst3YgA55L4= Received: from vm1982.osfux.nl (localhost [127.0.0.1]) by vm1982.osfux.nl (Postfix) with ESMTP id 61F1C2013C; Wed, 13 Mar 2019 14:46:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=osfux.nl; s=default; t=1552484786; bh=UgkTRayc6tXsacQXFIs8f1CrOAHDkzvxpkY/Zx3ADiM=; h=Subject:To:References:From:Date:In-Reply-To; b=U43PeFabj4UVo5brM38NElDI+XO9djEmFirSXYqS5gc4xEmFkLxJgsOptouQ6VSks 2lzJfJ7j8EFL3OVGqwkVmbT996rPVJi0r09U/G0GbSUVlIL6Mxj1YXL/YlDQKA0sU/ qBE92Lnc3ImRi2nRlXLIB0h/psGYlBjasmzbFRPlhs6ywvWltXAHKWs1Dl6kPKjfLA V4vFfIDaB7Zk2AQDLQHzqS7LHx/oSlPDF6QF8FdFnebOS0zuhkgXyPDyQQzTdjJHt1 JIURFLSDin3GULDvwj7bHeLy0zTuu3U7Dz4GvBVLC8Pgxea56sGmGpJX1fS2j7hqOS JYzaWQ033/c6qgLcatygXf7E/PvQ8VQhiW1AutD75o+RdgslidGO3tzbxQYZP5nj+A 9H0j3zDi12/DR7UkTLll30cqctfxk9Az/MhAJproJCV8kCzQLox/05hvUB45V/5Y4I S6m/Yph4tKokYmAoks47eE89YP88hNt65Ks8MMKBLhEgGfbH4a0ExXL3Ogs9Yz1HuC 22eMrOp2Hvfqy60zV+7uSLtJZbI3R4u8ubSVhCP9VjNzPLJ3H4xPteLackxgvnlFTP +uasf3V/tcmGcrvK6pLaSMIZ0K78d8gHanQ6ZK1q40gCanvV4vAEwg3HM5swuDg5wk bg8MRqUsaw20FXScNHCqTr4g= X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on vm1982.osfux.nl Received: from [192.168.9.77] (ip51ccb320.speed.planet.nl [81.204.179.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vm1982.osfux.nl (Postfix) with ESMTPSA; Wed, 13 Mar 2019 14:46:25 +0100 (CET) Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails To: "Julian H. Stacey" , hackers@freebsd.org References: <201903131150.x2DBo75m071495@fire.js.berklix.net> From: Ruben Message-ID: <70bf53f4-92da-2021-8013-96411b859ef0@osfux.nl> Date: Wed, 13 Mar 2019 14:46:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <201903131150.x2DBo75m071495@fire.js.berklix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: CAD5280300 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:46:51 -0000 Hi Julian, On 3/13/19 12:50 PM, Julian H. Stacey wrote: > Hi hackers@freebsd.org, > Has anyone else noticed release 12.0-p3 /usr/sbin/ntpd runs as > uid=123 not root on 12.0, the process runs, But fails to correct > the time ! Next thing to diagnose it, would be a kill of ntpd & > restart direct as root, I'm not root there so I'll wait for that. > > Are others 12 systems slipping time too ? > Stuf snipped. I noticed some UID changes as well. Had to chown some ntpd directories to reflect that change as well (they were not writable for the ntpd daemon after upgrading from 11.2 to 12.0 . Regards, Ruben From owner-freebsd-hackers@freebsd.org Wed Mar 13 15:48:31 2019 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 758241537653 for ; Wed, 13 Mar 2019 15:48:31 +0000 (UTC) (envelope-from jhs@berklix.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 DC59285418 for ; Wed, 13 Mar 2019 15:48:30 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9D2E7153764D; Wed, 13 Mar 2019 15:48:30 +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 8BD5D153764A for ; Wed, 13 Mar 2019 15:48:30 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E296853D0; Wed, 13 Mar 2019 15:48:27 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C2D5.dip0.t-ipconnect.de [46.82.194.213]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id x2DFmCek062101 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2019 16:48:21 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id x2DFmCaZ035357; Wed, 13 Mar 2019 16:48:12 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id x2DFlEZ0078477; Wed, 13 Mar 2019 16:48:12 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201903131548.x2DFlEZ0078477@fire.js.berklix.net> To: Dimitry Andric , Eugene Grosbein , Ruben , hackers@freebsd.org Subject: Re: /usr/sbin/ntpd runs as uid=123 not root on 12.0 & fails From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Wed, 13 Mar 2019 14:46:37 +0100." <70bf53f4-92da-2021-8013-96411b859ef0@osfux.nl> Date: Wed, 13 Mar 2019 16:47:14 +0100 X-Rspamd-Queue-Id: 8E296853D0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.63 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.02)[-0.016,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.72)[-0.716,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.60)[0.603,0]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: slim.berklix.com]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[213.194.82.46.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.13)[asn: 33824(-0.63), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:48:31 -0000 Thanks Dimitry, Eugene, Ruben for all ideas, it helped to track down to what else ... root@ for the host found an old host specific ipfw firewall rule that needed to be deleted. Working now. Thanks again all. Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent Brexit now minority: 2.1 M now over 18, More Remainers; 1.5 M died, less Leavers; 700 K votes Stolen from British Remainers in EU; + 3 M globaly dis- franchised; + drift to Remain + avoid chaos. MPs should urge Queen: Dismiss May, appoint new PM for unity government & 2nd Referendum. Revoke Art. 50, plan better, refile Art.50 later? http://ExitBrexit.UK/#email_an_mp From owner-freebsd-hackers@freebsd.org Wed Mar 13 18:57:55 2019 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 7BC1C153DDBD for ; Wed, 13 Mar 2019 18:57:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69C8869EE7 for ; Wed, 13 Mar 2019 18:57:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x832.google.com with SMTP id z39so3225326qtz.0 for ; Wed, 13 Mar 2019 11:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=taHaWDG7Fir+hcmVPDx9MQotqNmzOJ0TaNBEaNyA/6Y=; b=NGbZnIaB/WEIJB7nPm4X/pXf/WD7dHK3AuPMDuyZx73UDWAP0ic5Ns7vDCTjGyDl1C ELK43x6OGLe7zkgAKHRCtHP1yVq/jiXhpJ4K7i0qALZDmf8Zrk5n5cE8FqkdtkGkoG3q FBkqjFlMcv10BXfa29yZwvNN90LOu8mch7vr3rSuxHNs82nXW89lRvsRZ9et8vg77cKs /SkH3s+BIDVX+NKxTakkDP77YeEvXqbbL1CdOpQRDI6CfDaDeSqYAC+Bn/d7G9XsH4Dh x+E8SmPTak5j/ApAulD0aWUr0NyoiprQLCn9lsOwS5GTjXyMcmB4ecziruYkPB7YmNWn tywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=taHaWDG7Fir+hcmVPDx9MQotqNmzOJ0TaNBEaNyA/6Y=; b=hnssv2n17JNc6LxmM+f2+77GYF1e3ZPyGgQD7HYf4/u5/mxICk2SzIaR/tqgJG1sYi f7GBpIGpUAIt+dqqhbDWaZv4h8Z4DMEYpUC66C+t6L2Vbmby5Q8M13w+omCas0/UxAQ4 jmjU20pxCuX5o76H/8173aP7F2N3A/AVg0iFsMBku0jMF1r6DCG00rs9qdDRjiJWvwsR Dhvkf2pJ7uxnZPUA4q15h3XfDFZnyXRhX3hmLYy54oNLDH4kMWQEMuAT2VVpFOqzAp/x CtFkGuiz7PJ3W08UBnQ0NnTBvN3S+WGF0IpK2eub/c6/n4iINKMxx/KFVihIYHQZO/jX Vapw== X-Gm-Message-State: APjAAAW5a1RKJf2bynCZysA2YVp9R0/Za4tsv2wfa5q7la0QCrJywnhN lCVgaj46PfmDIXE2BoIYwEfQFaTJznuw5JxaYzcGc5mI X-Google-Smtp-Source: APXvYqwXzV/e40ARc3D10H2UXycyRFm+TtVyXHQPl2Wj/1k6v7xiv2WY7Ub6KedRuhETv43gRj32qf0raQRRCHDpM1s= X-Received: by 2002:ac8:2b2e:: with SMTP id 43mr35523670qtu.33.1552503473648; Wed, 13 Mar 2019 11:57:53 -0700 (PDT) MIME-Version: 1.0 References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> In-Reply-To: <78358.1552464694@critter.freebsd.dk> From: Warner Losh Date: Wed, 13 Mar 2019 12:57:41 -0600 Message-ID: Subject: Re: kern_sysctl.c interface To: Poul-Henning Kamp Cc: Alfonso Siciliano , FreeBSD Hackers X-Rspamd-Queue-Id: 69C8869EE7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=NGbZnIaB X-Spamd-Result: default: False [-4.00 / 15.00]; RBL_SEM_IPV6(1.00)[2.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.bl.ipv6.spameatingmonkey.net]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.52)[-0.522,0]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; R_DKIM_ALLOW(0.00)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(-2.77)[ip: (-9.00), ipnet: 2607:f8b0::/32(-2.73), asn: 15169(-2.08), country: US(-0.07)] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:57:55 -0000 On Wed, Mar 13, 2019, 2:14 AM Poul-Henning Kamp wrote: > -------- > In message <20190313013530.d96fc84c362bb489178357eb@gmail.com>, Alfonso > Sicilia > no writes: > > >A comment tells > > > > * This interface is under work and consideration, and should probably > > * be killed with a big axe by the first person who can find the time. > > * (be aware though, that the proper interface isn't as obvious as it > > * may seem, there are various conflicting requirements. > > I think that is a comment I added more than 20 years ago because we, > or at least I, wondered if the sysctl-OID tree should be moved to > something SNMP-OID compatible. > > I dont know of anything happening after that. > I suspect after 20ish years the comment can be removed, eh? Warner -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Mar 13 19:06:11 2019 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 E8215153E4B2; Wed, 13 Mar 2019 19:06:10 +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 4CD4A6A963; Wed, 13 Mar 2019 19:06:10 +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 x2DJ61oF003064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 21:06:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2DJ61oF003064 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2DJ5wrI003063; Wed, 13 Mar 2019 21:05:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Mar 2019 21:05:58 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190313190558.GB2492@kib.kiev.ua> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190305223415.U1563@besplex.bde.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:06:11 -0000 On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: > On Tue, 5 Mar 2019, Bruce Evans wrote: > > > On Mon, 4 Mar 2019, Konstantin Belousov wrote: > > >* [... shift for bogus TSC-low timecounter] > >> I suspect that the shift of 1 (at least) hides cross-socket inaccuracy. > >> Otherwise, I think, some multi-socket machines would start showing the > >> detectable backward-counting bintime(). At the frequencies at 4GHz and > >> above (Intel has 5Ghz part numbers) I do not think that stability of > >> 100MHz crystall and on-board traces is enough to avoid that. > > > > I think it is just a kludge that reduced the problem before it was fixed > > properly using fences. > > > > Cross-socket latency is over 100 cycles according to jhb's tscskew > > benchmark: on Haswell 4x2: > > > > CPU | TSC skew (min/avg/max/stddev) > > ----+------------------------------ > > 0 | 0 0 0 0.000 > > 1 | 24 49 84 14.353 > > 2 | 164 243 308 47.811 > > 3 | 164 238 312 47.242 > > 4 | 168 242 332 49.593 > > 5 | 168 243 324 48.722 > > 6 | 172 242 320 52.596 > > 7 | 172 240 316 53.014 > > > > freefall is similar. Latency is apparently measured relative to CPU 0. > > It is much lower to CPU 1 since that is on the same core. > > > > I played with this program a lot 3 and a half years ago, but forgot > > mist of what I learned :-(. I tried different fencing in it. This > > seems to make little difference when the program is rerun. With the > > default TESTS = 1024, the min skew sometimes goes negative on freefall, > > but with TESTS = 1024000 that doesn't happen. This is the opposite > > of what I would expect. freefall has load average about 1. > > I understand this program again. First, its name is actually tscdrift. > I tested the 2015 version, and this version is still in > /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to > the copyright (rgrimes wouldn't like this) and to $FreeBSD$. > > The program doesn't actually measure either TSC drift or TSC skew, except > indirectly. What it actually measures is the IPC (Inter-Process- > Communication) time for synchronizing the drift and skew measurments, > except bugs or intentional sloppiness in its synchronization also make it > give an indirect measurement of similar bugs or sloppiness in normal use. > > After changing TESTS from 1024 to 1024000, it shows large errors in the > negative direction, as expected from either large negative skew or program > bugs: this is on freefall: > > XX CPU | TSC skew (min/avg/max/stddev) > XX ----+------------------------------ > XX 0 | 0 0 0 0.000 > XX 1 | -6148 108 10232 46.871 > XX 2 | 114 209 95676 163.359 > XX 3 | 96 202 47835 101.250 > XX 4 | -2223 207 34017 117.257 > XX 5 | -2349 206 33837 106.259 > XX 6 | -2664 213 33579 96.048 > XX 7 | -2451 212 49242 126.428 Note that freefall is single-socket. My belief is that due to the construction of the RDTSC on Intels, it is impossible for the counter to become scew on single socket. All cores are fed from the same input signal, and most likely, even read the same uncore counter. The later is less likely because RDTSC latency is quite low, but there might be additional hw tricks. On the other hand, for multi-socket machines, I do not think there is anything except the external clock signal which would ensure that the counters stay in sync. I tried to imagine is there is any shared hardware on multi-socket Intel system which would give equal latency for accesses from different sockets, and it seems that there is no such hardware. Then it is trully impossible to observe the scew. It might be possible to measure round-trip time separately, and then subtract it from the measured scew. > > The negative "skews" occur because the server and the clients (1 client at > a time) read the TSC with uncontrolled timing after the server opens the > gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs > on different cores. So when neither thread is preempted, the TSC on the > server is about 200 cycles in advance. Sometimes the server is preempted, > so it reads its TSC later than the client (a maximum of about 6148 cycles > later in this test). More often the client is preempted, since the IPC > time is march larger than the time between the server opening the gate and > the server reading its TSC. > > The server is also missing fencing for its TSC read, so this read may > appear to occur several cycles before opening the gate. This gives a > an error in the positive direction for the reported "skew" (the error > is actually in the positive direction for the reported IPC time). It > would be useful to measure this error by intentionally omitting fencing, > but currently it is just a small amount of noise on top of the noise from > preemption. > > After fixing the syncronization: > > XX CPU | TSC skew (min/avg/max/stddev) > XX ----+------------------------------ > XX 0 | 0 0 0 0.000 > XX 1 | 33 62 49161 57.652 > XX 2 | 108 169 33678 73.456 > XX 3 | 108 171 43053 119.256 > XX 4 | 141 169 41289 114.567 > XX 5 | 141 169 40035 112.755 > XX 6 | 132 186 147099 269.449 > XX 7 | 153 183 431526 436.689 > > Synchronization apparenly takes a long time, especially to other cores. > The minimum and avergae now gives the best-case IPC time very accurately. > The average is 20-30 cycles smaller than before, probably because I > fixed the fencing. The maximum and standard deviation are garbage noise > from preemption. Preemption should be disabled somehow. > > Large drifts and skews would show up as nonsense values for the minimum > IPC time. Small drifts would soon give large skews. To measure small > skews, change the CPU of the server to measure the minimum IPC time in > the opposite direction. > > Fixes: > > XX --- tscdrift.c 2015-07-10 06:22:36.505493000 +0000 > XX +++ w.c 2019-03-05 11:22:22.232341000 +0000 > XX @@ -32,6 +32,15 @@ > XX #include > XX #include > XX #include > XX +/* > XX + * XXX: atomic.h is not used. Instead we depend on x86 memory ordering and > XX + * do direct assignments to and comparisons of 'gate', and sometimes add > XX + * memory barriers. The correct atomic ops would do much the same with > XX + * clearer spelling. The 'lock' prefix is never needed and the barriers are > XX + * only to get program order so as to give acq or rel semantics for ether > XX + * the loads, the stores or for buggy unfenced rdtsc's. Fences also give > XX + * program order, so some of the explicit barriers are redundant. > XX + */ > XX #include > XX #include > XX #include > XX @@ -45,7 +54,7 @@ > XX > XX #define barrier() __asm __volatile("" ::: "memory") > XX > XX -#define TESTS 1024 > XX +#define TESTS 1024000 > XX > XX static volatile int gate; > XX static volatile uint64_t thread_tsc; > XX @@ -74,12 +83,12 @@ > XX gate = 1; > XX while (gate == 1) > XX cpu_spinwait(); > XX - barrier(); > XX > XX + barrier(); > XX __asm __volatile("lfence"); > XX thread_tsc = rdtsc(); > XX - > XX barrier(); > XX + > XX gate = 3; > XX while (gate == 3) > XX cpu_spinwait(); > > This is the client. The explicit barriers are confusing, and the blank > lines are in all the wrong places. All the accesses to 'gate' need > to be in program order. x86 memory ordering gives this automatically > at the hardware level. 'gate' being volatile gives it at the compiler > level. Both rdtsc() and storing the result to thread_tsc need to be > in program order. lfence() in cpufunc.h has a memory clobber which > gives the former, but we use a direct asm and need a barrier() before > it to do the same thing. Then we need another barrier() after the > assignment to thread_tsc so that the store for this is before the store > to 'gate' (I think gate being volatile doesn't give this). This also > keeps the rdtsc() in program order (the asm for rdtsc() doesn't have > a memory clobber. I haven't noticed care about this being taken > anywhere else). > > Summary: only style changes in this section. > > XX @@ -139,12 +148,13 @@ > XX for (j = 0; j < TESTS; j++) { > XX while (gate != 1) > XX cpu_spinwait(); > XX - gate = 2; > XX - barrier(); > > Move down opening the gate so that it not opened until after reading the > TSC on the server. > > XX > XX + barrier(); > XX + __asm __volatile("lfence"); > > Fencing is not critical here. Using an early TSC value just gives a larger > reported IPC time. The barrier is important for getting program order of > rdtsc(). > > XX tsc = rdtsc(); > XX - > XX barrier(); > > This barrier is still associated with the TSC read, and the blank like is > moved to reflect this. Here rdtsc() must occur in program order, but > storing to tsc can be after storing to 'gate'. The barrier gives ordering > for the store to tsc too. > > XX + > XX + gate = 2; > XX while (gate != 3) > XX cpu_spinwait(); > XX gate = 4; > > I tried some locked atomic ops on 'gate') and mfence instead of lfence > to try to speed up the IPC. Nothing helped. We noticed long ago that > fence instructions tend to be even slower that locked atomic ops for > mutexes, and jhb guessed that this might be because fence instructions > don't do so much to force out stores. I am not sure I follow. MFENCE is documented by wording that implies, without any doubts, that store buffers are flushed before the instruction is retired. It is not so obvious for SFENCE, which sounds like a real fence instead of full flush, at least for normal write-back memory where it is NOP as far as ISA is considered. It is known and documented in optimization manuals that locked operations are much more efficient, but locked ops are only documented to ensure ordering and not flush. So SFENCE is not suitable as our barrier. And, the second point, LFENCE there does not work as barrier for IPC. It only ensures that RDTSC is not started earlier than the previous instructions. No store buffer flushing is done. > > Similar IPC is needed for updating timecounters. This benchmark indicates > that after an update, the change usually won't be visible on other CPUs > for 100+ cycles. Since updates are rare, this isn't much of a problem. > > Similar IPC is needed for comparing timecounters across CPUs. Any activity > on different CPUs is incomparable without synchronization to establish an > ordering. Since fences give ordering relative to memory and timecounters > don't use anything except fences and memory order for the generation count > to establish their order, the synchronization for comparing timecounters > (or clock_gettime() at higher levels) must also use memory order. > > If the synchronization takes over 100 cycles, then smaller TSC skews don't > matter much (they never break monotonicity, and only show up time differences > varying by 100 or so cycles depending on which CPU measures the start and > end events). Small differences don't matter at all. Skews may be caused It should be more than 100 cycles for inter-socket IPC, but then genuine RDTSC scew can accumulate much larger than 100, which is my worry. > by the TSCs actually being out of sync, or hardware only syncing them on > average (hopefully with small jitter) or bugs like missing fences. Missing > fences don't matter much provided unserialized TSC reads aren't too far > in the past. E.g., if we had a guarantee of only 10 cycles in the past for > the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. > But IPCs to the same core are 100 cycles faster so the margin is too close > for ommitting fences in all cases. I have no idea if RDTSC is allowed to execute before (in program order) earlier cache miss. If it is, then non-fenced RDTSC would easily give much larger error than IPC sync delay. > > Similarly for imperfect hardware. Hopefully its skew is in the +-1 cycle > range, but even +-10 isn't a problem if the IPC time is a bit larger than > 10 and even +-100 if the IPC time is a bit larger than 100. And the problem > scales nicely with the distance of the CPUs -- when they are further apart > so that hardware synchronization of their TSCs is more difficult, the IPC > time is large too. > > Hmm, that is only with physical IPCs. Since timecounters use physical > IPCs for everything, they can't work right with virtual synchronization. > Something like ntpd is needed to compare times across even small local > networks. It does virtual synchronization by compensating for delays. > > Bruce From owner-freebsd-hackers@freebsd.org Wed Mar 13 19:53:43 2019 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 C3960153FD91 for ; Wed, 13 Mar 2019 19:53:43 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9346D350 for ; Wed, 13 Mar 2019 19:53:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 432892025628; Wed, 13 Mar 2019 19:53:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x2DJreYg000887 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 19:53:41 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x2DJreA5000886; Wed, 13 Mar 2019 19:53:40 GMT (envelope-from phk) To: Warner Losh cc: Alfonso Siciliano , FreeBSD Hackers Subject: Re: kern_sysctl.c interface In-reply-to: From: "Poul-Henning Kamp" References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <884.1552506820.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Mar 2019 19:53:40 +0000 Message-ID: <885.1552506820@critter.freebsd.dk> X-Rspamd-Queue-Id: 6D9346D350 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.73 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.71)[0.713,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.72)[0.722,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: phk.freebsd.dk]; NEURAL_SPAM_LONG(0.91)[0.915,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; IP_SCORE(0.09)[ip: (0.17), ipnet: 130.225.0.0/16(0.08), asn: 1835(0.23), country: EU(-0.00)]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:53:43 -0000 -------- In message , Warner Losh writes: >> > * This interface is under work and consideration, and should probably >> > * be killed with a big axe by the first person who can find the time. >> > * (be aware though, that the proper interface isn't as obvious as it >> > * may seem, there are various conflicting requirements. >> >> I think that is a comment I added more than 20 years ago because we, >> or at least I, wondered if the sysctl-OID tree should be moved to >> something SNMP-OID compatible. >> >> I dont know of anything happening after that. > >I suspect after 20ish years the comment can be removed, eh? Well, it's still a butt-ugly and inefficient interface... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Wed Mar 13 20:35:24 2019 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 B10B5154160F for ; Wed, 13 Mar 2019 20:35:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 455FE6F8B7 for ; Wed, 13 Mar 2019 20:35:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZIxdcuAVM1lpvAgC.IfMgIwEtoCInE36rN.16_uZzwK3ExhtbK1R39ftgmXFmRU BRmIjYjxj8tKmx_Y4lBvygjEW5dsqsRyCN9UZrDyD__Jkn4q5hnLWfr1OIFsYEJOXdYIWJOe7yPG 1siWx4qgvIWyodOaxj_HLzM7Z6FyuOgfblqk5w0w75w1M65D48ww82cO072yJYrn4KTUACJxs9cb 6koxTS4fMGFu_TBmprLsdcZZf4ySmIW64sEEqx2rBad997veGvP6nbFTWCUOJzCVAy3JwMOGdFob t_OLSW9.PO0FxLmS1dmnkNSEnjKb3ipLZK3UgkWTxoTFKA4JiUD0NsM_SJvJ3F_H1PYPfqvFCqfg RMy7UGIZCkDTCPrkW5UsL8US6r2fyHXPqNB2AHwX8UOJxac9zM1_iH6hDe99wZFwjwBs5MhXA08p nWyHoy5REGE7aMqyl6iRshEDXrvS0358lpRWID8bDQYMfiDvsUXHH5jTITql82b06d4SqLAvZz9F eni2AIJCYjyiCP1n29h5w9yvjcm8e4fND8ds0W32WidvKxj1GJ_LxafJb9zzJ3Nc2n5j31fCa2V0 VJctIegmYx09GhFOGuf8DbqyMfQVhrINHCsxdmahqIEUgdLEJmAR3c_3vWaIuoB6Z3FW0VYbF6Y8 Am3jnfvk20jdQhteXtQoEWYi23iilF_.GkDAgY3SBgXIhIXqSyGlBgBGuyxgl.l7X48U3mS2w37m gooGwp5UOX6TKvb9gY0i3dvHm4dEYRQD0xDOSO0xymwgyEXOYYrpLX5z0eGC7gfJ4xKxl5DoYUux Qyf2NMe1Rri1arvCxWg75VXpDfCq.jlyO2FrfLlYEAb3N1a8GvLQrhe0lHN5OYq9GAuObShX5W9j QIp8WXDysseCtPXOZJQjUTYldIRBzuT58.NPD9tUd30tU5EIzLH1IZdSGtpNdj4EKzcjbXrWrCs7 zI78SrMOuPHmCbL5fkuXRmJ462vJ3unJTuIVcSkhLaxGD4MnrVXLduNHzaoZGMKWA24zf1vRqTFW L0beqLY70NWRjc6wi7iasAr_kMX5wf_nmsqIDMjdbEXbEueQL7I52iPFKXRDS Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Mar 2019 20:35:21 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e21aea6b1716ae0d89a03f93d0b5f824; Wed, 13 Mar 2019 20:15:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: C++11 Load/Store seq cst for powerpc64: which style does the FreeBSD ABI specify? Message-Id: <5B354F1C-AFDC-4306-857A-48AACB2D8492@yahoo.com> Date: Wed, 13 Mar 2019 13:15:04 -0700 To: FreeBSD PowerPC ML , freebsd-hackers Hackers X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 455FE6F8B7 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.87)[ip: (2.66), ipnet: 98.137.64.0/21(0.98), asn: 36647(0.78), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.60)[0.598,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_MEDIUM(0.36)[0.356,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.70)[0.698,0]; RCVD_IN_DNSWL_NONE(0.00)[147.69.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:35:25 -0000 According to: https://www.cl.cam.ac.uk/~pes20/cppppc/popl079-batty.pdf the following two alternatives do not interoperate correctly and so can not be mixed --and so the ABI needs to specify a choice of which to use so that code from various compilers and such can be mixed: (leading-sync style:) Load Seq Cst: sync; ld; cmp; bc; isync Store Seq Cst: sync; st vs. (the trailing-sync style:) Load Seq Cst: ld; sync Store Seq Cst: lwsync; st; sync Which is the powerpc64 FreeBSD ABI based on? Which is the 32-bit powerpc FreeBSD ABI based on? Is there a place to see the FreeBSD ABI specification of this for powerpc64 (and any related items)? If yes, where? Similarly for 32-bit powerpc. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Wed Mar 13 21:47:45 2019 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 B36CF1542D57 for ; Wed, 13 Mar 2019 21:47:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30AB271E00 for ; Wed, 13 Mar 2019 21:47:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: njhf4UMVM1konPYelGtCvG2CLqQbU2S165OHROnVAP9wg9HyjO51PkO4DNHPCzI 502D0uLj2YBDLZmRA64XBORhlQJw5Ghxwr2gLhSzvHb_gQL3VRU3lGMQiIEzuLn_SzfxW1etQXNW yIVlJDl6uWdELzd2j1r83.q0QvvLd0k3IwatDyRvhvfKaxv3NWSYMLzY8brSfeWi9amknabxYt.f RGKf2eIYU4WPvXQ9Zp3RrrndCSssCZuXEDikRFwPma0E1AzP1ygGxw3NMHG74HmWbiBSiRxI8XfW nsygbRMt93oqyoITKZ0peYNCB_YteN1CdB3tZ53QUMHJlNsn44fEG.75fxhlCmUBhukHw5sUVe7X _JdU.R40EsJEWnbMANXaBI.s6YQStGfcG21wFDdARTsnTmBDCB9NuDXE6hcaGzEZNeY7nfX4P3GS MTQUSARJBRzaxQ8V2vWeQP7xHTLITF1C7mir4XZmYAbw3Ut4lzODVY1Y9z.Pzs7dq_rAzOJ4InyK nz49Ir5bbQI8gaF11U.j.bD7Vvj_sQLOYdxmz92sPGA1qy0Bjpx0j2DETPgtBKnua48EOoBbaKV8 rkQRaUq1zn_4aKNYEdB9312tIFxpiBNOy9IXSlvpUXpqQ4TYjpVYDgyK.UJP5Q92qXFjpt9y6OkB L8bO8IjmtHdAQMC_5YTWp4GC.PTqBHnNdxmhpZdQkLk2HEev9Rm6f44IjBBwDqdAH6uMQg6qyE2O e9Wa_yQoPnuQYw4baEiRkTrTmNnmsVMBCllD9jusuuAVuauUqmngUd2oExmBBAx.Jk6RlrdQod_9 CMpr.e.2nSxYibH29sKLyN3WXrVm.lnB_kG3naWAED6TFUTv2rx9HtZLCEMnN5cyoDd0OL9SPElN x1AQ_ZdG8p7tw47KkugHcVuUM37Yq8n5uJ8bOAXyRyxvgEeriaJLIJWm8U.k7xbWCLodywlk.Ocf V18.t7SfBDwwkqwCF4.GMO3cYMxu8Fsl6GhT08K7PtDUon7iHZOPstheXTNtw9488k0CA3nw89Go rQse7h_WjkxY0YjmaBF5vrMYS38APcIPTD9Ef7md2lgHfeud1Crld._gOAuRU3OrfjvONKOi2t8M rvYiXNAM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Mar 2019 21:47:38 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 58284d86e6b91e2c7d115888f3682c37; Wed, 13 Mar 2019 21:47:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) From: Mark Millard In-Reply-To: <20190313190558.GB2492@kib.kiev.ua> Date: Wed, 13 Mar 2019 14:47:35 -0700 Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 30AB271E00 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 21:47:46 -0000 On 2019-Mar-13, at 12:05, Konstantin Belousov wrote: >> . . . > I am not sure I follow. MFENCE is documented by wording that implies, > without any doubts, that store buffers are flushed before the > instruction is retired. It is not so obvious for SFENCE, which > sounds like a real fence instead of full flush, at least for normal > write-back memory where it is NOP as far as ISA is considered. > > It is known and documented in optimization manuals that locked > operations are much more efficient, but locked ops are only documented > to ensure ordering and not flush. So SFENCE is not suitable as our > barrier. What I've seen in papers for the C++ Load/Store Seq Cst mappings to processors is: For write-fencing style: Load Seq Cst: MOV from memory Store Seq Cst alternative 0: XCHG (which as an implicit lock prefix) Store Seq Cst alternative 1: MOV into memory; MFENCE For read-fencing style: Load Seq Cst alternative 0: LOCK XADD(0) Load Seq Cst alternative 1: MFENCE; MOV from memory Store Seq Cst: MOV into memory There is also: Seq Cst Fence: MFENCE I've never seen SFENCE (or LFENCE) suggested for any of the above. I would expect for C++ Seq Cst that the XCHG and the LOCK XADD(0) would need to flush store buffers in order for those alternatives to be valid for C++ Seq Cst. I've seen a reference to a "locked identity operation to the top of stack" as another form of locked style of Seq Cst fencing. (write-fencing and read-fencing can not be generally mixed for Seq Cst: they do not inter-operate.) > And, the second point, LFENCE there does not work as barrier for IPC. > It only ensures that RDTSC is not started earlier than the previous > instructions. No store buffer flushing is done. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Mar 14 12:51:34 2019 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 D95D11541207; Thu, 14 Mar 2019 12:51:33 +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 21B69763BB; Thu, 14 Mar 2019 12:51:33 +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 x2ECpK3K056767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 14:51:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2ECpK3K056767 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2ECpJwD056766; Thu, 14 Mar 2019 14:51:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 14:51:19 +0200 From: Konstantin Belousov To: Mark Millard Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190314125119.GG2492@kib.kiev.ua> References: <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C3486AE-DA3A-49DF-BAA5-139D4E99FADB@yahoo.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:51:34 -0000 On Wed, Mar 13, 2019 at 02:47:35PM -0700, Mark Millard wrote: > > > On 2019-Mar-13, at 12:05, Konstantin Belousov wrote: > > >> . . . > > I am not sure I follow. MFENCE is documented by wording that implies, > > without any doubts, that store buffers are flushed before the > > instruction is retired. It is not so obvious for SFENCE, which > > sounds like a real fence instead of full flush, at least for normal > > write-back memory where it is NOP as far as ISA is considered. > > > > It is known and documented in optimization manuals that locked > > operations are much more efficient, but locked ops are only documented > > to ensure ordering and not flush. So SFENCE is not suitable as our > > barrier. > > What I've seen in papers for the C++ Load/Store Seq Cst mappings to > processors is: > > For write-fencing style: > > Load Seq Cst: MOV from memory > Store Seq Cst alternative 0: XCHG (which as an implicit lock prefix) > Store Seq Cst alternative 1: MOV into memory; MFENCE > > For read-fencing style: > > Load Seq Cst alternative 0: LOCK XADD(0) > Load Seq Cst alternative 1: MFENCE; MOV from memory > Store Seq Cst: MOV into memory > > There is also: > > Seq Cst Fence: MFENCE > > I've never seen SFENCE (or LFENCE) suggested for any of the above. I do not discuss implementation of the C++11 memory model primitives. FWIW, FreeBSD atomic(9) uses more optimal variant of what you call read-fencing style on x86. I did not looked (or rather, do not remember what I saw) at the implementation of C1x memory model load_acq and store_rel in clang and gcc. My text above is about 1. ensuring that RDTSC is executed not earlier than the previous instructions in the program order, and 2. making stores from the server thread visible to the subordinate thread as soon as possible, so that the store buffer latency was not accounted for the RDTSC inter-core communication latency. > > I would expect for C++ Seq Cst that the XCHG and the LOCK XADD(0) > would need to flush store buffers in order for those alternatives > to be valid for C++ Seq Cst. > > I've seen a reference to a "locked identity operation to the top of > stack" as another form of locked style of Seq Cst fencing. > > (write-fencing and read-fencing can not be generally mixed for Seq > Cst: they do not inter-operate.) > > > And, the second point, LFENCE there does not work as barrier for IPC. > > It only ensures that RDTSC is not started earlier than the previous > > instructions. No store buffer flushing is done. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Mar 14 13:00:46 2019 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 3B21715419C2 for ; Thu, 14 Mar 2019 13:00:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70734768E4 for ; Thu, 14 Mar 2019 13:00:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4CC7026011B; Thu, 14 Mar 2019 14:00:42 +0100 (CET) Subject: Re: USB stack getting confused From: Hans Petter Selasky To: "O'Connor, Daniel" Cc: Konstantin Belousov , FreeBSD Hackers References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> <991d10df-b42d-b557-1b47-37db5bfb4d42@selasky.org> Message-ID: Date: Thu, 14 Mar 2019 14:00:17 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <991d10df-b42d-b557-1b47-37db5bfb4d42@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 70734768E4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.82)[-0.823,0]; IP_SCORE(-2.58)[ip: (-8.77), ipnet: 2a01:4f8::/29(-2.19), asn: 24940(-1.94), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:00:46 -0000 On 3/11/19 2:41 PM, Hans Petter Selasky wrote: >> >> I have the source code and I can see what the issue is so I'll fix >> that, although I am surprised the limit for USB devices is so much >> lower than the system limit for file descriptors generally. >> > > Hi, > > USB has a limit on open FD's per USB device, (USB_FIFO_MAX = 128) / 2 = 64. > > --HPS Hi Daniel, There can be up to 127 devices per USB controller, so 127 * 64 FDs is the maximum allowed. I think the limit is reasonable, given that non-admin users can have access to such devices. Did you get any further on this issue? --HPS From owner-freebsd-hackers@freebsd.org Thu Mar 14 13:31:17 2019 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 AC50C1543C14 for ; Thu, 14 Mar 2019 13:31:17 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id B8D4B77C31 for ; Thu, 14 Mar 2019 13:31:09 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from 124-148-131-52.dyn.iinet.net.au (HELO midget.dons.net.au) ([124.148.131.52]) by ipmail06.adl2.internode.on.net with ESMTP; 15 Mar 2019 00:01:00 +1030 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x2EDUiUd092847 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Mar 2019 00:00:58 +1030 (ACDT) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x2ED2vxd073554 for ; Thu, 14 Mar 2019 23:32:57 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [10.0.2.26] ([10.0.2.26]) by ns.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id x2ED2uTo073551; Thu, 14 Mar 2019 23:32:57 +1030 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: USB stack getting confused From: "O'Connor, Daniel" In-Reply-To: Date: Thu, 14 Mar 2019 23:32:56 +1030 Cc: Konstantin Belousov , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <01E69132-6EB6-4688-ADA2-FF62393F8DFA@dons.net.au> References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> <991d10df-b42d-b557-1b47-37db5bfb4d42@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: B8D4B77C31 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.37 / 15.00]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[midget.dons.net.au]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[129.137.101.150.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[52.131.148.124.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.98)[0.984,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.02)[ip: (3.89), ipnet: 150.101.0.0/16(0.91), asn: 4739(0.32), country: AU(-0.04)]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[dons.net.au]; NEURAL_SPAM_MEDIUM(0.98)[0.976,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:31:17 -0000 > On 14 Mar 2019, at 23:30, Hans Petter Selasky wrote: > On 3/11/19 2:41 PM, Hans Petter Selasky wrote: >>>=20 >>> I have the source code and I can see what the issue is so I'll fix = that, although I am surprised the limit for USB devices is so much lower = than the system limit for file descriptors generally. >>>=20 >> Hi, >> USB has a limit on open FD's per USB device, (USB_FIFO_MAX =3D 128) / = 2 =3D 64. >> --HPS >=20 > There can be up to 127 devices per USB controller, so 127 * 64 FDs is = the maximum allowed. I think the limit is reasonable, given that = non-admin users can have access to such devices. I suppose that makes sense, but the failure mode was pretty surprising = to me. I didn't realise that usbconfig has to open each device to get = information on it - I had assumed that it got it via /dev/usbctl or = similar. > Did you get any further on this issue? Sorry - yes I found the leak in my code. I thought I already said so but = obviously not. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Thu Mar 14 13:48:21 2019 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 AED2215447F4 for ; Thu, 14 Mar 2019 13:48:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C32D48079A for ; Thu, 14 Mar 2019 13:48:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 90AD2260297; Thu, 14 Mar 2019 14:48:18 +0100 (CET) Subject: Re: USB stack getting confused To: "O'Connor, Daniel" Cc: Konstantin Belousov , FreeBSD Hackers References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> <20190309192330.GO2492@kib.kiev.ua> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> <1BBD445B-9A27-4BE7-9B60-04BE0814D7CA@dons.net.au> <1692bbc5-02f4-d0e9-a290-219f045ff55b@selasky.org> <205EC4C0-810B-47C3-A21E-A1EE0A6E3824@dons.net.au> <991d10df-b42d-b557-1b47-37db5bfb4d42@selasky.org> <01E69132-6EB6-4688-ADA2-FF62393F8DFA@dons.net.au> From: Hans Petter Selasky Message-ID: <5693abe3-731b-2532-07c8-933f8d2236f4@selasky.org> Date: Thu, 14 Mar 2019 14:47:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <01E69132-6EB6-4688-ADA2-FF62393F8DFA@dons.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C32D48079A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.80 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.90)[-0.901,0]; IP_SCORE(-2.59)[ip: (-8.79), ipnet: 2a01:4f8::/29(-2.19), asn: 24940(-1.94), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:48:21 -0000 On 3/14/19 2:02 PM, O'Connor, Daniel wrote: > > I suppose that makes sense, but the failure mode was pretty surprising to me. I didn't realise that usbconfig has to open each device to get information on it - I had assumed that it got it via /dev/usbctl or similar. > >> Did you get any further on this issue? > > Sorry - yes I found the leak in my code. I thought I already said so but obviously not. Let us know if you find any more issues :-) --HPS From owner-freebsd-hackers@freebsd.org Thu Mar 14 15:57:09 2019 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 6F78B1547D0E for ; Thu, 14 Mar 2019 15:57:09 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27EF7862F9 for ; Thu, 14 Mar 2019 15:57:08 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-oi1-x235.google.com with SMTP id j10so4791503oij.13 for ; Thu, 14 Mar 2019 08:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gIunQuMtO3bKoETKNb5UgqK2I1sWLOpALgAMdP5t04M=; b=e8+YCSBl+zwzxq8KkZ/XSGRX4nS4HdG1W3IGUv+7HNZ0KjCbIbVeDHUiozG48FYNNd eWN1bkAKZ/BUOlkE0A5IB2VTQI2CuR7OBULtXCWAue+tO7hGC98agrtHKJNqgr+8spRh KJixsDQfe5YqgWlbH5H+ckvARHoT0tyjxb3a/sR/ltUv06fwBQ4+tRtqI08CI/4U6xJL hFVzpKHuFVw+4wDWqSA7iBzapuGezLJx18k8Gq1QtS7zyhW/jkx+Ll+Cgh9DlfKrsBWM +3E4tr+J4SVa7urfZv/JLbVrQtlRH5xi0nF93yFfZ4d7vsfFE4WRNiE8x3tx1g6o6UTL B5uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gIunQuMtO3bKoETKNb5UgqK2I1sWLOpALgAMdP5t04M=; b=YYWJ0qXRzhs90ATH+KAcGkLABQiYhkeJ74TkGI2jVtdKzsSRdIgFt+5/RjhfdwJ/CR h1kNGNxPREskLCHj7HhBTBZCAk1+jDDr9lRQiPrCgkgVY9rsZIO03iIw5tU5dwclpGNd rWmtdSZkIVIvXaYe+yCi7ckvv4VQ8yFyAQujJueaRubv61p7PQpmqae5hfb4kun5X2ow z6lSzbR8fqt/IsBz2eTm0Y3B/ykEiaOEe1IswOTEXMmr0oXSS9/vmVHUHC38Rg4JFn+N DTepvB7qPwg27BJ2FY/plCxjQBmNH5fjg1Y8RrQaCl/1FRbmRvRAmwzfvTLhWEhMPstw CP2g== X-Gm-Message-State: APjAAAVFnBvgSr8fNyMvnsslA/lt3out9tYDO/tnRnWkZcwlonxy9EFC zBRvwnj1UVhREC9/wIa3SrPLBtXBLBRj0VXBtyw= X-Google-Smtp-Source: APXvYqzpvtJ9RY9bpQfy6KJklv2WMQleb4+sKQ382571/y1Q16ZRvsfG4pwMPP8610hyIJrvgh29NG16rPWHALerKxc= X-Received: by 2002:aca:3bd5:: with SMTP id i204mr2488091oia.167.1552579026300; Thu, 14 Mar 2019 08:57:06 -0700 (PDT) MIME-Version: 1.0 References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <885.1552506820@critter.freebsd.dk> In-Reply-To: <885.1552506820@critter.freebsd.dk> From: Alfonso Sabato Siciliano Date: Thu, 14 Mar 2019 16:56:55 +0100 Message-ID: Subject: Re: kern_sysctl.c interface To: Poul-Henning Kamp Cc: Warner Losh , FreeBSD Hackers X-Rspamd-Queue-Id: 27EF7862F9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=e8+YCSBl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2607:f8b0:4864:20::235 as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-6.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[5.3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.86)[ip: (-9.45), ipnet: 2607:f8b0::/32(-2.72), asn: 15169(-2.08), country: US(-0.07)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 15:57:09 -0000 On Wed, 13 Mar 2019 at 20:53, Poul-Henning Kamp wrote: > -------- > In message < > CANCZdfo8v6O+cJqOFu87ReiTTJxQJxX8YZgj8RBygy9Nb_FEEw@mail.gmail.com> > , Warner Losh writes: > > >> > * This interface is under work and consideration, and should probably > >> > * be killed with a big axe by the first person who can find the time. > >> > * (be aware though, that the proper interface isn't as obvious as it > >> > * may seem, there are various conflicting requirements. > >> > >> I think that is a comment I added more than 20 years ago because we, > >> or at least I, wondered if the sysctl-OID tree should be moved to > >> something SNMP-OID compatible. > >> > >> I dont know of anything happening after that. > > > >I suspect after 20ish years the comment can be removed, eh? > > Well, it's still a butt-ugly and inefficient interface... > thank you for your answers, I agree with you, snmp-oid could be a nice project in the future. Regards, Alfonso From owner-freebsd-hackers@freebsd.org Thu Mar 14 16:00:30 2019 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 68A1E154805B for ; Thu, 14 Mar 2019 16:00:30 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 391AB8654A for ; Thu, 14 Mar 2019 16:00:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f174.google.com with SMTP id v3so5294707ljk.9 for ; Thu, 14 Mar 2019 09:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sFC68e3JbPS8KNVY31YqxSVHiWO9g1z09tRtFxhf48I=; b=OrY8Z6g8ytB4u+XLaTmpdyovEHJy05PtaumsjDkqExKFVL6UEt6ZwyE/KaadY4/V6t 7HYM+pCBch3PF5+m+870unsj8swYQ9Io3YUoI14d8g8FzIFXu1RfdNoEnkfG4kVhgzib ytZBw8FVFUmcIoMP0oS03XOmfPL+UnkKbDC/RTbAAn9PyK1+2IQsypJe086+NetLrEqw nY88dldc27zzcolOMKBBjX7X3FJcPjjJyNAwAcNf8q58FJgcJ1KsXu7CWHJ3KRWUYEbi 43l6ez7I+OvEuheg91/JzVTgrm61nxIhwUzkf6UoQrJ/jocYbUxCe0BCm32YqBEOuVke Z1RA== X-Gm-Message-State: APjAAAVR99M5zeh7FFsTBv7XHN8sZ1ajov0Zn77PNsvgW9HMWkK49LLO SwjPDLr6VJDiWLdrtmQtWCv4fRivTPsWImLvzUE= X-Google-Smtp-Source: APXvYqxKQ6xIwXekxuGhC33lFKnLEOtxuIJoKRrcA35EBAwdXRksZ0qw18vi7ue3BiLq6JrONta2ssxw368iYeS4Eb0= X-Received: by 2002:a2e:9dda:: with SMTP id x26mr26819778ljj.53.1552579221940; Thu, 14 Mar 2019 09:00:21 -0700 (PDT) MIME-Version: 1.0 References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <885.1552506820@critter.freebsd.dk> In-Reply-To: From: Alan Somers Date: Thu, 14 Mar 2019 10:00:10 -0600 Message-ID: Subject: Re: kern_sysctl.c interface To: Alfonso Sabato Siciliano Cc: Poul-Henning Kamp , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 391AB8654A X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.174 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-4.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[174.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-1.30)[ip: (-0.45), ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.08), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 16:00:30 -0000 On Thu, Mar 14, 2019 at 9:57 AM Alfonso Sabato Siciliano wrote: > > On Wed, 13 Mar 2019 at 20:53, Poul-Henning Kamp wrote: > > > -------- > > In message < > > CANCZdfo8v6O+cJqOFu87ReiTTJxQJxX8YZgj8RBygy9Nb_FEEw@mail.gmail.com> > > , Warner Losh writes: > > > > >> > * This interface is under work and consideration, and should probably > > >> > * be killed with a big axe by the first person who can find the time. > > >> > * (be aware though, that the proper interface isn't as obvious as it > > >> > * may seem, there are various conflicting requirements. > > >> > > >> I think that is a comment I added more than 20 years ago because we, > > >> or at least I, wondered if the sysctl-OID tree should be moved to > > >> something SNMP-OID compatible. > > >> > > >> I dont know of anything happening after that. > > > > > >I suspect after 20ish years the comment can be removed, eh? > > > > Well, it's still a butt-ugly and inefficient interface... > > > > thank you for your answers, I agree with you, > snmp-oid could be a nice project in the future. > > Regards, > Alfonso This is the first time in a long time that I've read the words "snmp" and "future" in the same sentence. Does anybody still use SNMP anymore? Has it been supplanted yet? -Alan From owner-freebsd-hackers@freebsd.org Thu Mar 14 16:12:06 2019 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 CAF8915487EB for ; Thu, 14 Mar 2019 16:12:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8DB586F1B; Thu, 14 Mar 2019 16:12:04 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf1-x42b.google.com with SMTP id q17so4145666pfh.10; Thu, 14 Mar 2019 09:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DAnYF8mBrx9DqpoL3HZOVtsbHMW0NVFZ7ZM7TXWMjLk=; b=V52SobcPituDgvY80ux/gsfUMEjt3uzVv6SpMtOaAMz1RKTXcYsi6xr6xBHnOVZdlg Zv0wtPXdNnAGXQNE5AxsHViS04oyPm7pcmKUInApjmOxDwj/dXuQi0WE69R9iesUHtJ2 l6wr48//zGCE/y5tuR2Y1eLCn9RXzXseSnB9ivwwpXQ0WIxShi5H4BpXGeJi3CpT2xrc uV4QLntdUxgmZiChjKgE5xAIvgkB16ZZtxTXavLIzV/po7f6P110GrVXqojUu7vEd17S u4i82VN6f3vAKFf/RrYl8SCdTMG2EMI05N5e191B3ierC4BXpukgcvfrchwj2ottq3y7 BXLA== 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=DAnYF8mBrx9DqpoL3HZOVtsbHMW0NVFZ7ZM7TXWMjLk=; b=npy6b6g8DZYpfvtWDRdXWqxC1KZlY3sl3XrWqPVe8JIoNmYdDLofjAM96RCSzEjcB9 e3t4/yv+KTX1FIZoEbFXfo99U1BOzRjDbmK4VJVPV5QLawrIsxHZo8DnngKeNBmBNOko zyGxQAhbtDmLRmVFqtzrCCuKgp2vuWRAz0tRndhCqB8P5sgW+n7FY3mNF7vPRC3IDHDz rg1I+d00hsSsDj619V7DRzAMTAsnGQpdQqjYiNXmaVTzWpZuZhAfevC/hL1smatuAv86 AVleOOmdq+/pcfph7jO8tTRFyHGyQijiT+jF+jVEmhd5j6rYlg0j55wwg+Hx0I3fIQJg A8eA== X-Gm-Message-State: APjAAAWB4R5nH1Dv1X/LKGEmPyT+0ge5Smd7upfZpZuwh1OvFKifGiT2 0uWDGvwOTmGue6lMXNPpBY1ZXWwY X-Google-Smtp-Source: APXvYqw9Qbw2+CF5IeWtOvqq8nV1U8FXSlNS+p2JuJ3ww3Adu/xzsuhbHXfHW6AJi3dimK6cs/b9pA== X-Received: by 2002:a63:6f49:: with SMTP id k70mr15454398pgc.132.1552579923234; Thu, 14 Mar 2019 09:12:03 -0700 (PDT) Received: from ?IPv6:2607:fb90:816e:b537:ac42:c8bc:1f2d:490d? ([2607:fb90:816e:b537:ac42:c8bc:1f2d:490d]) by smtp.gmail.com with ESMTPSA id g12sm16931825pfd.72.2019.03.14.09.12.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 09:12:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: kern_sysctl.c interface From: Enji Cooper X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Thu, 14 Mar 2019 09:12:01 -0700 Cc: Alfonso Sabato Siciliano , FreeBSD Hackers , Poul-Henning Kamp Content-Transfer-Encoding: quoted-printable Message-Id: <0261C3A9-8C7C-4F39-86EE-C448C21A8504@gmail.com> References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <885.1552506820@critter.freebsd.dk> To: Alan Somers X-Rspamd-Queue-Id: A8DB586F1B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=V52SobcP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::42b as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-6.28 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.78)[ip: (-9.04), ipnet: 2607:f8b0::/32(-2.72), asn: 15169(-2.08), country: US(-0.07)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[b.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 16:12:06 -0000 > On Mar 14, 2019, at 09:00, Alan Somers wrote: ... > This is the first time in a long time that I've read the words "snmp" > and "future" in the same sentence. Does anybody still use SNMP > anymore? Has it been supplanted yet? Cisco and isilon do. Facebook doesn=E2=80=99t on their main fleet because it= doesn=E2=80=99t provide fine grained reporting efficiently at scale and for= other reasons. Monitoring systems like Zabbix or Prometheus provide greater value in contem= porary complex systems architectures. Thanks, -Enji (former SNMP advocate)= From owner-freebsd-hackers@freebsd.org Thu Mar 14 19:39:56 2019 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 762E2152925C; Thu, 14 Mar 2019 19:39:56 +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 B1A1C8E56D; Thu, 14 Mar 2019 19:39:55 +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 x2EJdmBX061154 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 21:39:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EJdmBX061154 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EJdkor061152; Thu, 14 Mar 2019 21:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 21:39:46 +0200 From: Konstantin Belousov To: Mark Millard Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] Message-ID: <20190314193946.GJ2492@kib.kiev.ua> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:39:56 -0000 On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: > A basic question and a small note. > > Question's context for it tc->tc_get_timecount(tc) values: > > In the powerpc64 context tc->tc_get_timecount(tc) is the lower > 32 bits of the tbr, in my context having a 33,333,333 MHz or so > increment rate for a machine with a 2.5 GHz or so clock rate. > The truncated 32 bit tbr value wraps every 128 seconds or so. > 2 sockets, 2 cores per socket, so 4 separate tbr values. > > The question is . . . > > In tc_delta's: > > tc->tc_get_timecount(tc) - th->th_offset_count > > is observing tc->tc_get_timecount(tc) < th->th_offset_count > ever supposed to be possible in correct operation, other than > tc->tc_get_timecount(tc) having wrapped around (and so being > newly 0 or "near" 0, no evidence of of having it having been > near 128 seconds or more for my context)? I think yes, there is no reason for current get_timecount() value to have any arithmetic relation to th_offset_count. Look at tc_windup() on how the th_offset_count is calculated. The final value is clamped by the tc_counter_mask, so only lower bits are important (higher bits are evacuated to th_offset or lost due to overflow if tc_windup() was not called soon enough). > > > The note: > > On 2019-Mar-7, at 14:22, Konstantin Belousov wrote: > > > . . . > > + > > + if (__predict_false(delta < large_delta)) { > > I thought that delta for scale*delta and that the overflow case for the multiplication > was when delta>=large_delta . You are right, I fixed this in my repo. > > > + /* Avoid overflow for scale * delta. */ > > + x = (scale >> 32) * delta; > > + bt->sec += x >> 32; > > + bintime_addx(bt, x << 32); > > + bintime_addx(bt, (scale & 0xffffffff) * delta); > > + } else { > > + bintime_addx(bt, scale * delta); > > + } > > . . . > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Mar 14 19:37:39 2019 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 9EFF7152916E; Thu, 14 Mar 2019 19:37:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 73DED8E426; Thu, 14 Mar 2019 19:37:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1518D7E1BC4; Fri, 15 Mar 2019 06:37:28 +1100 (AEDT) Date: Fri, 15 Mar 2019 06:37:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Bruce Evans , Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) In-Reply-To: <20190313190558.GB2492@kib.kiev.ua> Message-ID: <20190315034923.S7485@besplex.bde.org> References: <20190302225513.W3408@besplex.bde.org> <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=UJetJGXy c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=JjY8lKhXyHmvJdNTt2IA:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 73DED8E426 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-6.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[optusnet.com.au]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[optusnet.com.au]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-0.91)[-0.914,0]; IP_SCORE(-2.84)[ip: (-7.76), ipnet: 211.28.0.0/14(-3.57), asn: 4804(-2.84), country: AU(-0.04)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; FREEMAIL_CC(0.00)[optusnet.com.au]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Thu, 14 Mar 2019 19:50:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:37:39 -0000 On Wed, 13 Mar 2019, Konstantin Belousov wrote: > On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: >> [... tscdrift.c] >> I understand this program again. First, its name is actually tscdrift. >> I tested the 2015 version, and this version is still in >> /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to >> the copyright (rgrimes wouldn't like this) and to $FreeBSD$. >> >> The program doesn't actually measure either TSC drift or TSC skew, except >> indirectly. What it actually measures is the IPC (Inter-Process- >> Communication) time for synchronizing the drift and skew measurments, >> except bugs or intentional sloppiness in its synchronization also make it >> give an indirect measurement of similar bugs or sloppiness in normal use. >> >> After changing TESTS from 1024 to 1024000, it shows large errors in the >> negative direction, as expected from either large negative skew or program >> bugs: this is on freefall: >> >> XX CPU | TSC skew (min/avg/max/stddev) >> XX ----+------------------------------ >> XX 0 | 0 0 0 0.000 >> XX 1 | -6148 108 10232 46.871 >> XX 2 | 114 209 95676 163.359 >> XX 3 | 96 202 47835 101.250 >> XX 4 | -2223 207 34017 117.257 >> XX 5 | -2349 206 33837 106.259 >> XX 6 | -2664 213 33579 96.048 >> XX 7 | -2451 212 49242 126.428 > Note that freefall is single-socket. My belief is that due to the > construction of the RDTSC on Intels, it is impossible for the counter > to become scew on single socket. All cores are fed from the same > input signal, and most likely, even read the same uncore counter. > The later is less likely because RDTSC latency is quite low, but there > might be additional hw tricks. The large negative numbers show that even for single-socket, there are really large errors if times are compared without cross-CPU synchronization by the program. Initial skews in hardware are presumably smaller. If the hardware skew drifts then there is a large problem for the software to compensate. I think that is unlikely to be a problem. In a recent commit, mav@ wrote that some Skylake systems only return even values in rdtsc(), and some seem to have a much lower resolution of 180+ (?) cycles. 180 cycles might be from the skew being that much and the hardware refusing to return values closer than that, perhaps even on the same CPU. I already pointed out discarding bits as in TSC-low doesn't work to avoid comparing values that are too close. Rather the reverse. Compensating for skews needs as much accuracy as possible starting with measuring them. > On the other hand, for multi-socket machines, I do not think there is > anything except the external clock signal which would ensure that the > counters stay in sync. > > I tried to imagine is there is any shared hardware on multi-socket Intel > system which would give equal latency for accesses from different sockets, > and it seems that there is no such hardware. Then it is trully impossible > to observe the scew. Yes, it has relativistic problems too. A distance of 1 foot and a speed of 4GHz gives a skew of at least 4 cycles in "absolute" time. > It might be possible to measure round-trip time separately, and then > subtract it from the measured scew. The hardware can do that too, or at least provide some support. I think the "absolute" time must be determined by a distributed clock. Since the system is not usually under much acceleration, the relativistic problems are small. The clock has a knowable constant propagation speed. >> The negative "skews" occur because the server and the clients (1 client at >> a time) read the TSC with uncontrolled timing after the server opens the >> gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs >> on different cores. So when neither thread is preempted, the TSC on the >> server is about 200 cycles in advance. Sometimes the server is preempted, >> so it reads its TSC later than the client (a maximum of about 6148 cycles >> later in this test). More often the client is preempted, since the IPC >> time is march larger than the time between the server opening the gate and >> the server reading its TSC. >> >> The server is also missing fencing for its TSC read, so this read may >> appear to occur several cycles before opening the gate. This gives a >> an error in the positive direction for the reported "skew" (the error >> is actually in the positive direction for the reported IPC time). It >> would be useful to measure this error by intentionally omitting fencing, >> but currently it is just a small amount of noise on top of the noise from >> preemption. >> >> After fixing the syncronization: >> >> XX CPU | TSC skew (min/avg/max/stddev) >> XX ----+------------------------------ >> XX 0 | 0 0 0 0.000 >> XX 1 | 33 62 49161 57.652 >> XX 2 | 108 169 33678 73.456 >> XX 3 | 108 171 43053 119.256 >> XX 4 | 141 169 41289 114.567 >> XX 5 | 141 169 40035 112.755 >> XX 6 | 132 186 147099 269.449 >> XX 7 | 153 183 431526 436.689 >> ... >> I tried some locked atomic ops on 'gate') and mfence instead of lfence >> to try to speed up the IPC. Nothing helped. We noticed long ago that >> fence instructions tend to be even slower that locked atomic ops for >> mutexes, and jhb guessed that this might be because fence instructions >> don't do so much to force out stores. > I am not sure I follow. MFENCE is documented by wording that implies, > without any doubts, that store buffers are flushed before the > instruction is retired. It is not so obvious for SFENCE, which > sounds like a real fence instead of full flush, at least for normal > write-back memory where it is NOP as far as ISA is considered. The program uses LFENCE partly because it is the documented method of serializing rdtsc on Intel CPUs. It only gives serialization on 1 CPU. The locking protocol gives serialization of memory accesses and rdtsc's across CPUs (after I fixed it). Only serialization of the rdtsc instructions -- their results may still be out of order if there is skew and the skew is larger than the IPC time. MFENCE is the documented method for serializing rdtsc on (some?) AMD CPUs, it is just slower on freefall's Xeon CPUs. SFENCE has little affect on freefall's Xeon CPUs. It apparently doesn't serialize rdtsc and is useless for the locking protocol. The locking protocol uses only load_acq, store_rel, fence_acq and fence_rel. These are disguised as simple C operations and compiler memory barriers. FENCE instructions apparently don't work for speeding up the store buffers. > It is known and documented in optimization manuals that locked > operations are much more efficient, but locked ops are only documented > to ensure ordering and not flush. So SFENCE is not suitable as our > barrier. I tried them too. What are they more efficient for? Is it just that they are local while fences are global? > And, the second point, LFENCE there does not work as barrier for IPC. > It only ensures that RDTSC is not started earlier than the previous > instructions. No store buffer flushing is done. Yes, I know that, and tried to find a way to flush store buffers faster. Hmm, unfenced rdtsc is correct and good as an optimization in some contexts. This program is an example. It doesn't matter for monotonicity or for getting an upper bound on time differences if the start time is in the past. >> Similar IPC is needed for updating timecounters. This benchmark indicates >> that after an update, the change usually won't be visible on other CPUs >> for 100+ cycles. Since updates are rare, this isn't much of a problem. >> >> Similar IPC is needed for comparing timecounters across CPUs. Any activity >> on different CPUs is incomparable without synchronization to establish an >> ordering. Since fences give ordering relative to memory and timecounters >> don't use anything except fences and memory order for the generation count >> to establish their order, the synchronization for comparing timecounters >> (or clock_gettime() at higher levels) must also use memory order. >> >> If the synchronization takes over 100 cycles, then smaller TSC skews don't >> matter much (they never break monotonicity, and only show up time differences >> varying by 100 or so cycles depending on which CPU measures the start and >> end events). Small differences don't matter at all. Skews may be caused > It should be more than 100 cycles for inter-socket IPC, but then genuine > RDTSC scew can accumulate much larger than 100, which is my worry. If it can accumulate at all, then it will soon accumulate to a huge value. 1 part per billion drift is 86400*4 cycles/day at 4HGHz. Since we haven't seen this, the hardware must be doing something right (or we don't have the large hardware that has problems). >> by the TSCs actually being out of sync, or hardware only syncing them on >> average (hopefully with small jitter) or bugs like missing fences. Missing >> fences don't matter much provided unserialized TSC reads aren't too far >> in the past. E.g., if we had a guarantee of only 10 cycles in the past for >> the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. >> But IPCs to the same core are 100 cycles faster so the margin is too close >> for ommitting fences in all cases. > I have no idea if RDTSC is allowed to execute before (in program order) > earlier cache miss. If it is, then non-fenced RDTSC would easily give > much larger error than IPC sync delay. Yes, the fences are needed in general. But can we avoid them in the usual case where the program doesn't do any explicit IPCs? clock_gettime() and kernel time calls must be monotonic within a single thread. Hopefully this is automatic when the thread stays on a single CPU (this only requires rdtsc() to be monotonic. This is not as accurate as possible, but the inaccuracies are no worse than ones for delays from cache misses). Time-related IPCs are needed when the thread is moved to a different CPU. Schedulers don't understand this, but I think they do enough locking and delays to give the same effect. They could do 1 fence instruction per context switch to serialize TSCs more intentionally. This is probably faster than 1 fence instruction per timecounter call. Applications that want to compare times across threads should do the IPCs explicitly. This should be in a library function, and the library function can sprinkle fences too. Bruce From owner-freebsd-hackers@freebsd.org Thu Mar 14 20:07:35 2019 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 E7760152A7D6; Thu, 14 Mar 2019 20:07:34 +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 26B1D69BC8; Thu, 14 Mar 2019 20:07:34 +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 x2EK7Rjh068145 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 22:07:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EK7Rjh068145 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EK7RK4068144; Thu, 14 Mar 2019 22:07:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 22:07:27 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Mark Millard , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: TSC "skew" (was: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]) Message-ID: <20190314200726.GK2492@kib.kiev.ua> References: <20190303041441.V4781@besplex.bde.org> <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190305223415.U1563@besplex.bde.org> <20190313190558.GB2492@kib.kiev.ua> <20190315034923.S7485@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190315034923.S7485@besplex.bde.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 20:07:35 -0000 On Fri, Mar 15, 2019 at 06:37:26AM +1100, Bruce Evans wrote: > On Wed, 13 Mar 2019, Konstantin Belousov wrote: > > > On Wed, Mar 06, 2019 at 12:19:38AM +1100, Bruce Evans wrote: > > >> [... tscdrift.c] > >> I understand this program again. First, its name is actually tscdrift. > >> I tested the 2015 version, and this version is still in > >> /usr/src/tools/tools/tscdrift/tscdrift.c, with no changes to except to > >> the copyright (rgrimes wouldn't like this) and to $FreeBSD$. > >> > >> The program doesn't actually measure either TSC drift or TSC skew, except > >> indirectly. What it actually measures is the IPC (Inter-Process- > >> Communication) time for synchronizing the drift and skew measurments, > >> except bugs or intentional sloppiness in its synchronization also make it > >> give an indirect measurement of similar bugs or sloppiness in normal use. > >> > >> After changing TESTS from 1024 to 1024000, it shows large errors in the > >> negative direction, as expected from either large negative skew or program > >> bugs: this is on freefall: > >> > >> XX CPU | TSC skew (min/avg/max/stddev) > >> XX ----+------------------------------ > >> XX 0 | 0 0 0 0.000 > >> XX 1 | -6148 108 10232 46.871 > >> XX 2 | 114 209 95676 163.359 > >> XX 3 | 96 202 47835 101.250 > >> XX 4 | -2223 207 34017 117.257 > >> XX 5 | -2349 206 33837 106.259 > >> XX 6 | -2664 213 33579 96.048 > >> XX 7 | -2451 212 49242 126.428 > > Note that freefall is single-socket. My belief is that due to the > > construction of the RDTSC on Intels, it is impossible for the counter > > to become scew on single socket. All cores are fed from the same > > input signal, and most likely, even read the same uncore counter. > > The later is less likely because RDTSC latency is quite low, but there > > might be additional hw tricks. > > The large negative numbers show that even for single-socket, there are > really large errors if times are compared without cross-CPU synchronization > by the program. Negative numbers are easily explained by the server thread being de-scheduled right after writing the command to memory but before reading RDTSC. > > Initial skews in hardware are presumably smaller. If the hardware skew > drifts then there is a large problem for the software to compensate. I > think that is unlikely to be a problem. It depends. On my SKL-X, BIOS does not sync RDTSC between cores at all, on single-core machine. > > In a recent commit, mav@ wrote that some Skylake systems only return even > values in rdtsc(), and some seem to have a much lower resolution of 180+ > (?) cycles. 180 cycles might be from the skew being that much and the > hardware refusing to return values closer than that, perhaps even on the > same CPU. > > I already pointed out discarding bits as in TSC-low doesn't work to avoid > comparing values that are too close. Rather the reverse. Compensating > for skews needs as much accuracy as possible starting with measuring them. > > > On the other hand, for multi-socket machines, I do not think there is > > anything except the external clock signal which would ensure that the > > counters stay in sync. > > > > I tried to imagine is there is any shared hardware on multi-socket Intel > > system which would give equal latency for accesses from different sockets, > > and it seems that there is no such hardware. Then it is trully impossible > > to observe the scew. > > Yes, it has relativistic problems too. A distance of 1 foot and a speed > of 4GHz gives a skew of at least 4 cycles in "absolute" time. > > > It might be possible to measure round-trip time separately, and then > > subtract it from the measured scew. > > The hardware can do that too, or at least provide some support. I think > the "absolute" time must be determined by a distributed clock. Since the > system is not usually under much acceleration, the relativistic problems > are small. The clock has a knowable constant propagation speed. Well, the reason why I started enumerating the hardware known to me on x86 for this purpose, is because initially I thought that I can sync two threads by reading HPET counter register on both cores, and then do RDTSC on the next tick (say when counter moves to next multiple of 1024 * 1024). But the problem is that HPET is in 'legacy' domain, being attached by direct connection to the socket with BSP, and other socket must access it through the legacy socket. Might be some arithmetic helps there, but I dropped further thinking. > > >> The negative "skews" occur because the server and the clients (1 client at > >> a time) read the TSC with uncontrolled timing after the server opens the > >> gate for this read (gate = 2). The IPC time is about 200 cycles to CPUs > >> on different cores. So when neither thread is preempted, the TSC on the > >> server is about 200 cycles in advance. Sometimes the server is preempted, > >> so it reads its TSC later than the client (a maximum of about 6148 cycles > >> later in this test). More often the client is preempted, since the IPC > >> time is march larger than the time between the server opening the gate and > >> the server reading its TSC. > >> > >> The server is also missing fencing for its TSC read, so this read may > >> appear to occur several cycles before opening the gate. This gives a > >> an error in the positive direction for the reported "skew" (the error > >> is actually in the positive direction for the reported IPC time). It > >> would be useful to measure this error by intentionally omitting fencing, > >> but currently it is just a small amount of noise on top of the noise from > >> preemption. > >> > >> After fixing the syncronization: > >> > >> XX CPU | TSC skew (min/avg/max/stddev) > >> XX ----+------------------------------ > >> XX 0 | 0 0 0 0.000 > >> XX 1 | 33 62 49161 57.652 > >> XX 2 | 108 169 33678 73.456 > >> XX 3 | 108 171 43053 119.256 > >> XX 4 | 141 169 41289 114.567 > >> XX 5 | 141 169 40035 112.755 > >> XX 6 | 132 186 147099 269.449 > >> XX 7 | 153 183 431526 436.689 > >> ... > >> I tried some locked atomic ops on 'gate') and mfence instead of lfence > >> to try to speed up the IPC. Nothing helped. We noticed long ago that > >> fence instructions tend to be even slower that locked atomic ops for > >> mutexes, and jhb guessed that this might be because fence instructions > >> don't do so much to force out stores. > > I am not sure I follow. MFENCE is documented by wording that implies, > > without any doubts, that store buffers are flushed before the > > instruction is retired. It is not so obvious for SFENCE, which > > sounds like a real fence instead of full flush, at least for normal > > write-back memory where it is NOP as far as ISA is considered. > > The program uses LFENCE partly because it is the documented method of > serializing rdtsc on Intel CPUs. It only gives serialization on 1 CPU. > > The locking protocol gives serialization of memory accesses and rdtsc's > across CPUs (after I fixed it). Only serialization of the rdtsc > instructions -- their results may still be out of order if there is skew > and the skew is larger than the IPC time. > > MFENCE is the documented method for serializing rdtsc on (some?) AMD CPUs, > it is just slower on freefall's Xeon CPUs. > > SFENCE has little affect on freefall's Xeon CPUs. It apparently doesn't > serialize rdtsc and is useless for the locking protocol. > > The locking protocol uses only load_acq, store_rel, fence_acq and fence_rel. > These are disguised as simple C operations and compiler memory barriers. > FENCE instructions apparently don't work for speeding up the store buffers. > > > It is known and documented in optimization manuals that locked > > operations are much more efficient, but locked ops are only documented > > to ensure ordering and not flush. So SFENCE is not suitable as our > > barrier. > > I tried them too. What are they more efficient for? Is it just that they > are local while fences are global? They are more efficient in enforcing the memory order as defined by C11 and atomic(9). E.g. 'lock add 0, per-cpu location' is faster than MFENCE but gives the same effects by ordering all writes before it vs. all reads after it. Neither fences nor locked instructions are global. If anything, locked instructions are more global because they must take the cache line into exclusive ownership, so they must invalidate it in all other caches. While fences only affect the local CPU pipeline and potentially wait for some local events like store buffer flushing (but SFENCE could not). > > > And, the second point, LFENCE there does not work as barrier for IPC. > > It only ensures that RDTSC is not started earlier than the previous > > instructions. No store buffer flushing is done. > > Yes, I know that, and tried to find a way to flush store buffers faster. > > Hmm, unfenced rdtsc is correct and good as an optimization in some contexts. > This program is an example. It doesn't matter for monotonicity or for > getting an upper bound on time differences if the start time is in the past. On anything newer than SandyBridge there is RDTSCP instruction which provides the required serialization automatically. > > >> Similar IPC is needed for updating timecounters. This benchmark indicates > >> that after an update, the change usually won't be visible on other CPUs > >> for 100+ cycles. Since updates are rare, this isn't much of a problem. > >> > >> Similar IPC is needed for comparing timecounters across CPUs. Any activity > >> on different CPUs is incomparable without synchronization to establish an > >> ordering. Since fences give ordering relative to memory and timecounters > >> don't use anything except fences and memory order for the generation count > >> to establish their order, the synchronization for comparing timecounters > >> (or clock_gettime() at higher levels) must also use memory order. > >> > >> If the synchronization takes over 100 cycles, then smaller TSC skews don't > >> matter much (they never break monotonicity, and only show up time differences > >> varying by 100 or so cycles depending on which CPU measures the start and > >> end events). Small differences don't matter at all. Skews may be caused > > It should be more than 100 cycles for inter-socket IPC, but then genuine > > RDTSC scew can accumulate much larger than 100, which is my worry. > > If it can accumulate at all, then it will soon accumulate to a huge value. > 1 part per billion drift is 86400*4 cycles/day at 4HGHz. Since we haven't > seen this, the hardware must be doing something right (or we don't have the > large hardware that has problems). I am not sure. Hopefully you are right. > > >> by the TSCs actually being out of sync, or hardware only syncing them on > >> average (hopefully with small jitter) or bugs like missing fences. Missing > >> fences don't matter much provided unserialized TSC reads aren't too far > >> in the past. E.g., if we had a guarantee of only 10 cycles in the past for > >> the TSC and 160 cycles for IPCs to other CPUs, then we could omit the fences. > >> But IPCs to the same core are 100 cycles faster so the margin is too close > >> for ommitting fences in all cases. > > I have no idea if RDTSC is allowed to execute before (in program order) > > earlier cache miss. If it is, then non-fenced RDTSC would easily give > > much larger error than IPC sync delay. > > Yes, the fences are needed in general. > > But can we avoid them in the usual case where the program doesn't do > any explicit IPCs? clock_gettime() and kernel time calls must be > monotonic within a single thread. Hopefully this is automatic when > the thread stays on a single CPU (this only requires rdtsc() to be > monotonic. I am not sure about this part as well. Rather, I expect that it is not true because RDTSC can be reordered with other instructions and then large delays like cache misses would cause significantly wrong measurements even for single-thread. > This is not as accurate as possible, but the inaccuracies > are no worse than ones for delays from cache misses). Time-related > IPCs are needed when the thread is moved to a different CPU. Schedulers > don't understand this, but I think they do enough locking and delays > to give the same effect. They could do 1 fence instruction per context > switch to serialize TSCs more intentionally. This is probably faster > than 1 fence instruction per timecounter call. Applications that want > to compare times across threads should do the IPCs explicitly. This > should be in a library function, and the library function can sprinkle > fences too. > > Bruce From owner-freebsd-hackers@freebsd.org Thu Mar 14 21:06:08 2019 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 071D8152E25F for ; Thu, 14 Mar 2019 21:06:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95A986D1B8 for ; Thu, 14 Mar 2019 21:06:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: b98A80QVM1ndr3O2RIri_T67nc11zhImn7xgJgXJsdFfSBstZLHBxUbkieqniOB sulCwsVOt9gP98cbicIbHoe7Rkm8l0EyvUaEPl95q_TxrLVFqTYN8iFBoebltuS6ST5s34.u8EuX 0w8kex.awM2djXZmfuSvD83uisryI.kZOR6oKlYjFze251hXY7FQ.KL_lslYsRuTKqbNsPHnPZlQ FoBRKenXxpk5SFSqMLeTWlOpGPZ6Oa5kRMNoleJRtX6THg0Vno4lHaHdOHgQQ.0BfglafvA6DT_A 4fY2sxv9dI7hQBB6sYc77Sj6PL4AP79kb.rnifvH4XlSZZdkhDi.61pIsv3VbT0ffYU0bYfr5gru RKgislDUBJg73CzCrF4N9libUUaEdcoMczq67wW7ldervDy6Ie2b3ULRREIlW7VyFxo3fqwS42E2 qRax6DBW_FV_xC4VCM8vYEOiQwjnw1zZjCLW3yOAO_8UlUsYSdr_iRm7SSQPoeubfmixFpETpuWb d7ffs4z2UYyF_WSIGm0LOV2DyRliXel_uErbdBfDS.0tarI_oQJU9u83xa5tiAMoaUYLFR1sVBLA R8QYRH9.c5jtTMfXwmWGmj.qQ2UvEvP7pz3NOvCNzh62mzEaLKitULMswSTYyRRTyAlufuEgajB4 QKHRajgftJLKdEoHhKCS4DHEVvvrmMONHQAau1ndn2aSdlmZuFbriIbTMiVCA5aq2vnGY_0CiR5b BtjdcZEcM6Ut0ZfztH67I_uDMuRZ6n348YVwuShHtfEv7TSzc4qi_cwdnn4hmKamx1IVE6UJEGAd xpIbRMaOynGn6VRRxzClgt8ljVcKZfezWITxugaUC8oxwVsCuE1tobBHqgFLSN1xnlXegW39TImJ sCb7yvfMzR5Cbjjc9fVP8dhb7J1.dbAacpYu9y3TDcfKspE5LIz2KnjsIvkc7YPDFPMS0212EvUc P6STZedz_U8_xbPrJ4pstaA6LGlI6gCj5NhdxDHHmamW5bqvuCOk2TEIM07bQ8eXt0x9ApJ1UDL0 5bPWHJUwyeNH80JGHZRqwgbS8YMeG4HwcgQ0ZkQ_UtHA6jiKcdlzbncT5WXl49BvS09oW51NNmKS .HWr7CA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 21:06:00 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9bb07e4b69e4d33f5b956231b2bf4305; Thu, 14 Mar 2019 21:06:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] From: Mark Millard In-Reply-To: <20190314193946.GJ2492@kib.kiev.ua> Date: Thu, 14 Mar 2019 14:05:57 -0700 Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> <20190314193946.GJ2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 95A986D1B8 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 21:06:08 -0000 On 2019-Mar-14, at 12:39, Konstantin Belousov = wrote: > On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: >> A basic question and a small note. >>=20 >> Question's context for it tc->tc_get_timecount(tc) values:=20 >>=20 >> In the powerpc64 context tc->tc_get_timecount(tc) is the lower >> 32 bits of the tbr, in my context having a 33,333,333 MHz or so >> increment rate for a machine with a 2.5 GHz or so clock rate. >> The truncated 32 bit tbr value wraps every 128 seconds or so. >> 2 sockets, 2 cores per socket, so 4 separate tbr values. >>=20 >> The question is . . . >>=20 >> In tc_delta's: >>=20 >> tc->tc_get_timecount(tc) - th->th_offset_count >>=20 >> is observing tc->tc_get_timecount(tc) < th->th_offset_count >> ever supposed to be possible in correct operation, other than >> tc->tc_get_timecount(tc) having wrapped around (and so being=20 >> newly 0 or "near" 0, no evidence of of having it having been >> near 128 seconds or more for my context)? > I think yes, there is no reason for current get_timecount() value > to have any arithmetic relation to th_offset_count. Look at = tc_windup() > on how the th_offset_count is calculated. The final value is clamped > by the tc_counter_mask, so only lower bits are important (higher bits > are evacuated to th_offset or lost due to overflow if tc_windup() > was not called soon enough). >=20 Okay. Thanks. Just FYI: I asked because in my powerpc64 context I was seeing (in sleepq_timeout) td->td_sleeptimo > sbinuptime() in: if (td->td_sleeptimo > sbinuptime() || td->td_sleeptimo =3D=3D = 0) { /* * The thread does not want a timeout (yet). */ and without such sleeps being rescheduled in that case, those sleeps hang up. My hack to temporarily enable useful operation was to have binuptime avoid tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences, as shown below: . . . do { do { // HACK!!! th=3D timehands; tc=3D th->th_counter; gen=3D atomic_load_acq_int(&th->th_generation); tim_cnt=3D tc->tc_get_timecount(tc); tim_offset=3D th->th_offset_count; tim_wrong_order_diff=3D tim_offset-tim_cnt; } while (tim_cntth_offset; . . . where I experimentally came up with the following for the specific = PowerMac G5 context: u_int const wrong_order_diff_proper_upper_bound=3D 0x14u; // = 0x11 is max observed diff so far HACK!!! I've not hand any hung-up sleeps after that change. Despite being a = hack, this gives evidence that tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences (in binuptime) is involved in the hangups in some essential way for the PowerMac G5 context. I look forward to removing this hack at some point, when things just work for this 2 socket, 2 cores per socket powerpc64 context. But for now the hack is locally useful. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Mar 14 19:57:28 2019 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 C3941152A25E; Thu, 14 Mar 2019 19:57:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3790D680D2; Thu, 14 Mar 2019 19:57:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id CD53848B9FA; Fri, 15 Mar 2019 06:57:17 +1100 (AEDT) Date: Fri, 15 Mar 2019 06:57:16 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Mark Millard , Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] In-Reply-To: <20190314193946.GJ2492@kib.kiev.ua> Message-ID: <20190315064830.F7981@besplex.bde.org> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> <20190314193946.GJ2492@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=nzRIfmPsLuHBWj42Ri8A:9 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 3790D680D2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-Mailman-Approved-At: Thu, 14 Mar 2019 21:12:06 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:57:29 -0000 On Thu, 14 Mar 2019, Konstantin Belousov wrote: > On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: >> A basic question and a small note. >> >> Question's context for it tc->tc_get_timecount(tc) values: >> >> In the powerpc64 context tc->tc_get_timecount(tc) is the lower >> 32 bits of the tbr, in my context having a 33,333,333 MHz or so >> increment rate for a machine with a 2.5 GHz or so clock rate. >> The truncated 32 bit tbr value wraps every 128 seconds or so. >> 2 sockets, 2 cores per socket, so 4 separate tbr values. >> >> The question is . . . >> >> In tc_delta's: >> >> tc->tc_get_timecount(tc) - th->th_offset_count >> >> is observing tc->tc_get_timecount(tc) < th->th_offset_count >> ever supposed to be possible in correct operation, other than >> tc->tc_get_timecount(tc) having wrapped around (and so being >> newly 0 or "near" 0, no evidence of of having it having been >> near 128 seconds or more for my context)? > I think yes, there is no reason for current get_timecount() value > to have any arithmetic relation to th_offset_count. Look at tc_windup() > on how the th_offset_count is calculated. The final value is clamped > by the tc_counter_mask, so only lower bits are important (higher bits > are evacuated to th_offset or lost due to overflow if tc_windup() > was not called soon enough). Yes, it is a standard method to calculate time differences from a possibly- wrapped counter as (finish - start) & mask in unsigned arithmetic, where the counter must be checked before it wraps relative to 'start'. >> The note: >> >> On 2019-Mar-7, at 14:22, Konstantin Belousov wrote: >> >>> . . . >>> + >>> + if (__predict_false(delta < large_delta)) { >> >> I thought that delta> for scale*delta and that the overflow case for the multiplication >> was when delta>=large_delta . > You are right, I fixed this in my repo. >> >>> + /* Avoid overflow for scale * delta. */ >>> + x = (scale >> 32) * delta; >>> + bt->sec += x >> 32; >>> + bintime_addx(bt, x << 32); >>> + bintime_addx(bt, (scale & 0xffffffff) * delta); >>> + } else { >>> + bintime_addx(bt, scale * delta); >>> + } >>> . . . Fixed in my version too. I might have helped break this. I reversed the condition to get the unusual path executed (though not when it overflow), and forgot to undo this. At least the unusual path got checked more). Bruce From owner-freebsd-hackers@freebsd.org Fri Mar 15 14:45:17 2019 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 3EBD2154ACB2 for ; Fri, 15 Mar 2019 14:45:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54D046B32F for ; Fri, 15 Mar 2019 14:45:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f172.google.com with SMTP id t13so8192102lji.2 for ; Fri, 15 Mar 2019 07:45:16 -0700 (PDT) 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 :content-transfer-encoding; bh=1f9dc2I/SkC/aftGDmaUQxlA4x0Mx9YnptCO1QGIudk=; b=LNN3ucaP6+NqLISI+dRb8CotfqsLV/m45tqucJF1DNGOcnhMC0lNjMKXhSqZ3+5x3U yQUxWK3QJ+hTMfk9cctDdfWYnP9kfepNpgbBIUi7bYiuffAaBo9n1mspKGmTgJ5XeJrj Srh858ih/M3EkEO0acP9ed0vsLTaKKLA9QUhgG5hwHxElV86tft2MFtdL4FMQNoN2Ajs Crhu5o0WlgUDg8RDqxthD+4rmPUjfBMw4v5veZ+rM89JsNGiHcim04ay61kYGzbhbKei 5eGc1iUS9M007P0EKjyn+GRowHKdtPqt7o9zaumrj1Oy0MrKMJv7uy9v5z0oH2J5nAMf Fz8w== X-Gm-Message-State: APjAAAU2RlmVxsf92iyqbbkkTsgRMlQhwSUVTeczSB3zqf7JuXH67u9n jGY1aELCMl1EafV2fOK8htT3iLcDV+c+UUCqL4/wNjDB X-Google-Smtp-Source: APXvYqzpr2rkvkljKzqzU4iYkXo1+GQ1z5d74+jka+mxaUGhmAE/Y7jKdEWmfH+f/tsk/pelCObDbmPBxxDhCmMuQUY= X-Received: by 2002:a2e:8456:: with SMTP id u22mr2332226ljh.108.1552661108362; Fri, 15 Mar 2019 07:45:08 -0700 (PDT) MIME-Version: 1.0 From: Alan Somers Date: Fri, 15 Mar 2019 08:44:57 -0600 Message-ID: Subject: VOP_INACTIVE(9): reclaiming space for open but deleted files? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 54D046B32F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.95 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.75)[-0.746,0]; RCVD_IN_DNSWL_NONE(0.00)[172.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.20)[ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.08), country: US(-0.07)]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 14:45:17 -0000 VOP_INACTIVE(9) says that the vop can "be used to reclaim space for =E2=80=98open but deleted=E2=80=99 files". What does that mean? How can y= ou reclaim space for open files? I assume it's just a mistake, but I want to check before I fix the man page. SVN archaeology shows that the line has been present since a mass import of man pages in 1997. -Alan From owner-freebsd-hackers@freebsd.org Fri Mar 15 15:16:19 2019 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 AB957154B7A5 for ; Fri, 15 Mar 2019 15:16:19 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f178.google.com (mail-it1-f178.google.com [209.85.166.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0D7F6C6E3; Fri, 15 Mar 2019 15:16:18 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f178.google.com with SMTP id l15so11374564iti.4; Fri, 15 Mar 2019 08:16:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=9MBioCafJwSEBqGAKOz3W3bms54njjrkYIliqEReZMk=; b=Xdh73Ev1hVlRBkR7p7lk6QNlBFbsjwZnjVXq4SsLBET4QztPKp9IZvExrU+enO9rUK MTcyZ5ZuvCU0bcyDLao6vDk8ZLfoc8ER/ZpEljMFAGX3mVYGodYS23J73OG9WlXvPL60 ZvSu+gwZ6xz7u7/dY11g5Qmj7Yta0bF64Z8qBKDVyLciT1Yy2owapMLZnFPMonqqwiDV symAuU6AOQL+ebnUYDIIUQM5XvW7hvBjB00eWrBhur6SMk8SkWP+EmFG9C+COPjCV9FE dB7ifRKDEPqmq7iPRV3hRRScj9W64bkwS/cjMn4wfFfko68wILez8HFkaCIXv646ZsNN wZCA== X-Gm-Message-State: APjAAAUrbxBGjr7uvhnLzrSzOFkGNQpkfN3YjgtUJNoB8lBIpIIQETC+ +KDLl17UwoZcLcGWj0PXGmQ6ZYfW X-Google-Smtp-Source: APXvYqwAQxrqtSDsQ3cyO0fY4LLH+DXECSiqZdp41qGqS8IanuuX6uvI6wSMKjbP8A+iPyP5kxhFlQ== X-Received: by 2002:a24:2e03:: with SMTP id i3mr2641155ita.5.1552662971543; Fri, 15 Mar 2019 08:16:11 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id y3sm1099628itb.2.2019.03.15.08.16.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 08:16:11 -0700 (PDT) Received: by mail-it1-f177.google.com with SMTP id z124so11385330itc.2; Fri, 15 Mar 2019 08:16:11 -0700 (PDT) X-Received: by 2002:a24:55c9:: with SMTP id e192mr2202005itb.166.1552662970987; Fri, 15 Mar 2019 08:16:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Fri, 15 Mar 2019 08:15:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? To: Alan Somers Cc: FreeBSD Hackers X-Rspamd-Queue-Id: A0D7F6C6E3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MIME_TRACE(0.00)[0:+,1:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[178.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.83)[ip: (-8.13), ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.08), country: US(-0.07)] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:16:19 -0000 Inactive is called when the last =E2=80=9Copen=E2=80=9D goes away. On Fri, Mar 15, 2019 at 7:46 AM Alan Somers wrote: > VOP_INACTIVE(9) says that the vop can "be used to reclaim space for > =E2=80=98open but deleted=E2=80=99 files". What does that mean? How can= you reclaim > space for open files? I assume it's just a mistake, but I want to > check before I fix the man page. SVN archaeology shows that the line > has been present since a mass import of man pages in 1997. > -Alan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Fri Mar 15 15:19:30 2019 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 7A0B0154B8FA for ; Fri, 15 Mar 2019 15:19:30 +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 AC9126C97D; Fri, 15 Mar 2019 15:19:29 +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 x2FFJKZM031795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Mar 2019 17:19:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2FFJKZM031795 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2FFJKbk031794; Fri, 15 Mar 2019 17:19:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Mar 2019 17:19:20 +0200 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD Hackers Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? Message-ID: <20190315151920.GC96870@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:19:30 -0000 On Fri, Mar 15, 2019 at 08:44:57AM -0600, Alan Somers wrote: > VOP_INACTIVE(9) says that the vop can "be used to reclaim space for > ‘open but deleted’ files". What does that mean? How can you reclaim > space for open files? I assume it's just a mistake, but I want to > check before I fix the man page. SVN archaeology shows that the line > has been present since a mass import of man pages in 1997. VOP_INACTIVE() call means that the last use count for the vnode is dereferenced. This can only happen when there is no more open files using the vnode. Now consider what happens when you open file, then unlink it while keeping the file opened. Filesystems usually mark such files with VV_NOSYNC v_vflag, but there are typically other means to determine that there is no name for the inode, like UFS i_nlink. On the last close VOP_INACTIVE() is called (this is not guaranteed but you need to race to not get the call). Then, if the vnode is not reclaimed, it is put on the free list and the allocated blocks and other resources linger until the vnode is reclaim (reclaim absolutely must free space for inodes which cannot be reached). If inactive() frees the resources, the temporal leak is avoided. As example look at UFS_INACTIVE(). If it detects file with effective link count of zero, it resets i_mode and calls ffs_vfree() to free inode. Then the vnode is reclaimed. From owner-freebsd-hackers@freebsd.org Fri Mar 15 16:25:27 2019 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 651F115259CE for ; Fri, 15 Mar 2019 16:25:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5B4B6F4C9 for ; Fri, 15 Mar 2019 16:25:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f172.google.com with SMTP id v10so8476289lji.3 for ; Fri, 15 Mar 2019 09:25:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tfYrLkqSIy5oDf0QgiNcICMtC+mHZsxJWKvf999p+Qk=; b=BO1ui//VaOMVCaej4ky/13Lfv9Qh0KrR3iZzs9mC1UFyP1u/gyw/zyPHie5iyEm/t9 mSq7kDyIS55BJFcNDXOWC7Z7gLqCPNkdq7fboWzBajypg7xnFdhku7mIEsFMqrZWWWiD iATCPmxMPU51LZz47VBVEVFnrGUMEVz7przGH89YMqNuwmBh2Qf9SApdig7azIP5xoDQ 0F7Dlg22ywGnwzyT2kdbZphvA/ZQ+hYWr/E7L1j+2nNUykkzXBkVJ095tL6VGXmNbiuo Gsc4pANXgysq0L5J+zEcVt3FnKncp99MVjE+kXsDPYOU245FyrBVc5Az9PTDUKfLNBvD nrTA== X-Gm-Message-State: APjAAAU3Llq/8/Q7HiupG6bPY/DRRnzXxvPce7kSko9NNAS+D2vUaOyN pfjZK2y7llZrz6dCKyHOA9sImclHD7HqFQm698M= X-Google-Smtp-Source: APXvYqxRsH5x7O9L1oivRg1fdOhoo2ur/0LJSOB/MRnfaQ5Ht7hIZNn4fwMyZVOZgP/7bHx7wrd6vJhcCxk8lJ91L5s= X-Received: by 2002:a2e:9889:: with SMTP id b9mr2450283ljj.29.1552667125051; Fri, 15 Mar 2019 09:25:25 -0700 (PDT) MIME-Version: 1.0 References: <20190315151920.GC96870@kib.kiev.ua> In-Reply-To: <20190315151920.GC96870@kib.kiev.ua> From: Alan Somers Date: Fri, 15 Mar 2019 10:25:13 -0600 Message-ID: Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? To: Konstantin Belousov Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E5B4B6F4C9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.951,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 16:25:27 -0000 On Fri, Mar 15, 2019 at 9:19 AM Konstantin Belousov w= rote: > > On Fri, Mar 15, 2019 at 08:44:57AM -0600, Alan Somers wrote: > > VOP_INACTIVE(9) says that the vop can "be used to reclaim space for > > =E2=80=98open but deleted=E2=80=99 files". What does that mean? How c= an you reclaim > > space for open files? I assume it's just a mistake, but I want to > > check before I fix the man page. SVN archaeology shows that the line > > has been present since a mass import of man pages in 1997. > > VOP_INACTIVE() call means that the last use count for the vnode is > dereferenced. This can only happen when there is no more open files > using the vnode. > > Now consider what happens when you open file, then unlink it while > keeping the file opened. Filesystems usually mark such files with > VV_NOSYNC v_vflag, but there are typically other means to determine that > there is no name for the inode, like UFS i_nlink. On the last close > VOP_INACTIVE() is called (this is not guaranteed but you need to race to > not get the call). Then, if the vnode is not reclaimed, it is put on the > free list and the allocated blocks and other resources linger until the > vnode is reclaim (reclaim absolutely must free space for inodes which > cannot be reached). If inactive() frees the resources, the temporal > leak is avoided. > > As example look at UFS_INACTIVE(). If it detects file with effective lin= k > count of zero, it resets i_mode and calls ffs_vfree() to free inode. The= n > the vnode is reclaimed. Ok, so the man page is talking files which were formerly open but deleted, but are no longer open. I find the wording confusing. It seems to refer to files that are still open but deleted. -Alan From owner-freebsd-hackers@freebsd.org Fri Mar 15 17:01:19 2019 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 5B57B1526A5B for ; Fri, 15 Mar 2019 17:01:19 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B28F70E7A; Fri, 15 Mar 2019 17:01:18 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f179.google.com with SMTP id k74so960258ita.3; Fri, 15 Mar 2019 10:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=2kYSnGKQ+b32tqkPxTipsUGP910N8SD9JLeb813B5r8=; b=LnZ+pqWxbl0vfs0ZZQL4OJ5mEtPL76yRKUsVKdr6xMnsaSRuJGOc2KTtNSi98/XgHv V1X7XEGQ/9Cqh1ThvSm7CRgjry7F20ROOY4VjLAMVFFSXlZJl8sRoh3oGgcg7SmUg3RY iWQZtqxc4+4cLvKHWHs7O6pcCj2XuIMH9F8HPzABn6a/mYQZCRKrmHPklwNC7q/fJNUs 9dxZmpdDbCKawjt8Z37FT4cSxpJOEH7eIazeqwjeq893jChIueVFIqP8CX6I1niRStbj eU+MnxZVbWHKly3nu4vqA8ljMypfREPGm+kQ7zOy8jcIpspWr/ircWcX7qRd7R0Kf9eI 8DbQ== X-Gm-Message-State: APjAAAUUh2WDS3HJ4yBnYai667aXZ/ly13Id4McYRRSWRgBYP7373qIn QLOHxSsJFblpZKL8TVdh+j5l7xOr X-Google-Smtp-Source: APXvYqyUFhDZ5cbpjb0BKHGWfHW5Q0Fvo002I2pB29V63+nTsR6hVH4ulDpotJ3Su2edvJk4jpzndA== X-Received: by 2002:a02:9101:: with SMTP id a1mr3101572jag.50.1552669276821; Fri, 15 Mar 2019 10:01:16 -0700 (PDT) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com. [209.85.166.181]) by smtp.gmail.com with ESMTPSA id o9sm1234190itb.23.2019.03.15.10.01.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 10:01:16 -0700 (PDT) Received: by mail-it1-f181.google.com with SMTP id 188so11981500itb.0; Fri, 15 Mar 2019 10:01:16 -0700 (PDT) X-Received: by 2002:a02:4084:: with SMTP id n126mr2948134jaa.78.1552669275990; Fri, 15 Mar 2019 10:01:15 -0700 (PDT) MIME-Version: 1.0 References: <20190315151920.GC96870@kib.kiev.ua> In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Fri, 15 Mar 2019 10:01:05 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? To: Alan Somers Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4B28F70E7A X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.83 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.85)[ip: (-8.23), ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.08), country: US(-0.07)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 17:01:19 -0000 On Fri, Mar 15, 2019 at 9:26 AM Alan Somers wrote: > Ok, so the man page is talking files which were formerly open but > deleted, but are no longer open. I find the wording confusing. It > seems to refer to files that are still open but deleted. Hi Alan, I totally agree that the wording could be more clear. If you'd like to improve it and want a second pair of eyes on the modified text, feel free to CC me. I appreciate anything that improves the clarity of our VFS documentation, especially given how complex VFS is. (In particular, if Andriy ever deleted https://wiki.freebsd.org/AndriyGapon/AvgVfsSolarisVsFreeBSD , I would be lost :-).) Best, Conrad From owner-freebsd-hackers@freebsd.org Sat Mar 16 00:55:12 2019 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 4A1301536220 for ; Sat, 16 Mar 2019 00:55:12 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE6B98BF02; Sat, 16 Mar 2019 00:55:11 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id z20so9440984ljj.10; Fri, 15 Mar 2019 17:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1DvTi4PnFPzi8cEahF1osCsza6oNRytGRNsM1ssj9Ds=; b=XfOs098Fn3BJxv5j8f1K+WgE0BUe5ZXO+a9IlXpCScN7jg/b+Owfx//JFj9dJtqKWI WyhVAhXhCBkVZ+o+R0ov7cw6enyK7JcjGWegL7UWxMyzzRhrbrwCcQVed6gNB26z+ZO1 gBFEVzNxIqpuSGu3X6HxWU3NOmxE7BDPoFZ9RdTfRs+qE5RxTD9L4wCVnFROMkG4EKR1 2x7yOB1wsrWi3ymp2klm932s5CXJIhRk1LFhYJqE1bLs6gamfMYdTcY2DYtV50ftauQ4 UhGKoxkB6zzquyXaS/DlGJ4FA4GvcBR+Rd1JRbpRraOASctjiMLZhDYNgS1B0he6VFFz Ot1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1DvTi4PnFPzi8cEahF1osCsza6oNRytGRNsM1ssj9Ds=; b=QxtEGzAi4gXLwxecR8phsuJ59ehq+XuLAD0/APh1Wj2hYqt6nLGQH8THc58P02hgC7 awvALYUjHqLlFZedKKn8OyEbNz/Xzdm16d4DkuY+xX+VXtOra7DStrOdqvZTWexjpTR5 P/9EQNjNIVRAnHlRF31kq9IBYodl2GFcrOk4thfImbHLstIbWKqe3ht+ywK6L3beAQEP V96GG+oQgC7KI2zLRS6c6Lah0GVvJbuTw0kNugW9LlotWwU3+WSuMnJx86DCbzkWOygp UDa4Ctk1ed2+3gqlGSW8ZqucVnjESZekLndDoEXCKOwxe/mRR4Ma4o9Fzo+0SHlGRvEM omJA== X-Gm-Message-State: APjAAAWwRRQVxxuls01FeCI1s0/akWoTF3LT3foKoupiW0m63SzbWqY6 wju1lwn0oZ2+XqlWBwcMvtjVo0Lb X-Google-Smtp-Source: APXvYqxvksJBHwj6xXsggiGE6J+9iVwWJ67y76ZIibkqVi17KwQXe4Nsn9maQqA4oOuSSkd6Vn1gBQ== X-Received: by 2002:a2e:5bc5:: with SMTP id m66mr3216861lje.19.1552697709988; Fri, 15 Mar 2019 17:55:09 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:7285:c2ff:fe43:675b]) by smtp.gmail.com with ESMTPSA id n13sm700034lfb.89.2019.03.15.17.55.08 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 15 Mar 2019 17:55:09 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 16 Mar 2019 03:55:07 +0300 To: Konstantin Belousov Cc: Alan Somers , FreeBSD Hackers Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? Message-ID: <20190316035507.02f75436@rimwks> In-Reply-To: <20190315151920.GC96870@kib.kiev.ua> References: <20190315151920.GC96870@kib.kiev.ua> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: AE6B98BF02 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; TAGGED_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 00:55:12 -0000 T24gRnJpLCAxNSBNYXIgMjAxOSAxNzoxOToyMCArMDIwMA0KS29uc3RhbnRpbiBCZWxvdXNvdiA8 a29zdGlrYmVsQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj4gT24gRnJpLCBNYXIgMTUsIDIwMTkgYXQg MDg6NDQ6NTdBTSAtMDYwMCwgQWxhbiBTb21lcnMgd3JvdGU6DQo+ID4gVk9QX0lOQUNUSVZFKDkp IHNheXMgdGhhdCB0aGUgdm9wIGNhbiAiYmUgdXNlZCB0byByZWNsYWltIHNwYWNlIGZvcg0KPiA+ IOKAmG9wZW4gYnV0IGRlbGV0ZWTigJkgZmlsZXMiLiAgV2hhdCBkb2VzIHRoYXQgbWVhbj8gIEhv dyBjYW4geW91DQo+ID4gcmVjbGFpbSBzcGFjZSBmb3Igb3BlbiBmaWxlcz8gIEkgYXNzdW1lIGl0 J3MganVzdCBhIG1pc3Rha2UsIGJ1dCBJDQo+ID4gd2FudCB0byBjaGVjayBiZWZvcmUgSSBmaXgg dGhlIG1hbiBwYWdlLiAgU1ZOIGFyY2hhZW9sb2d5IHNob3dzDQo+ID4gdGhhdCB0aGUgbGluZSBo YXMgYmVlbiBwcmVzZW50IHNpbmNlIGEgbWFzcyBpbXBvcnQgb2YgbWFuIHBhZ2VzIGluDQo+ID4g MTk5Ny4gIA0KPiANCj4gVk9QX0lOQUNUSVZFKCkgY2FsbCBtZWFucyB0aGF0IHRoZSBsYXN0IHVz ZSBjb3VudCBmb3IgdGhlIHZub2RlIGlzDQo+IGRlcmVmZXJlbmNlZC4gVGhpcyBjYW4gb25seSBo YXBwZW4gd2hlbiB0aGVyZSBpcyBubyBtb3JlIG9wZW4gZmlsZXMNCj4gdXNpbmcgdGhlIHZub2Rl Lg0KPiANCg0KSSB3YXMgc2VlbiBhbm90aGVyIHVzZSBjYXNlOiBhcHAgYWxsb2NhdGUgZmlsZSB0 byAxMGdiLA0KbW1hcCgpIDRtYiwgd3JpdGUoKSwgdW5tYXAoKS4uLm1hbnkgdGltZXMuIDEwZ2Ig d3JpdGVkLiBjbG9zZSgpLg0KQW5kIEZyZWVCU0Qga2VlcCBhbGwgMTBnIHJhbSBhcyBpbmNhdGl2 ZS93aXJlZCwgYW5kIGRvdCBub3QgYWxsb3cgdXNlIGl0Lg0KVW50aWxsIGZpbGUgcmVhZGVkIG9y IGRlbGV0ZWQuDQpUaGF0IHdhcyBvbiAxMHgsIHdpdGhvdXQgc3dhcC4NCg== From owner-freebsd-hackers@freebsd.org Sat Mar 16 01:03:31 2019 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 E2C401536B23 for ; Sat, 16 Mar 2019 01:03:30 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5674B8C60F for ; Sat, 16 Mar 2019 01:03:29 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-ed1-x52d.google.com with SMTP id r23so9070872edm.7 for ; Fri, 15 Mar 2019 18:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=mdeMJoUdaqrvZQ0YjMXHsCVSunsy2hHM0V/YQlRhtYM=; b=uai2U5PFSC446JNAr1ERvyiMZPp4h8ssq6ra66l6A1Clv4lzpP0JqQD2wSa8oJCQ60 TdTOC4jGpbzBeiioRJ4LGX03epcMfH9X3KBN3OyttiQucgQkXFXPxqfS0w9LZAxssCkY /QZbDwZQLEqI20xjo1TJkKs9HbiIdLqZ1NT8TwVYTAUTaG7eT+g4oQucbNqyrS6SPQe8 sz98eoJF8A1/NpzKI8Bt0ZhRdSTsAOak3asxGCwFHDzOxNAvaasEEmuafrEtWItsSd7/ Es2tnT3k+iMstDooQkKu6d8knxErFMgbGdLExgD2eSf8CbCjEW/82zkAypQc0+hXOvuO 3ikQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=mdeMJoUdaqrvZQ0YjMXHsCVSunsy2hHM0V/YQlRhtYM=; b=lX4PHHWQR1a0iZtjQdkmAEqyJbMRSYu+oFLLOLMLdCkieIieLgmLlgpkv9GK4JgVRH 4b0H0gNuwc4lOnMSzUp90bhcoFpRfir2MI4FkaCcBex3jGio0VV7sdO9p/oBwrDGNDU+ rmyyLHlceYlN/LQYY2Qt0ToGfGy4VosGh6JYctfbxMMjEhdBilMUAsSYCK+zCkC5MaFn 4+iJigmCbGlZZxev3ehFrvNs13lfr1ndYx8IjEKOaYdcSDK/QCdx/lOBFTySPcd5fHH4 gqKOc4QHJwIdA1DcFfS3oKYvfgfDu7O+bJuWZlOYeGWKSrfSAX9B6gtk47epiS2yZsPu PaVA== X-Gm-Message-State: APjAAAVr+8DNiIGVt5mBnDDFKRbB3lfuoeQVpuYl1yXR5ECloIbs96G4 szndT7kNiMXSWn0uWt2WdzHx3uXL X-Google-Smtp-Source: APXvYqxVenVmPviUOjRnWSYIqtiGWIAQoc2cJGdXG0bfL+hHBoInI4zwObRDltECTAsiQWYOAhP3Xg== X-Received: by 2002:a17:906:31cb:: with SMTP id f11mr3872579ejf.78.1552698207998; Fri, 15 Mar 2019 18:03:27 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:7285:c2ff:fe43:675b]) by smtp.gmail.com with ESMTPSA id e21sm1108887edb.27.2019.03.15.18.03.26 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 15 Mar 2019 18:03:27 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 16 Mar 2019 04:03:25 +0300 To: FreeBSD Hackers Cc: Rozhuk Ivan Subject: mprime fail to start on FreeBSD 12 with clang - why!? Message-ID: <20190316040325.2a489f2b@rimwks> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5674B8C60F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=uai2U5PF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-5.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.72)[ip: (-9.07), ipnet: 2a00:1450::/32(-2.36), asn: 15169(-2.08), country: US(-0.07)]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 01:03:31 -0000 Hello! I maintain math/mprime. It can not start on FreeBSD 12 if it build with clang. If works ok on 11.2. Both 11.2 and 12.0 stable, updated less than 1m ago - same clang version. If it build with gcc8 - it does not depend on gcc runtime, gcc can be removed and mprime continue work. To build with gcc: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236546 Why this can happen? From owner-freebsd-hackers@freebsd.org Sat Mar 16 11:59:58 2019 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 30C431527ED8 for ; Sat, 16 Mar 2019 11:59:58 +0000 (UTC) (envelope-from kib@freebsd.org) 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 8A859856B8; Sat, 16 Mar 2019 11:59:57 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2GBxjjx019025 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Mar 2019 13:59:48 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2GBxjjx019025 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2GBxjOC019024; Sat, 16 Mar 2019 13:59:45 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sat, 16 Mar 2019 13:59:45 +0200 From: Konstantin Belousov To: Rozhuk Ivan Cc: Alan Somers , FreeBSD Hackers Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? Message-ID: <20190316115945.GE96870@kib.kiev.ua> References: <20190315151920.GC96870@kib.kiev.ua> <20190316035507.02f75436@rimwks> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190316035507.02f75436@rimwks> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 11:59:58 -0000 On Sat, Mar 16, 2019 at 03:55:07AM +0300, Rozhuk Ivan wrote: > On Fri, 15 Mar 2019 17:19:20 +0200 > Konstantin Belousov wrote: > > > On Fri, Mar 15, 2019 at 08:44:57AM -0600, Alan Somers wrote: > > > VOP_INACTIVE(9) says that the vop can "be used to reclaim space for > > > ‘open but deleted’ files". What does that mean? How can you > > > reclaim space for open files? I assume it's just a mistake, but I > > > want to check before I fix the man page. SVN archaeology shows > > > that the line has been present since a mass import of man pages in > > > 1997. > > > > VOP_INACTIVE() call means that the last use count for the vnode is > > dereferenced. This can only happen when there is no more open files > > using the vnode. > > > > I was seen another use case: app allocate file to 10gb, Another case of what ? > mmap() 4mb, write(), unmap()...many times. 10gb writed. close(). > And FreeBSD keep all 10g ram as incative/wired, and dot not allow use it. > Untill file readed or deleted. > That was on 10x, without swap. So what is the problem ?