On 15.10.2012 [16:26:48 -0300], Lucas Meneghel Rodrigues wrote:
> On 10/15/2012 04:14 PM, Gawlas, Julius wrote:
> >We are running nightly tests suite that exercises new kernel and one of the 
> >tests is libhugetlbfs. We are plugging in into standard libhugetlbfs using 
> >libhugetlbfs-2.0.tar.gz. We have seen lately intermittent problems where the 
> >suite will just hang somewhere in the middle of
> >
> >$ make  check OBJDIRS=obj64
> >...
> >linkhuge_rw
> >
> >(Note that we don't really know much about that test, we just picked it up 
> >as part of regression suite)
> >
> >After checking the libhugetlbfs site it turns out latest library is 
> >libhugetlbfs-2.14, so we picked it up and attempted to run tests based on 
> >that. But on 64 bits this fails as well:
> >
> >$ make  check OBJDIRS=obj64
> >     LD64 (lib test) obj64/huge_below_4GB_normal_above
> >     CC32 obj32/shmoverride_linked.o
> >   stderr:
> >   /usr/bin/ld: warning: zero_filesize_segment.ld contains output sections; 
> > did you forget -T?
> >   In file included from /usr/include/features.h:385,
> >                    from /usr/include/sys/types.h:26,
> >                    from shmoverride_linked.c:18:
> >   /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or 
> > directory
> >   make[1]: *** [obj32/shmoverride_linked.o] Error 1
> >   make: *** [tests/all] Error 2
> >
> >
> >Mailing list archive for libhugetlbfs seems to be filled with spam.
> >
> >Anybody can help or shed any light on this? Any help or pointers would be 
> >appreciated. Is that test bogus?
> 
> No, it's not. We just have not been executing it regularly, one
> thing that I do want to change in the near future on our next
> regression suite. Seems like maintenance is required here:
> 
> 1) Verify whether those tests were incorporated by another large
> suite, such as LTP, and being maintained there.
> 2) If people are maintaining the tests elsewhere, we'll use the
> source from that place, and update the wrapper, or eventually drop
> this wrapper in favor of running the larger suite.
> 3) If no one is maintaining this code and it wasn't assimilated by a
> larger suite, it makes sense to debug the failures and start fixing
> them, and create our own fork hosted on autotest's github area.
> 
> I'll be happy to help with all that.

I'm one of the former maintainers of the project. Will get the right
folks involved.

-Nish

_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel

Reply via email to