glibc 2.34 failed tests

glibc 2.34 failed tests

[Michael Brunnbauer]

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


hi all,

these are my test failures for glibc 2.34:

FAIL: malloc/tst-mxfast-mcheck
FAIL: malloc/tst-tcfree2
FAIL: nss/tst-nss-files-hosts-multi
FAIL: resolv/tst-bug18665
FAIL: resolv/tst-resolv-search
FAIL: rt/tst-mqueue10
FAIL: time/tst-itimer

In comparison, those failed for 2.33 - which I use in production:

FAIL: elf/tst-dlopenfail
FAIL: malloc/tst-safe-linking
FAIL: malloc/tst-tcfree2
FAIL: nss/tst-nss-files-hosts-multi
FAIL: resolv/tst-bug18665
FAIL: resolv/tst-resolv-search

Should I worry? Here are the .out files for the new failures:

cat ./malloc/tst-mxfast-mcheck.out
tst-mxfast.c:49: numeric comparison failure
   left: 2 (0x2); from: m.smblks
  right: 0 (0x0); from: 0
error: 1 test failures

cat ./rt/tst-mqueue10.out
error: tst-mqueue10.c:46: not true: q != (mqd_t) -1
error: 1 test failures

cat ./time/tst-itimer.out
tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
   left: 10000 (0x2710); from: it_old.it_interval.tv_usec
  right: 20 (0x14); from: 20
tst-itimer.c:90: numeric comparison failure
   left: 20 (0x14); from: it.it_interval.tv_usec
  right: 10000 (0x2710); from: it_old.it_interval.tv_usec
tst-itimer.c:118: numeric comparison failure
   left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
  right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
   left: 0 (0x0); from: it_old.it_interval.tv_usec
  right: 20 (0x14); from: 20
tst-itimer.c:141: numeric comparison failure
   left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
  right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
tst-itimer.c:142: numeric comparison failure
   left: 20 (0x14); from: it.it_interval.tv_usec
  right: 0 (0x0); from: it_old.it_interval.tv_usec
tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
   left: 10000 (0x2710); from: it_old.it_interval.tv_usec
  right: 20 (0x14); from: 20
tst-itimer.c:90: numeric comparison failure
   left: 20 (0x14); from: it.it_interval.tv_usec
  right: 10000 (0x2710); from: it_old.it_interval.tv_usec
tst-itimer.c:118: numeric comparison failure
   left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
  right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
   left: 0 (0x0); from: it_old.it_interval.tv_usec
  right: 20 (0x14); from: 20
tst-itimer.c:141: numeric comparison failure
   left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
  right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
tst-itimer.c:142: numeric comparison failure
   left: 20 (0x14); from: it.it_interval.tv_usec
  right: 0 (0x0); from: it_old.it_interval.tv_usec
error: 12 test failures

thnx,
cu,
brunni

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: glibc 2.34 failed tests

[Siddhesh Poyarekar]

On Tue, 3 Aug 2021 at 21:45, Michael Brunnbauer <brunni@netestate.de> wrote:
> cat ./malloc/tst-mxfast-mcheck.out
> tst-mxfast.c:49: numeric comparison failure
>    left: 2 (0x2); from: m.smblks
>   right: 0 (0x0); from: 0
> error: 1 test failures

This failure is harmless; tst-mxfast should not be built with lmcheck
since the sizes requested get altered and may not always return a
predictable result.  I haven't taken a closer look at the other two
but please report them on bugzilla (one for each failure) along with
your build configuration so that the developers can reproduce the
problem.

Thanks,
Siddhesh

Re: glibc 2.34 failed tests

[Adhemerval Zanella]

On 03/08/2021 13:15, Michael Brunnbauer wrote:
> 
> hi all,
> 
> these are my test failures for glibc 2.34:
> 
> FAIL: malloc/tst-mxfast-mcheck
> FAIL: malloc/tst-tcfree2
> FAIL: nss/tst-nss-files-hosts-multi
> FAIL: resolv/tst-bug18665
> FAIL: resolv/tst-resolv-search
> FAIL: rt/tst-mqueue10
> FAIL: time/tst-itimer
> 
> In comparison, those failed for 2.33 - which I use in production:
> 
> FAIL: elf/tst-dlopenfail

