From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 09:30:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7FF516A415 for ; Thu, 19 Oct 2006 09:30:51 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E6FD43D4C for ; Thu, 19 Oct 2006 09:30:51 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id B48905A0C46; Thu, 19 Oct 2006 19:30:49 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 8A26B2740A; Thu, 19 Oct 2006 19:30:48 +1000 (EST) Date: Thu, 19 Oct 2006 19:30:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Scott Long In-Reply-To: <453724CA.8070609@samsco.org> Message-ID: <20061019192654.U77123@delplex.bde.org> References: <2a41acea0610181046k822afd1qcec4187dc8514187@mail.gmail.com> <2a41acea0610181531y732cd5sa7bf733cc445491c@mail.gmail.com> <20061018224233.GA1632@xor.obsecurity.org> <20061019110950.X75878@delplex.bde.org> <4536EF19.2060201@samsco.org> <20061019141748.Y76352@delplex.bde.org> <45371B91.5090507@samsco.org> <20061019164814.L76712@delplex.bde.org> <453724CA.8070609@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-net , Jack Vogel , Kris Kennaway Subject: Re: em network issues 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: Thu, 19 Oct 2006 09:30:51 -0000 On Thu, 19 Oct 2006, Scott Long wrote: > Bruce Evans wrote: >> On Thu, 19 Oct 2006, Scott Long wrote: >>> Can you be more specific as to the 'bad things'? >> >> Not very. Maybe interrupts don't get reenabled as intended. Then the >> symptoms get mutated by watchdog timeouts. > > Then yes, I'm already thinking of a better way to do the interrupt > enable/disable thing. I am still very surprised that the hardware > cannot be silenced by doing a read and/or write of a status register, > like most other hardware. If that were possible, this would be a very > simple problem. Er, what is it that em_disable_intr() disables? The problem might go the other way, being that em_enable_intr() doesn't always work due to the device not liking high frequency toggling of the interrupt mask register. Bruce