From owner-freebsd-smp  Wed Sep 11 14:56:28 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA05588
          for smp-outgoing; Wed, 11 Sep 1996 14:56:28 -0700 (PDT)
Received: (from peter@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA05561
          for freebsd-smp; Wed, 11 Sep 1996 14:56:24 -0700 (PDT)
Date: Wed, 11 Sep 1996 14:56:24 -0700 (PDT)
From: Peter Wemm <peter>
Message-Id: <199609112156.OAA05561@freefall.freebsd.org>
To: freebsd-smp
Subject: cvs commit:  sys/sys resourcevar.h sys/miscfs/procfs procfs_status.c sys/kern init_main.c kern_acct.c kern_exit.c kern_resource.c kern_shutdown.c kern_synch.c tty.c
Sender: owner-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

peter       96/09/11 14:56:22

  Modified:    sys       resourcevar.h
               kern      init_main.c kern_acct.c kern_exit.c
                        kern_resource.c  kern_shutdown.c kern_synch.c tty.c
               miscfs/procfs  procfs_status.c
  Log:
  Most of this came about as a result of trying to figure out WTF's going
  on with the negative times in calcru().  I added an extra arg for calcru
  to use in it's diagnostic message. It appears that it's somehow related
  to the way we fork our processes and connect them to the run queues relative
  to the start time we set.  The most often case of failure was for very
  short lived processes that exited very quickly,
  eg: find /usr -exec echo {} \;
  
  Eventually I gave up and commented the warning out under a #ifndef SMP
  block.
  
  Also, do some work on the smp_idleloop(). We were breaking a LOT of rules
  in there, including modifying the run queues with no spl protection, calling
  code without raising to the required spl level, etc.  It's a wonder things
  worked at all...... :-]
  
  Attempt to allow safer shutdowns, but I'm not sure I've got it right.  If
  boot() is called on cpu != #0, it sets a trap to catch non-zero cpus and
  repeatedly sleeps, hoping that the other cpu will schedule the process.
  I do not recall if I got this working, I must check it again.
  (cpu#1 etc cannot shut the system down, as they do not have interrupts
   enabled, so they cannot complete the disk IO, and hence do not clean
   unmount the filesystems.)
  
  Revision  Changes    Path
  1.2       +2 -8      sys/sys/resourcevar.h
  1.21      +20 -3     sys/kern/init_main.c
  1.2       +1 -1      sys/kern/kern_acct.c
  1.7       +1 -1      sys/kern/kern_exit.c
  1.2       +11 -10    sys/kern/kern_resource.c
  1.3       +18 -0     sys/kern/kern_shutdown.c
  1.10      +5 -4      sys/kern/kern_synch.c
  1.2       +8 -6      sys/kern/tty.c
  1.2       +1 -1      sys/miscfs/procfs/procfs_status.c