This is a new failure, could you post the .out output?

> FAIL: malloc/tst-safe-linking

Siddhesh has improved it to avoid some false positives, but from from
the commit message it seems that although unlikely it might still be
possible. Could you post the output to see if this is the case?

> FAIL: malloc/tst-tcfree2

This is another new failure., could you post the .out output as well?

> FAIL: nss/tst-nss-files-hosts-multi
> FAIL: resolv/tst-bug18665
> FAIL: resolv/tst-resolv-search

I recall this might fail depending of how the system network is configured.
What .out file shows?

> 
> Should I worry? Here are the .out files for the new failures:
> 
> cat ./malloc/tst-mxfast-mcheck.out
> tst-mxfast.c:49: numeric comparison failure
>    left: 2 (0x2); from: m.smblks
>   right: 0 (0x0); from: 0
> error: 1 test failures
> 
> cat ./rt/tst-mqueue10.out
> error: tst-mqueue10.c:46: not true: q != (mqd_t) -1
> error: 1 test failures

I think this might be related to the fact rt/tst-mqueue10.c uses the
"/tst-mqueue2-" as template (it might interfere with rt/tst-mqueue2.c
itself).

> 
> cat ./time/tst-itimer.out
> tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
>    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
>   right: 20 (0x14); from: 20
> tst-itimer.c:90: numeric comparison failure
>    left: 20 (0x14); from: it.it_interval.tv_usec
>   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
> tst-itimer.c:118: numeric comparison failure
>    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
> tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
>    left: 0 (0x0); from: it_old.it_interval.tv_usec
>   right: 20 (0x14); from: 20
> tst-itimer.c:141: numeric comparison failure
>    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
>   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> tst-itimer.c:142: numeric comparison failure
>    left: 20 (0x14); from: it.it_interval.tv_usec
>   right: 0 (0x0); from: it_old.it_interval.tv_usec
> tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
>    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
>   right: 20 (0x14); from: 20
> tst-itimer.c:90: numeric comparison failure
>    left: 20 (0x14); from: it.it_interval.tv_usec
>   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
> tst-itimer.c:118: numeric comparison failure
>    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
> tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
>    left: 0 (0x0); from: it_old.it_interval.tv_usec
>   right: 20 (0x14); from: 20
> tst-itimer.c:141: numeric comparison failure
>    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
>   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> tst-itimer.c:142: numeric comparison failure
>    left: 20 (0x14); from: it.it_interval.tv_usec
>   right: 0 (0x0); from: it_old.it_interval.tv_usec
> error: 12 test failures

I almost sure this is the same issue I saw on an older kernel under KVM [1]

[1] https://patchwork.sourceware.org/project/glibc/patch/20210719163846.2954193-3-adhemerval.zanella@linaro.org/

Re: glibc 2.34 failed tests

[Siddhesh Poyarekar]

On Wed, Aug 4, 2021 at 5:26 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> > FAIL: malloc/tst-safe-linking
>
> Siddhesh has improved it to avoid some false positives, but from from
> the commit message it seems that although unlikely it might still be
> possible. Could you post the output to see if this is the case?

I think Michael said he saw that failure in 2.33 and not on 2.34,
which is how it should be with my fix.

Siddhesh

Re: glibc 2.34 failed tests

[Adhemerval Zanella]

On 04/08/2021 09:00, Siddhesh Poyarekar wrote:
> On Wed, Aug 4, 2021 at 5:26 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>> FAIL: malloc/tst-safe-linking
>>
>> Siddhesh has improved it to avoid some false positives, but from from
>> the commit message it seems that although unlikely it might still be
>> possible. Could you post the output to see if this is the case?
> 
> I think Michael said he saw that failure in 2.33 and not on 2.34,
> which is how it should be with my fix.
> 
> Siddhesh
> 

But the test was added only on 2.34 (assuming he is testing with the release
package). Micheal, are you using the source package or some repository revision?

