From owner-freebsd-current@freebsd.org Mon Sep 14 10:05:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE088A03729 for ; Mon, 14 Sep 2015 10:05:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 8BDB01F18; Mon, 14 Sep 2015 10:05:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZbQdW-000Fo5-V6; Mon, 14 Sep 2015 13:05:23 +0300 Date: Mon, 14 Sep 2015 13:05:22 +0300 From: Slawa Olhovchenkov To: Mark Johnston Cc: "Alexander V. Chernikov" , FreeBSD CURRENT Subject: Re: kernel dtrace and current Message-ID: <20150914100522.GS3158@zxy.spb.ru> References: <738721442150603@web6j.yandex.ru> <20150913205333.GA2444@muskytusk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913205333.GA2444@muskytusk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 10:05:26 -0000 On Sun, Sep 13, 2015 at 08:53:33PM +0000, Mark Johnston wrote: > On Sun, Sep 13, 2015 at 04:23:23PM +0300, Alexander V. Chernikov wrote: > > Hello all, > > > > I keep running in > > "dtrace: failed to compile script: "/usr/lib/dtrace/psinfo.d", line 39: failed to copy type of 'pr_uid': Type information is in parent and unavailable" > > message more and more often while trying to trace different -current kernels. > > > > Typically the reason besides that is the number of types embedded in kernel CTF: > > ctfdump -S /boot/kernel/kernel | awk '$0~/of types/{print$6}' > > 37160 > > > > We are bound to 32k of types by CTF format (and numbers above 32k (e.g.w/ highest bit set) are considered "child" types with the information stored in "parent"). > > ctfmerge ignores this fact and instead of yelling emits type indices above 32k. On the other hand, libctf sees such indices while parsing sections and since there is no > > "parent" for kernel, it emits the error above and stops. > > > > Thankfully, r287234 really improved the situation for ctfmerge, but there are still several thousands of identical structures and the total number is close to 32k. > > r281797 and r287234 should have fixed most instances of duplicate type > definitions. At the moment, amd64 GENERIC and GENERIC-NODEBUG have > roughly 25K types in their respective CTF containers; there is a small > handful of duplicates, but at least some of them are legitimate (some > pairs of drivers redefine the same types, e.g. aac(4)/aacraid(4) or > mps(4)/mpr(4)). > > Could you post a config that results in the large number of duplicates > you mention above? > > > > > Personally I solved this by removing unneeded devices from GENERIC-inherited configs. > > I wonder, however if this can be handled better. > > FWIW, removing old drivers from GENERIC would be straightforward if we > could auto-load KLDs based on device IDs. We can just unconditionaly load all current drivers from GENERIC as KLD. This is as good as ever.