Bug#384307: [Fwd: Bug#384307: sysstat: FTBFS (powerpc/ppc64): 'PAGE_SIZE' undeclared (first use in this function)]

2006-09-10 Thread Sebastien Godard

Hi Robert,

This bug will be fixed in sysstat 7.0.1 which will be released next week.
Sysstat will use the sysconf() system call to get the size of a page 
instead of using PAGE_SIZE definition.


Regards,
Sébastien.

Robert Luberda wrote:

Hi Sebastien,

Forwarding another bug report - PAGE_SIZE is not longer defined on
powerpc arch.

Regards,
robert

  




Sujet:
Bug#384307: sysstat: FTBFS (powerpc/ppc64): 'PAGE_SIZE' undeclared 
(first use in this function)

Expéditeur:
Andreas Jochens [EMAIL PROTECTED]
Date:
Wed, 23 Aug 2006 13:54:27 +0200
Destinataire:
Debian Bug Tracking System [EMAIL PROTECTED]

Destinataire:
Debian Bug Tracking System [EMAIL PROTECTED]


Package: sysstat
Version: 7.0.0-1
Severity: serious
Tags: patch

When building 'sysstat' on powerpc/unstable,
I get the following error:

sa.h:397: warning: 'packed' attribute ignored for field of type 'unsigned 
char[3u]'
sed s+VERSION_NUMBER+7.0.0+g version.in  version.h
gcc -o common.o -c -Wall -Wstrict-prototypes -pipe -g -fno-strength-reduce -O2  -DUSE_NLS 
-DPACKAGE=\sysstat\ -DLOCALEDIR=\/usr/share/locale\ common.c
common.c: In function 'get_kb_shift':
common.c:434: error: 'PAGE_SIZE' undeclared (first use in this function)
common.c:434: error: (Each undeclared identifier is reported only once
common.c:434: error: for each function it appears in.)
make[1]: *** [common.o] Error 1
make[1]: Leaving directory `/sysstat-7.0.0'
make: *** [build-stamp] Error 2

With the attached patch 'sysstat' can be compiled on powerpc.

Regards
Andreas Jochens

diff -urN ../tmp-orig/sysstat-7.0.0/common.c ./common.c
--- ../tmp-orig/sysstat-7.0.0/common.c  2006-07-09 08:19:06.0 +
+++ ./common.c  2006-08-23 11:20:05.0 +
@@ -29,13 +29,6 @@
 #include sys/types.h
 #include sys/ioctl.h
 
-/*

- * For PAGE_SIZE (which may be itself a call to getpagesize()).
- * PAGE_SHIFT no longer necessarily exists in asm/page.h. So
- * we use PAGE_SIZE to compute PAGE_SHIFT...
- */
-#include asm/page.h
-
 #include version.h
 #include common.h
 #include ioconf.h
@@ -431,7 +424,7 @@
int shift = 0;
int size;
 
-   size = PAGE_SIZE  10; /* Assume that a page has a minimum size of 1 kB */

+   size = sysconf(_SC_PAGE_SIZE)  10; /* Assume that a page has a minimum 
size of 1 kB */
while (size  1) {
   shift++;
   size = 1;



  



--
Sébastien Godard (sysstat at wanadoo.fr)
http://perso.orange.fr/sebastien.godard/





Bug#378995: [Fwd: Bug#378995: sysstat: -s skips an entry [patch]]

2006-08-09 Thread Sebastien Godard

Hi Robert,

Robert Luberda wrote:

I'm forwarding bug report I got during my holidays.
I can reproduce the behaviour with sysstat 7.0.0.
I haven't checked however if the attached patch is correct and works.

  

SNIP

sar -s hh:mm:ss should return data after the specified time, however
it effectively skips the first record:

# sar -d |tail -n 5
14:06:08   dev8-0  0.92  0.00 18.54 20.22 0.00  0.60
  0.18  0.02
14:07:08   dev8-0  0.58  0.00 13.20 22.63 0.00  0.23
  0.20  0.01
14:08:08   dev8-0  1.57  0.00 36.26 23.15 0.00  1.52
  0.17  0.03
14:09:08   dev8-0  0.77  0.00 17.87 23.30 0.00  0.22
  0.09  0.01
Average:   dev8-0  0.89  0.00 20.64 23.19 0.00  0.75
  0.22  0.02

# sar -d -s 14:08:00
Linux 2.6.8-2-686 (IS-844)  20/07/06

14:08:08  DEV   tps  rd_sec/s  wr_sec/s  avgrq-sz avgqu-sz 
await svctm %util
14:09:08   dev8-0  0.77  0.00 17.87 23.30 0.00  0.22
  0.09  0.01
Average:   dev8-0  0.77  0.00 17.87 23.30 0.00  0.22
  0.09  0.01

# sar -d -s 14:09:00 |tail
Linux 2.6.8-2-686 (IS-844)  20/07/06

  
This behavior of sar may seem a bit ambiguous, I must admit, but it's 
not a bug. Here is the explanation:
1) First, sar only displays stats on a complete interval of time. So if 
you set the starting time to 14:08:00 in the example above, sar will 
begin to display the stats at 14:08:08.
2) Then, the values displayed by sar are not instantaneous values, but 
rather values calculated on an interval of time. The stats displayed at 
time T are calculated on the interval ]T-dt;T] where dt is the sampling 
interval. That's why when you enter -s 14:08:00 on the command line, 
the first line of stats displayed is for 14:09:08 which is actually the 
stats calculated from 14:08:08 to 14:09:08... and which is what you 
asked for (OK, to be very accurate, the interval from 14:08:00 to 
14:08:08 is missing, but sar doesn't know how to compute the stats for 
it since it is only a fraction of the interval.)


Regards,

--
Sébastien Godard (sysstat at wanadoo.fr)
http://perso.orange.fr/sebastien.godard/





Bug#379764: sysstat: iostat fails to show stats of one partition

2006-07-26 Thread Sebastien Godard

Hi,

Toni Timonen wrote:

Package: sysstat
Version: 6.1.3-1
Severity: normal
Tags: patch

getting iostat of one partition fails.
eg.


[EMAIL PROTECTED]:~/work/m/tmp/sysstat-6.1.3$ ./iostat -p /dev/hda1
Linux 2.6.15-1-686 (sd033)  25/07/06

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  10.860.64   35.550.720.00   52.23

  Device:tps   Blk_read/s   Blk_wrtn/s   Blk_read 
Blk_wrtn
[EMAIL PROTECTED]:~/work/m/tmp/sysstat-6.1.3$

(but running 'iostat -p /dev/hda' gives full output).
A patch to fix this issue is attached.



No, this is not the expected behavior for iostat.
The argument following option -p should be a device (like /dev/hda, 
/dev/sda, etc.), and not a partition (/dev/hda1, ...).
iostat -p /dev/hda tells iostat to display the statistics for device 
hda and all its partitions.
If you want to display the stats only for hda1, just enter iostat 
/dev/hda1 (and not iostat -p /dev/hda1).


Regards,
--
Sebastien GODARD (sysstat maintainer)
http://perso.orange.fr/sebastien.godard/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#363509: /usr/bin/mpstat: mpstat output without parameters is wrong (fwd)

2006-04-21 Thread Sebastien Godard

Hi Robert,

Robert Luberda wrote:

I'm forwarding the bug I got today.

- Forwarded message from Benoit Panizzon [EMAIL PROTECTED] -

I was just playing around with rrdtools and wanted to graph my system status 
when I discovered that mpstats
prints nosense data when called without parameter:

Example on a server just running a kernel make -j 20:

$ mpstat
Linux 2.6.14.3 (go.imp.ch)  19.04.2006

16:25:45 CPU   %user   %nice %system %iowait%irq   %soft   %idle
intr/s
16:25:45 all0.410.000.160.030.120.01   99.27
497.45

99% Idle? Can't be...

How to get the right output:

$ mpstat 1 1
Linux 2.6.14.3 (go.imp.ch)  19.04.2006

16:26:10 CPU   %user   %nice %system %iowait%irq   %soft   %idle
intr/s
16:26:11 all   88.670.009.360.000.490.001.48
391.09
Durchschn.:  all   88.670.009.360.000.490.001.48
391.09

This looks about right...
  

OK. This is not a bug ;-)
Without any parameters entered on the command line, mpstat displays its 
stats since system startup (in the example above, mpstat displays the 
stats averaged between system boot time and 16:25:45).
When you enter mpstat 1 1, mpstat displays one line of stats on a 1 
second interval (in the example above, between 16:26:10 and 16:26:11).

I will update mpstat manual page to make this clear.

Regards,

--
Sébastien Godard (sysstat at wanadoo.fr)
http://perso.wanadoo.fr/sebastien.godard/






Bug#362146: iostat: wrong avgqu-sz and %util values (fwd)

2006-04-21 Thread Sebastien Godard

Hi,

Robert Luberda wrote:

Forwarding yet another bug report.

- Forwarded message from Gabor Gombas [EMAIL PROTECTED] -

I just noticed that iostat -x -d 2 reports bogus values for avgqu-sz
and %util:

Device:rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/srkB/swkB/s avgrq-sz 
avgqu-sz   await  svctm  %util
sda  0.00   5.00  0.00  6.000.00   88.00 0.0044.0014.67 
978275.898.67 166.75 100.05
sdb  0.00   5.00  0.00  6.000.00   88.00 0.0044.0014.67 
978275.874.58 166.75 100.05
md0  0.00   0.00  0.00  5.500.00   44.00 0.0022.00 8.00 
0.000.00   0.00   0.00
md4  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
md3  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
md2  0.00   0.00  0.00  1.500.00   12.00 0.00 6.00 8.00 
0.000.00   0.00   0.00
md1  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
sdc  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00

AMD64 has similar problems, just the numbers are larger:

Device:rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/srkB/swkB/s avgrq-sz 
avgqu-sz   await  svctm  %util
sda  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
9269720640049696.000.00   0.00 100.55
sdb  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
9269720640049696.000.00   0.00 100.55
sdc  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
9269720640049696.000.00   0.00 100.55
sdd  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
9269720640049696.000.00   0.00 100.55
md0  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
md3  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
md2  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
md1  0.00   0.00  0.00  0.000.000.00 0.00 0.00 0.00 
0.000.00   0.00   0.00
  
I am wondering if this problem is not linked to the following Linux 
kernel bug, as explained in sysstat FAQ :


*** BEGIN FAQ ***
3.6. iostat -x displays huge numbers for some fields...

Because of a Linux kernel bug, iostat -x may display huge I/O response times
(svctm) and a bandwidth utilization (%util) of 100% for some devices. Indeed
these devices have a value for the field #9 (beginning after the device 
name)

in /proc/{partitions,diskstats} which is always different from 0, and even
negative sometimes. Yet this field should go to zero, since it gives the
number of I/Os currently in progress (it is incremented as requests are
submitted, and decremented as they finish).
To (temporarily) solve the problem, you should reboot your system to 
reset the

counters in /proc/{partitions,diskstats}.
*** END FAQ ***

This could explain why we get such a value for %util (100%).
Gabor : could you please send me the contents of your /proc/diskstats 
file so that I can check it?


PS: Note that a problem with huge avgqu-sz values was also reported on 
64-bit machines in LKML.
Though fixing iostat to handle this problem was possible, it was decided 
to update the kernel's disk_stats structure to fix it (patch from Ben 
Woodard which was finally included in 2.6.17-rc1).


Regards,

--
Sébastien Godard (sysstat at wanadoo.fr)
http://perso.wanadoo.fr/sebastien.godard/