Date: Fri, 6 Sep 2002 11:59:28 +0200 (CEST) From: Martin Blapp <mb@imp.ch> To: Donald Becker <becker@scyld.com> Cc: <hackers@freebsd.org>, <tulip-bug@scyld.com> Subject: Re: [tulip-bug] FreeBSD Problems with dc(4) ADMtek AN985 chip Message-ID: <20020906110858.I39212-100000@levais.imp.ch> In-Reply-To: <Pine.LNX.4.44.0209060449140.1023-100000@beohost.scyld.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > This technique cannot be efficiently used with mbufs in *BSD, so there > must be two different ring handling code paths: both chained > and wrapped-ring configurations. Ok > That's very likely a media selection problem, rather than a Rx > descriptor problem. Of course resetting the chip will clear a > descriptor hang, but that wouldn't be my first guess. It looks like you are right. I've seen two problems and they produced mixed results. 1.) TX underrun (FreeBSD specific) 2.) Media selection problem after small timeouts (cable problems) (Linux and FreeBSD) But why I don't see this in wind*** ? I run now this patch for two days (Enable automatically TX underrun recovery) http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34236 This patch fixed the problems that all connections got dropped. After have fixed this, I still had the connection problems, but the connections were still active. It looks now that the media selection does not work all the times. If the connection goes away for just a few moments 1/10sec or faster (maybe two times fery fast) the link stays broken even if the connection is there again 100%. If the connection is interrupted more than 5/10sec the link works again. My switch does still show a active link, and ifconfig does show it as active. It looks that some recovery function does not work as expected. How does this have to behave normally. Hardware bug (chip) or software bug ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020906110858.I39212-100000>