From owner-freebsd-net@FreeBSD.ORG Fri Jul 9 13:58:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A66F1065673 for ; Fri, 9 Jul 2010 13:58:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id E6C288FC14 for ; Fri, 9 Jul 2010 13:58:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o69DwmH9041206; Fri, 9 Jul 2010 23:58:48 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 9 Jul 2010 23:58:47 +1000 (EST) From: Ian Smith To: Shtorm In-Reply-To: <1278496982.21743.50.camel@stormi-desktop> Message-ID: <20100709233505.J54166@sola.nimnet.asn.au> References: <1278330234.10826.18.camel@stormi-desktop> <1278356796.10826.35.camel@stormi-desktop> <1278404933.20433.26.camel@stormi-desktop> <1278496982.21743.50.camel@stormi-desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Intel 82574L Gigabit Ethernet Controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:58:51 -0000 On Wed, 7 Jul 2010, Shtorm wrote: > > > Yow, 30 vlans, but only em1 is using vlans not em0? > > > > Is only em1 having watchdogs? I noticed you appear to > > have flow control off, maybe turning it on would help. > > > > I would like to see the log messages from the watchdogs. > > Jack > > Yes, em0 - plain untagged traffic to border router, em1 - tagged - one > vlan per 200-300 pppoe clients. Anyway, I saw watchdogs on em0 too, > there is no logs for it because remote syslog server connected via em0 > and it looses messages during card reset, will enable local logs to get > some info. > > Log files are almost empty, is there any driver-specific debugging > options other than TUNABLE_INT("hw.em.sbp", &em_debug_sbp)? Anyway will > try to set it to 1 and wait for watchdog. > > Here is a part from log file I have now Deleting the stuff you're most interested in :) > Jul 6 10:32:34 ntp info hostname x.x.x.8 ntpd adjusting local clock by 5.083720s > Jul 6 10:33:07 ntp info hostname x.x.x.8 ntpd adjusting local clock by 4.915903s > Jul 6 10:35:01 auth info hostname x.x.x.8 login login on ttyv2 as root > Jul 6 10:35:01 auth notice hostname x.x.x.8 login ROOT LOGIN (root) ON ttyv2 > Jul 6 10:35:24 kern crit hostname x.x.x.8 kernel em1: Watchdog timeout -- resetting [..] > Jul 6 10:37:21 ntp info hostname x.x.x.8 ntpd adjusting local clock by 3.641940s > Jul 6 10:37:46 kern crit hostname x.x.x.8 kernel em1: Watchdog timeout -- resetting [..] > Jul 6 10:38:40 kern crit hostname x.x.x.8 kernel Limiting icmp unreach > response from 237 to 200 packets/sec > Jul 6 10:39:10 kern crit hostname x.x.x.8 kernel em1: Watchdog timeout > -- resetting Probably completely unrelated, but I can't help noticing those big clock shifts by ntp over a short period amidst all this. I don't know if that could affect watchdogs, but is it a regular occurrence during these? >From your latest, a bit more noise from ntp: > Jul 8 07:23:40 server kernel: em0: Watchdog timeout -- resetting [..] > Jul 8 07:23:56 server ntpd[3687]: 2 out of 3 peers valid > Jul 8 07:23:56 server ntpd[3687]: bad peer from pool pool.ntp.org (195.214.215.17) > Jul 8 07:27:15 server kernel: em0: Watchdog timeout -- resetting Ignore if not relevant. cheers, Ian