From owner-freebsd-hardware Sat Oct 10 10:26:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA02761 for freebsd-hardware-outgoing; Sat, 10 Oct 1998 10:26:29 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA02756; Sat, 10 Oct 1998 10:26:25 -0700 (PDT) (envelope-from rkw@Dataplex.NET) Received: from [208.2.87.5] (user5.dataplex.net [208.2.87.5]) by shrimp.dataplex.net (8.9.1/8.9.1) with ESMTP id MAA03922; Sat, 10 Oct 1998 12:47:12 -0500 (CDT) (envelope-from rkw@dataplex.net) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199810101525.LAA05659@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Oct 1998 12:24:18 -0500 To: Bill Paul From: Richard Wackerbarth Subject: Re: Call for testers for PNIC ethernet driver Cc: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:25 AM -0500 10/10/98, Bill Paul wrote: >I know I'm going to regret this, but: this is a call for testers for a >preliminary driver for PNIC-based ethernet adapters. I'll give it a try. >However after several hours of hammering on it, I could not find a >way to properly update the chip's pointer after it had been loaded >the first time. Even after shutting the transmitter off, updating the >register, and observing that its contents had changed, the chip would >refuse to transmit from the newly loaded list. (Instead, it would yield >'no tx buffer available' errors). The only way to really clear the >pointer is to do a soft reset of the chip, but that trashes the rest of >the chip state. > >My solution to this was to allocate one extra descriptor (called >the kludge descriptor) and tack it on the end of each list with >the 'own' bit cleared. This would cause the chip to go idle when >it hit the end of the current list with its pointer set to the >address of the kludge descriptor, which I could then update to >point to anther arbitrarily located list. It means loading an >extra descriptor into the chip for each frame, which sucks, but >which hopefully won't impact performace that much. Sounds like the 1394 driver that I wrote last year. I was able to do a slight variation on your theme. I had a single kludge descriptor per DMA channel. When I was ready to queue a new batch of output, I set the last link of the batch chain to point to the kludge. I then went back and changed the link of the (remembered) previous chain to point to the head of my addition. There was the usual race condition. If the hardware "won", it jumped off to the kludge and gave its halt interrupt. If "I" won, the hardware saw the list as if it had always been a single chain and never knew that the kludge block had been at its earlier location. In my case, I was able to keep the channel busy most of the time and rarely took the extra hit. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message