Use IFQ_MAXLEN instead. This seemed like a good idea at the time since
most 3c509s have all of 2k for their TX fifo. My intention was to revisit
ifq_maxlen and auto-scale it or something.
ttcp-t: 16777216 bytes in 21.53 real seconds = 761.07 KB/sec +++
ttcp-t: 2771 I/O calls, msec/call = 7.96, calls/sec = 128.72
ttcp-t: 0.0user 2.9sys 0:21real 13% 20i+280d 222maxrss 0+2pf 717+0csw
ttcp-r: 16777216 bytes in 14.11 real seconds = 1161.48 KB/sec +++
ttcp-r: 2050 I/O calls, msec/call = 7.05, calls/sec = 145.33
ttcp-r: 0.0user 1.4sys 0:14real 10% 87i+1198d 196maxrss 0+1pf 1949+186csw
I've got some tweaks that move the TX speed up to the RX speed but I've
got to groom them from the mess I've made of my source tree.
Yelled at by: wpaul
ddb is entered. Don't refer to `in_Debugger' to see if we
are in the debugger. (The variable used to be static in Debugger()
and wasn't updated if ddb is entered via traps and panic anyway.)
- Don't refer to `in_Debugger'.
- Add `db_active' to i386/i386/db_interface.d (as in
alpha/alpha/db_interface.c).
- Remove cnpollc() stub from ddb/db_input.c.
- Add the dbctl function to syscons, pcvt, and sio. (The function for
pcvt and sio is noop at the moment.)
Jointly developed by: bde and me
(The final version was tweaked by me and not reviewed by bde. Thus,
if there is any error in this commit, that is entirely of mine, not
his.)
Some changes were obtained from: NetBSD
The problem occurs when an indirect block and a data block are
being allocated at the same time. For example when the 13th block
of the file is written, the filesystem needs to allocate the first
indirect block and a data block. If the indirect block allocation
succeeds, but the data block allocation fails, the error code
dellocates the indirect block as it has nothing at which to point.
Unfortunately, it does not deallocate the indirect block's associated
dependencies which then fail when they find the block unexpectedly
gone (ptr == 0 instead of its expected value). The fix is to fsync
the file before doing the block rollback, as the fsync will flush
out all of the dependencies. Once the rollback is done the file
must be fsync'ed again so that the soft updates code does not find
unexpected changes. This approach is much slower than writing the
code to back out the extraneous dependencies, but running out of
disk space is not expected to be a common occurence, so just getting
it right is the main criterion.
PR: kern/15063
Submitted by: Assar Westerlund <assar@stacken.kth.se>
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.
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>
