fuller@isctsse.UUCP (Bill Fuller) (05/02/89)
Hi, Has anyone been able to get the xperfmon program that comes with the contribution clients to work under 4.0.1 SunOS on a SUN 4. I have an arithmetic exception, and then the program dumps. I have run trace on it and found that when it opened /dev/kmem to get the info it needed, the address that gets passed to the macro steal() is illegal and cause EFAULT in the module get_namelist for the MAXFREE (line 394). This function is in the file: system.c. However, my error does not occur until I am in the module draw_background(), in window.c. It calculates the lines to draw based on the window size and calls XDrawLine. However, all of the arguments being passed to XDrawLine appear correct in that the x1, y1, x2, y2, are properly calculated. Can anyone give me a lead here? Thankyou, William H. Fuller
faulkner@jmullins.harvard.edu (Don Faulkner) (05/02/89)
In article <227@isctsse.UUCP> fuller@isctsse.UUCP (Bill Fuller) writes:
WHF> Has anyone been able to get the xperfmon program that comes with
WHF> the contribution clients to work under 4.0.1 SunOS on a SUN 4.
Works for me, sans free.
try "xperfmon -not free
--
Don Faulkner
Building 1, Room 803
Harvard University, School of Public Health
665 Huntington Avenue
Boston, MA 02115
ARPA: faulkner%jmullins@harvard.harvard.edu
BITNET: faulkner@harvard
Telephone: (617) 732-2297djm@lupine.UUCP (Dave Mackie) (05/04/89)
Your problem with xperfmon on SUNOS 4.X is due to the fact that xperfmon expects to find the symbol 'maxfree', the largest possible amount of free physical memory, in the kernel. This existed in SUNOS 3.X, but went away in 4.X. The workaround is trivial, just initialize the variable maxfree in system.c to be a reasonable large value (in KB) for your site. These days I would guess that's 8-32 MB. When xperfmon compresses the displayed data after running out of room for the strip charts, it will rescale the graphs to a range appropriate for the collected data. This is a very nice feature, and makes the initial choice for the maximum of small concern. In general, the problem with xperfmon is that it needs to know all sorts of incestuous information about the kernel that change from version to version, never mind machine to machine. Dave Mackie Network Computing Devices djm@ncd.com P.S. I asked SUN about how to find out from a user level application running on SUNOS 4.X, how much physical memory is installed. They couldn't imagine why anyone would ever want to know. I guess virtual memory has caused some people to have under-active imaginations :-)
dshr@SUN.COM (David Rosenthal) (05/05/89)
> P.S. I asked SUN about how to find out from a user level application > running on SUNOS 4.X, how much physical memory is installed. > They couldn't imagine why anyone would ever want to know. I guess > virtual memory has caused some people to have under-active > imaginations :-) > Use the Force, Luke! We try: devnull% nm -g /vmunix | grep mem ...... 0f08609c B _maxmem # Hmmm!! ...... 0f080cb6 D _physmem # Sounds interesting! Devnull runs a slightly souped-up version of 4.0, so your results may vary, but I can't remember inventing these variables. David.
sasmwk@sas.UUCP (Mark Kernodle) (05/12/89)
I get the exact same behavior on a Sun 3/260 runing SunOs 4.01.