ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
<NishanthMenon>
When an SoC has custom system wide suspend state, is the standard strategy folks use to deal with say suspend-to-special-idle1, suspend-to-special-idle2 etc .. to use a systemd service file to read a config file which is then translated to specific sysfs file update the SoC specific system power state?
mag has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mag has joined #armlinux
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
apritzel_ has quit [Ping timeout: 248 seconds]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
hanetzer has quit [Ping timeout: 256 seconds]
hanetzer has joined #armlinux
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #armlinux
hanetzer has quit [Ping timeout: 265 seconds]
hanetzer has joined #armlinux
vigneshr has joined #armlinux
amitk has joined #armlinux
heat has quit [Ping timeout: 260 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
guillaume_g has joined #armlinux
<arnd>
ajb-linaro: ah, I must have misremembered then, I thought it only happens with "-cpu host". Can you reproduce it with both -cpu settings?
<arnd>
what the warning tells you is that _sve_rdvl() reports an expected vector length. I'm not sure which register this is, but the macro looks like
<arnd>
with "-cpu max", I would expect SVE to get emulated by qemu the same way it does when KVM is disabled
<arnd>
maybe the instruction is not trapped but directly executed by the host cpu, so it tells you whatever non-SVE CPUs are supposed to report (invalid, zero or the size of NEON vectors, not sure)
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 246 seconds]
macromorgan has quit [Read error: Connection reset by peer]
viorel_suman has joined #armlinux
monstr has joined #armlinux
iivanov has joined #armlinux
frieder has joined #armlinux
biju has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #armlinux
<maz>
arnd: do you have a pointer to this KVM issue with SVE? this really should be air-tight, but if it isn't, there is a whole lot of stuff to revert immediately.
iivanov_ has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
<maz>
j`ey: arnd was talking about something already reported, but I have no trace of it.
<j`ey>
ah sorry, thought you just missed the context on irc
matthias_bgg has quit [Ping timeout: 260 seconds]
<maz>
nah, that's still in my scrollback buffer... (ffs, when is ARM going to release an AArch64 FVP???)
apritzel has joined #armlinux
matthias_bgg has joined #armlinux
prabhakarlad has joined #armlinux
cleger has joined #armlinux
alexels has joined #armlinux
<ajb-linaro>
arnd: I don't have any HW capable of SVE and KVM...
<ajb-linaro>
gah why are selftests so hard to cross build
sszy has joined #armlinux
heat has joined #armlinux
<Guest9561>
ajb-linaro: are you using a hosted toolchain, or a bare-metal toolchain? with a hosted cross-toolchain I just need to build the kernel, run 'make headers', then 'make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/testing/selftests TARGETS=arm64 install' and I get a folder full of tests
Guest9561 is now known as mrutland
mrutland is now known as Guest6991
<ajb-linaro>
mrutland: its the debian gcc-aarch64-linux-gnu toolchain - but I think its a header issue because obviously my system doesn't understand HWCAP2_SME yet
* ajb-linaro
tried make -C ../../tools/testing/selftests/ O=(pwd)/tools/testing/selftests INSTALL_PATH=(pwd)/install TARGETS=arm64
<Guest6991>
Ah, I was under the impression that running 'make headers' built that into an in-tree file that the selftests included
<Guest6991>
Ugh, nickserv pain
<Guest6991>
I thought my system was too old to have HWCAP2_SME in its native headers
* ajb-linaro
tries make headers first
<ajb-linaro>
so should it try an pick up headers from $BLD/usr/include/?
<Guest6991>
If I *don't* run 'make headers' first, I get tonnes of missing definition warnings, If I do, it works
<Guest6991>
Yup, AFAICT it picks it up from the 'usr/include/' directory in-tree, I'm doing na in-tree build so I don't know if it's looking at $BLD or potentially missing that
<ajb-linaro>
bbl, time to speed run my Wednesday meetings
<arnd>
ajb-linaro: I didn't mean you should run it on SVE-enabled hardware in KVM, I'm fairly sure it only happens on non-SVE hardware. The question is whether "-cpu host" correctly reports the absence of SVE so the testcase gets skipped, or if it runs into the same assertion in the kernel
<ajb-linaro>
arnd: ahh ok
<ajb-linaro>
mrutland: hmm yeah I'm doing out-of-tree builds and the -I/home/alex/lsrc/linux.git/tools/testing/selftests/ -isystem /home/alex/lsrc/linux.git/builds/arm64.initramfs/tools/testing/selftests/usr
<ajb-linaro>
/include looks suspicious
<mrutland>
ajb-linaro: I'm just building something atm, but I can try an out-of-tree build in a sec
<mrutland>
ajb-linaro: if you could share your magic runes it'd help :)
<mrutland>
(I largely can't remember how to do out-of-tree builds)
<maz>
robmur01: awesome! do you know if they plan to do the same for AEM?
<ajb-linaro>
mrutland: I thought out-of-tree was the OneTrueWay (tm) for anyone who has a zoo of kernel builds
<mrutland>
ajb-linaro: I'm starting to use git-worktree atm, and I don't usually have more than two things I need to have active at once
<mrutland>
ajb-linaro: I think those steps are missing bits? that first 'make menuconfig' can't work unless you have some other environment variables telling it where the kernel tree makefile is
luispm has quit [Ping timeout: 268 seconds]
<mrutland>
Looking at the docs, it does look like the kselftest makefile stuff expects to be run on an in-kernel build, even if the kselftests are build out-of-tree
<mrutland>
So probably worth asking on the list; I can't see how this can work without separate paths specified for the kernel dir and the kselftest dir
<mrutland>
Ugh; trying to do an out-of-tree build for that ended up placing objects in the src dir
<mrutland>
So I think people haven't really thought about this case, and it's not qruite right
<mrutland>
e.g. if I run "make -C /home/mark/src/linux O=/home/mark/out-of-tree-build-dir ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j50 kselftest-install TARGETS=arm64"
<mrutland>
... it builds, and I end up with a 'kselftest' folder in my out-of-tree-build dir
<mrutland>
... but it created the objects in the src dir
<broonie>
The kselftest build stuff is a bit of a disaster.
<broonie>
arnd: Not seen any report of any issue that looks like what ajb-linaro mentioned, everything from the LKFT people has been "our emulated system is very slow" and possibly one issue in fp-stress that's already fixed in -next but I'm waiting for Naresh to reply there.
luispm has joined #armlinux
matthias_bgg has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
<broonie>
ajb-linaro: Do you have more specifics on how to reproduce the issue? Running sve_vl and sve-ptrace inside a guest is working for me with both -next and Linus' tree.
<broonie>
Under qemu.
<ajb-linaro>
broonie: with -cpu max,pauth-impdef=on -machine virt-2.10,mte=on
<ajb-linaro>
broonie: but maybe its a QEMU regression - what version are you running
<broonie>
arnd: You'd not be able to trigger the assert without SVE hardware, RDVL is an instruction which would fault on non-SVE.
<ajb-linaro>
broonie: ok once I've got the one test case built I shall bisect QEMU
naoki has quit [Quit: naoki]
<broonie>
I do a good chunk of my testing in qemu, but it's possible host performance issues or something could trigger a race condition. It looks like you're testing mainline?
<ajb-linaro>
broonie: I live on mainline...
<broonie>
What it's checking there is that the vector length it thought it set on the task is the same one that's set in the hardware, originally written via ZCR_EL1.LEN and then verified via the RDVL instruction.
NikhilAmd has joined #armlinux
<mrutland>
ajb-linaro: should I go with -j256 instead? ;
<mrutland>
ajb-linaro: it turns out core/thread count != throughput anyway ;)
NikhilAmd has quit [Quit: Client closed]
<robmur01>
maz: sorry, no idea, just thought I'd check out of curiosity and was pleasantly surprised.
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #armlinux
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #armlinux
alexels has quit [Quit: WeeChat 3.7.1]
torez has joined #armlinux
<ajb-linaro>
mrutland: ok I was being too clever - I should have kept O= the root of my build tree: make -C ../../tools/testing/selftests/ O=(pwd) TARGETS=arm64
<ajb-linaro>
hmm still dynamically linked though...
<geertu>
mrutland: Yeah, I ran into selftest placing objects in the src dir a few years ago, and sent patches