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

[Bill Paul]

wpaul       2004/03/11 01:40:00 PST

  FreeBSD src repository

  Modified files:
    sys/compat/ndis      subr_ndis.c 
    sys/dev/if_ndis      if_ndis.c 
  Log:
  Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers
  for Windows are deserialized miniports. Such drivers maintain their own
  queues and do their own locking. This particular driver is not deserialized
  though, and we need special support to handle it correctly.
  
  Typically, in the ndis_rxeof() handler, we pass all incoming packets
  directly to (*ifp->if_input)(). This in turn may cause another thread
  to run and preempt us, and the packet may actually be processed and
  then released before we even exit the ndis_rxeof() routine. The
  problem with this is that releasing a packet calls the ndis_return_packet()
  function, which hands the packet and its buffers back to the driver.
  Calling ndis_return_packet() before ndis_rxeof() returns will screw
  up the driver's internal queues since, not being deserialized,
  it does no locking.
  
  To avoid this problem, if we detect a serialized driver (by checking
  the attribute flags passed to NdisSetAttributesEx(), we use an alternate
  ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to
  (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the
  packet won't be processed until after ndis_rxeof_serial() returns.
  
  Note that another approach is to always copy the packet data into
  another mbuf and just let the driver retain ownership of the ndis_packet
  structure (ndis_return_packet() never needs to be called in this
  case). I'm not sure which method is faster.
  
  Revision  Changes    Path
  1.51      +1 -0      src/sys/compat/ndis/subr_ndis.c
  1.44      +123 -0    src/sys/dev/if_ndis/if_ndis.c