failing tests on sparc64-ieee1275 target

failing tests on sparc64-ieee1275 target

[Glenn Washburn]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

Hi,

I'm running the sparc tests and running into some odd failures. Is
anyone running these tests successfully? I've attached the
test-suite.log which shows a bash trace of each failing test. There are
many failing fs tests with hard errors, those can be ignored. The last
4 tests are the pertinent ones. Also included are the qemu output files.
I'll discuss briefly each failing test below in the order which they
appear in the log file.

*** grub_script_expansion
It looks like qemu or the firmware is hitting and exception output. Both
disks and other are the string "Unhandled Exception 0x0000000000000030
PC = 0x00000000ffd0f370 NPC = 0x00000000ffd0f374
Stopping execution". I'm using the firmware from Ubuntu's
openbios-sparc package. Is there a better one? Does this actually work
for anyone?

*** gzcompress_test
This test is failing because the 60 minute timeout for qemu in
grub-shell has run out. The output file shows "error: ELF header
smaller than expected." many times and then goes to the rescue shell
and waits for the time out. An idea what is causing this? I'm guessing
a build issue, but the build completed successfully.

*** grub_func_test
The signature test and sleep tests are failing. I'm guessing for the
sleep that there's an issue with the VM's clock. And for the signature
test, it says "no cmos found". Could this be an issue with the Ubuntu
firmware package?

*** file_filter_test
There's a clear issue with xz decompression because of the error
message "error: xz file corrupted or unsupported block options." Since
this works many other places, what makes sparc different? Could it be
the xz test file is endian specific? A subtler issue is that catting the
gzip file does not show the expected output, but does not show an error
message either. So something seeing to be failing there. The catted lzop
file does show the correct output, so the failures seem to be decoder
specific.

What's that is odd is that all of the other grub qemu tests are
successful. Anyone else run in to these issues and know how I might be
able to get these tests working if these aren't genuine bugs?

Glenn

[-- Attachment #2: test-suite.log.xz --]
[-- Type: application/x-xz, Size: 16756 bytes --]

[-- Attachment #3: file_filter_test.qemu.out --]
[-- Type: application/octet-stream, Size: 1447 bytes --]

[-- Attachment #4: grub_func_test.qemu.out --]
[-- Type: application/octet-stream, Size: 2363 bytes --]

[-- Attachment #5: grub_script_expansion.qemu.out --]
[-- Type: application/octet-stream, Size: 1483 bytes --]

[-- Attachment #6: gzcompress_test.qemu.out --]
[-- Type: application/octet-stream, Size: 1847 bytes --]

Re: failing tests on sparc64-ieee1275 target

[John Paul Adrian Glaubitz]

Hello!

On 12/19/20 7:29 AM, Glenn Washburn wrote:
> I'm running the sparc tests and running into some odd failures. Is
> anyone running these tests successfully? I've attached the
> test-suite.log which shows a bash trace of each failing test. There are
> many failing fs tests with hard errors, those can be ignored. The last
> 4 tests are the pertinent ones. Also included are the qemu output files.
> I'll discuss briefly each failing test below in the order which they
> appear in the log file.

I don't think we're running the tests on anything besides x86 in Debian,
but you can check the build logs here:

> https://buildd.debian.org/status/package.php?p=grub2&suite=sid

To view a build log, click on any entry in the "Status" column.

FWIW, we're deploying GRUB on Debian/sparc64 without any issues both for
installation media and hard disks. If you want, you can run the tests on
real hardware through the GCC compile farm [1].

Adrian

> [1] https://gcc.gnu.org/wiki/CompileFarm

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: failing tests on sparc64-ieee1275 target

[Glenn Washburn]

Hi Adrian,

On Sat, 19 Dec 2020 21:53:54 +0100
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

> Hello!
> 
> On 12/19/20 7:29 AM, Glenn Washburn wrote:
> > I'm running the sparc tests and running into some odd failures. Is
> > anyone running these tests successfully? I've attached the
> > test-suite.log which shows a bash trace of each failing test. There
> > are many failing fs tests with hard errors, those can be ignored.
> > The last 4 tests are the pertinent ones. Also included are the qemu
> > output files. I'll discuss briefly each failing test below in the
> > order which they appear in the log file.
> 
> I don't think we're running the tests on anything besides x86 in
> Debian, but you can check the build logs here:
> 
> > https://buildd.debian.org/status/package.php?p=grub2&suite=sid
> 
> To view a build log, click on any entry in the "Status" column.

Who is "we" here? Debian maintainers for grub2? Thanks for this info.
Looking at the logs for amd64 and i386, the "make check" test are not
actually being run. Are those the tests that you're referring to? I'm I
missing it in the logs? To be clear, I have no issues building for
sparc64.

> FWIW, we're deploying GRUB on Debian/sparc64 without any issues both
> for installation media and hard disks. If you want, you can run the
> tests on real hardware through the GCC compile farm [1].
> 
> Adrian
> 
> > [1] https://gcc.gnu.org/wiki/CompileFarm

Thanks for this suggestion, its been mentioned before and seems like a
pretty cool project. However, I'm failing to see how it could be useful
here. My problem is with the "make check" tests which are setup to be
run in a virtual machine. I could do a build for sparc64 on the compile
farm, but how run I run the tests which require a grub boot? From what
I can tell, the compile farm doesn't allow testing of the boot of a
sparc64 machine. Without virtualization, that would require some kind
of kvm/serial access. How exactly are you thinking I could run the
tests on real hardware through the GCC compile farm?

Glenn