Date: Sun, 9 Jan 2000 16:33:14 +0800 From: Greg Lehey <grog@lemis.com> To: Darren Reed <darrenr@reed.wattle.id.au>, Mike Smith <msmith@FreeBSD.ORG> Cc: Warner Losh <imp@village.org>, joe@pavilion.net, dillon@apollo.backplane.com, committers@FreeBSD.ORG, current@FreeBSD.ORG Subject: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th) Message-ID: <20000109163314.A515@mojave.worldwide.lemis.com> In-Reply-To: <200001071246.XAA05593@avalon.reed.wattle.id.au>; from darrenr@reed.wattle.id.au on Fri, Jan 07, 2000 at 11:46:49PM %2B1100 References: <200001071246.XAA05593@avalon.reed.wattle.id.au> <200001072052.MAA01482@mass.cdrom.com> <200001062246.PAA80310@harmony.village.org> <200001071246.XAA05593@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 7 January 2000 at 23:46:49 +1100, Darren Reed wrote: > In some email I received from Warner Losh, sie wrote: >> >> In message <20000106212050.D95011@florence.pavilion.net> Josef Karthauser writes: >> : My 3c589d works just fine now, along with suspend/resume :) (under 4.0). >> >> The issue with the 3c589d is with its speed. It is falling back to >> the timeout routine to send data rather than getting an interrupt when >> the tx has happened (or something like this, I'm reporting second hand >> stuff). > > Whatever it is, results in ping times being 1000ms then 10ms then 1000ms > then 10ms...when it responds. This doesn't look typical of the problems we've been discussing. First, they appear to occur more with -CURRENT, and secondly they don't affect the ping times. What I've been seeing is that everything is fine until a collision occurs, after which something times out and it takes a 1 second timeout before it continues. It's easiest to see with long ftp transfers. > i.e. it's a mistake to use FreeBSD 3.x with the 3c589d. Mine worked fine under 3.x. The problem seems to have crept in in about October last year (1999). On Friday, 7 January 2000 at 12:52:28 -0800, Mike Smith wrote: >>> The issue with the 3c589d is with its speed. It is falling back to >>> the timeout routine to send data rather than getting an interrupt when >>> the tx has happened (or something like this, I'm reporting second hand >>> stuff). >> >> Whatever it is, results in ping times being 1000ms then 10ms then 1000ms >> then 10ms...when it responds. > > This is typical for interrupt misconfiguration for this driver. When you > get the interrupt configuration right, it works fine. > > (No, getting the interrupt configuration right is not a trivial task.) That may be the answer for Darren's problem. It's definitely not the case for the ones we have been discussing on -mobile. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000109163314.A515>