Date: Mon, 14 Sep 2015 13:05:22 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Mark Johnston <markj@FreeBSD.org> Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: kernel dtrace and current Message-ID: <20150914100522.GS3158@zxy.spb.ru> In-Reply-To: <20150913205333.GA2444@muskytusk> References: <738721442150603@web6j.yandex.ru> <20150913205333.GA2444@muskytusk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150914100522.GS3158>