From owner-freebsd-current Fri Oct 11 08:30:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA22611 for current-outgoing; Fri, 11 Oct 1996 08:30:38 -0700 (PDT) Received: from walkabout.asstdc.com.au (imb@walkabout.asstdc.com.au [202.12.127.73]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA22594 for ; Fri, 11 Oct 1996 08:30:30 -0700 (PDT) Received: (from imb@localhost) by walkabout.asstdc.com.au (8.7.6/BSD4.4) id BAA00199 Sat, 12 Oct 1996 01:29:39 +1000 (EST) From: michael butler Message-Id: <199610111529.BAA00199@walkabout.asstdc.com.au> Subject: Re: 3c589b + ep driver To: nao@sbl.cl.nec.co.jp (Naoki Hamada) Date: Sat, 12 Oct 1996 01:29:39 +1000 (EST) Cc: current@freebsd.org In-Reply-To: <199610090426.NAA20434@sirius.sbl.cl.nec.co.jp> from Naoki Hamada at "Oct 9, 96 01:26:51 pm" X-Comment: Phone 0419-240-180, International +61-419-240-180 X-Comment: finger imb@asstdc.com.au for PGP public key X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I found that the ep driver does not properly handle commands which > take time more than a I/O cycle. What about the following patch? (This > patch is 961006-SNAP based. Still applicable to the current, I hope.) In your patch, you've moved some of the spin-loops to a position immediately after the command which requires the wait. Since there is often some code that is run between it and the next time we need to talk to the card, it's more efficient to do those calculations first and then wait for the card to become ready - it may actually be ready by then and we've constructively used the time we would have otherwise have spent waiting for it. In this case it doesn't change things very much because the delays are relatively short but, as a matter of efficiency, I tend to do this. I do find it confusing, however, if the spin-loop doesn't have an associated comment to document which command (possibly more than a screenful before) necessitated the wait so there's probably a balance in there somewhere .. > @@ -1289,6 +1291,7 @@ > } > all_pkt: > outw(BASE + EP_COMMAND, RX_DISCARD_TOP_PACK); > + EP_BUSY_WAIT; > /* > * recompute average packet's length, the factor used is 1/8 to go down > * and 1/32 to go up Unfortunately, my particular 589b wants the wait before the discard command else it drops link-OK and goes off into the never-never .. still trying to find out why :-( michael