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)
BCMM has quit [Quit: Konversation terminated!]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
otavio has joined #yocto
goliath has quit [Quit: SIGSEGV]
sakoman has joined #yocto
wmiles has quit [Quit: Quit]
elfenix has joined #yocto
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
sakoman has quit [Quit: Leaving.]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
paulg has quit [Ping timeout: 272 seconds]
rfried has joined #yocto
rob_w has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
chrfle_ has joined #yocto
zyga-mbp has joined #yocto
chrfle_ has quit [Ping timeout: 268 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP> kanavin: since the last set of upgrades, I think parted is timing out on qemuarm64 :/
<RP> kanavin: that batch has seemed a bit tricky with the mingw breakage and the libcap reproducibility issue that appeared in perf :(
chrfle_ has joined #yocto
mckoan|away is now known as mckoan
zyga-mbp has joined #yocto
* RP wonders if using "/tmp/sdk" as a hardcoded path in tests which can run in parallel is wise
zyga-mbp has quit [Client Quit]
zpfvo has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudx
<ant_home> hi RP
<RP> hi ant_home
<ant_home> using now external layers of dubious q I 'd ask for an optional QA like Gentoo
<ant_home> * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * .
<ant_home> just parse the compile log
<ant_home> like in a class maybe
<ant_home> *then* you run tests :)
<ant_home> you know, just to have an idea what kind of fault are to expect...
<ant_home> I have found many examples here :)
<LetoThe2nd> I totally misread that as "don't know what kind of failure to expert"
<ant_home> sorry, did not sleep enough
* ant_home heads to coffee
<RP> ant_home: I think where compile warnings are known to break, they tend to be errors...
<LetoThe2nd> Same here. Share coffee, please.
goliath has joined #yocto
<ant_home> see
<ant_home> ./git/tuxtxt/tuxtxt.c:267:3: warning: 'return' with no value, in function returning non-void
<ant_home> 267 | return;
<RP> ant_home: that should be a compiler error really? :)
<ant_home> RP: sigh...there are recipes undoing rm_work because other needs theirs sysroot. How to re-instate shared sysroot :)
Vonter has quit [Read error: Connection reset by peer]
leon-anavi has joined #yocto
tnovotny has joined #yocto
Vonter has joined #yocto
keepitsimplejim[ has joined #yocto
kayterina has joined #yocto
* derRichard wonders why we have COMPATIBLE_MACHINE but no COMPATIBLE_DISTRO
* LetoThe2nd sets COMPATIBLE_EVERYTHING = "1" in local.conf
<derRichard> well, i have a rather complex yocto project on my desk with many different distros, images, machines, ...
<ant_home> derRichard, add OpenWrt soon
<LetoThe2nd> and make it compatible!
<kanavin> RP: I'll run the test now, but without kvm on x86 it might be tricky to investigate
* derRichard heads back to work
<derRichard> i'm not into kidding right now
kayterina_ has joined #yocto
prabhakarlad has joined #yocto
<ant_home> derRichard, check the ML when you have time later
<derRichard> ?
<ant_home> about the patches to build OpenWrt
<derRichard> o_O
<derRichard> :)
<keepitsimplejim[> I'm getting errors when trying to compile 'elfutils-devel' where would be the best place to discuss it?
<derRichard> ant_home: is it related to that one? https://www.youtube.com/watch?v=2gACMkjBRyM
<derRichard> and which mailinglist do you mean?
BCMM has joined #yocto
<ant_home> sorry, OE one
<derRichard> thx :)
* derRichard forwards to his yocto hating but openwrt loving buddy
<ant_home> jit
ilunev has joined #yocto
zyga-mbp has joined #yocto
abelloni_ is now known as abelloni
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
kayterina_ has quit [Quit: Leaving]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<kanavin> RP: patch sent
<RP> kanavin: ah, great, thanks! :)
<RP> If anyone wants a nice easy bug to fix that would help our general intermittent failure issues: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14438
<RP> Hard to reproduce, easy to fix now the cause is known
Guest3365 has joined #yocto
Guest3365 has quit [Client Quit]
ollie88r has joined #yocto
<ollie88r> hi. im having issues getting "shadow" to be installed in my targets image. I can across the following
<ollie88r> When runtime package management is disabled in the image, several packages are removed including base-passwd, shadow, and update-alternatives. You can specify functions separated by semicolons:
<ollie88r> could this be the reason? and if so, can someone help me work around this?
argonautx has joined #yocto
<keepitsimplejim[> I've found a patch that looks to correct the error with 'libebl' when compiling for Gatesgarth and I'm in the process of compiling so I'll have to get back if it works. I've attached a link to the patch.
patrick_r has joined #yocto
<patrick_r> am cross compiling for imx-6 so it is an arm 7 processor, some software here can be either native of cross compiled. need to -D__ARM__ for example only for the cross compilation as I have parts of the source code (#ifdef etc) that I don't want to compile in native
<patrick_r> is there a resipe trick to do that?
<patrick_r> recipe*
<patrick_r> Jeez I really type too fast, "either native OR cross compiled" *
<RP> patrick_r: if you use the cross compiler those definitions should be set automatically for the given target system?
<patrick_r> @RP I do not see any in the log.do_compile
<RP> patrick_r: I mean that the compiler should be setting some things itself automatically shouldn't it?
<patrick_r> @RP: not explicitely so I do not know what is defined
<RP> patrick_r: look at the gcc manuals or something like https://sourceforge.net/p/predef/wiki/Architectures/
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
ollie88r has quit [Quit: Client closed]
mckoan is now known as mckoan|away
chrfle_ has quit [Quit: Leaving]
zyga has joined #yocto
zyga-mbp has quit [Ping timeout: 252 seconds]
zyga has quit [Ping timeout: 272 seconds]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
zyga-mbp has joined #yocto
goliath has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
vmeson has quit [Ping timeout: 268 seconds]
patrick_r has quit [Quit: Client closed]
kayterina has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
<mcfrisk> maybe I missed some irc or mailing list discussions, but how to resolve download failures for http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot/archive/a456d0771ba0.tar.gz ?
<mcfrisk> so this from meta-java dunfell branch and likely master too
<RP> mcfrisk: I did try and populate the YP mirror but I'm not sure I was given the right tarballs
<kanavin> RP: I believe that the disappeared tarballs are not in that set :(
vmeson has joined #yocto
<mcfrisk> 69719a9657b15e6bef1bef137a15d830293091fbc46616fe8759e863ba904442 downloads/a456d0771ba0.tar.gz
<mcfrisk> sha256sum
<kanavin> mcfrisk, that's just the first one out of 6 or 7
<mcfrisk> sigh
<mcfrisk> but I managed to build it today on local machine, not on our CI servers. I might have them all
<mcfrisk> is this the full set of files: langtools-fd2fdb20d858.tar.gz jdk-d7ecb57d3c61.tar.gz jaxws-d92eda447bca.tar.gz jaxp-77e7219c7424.tar.gz corba-79ee8535bc51.tar.gz hotspot-a456d0771ba0.tar.gz
<ecdhe> I'm using a kernel recipe that's been extended several times. What's the easiest way to inspect the final rendering of its .config file? `devtool modify` puts it in a workspace directory for me but the .config hasn't been generated at that point.
prabhakarlad has quit [Quit: Client closed]
<mcfrisk> RP kanavin: these are the files referenced in SRC_URI of icedtea7-native: https://mcfrisk.kapsi.fi/temp/yocto_java_files/
<kanavin> mcfrisk, I don't think so, let me check
prabhakarlad has joined #yocto
<mcfrisk> I went through icedtea7-native SRC_URI and found those files from my local download cache. Would be nice to get them to yocto side mirrors, if nothing else.
<kanavin> mcfrisk, corba is not there for one thing?
<kanavin> let me check again..
<kanavin> so the following files are needed
<mcfrisk> kanavin: added corba which I missed
<mcfrisk> kanavin: note that the downloadfilenames are different..
<kanavin> I think you should also strip the prefixes
<mcfrisk> ah, so I should remove the prefixes? downloadfilenames is confusing..
<kanavin> I am not exactly sure, how yocto mirrors operate though
<kanavin> but if we were to adjust SRC_URI, the prefixless names would be the right ones
<mcfrisk> I added symlinks to both styles are now in https://mcfrisk.kapsi.fi/temp/yocto_java_files/
prabhakarlad has quit [Quit: Client closed]
<mcfrisk> /to/so/
<kanavin> I guess both should be added to yocto mirror and then someone should attempt a build
Guest1 has joined #yocto
<mcfrisk> "bitbake -c fetch icedtea7-native" is enough to test
<mcfrisk> or there may be more java recipes broken...
patrick_r has joined #yocto
<v0n> I have tty devices which requires to send them a specific letter at a specific baudrate in order to identify it and receive an ID. Are there tool out there to do that already or should go with a simple C program tweaking termios structs?
paulg has joined #yocto
<RP> mcfrisk: let me add those...
<RP> mcfrisk: files should be either there or in the process of the server syncing them in
sakoman has joined #yocto
yates has joined #yocto
<ilunev> I wonder why a "devtool modify linux-raspberrypi" does not apply any patches from SRC_URI whilst bitbake happily uses them.
<yates> i'm seeing "ld.bfd" used as the linker. what is that? i thought "ld" was the linker?
prabhakarlad has joined #yocto
<RP> yates: there are two possible linkers, the older one (bfd) and gold
<yates> RP: ok
<yates> going decades back, i always thought the executable "ld" was the old/standard one, not "ld.bfd". perhaps that's relatively new?
<RP> yates: now there are two you need a way to specify it
<yates> that makes sense.
rcw has joined #yocto
<yates> new question: isn't it a common problem to require a driver within u-boot, e.g., a specific file system, as well as for the booted linux kernel? is it necessary to develop the two drivers independently or is there some way one driver can be shared?
rob_w has joined #yocto
<mcfrisk> RP: thanks, can see the files in http://downloads.yoctoproject.org/mirror/sources/
courchea has joined #yocto
courchea has quit [Client Quit]
Guest1 has quit [Quit: Client closed]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
patrick_r has quit [Quit: Client closed]
zyga-mbp has joined #yocto
argonautx has quit [Quit: Leaving]
tnovotny has quit [Read error: Connection reset by peer]
leon-anavi has quit [Quit: Leaving]
tnovotny has joined #yocto
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP> jonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/1103 - looks like there is a reprodcubile real compile issue with that on tubleweed :/
<rburton> damned thing
<rburton> brotli/c/enc/encode.c:1473:20: error: argument 5 of type ‘const uint8_t *’ {aka ‘const unsigned char *’} declared as a pointer [-Werror=vla-parameter]
<rburton> spider sense tingling
<jonmason> wasn't this patched recently?
<rburton> yes
<rburton> will revert and see if this is all khem's fault
prabhakarlad has quit [Ping timeout: 250 seconds]
<jonmason> lol, blame khem!
<RP> at least I'm not getting blamed for a change :)
<rburton> yet
<rburton> you may have just jinxed it
<RP> heh, can't wait :)
<rburton> fired a manual build on that worker to poke
prabhakarlad has joined #yocto
zpfvo has quit [Quit: Leaving.]
<rburton> hm ok so reverting that didn't help
<rburton> aha
<rburton> thought my spider sense was tinging and it wasn't the last patch
<rburton> got a fix
<rburton> grr
<rburton> does THISDIR get updated for inc files?
<rburton> so if I require, the path is where the include is?
vmeson has quit [Ping timeout: 240 seconds]
<rburton> (yes)
vmeson has joined #yocto
TommyGilchrist has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<rburton> RP: rule of thumb is that tumbleweed has gcc11
tnovotny has quit [Quit: Leaving]
<TommyGilchrist> Hi folks, just joined and I'm new to IRC in general. I've joined to hopefully get some help getting a compiled driver to work in a Yocto based build
prabhakarlad has quit [Quit: Client closed]
<rburton> RP: got a fix locally, should be in meta-arm tomorrow
<TommyGilchrist> But I'm not sure of the local rules / good manners. I don't want to just barge in with "someone fix this for me"
<TommyGilchrist> Also, this is for use on an Nvidia Jetson board so not sure if this it would be better to ask on meta-tegra or here
<TommyGilchrist> Issue is that a company has provided a pre-compiled driver (they won't release the source) for their video card and it works fine for the Nvidia supplied Ubuntu 18.04 reference build but when I try to modprobe the driver files in Yocto I get “modprobe: ERROR: could not insert 'videobuf_dma_sg': Exec format error”
<TommyGilchrist> And this is my first foray in linux drivers
prabhakarlad has joined #yocto
ilunev has joined #yocto
zyga-mbp has quit [Ping timeout: 268 seconds]
ilunev has quit [Ping timeout: 240 seconds]
ilunev has joined #yocto
<ecdhe> TommyGilchrist: welcome!
<ecdhe> What are the kernel versions that work and don't work?
<TommyGilchrist> Thanks ecdhe - That's what's confusing me (well, that and a lot of other things). I think they're the same. Just digging out the details
<v0n> I'm adding "gcc" to IMAGE_INSTALL but I don't have (g)cc on the target. Is it the wrong package?
<TommyGilchrist> From the Yocto build - uname -r => 4.9.201-l4t-r32.5+gc68230c5b46a
<rburton> v0n: gcc-symlinks to get the 'gcc' binary
<v0n> rburton: thank you
zyga-mbp has joined #yocto
<TommyGilchrist> and from the Nvidia build => 4.9.201-tegra
<TommyGilchrist> What I did notice is that the Nvidia kernel was built with GCC 7.3.1 whereas the Yocto build used GCC 8.3.0 and I did find some articles indicating that the "Exec format error" could be related to GCC version but I don't know if that's actually relevant in this case
<TommyGilchrist> modinfo ./videobuf-dma-sg.ko (the first of the precompiled drivers that tries to load) reports
<TommyGilchrist> vermagic: 4.9.201-l4t-r32.5+gc68230c5b46a SMP preempt mod_unload modversions aarch64
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gsalazar has quit [Ping timeout: 272 seconds]
ilunev has quit [Ping timeout: 244 seconds]
ilunev has joined #yocto
<smurray> TommyGilchrist: I could imagine modversions being problematic, even with the same kernel commit level I think differences in .config might yield different checksums
zyga-mbp has joined #yocto
ilunev has quit [Ping timeout: 268 seconds]
<moto-timo> qemu-system-native is failing do_configure missing pthreads/headers... but I don't see libpthread-stubs as a dependency in qemu/ recipes
<moto-timo> seems like a 6.0 change
<khem> rburton: I fixed sbsa-acs recipe not edk2-firmware
<khem> but it seems you need same fix there too
ilunev has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<moto-timo> PACKAGECONFIG_pn-qemu-system-native = "fdt alsa kvm virglrenderer glx gtk+"
<moto-timo> so it might only be happening with one of those configs?
<moto-timo> (on master)
prabhakarlad has quit [Quit: Client closed]
<TommyGilchrist> Thanks smurray - my problem is that I vaguely understand those terms but it looks like I've a steep learning curve ahead of me
<TommyGilchrist> Or rather I know what they mean but not how to address it :-)
<ecdhe> TommyGilchrist: I msg'd you
ncaidin_lf has joined #yocto
<ncaidin_lf> Hi Richard, I don't know if you've identified anyone to respond to the LTS discussion yet, but as I was reviewing my notes again, I was wondering if I should respond with the following: The recent survey made it relatively clear that folks might be interested in 3 or 4 years for support. We haven't had a mix-in layer in practice. Members who share
<ncaidin_lf> an interest in a particular kernel version could come together and support. Experimenting with this approach could be quite valuable for the community to learn from.Changing the compiler would have a big ripple effect (which I assume means lots of churn and changes and not so easily manageable).There was a mention about 6 year Android releases and
<ncaidin_lf> whether YP should take that into consideration?An acknowledgement that it may not be easy to figure out the best kernel strategies.At least one company/org seemed interested in updating the Linux Kernel in the 2nd year of the Yocto LTS. Is there any shared interest for this? This potentially could be where experimenting with the mix-in layer
<ncaidin_lf> would come in.
<ncaidin_lf> (those are supposed to be bullet points)
prabhakarlad has joined #yocto
TommyGilchrist is now known as tommyg
xmn has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]
<JPEW> RP: Would the word "ERROR" in stderr cause a AB job to think it had an error?
<JPEW> RP: Adding tests for the streaming compressor patch I sent; LZ4 prints "Error ..." to stderr when I test for expected failure conditions; want to know if that will confuse the AB, or if I need to supress stderr
kpo_ has joined #yocto
ncaidin_lf has quit [Quit: Client closed]
<moto-timo> qemu-system-native config issue is self inflicted... needs PACKAGECONFIG pie
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ncaidin_lf has joined #yocto
ncaidin_lf has quit [Client Quit]
<moto-timo> seems to happen when adding gtk+ to PACKAGECONFIG
<ecdhe> I have a SRC_URI = git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git;protocol=git;tag=v5.13-rc6
<ecdhe> The commit hash of this specific commit is 009..33d
<ecdhe> So then I get a "Failed to fetch URL"
<ecdhe> Then I get "Fetcher failure: Unable to find revision <commit hash> in branch master even from upstream"
<ecdhe> I did not specific a commit hash in the recipe, so the fact that I'm seeing the expected commit hash means it found the tag I specified and found the correct commit hash.
<ecdhe> What I don't get is why the fetcher cares whether this tag/commit is on master or not
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
<moto-timo> RP: looks like qemu-system-native PACKAGECONFIG is yet another case where variable precedence is.... not exactly as 'expected'
<RP> JPEW: it won't confuse tasks, it would confuse the main console so it depends where it is logged
<RP> moto-timo: I talked about that on in my previous oe-arch email :/
<JPEW> RP: Ok. I decided to add an option to suppress stderr (which the tests use) anyway
<moto-timo> yeah... it's the first time it bit me (and I knew it bit me)
<moto-timo> fingers crossed graphical qemu works this time.
<RP> rburton: right, I suspected something like that, thanks!
<moto-timo> need to figure out why qemu (graphical) isn't launching properly with testimage on master... something changed since hardknot/qemu-6.0.0
<moto-timo> check that... I think I saw the same issue with hardknott. some system configuration nonsense to be sure
<RP> moto-timo: I think I have gtk and sdl enabled in my local.conf for reasons I don't remember
moto-timo_ has joined #yocto
moto-timo_ has quit [Client Quit]
moto-timo_ has joined #yocto
<dvorkindmitry> how can I write my bblayers.conf file to force it to include some -meta automatically if it exists? I want to write something like BBLAYERS ?= " ${TOPDIR}/../meta-openamp" and it should pass Ok if there is no meta-openamp dir
moto-timo_ has quit [Client Quit]
Vonter has quit [Ping timeout: 268 seconds]
moto-timo_ has joined #yocto
moto-timo_ has quit [Client Quit]
moto-timo has quit [*.net *.split]
moto-timo has joined #yocto
<moto_timo[m]> RP: yeah, I need to understand that better (sdl vs. gtk+)
<moto-timo> libera went a little nuts there for me for a moment
<moto-timo> luckily matrix carried the converation
Vonter has joined #yocto
<RP> zedd: whatever this rcu thing is, it is cross architecture: https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/3574/steps/13/logs/stdio
<RP> zedd: that rules out kvm actually
<RP> vmeson: ^^^
Vonter has quit [Ping timeout: 240 seconds]
<RP> 1804 again though
tommyg has quit [Quit: Client closed]
<RP> that basically isolates it to guest kernel or qemu
dvorkindmitry has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
wesm has quit [Ping timeout: 268 seconds]
<RP> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2229/steps/14/logs/stdio is interesting as it appears it crashed UEFI firmware too around the same time
<RP> so I think this is a qemu bug
<RP> paulg: you love qemu right? :)
<vmeson> RP noted but I've run out of attention span for the day. The sun is out and the patio is calling me...
<RP> vmeson: its only 10pm here and I'm still going :(
<RP> Those logs suggest three separate qemu instances in separate bitbake builds were taken out at roughly the same time
<RP> and on 1804 again
wesm has joined #yocto
yannd has quit [Quit: Quitte]
<paulg> okay, I'll bite - what is 1804? Some sekrit code name for a sector of Area51?
yannd has joined #yocto
vmeson has quit [Ping timeout: 244 seconds]
<RP> paulg: ubuntu 18.04 host machines
<RP> paulg: yours is more fun
<paulg> ah, right - the whole "commas save lives
<paulg> and "lets eat Grandpa" thing.
* paulg was actually thinking line numbers in some test log or similar.
<paulg> rcu stall messages are pretty much designed to be impenetrable by mere mortals w/o doing two hours of reading of the source...
prabhakarlad has quit [Quit: Client closed]
<ant_home> if it'd happen often on arm I'd try to lure arnd on #armlinux
<ant_home> s/mere mortals/arnd/
<ant_home> and it is penetrable
<paulg> checked #mklinux the other day to see if the ppc folks moved from FleaNode to Belarus Chat - both looked like ghost towns.
rob_w has quit [Quit: Leaving]
<paulg> I guess I should start saying "FleeNode" instead of my usual "FleaNode" :-P
<paulg> I left when I saw yocti left.
<paulg> Can't argue with a bot.
<moto-timo> /close #fleenode
<moto-timo> 9 out of 10 lemmings agree
<jordemort> so here's a really weird one, i am mounting a ubifs root in my initramfs - if i just let that script run, it works fine, but if i sleep 10 seconds before trying to mount the filesystem, it hangs hard, no logs, completely unresponsive, no kernel panic
<jordemort> i have dealt with filesystems that get angry if you mount them too soon but this is the first one i have encountered that gets angry if you mount it too late
<jordemort> no background processes or anything, my init script in the initramfs is pid 1
goliath has quit [Quit: SIGSEGV]
<ant_home> jordemort, derRichard is your man
<ant_home> are you sure the ubifs is sane?
<RP> paulg: they removed my nick reg so that was the end of it for me
<derRichard> jordemort: this makes no sense at all
<jordemort> ant_home: sane enough for u-boot to load the kernel and initramfs off of it, sane enough that if i mount it right away then the device boots up and plays nice
<RP> paulg: I've been reading https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt but I think the errors we see are just a sign there is something very wrong :/
<derRichard> did you enable the kernel hung task or lockup detector?
<moto-timo> Paula
<moto-timo> Argh
<jordemort> derRichard: yeah it super doesn't, it seems like if i wait more than ~4-5 seconds to mount it after things come up then i get the freeze
ant_home is now known as ant
<moto-timo> paulg: when they kicked IRCcloud clients I said “ you are too insane for me to waste my time”
ant is now known as Guest1692
<jordemort> i'm wondering if there's something dumb happening in my kernel? something wrong in the device tree that makes the kernel step on something important like an interrupt or something... but if that was the case i'd expect the device to hang in normal operation, it doesn't, no NAND or FS problems once it comes up
<jordemort> derRichard: not explicitly, i'll look into that
<paulg> [06/16 18:48] -NickServ- Nick paulg isn't registered.
<paulg> Hrrmph. Never noticed that. Savages.
Guest1692 has quit [Quit: Leaving]
ant_home has joined #yocto
<derRichard> jordemort: one thing that comes into my mind is the ubi wearleveling worker. maybe(!) it starts with work and gets stuck after some time while doing io
<derRichard> a buggy nand driver could cause this
kpo_ has quit [Read error: Connection reset by peer]
BCMM has quit [Quit: Konversation terminated!]
<jordemort> hm, booting with nmi_watchdog=1 and softlockup_panic=1 hasn't produced any debugging
<derRichard> did you enable these in the kernel?
kpo_ has joined #yocto
<jordemort> ah are there associated kernel config options?
<derRichard> yes
<jordemort> ok
<derRichard> jordemort: did it trigger?
<jordemort> derRichard: still rebuilding the kernel
<jordemort> derRichard: i'll let you know tomorrow, going to wander off to dinner soon
<derRichard> ok :)
<jordemort> thanks for the help!
<derRichard> np
<jordemort> i am like 99% sure i messed up the device tree here or something porting from the vendor's 4.14 to 5.4
<jordemort> i should really just hand them back my kernel tree and tell them "you fix it" :D
<yates> when building a (cross-)toolchain, does yocto pull libgcc from here: https://github.com/gcc-mirror/gcc/tree/releases/gcc-10/libgcc ?
<JPEW> RP the grace period counter getting so high it's negative seems suspicious. Is it negative on many of them?
<JPEW> It looks unsigned, but is printed as signed, so I don't think it's *actually* negative, just really large