Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Jun 2004 15:17:45 +0000 (UTC)
From:      Bruce Evans <bde@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/i386/isa npx.c
Message-ID:  <200406061517.i56FHj1p082822@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
bde         2004-06-06 15:17:45 UTC

  FreeBSD src repository

  Modified files:
    sys/i386/isa         npx.c 
  Log:
  Fixed misclassification of npx interrupts caused by npx_probe().
  Dividing by 0 in order to check for irq13/exception16 delivery apparently
  always causes an irq13 even if we have configured for exception16 (by
  setting CR0_NE).  This was expected, but the timing of the irq13 was
  unexpected.  Without CR0_NE, the irq13 is delivered synchronously at
  least on my test machine, but with CR0_NE it is delivered a little
  later (about 250 nsec) in PIC mode and much later (5000-10000 nsec)
  in APIC mode.  So especially in APIC mode, the irq13 may arrive after
  it is supposed to be shut down.  It should then be masked, but the
  shutdown is incomplete, so the irq goes to a null handler that just
  reports it as stray.  The fix is to wait a bit after dividing by 0 to
  give a good chance of the irq13 being handled by its proper handler.
  
  Removed the hack that was supposed to recover from the incomplete shutdown
  of irq13.  The shutdown is now even more incomplete, or perhaps just
  incomplete in a different way, but the hack now has no effect because
  irq13 is edge triggered and handling of edge triggered interrupts is
  now optimized by skipping their masking.  The hack only worked due
  to it accidentally not losing races.
  
  The incomplete shutdown of irq13 still allows unprivileged users to
  generate a stray irq13 (except on systems where irq13 is actually used)
  by unmasking an npx exception and causing one.  The exception gets
  handled properly by the exception 16 handler.  A spurious irq13 is
  delivered asynchronously but is harmless (as in the probe) because it
  is almost perfectly not handled by the null interrupt handler.
  Perfectly not handling it involves mainly not resetting the npx busy
  latch.  This prevents further irq13's despite them not being masked in
  the [A]PIC.
  
  Revision  Changes    Path
  1.149     +1 -12     src/sys/i386/isa/npx.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406061517.i56FHj1p082822>