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 <dmi...@daynix.com> wrote: > >> >> On 2 Jun 2016, at 19:29 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: >> >> On 2 June 2016 at 15:15, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> On 2 June 2016 at 07:47, Jason Wang <jasow...@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