Re: glibc 2.34 failed tests

[Siddhesh Poyarekar]

On Wed, Aug 4, 2021 at 5:33 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 04/08/2021 09:00, Siddhesh Poyarekar wrote:
> > On Wed, Aug 4, 2021 at 5:26 PM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> >>> FAIL: malloc/tst-safe-linking
> >>
> >> Siddhesh has improved it to avoid some false positives, but from from
> >> the commit message it seems that although unlikely it might still be
> >> possible. Could you post the output to see if this is the case?
> >
> > I think Michael said he saw that failure in 2.33 and not on 2.34,
> > which is how it should be with my fix.
>
> But the test was added only on 2.34 (assuming he is testing with the release
> package). Micheal, are you using the source package or some repository revision?

No, the safe linking test was added in 2.32.

Siddhesh

Re: glibc 2.34 failed tests

[Adhemerval Zanella]

On 04/08/2021 09:08, Siddhesh Poyarekar wrote:
> On Wed, Aug 4, 2021 at 5:33 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 04/08/2021 09:00, Siddhesh Poyarekar wrote:
>>> On Wed, Aug 4, 2021 at 5:26 PM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>> FAIL: malloc/tst-safe-linking
>>>>
>>>> Siddhesh has improved it to avoid some false positives, but from from
>>>> the commit message it seems that although unlikely it might still be
>>>> possible. Could you post the output to see if this is the case?
>>>
>>> I think Michael said he saw that failure in 2.33 and not on 2.34,
>>> which is how it should be with my fix.
>>
>> But the test was added only on 2.34 (assuming he is testing with the release
>> package). Micheal, are you using the source package or some repository revision?
> 
> No, the safe linking test was added in 2.32.

Sorry, I meant the other tests (rt/tst-mqueue10 and time/tst-itimer), that's why
I think he is testing with 2.34. Also, the message title indicates it as well.

Re: glibc 2.34 failed tests

[Siddhesh Poyarekar]

On Wed, Aug 4, 2021 at 5:41 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> Sorry, I meant the other tests (rt/tst-mqueue10 and time/tst-itimer), that's why
> I think he is testing with 2.34. Also, the message title indicates it as well.

OK, there are two sets of results, one for 2.33 and another for 2.34 :)

Siddhesh

Re: glibc 2.34 failed tests

[Michael Brunnbauer]

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


hi

On Wed, Aug 04, 2021 at 08:56:17AM -0300, Adhemerval Zanella wrote:
> > FAIL: elf/tst-dlopenfail
> 
> This is a new failure, could you post the .out output?
> 
> > FAIL: malloc/tst-safe-linking

Those two failures occured with glibc 2.33 but not with 2.34 on my current 
machine.

> > FAIL: malloc/tst-tcfree2
> 
> This is another new failure., could you post the .out output as well?

FAIL: tcache double free
Expected signal 'Aborted' from child, got none

> > FAIL: nss/tst-nss-files-hosts-multi
> > FAIL: resolv/tst-bug18665
> > FAIL: resolv/tst-resolv-search
> 
> I recall this might fail depending of how the system network is configured.
> What .out file shows?

It's an ipv4 only system. Here are the outputs:

cat nss/tst-nss-files-hosts-multi.out
Timed out: killed the child process
Termination time: 2021-08-03T15:50:02.888711343
Last write to standard output: 2021-08-03T15:49:22.870384035

cat resolv/tst-bug18665.out
warning: unshare (CLONE_NEWUTS) failed: Invalid argument
warning: could not enter network namespace
Timed out: killed the child process
Termination time: 2021-08-03T15:48:22.269459412
Last write to standard output: 2021-08-03T15:48:02.250298068

cat resolv/tst-resolv-search.out
warning: unshare (CLONE_NEWUTS) failed: Invalid argument
warning: could not enter network namespace
Timed out: killed the child process
Termination time: 2021-08-03T15:48:52.829291960
Last write to standard output: 2021-08-03T15:48:32.810330616


