From owner-cvs-src@FreeBSD.ORG Sun Dec 24 05:52:02 2006 Return-Path: <owner-cvs-src@FreeBSD.ORG> X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAEFE16A47B; Sun, 24 Dec 2006 05:52:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7EAFA13C473; Sun, 24 Dec 2006 05:52:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBO5psbW036209; Sat, 23 Dec 2006 22:52:00 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <458E1579.1050907@samsco.org> Date: Sun, 24 Dec 2006 00:51:53 -0500 From: Scott Long <scottl@samsco.org> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Bruce Evans <bde@zeta.org.au> References: <200612201203.kBKC3MhO053666@repoman.freebsd.org> <20061220132631.GH34400@FreeBSD.org> <20061222003115.R16146@delplex.bde.org> <20061223215918.GA33627@lath.rinet.ru> <20061224124016.F24444@delplex.bde.org> In-Reply-To: <20061224124016.F24444@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, Bruce Evans <bde@FreeBSD.org>, Oleg Bulyzhin <oleg@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/bge if_bge.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: Sun, 24 Dec 2006 05:52:03 -0000 Bruce Evans wrote: > On Sun, 24 Dec 2006, Oleg Bulyzhin wrote: > >> On Fri, Dec 22, 2006 at 01:24:45AM +1100, Bruce Evans wrote: >>> On Wed, 20 Dec 2006, Gleb Smirnoff wrote: >>>> >>>> I have a suspicion that this may cause a problem under high load. >>>> Imagine >>>> that thread #1 is spinning in bge_start_locked() getting packets out >>>> of interface queue and putting them into TX ring. Some other threads >>>> are >>>> putting the packets into interface queue while its lock is temporarily >>>> relinguished be the thread #1. In the same time interrupts happen, some >>>> packets are sent, but the TX ring is never got empty. >>>> >>>> The above scenario will cause a fake watchdog event. >>> >>> bge_start_locked() starts with the bge (sc) lock held and never releases >>> it as far as I can see. This this problem can't happen (the lock >>> prevents both txeof and the watchdog from being reached before start >>> resets the timeout to 5 seconds). > >> it's quite unusal) and it is not lock related: >> 1) bge_start_locked() & bge_encap fills tx ring. >> 2) during next 5 seconds we do not have packets for transmit (i.e. no >> bge_start_locked() calls --> no bge_timer refreshing) >> 3) for any reason (don't ask me how can this happen), chip was unable to >> send whole tx ring (only part of it). >> 4) here we have false watchdog - chip is not wedged but bge_watchdog >> would >> reset it. > > Then it is a true watchdog IMO. Something is very wrong if you can't send > 512 packets in 5 seconds (or even 1 packet in 5/512 seconds). > No it's not wrong. You can be under heavy load and be constantly preempted. Or you could be getting a fed a steady stream of traffic and have a driver that is smart enough to clean the TX-complete ring in if_start if it runs out of TX slots. These effects have been observed in at least the if_em driver. Scott