possible bug in e100bex ndis DDK 6000 sample ?

The function NICReturnRFD(Adapter, pMpRfd)

pulls a HW RFD corresponding to pMpRfd from the linked list and adds
it to the tail. While sofware links will be ok, the HW RFDs link will
be broken because,


pHwRfd->RfdCbHeader.CbStatus = 0;
pHwRfd->RfdActualCount = 0;
pHwRfd->RfdCbHeader.CbCommand = (RFD_EL_BIT);
pHwRfd->RfdCbHeader.CbLinkPointer = DRIVER_NULL;


AND

// Link it onto the end of the chain dynamically
pHwRfd = pLastMpRfd->HwRfd;
pHwRfd->RfdCbHeader.CbLinkPointer = pMpRfd->HwRfdPhys;
pHwRfd->RfdCbHeader.CbCommand = 0;

WILL only fix the CURRENT and NEXT links and NOT the PREVIOUS HW RFD
link.

There should be a way to fix the previous HW RFD link pointer also.
something like pPREV_RFD->RfdCbHeader.CbLinkPointer = PENULTIMATE_TAIL-
>RFD_PA

This code luckily works as long as pMpRfd in NICReturnRFD(Adapter,
pMpRfd) is the HEAD ENTRY. In MpHandleRecvInterrupt ( ... ) it was a
lucky case and in MPReturnNetBufferLists(...) and a couple of other
places it looks like a BUG.

Can some one clarify?

I have attempted a pictorial description of the bug

hw_rfd1 -> hw_rfd2 -> hw_rfd3

will become 2 sets

hw_rfd1 -> hw_rfd2 AND a hanging hw_rfd3 -> hw_rfd2 !! because of bad
linking of
pHwRfd->RfdCbHeader.CbLinkPointer

thx
ugk

Stephan
Wed Dec 12 01:45:06 PST 2007

I don't get the point, sorry. I took a quick look at the sample source
code and it looks ok. Opposed to that, your "pictorial description"
would seem buggy:

"hw_rfd1 -> hw_rfd2 AND a hanging hw_rfd3 -> hw_rfd2 !!"

The new RFD, i.e. RFD3 in this case, will be the new tail, so how come
you think RFD3 is before RFD2 and RFD2 is still the tail?

Note that the hardware RFDs are chained in a singly linked list,
whereas the software "receive list" is a doubly linked list.

Correct me if I am wrong.

Stephan
---
On Dec 7, 7:16 am, kernw...@yahoo.com wrote:
> The function NICReturnRFD(Adapter, pMpRfd)
>
> pulls a HW RFD corresponding to pMpRfd from the linked list and adds
> it to the tail. While sofware links will be ok, the HW RFDs link will
> be broken because,
>
> pHwRfd->RfdCbHeader.CbStatus = 0;
> pHwRfd->RfdActualCount = 0;
> pHwRfd->RfdCbHeader.CbCommand = (RFD_EL_BIT);
> pHwRfd->RfdCbHeader.CbLinkPointer = DRIVER_NULL;
>
> AND
>
> // Link it onto the end of the chain dynamically
> pHwRfd = pLastMpRfd->HwRfd;
> pHwRfd->RfdCbHeader.CbLinkPointer = pMpRfd->HwRfdPhys;
> pHwRfd->RfdCbHeader.CbCommand = 0;
>
> WILL only fix the CURRENT and NEXT links and NOT the PREVIOUS HW RFD
> link.
>
> There should be a way to fix the previous HW RFD link pointer also.
> something like pPREV_RFD->RfdCbHeader.CbLinkPointer = PENULTIMATE_TAIL-
>
> >RFD_PA
>
> This code luckily works as long as pMpRfd in NICReturnRFD(Adapter,
> pMpRfd) is the HEAD ENTRY. In MpHandleRecvInterrupt ( ... ) it was a
> lucky case and in MPReturnNetBufferLists(...) and a couple of other
> places it looks like a BUG.
>
> Can some one clarify?
>
> I have attempted a pictorial description of the bug
>
> hw_rfd1 -> hw_rfd2 -> hw_rfd3
>
> will become 2 sets
>
> hw_rfd1 -> hw_rfd2 AND a hanging hw_rfd3 -> hw_rfd2 !! because of bad
> linking of
> pHwRfd->RfdCbHeader.CbLinkPointer
>
> thx
> ugk