From owner-freebsd-current Fri Sep 20 9: 6: 5 2002 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 7FD2137B401; Fri, 20 Sep 2002 09:06:04 -0700 (PDT) Received: from smtp0.adl1.internode.on.net (smtp0.adl1.internode.on.net [203.16.214.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3F043E3B; Fri, 20 Sep 2002 09:06:03 -0700 (PDT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp1471.qld.padsl.internode.on.net [150.101.178.190]) by smtp0.adl1.internode.on.net (8.12.4/8.12.4) with ESMTP id g8KG5xp5042240; Sat, 21 Sep 2002 01:36:01 +0930 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.6/8.11.6) with ESMTP id g8KG5w332706; Sat, 21 Sep 2002 02:05:58 +1000 (EST) (envelope-from mckay) Message-Id: <200209201605.g8KG5w332706@dungeon.home> To: John Baldwin Cc: Stephen McKay , current@FreeBSD.org Subject: Re: dc(4) patch References: In-Reply-To: from John Baldwin at "Fri, 20 Sep 2002 11:41:00 -0400" Date: Sat, 21 Sep 2002 02:05:58 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, 20th September 2002, John Baldwin wrote: >On 20-Sep-2002 Stephen McKay wrote: >> Not quite. Davicom cards (and your card) fail to idle the receiver. >> PNIC cards fail to idle the transmitter. So it makes just as much >> sense as any other idea to check those bits only on cards that document >> that you have to check those bits. My documentation only covers Intel. :-) > >Hmm, what if we went back then to waiting until at least one of either >TX or RX went idle? Did only waiting for one actually break any 21143 >cards? Well that's the funny thing. It's documented to be necessary on Intel 21143 chips, but I've never seen a non-zero delay between asking for the TX and RX to idle, and observing them to be idle. So we could probably delete the test-and-delay loop entirely. Waiting for just one of them to go idle, like we have in -stable, is just silly. Would you test for condition "A" and assume that means "B" is OK in any other part of the kernel? It's really hoping that idling the TX and RX take about the same time when there's no reason to believe that. I think the test in -stable is pretty much equivalent to having no test at all. The only solid documentation I've got demands *both* must be idle. But that's from Intel and describes the original chips. Hence, my view that we should test the bits on Intel chips and forget about it on the clones. Clones tend not to bother implementing all the limitations of the original anyway. If we find a clone that turns out to need the tests, we can enable them for that clone too. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message