Message ID | 1464850102-17829-1-git-send-email-jasowang@redhat.com |
---|---|
State | New |
Headers | show |
On 2 June 2016 at 07:47, Jason Wang <jasowang@redhat.com> wrote: > The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: > > Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 517b5e9a175fe7d47cc0fab6c2310241fd33c115: > > Add ENET device to i.MX6 SOC. (2016-06-02 10:42:46 +0800) > > ---------------------------------------------------------------- > Main changes: > - e1000e emulation > - convet vmxnet3 to use DMA api > - ENET support for FEC device > Changes from V3: > - add ENET series > - fix clang sanitizer about misaligned access > Changes from V2: > - fix clang build > Changes from V1: > - fix 32bit build > Applied, thanks. -- PMM
On 2 June 2016 at 15:15, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 June 2016 at 07:47, Jason Wang <jasowang@redhat.com> wrote: >> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: >> >> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) >> >> are available in the git repository at: >> >> https://github.com/jasowang/qemu.git tags/net-pull-request >> >> for you to fetch changes up to 517b5e9a175fe7d47cc0fab6c2310241fd33c115: >> >> Add ENET device to i.MX6 SOC. (2016-06-02 10:42:46 +0800) >> >> ---------------------------------------------------------------- >> Main changes: >> - e1000e emulation >> - convet vmxnet3 to use DMA api >> - ENET support for FEC device >> Changes from V3: >> - add ENET series >> - fix clang sanitizer about misaligned access >> Changes from V2: >> - fix clang build >> Changes from V1: >> - fix 32bit build >> > > Applied, thanks. Looks like this caused a travis build failure for the config which uses --enable-trace-backends=ust: https://travis-ci.org/qemu/qemu/jobs/134759359 Could you or Dmitry have a look, please? thanks -- PMM
> On 2 Jun 2016, at 19:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > > On 2 June 2016 at 15:15, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 2 June 2016 at 07:47, Jason Wang <jasowang@redhat.com> wrote: >>> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: >>> >>> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) >>> >>> are available in the git repository at: >>> >>> https://github.com/jasowang/qemu.git tags/net-pull-request >>> >>> for you to fetch changes up to 517b5e9a175fe7d47cc0fab6c2310241fd33c115: >>> >>> Add ENET device to i.MX6 SOC. (2016-06-02 10:42:46 +0800) >>> >>> ---------------------------------------------------------------- >>> Main changes: >>> - e1000e emulation >>> - convet vmxnet3 to use DMA api >>> - ENET support for FEC device >>> Changes from V3: >>> - add ENET series >>> - fix clang sanitizer about misaligned access >>> Changes from V2: >>> - fix clang build >>> Changes from V1: >>> - fix 32bit build >>> >> >> Applied, thanks. > > Looks like this caused a travis build failure for the config which > uses --enable-trace-backends=ust: > https://travis-ci.org/qemu/qemu/jobs/134759359 > > Could you or Dmitry have a look, please? Hi Peter, The build did not pass because of tracepoint e1000e_rx_rss_ip6 which failed to compile. This tracepoint has 11 parameters, when 1 parameter is removed build succeeds. Could it be that ust backend has a limitation of 10 parameters per event? Should I split this trace into 2 events? In general, I would like to check compilability of my patches better next time, is there a way to figure out a full list of configurations to be tested? Is there a tool for that maybe? Thanks, Dmitry > > thanks > -- PMM
Hi, After deeper investigation: From lttng/tracepoint.h: … /* * TP_ARGS takes tuples of type, argument separated by a comma. * It can take up to 10 tuples (which means that less than 10 tuples is * fine too). * Each tuple is also separated by a comma. */ … So this is a ust backend limitation. Since build is failing, I’m sending a patch that splits this tracepoint into 2 events. ~Dmitry > On 2 Jun 2016, at 21:09 PM, Dmitry Fleytman <dmitry@daynix.com> wrote: > >> >> On 2 Jun 2016, at 19:29 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >> >> On 2 June 2016 at 15:15, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 2 June 2016 at 07:47, Jason Wang <jasowang@redhat.com> wrote: >>>> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: >>>> >>>> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2016-05-24 13:06:33 +0100) >>>> >>>> are available in the git repository at: >>>> >>>> https://github.com/jasowang/qemu.git tags/net-pull-request >>>> >>>> for you to fetch changes up to 517b5e9a175fe7d47cc0fab6c2310241fd33c115: >>>> >>>> Add ENET device to i.MX6 SOC. (2016-06-02 10:42:46 +0800) >>>> >>>> ---------------------------------------------------------------- >>>> Main changes: >>>> - e1000e emulation >>>> - convet vmxnet3 to use DMA api >>>> - ENET support for FEC device >>>> Changes from V3: >>>> - add ENET series >>>> - fix clang sanitizer about misaligned access >>>> Changes from V2: >>>> - fix clang build >>>> Changes from V1: >>>> - fix 32bit build >>>> >>> >>> Applied, thanks. >> >> Looks like this caused a travis build failure for the config which >> uses --enable-trace-backends=ust: >> https://travis-ci.org/qemu/qemu/jobs/134759359 >> >> Could you or Dmitry have a look, please? > > Hi Peter, > > The build did not pass because of tracepoint e1000e_rx_rss_ip6 which failed to compile. > > This tracepoint has 11 parameters, when 1 parameter is removed build succeeds. > Could it be that ust backend has a limitation of 10 parameters per event? > Should I split this trace into 2 events? > > In general, I would like to check compilability of my patches better next time, > is there a way to figure out a full list of configurations to be tested? Is there a tool for that maybe? > > Thanks, > Dmitry > >> >> thanks >> -- PMM
On 06/02/2016 12:09 PM, Dmitry Fleytman wrote: > > The build did not pass because of tracepoint e1000e_rx_rss_ip6 which failed to compile. > > This tracepoint has 11 parameters, when 1 parameter is removed build succeeds. > Could it be that ust backend has a limitation of 10 parameters per event? > Should I split this trace into 2 events? > > In general, I would like to check compilability of my patches better next time, > is there a way to figure out a full list of configurations to be tested? Is there a tool for that maybe? The brand new docker tests (see commit cbd614870 and above) should make it easier to test multiple setups, although I'm not sure if ust is one of the docker tests yet.
On 2 June 2016 at 19:38, Dmitry Fleytman <dmitry@daynix.com> wrote: > From lttng/tracepoint.h: > > … > > /* > * TP_ARGS takes tuples of type, argument separated by a comma. > * It can take up to 10 tuples (which means that less than 10 tuples is > * fine too). > * Each tuple is also separated by a comma. > */ > > … > > So this is a ust backend limitation. > > Since build is failing, I’m sending a patch that splits this > tracepoint into 2 events. I see; thanks for the patch. (A possible enhancement for the trace code would be to make going over 10 arguments to a tracepoint be a compile failure whichever backend was in use, so they're less likely to slip through.) thanks -- PMM
On Thu, 06/02 13:05, Eric Blake wrote: > On 06/02/2016 12:09 PM, Dmitry Fleytman wrote: > > > > > The build did not pass because of tracepoint e1000e_rx_rss_ip6 which failed to compile. > > > > This tracepoint has 11 parameters, when 1 parameter is removed build succeeds. > > Could it be that ust backend has a limitation of 10 parameters per event? > > Should I split this trace into 2 events? > > > > In general, I would like to check compilability of my patches better next time, > > is there a way to figure out a full list of configurations to be tested? Is there a tool for that maybe? > > The brand new docker tests (see commit cbd614870 and above) should make > it easier to test multiple setups, although I'm not sure if ust is one > of the docker tests yet. Yes, thanks for mentioning! And there is a "travis" script that can mimic travis-ci.org testing (it's a PoC far from perfect for now): make docker-travis@ubuntu Next step, I'll take a look at our .travis.yml matrix and make a selection out of that (maybe by flattening all dimensions onto one base configuration, so it can become a first class test that completes in a resonable time on a single average machine that a developer owns). Fam