| Message ID | 20230309115714.906369-1-kraxel@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Thu, 9 Mar 2023 at 11:58, Gerd Hoffmann <kraxel@redhat.com> wrote: > > The following changes since commit 9832009d9dd2386664c15cc70f6e6bfe062be8bd: > > Merge tag 'pull-riscv-to-apply-20230306' of https://gitlab.com/palmer-dabbelt/qemu into staging (2023-03-07 12:53:00 +0000) > > are available in the Git repository at: > > https://gitlab.com/kraxel/qemu.git tags/edk2-stable202302-20230309-pull-request > > for you to fetch changes up to 75bc97ac50634229fa9da45faa1fa64bbe6024c7: > > edk2: update firmware binaries (2023-03-09 12:49:29 +0100) > > ---------------------------------------------------------------- > edk2: update to 202302 stable tag > > ---------------------------------------------------------------- > > Gerd Hoffmann (3): > edk2: update submodule to edk2-stable202302 > edk2: replace build scripts > edk2: update firmware binaries The docker-edk2 CI job fails: https://gitlab.com/qemu-project/qemu/-/jobs/3910666498 Step 1/3 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not 'application/vnd.oci.image.manifest.v1+json' This may be fixable with an equivalent of: https://lore.kernel.org/qemu-devel/20230224212543.20462-2-palmer@rivosinc.com/ for .gitlab-ci.d/edk2.yml What I still do not understand is why we have both: (1) binaries of edk2 committed to git (2) a gitlab CI job that is building edk2 The bios-tables-test also fails: https://gitlab.com/qemu-project/qemu/-/jobs/3910666555 (but also seen on other configs): ▶ 206/206 ERROR:../tests/qtest/acpi-utils.c:158:acpi_find_rsdp_address_uefi: code should not be reached ERROR 206/206 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test ERROR 706.75s killed by signal 6 SIGABRT (I also tested this with the qga and hexagon pullreqs, but neither of those should have affected this.) thanks -- PMM
On 10/3/23 12:30, Peter Maydell wrote: > On Thu, 9 Mar 2023 at 11:58, Gerd Hoffmann <kraxel@redhat.com> wrote: >> Gerd Hoffmann (3): >> edk2: update submodule to edk2-stable202302 >> edk2: replace build scripts >> edk2: update firmware binaries > > The docker-edk2 CI job fails: > https://gitlab.com/qemu-project/qemu/-/jobs/3910666498 > > Step 1/3 : FROM ubuntu:18.04 > 18.04: Pulling from library/ubuntu > mediaType in manifest should be > 'application/vnd.docker.distribution.manifest.v2+json' not > 'application/vnd.oci.image.manifest.v1+json' > > This may be fixable with an equivalent of: > https://lore.kernel.org/qemu-devel/20230224212543.20462-2-palmer@rivosinc.com/ > for .gitlab-ci.d/edk2.yml > > What I still do not understand is why we have both: > (1) binaries of edk2 committed to git > (2) a gitlab CI job that is building edk2 Originally we wanted to have reproducible images by: - pushing code change to gitlab (commit #1), - building the FW images on gitlab, - downloading & testing them, - committing the images (commit #2). Since we never used that, we can probably remove the docker-edk2 CI job which already bitrotted...
Hi Gerd, On 9/3/23 12:57, Gerd Hoffmann wrote: > The following changes since commit 9832009d9dd2386664c15cc70f6e6bfe062be8bd: > > Merge tag 'pull-riscv-to-apply-20230306' of https://gitlab.com/palmer-dabbelt/qemu into staging (2023-03-07 12:53:00 +0000) > > are available in the Git repository at: > > https://gitlab.com/kraxel/qemu.git tags/edk2-stable202302-20230309-pull-request > > for you to fetch changes up to 75bc97ac50634229fa9da45faa1fa64bbe6024c7: > > edk2: update firmware binaries (2023-03-09 12:49:29 +0100) > > ---------------------------------------------------------------- > edk2: update to 202302 stable tag > > ---------------------------------------------------------------- > > Gerd Hoffmann (3): > edk2: update submodule to edk2-stable202302 Please update pc-bios/README: The images were built at git tag "edk2-stable202008". The firmware binaries bundle parts of the OpenSSL project, at git tag "OpenSSL_1_1_1g" (the OpenSSL tag is a function of the edk2 tag). Parts of the Berkeley SoftFloat library are bundled as well, at Release 3e plus a subsequent typo fix (commit b64af41c3276f97f0e181920400ee056b9c88037), as an OpenSSL dependency on 32-bit ARM. > edk2: replace build scripts > edk2: update firmware binaries
Hi, > ▶ 206/206 ERROR:../tests/qtest/acpi-utils.c:158:acpi_find_rsdp_address_uefi: > code should not be reached ERROR > 206/206 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test > ERROR 706.75s killed by signal 6 SIGABRT mst? laszlo? Any hints how to debug that? Tried to start qemu manually with the command line I get from "make V=1 check-qtest-aarch64", that seems to start the uefi app from the iso image just fine ... take care, Gerd
On 3/15/23 16:56, Gerd Hoffmann wrote: > Hi, > >> ▶ 206/206 ERROR:../tests/qtest/acpi-utils.c:158:acpi_find_rsdp_address_uefi: >> code should not be reached ERROR >> 206/206 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test >> ERROR 706.75s killed by signal 6 SIGABRT > > mst? laszlo? Any hints how to debug that? > > Tried to start qemu manually with the command line I get from > "make V=1 check-qtest-aarch64", that seems to start the uefi > app from the iso image just fine ... This is strange, the search is supposed to continue for 600 seconds (see TEST_DELAY and TEST_CYCLES). I've got no better idea than to run the UEFI application, then dump the guest memory from the QEMU monitor, and then fish around in it... Laszlo
On Wed, Mar 15, 2023 at 05:16:10PM +0100, Laszlo Ersek wrote: > On 3/15/23 16:56, Gerd Hoffmann wrote: > > Hi, > > > >> ▶ 206/206 ERROR:../tests/qtest/acpi-utils.c:158:acpi_find_rsdp_address_uefi: > >> code should not be reached ERROR > >> 206/206 qemu:qtest+qtest-aarch64 / qtest-aarch64/bios-tables-test > >> ERROR 706.75s killed by signal 6 SIGABRT > > > > mst? laszlo? Any hints how to debug that? > > > > Tried to start qemu manually with the command line I get from > > "make V=1 check-qtest-aarch64", that seems to start the uefi > > app from the iso image just fine ... > > This is strange, the search is supposed to continue for 600 seconds (see > TEST_DELAY and TEST_CYCLES). I've got no better idea than to run the > UEFI application, then dump the guest memory from the QEMU monitor, and > then fish around in it... Turned out to be the numa test case only, and edk2 not booting due to small numa nodes. take care, Gerd