From dillon@backplane.com  Sat Aug 17 07:53:45 1996
Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA29097
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 17 Aug 1996 07:53:43 -0700 (PDT)
Received: (dillon@localhost) by apollo.backplane.com (8.7.5/8.6.5) id HAA00446; Sat, 17 Aug 1996 07:53:40 -0700 (PDT)
Message-Id: <199608171453.HAA00446@apollo.backplane.com>
Date: Sat, 17 Aug 1996 07:53:40 -0700 (PDT)
From: Matthew Dillon <dillon@backplane.com>
Reply-To: dillon@backplane.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: vmstat reports impossible avm after starting up X
X-Send-Pr-Version: 3.2

>Number:         1501
>Category:       kern
>Synopsis:       vmstat reports impossible avm after starting up X
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 17 08:00:01 PDT 1996
>Closed-Date:    Sat May 30 23:57:55 PDT 1998
>Last-Modified:  Sat May 30 23:58:32 PDT 1998
>Originator:     Matthew Dillon
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
BEST Internet Communications
>Environment:

	running 2.1.5 patched to (ctm) src-2.1.0.0154.gz
	Pentium 90 
	32 MB ram

>Description:

	vmstat comes back with reasonable numbers in the avm field, for
	example:

    0 0 0 95372  5704   37   0   1   0  46   0  2  0  0  302  207  47  1  2 97

	Until I run xdm.  It then comes back with a 2 GByte+ avm, clearly
	impossible.

    0 0 02523444 5704   37   0   1   0  46   0  2  0  0  302  207  47  1  2 97


    I added a debugging printf in vm_meter.c in the loop that collects
    the metering information that vmstat uses.  My debugging printf
    simply prints out the size of each object.  I found that after running
    xdm, the size of exactly one of the objects in the object returned
    an impossible number as shown below.  I do not know which process this
    object belongs to, but it's a good bet that it's the X server.  Perhaps
    it's the video map ??? I dunno.

    Aug 17 07:38:38 apollo /kernel: object f0c24d80 size 3936256
    Aug 17 07:38:38 apollo /kernel: object f0c24c00 size 4096
    Aug 17 07:38:38 apollo /kernel: object f0c2b080 size 73728
    Aug 17 07:38:38 apollo /kernel: object f0c2b600 size 8192
    Aug 17 07:38:38 apollo /kernel: object f0c2fc80 size 4096
    Aug 17 07:38:38 apollo /kernel: object f0c35600 size 12288
    Aug 17 07:38:38 apollo /kernel: object f0c37f80 size 20480
    Aug 17 07:38:38 apollo /kernel: object f0c37e80 size -1609564160
    Aug 17 07:38:38 apollo /kernel: object f0c37c80 size 16384
    Aug 17 07:38:38 apollo /kernel: object f0c37c00 size 8192
    Aug 17 07:38:38 apollo /kernel: object f0c37b00 size 12288
    Aug 17 07:38:38 apollo /kernel: object f0c37a80 size 4096
    Aug 17 07:38:38 apollo /kernel: object f0c37a00 size 4096
    Aug 17 07:38:38 apollo /kernel: object f0c37980 size 16384


>How-To-Repeat:

	Run xdm (Using XFree86 with the Cirrus accel. driver)
	Then run 'vmstat 5'

>Fix:
	
    I added a quick hack to vm_meter to ignore size's that were < 0
    (from the point of view of a signed 32 bit int).  That is not
    the correct fix.  The correct fix would be to locate the code
    generating the bogus object size and fix that.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 22:15:23 PDT 1996 
State-Changed-Why:  

Confirm Status: vmstat reports impossible avm after starting up X 

State-Changed-From-To: feedback->open 
State-Changed-By: scrappy 
State-Changed-When: Wed Oct 23 13:03:21 PDT 1996 
State-Changed-Why:  

Problem Still Exists 
State-Changed-From-To: open->closed 
State-Changed-By: steve 
State-Changed-When: Sat May 30 23:57:55 PDT 1998 
State-Changed-Why:  
Originator believes problem to be fixed in -current. 
>Unformatted:
