Date: Thu, 11 Mar 2004 01:40:00 -0800 (PST) From: Bill Paul <wpaul@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/compat/ndis subr_ndis.c src/sys/dev/if_ndis if_ndis.c Message-ID: <200403110940.i2B9e0Mc058383@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403110940.i2B9e0Mc058383>