From owner-cvs-src@FreeBSD.ORG  Thu Apr 17 04:16:52 2008
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 08C6A106566C;
	Thu, 17 Apr 2008 04:16:52 +0000 (UTC)
	(envelope-from yongari@FreeBSD.org)
Received: from repoman.freebsd.org (repoman.freebsd.org
	[IPv6:2001:4f8:fff6::29])
	by mx1.freebsd.org (Postfix) with ESMTP id EADEB8FC13;
	Thu, 17 Apr 2008 04:16:51 +0000 (UTC)
	(envelope-from yongari@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m3H4Gpt4032562;
	Thu, 17 Apr 2008 04:16:51 GMT
	(envelope-from yongari@repoman.freebsd.org)
Received: (from yongari@localhost)
	by repoman.freebsd.org (8.14.1/8.14.1/Submit) id m3H4Gpos032561;
	Thu, 17 Apr 2008 04:16:51 GMT (envelope-from yongari)
Message-Id: <200804170416.m3H4Gpos032561@repoman.freebsd.org>
From: Pyun YongHyeon <yongari@FreeBSD.org>
Date: Thu, 17 Apr 2008 04:16:50 +0000 (UTC)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
X-FreeBSD-CVS-Branch: RELENG_7
Cc: 
Subject: cvs commit: src/sys/pci if_rl.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2008 04:16:52 -0000

yongari     2008-04-17 04:16:50 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_7)
    sys/pci              if_rl.c 
  Log:
  MFC if_rl.c, rev 1.174 to RELENG_7.
    It seems that RealTek 8129/8139 chip reports invalid length of
    received frame under certain conditions. wpaul said the length
    0xfff0 is special meaning that indicates hardware is in the
    process of copying a packet into host memory. But it seems
    there are other cases that hardware is busy or stuck in bad
    situation even if the received frame length is not 0xfff0.
    To work-around this condition, add a check that verifys that
    recevied frame length is in valid range. If received length is out
    of range reinitialize hardware to recover from stuck condition.
  
  Revision   Changes    Path
  1.170.2.3  +5 -3      src/sys/pci/if_rl.c