Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Tue, Aug 5, 2014 at 10:47 AM, Peter Meerwald wrote: > >> On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: >> > could you please try to pass --enable-neon-opt for the armhf build? I >> > think ARMHF is supposed to provide NEON support >> >> Armhf seems to be autodetecting neon[1]. However, NEON is not >> guaranteed to be available on armhf, so runtime detection is required. > > right armhf does not imply NEON, see > https://wiki.debian.org/ArmHardFloatPort#NEON Yes, I saw it there too :) > >> [1] >> https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 > > I managed to get a Debian jessie PPC image running and could reproduce the > mix-test issue; let's see OK, I've anyway uploaded to experimental a build reenabling the tests with both your patches. The results should start appearing at [1] as they become available [1] https://buildd.debian.org/status/package.php?p=pulseaudio&suite=experimental -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
> On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: > > could you please try to pass --enable-neon-opt for the armhf build? I > > think ARMHF is supposed to provide NEON support > > Armhf seems to be autodetecting neon[1]. However, NEON is not > guaranteed to be available on armhf, so runtime detection is required. right armhf does not imply NEON, see https://wiki.debian.org/ArmHardFloatPort#NEON > [1] > https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 I managed to get a Debian jessie PPC image running and could reproduce the mix-test issue; let's see p. -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: > could you please try to pass --enable-neon-opt for the armhf build? I > think ARMHF is supposed to provide NEON support Armhf seems to be autodetecting neon[1]. However, NEON is not guaranteed to be available on armhf, so runtime detection is required. AFAICS pulse does runtime detect neon, so we should be OK. [1] https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=armhf&ver=5.0-6&stamp=1407203063 -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Mon, Aug 4, 2014 at 11:55 AM, Peter Meerwald wrote: >> > posted here >> > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021051.html >> >> Still failing on powerpc and s390x. > > do you have the link to the build bot? > that was rather helpful last time No, I don't. I ran these on the porterboxes, not on the build farm. I'll schedule a build tonight on the build farm. >> >> I'm also getting this (after disabling timeouts) on powerpc: >> >> tests/once-test.c:74:F:once:once_test:0: Assertion >> 'pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask) == 0' >> failed > > hm > >> > >> > and here >> > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021053.html >> >> I haven't tested that yet. I did also apply this patch to build >> correctly on kFreeBSD: >> >> http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/tree/debian/patches/gnu-kfreebsd.patch > > I disagree with the patch; why should the SSE optimizations be disabled > when running a FreeBSD kernel? I don't really know. I just mimicked commit b0a04d8031f9ef, which does not give much info, unfortunately. I presumed the problem was with the kernel and not the compiler, but of course I could be wrong. -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
> > posted here > > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021051.html > > Still failing on powerpc and s390x. do you have the link to the build bot? that was rather helpful last time > > I'm also getting this (after disabling timeouts) on powerpc: > > tests/once-test.c:74:F:once:once_test:0: Assertion > 'pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask) == 0' > failed hm > > > > and here > > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021053.html > > I haven't tested that yet. I did also apply this patch to build > correctly on kFreeBSD: > > http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/tree/debian/patches/gnu-kfreebsd.patch I disagree with the patch; why should the SSE optimizations be disabled when running a FreeBSD kernel? > I will send it when I rebase it to current git head. p. -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Mon, Aug 4, 2014 at 9:10 AM, Peter Meerwald wrote: > Hello, > >> > I think pa_mix_s24_32re_c() is simply wrong, and has never worked; it >> > should advance m->ptr by sizeof(int32_t), not 3 -- will submit a fix and >> > update the test code >> >> I can test the patch, if you can send me one :) > > posted here > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021051.html Still failing on powerpc and s390x. I'm also getting this (after disabling timeouts) on powerpc: tests/once-test.c:74:F:once:once_test:0: Assertion 'pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask) == 0' failed > > and here > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021053.html I haven't tested that yet. I did also apply this patch to build correctly on kFreeBSD: http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/tree/debian/patches/gnu-kfreebsd.patch I will send it when I rebase it to current git head. > could you please try to pass --enable-neon-opt for the armhf build? I > think ARMHF is supposed to provide NEON support I'm not sure. I'll check and if so I will enable it. -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
Hello, > > I think pa_mix_s24_32re_c() is simply wrong, and has never worked; it > > should advance m->ptr by sizeof(int32_t), not 3 -- will submit a fix and > > update the test code > > I can test the patch, if you can send me one :) posted here http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021051.html and here http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021053.html could you please try to pass --enable-neon-opt for the armhf build? I think ARMHF is supposed to provide NEON support p. -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
On Fri, Aug 1, 2014 at 2:14 AM, Peter Meerwald wrote: > > Hello, Hi, > > > In the latest version of pulseaudio in Debian I enabled the test suite > > at build time. Unfortunately, this resulted in failures in almost all > > thanks for reporting! > > > builds[1]. Several test failures occurred due to timeouts, which I > > think could be fixed by simply extending the timeout period. These are > > either in the thread or volume tests. However, many tests failed due > > to assertions: > > I'm trying to reproduce (which is tedious); it would be easier if one > could investigate the build machines... The build machines themselves are restricted. But I have access to machines that are hopefully similar enough, provided by Debian. So I can try any patches you offer for build, but unfortunately not for actual audio playing. There is a process to get access to the porter boxes to third-parties, so if you are interested we could arrange that, but it will probably take some time to set up. > > > On freebsd, we couldn't build: > > > > Debian does not #define __FreeBSD__ but instead defines > > __FreeBSD_kernel__. This seems to have changed recently. I don't know > > if real FreeBSD defines the kernel variant, but > > > On hurd-i386: > > > > tests/get-binary-name-test.c:44:F:getbinaryname:getbinaryname_test:0: Failed > > gah, I'm not going to install hurd :) :) > this tests one function, pa_get_binary_name() in src/pulse/util.c, if > /proc/self/exe exists, an #ifdef could be added for hard Hmm, this indeed appears to be missing functionality in hurd: https://lists.gnu.org/archive/html/help-hurd/2011-10/msg3.html > > I think pa_mix_s24_32re_c() is simply wrong, and has never worked; it > should advance m->ptr by sizeof(int32_t), not 3 -- will submit a fix and > update the test code I can test the patch, if you can send me one :) > > > On armel: > > > > tests/mix-test.c:266:F:mix:mix_test:0: Assertion '*u == *v' failed > > > > On Powerpc: > > > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > > > On s390x: > > > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > > > On mips: > > > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > > > On sparc: > > > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > > I may need to disable it anyway because on some archs the thread-test > > seems to take just too long (or perhaps there is a race?). But I > > thought I should report here the results anyway. > > is this emulated or real hardware; some tests take long, so we could just > increase the allowed time I can't remember which architecture appeared to hang, but I can try again tomorrow hopefully. But they where all real hardware, except for the kfreebsd boxes. I was thinking of just disabling the timeouts by setting CK_TIMEOUT_MULTIPLIER to 0. The debian build daemons do have a timeout killer as well. -- Saludos, Felipe Sateler ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio test suite failures
Hello, > In the latest version of pulseaudio in Debian I enabled the test suite > at build time. Unfortunately, this resulted in failures in almost all thanks for reporting! > builds[1]. Several test failures occurred due to timeouts, which I > think could be fixed by simply extending the timeout period. These are > either in the thread or volume tests. However, many tests failed due > to assertions: I'm trying to reproduce (which is tedious); it would be easier if one could investigate the build machines... > On freebsd, we couldn't build: > > Debian does not #define __FreeBSD__ but instead defines > __FreeBSD_kernel__. This seems to have changed recently. I don't know > if real FreeBSD defines the kernel variant, but > On hurd-i386: > > tests/get-binary-name-test.c:44:F:getbinaryname:getbinaryname_test:0: Failed gah, I'm not going to install hurd :) this tests one function, pa_get_binary_name() in src/pulse/util.c, if /proc/self/exe exists, an #ifdef could be added for hard I think pa_mix_s24_32re_c() is simply wrong, and has never worked; it should advance m->ptr by sizeof(int32_t), not 3 -- will submit a fix and update the test code > On armel: > > tests/mix-test.c:266:F:mix:mix_test:0: Assertion '*u == *v' failed > > On Powerpc: > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > On s390x: > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > On mips: > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > > On sparc: > > tests/mix-test.c:180:F:mix:mix_test:0: Assertion '*u == *v' failed > I may need to disable it anyway because on some archs the thread-test > seems to take just too long (or perhaps there is a race?). But I > thought I should report here the results anyway. is this emulated or real hardware; some tests take long, so we could just increase the allowed time > > [1] > https://buildd.debian.org/status/logs.php?pkg=pulseaudio&ver=5.0-3&suite=sid > > -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
