hsg@pbinfo.UUCP (Joerg Hoyer) (11/21/89)
I have some trouble with xperfmon on Sun3 and Sun4 running under SunOs4.0*.
xperfmon brings it's window up, but then dies it with floating point execption.
I've found the problem in window.c in the function draw_background.
If i = 3 in the second for-loop xperfmon dies in the following line:
graph_list[i]->zero = graph_list[i]->min_pix + (graph_list[i]->min_value*SCALE(i));
Has anyone had this problem too and fixed it ?
Thanx in advanced.
Joerg
/
/ ---- ---- Joerg Hoyer
/___ /___ /___/ Universitaet Paderborn Fb 17
/ / / / Warburgerstr. 100
/ / / / D - 4790 Paderborn, WEST-GERMANY
/ / ___/ /__/ email: hsg@pbinfo.uucp or ..!uunet!unido!pbinfo!hsggwe@cbnews.ATT.COM (George W. Erhart) (11/21/89)
In article <726@corona.pb> hsg@pbinfo.UUCP (Joerg Hoyer) writes: >If i = 3 in the second for-loop xperfmon dies in the following line: >graph_list[i]->zero = graph_list[i]->min_pix + (graph_list[i]->min_value*SCALE(i)); Note that SCALE(i) will cause your floating point exception if graph_list[i]->max_value == 0 ... note further that when i is equal to 3, the draw_background() function is attempting to draw the background for the "Free" component of the display. Further investigation of this problem will show that in system.c, the structure nl[] contains the symbol names of the values in the vmunix kernel that hold things like the maximum amount of free memory in the system. (Which equals the total amount of RAM under SUN OS 3.5.) In SUN OS 3.5, the maximum amount of free memory was contained in "_maxfree". This symbol is not in SUN OS 4.0.X. Thus, when nlist() returns a zero value for the maxfree memory, the SCALE() will fail in draw_background(). I did not have time to find out what new symbol could be used to replace _maxfree, so I hardcoded the maximum of 24MB in my copy of system.c. Have fun ... but remember that it is dangerous to play with kernels! -- George Erhart AT&T Network Systems/Bell Laboratories att!cbdkc1!gwe
bret@codonics.COM (Bret Orsburn) (11/21/89)
In article <726@corona.pb> hsg@pbinfo.UUCP (Joerg Hoyer) writes: >I have some trouble with xperfmon on Sun3 and Sun4 running under SunOs4.0*. >xperfmon brings it's window up, but then dies it with floating point execption. > >I've found the problem in window.c in the function draw_background. >If i = 3 in the second for-loop xperfmon dies in the following line: >graph_list[i]->zero = graph_list[i]->min_pix + (graph_list[i]->min_value*SCALE(i)); > >Has anyone had this problem too and fixed it ? This is the second time this has appeared this week. I responded by Email the first time, but will venture a follow-up this time. For each quantity foo displayed, the SCALE macro does a division by (max_foo - min_foo) In SunOS 4, the quantity used to represent Available Memory sometimes ranges from 0 to 0, resulting in a divide by zero error. The *correct* fix would be to locate a better data value to chart or to error check the existing data. The skill-level-zero fix is to add one to the denominator of the SCALE macro. I leave it as an exercise for the reader to guess how I handled it ;-) -- bret@codonics.com uunet!codonics!bret Bret Orsburn
stolcke@icsib2.Berkeley.EDU (Andreas Stolcke) (11/22/89)
There was a lot of network traffic on this subject lately, and I'm not sure I'm up to date on the problems being dicussed. However, the patch in xperfmon.sun4_0.patch in contrib on expo worked just fine for us (SunOS4.0.1/3, Sun4 and Sparcstations). ---- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
cyliax@ori-d48-3.inf.ethz.ch (Ingo Cyliax) (11/22/89)
Can't you just read the memory configuration size from /dev/eeprom on the suns ? On our systems /dev/eeprom is readable by anyone, and the locations are : 0x14 (memsize) 0x15 (memtest) -ingo /* Ingo Cyliax Stabstelle Software * * cyliax@inf.ethz.ch Departement Informatik * * cyliax@ethz.uucp ETH-Zentrum * * Tel: +41 1 256 35 31 CH-8092 Zuerich, Switzerland */