dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
agola has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
jpuhlman__ has joined #yocto
jpuhlman_ has quit [Ping timeout: 258 seconds]
otavio has quit [Remote host closed the connection]
vmeson has quit [Ping timeout: 252 seconds]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 265 seconds]
agners has quit [Quit: WeeChat 3.2]
vmeson has joined #yocto
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
dev1990_ has joined #yocto
dev1990 has quit [Ping timeout: 265 seconds]
xmn has quit [Quit: ZZZzzz…]
georgem has quit [Quit: Connection closed for inactivity]
Vineela has quit [Quit: Leaving.]
williamh89 has quit [Quit: Ping timeout (120 seconds)]
xmn has joined #yocto
zyga-mbp has joined #yocto
rob_w has joined #yocto
tnovotny has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
zpfvo has joined #yocto
cquast has joined #yocto
<Ch^W> I was reading about the rcu autobuilder hangs. Those sound vaguely familiar to the behavior we saw in a completely different scenario.
hpsy has joined #yocto
<Ch^W> The cause in that case was periodic pauses at the block I/O level which would hang anything I/O bound - which was basically anything that logged once everything backed up.
<Ch^W> All of our telemetry hung, so we had gaps in the logs, but ftrace data showed the lead-up and recovery pretty clearly.
kayterina has joined #yocto
ilunev has joined #yocto
Schlumpf has joined #yocto
ant_ has quit [Ping timeout: 252 seconds]
leon-anavi has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudx
florian has joined #yocto
xmn has quit [Quit: ZZZzzz…]
goliath has joined #yocto
hpsy has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
<RP> Ch^W: it could well be something like that. The fact ftrace tracks it is useful info
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
rob_w has quit [Quit: Leaving]
vmeson has quit [Ping timeout: 250 seconds]
vmeson has joined #yocto
Schlumpf has quit [Quit: Client closed]
patrick-r has joined #yocto
<patrick-r> hello
<florian> hi patrick-r
<patrick-r> question about the bitbake -c make menuconfig virtual/kernel : once this command is complete it stores its .config and then bitmake <image-name> will rebuild the image which means re-building the kernel
<patrick-r> what I need to know is basically where is this kernel stored? as I need to save the changes for other developpers to use
<florian> just run a "make savedefconfig" - usually the complete .config isn't what you want to hand to other developers.
<patrick-r> from what directory?
RobertBerger has quit [Quit: Leaving]
rber|res has joined #yocto
<mckoan> patrick-r: bitbake -e virtual/kernel | grep ^S=
<mckoan> patrick-r: bitbake -e virtual/kernel | grep ^WORKDIR=
<florian> or use -c devshell
<mckoan> florian: +1
rob_w has joined #yocto
Guest53 has joined #yocto
Guest53 has quit [Client Quit]
p34nutz has joined #yocto
<RP> To answer my question from yesterday, the log discrepancies are either serial port config changing the ACPI or kernel log levels on the console used to collect the kernel messages
kayterina has quit [Ping timeout: 258 seconds]
Schlumpf has joined #yocto
georgem has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<fabatera[m]> out-of-tree module modprobe error (not found in modules.dep)
<fabatera[m]> Running 'depmod -a' on target makes no difference.
<fabatera[m]> (I've hit ENTER too soon..)
<fabatera[m]> Is there any trick to ensure depmod is running on build?
<fabatera[m]> I'm getting out-of-tree module modprobe error (not found in modules.dep)
<fabatera[m]> Running 'depmod -a' on target makes no difference.
<override> hey guys, trying to wrap my head around the intricacies of do_install vs do_install_append. do_install seems to delete a dir in D for me while append isnt. no clue whats going on
<jonesv[m]> I'm not sure what it means, so I don't want to just blindly use m4_pattern_allow. Could it be because of the cross-compilation, so AC_CHECK_LIB does not really make sense?
jonesv[m] has joined #yocto
Spooster has joined #yocto
<mckoan> fabatera[m]: modprobe is for in-tree modules only, try using insmod
<fabatera[m]> mckoan: Actually , on ohter platforms I only need to set my conf files on /etc/modprobe.d/
<fabatera[m]> I have the same recipe working well on many platforms, but I'm only getting this on intel-corei7-64 machine , yocto gatesgarth
williamh89 has joined #yocto
<mckoan> fabatera[m]: that't right
paulg has joined #yocto
zyga-mbp has quit [Ping timeout: 258 seconds]
<RP> Variable SSTATETASKS value changed:
<RP> "do_deploy_source_date_epoch do_package do_package_qa {+do_package_write_deb do_package_write_ipk+} do_package_write_rpm do_packagedata do_populate_lic do_populate_sysroot do_stash_locale"
<RP> The system shouldn't be depending on that :(
zyga-mbp has joined #yocto
<williamh89> just a general linux question... is it possible to see/track which shared library is being used by a python program? (I have a GUI application that uses one of libEGL/libGL/libGLES and I want to know which)
kayterina has joined #yocto
<override> williamh89 you an maybe look at the requirments.txt or setup.py for your app?
<override> can*
camus has quit [Ping timeout: 252 seconds]
<williamh89> hmm requirements doesnt indicate, but I guess I will dig through the setup
<williamh89> thanks!
camus has joined #yocto
patrick-r has quit [Quit: Client closed]
rber|res has quit [Read error: Connection reset by peer]
<override> how I can keep the QA check from running on a binary in D??? I dont want to override the the entire do_install function and do_install_append still endups showing the QA failuire
<override> failure*
<paulg> never did understand the "insane" name ; "sane" or "sanity" or "is_sane" would have made more sense?
<RP> paulg: we have a sanity.bbclass too...
* RP didn't name that one
<RP> (insane)
<paulg> yah, I suppose if I really cared, I could data-mine git, but it was just a passing random observation.
zyga has joined #yocto
<paulg> RP, doesn't really give a hint as to the choice of the name, does it?
zyga-mbp has quit [Ping timeout: 252 seconds]
<RP> paulg: zecke also added the cookie monster to the bitbake datastore :)
sakoman has joined #yocto
<RP> paulg: commits from back then make fun reading, the commit messages are sparse :/
<p34nutz> @RP hi
pidge has joined #yocto
<paulg> kinda makes one wonder what things will look like in another 15y. Assuming people still care about yocto/linux - the whole world might be running google fuschia by then, despite vmeson 's best efforts to convert everything to rust...
davidinux has quit [Ping timeout: 265 seconds]
<override> smurray: thanks for link. Will take a look
davidinux has joined #yocto
<RP> hi p34nutz
<p34nutz> nice to meet you RP
<p34nutz> davidinux invited me to join here
davidinux has quit [Ping timeout: 252 seconds]
<RP> p34nutz: I had started to look at some of the presentations on what you've been working on, good to meet you
davidinux has joined #yocto
<p34nutz> RP: yes, it's a hard work, since we have a single yocto project with a lot of variants (target machines, image "flavours", etc.). We're basically trying to reduce complexity (and leverage others' work wherever we can)
<p34nutz> RP: I'd be glad to receive your feedback (and provide some feedback to you, also :) )
<override> RP so i can just inherit insane into my recipe, and put WARN_QA = "arch" ?
<yates_work> i am still trying to chase down the problem "csky-poky-linux-ld: cannot find libgcc.a: No such file or directory" for my machine's core-image-minimal build. i've found multiple libgcc.a's: http://paste.ubuntu.com/p/FfmxnTgf9h/
<RP> override: insane is generally already inherited and you probably want INSANE_SKIP = "arch"
<yates_work> so which one of these should be issued as a --sysroot to the linker?
<RP> p34nutz: I think you should probably "present" what you're doing on the mailing list, its more about the community's collective view on changes than mine specifically
<yates_work> is there an option i can issue to ld to cause it to emit all its search paths?
<override> Thanks RP: .. That arch check was really driving me insane
<yates_work> it could be that it's already using a valid sysroot but the libgcc.a build is not placing it in that sysroot
<yates_work> khem: any thoughts on this?
<fray> link w/ gcc add -v [if I remember correctly], the linker paths will be shown
<yates_work> btw, this error is arising when the kernel is being built, when vmlinux.o is being linked
<yates_work> fray: well the compile and link are done separately, but et me try -v with the linker. thanks.
<fray> You can still link with gcc
<fray> 'ld' itself won't have the libgcc.a path for instance.. only gcc has that
xmn has joined #yocto
<perdmann_> Hi, i created a recipe which creates a shared Object. If i built with yocto everything looks fine, if i built the SDK my so file is not in there.
<fray> https://pastebin.com/MMqN2hPp -- see down a bit it shows you the linking path.
<perdmann_> Sometimes i have the feeling that shared objects are only created into the SDK if i really use them in a makefile. Is this some kind of yocto magic or did i just imagein this?
<fray> you can use gcc as a link only path if you need to do it in separate runs
<yates_work> fray: this is the way the kernel makefile is designed - it separates the compiles from the final "ld"-based link
<yates_work> sure, i could try to change all that, but something more basic seems to be messed up, like libgcc.a not being placed in the proper sysroot
<fray> If you run ld directly (in any context) then YOU are responsible for passing the locations of the gcc based link files..
<fray> When the kernel builds, it does NOT use a sysroot
<fray> Also typically libgcc.a is NOT in the sysroot, as it's a static library.. the libgcc.a, is part of the gcc path set. (Yes it'll be in the sysroot if you have target gcc and such....)
<fray> whatever you are building for, if libgcc.a is needed by the kernel then you need to pass the path to libgcc.a as part of your ld run
<fray> The few architectures I've used before that needed libgcc.a when building the kernel had code that would ask gcc where libgcc.a is, and then use that full path during link
davidinux has quit [Ping timeout: 268 seconds]
<fray> Have you tried this yet?
<fray> gcc -print-libgcc-file-name
<fray> /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a
<fray> again, this should give you the _exact_ path to the libgcc.a you need, which is what the kernel should already be doing. Then you pass that into ld directly
davidinux has joined #yocto
<yates_work> "<cross>-gcc -print-libgcc-file-name" returns "libgcc.a"
<yates_work> no path, just the file name
ochredoke has joined #yocto
<yates_work> fray: was there something else you were asking me to try?
<yates_work> the -v results: http://paste.ubuntu.com/p/3ZXWZMZYSJ/
<fray> with the -v you need to compile something, or alternatively just run
<fray> gcc -print-search-dirs
<fray> But if -print-libgcc-file-name comes back with just 'libgcc.a', then most likely you have something wrong in your environment.
<fray> That is the default response when it can't actually find libgcc.a in your environment anywhere..
<p34nutz> RP: you mean the general mailing list? https://lists.yoctoproject.org/g/yocto
<fray> are the paths in the libraries: valid?
<fray> Calling 'gcc' directly without the tuning args as well will cause paths and sysroot to be unavailable in many cases, are you using the regular target CC?
<fray> The other thing, the kernel does not typically use libgcc.a, so I believe it's not always going to be in your path unless you add a depends to the right component.
<fray> If you look at linux-yocto.inc, the three architectures that need libgcc are aarch64, nios2 and arc, so the following existed:
<fray> linux-yocto.inc:DEPENDS_append_aarch64 = " libgcc"
<fray> linux-yocto.inc:DEPENDS_append_nios2 = " libgcc"
<fray> linux-yocto.inc:DEPENDS_append_arc = " libgcc"
<fray> without that libgcc won't be available at all, which also could explain the -print-libgcc-file-name issue
<yates_work> fray: two paths seem to be invalid: http://paste.ubuntu.com/p/fnJg4xhWDj/
<fray> If this is a new architecture, or you are enabling an option that now requires libgcc then you need to add that as a DEPENDS to your kernel build
<vmeson> paulg: just skimming history but FYI Fushcia has componets written in Rust :)
<fray> I believe those paths are where it would be installed typically
<fray> zedd, I offered a suggestion, but I don't know enough about the issues to proceed...
<fray> 'er wrong window.. but anyway
<zedd> yup! sounds good.
mckoan is now known as mckoan|away
<yates_work> fray: i already have this in my kernel recipe: DEPENDS_append = " libgcc"
wesm has quit [Ping timeout: 250 seconds]
<yates_work> khem: suggested that a few days ago
<fray> yes, that is certainly the main requirement. without that it won't be there at all..
<fray> so where in the _two_ sysroots, recipe-sysroot-native and recipe-sysroot is 'libgcc.a'? If it's not in either, then that is your issue -- whatever you are targeting doesn't have a static libgcc.a
<yates_work> fray: hang on, checking
<fabatera[m]> mckoan: I guess busybox's modprobe doesn't support modprobe.conf install/remove
<fray> fabatera[m]: it didn't many years ago, but I rarely use busybox for anything like that anymore
camus has quit [Ping timeout: 268 seconds]
camus1 has joined #yocto
<yates_work> fray: it is in recipe-sysroot: http://paste.ubuntu.com/p/7Bf4rXcnmD/
<fray> ok, there is your link path.. but I suspect due to NOT calling gcc with --sysroot=, you aren't getting a valid response
<yates_work> but note the libraries reported by --print-search-dirs do not include that
<fray> thats because your call to the compiler did not include "--sysroot=..../recipe-sysroot"
<fray> this is part of the normal $CC
camus1 is now known as camus
<fray> you are going to have to look at how aarch64/nios2/arc had the call to get the libgcc.a path
cquast has quit [Ping timeout: 250 seconds]
<fabatera[m]> fray: yes, and looks like will stay not supporting. I'm trying to build with the minimum possible provided with the "core-image-minimal", but I guess I'll need to install modprobe from another source.
<yates_work> i am confused because, as i stated earlier, the kernel makefile performs the compile and link in separate steps. so why would adding "--sysroot=..../recipe-sysroot" result in the linker finding the path?
tnovotny has quit [Quit: Leaving]
<yates_work> so why would adding "--sysroot=..../recipe-sysroot" IN THE COMPILER INVOCATION result in the linker finding the path?
<fray> If you call the linker directly, you MUST pass the full path to libgcc.a, to get the path you need gcc to tell you what the path is.. and to do that you need the sysroot..
<fray> foo-gcc --sysroot=.../recipe-sysroot -print-libgcc-filename
<fray> then use the output of that as the libgcc to link against when calling ld
<fray> you can NOT just link using 'libgcc.a' it won't work, as ld has no in-built paths to search
<fray> aarch64, nios2, and arc should already being doing this "somewhere"
ant_ has joined #yocto
Guest57 has joined #yocto
<fray> I'm not 100% sure of this, but I know the linux-yocto has two different CC arguments.
<fray> (this is in bitbake scope, not kernel makefile scope)
<fray> CC = <cross>-gcc --sysroot=<path>
<fray> KERNEL_CC = <cross>-gcc
<fray> so when the kernel makefile is called, it's typically called using CC=KERNEL_CC
<fray> but I THINK CC is still available, so you can just do "${CC} -print-libgcc-filename" in your recipe, capture the output and pass that into the system as the libgcc.a.. again, aarch4/arc/nios2 should ALREADY be doing this, so figure out what and how they do it and mathc it
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wesm has joined #yocto
<yates_work> mathc it?
<yates_work> match
<yates_work> fray: ok very good - let me work on this. very very much appreciate your help
<fray> yes match that
<yates_work> ptf
Guest57 has quit [Quit: Client closed]
_whitelogger has joined #yocto
vquicksilver is now known as Guest6275
lexano has joined #yocto
manuel1985 has joined #yocto
Schlumpf has quit [Quit: Client closed]
<manuel1985> Can two builds use the same build & tmp directory? I remember mckoan already gave me an answer weeks ago, but I failed to write down. I think he said "only if they're of the same architecture", which puzzled me.
bjobjo_ is now known as bjobjo
bjobjo has quit [Changing host]
bjobjo has joined #yocto
<RP> sakoman: you could probably prove it by comparing a pcmanfm build with the current buildtools used on dunfell vs master
ecdhe has joined #yocto
ecdhe has quit [Changing host]
<sakoman> RP: thanks will look at that after I sort out the issues with the python upgrade series
<sakoman> RP: hmmm . . . probably not that since dunfell has that commit: https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=fb8063147c1afc8f2554597a0e40de6659014bb6
zyga has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zpfvo has quit [Remote host closed the connection]
<RP> sakoman: did you update the buildtools tarball used on the autobuilder though?
<sakoman> ah, perhaps not . . .
kayterina has quit [Remote host closed the connection]
manuel1985 has quit [Ping timeout: 246 seconds]
manuel1985 has joined #yocto
manuel1985 has quit [Remote host closed the connection]
dtometzki has quit [Read error: Connection reset by peer]
manuel1985 has joined #yocto
dtometzki has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
rcw has joined #yocto
<Saur> Why does BAD_RECOMMENDATIONS += "foo" prevent a recipe from doing RDEPENDS_${PN} += "foo"? It results in an error from dnf with "package foo... is filtered out by exclude filtering". Without having looked at the code, this seems wrong to me.
Vineela has joined #yocto
<perdmann_> Hi, i created a recipe which creates a shared Object. If i built with yocto everything looks fine, if i built the SDK my so file is not in there.
<fabatera[m]> I just removed MODPROBE from busybox config. Which package should I install to have the "full" modprobe?
<perdmann_> How does the so resolver work?
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 256 seconds]
WadeBerrier[m] has joined #yocto
leon-anavi has quit [Quit: Leaving]
zyga-mbp has joined #yocto
williamh89 has quit [Quit: Client closed]
wing0 has joined #yocto
<zedd> fabatera[m]: should come from the kmod recipe.
<override> hey can anyone help me understand what going on here - https://pastebin.ubuntu.com/p/5MKZzyTmPF/
v0n has quit [Ping timeout: 272 seconds]
<override> should i just inherit setuptools3 or what
<override> nvmd that already there
<override> here is the recipe - https://pastebin.ubuntu.com/p/Gdg9VRnFkz/
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Ping timeout: 252 seconds]
p34nutz has quit [Ping timeout: 246 seconds]
<override> anyone ^ khem: ?
<Ch^W> override: Add DEPENDS += "${PYTHON_PN}-setuptools-scm-native" to your recipe.
<Ch^W> RP: (assuming your kernel is configured for it) We found that turning on /sys/kernel/debug/tracing/events/block/ block_rq_insert and block_rq_complete was enough to see the issue at that level.
<override> thanks Ch^W, let me try that
<Ch^W> RP: And use /sys/kernel/debug/tracing/trace_pipe to read the data. It is much simpler that way. Or use a tool or whatever. You can also throw it into netcat to get it offboard quickly.
<Ch^W> We built progressively more sophisticated tools to meaure the insert and complete gap, etc. I am sure we probably missed some existing tools that would have made analysis easier. But we were receiving a lot of heat to get the problem fixed.
<override> thanks Ch^W. That works
<override> what is that tho?
<Ch^W> override: Look _very_closely at the error output you posted here https://pastebin.ubuntu.com/p/5MKZzyTmPF/. the clues are right there.
<override> im trying to figure out what setuptools-scm-native is to begin with
<Ch^W> It is the native version of setuptools-scm
<Ch^W> And setuptols-scm is a build dependency on your particular python libary.
<override> got it
<Ch^W> override: Anything with a trailing "-native" is a tool that needs to run _on_ your current machine instance to build your recipe. Without the -native, it is specific to the machine you are building for.
<override> and the tool is just coming from the tar file?
<Ch^W> override: Which tool are you referring to? I can interpret that several ways.
<override> this setuptools-scm-native tool
<override> the one we just added the DEPENDS for to make the recipe work
<override> and how do u underline text in irc?
<override> I can look up the latter
<Ch^W> The setuptools-scm is a garden variety build dependency. The recipe for it is found in openembedded-core/meta/recipes-devtools/python/python3-setuptools-scm
<Ch^W> override: Just put an underscore before and after a word to underline it -> _underlined_
<override> I see.. _nice. garden variety build dependency - adding that to my lists of things to read up on..
<override> more like _nice_
<Ch^W> Sorry "garden variety" is my word for it. As long as you add openembedded-core/meta to your list of bblayers, you will get all of those deps without doing anything other than adding them to your DEPENDS list.
<override> git it
<override> very cool. Thanks
<Ch^W> override: 👍🏼
florian has quit [Ping timeout: 246 seconds]
florian has joined #yocto
Vonter has quit [Ping timeout: 258 seconds]
<ecdhe> I have a linux source tree that I need to "patch" by copying in a large folder full of defconfigs. Is there a SRC_URI formulation that will do this cleanly? Or do I need to implement a do_patch_append to copy from ${WORKDIR} to ${S}?
<ecdhe> *from ${S} to ${WORKDIR}
<RP> Ch^W: thanks! we just need a reliable way to reproduce the issue now. Did you find a reliable way to cause an IO glitch like you mention for testing?
<Ch^W> RP: Sleeping in the lab was generally a reliable way to catch the issue ;)
<Ch^W> RP: Jokes aside, we _think_ the problem had to do with industrial SSDs with a bias for writes over reads, so big reads caused the controller some issues resulting in backups.
pidge_ has joined #yocto
pidge has quit [Read error: Connection reset by peer]
<Ch^W> Our solution was to refactor all of our realtime threads to avoid any writing. Writes were deferred to theads that could survive block level hangs.
<Ch^W> Our _hope_ is that bumping from kernel 4.18.20 to 5.10.x will also produce some relief. But we are months away from getting real data on that.
<RP> Ch^W: Interesting. In our case it seems to be related to load from builds on our autobuilders but we're not sure which load component is the problem or how to replicate that reliably
<RP> Ch^W: did you find any kernel stats like iostat that could report on a problem "in progress"?
<Ch^W> RP: Those would definitely _hammer_ block I/O hard. Are you guys using an IOMMU?
wing0 has quit [Quit: WeeChat 3.1]
<Ch^W> RP: It was very hard to get that data. We regularly saw hangs <= 7 seconds, and about once every 12 hours it would hit over a minute which is when the SHTF.
<Ch^W> RP: Ultimately we were able to find the threads that were hanging and dropping RT data, which is where we resolved it as described above.
<RP> Ch^W: I don't think there would be IOMMU involved, or at least not much but I'm not entirely sure
<RP> Ch^W: We had data earlier today suggesting it took 302seconds to copy a 1GB file to a tmpfs :/
<Ch^W> RP: Yeah, that smells like a smoking gun. Your ftrace data would be _very_ instructive there.
<RP> Ch^W: the trouble is knowing where/when we need that data and having the privs to run it
<Ch^W> Just make sure you are offloading it via a port and not making the mistake we initially made and store it to disk. *sigh* live and learn
<RP> Ch^W: but an idea of what we could look at is a start
<RP> Ch^W: ironically, the copy to tmpfs is to avoids IO blocking!
<Ch^W> RP: Except it does not. It all uses the page cache.
<RP> Ch^W: well, if it is in the page cache (which tmpfs is by definition), it shouldn't stall on IO there?
<Ch^W> So you are almost certainly hamering the page cache too much.
<Ch^W> RP: You are running these all in VMs, right?
<RP> Ch^W: no, the autobuilders are "baremetal" distro installs. It is qemu VMs we use for testing running on those systems which crash/hang
<RP> the io load is from the host OS
<Ch^W> BRB
rob_w has quit [Read error: Connection reset by peer]
<Ch^W> RP: Ah ok, excuse the IOMMU comment then. Not needed for bare metal.
Tokamak has joined #yocto
<Ch^W> RP: The ftrace data would tell you if your problem is I/O bound rather than CPU bound. Which is super useful. If you see a transaction enter, but not complete for a long time, then it gives you evidence that your problem is block level.
<Ch^W> The fact that you can ping, but not spawn a new SSH process means your CPU is still processing stuff in kernel space. So it has a block layer / page cache smell to it.
<ecdhe> I copied a kernel recipe from another layer upon which my layer depends. I changed the version part of the filename from _5.10 to _5.13-rc6 and updated it to pull from the corresponding git branch. The recipe works perfectly when it's in the original layer (it depends on a files/ directory there) but when I move it to my build fails -- the search paths are all relative to the layer it's in. Given that the
<ecdhe> upstream layer (which I don't want to modify) does not provide a .bbclass that I can inherit, is there any way I can update the search paths of my copied recipe to include the meta-upstream-layer/recipes-kernel/linux/files folder instead of searching only within my layer?
<Tokamak> howdy. new to channel. fiddling with yocto again after a several year break. attempting to follow the quick-start guide to remember the steps and I didn't expect to be getting a seemingly trivial error: "Timeout while waiting for a reply from the bitbake server (60s)". thoughts on how to dig in?
<Ch^W> Tokamak: Maybe start with a ping?
<Tokamak> honesly have no idea what 'bitbake server' it is even trying to touch
<Tokamak> i assume its a local process..?
<Ch^W> Tokamak: Do you have any stuck bitbake processes in your process list?
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 258 seconds]
<Tokamak_> i think i was being too crafty for my own good. forgot that i moved the src folder since running oe configure script... seems that paths definitely are not relative to current poky source directory
<RP> Tokamak: sounds like a hung bitbake process
<Tokamak_> thanks for the thoughts RP and Ch^W, i'll try to not get further hung up on the trivial things :P
<ecdhe> I updated SRC_URI to point to a newer kernel (5.13-rc6) and renamed the .bb to the new version. I can select it by updating PREFERRED_PROVIDER_vitual/kernel
<ecdhe> The recipe works as long as it's in the TI layer directory
<ecdhe> But I want to capture these changes in my own layer
<ecdhe> There is a lot of shared code in .inc files already, and these include from my layer as expected because the meta-ti layer is in the search path
<RP> ecdhe: can't you just set the FILESPATH to include the other location?
<ecdhe> RP: I'll look that up! Can I do it relative to another layer?
<ecdhe> I mean, can I avoid an absolute path?
<RP> ecdhe: I'm less sure about how you'd figure out where the other layer is :/
<RP> ecdhe: you want FILESEXTRAPATHS
<ecdhe> It's always called meta-ti... but you're right, bitbake can support layers above the poky/ directory, can't it?
<RP> ecdhe: bitbake doesn't care where they are
<ecdhe> I'm guessing there isn't a good way to retrieve a layer's path based on it's name. So I'm going to have to assume that all layers are installed within the poky/ dir
<smurray> if this is wrt the inc files in recipes-kernel/linux in meta-ti, perhaps just prepend recipes-kernel/linux/ in your recipe in your layer
<smurray> I was looking at a layer (meta-sancloud) that does that today
<ecdhe> smurray: it's about the files/ dir in meta-ti/recipes-kernel/linux/
<ecdhe> smurray: the .inc files are including fine
<ecdhe> smurray: but files/cmem.dtsi can't be found
<RP> Figuring out a way of saving paths to layers would be nice, its been something I wonder about periodically
<smurray> ah. You'll need to build up a path from COREBASE or the like to add to FILESEXTRAPATHS
<ecdhe> RP: introspection of bblayers.conf could do the trick
<ecdhe> smurray: COREBASE is the root of poky?
<smurray> ecdhe: it's the meta directory in oe-core or poky. There might be something else more convenient, plus there's the issue of baking in layer location, which is less than ideal
nohit has quit []
nohit has joined #yocto
<smurray> ecdhe: using something like ${THISDIR}/../../../meta-ti/recipes-kernel/linux/files in the recipe is another option, but has the same problem
<ecdhe> smurray: ${COREBASE} is cleaner, I appreciate that one
<ecdhe> I need to study the BB recipe env vars
<smurray> it might be possible to cook up something with a block of anon python that parsed it out of BBPATH
<smurray> not amazing either, but maybe a bit more robust
<ecdhe> smurray: I don't understand yocto well enough to get that python to run ahead of teh FILESEXTAPATHS evaluation
<smurray> ecdhe: you'd probably want to d.appendVar (or prependVar) in the python block
rcw has quit [Quit: Leaving]
<RP> zedd, paulg, abelloni: I have a more interesting rcu traceback: https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2252/steps/14/logs/stdio
<RP> specifically "BUG: scheduling while atomic: swapper/3/0/0x00000002"
<ecdhe> smurray, RP: thanks for your help, completely squashed that bug
<smurray> ecdhe: cool
<jonesv[m]> In my recipe, I want to do `include files/${MACHINE}/my_file.inc` to set the KERNEL_MODULE_AUTOLOAD per machine. Is that a bad idea?
Vonter has joined #yocto
florian has quit [Ping timeout: 256 seconds]
<ecdhe> jonesv[m]: seems reasonable
* RP suspects tomorrow I need to trigger some rcu stalls and see if the kernel does actually recover or crash
<Ch^W> RP: If you grab ftrace data, I am happy to give it a peek. Recommend you keep track of when acquisition starts since the timestamps are relative.
<RP> Ch^W: thanks, I don't think we can capture data accurately enough at the right time currently unfortunately :(
<Ch^W> RP: Even offloading it via netcat to a stable platform?
<Ch^W> it is a simple pipe interface.
<RP> Ch^W: the trouble is the huge amount of data our autobuilders work with during builds
<RP> Ch^W: this issue is rare, maybe 1 in 200 qemu VM runs and we can't enable ftrace on every worker starting them
<jonesv[m]> and one more thing: meta-raspberrypi says that I should set `RPI_USE_U_BOOT = "1"` in my local.conf. Can I do that in the image bb recipe instead?
<ecdhe> jonesv[m]: I believe so
florian has joined #yocto
<jonesv[m]> I am not completely clear about the link between local.conf and the rest. Like if I set it in both places, which one will prevail? local.conf?
<ecdhe> jonesv[m]: there are several options people like to set in local.conf that I think are more appropriate for layers
<jonesv[m]> right, got it
<ecdhe> jonesv[m]: look into layer priority... I'm not sure what the priority of local.conf is but I think in the past local.conf has overridden my layers (please confirm this instead of taking my word)
<jonesv[m]> Also I don't really feel like versioning my local.conf, but typically setting meta-raspberrypi to use u-boot seems like something I want to version :)
<ecdhe> ^^^ exactly -- I want to version control my layer's required options, not have extra documentation
Vonter has quit [Ping timeout: 252 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
florian has quit [*.net *.split]
nohit has quit [*.net *.split]
Tokamak_ has quit [*.net *.split]
pidge_ has quit [*.net *.split]
WadeBerrier[m] has quit [*.net *.split]
ChanServ has quit [*.net *.split]
prabhakarlad has quit [*.net *.split]
marka has quit [*.net *.split]
ecdhe has quit [*.net *.split]
sakoman has quit [*.net *.split]
Spooster has quit [*.net *.split]
jpuhlman__ has quit [*.net *.split]
sgw has quit [*.net *.split]
nerdboy has quit [*.net *.split]
rfs613 has quit [*.net *.split]
mckoan|away has quit [*.net *.split]
yocti has quit [*.net *.split]
rewitt3 has quit [*.net *.split]
Fanfwe has quit [*.net *.split]
woky has quit [*.net *.split]
camus has quit [*.net *.split]
xmn has quit [*.net *.split]
vmeson has quit [*.net *.split]
chrfle has quit [*.net *.split]
mranostaj has quit [*.net *.split]
risca has quit [*.net *.split]
tperrot has quit [*.net *.split]
gourve_l has quit [*.net *.split]
jsbronder has quit [*.net *.split]
bps has quit [*.net *.split]
JaMa has quit [*.net *.split]
manuel_ has quit [*.net *.split]
bradfa has quit [*.net *.split]
awafaa has quit [*.net *.split]
jonmason has quit [*.net *.split]
jonesv[m] has quit [*.net *.split]
dtometzki has quit [*.net *.split]
OutBackDingo_ has quit [*.net *.split]
paulg has quit [*.net *.split]
iokill has quit [*.net *.split]
ochredoke has quit [*.net *.split]
nsbdfl has quit [*.net *.split]
Vineela has quit [*.net *.split]
Guest6275 has quit [*.net *.split]
wesm has quit [*.net *.split]
ant_ has quit [*.net *.split]
goliath has quit [*.net *.split]
Dracos-Carazza has quit [*.net *.split]
qschulz has quit [*.net *.split]
warthog9 has quit [*.net *.split]
LocutusOfBorg has quit [*.net *.split]
yates_work has quit [*.net *.split]
mattsm has quit [*.net *.split]
cambrian_invader has quit [*.net *.split]
override has quit [*.net *.split]
Emantor has quit [*.net *.split]
rodrjassoccom[m] has quit [*.net *.split]
moto-timo has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
lacouture[m] has quit [*.net *.split]
OnkelUlla has quit [*.net *.split]
xantoz has quit [*.net *.split]
fullstop has quit [*.net *.split]
abelloni has quit [*.net *.split]
mvlad has quit [*.net *.split]
creich has quit [*.net *.split]
Ch^W has quit [*.net *.split]
grma has quit [*.net *.split]
alejandr1 has quit [*.net *.split]
janvermaete[m] has quit [*.net *.split]
dwagenk has quit [*.net *.split]
Saur[m] has quit [*.net *.split]
Pierre-jeanTexie has quit [*.net *.split]
Jari[m] has quit [*.net *.split]
marex has quit [*.net *.split]
barath has quit [*.net *.split]
cody has quit [*.net *.split]
Andrei[m] has quit [*.net *.split]
paulbarker has quit [*.net *.split]
droman has quit [*.net *.split]
perdmann_ has quit [*.net *.split]
Shaun has quit [*.net *.split]
beneth has quit [*.net *.split]
fitzsim has quit [*.net *.split]
bluelightning has quit [*.net *.split]
fancer has quit [*.net *.split]
keepitsimplejim[ has quit [*.net *.split]
kanavin has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
dlan has quit [*.net *.split]
derRichard has quit [*.net *.split]
ejoerns[m] has quit [*.net *.split]
rsalveti has quit [*.net *.split]
alex88[m] has quit [*.net *.split]
Spectrejan[m] has quit [*.net *.split]
fabatera[m] has quit [*.net *.split]
asus_986_gpu[m] has quit [*.net *.split]
moto_timo[m] has quit [*.net *.split]
shoragan|m has quit [*.net *.split]
ndec[m] has quit [*.net *.split]
khem has quit [*.net *.split]
kayterina[m] has quit [*.net *.split]
Emantor[m] has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
jordemort has quit [*.net *.split]
dgriego has quit [*.net *.split]
matthewcroughan has quit [*.net *.split]
mattofak has quit [*.net *.split]
JPEW has quit [*.net *.split]
Tartarus has quit [*.net *.split]
CosmicPenguin has quit [*.net *.split]
ndec has quit [*.net *.split]
armpit has quit [*.net *.split]
dl9pf has quit [*.net *.split]
smurray has quit [*.net *.split]
neverpanic has quit [*.net *.split]
xtopher has quit [*.net *.split]
madisox has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
PascalBach[m] has quit [*.net *.split]
AlessandroTaglia has quit [*.net *.split]
tgamblin has quit [*.net *.split]
ad__ has quit [*.net *.split]
RP has quit [*.net *.split]
rburton has quit [*.net *.split]
shoragan has quit [*.net *.split]
jpnurmi has quit [*.net *.split]
halstead has quit [*.net *.split]
Gaffel has quit [*.net *.split]
Net147 has quit [*.net *.split]
zedd has quit [*.net *.split]
fray has quit [*.net *.split]
alex88 has quit [*.net *.split]
wyre has quit [*.net *.split]
frosteyes has quit [*.net *.split]
Alban[m] has quit [*.net *.split]
dkl has quit [*.net *.split]
dmoseley has quit [*.net *.split]
marc1 has quit [*.net *.split]
rfried has quit [*.net *.split]
kergoth has quit [*.net *.split]
ldts has quit [*.net *.split]
tkoskine has quit [*.net *.split]
Crofton has quit [*.net *.split]
mithro has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
zibri has quit [*.net *.split]
override has joined #yocto
cambrian_invader has joined #yocto
mattsm has joined #yocto
yates_work has joined #yocto
LocutusOfBorg has joined #yocto
qschulz has joined #yocto
warthog9 has joined #yocto
Dracos-Carazza has joined #yocto
goliath has joined #yocto
ant_ has joined #yocto
wesm has joined #yocto
Guest6275 has joined #yocto
Vonter has joined #yocto
Vineela has joined #yocto
woky has joined #yocto
JaMa has joined #yocto
Fanfwe has joined #yocto
gourve_l has joined #yocto
jsbronder has joined #yocto
bps has joined #yocto
yocti has joined #yocto
rewitt3 has joined #yocto
mckoan|away has joined #yocto
risca has joined #yocto
tperrot has joined #yocto
mranostaj has joined #yocto
nerdboy has joined #yocto
chrfle has joined #yocto
rfs613 has joined #yocto
sgw has joined #yocto
jpuhlman__ has joined #yocto
Spooster has joined #yocto
vmeson has joined #yocto
sakoman has joined #yocto
xmn has joined #yocto
ecdhe has joined #yocto
camus has joined #yocto
marka has joined #yocto
frosteyes has joined #yocto
wyre has joined #yocto
alex88 has joined #yocto
fray has joined #yocto
zedd has joined #yocto
Net147 has joined #yocto
halstead has joined #yocto
Gaffel has joined #yocto
shoragan has joined #yocto
jpnurmi has joined #yocto
nsbdfl has joined #yocto
creich has joined #yocto
mvlad has joined #yocto
ochredoke has joined #yocto
abelloni has joined #yocto
xantoz has joined #yocto
OnkelUlla has joined #yocto
fullstop has joined #yocto
tangofoxtrot has joined #yocto
lacouture[m] has joined #yocto
moto-timo has joined #yocto
rodrjassoccom[m] has joined #yocto
Emantor has joined #yocto
ChanServ has joined #yocto
NishanthMenon has joined #yocto
Crofton has joined #yocto
mithro has joined #yocto
tkoskine has joined #yocto
ldts has joined #yocto
dmoseley has joined #yocto
kergoth has joined #yocto
marc1 has joined #yocto
dkl has joined #yocto
zibri has joined #yocto
Alban[m] has joined #yocto
rfried has joined #yocto
bluelightning has joined #yocto
dlan has joined #yocto
fancer has joined #yocto
keepitsimplejim[ has joined #yocto
derRichard has joined #yocto
tlwoerner has joined #yocto
kanavin has joined #yocto
rsalveti has joined #yocto
prabhakarlad has joined #yocto
manuel_ has joined #yocto
bradfa has joined #yocto
awafaa has joined #yocto
jonesv[m] has joined #yocto
jonmason has joined #yocto
OutBackDingo_ has joined #yocto
iokill has joined #yocto
paulg has joined #yocto
dtometzki has joined #yocto
cody has joined #yocto
barath has joined #yocto
dwagenk has joined #yocto
Pierre-jeanTexie has joined #yocto
Saur[m] has joined #yocto
paulbarker has joined #yocto
Andrei[m] has joined #yocto
Jari[m] has joined #yocto
janvermaete[m] has joined #yocto
perdmann_ has joined #yocto
droman has joined #yocto
fitzsim has joined #yocto
Shaun has joined #yocto
beneth has joined #yocto
AlessandroTaglia has joined #yocto
ad__ has joined #yocto
tgamblin has joined #yocto
PascalBach[m] has joined #yocto
rburton has joined #yocto
RP has joined #yocto
dl9pf has joined #yocto
Tartarus has joined #yocto
asus_986_gpu[m] has joined #yocto
alex88[m] has joined #yocto
ejoerns[m] has joined #yocto
Emantor[m] has joined #yocto
matthewcroughan has joined #yocto
khem has joined #yocto
dgriego has joined #yocto
xtopher has joined #yocto
ndec[m] has joined #yocto
fabatera[m] has joined #yocto
kayterina[m] has joined #yocto
moto_timo[m] has joined #yocto
Spectrejan[m] has joined #yocto
jordemort has joined #yocto
shoragan[m] has joined #yocto
CosmicPenguin has joined #yocto
JPEW has joined #yocto
mattofak has joined #yocto
ndec has joined #yocto
neverpanic has joined #yocto
armpit has joined #yocto
smurray has joined #yocto
madisox has joined #yocto
mcfrisk has joined #yocto
shoragan|m has joined #yocto
grma has joined #yocto
Ch^W has joined #yocto
alejandr1 has joined #yocto
marex has joined #yocto
pidge_ has joined #yocto
florian has joined #yocto
Tokamak_ has joined #yocto
WadeBerrier[m] has joined #yocto
nohit has joined #yocto
florian has quit [Ping timeout: 256 seconds]
khem has quit [Ping timeout: 272 seconds]
lacouture[m] has quit [Ping timeout: 244 seconds]
rodrjassoccom[m] has quit [Ping timeout: 244 seconds]
WadeBerrier[m] has quit [Ping timeout: 256 seconds]
PascalBach[m] has quit [Ping timeout: 244 seconds]
AlessandroTaglia has quit [Ping timeout: 244 seconds]
Spectrejan[m] has quit [Ping timeout: 272 seconds]
fabatera[m] has quit [Ping timeout: 272 seconds]
moto_timo[m] has quit [Ping timeout: 272 seconds]
alex88[m] has quit [Ping timeout: 272 seconds]
asus_986_gpu[m] has quit [Ping timeout: 272 seconds]
shoragan|m has quit [Ping timeout: 272 seconds]
ndec[m] has quit [Ping timeout: 272 seconds]
ejoerns[m] has quit [Ping timeout: 272 seconds]
kayterina[m] has quit [Ping timeout: 272 seconds]
Emantor[m] has quit [Ping timeout: 272 seconds]
jordemort has quit [Ping timeout: 272 seconds]
shoragan[m] has quit [Ping timeout: 272 seconds]
keepitsimplejim[ has quit [Ping timeout: 268 seconds]
dwagenk has quit [Ping timeout: 272 seconds]
janvermaete[m] has quit [Ping timeout: 272 seconds]
Saur[m] has quit [Ping timeout: 272 seconds]
Pierre-jeanTexie has quit [Ping timeout: 272 seconds]
Jari[m] has quit [Ping timeout: 272 seconds]
barath has quit [Ping timeout: 272 seconds]
cody has quit [Ping timeout: 272 seconds]
Andrei[m] has quit [Ping timeout: 272 seconds]
Alban[m] has quit [Ping timeout: 272 seconds]
ChanServ has quit [*.net *.split]
ChanServ has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has quit [Quit: Leaving]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
OnkelUlla has quit [Ping timeout: 244 seconds]
OnkelUlla has joined #yocto
<jonesv[m]> But I'm kind of realizing that I cannot set `MACHINE_ESSENTIAL_EXTRA_RDEPENDS` from my image recipe, could that be?
<jonesv[m]> Somehow it would make sense, but that's what I use to set the `kernel-module-*` I want 🤔
<jonesv[m]> Oh or maybe I should install them as packages with `IMAGE_INSTALL_append` 💡
<jonesv[m]> hmm but then KERNEL_MODULE_AUTOLOAD seems like it's not working in my image recipe :-(. I don't get why that would be linked to the bsp/machine configuration
<jonesv[m]> aha!
<jonesv[m]> That one should probably go in my kernel bbappend!
<jonesv[m]> > You can use the KERNEL_MODULE_AUTOLOAD variable anywhere that it can be recognized by the kernel recipe or by an out-of-tree kernel module recipe (e.g. a machine configuration file, a distribution configuration file, an append file for the recipe, or the recipe itself).
Spooster has quit [Remote host closed the connection]
<Ch^W> RP: Remind me, when it happens, do all qemu VMs hang? Or just a few?