Below is an e-mail I sent to Teemu Toivola with all of the information on a bug I've encountered.
-- begin http://u13.net/dev Linux outcry.u13.net 2.6.16.24 #1 SMP Fri Jul 14 09:01:44 EDT 2006 x86_64 GNU/Linux Running debian with a kernel I compiled myself straight from the kernel.org tgz. 32 bit userland, 64 bit kernel. apparently the counters in /proc/net/dev are 64 bit on my system (this is thought to be odd by who I've spoken to so far). proc.c doesn't seem to handle this right, using strtoul() in some places where strtoull() is needed. I first discovered this on my production system when using vnstat -tr. After a seemingly random amount of time (2-24 hours), vnstat -tr would show 0 for tx/rx counts, at separate times. This led me to check /proc/net/dev. There, I discovered that the counter didn't overflow at 32 bits like expected, but rather uses a 64 bit counter. Given enough time, the packet count would probably show the same signs of oddness in vnstat -tr. As well, the normal vnstat db wouldn't update because every time strtoul() is called on an int > 32 bits, it just returns the max value for a 32 bit integer, thus giving a delta of 0 for transferred data. I hacked it to just use strtoull everywhere that strtoul was used (since you appeared to use %Lu in all of your printfs anyway), though there has got to be a more proper solution. Are you aware of this, and do you know at what point the kernel started using 64 bit counters on 64 bit systems? I've spoken to other people who run other kernels on amd64 systems, and theirs use 32 bit counters. This box used 64 bit counters even on the same kernels as them. This could all be solved if you checked the code in vnstat to have it properly handle 64 bit ints in /proc/net/dev. it appears that proc.c and misc.c are the two files that need changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
