[dpdk-ci] Failures reported by Intel CI for series 10551

[dpdk-ci] Failures reported by Intel CI for series 10551

[David Marchand]

Hello,

(It looks like I have no luck with CI those days... :-)).

All patches of a series of mine
(https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are
marked as failing all compilation in Intel CI.

- Is it normal to see all patches with the exact same test report?
Patch 1: http://mails.dpdk.org/archives/test-report/2020-June/137872.html
Patch 9: http://mails.dpdk.org/archives/test-report/2020-June/137880.html

UNH and ovsrobot only report once when testing a full series.
It makes more sense if Intel CI only tests full series.


- Putting the first point aside, and focusing on patch 9 error:
http://mails.dpdk.org/archives/test-report/2020-June/137880.html

../drivers/mempool/bucket/rte_mempool_bucket.c: In function ‘bucket_get_count’:
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
declaration of function ‘rte_lcore_iterate’; did you mean
‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
  rte_lcore_iterate(count_per_lcore, &ctx);
  ^~~~~~~~~~~~~~~~~
  rte_lcore_is_enabled
../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
cc1: all warnings being treated as errors


This function is defined in rte_lcore.h which does seem to be
included, seeing how the compiler suggests another
rte_lcore_is_enabled function.
The v2 revision passed fine
(http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and
I see no change in v3 that would break like this.

I am a bit puzzled...
One thing that comes to mind, do we have dpdk headers installed
system-wide on the Intel CI server(s)?


-- 
David Marchand

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[Lincoln Lavoie]

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

Hi David,

Did you get any response to this from the Intel folks?  Should we add a bug
to track this for discussion / review at our meeting next week?

Cheers,
Lincoln

On Tue, Jun 23, 2020 at 3:07 AM David Marchand <david.marchand@redhat.com>
wrote:

> Hello,
>
> (It looks like I have no luck with CI those days... :-)).
>
> All patches of a series of mine
> (https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are
> marked as failing all compilation in Intel CI.
>
> - Is it normal to see all patches with the exact same test report?
> Patch 1: http://mails.dpdk.org/archives/test-report/2020-June/137872.html
> Patch 9: http://mails.dpdk.org/archives/test-report/2020-June/137880.html
>
> UNH and ovsrobot only report once when testing a full series.
> It makes more sense if Intel CI only tests full series.
>
>
> - Putting the first point aside, and focusing on patch 9 error:
> http://mails.dpdk.org/archives/test-report/2020-June/137880.html
>
> ../drivers/mempool/bucket/rte_mempool_bucket.c: In function
> ‘bucket_get_count’:
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
> declaration of function ‘rte_lcore_iterate’; did you mean
> ‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
>   rte_lcore_iterate(count_per_lcore, &ctx);
>   ^~~~~~~~~~~~~~~~~
>   rte_lcore_is_enabled
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
> extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
>
>
> This function is defined in rte_lcore.h which does seem to be
> included, seeing how the compiler suggests another
> rte_lcore_is_enabled function.
> The v2 revision passed fine
> (http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and
> I see no change in v3 that would break like this.
>
> I am a bit puzzled...
> One thing that comes to mind, do we have dpdk headers installed
> system-wide on the Intel CI server(s)?
>
>
> --
> David Marchand
>
>

-- 
*Lincoln Lavoie*
Senior Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylavoie@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu/>

[-- Attachment #2: Type: text/html, Size: 4083 bytes --]

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[David Marchand]

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

On Wed, Jun 24, 2020 at 4:20 PM Lincoln Lavoie <lylavoie@iol.unh.edu> wrote:

> Hi David,
>
> Did you get any response to this from the Intel folks?  Should we add a
> bug to track this for discussion / review at our meeting next week?
>

I received no response yet, so you can create a bz to track this.
Thanks.


-- 
David Marchand

[-- Attachment #2: Type: text/html, Size: 930 bytes --]

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[Chen, Zhaoyan]

Hi, David,

For your question, "Is it normal to see all patches with the exact same test report?"
Yes, we always test a series, rather than a single patch. You can see the exact same report 
on any patch in a series. (it's convenient, you don't need backward to search 
the header of the series, then check result)

" One thing that comes to mind, do we have dpdk headers installed system-
> wide on the Intel CI server(s)?"

Sure, we do. We don't see any problem on other patch compilation, so far. but it's strange 
that your V2 and V3 is same, but v3 test is failed. (code base is same). So I will try to re-run
your series(v3), and check what's changed on CI system between the 2 days. Is that helpful? 

Regards,
Zhaoyan Chen

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Tuesday, June 23, 2020 3:08 PM
> To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>
> Subject: Failures reported by Intel CI for series 10551
> 
> Hello,
> 
> (It looks like I have no luck with CI those days... :-)).
> 
> All patches of a series of mine
> (https://patchwork.dpdk.org/project/dpdk/list/?series=10551) are marked
> as failing all compilation in Intel CI.
> 
> - Is it normal to see all patches with the exact same test report?
> Patch 1: http://mails.dpdk.org/archives/test-report/2020-
> June/137872.html
> Patch 9: http://mails.dpdk.org/archives/test-report/2020-
> June/137880.html
> 
> UNH and ovsrobot only report once when testing a full series.
> It makes more sense if Intel CI only tests full series.
> 
> 
> - Putting the first point aside, and focusing on patch 9 error:
> http://mails.dpdk.org/archives/test-report/2020-June/137880.html
> 
> ../drivers/mempool/bucket/rte_mempool_bucket.c: In function
> ‘bucket_get_count’:
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: implicit
> declaration of function ‘rte_lcore_iterate’; did you mean
> ‘rte_lcore_is_enabled’? [-Werror=implicit-function-declaration]
>   rte_lcore_iterate(count_per_lcore, &ctx);
>   ^~~~~~~~~~~~~~~~~
>   rte_lcore_is_enabled
> ../drivers/mempool/bucket/rte_mempool_bucket.c:400:2: error: nested
> extern declaration of ‘rte_lcore_iterate’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> 
> 
> This function is defined in rte_lcore.h which does seem to be included,
> seeing how the compiler suggests another rte_lcore_is_enabled function.
> The v2 revision passed fine
> (http://mails.dpdk.org/archives/test-report/2020-June/137552.html) and I
> see no change in v3 that would break like this.
> 
> I am a bit puzzled...
> One thing that comes to mind, do we have dpdk headers installed system-
> wide on the Intel CI server(s)?
> 
> 
> --
> David Marchand

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[David Marchand]

On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan <zhaoyan.chen@intel.com> wrote:
>
> Hi, David,
>
> For your question, "Is it normal to see all patches with the exact same test report?"
> Yes, we always test a series, rather than a single patch. You can see the exact same report
> on any patch in a series. (it's convenient, you don't need backward to search
> the header of the series, then check result)

Convenience is subject to interpretation :-).
Other CI systems send a single report which is more sane for me.


>
> " One thing that comes to mind, do we have dpdk headers installed system-
> > wide on the Intel CI server(s)?"
>
> Sure, we do. We don't see any problem on other patch compilation, so far. but it's strange
> that your V2 and V3 is same, but v3 test is failed. (code base is same). So I will try to re-run
> your series(v3), and check what's changed on CI system between the 2 days. Is that helpful?

Just to be sure.
By this, you mean that you have some dpdk headers installed on the CI
system in /usr?

Having those headers most likely exacerbates races with dpdk headers
copy in the building directory.
This could be where my series failed.


-- 
David Marchand

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[Thomas Monjalon]

26/06/2020 09:43, David Marchand:
> On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan <zhaoyan.chen@intel.com> wrote:
> >
> > Hi, David,
> >
> > For your question, "Is it normal to see all patches with the exact same test report?"
> > Yes, we always test a series, rather than a single patch. You can see the exact same report
> > on any patch in a series. (it's convenient, you don't need backward to search
> > the header of the series, then check result)
> 
> Convenience is subject to interpretation :-).
> Other CI systems send a single report which is more sane for me.

I think these tests have 2 purposes:
	- sending quick error feedback to the author
	- check that all is green before merging
In both cases we don't need to have the same report duplicated,
because we check for failures in all patches anyway.

I suggest sending the series report only on the last patch of the series.

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[Chen, Zhaoyan]

Hi all,

I have updated the info for this issue in bugzilla.


We have re-built the patchset. It was passed. The root cause is that patches in the  series are disorder by patchid. (patch 7/9 and patch 8/9). Usually, we apply patches by the order of patch id in a series. 

Why the issue is exposed this time?

Meet 2 conditions,
- the patches are disorder in the series
- the disordered patches are modified same file

Solution
- Change applying patch order by patch date, rather than patch id in patchwork.
But we don't know if patch date is unique and ordered for each patch in the series. 
We need patchwork document to confirm. So far, its good.


For Thomas' suggestion, "sending the series report only on the last patch of the series", currently, I find all reports iol-* are sent to the first patch in the series. Shall we align? and shall we get feedback from all maintainers or developers in the community?



Regards,
Zhaoyan Chen

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, June 26, 2020 6:24 PM
> To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>; David Marchand
> <david.marchand@redhat.com>
> Subject: Re: [dpdk-ci] Failures reported by Intel CI for series 10551
> 
> 26/06/2020 09:43, David Marchand:
> > On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan
> <zhaoyan.chen@intel.com> wrote:
> > >
> > > Hi, David,
> > >
> > > For your question, "Is it normal to see all patches with the exact same
> test report?"
> > > Yes, we always test a series, rather than a single patch. You can
> > > see the exact same report on any patch in a series. (it's
> > > convenient, you don't need backward to search the header of the
> > > series, then check result)
> >
> > Convenience is subject to interpretation :-).
> > Other CI systems send a single report which is more sane for me.
> 
> I think these tests have 2 purposes:
> 	- sending quick error feedback to the author
> 	- check that all is green before merging In both cases we don't
> need to have the same report duplicated, because we check for failures in
> all patches anyway.
> 
> I suggest sending the series report only on the last patch of the series.
> 

Re: [dpdk-ci] Failures reported by Intel CI for series 10551

[Thomas Monjalon]

I replied in Bugzilla.
Let's not duplicate the discussion please.
At this point, we should continue in Bugzilla.
Thanks

30/06/2020 07:59, Chen, Zhaoyan:
> Hi all,
> 
> I have updated the info for this issue in bugzilla.
> 
> 
> We have re-built the patchset. It was passed. The root cause is that patches in the  series are disorder by patchid. (patch 7/9 and patch 8/9). Usually, we apply patches by the order of patch id in a series. 
> 
> Why the issue is exposed this time?
> 
> Meet 2 conditions,
> - the patches are disorder in the series
> - the disordered patches are modified same file
> 
> Solution
> - Change applying patch order by patch date, rather than patch id in patchwork.
> But we don't know if patch date is unique and ordered for each patch in the series. 
> We need patchwork document to confirm. So far, its good.
> 
> 
> For Thomas' suggestion, "sending the series report only on the last patch of the series", currently, I find all reports iol-* are sent to the first patch in the series. Shall we align? and shall we get feedback from all maintainers or developers in the community?
> 
> 
> 
> Regards,
> Zhaoyan Chen
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Friday, June 26, 2020 6:24 PM
> > To: Chen, Zhaoyan <zhaoyan.chen@intel.com>
> > Cc: ci@dpdk.org; sys_stv <sys_stv@intel.com>; David Marchand
> > <david.marchand@redhat.com>
> > Subject: Re: [dpdk-ci] Failures reported by Intel CI for series 10551
> > 
> > 26/06/2020 09:43, David Marchand:
> > > On Fri, Jun 26, 2020 at 5:03 AM Chen, Zhaoyan
> > <zhaoyan.chen@intel.com> wrote:
> > > >
> > > > Hi, David,
> > > >
> > > > For your question, "Is it normal to see all patches with the exact same
> > test report?"
> > > > Yes, we always test a series, rather than a single patch. You can
> > > > see the exact same report on any patch in a series. (it's
> > > > convenient, you don't need backward to search the header of the
> > > > series, then check result)
> > >
> > > Convenience is subject to interpretation :-).
> > > Other CI systems send a single report which is more sane for me.
> > 
> > I think these tests have 2 purposes:
> > 	- sending quick error feedback to the author
> > 	- check that all is green before merging In both cases we don't
> > need to have the same report duplicated, because we check for failures in
> > all patches anyway.
> > 
> > I suggest sending the series report only on the last patch of the series.
> > 
> 
>