> > cat ./rt/tst-mqueue10.out
> > error: tst-mqueue10.c:46: not true: q != (mqd_t) -1
> > error: 1 test failures
> 
> I think this might be related to the fact rt/tst-mqueue10.c uses the
> "/tst-mqueue2-" as template (it might interfere with rt/tst-mqueue2.c
> itself).

I opened a ticket for this one: https://sourceware.org/bugzilla/show_bug.cgi?id=28188

> > cat ./time/tst-itimer.out
> > tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
> >    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
> >   right: 20 (0x14); from: 20
> > tst-itimer.c:90: numeric comparison failure
> >    left: 20 (0x14); from: it.it_interval.tv_usec
> >   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
> > tst-itimer.c:118: numeric comparison failure
> >    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> >   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
> > tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
> >    left: 0 (0x0); from: it_old.it_interval.tv_usec
> >   right: 20 (0x14); from: 20
> > tst-itimer.c:141: numeric comparison failure
> >    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
> >   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> > tst-itimer.c:142: numeric comparison failure
> >    left: 20 (0x14); from: it.it_interval.tv_usec
> >   right: 0 (0x0); from: it_old.it_interval.tv_usec
> > tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
> >    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
> >   right: 20 (0x14); from: 20
> > tst-itimer.c:90: numeric comparison failure
> >    left: 20 (0x14); from: it.it_interval.tv_usec
> >   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
> > tst-itimer.c:118: numeric comparison failure
> >    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> >   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
> > tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
> >    left: 0 (0x0); from: it_old.it_interval.tv_usec
> >   right: 20 (0x14); from: 20
> > tst-itimer.c:141: numeric comparison failure
> >    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
> >   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
> > tst-itimer.c:142: numeric comparison failure
> >    left: 20 (0x14); from: it.it_interval.tv_usec
> >   right: 0 (0x0); from: it_old.it_interval.tv_usec
> > error: 12 test failures
> 
> I almost sure this is the same issue I saw on an older kernel under KVM [1]
> 
> [1] https://patchwork.sourceware.org/project/glibc/patch/20210719163846.2954193-3-adhemerval.zanella@linaro.org/

My machine is not a virtual one though. Here is the ticket for this one:

https://sourceware.org/bugzilla/show_bug.cgi?id=28189

cu,
brunni

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: glibc 2.34 failed tests

[Adhemerval Zanella]

On 04/08/2021 09:29, Michael Brunnbauer wrote:
> 
> hi
> 
> On Wed, Aug 04, 2021 at 08:56:17AM -0300, Adhemerval Zanella wrote:
>>> FAIL: elf/tst-dlopenfail
>>
>> This is a new failure, could you post the .out output?
>>
>>> FAIL: malloc/tst-safe-linking
> 
> Those two failures occured with glibc 2.33 but not with 2.34 on my current 
> machine.
> 
>>> FAIL: malloc/tst-tcfree2
>>
>> This is another new failure., could you post the .out output as well?
> 
> FAIL: tcache double free
> Expected signal 'Aborted' from child, got none
> 
>>> FAIL: nss/tst-nss-files-hosts-multi
>>> FAIL: resolv/tst-bug18665
>>> FAIL: resolv/tst-resolv-search
>>
>> I recall this might fail depending of how the system network is configured.
>> What .out file shows?
> 
> It's an ipv4 only system. Here are the outputs:
> 
> cat nss/tst-nss-files-hosts-multi.out
> Timed out: killed the child process
> Termination time: 2021-08-03T15:50:02.888711343
> Last write to standard output: 2021-08-03T15:49:22.870384035
> 
> cat resolv/tst-bug18665.out
> warning: unshare (CLONE_NEWUTS) failed: Invalid argument
> warning: could not enter network namespace
> Timed out: killed the child process
> Termination time: 2021-08-03T15:48:22.269459412
> Last write to standard output: 2021-08-03T15:48:02.250298068
> 
> cat resolv/tst-resolv-search.out
> warning: unshare (CLONE_NEWUTS) failed: Invalid argument
> warning: could not enter network namespace
> Timed out: killed the child process
> Termination time: 2021-08-03T15:48:52.829291960
> Last write to standard output: 2021-08-03T15:48:32.810330616

