From owner-cvs-all  Wed Jul 19  7:33:57 2000
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id CC14A37BE44; Wed, 19 Jul 2000 07:33:53 -0700 (PDT)
	(envelope-from gallatin@FreeBSD.org)
Received: (from gallatin@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id HAA34325;
	Wed, 19 Jul 2000 07:33:53 -0700 (PDT)
	(envelope-from gallatin@FreeBSD.org)
Message-Id: <200007191433.HAA34325@freefall.freebsd.org>
From: Andrew Gallatin <gallatin@FreeBSD.org>
Date: Wed, 19 Jul 2000 07:33:53 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/pci if_fxp.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

gallatin    2000/07/19 07:33:53 PDT

  Modified files:
    sys/pci              if_fxp.c 
  Log:
  Fix an alpha-only race which causes the transmit side of the chip to
  lock up under moderate to heavy load.
  
  The status & command fields share a 32-bit longword.  The programming
  API of the eepro apparently requires that you update the command field
  of a transmit slot that you've already given to the card.  This means
  the card could be updating the status field of the same longword at
  the same time. Since alphas can only operate on 32-bit chunks of
  memory, both the status & command fields are loaded from memory &
  operated on in registers when the following line of C is executed:
  
                  sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S;
  
  The race is caused by the card DMA'ing up the status at just the wrong
  time -- after it has been loaded into a register & before it has been
  written back.  The old value of the status is written back, clobbering
  the status the card just DMA'ed up. The fact that the card has sent
  this frame is missed & the transmit engine appears to hang.
  
  Luckily, as numerous people on the freebsd-alpha list pointed out, the
  load-locked/store-conditional instructions used by the atomic
  functions work with respect changes in memory due to I/O devices.  We
  now use them to safely update the command field.
  
  Tested by: Bernd Walter <ticso@mail.cicely.de>
  
  Revision  Changes    Path
  1.83      +13 -1     src/sys/pci/if_fxp.c



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