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
Driver is not functional yet, but does compile. Tests with xe cards
indicates that it doesn't panic the machine when they are present, but
fail to probe. Interface help in the pcic/pccard layers are needed to
complete this driver.
o ifdef out pccardchip.h (almost all of it, there are dangling bits
o Add rid/res members to pccard_function
o remove pct/pch from pccard_softc
o map memory properly in scan_cis (almost, see XXX for more work)
o manage ccr.
o remove bogus comment I added about touching the ccr being a layering
violation for pccard. It is properly done at that level.
o More function prototyping
whilst we are playing or recording. since we should irq ~20 times/sec when
active, this should never trigger. in theory. if it never does trigger,
the check will be removed.
to wake up any processes waiting via PIOCWAIT on process exit, and truss
needs to be more aware that a process may actually disappear while it's
waiting.
Reviewed by: Paul Saab <ps@yahoo-inc.com>
1) Fastpath deletions. When a file is being deleted, check to see if it
was so recently created that its inode has not yet been written to
disk. If so, the delete can proceed to immediately free the inode.
2) Background writes: No file or block allocations can be done while the
bitmap is being written to disk. To avoid these stalls, the bitmap is
copied to another buffer which is written thus leaving the original
available for futher allocations.
3) Link count tracking. Constantly track the difference in i_effnlink and
i_nlink so that inodes that have had no change other than i_effnlink
need not be written.
4) Identify buffers with rollback dependencies so that the buffer flushing
daemon can choose to skip over them.
it only on the buf_daemon process). The problem is that when the
syncer process starts running the worklist, it wants to delete
lots of files. It does this by VFS_VGET'ing the vnodes, clearing
the blocks in them and bdwrite'ing the buffer. It can process close
to a thousand files per second which generates a large number of
dirty buffers. So, giving it special priviledge at the buffer trough
leads to trouble as the buf_daemon does occationally need a free
buffer to proceed and if the syncer has used every last one up,
we are toast.
of dirrem structure rather than the collaterally created freeblks
and freefile structures. Limit the rate of buffer dirtying by the
syncer process during periods of intense file removal.
check before the inode is unlocked while grabbing its parent directory.
Once it is unlocked, other operations may slip in that could make
the inode-is-flushed check fail. Allowing other writes to the inode
before returning from fsync does not break the semantics of fsync
since we have flushed everything that was dirty at the time of the
fsync call.
hinted at in the previous config(8) commits. I've spoken about this with
a few people and after the initial suprise wore off they thought it wasn't
a bad idea. The upshot of it is that all the files*, Makefile*, options*
files are all right next to each other in the hope that people making
changes to one set will remember the others.
Note, config(8) looks to sys/conf first, and falls back to sys/$mach/conf
still, so this doesn't stop people working in subdirs for new platforms.
But once it's in the tree it can be moved next to the other files so that
the non-i386 platforms are (hopefully) treated a little better than as if
they were "second class" ports.
This does not change any user editable files. the config program is
still run in the same directory as before, the per-platform files
(GENERIC, LINT etc) are still in the same place.
