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>
index | next in thread | previous in thread | raw e-mail
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.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150914100522.GS3158>