On Mon, May 09 2022, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote: >> On Fri, May 06 2022, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > I would expect them to work, they seemed happy when I was doing >> > the async mode support IIRC and a quick spin with -next in qemu >> > everything seems fine, I'm travelling so don't have the >> > environment for models to hand right now. > >> Thanks; I think that points to some setup/config problem on my side, >> then :/ (I ran the selftests under QEMU's tcg emulation, and while it >> looks better, I still get timeouts for check_gcr_el1_cswitch and >> check_user_mem.) > > That might just be an actual timeout depending on the preformance of > the host system. Our mails may have crossed mid-air; the tests finish for me eventually. > >> >> where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an >> >> initrd built by mbuto[3] from that level with a slightly tweaked "kselftests" >> >> profile (adding /dev/shm). > >> > What are you using for EL3 with the model? Both TF-A and >> > boot-wrapper are in regular use, TF-A gets *way* more testing >> > than boot-wrapper which is mostly used by individual developers. > >> I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3, >> if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm >> still in the process of getting familiar with the arm64 world, so I'm >> currently starting out with the setups that others had shared with me.) > > I'm now back with the models and it turns out that while qemu is happy I > can reproduce what you're seeing with the model, at least as far back as > v5.15 which suggests it's likely to be more operator error than a bug. > Trying to figure it out now. Ok, thanks for looking.
