From owner-cvs-all  Wed Jan 12 14:24: 9 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 884321507E; Wed, 12 Jan 2000 14:24:07 -0800 (PST)
	(envelope-from wpaul@FreeBSD.org)
Received: (from wpaul@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id OAA56914;
	Wed, 12 Jan 2000 14:24:07 -0800 (PST)
	(envelope-from wpaul@FreeBSD.org)
Message-Id: <200001122224.OAA56914@freefall.freebsd.org>
From: Bill Paul <wpaul@FreeBSD.org>
Date: Wed, 12 Jan 2000 14:24:06 -0800 (PST)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/pci if_dc.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

wpaul       2000/01/12 14:24:06 PST

  Modified files:
    sys/pci              if_dc.c 
  Log:
  Reintroduce the dc_coal() workaround routine for coalescing outbound
  packets into a single buffer, and set the DC_TX_COALESCE flag for the
  Davicom DM9102 chip. I thought I had escaped this problem, but... This
  chip appears to silently corrupt or discard transmitted frames when
  using scatter/gather DMA (i.e. DMAing each packet fragment in place
  with a separate descriptor). The only way to insure reliable transmission
  is to coalesce transmitted packets into a single cluster buffer. (There
  may also be an alignment constraint here, but mbuf cluster buffers are
  naturally aligned on 2K boundaries, which seems to be good enough.)
  
  The DM9102 driver for Linux written by Davicom also uses this workaround.
  Unfortunately, the Davicom datasheet has no errata section describing
  this or any other apparently known defect.
  
  Problem noted by: allan_chou@davicom.com.tw
  
  Revision  Changes    Path
  1.5       +45 -3     src/sys/pci/if_dc.c



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