cvs commit: src/sys/compat/ndis kern_ndis.c src/sys/dev/if_ndis if_ndis.c

[Brian F. Feldman]

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 
>   Log:
>   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 
crashing :-(

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\