From owner-cvs-all  Wed May  2  6: 7: 4 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4CB6637B423; Wed,  2 May 2001 06:06:59 -0700 (PDT)
	(envelope-from bde@FreeBSD.org)
Received: (from bde@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f42D6xo49420;
	Wed, 2 May 2001 06:06:59 -0700 (PDT)
	(envelope-from bde)
Message-Id: <200105021306.f42D6xo49420@freefall.freebsd.org>
From: Bruce Evans <bde@FreeBSD.org>
Date: Wed, 2 May 2001 06:06:59 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/i386/isa npx.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

bde         2001/05/02 06:06:58 PDT

  Modified files:
    sys/i386/isa         npx.c 
  Log:
  Fixed panics in npx exception handling.  When using IRQ13 exception
  handling, SMPng always switches the npx context away from curproc
  before calling the handler, so the handler always paniced.  When using
  exception 16 exception handling, SMPng sometimes switches the npx
  context away from curproc before calling the handler, so the handler
  sometimes paniced.  Also, we didn't lock the context while using it,
  so we sometimes didn't detect the switch and then paniced in a less
  controlled way.
  
  Just lock the context while using it, and return without doing anything
  except clearing the busy latch if the context is not for curproc.  This
  fixes the exception 16 case and makes the IRQ13 case harmless.  In both
  cases, the instruction that caused the exception is restarted and the
  exception repeats.  In the exception 16 case, we soon get an exception
  that can be handled without doing anything special.  In the IRQ13 case,
  we get an easy to kill hung process.
  
  Revision  Changes    Path
  1.97      +19 -8     src/sys/i386/isa/npx.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message