[ovs-discuss] branch-2.3: rx/tx counter overflow

[Andrey Korolyov]

On Mon, Oct 27, 2014 at 8:19 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Mon, Oct 27, 2014 at 9:15 AM, Andrey Korolyov <andrey at xdel.ru> wrote:
>> On Mon, Oct 27, 2014 at 7:15 PM, Ben Pfaff <blp at 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 <blp at 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 <blp at 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.