<RP>
khem: any idea if the new glibc brings functions pseudo needs to wrap?
tokamak has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
tokamak has joined #yocto
<khem>
RP: good question, there is some change in how it unwinds through ldso but that should be transparent
<khem>
right now, I am just ensuring the builds and ptests so far qemux86-64 is looking ok. Found an issue on 32bit x86 which I fixed https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut&id=549f65d5e0073448229ed8bdf99c4936c2275af6
<khem>
I will take a look into new functions/APIs later today
<khem>
perhaps its not yet in nanbield can you try latest master first ?
<Xogium>
khem: oh, that's not yet on the nanbield branch I take it ?
<Xogium>
right
<Xogium>
master works
<khem>
yeah maybe propose a backport
<Xogium>
how do one go about that ?
<khem>
git cherry-pick into nanbield, test it and send the patch to ml with [nanbield] in subject
<Xogium>
that easy huh ?
<Xogium>
nice
<Xogium>
I am one of those people who's having big trouble with mailing list patch workflows, though. But I'll try my best
<khem>
hmm yeah but ml workflow is what project uses
<Xogium>
khem: huh doesn't seem it got backported to kirkstone either, yet
<khem>
yeah I guess if its not in nanbield then its no where in releases yet I would imagine
<Xogium>
yeah makes sense
ddee has joined #yocto
<ddee>
why is the address sanitizer check failing for arm64 and riscv64 on master and mickledore branches. When I execute a program on qemu it gives the following error: AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0x600000000000,
<Xogium>
ERROR: Revision 1.51.1 was found on multiple branches:
<Xogium>
Please provide the correct branch with -B/--srcbranch
amitk_ has joined #yocto
<Xogium>
there is no branch containing 1.51.1 from what I can see
<Xogium>
it's just a tag
<Xogium>
if I use the sha of this commit with git branch --contains, nothing is returned
jmd has quit [Remote host closed the connection]
sakman has joined #yocto
<dvergatal>
RP: around?
amitk_ has quit [Ping timeout: 255 seconds]
amitk_ has joined #yocto
xmn has quit [Ping timeout: 264 seconds]
ddee has joined #yocto
<ddee>
why is the address sanitizer check failing for arm64 and riscv64 on master and mickledore branches. When I execute a program on qemu it gives the following error: AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0x600000000000,
<ddee>
0xfffffffffffffff4) (tid=389)
<ddee>
[12:42:31 PM] <ddee> <empty stack>
rfuentess has quit [Remote host closed the connection]
mvlad has joined #yocto
florian has joined #yocto
Guest0 has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wicki has joined #yocto
<Guest0>
Hello, is this the right place to ask about kernel in yocto (kirkstone version)? I have problem with memory leak and don't know where to ask
khem has quit [Quit: Connection closed for inactivity]
amitk_ has quit [Ping timeout: 252 seconds]
Guest0 has quit [Quit: Client closed]
amitk_ has joined #yocto
amitk_ has quit [Client Quit]
prabhakarlad has joined #yocto
Kubu_work has joined #yocto
<rburton>
ddee: any program or a program in particular? it could be because the code is buggy...
raghavgururajan has joined #yocto
jonesv has joined #yocto
tleb has joined #yocto
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
leon-anavi has joined #yocto
<ddee>
For any program I try it's the same
<KanjiMonster>
ddee: is this a userspace memory leak? is this a kernel memory leak? what are the symptoms? how do you determine it is one?
<Xogium>
KanjiMonster: wrong person, I think. The one with memory leak left
<KanjiMonster>
ah true
<KanjiMonster>
ddee: sorry for the ping
<ddee>
My question was about address sanitizer check failing for arm64 and riscv64 on master and mickledore branches.
ddee has quit [Ping timeout: 250 seconds]
ddee has joined #yocto
prabhakarlad has quit [Quit: Client closed]
ddee has quit [Quit: Client closed]
ddee has joined #yocto
prabhakar has quit [Ping timeout: 276 seconds]
jmiehe has joined #yocto
Dr_Who has quit [Ping timeout: 252 seconds]
Guest3 has joined #yocto
Guest3 has quit [Client Quit]
ddee has quit [Quit: Client closed]
Guest18 has joined #yocto
Xagen has joined #yocto
prabhakarlad has joined #yocto
prabhakar has joined #yocto
camus has quit [Remote host closed the connection]
<khem>
Xogium: those stalls mean your CPU is very busy to the extent that it can not breathe :)
florian_kc has quit [Ping timeout: 268 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<Xogium>
khem: interesting.
<Xogium>
happens every single time I power up the vm
<Xogium>
khem: the host got no higher than 2.6 load average when booting the vm. This is a ryzen 7 3700x
<Xogium>
so not even the full 16 load average it can take due to having 16 threads
<Xogium>
unless you mean the cpu in the vm itself ?
florian__ has quit [Ping timeout: 268 seconds]
<Xogium>
for the record this is the first time I have this happening
<Xogium>
but its constant
florian__ has joined #yocto
leon-anavi has quit [Quit: Leaving]
florian__ has quit [Ping timeout: 252 seconds]
<khem>
Xogium: is the kernel enabling preeption ? and you only have to starve one thread so one core/thread is enough I think to cause this
<Xogium>
khem: default yocto config
<khem>
hmm I thought you were seeing this on your build host or some such. But it seems you are seeing it on yocto generated image running on ryzen 7 ?
<Xogium>
yes exactly
<Xogium>
sorry, I wasn't clear. I should have specified those were kernel messages in the vm itself
<Xogium>
I got a cool variant too now
<khem>
what is CONFIG_RCU_CPU_STALL_TIMEOUT set to in .config ?
<khem>
hmm on my archlinux system I see its set to 60
<khem>
so perhaps try with that quirk
<Xogium>
interesting
<Xogium>
so it's only pure luck that I never had this before ?
<khem>
possible, depends on workloads though
<khem>
my system is running 6.7 kernel btw. with lot of cores
<Xogium>
yeah, but that one was pretty calm at the moment. Now I'm down to a mere 0.5 load average and it still did it. It's a constant chance of this happening on boot
<khem>
yes boot is quite gruelling on CPU
<khem>
especially systemd doing parallel service starts etc.
olani- has joined #yocto
<Xogium>
I'll try 60, but yeah. First time I ever see that in a vm
<Xogium>
I also get this, but I don't how important that might be
<Xogium>
[ 1.609715] fail to initialize ptp_kvm
<Xogium>
*don't know
rob_w has quit [Read error: Connection reset by peer]
tgamblin has quit [Remote host closed the connection]
olani- has joined #yocto
tgamblin has joined #yocto
tgamblin has quit [Read error: Connection reset by peer]
tgamblin has joined #yocto
<tgamblin>
khem: what's interesting? That link seems to crash my HexChat
<khem>
yeah this link is all about how one should not use hexChat :)
<khem>
well look for x86/entry changes for v6.7 on lkml and you will see the PR
<Xogium>
also, can recipetool get confused when a git tag you're giving it seems to be on no particular branch ? I.e: the tag is a commit all alone, not on master, not on any branch, just standing there
<Xogium>
it's telling me it saw that revision on more than one branch, but then doesn't list any branch and tells me to specify the correct one using -B
<Xogium>
except that, well, git branch --contains with that commit sha returns nothing
<khem>
yeah it can, ideally it should just add nobranch=1 to SRC_URI
<Xogium>
can we pass that manually when running it ?
<khem>
dont know off hand,
<Xogium>
this is kind of a problem here because I'm trying to make a recipe for espeak-ng and kind of struggling with it :D