On Wed, Oct 29, 2014 at 11:04:02PM +0400, Andrey Korolyov wrote: > On Wed, Oct 29, 2014 at 6:56 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Tue, Oct 28, 2014 at 08:31:43AM -0700, Ben Pfaff wrote: > >> On Tue, Oct 28, 2014 at 03:37:58PM +0400, Andrey Korolyov wrote: > >> > On Mon, Oct 27, 2014 at 8:19 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > > On Mon, Oct 27, 2014 at 9:15 AM, Andrey Korolyov <and...@xdel.ru> > >> > > wrote: > >> > >> On Mon, Oct 27, 2014 at 7:15 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > >>> On Mon, Oct 27, 2014 at 08:12:28PM +0400, Andrey Korolyov wrote: > >> > >>>> On Mon, Oct 27, 2014 at 7:09 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > >>>> > On Mon, Oct 27, 2014 at 08:05:01PM +0400, Andrey Korolyov wrote: > >> > >>>> >> On Mon, Oct 27, 2014 at 7:04 PM, Ben Pfaff <b...@nicira.com> > >> > >>>> >> wrote: > >> > >>>> >> > On Mon, Oct 27, 2014 at 07:55:01PM +0400, Andrey Korolyov > >> > >>>> >> > wrote: > >> > >>>> >> >> ovs-ofctl dump-ports currently reporting values not large > >> > >>>> >> >> than u32 in > >> > >>>> >> >> the mentioned branch. lib/ofp-util.c has no regressions at a > >> > >>>> >> >> glance, > >> > >>>> >> >> probably truncation going in the different (not so obvious) > >> > >>>> >> >> way. > >> > >>>> >> > > >> > >>>> >> > Are you using a 64-bit kernel? There is some unavoidable > >> > >>>> >> > truncation > >> > >>>> >> > with 32-bit kernels. > >> > >>>> >> > >> > >>>> >> Yes, of course. > >> > >>>> > > >> > >>>> > Thanks. I guess you must have previously seen 64-bit values with > >> > >>>> > some > >> > >>>> > earlier version. Do you know what the most recent version was? > >> > >>>> > >> > >>>> For 0fe1d7f39de9836fea01c560a6fdbfd1405096ea it is clearly positive > >> > >>>> that it reports 64-bit counter values (branch-2.1). Had not tested > >> > >>>> against other revisions yet. Are you suggesting that the counter > >> > >>>> behavior with 32b limit is currently taken as a right one? > >> > >>> > >> > >>> I am trying to narrow down the range of commits that could have > >> > >>> caused > >> > >>> the problem. "git bisect" would be the ideal way to do it, if you > >> > >>> are > >> > >>> willing and able to try it. > >> > >> > >> > >> Heh, okay. I`m signing over bisection, please give me some time :) > >> > > > >> > > Thanks a lot. > >> > > >> > > >> > The bad cast introduced by 04c881eb6441fff2e91c9b9e23502bc554c0f437. > >> > >> That patch only adds assignments of 64-bit integers to 64-bit integers. > >> No casts or conversions are involved. > >> > >> Looking more closely, I think the problem here is that even 64-bit > >> kernels always pass IFLA_STATS to userspace using 32-bit integers. > >> Usersspace needs to look at IFLA_STATS64, instead, when it is present, > >> but there is currently no code to do that. > > > > I sent out a fix: > > http://openvswitch.org/pipermail/dev/2014-October/047940.html > > Would you mind testing that it solves your problem? > > > Thanks, worked perfectly! By the way, patchwork status is a bit > outdated (last commit was fetched from ml six days ago).
I'm glad it fixed the problem. We're aware something is wrong with patchwork. We'll try to fix it. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
