cvs commit: src/sys/compat/ndis kern_ndis.c src/sys/dev/if_ndis
Brian F. Feldman
green at FreeBSD.org
Fri Dec 26 01:28:35 PST 2003
Bill Paul <wpaul at FreeBSD.org> wrote:
> wpaul 2003/12/25 23:01:05 PST
> FreeBSD src repository
> Modified files:
> sys/compat/ndis kern_ndis.c
> sys/dev/if_ndis if_ndis.c
> Attempt to handle the status field in the ndis_packet oob area correctly.
> For received packets, an status of NDIS_STATUS_RESOURCES means we need
> to copy the packet data and return the ndis_packet to the driver immediatel.
> NDIS_STATUS_SUCCESS means we get to hold onto the packet, but we have
> to set the status to NDIS_STATUS_PENDING so the driver knows we're
> going to hang onto it for a while.
> For transmit packets, NDIS_STATUS_PENDING means the driver will
> asynchronously return the packet to us via the ndis_txeof() routine,
> and NDIS_STATUS_SUCCESS means the driver sent the frame, and NDIS
> (i.e. the OS) retains ownership of the packet and can free it
> right away.
FWIW, ndis_return_packet() was incorrectly calling ndis_chars.nmc_return_packet_func
for both txeof and rxeof: from what you
say, it should never be calling returnfunc() on txeof but it obviously does
so every time, and my card never returns NDIS_STATUS_PENDING in p->np_oob.npo_status
so every time an rxeof is handled the .sys itself locks up because
ndis_chars.nmc_return_packet_func is being called when the driver needs it
to be freed by NDIS itself. Either way, the wrong things definitely get
freed by the ndis_free_packet() because the free() calls themselves end up
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the cvs-all