On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote: > In message <[email protected]>, Cy Schubert writes: > > In message <[email protected]>, Cy Schubert writes: > > > In message <YtxAbplpPtLy2Ll1@nuc>, Mark Johnston writes: > > > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote: > > > > > In message <[email protected]>, 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 > > > > > > dtrac > > e > > > > > > command entered, whether it be a fbt or sdt, the following error > > > > > > occu > > rs > > > : > > > > > > > > > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { > > > > > > printf("entering > > > > > > ieee80211_vap_setup\n"); }' > > > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { > > > > > > printf("entering ieee80211_vap_setup\n"); }: > > > > > > "/usr/lib/dtrace/psinfo. > > d" > > > , > > > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is > > > > > > already > > de > > > fi > > > > ned > > > > > > slippy# > > > > > > > > > > > > Old DTrace scripts I've used months or even years ago also fail > > > > > > with > > 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 hope > > > > > > th > > at > > > > > > > > > it's simply something out of sync. But, should it not be, has > > > > > > anyone > > el > > > se > > > > > > > > > > encountered this lately? > > > > > > > > > > A full clean rebuild and installworld/kernel did not change the > > > > > result. > > > > > > > This is a new problem. > > > > > > > > I don't see any such problem on a system built from commit 151abc80cde, > > > > 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 llvm > > 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.
