have been cleaned up by deallocte_dependencies(). Once that is done, it
is safe to post the request to free the blocks. A similar change is also
needed for the freefile case.
PC Card (PCMPC100). the entry was one character
short...the final ")" was missing.
Pointed out by: Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org
Packets are received inside USB bulk transfer callbacks, which run at
splusb() (actually splbio()). The packet input queues are meant to be
manipulated at splimp(). However the locking apparently breaks down under
certain circumstances and the input queues can get trampled.
There's a similar problem with if_ppp, which is driven by hardware/tty
interrupts from the serial driver, but which must also manipulate the
packet input queues at splimp(). The fix there is to use a netisr, and
that's the fix I used here. (I can hear you groaning back there. Hush up.)
The usb_ethersubr module maintains a single queue of its own. When a
packet is received in the USB callback routine, it's placed on this
queue with usb_ether_input(). This routine also schedules a soft net
interrupt with schednetisr(). The ISR routine then runs later, at
splnet, outside of the USB callback/interrupt context, and passes the
packet to ether_input(), hopefully in a safe manner.
The reason this is implemented as a separate module is that there are
a limited number of NETISRs that we can use, and snarfing one up for
each driver that needs it is wasteful (there will be three once I get
the CATC driver done). It also reduces code duplication to a certain
small extent. Unfortunately, it also needs to be linked in with the
usb.ko module in order for the USB ethernet drivers to share it.
Also removed some uneeded includes from if_aue.c and if_kue.c
Fix suggested by: peter
Not rejected as a hairbrained idea by: n_hibma
of the SOA 'minimum' field. Now it's necessary to define $TTL seperately
to shut it up. Bind does reasonable things by default but it's annoying
still.
PR: 15834
Submitted by: Daniel Lewart <d-lewart@uiuc.edu>
Also, in addition to the previous log message, the last change had a fix
for the case where where f.mntfromname is a relative path like da0a.
Submitted by: bde
