From owner-freebsd-current@FreeBSD.ORG Mon Mar 20 07:12:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D6D016A401 for ; Mon, 20 Mar 2006 07:12:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC39F43D48 for ; Mon, 20 Mar 2006 07:12:04 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1035634nzf for ; Sun, 19 Mar 2006 23:12:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=gQwbmhjYpxUo/6e2kFYLpsxtcbENtiAHBUtGhNDZo3RVGyemREUo5tzc+yMsfda2FFwP7SZVPgxBEGeeOPYK3iLsqHgNjI5oSSm8hsyQVUsY/K5XJ8dTjjohZUFSrydeS9l1Br5/di+P+G4qkWf4Zos2GVKiK10E1juCQWaOyAs= Received: by 10.37.14.63 with SMTP id r63mr102430nzi; Sun, 19 Mar 2006 23:12:03 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 12sm2374855nzn.2006.03.19.23.12.02; Sun, 19 Mar 2006 23:12:03 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k2K7BxRb076411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Mar 2006 16:11:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k2K7Bxsd076410; Mon, 20 Mar 2006 16:11:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 20 Mar 2006 16:11:59 +0900 From: Pyun YongHyeon To: Frank Behrens Message-ID: <20060320071159.GA76305@cdnetworks.co.kr> References: <200603171426.k2HEQJ9L085859@pinky.frank-behrens.de> <200603200626.k2K6Qq2M029733@pinky.frank-behrens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603200626.k2K6Qq2M029733@pinky.frank-behrens.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: call for sk(4) testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 07:12:06 -0000 On Mon, Mar 20, 2006 at 07:26:48AM +0100, Frank Behrens wrote: > Pyun YongHyeon wrote on 20 Mar 2006 10:36: > > Thanks for your report. > > If you find any unusual things related with sk(4) please let me know. > > Unfortunalety I must report an issue. Yesterday I had after several > weeks of fine running: > Mar 19 17:59:08 moon kernel: sk0: watchdog timeout > Mar 19 17:59:08 moon kernel: sk0: link state changed to DOWN > Stock sk(4) had a flaw on sending TX command to NIC due to hardware related races. Rev. 1.90 of if_sk.c tried to fix it by keep resending the start TX command if driver detects pending packets to be transmitted. Since the check is done in interrupt handler it would fail to detect the stuck condition if the first TX command was lost. I modified the driver to enable a TX polling timer to reissue TX command periodically as stated in SK NET GENESIS data sheet. New driver is available at: http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h > The problem is not the watchdog timeout message itself, but that the No. The watchdog timeout message is serious one. It wouldn't recover from its stuck state without manual interface down/up procedure. > links goes down. Fortunately I have in my crontab still a "safety > belt", calling every 12 minutes > (ifconfig sk0 | fgrep active >/dev/null) || (ifconfig sk0 down; ifconfig sk0 up; ifconfig sk0) > > So the system could recover without user interaction: > Mar 19 18:12:01 moon kernel: sk0: link state changed to UP > Mar 19 18:12:01 moon kernel: sk0: phy failed to come ready > Yup, this is one thing I'd like to fix. >From time to time I saw the PHY message during sk(4) module load but it seems to work correctly in spite of the dereadful message(I think the same thing happens on stock driver too). So I guess you may safely ignore that message. If you still see "watchdog timeout message" please let me know. -- Regards, Pyun YongHyeon