This is due the missing kernel support for network namespace, I think we
should set the tests as unsupported in this case.

> 
> 
>>> cat ./rt/tst-mqueue10.out
>>> error: tst-mqueue10.c:46: not true: q != (mqd_t) -1
>>> error: 1 test failures
>>
>> I think this might be related to the fact rt/tst-mqueue10.c uses the
>> "/tst-mqueue2-" as template (it might interfere with rt/tst-mqueue2.c
>> itself).
> 
> I opened a ticket for this one: https://sourceware.org/bugzilla/show_bug.cgi?id=28188

Thanks, but the only reason I see to this fail is if the kernel 
misses POSIX message queue support.  Could you check if your kernel
has CONFIG_POSIX_MQUEUE enabled? 

> 
>>> cat ./time/tst-itimer.out
>>> tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
>>>    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
>>>   right: 20 (0x14); from: 20
>>> tst-itimer.c:90: numeric comparison failure
>>>    left: 20 (0x14); from: it.it_interval.tv_usec
>>>   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
>>> tst-itimer.c:118: numeric comparison failure
>>>    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>>>   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
>>> tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
>>>    left: 0 (0x0); from: it_old.it_interval.tv_usec
>>>   right: 20 (0x14); from: 20
>>> tst-itimer.c:141: numeric comparison failure
>>>    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
>>>   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>>> tst-itimer.c:142: numeric comparison failure
>>>    left: 20 (0x14); from: it.it_interval.tv_usec
>>>   right: 0 (0x0); from: it_old.it_interval.tv_usec
>>> tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
>>>    left: 10000 (0x2710); from: it_old.it_interval.tv_usec
>>>   right: 20 (0x14); from: 20
>>> tst-itimer.c:90: numeric comparison failure
>>>    left: 20 (0x14); from: it.it_interval.tv_usec
>>>   right: 10000 (0x2710); from: it_old.it_interval.tv_usec
>>> tst-itimer.c:118: numeric comparison failure
>>>    left: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>>>   right: 8589934591 (0x1ffffffff); from: 0x1ffffffffull
>>> tst-itimer.c:119: numeric comparison failure (widths 64 and 32)
>>>    left: 0 (0x0); from: it_old.it_interval.tv_usec
>>>   right: 20 (0x14); from: 20
>>> tst-itimer.c:141: numeric comparison failure
>>>    left: 8589934591 (0x1ffffffff); from: it.it_interval.tv_sec
>>>   right: 2748779068 (0xa3d70a3c); from: it_old.it_interval.tv_sec
>>> tst-itimer.c:142: numeric comparison failure
>>>    left: 20 (0x14); from: it.it_interval.tv_usec
>>>   right: 0 (0x0); from: it_old.it_interval.tv_usec
>>> error: 12 test failures
>>
>> I almost sure this is the same issue I saw on an older kernel under KVM [1]
>>
>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210719163846.2954193-3-adhemerval.zanella@linaro.org/
> 
> My machine is not a virtual one though. Here is the ticket for this one:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28189

Thanks, but I do not think KVM is the only thing that changes the clock
precision here.
 

Re: glibc 2.34 failed tests

[Michael Brunnbauer]

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


hi,

On Wed, Aug 04, 2021 at 05:12:42PM -0300, Adhemerval Zanella wrote:
[...]
> >>> error: tst-mqueue10.c:46: not true: q != (mqd_t) -1
> 
> Thanks, but the only reason I see to this fail is if the kernel 
> misses POSIX message queue support.  Could you check if your kernel
> has CONFIG_POSIX_MQUEUE enabled? 

It was disabled. I have enabled it for my next kernel update but assume
it is not vital.

> >>> tst-itimer.c:76: numeric comparison failure (widths 64 and 32)
[...]
> 
> Thanks, but I do not think KVM is the only thing that changes the clock
> precision here.

I have CONFIG_HZ=100 and CONFIG_HZ_100=y. Is is relevant that ISC ntpd is running?

cu,
brunni

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]