Re: DTrace Error

In message <Yt62QYRLicwanWxC@nuc>, Mark Johnston writes:
> On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> > In message <20220724030857.B57FAFC@slippy.cwsent.com>, Cy Schubert writes:
> > > In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert write
> s:
> > > > In message <YtxAbplpPtLy2Ll1@nuc>, Mark Johnston writes:
> > > > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > > > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert 
> writ
> > > es
> > > > :
> > > > > > > I'm not sure if this is because my obj tree needs a fresh rebuild
>  and
> > >  
> > > > > > > reinstall or if this is a legitimate problem. Regardless of the d
> trac
> > > e 
> > > > > > > command entered, whether it be a fbt or sdt, the following error 
> occu
> > > rs
> > > > :
> > > > > > >
> > > > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("enter
> ing 
> > > > > > > ieee80211_vap_setup\n"); }'
> > > > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > > > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psi
> nfo.
> > > d"
> > > > , 
> > > > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is alre
> ady 
> > > de
> > > > fi
> > > > > ned
> > > > > > > slippy# 
> > > > > > >
> > > > > > > Old DTrace scripts I've used months or even years ago also fail w
> ith 
> > > th
> > > > e 
> > > > > > > same error. It's not this one probe. All probes result in the pr_
> gid 
> > > er
> > > > ro
> > > > > r.
> > > > > > >
> > > > > > > I'm currently rebuilding my "prod" tree from scratch with the hop
> e th
> > > at
> > > >  
> > > > > > > it's simply something out of sync. But, should it not be, has any
> one 
> > > el
> > > > se
> > > > >  
> > > > > > > encountered this lately?
> > > > > > 
> > > > > > A full clean rebuild and installworld/kernel did not change the res
> ult.
> > >  
> > > > > > This is a new problem.
> > > > >
> > > > > I don't see any such problem on a system built from commit 151abc80cd
> e,
> > > > > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > > > > modules do you have loaded?
> > > >
> > > > [...]
> > >
> > > chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The 
> > > problem is fixed. I'm creating a special branch that reverts only the llv
> m 
> > > commits since then.
> > 
> > llvm 14 is not the problem. There must be something else after cb2ae6163174
>  
> > that is causing the regression.
>
> Are you able to bisect?  I spent a bit of time trying to replicate the
> problem based on your kernel config, without any luck yet.

How fortuitous is this email. I just rebooted my sandbox again and 
discovered this is related to non-INVARIANT kernels. Enabling INVARIANTS 
"fixes" dtrace. There must be some commit since cb2ae6163174 that affected 
non-INVARIANT kernels. As to which one, I'm not sure yet.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0