Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Oct 1998 12:24:18 -0500
From:      Richard Wackerbarth <rkw@Dataplex.NET>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        hackers@FreeBSD.ORG, hardware@FreeBSD.ORG
Subject:   Re: Call for testers for PNIC ethernet driver
Message-ID:  <l03130301b2454637f4c8@[208.2.87.5]>
In-Reply-To: <199810101525.LAA05659@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130301b2454637f4c8>