[LTP] LTP release

Jan Stancek
2018-01-10T11:26:13Z

----- Original Message -----
> On Wed, Jan 10, 2018 at 2:47 AM, Jan Stancek <jstancek@redhat.com> wrote:
>
> >
> >
> > ----- Original Message -----
> > > Hi!
> > > This is just a reminder that we should start working on the January
> > > stable release.
> > >
> > > I see that we included the meltdown test which I guess was one of the
> > > important enough patches to be included.
> > >
> > > Anything else that should be taken in before we freeze the git?
> > >
> > > I've did some preliminary testing (compiling and runnign LTP on a few
> > > selected distros) and haven't found any big issues so far, so it looks
> > > like this may as well be smoothest release ever (fingers crossed).
> >
> > I ran a test couple days ago with snapshot from 20180103 on RHEL6.2/6.9
> > and RHEL7.5(beta) across i386/x86_64/ppc64(le)/s390x. I'm planning
> > to try also some recent upstream kernel, but as you said so far
> > it looks good.
> >
>
> ​I ran LTP on the upstream kernel-4.15-rc6 across x86_64/ppc64(le)/s390x​,
> and catch some failures as below, ​but currently I haven't get a chance to
> look into the detail, just post here.​
>
>
> migrate_pages02 FAIL x86_64
> ------------------------------
> migrate_pages02 0 TINFO : pid(15539) migrate pid 0 to node -> 0
> migrate_pages02 9 TPASS : pid(15539) addr 0x194f840 is on expected
> node: 0
> migrate_pages02 10 TFAIL : migrate_pages02.c:165: pid(15539) addr
> 0x194f840 not on expected node: 0 , expected 1
> migrate_pages02 0 TINFO : mem_stats pid: 15539, node: 1
> migrate_pages02 0 TINFO : Node id: 1, size: 2044157952, free:
> 1439322112
> migrate_pages02 0 TINFO : pid(15535) migrate pid 15539 to node -> 1
> migrate_pages02 9 TFAIL : migrate_pages02.c:129: migrate_pages
> failed ret: -1, : errno=EPERM(1): Operation not permitted
> migrate_pages02 0 TINFO : mem_stats pid: 15539, node: 1
> migrate_pages02 0 TINFO : Node id: 1, size: 2044157952, free:
> 1439358976
> migrate_pages02 10 TFAIL : migrate_pages02.c:301: child returns 256

numactl -H output could be helpful here.

>
>
>
> msgctl11 FAIL s390x
> ----------------------
> msgctl11 0 TINFO : Found 32000 available message queues
> msgctl11 0 TINFO : Using upto 32698 pids
> Fork failure in the second child of child group 682
> Fork failure in the first child of child group 9
> Fork failure in the first child of child group 191
> ...
> Fork failure in the first child of child group 1490
> Fork failure in the first child of child group 1432
> Fork failure in the second child of child group 1326
> Fork failure in the first child of child group 1327
> Fork failure in the first child of child group 638
> msgctl11 1 TFAIL : msgctl11.c:205: Fork failed (may be OK if under
> stress)

I have very old note this test spawns large number of children, so
I'm assuming this is not a regression.

>
>
>
> shmt02/03/04/05/06/07/08/09/10 FAIL ppc64
> -------------------------------------------
> shmt02 1 TFAIL : shmt02.c:71: shmget Failed: shmid = -1, errno = 22
> shmt03 1 TFAIL : shmt03.c:72: shmget Failed: shmid = -1, errno = 22
> ...
> shmt10 2 TFAIL : shmt10.c:98: Error: shmid = -1
>
>
>
> switch01 FAIL ppc64(le)
> ------------------------
> endian_switch01 1 TFAIL : endian_switch01.c:127: Got SIGILL - test
> failed

This is new failure since 4.15-rc1:
commit 727f13616c45caa72e4325c5027c1a8f41e745a9
Author: Michael Ellerman <mpe@ellerman.id.au>
Date: Mon Oct 9 21:54:05 2017 +1100
powerpc: Disable the fast-endian switch syscall by default

One way would be to check if "/boot/config-$(uname -r)" exists
and contains "CONFIG_PPC_FAST_ENDIAN_SWITCH=y".

Or perhaps we can try to make switch only (0x1ebe), check if that
returns ENOSYS. If not we run current do_le_switch(). I'll try
this latter approach.

Regards,
Jan