tasks. Since the host controllers rely on tasks to process transfer
timeouts, if a synchronous transfer from a driver was invoked from
a task and timed out, it would never complete because the single
task thread was stuck performing the synchronous transfer so couldn't
process the timeout.
This affected the axe, udav and ural drivers.
Problem hardware provided by: guido
o day and mday are the same. No need to subtract 1 from mday.
o Set dow to -1 as clock_ct_to_ts() checks this field and
returns EINVAL on any day of the week but Sunday.
Unlock the vnode in devfs_close() while calling into the driver d_close()
routine.
devfs_revoke() changes by: ups
Reviewed and bugfixes by: tegge
Tested by: mbr, Peter Holm
Approved by: pjd (mentor)
MFC after: 1 week
- Count (scheduling of) software interrupts (SWIs) as SWIs, not as
hardware interrupts.
- Don't count (scheduling of) delayed SWIs as interrupts at all, since
in the delayed case it is expected that there are many more scheduling
calls than handling calls. Perhaps all interrupts should be counted
only when they are handled, but it is only counts of delayed SWIs that
shouldn never be combined with the other counts.
subr_trap.c:
- Count (handling of) Asynchronous System Traps (ASTs) as traps, not as
software interrupts.
Before these changes, the counter for SWIs only counted ASTs, and SWIs
weren't counted separately, but a subcounter for ASTs alone is less
needed than for most other exception sources.
4.4BSD-Lite uses the counters for similar things (actually matching
their names) on its main arches (hp300, ..., !i386) where more of the
exceptions are in hardware.
snd_emu10k1 and snd_emu10kx into one line. The 'pci' dependency here
adds no value, so I eliminted it (we don't have a snd.all file that
might make it mildly useful, and even then it wouldn't be that
useful). With the pci optional component eliminated, I could use the
'|' operator. I could have also include pci on both sides of the |
operator, but since it isn't a value add at all, it was better to
eliminate it.
- Inline ship_msg() into ngs_rcvmsg().
- Plug memory leak in case if no control socket present.
- Remove malloc() and allocate the sockaddr on stack.
- style(9).
long being DMA'ed 2 (or 1) bytes past the end of the mbuf and corrupting
random kernel memory. I had forgotten about the 2 bytes of implict
padding the firmware assumes.
Sponsored by: Myricom Inc.
- Use malloc() and free() instead of MALLOC() and FREE() macros.
- Do not check malloc results if M_WAITOK was used.
- Remove linked list of all netgraph sockets. It isn't needed.
- Use ng_findhook() instead of searching the list ourselves.
- Use NG_WAITOK in syscalls.
- Remove unneeded includes.
- style(9)
directory before the ${MACHINE_ARCH}/${MACHINE_ARCH} directory so that
machine-specific files take precedence of architecture-specific ones.
This fixes the build on sun4v which doesn't use the sparc64 version
of mem.c.
Tested by: make universe
- Fix the locking protocol to eliminate races between normal I/O and AENs.
- Various small improvements and usability tweaks.
Sponsored by: IronPort
Portions Submitted by: Doug Ambrisko
- Use bus_dmamap_load_mbuf_sg() to eliminate the need for the callback and
all of the extra bookkeeping associated with it.
- Eliminate the bce_dmamap_arg structure and streamline the memory allocation
routines to not need it. This does change some of the debugging messages.
- Refactor the loop that fills the buffer descriptor so that it can be done
with a single set of logic in a single loop instead of two sets of logic.
- Eliminate the need to cache and pass descriptor indexes between the start
loop and the encap function.
- Change the start loop to always check the ifnet sendq for more work.
This significantly helps the driver withstand large UDP workloads, though
it's still not perfect. I suspect the remaining work lies with handling
the OACTIVE flag, and also in possibly streamlining the interrupt handler
some. It is, however, nearly on par with the other popular gigabit drivers
in terms of stability now.
Implement the linux_io_* syscalls (AIO). They are only enabled if the native
AIO code is available (either compiled in to the kernel or as a module) at
the time the functions are used. If the AIO stuff is not available there
will be a ENOSYS.
From the submitter:
---snip---
DESIGN NOTES:
1. Linux permits a process to own multiple AIO queues (distinguished by
"context"), but FreeBSD creates only one single AIO queue per process.
My code maintains a request queue (STAILQ of queue(3)) per "context",
and throws all AIO requests of all contexts owned by a process into
the single FreeBSD per-process AIO queue.
When the process calls io_destroy(2), io_getevents(2), io_submit(2) and
io_cancel(2), my code can pick out requests owned by the specified context
from the single FreeBSD per-process AIO queue according to the per-context
request queues maintained by my code.
2. The request queue maintained by my code stores contrast information between
Linux IO control blocks (struct linux_iocb) and FreeBSD IO control blocks
(struct aiocb). FreeBSD IO control block actually exists in userland memory
space, required by FreeBSD native aio_XXXXXX(2).
3. It is quite troubling that the function io_getevents() of libaio-0.3.105
needs to use Linux-specific "struct aio_ring", which is a partial mirror
of context in user space. I would rather take the address of context in
kernel as the context ID, but the io_getevents() of libaio forces me to
take the address of the "ring" in user space as the context ID.
To my surprise, one comment line in the file "io_getevents.c" of
libaio-0.3.105 reads:
Ben will hate me for this
REFERENCE:
1. Linux kernel source code: http://www.kernel.org/pub/linux/kernel/v2.6/
(include/linux/aio_abi.h, fs/aio.c)
2. Linux manual pages: http://www.kernel.org/pub/linux/docs/manpages/
(io_setup(2), io_destroy(2), io_getevents(2), io_submit(2), io_cancel(2))
3. Linux Scalability Effort: http://lse.sourceforge.net/io/aio.html
The design notes: http://lse.sourceforge.net/io/aionotes.txt
4. The package libaio, both source and binary:
http://rpmfind.net/linux/rpm2html/search.php?query=libaio
Simple transparent interface to Linux AIO system calls.
5. Libaio-oracle: http://oss.oracle.com/projects/libaio-oracle/
POSIX AIO implementation based on Linux AIO system calls (depending on
libaio).
---snip---
Submitted by: Li, Xiao <intron@intron.ac>
