Date: Sat, 21 Sep 2002 02:05:58 +1000 From: Stephen McKay <smckay@internode.on.net> To: John Baldwin <jhb@FreeBSD.org> Cc: Stephen McKay <smckay@internode.on.net>, current@FreeBSD.org Subject: Re: dc(4) patch Message-ID: <200209201605.g8KG5w332706@dungeon.home> In-Reply-To: <XFMail.20020920114100.jhb@FreeBSD.org> from John Baldwin at "Fri, 20 Sep 2002 11:41:00 -0400" References: <XFMail.20020920114100.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209201605.g8KG5w332706>