cvs commit: src/sys/dev/disk/aic7xxx aic79xx.c

[Peter Avalos <pavalos@xxxxxxxxxxxxxxxxxxxxxxx>]

pavalos     2007/07/04 21:39:25 PDT

DragonFly src repository

  Modified files:
    sys/dev/disk/aic7xxx aic79xx.c 
  Log:
  Fix a race condition in the flushing of commands that
  have completed across the bus but not to the host before
  processing of an exception condition (busfree, bus reset,
  etc.).  When flushing the controller of completed commands,
  we also look for packetized commands that have completed
  with good status and are stored in the "good status fifo".
  The hardware will post to the good status fifo even if
  data for that command is still active in a FIFO.  In
  one particular failure case, a command outstanding on the
  bus reconnected, transferred data into a FIFO, and provided
  good status while the host driver was processing an expected
  busfree event (PPR message negotiation).  This resulted in
  an entry in the good status fifo that we completed, but
  since the sequencer was paused, the data in the data FIFO
  for this command had never been transferred to the host.
  Once the busfree processing was complete, the sequencer
  was unpaused, and the data completed its transfer to the
  host.  In some instances, the client for the data was notified
  of the completion and attempted to view the data before
  it arrived.  This case only occurred during the
  multi-target probe of the SCSI bus while some devices are
  negotiating to go packetized and some devices are already
  running in packetized.
  
  The fix is to run and FIFOs active with a context in the
  good status fifo to completion before completing the command
  to the SCSI layer.  This requies duplicating the FIFO rundown
  operations in the host driver that would usually be handled
  by the firmware, but there is no other alternative.
  
  Don't blindly shutdown the SCB dma engine when restarting
  the sequencer.  We may be killing an operation that is
  not supposed to be cancelled.  The cases where we need to
  shutdown these dma engines are already handled elsewhere in
  the driver.
  
  Fix a few more ahd_in?() -> ahd_in?_scbram() instances.
  
  Obtained-from: FreeBSD
  
  Revision  Changes    Path
  1.17      +380 -50   src/sys/dev/disk/aic7xxx/aic79xx.c


http://www.dragonflybsd.org/cvsweb/src/sys/dev/disk/aic7xxx/aic79xx.c.diff?r1=1.16&r2=1.17&f=u