Add a new API for allocating unit number (-like) resources.
Allocation is always lowest free unit number.
A mixed range/bitmap strategy for maximum memory efficiency. In
the typical case where no unit numbers are freed total memory usage
is 56 bytes on i386.
malloc is called M_WAITOK but no locking is provided (yet). A bit of
experience will be necessary to determine the best strategy. Hopefully
a "caller provides locking" strategy can be maintained, but that may
require use of M_NOWAIT allocation and failure handling.
While calling perror() on send() failure was useful for debugging the
if_em "wedging" problem, large numbers of perror() calls impacts send
performance. As such, just count the error, don't print it.
Add syscall_timing, a simple timing micro-benchmark for some
characteristic system calls. I've been sending this to people for
a while, and figured it would be more efficient to just put it in
CVS.
Merge netipsec/key.c:1.17 into KAME pfkey implementation:
date: 2004/09/26 02:01:27; author: sam; state: Exp; lines: +0 -5
Correct handling of SADB_UPDATE and SADB_ADD requests. key_align may
split the mbuf due to use of m_pulldown. Discarding the result because
of this does not make sense as no subsequent code depends on the entire
msg being linearized (only the individual pieces). It's likely
something else is wrong here but for now this appears to get things back
to a working state.
Submitted by: Roselyn Lee
This change was also made in the KAME CVS repository as key.c:1.337 by
itojun.
philip [Wed, 29 Sep 2004 23:49:57 +0000 (23:49 +0000)]
Introduce a tunable to disable support for Synaptics touchpads. A number of
people have reported problems (stickyness, aiming difficulty) which is proving
difficult to fix, so this will default to disable until sometime after 5.3R.
To enable Synaptics support, set the 'hw.psm.synaptics_support=1' tunable.
We seem to have occasions where sending an IPI takes significantly
longer than 'normal'. The cause is still being tracked down but
in the meantime there are machines where raising IPI_RETRIES does
help - it's not just a case of the machine staying locked up longer
and then panic-ing anyway. Several helpful folks on sparc64@ tried
a patch that helped figure out what to raise this number to.
Report once that the device isn't there, but keep trying. Don't
filter the errno values. They don't make as much sense as they used
to given how we do devices in /dev.
Prevent the unexpected deallocation of a page table page while performing
pmap_copy(). This entails additional locking in pmap_copy() and the
addition of a "flags" parameter to the page table page allocator for
specifying whether it may sleep when memory is unavailable. (Already,
pmap_copy() checks the availability of memory, aborting if it is scarce.
In theory, another CPU could, however, allocate memory between
pmap_copy()'s check and the call to the page table page allocator,
causing the current thread to release its locks and sleep. This change
makes this scenario impossible.)
Only fall back to probing the floppy drives via hints if there is a failure
in the actual _FDE parsing. If the failure occurs earlier such as in
fdc_attach() then don't try to probe any drives.
MFC after: 3 days
Reviewed by: njl
Tested by: Christian Laursen xi at borderworlds dot dk
When opening a pipe, usbd_setup_pipe() will do a usbd_clear_endpoint_stall()
to make sure the pipe is ready. Some devices apparently don't support
the clear stall command however. So what happens when you issue such
devices a clear stall command? Typically, the command just times out.
This, at least, is the behavior I've observed with two devices that
I own: a Rio600 mp3 player and a T-Mobile Sidekick II.
It used to be that after the timeout expired, the pipe open operation
would conclude and you could still access the device, with the only
negative effect being a long delay on open. But in the recent past,
someone added code to make the timeout a fatal error, thereby breaking
the ability to communicate with these devices in any way.
I don't know exactly what the right solution is for this problem:
presumeably there is some way to determine whether or not a device
supports the 'clear stall' command beyond just issuing one and waiting
to see if it times out, but I don't know what that is. So for now,
I've added a special case to the error checking code so that the
timeout is once again non-fatal, thereby letting me use my two
devices again.
Fixed symlinking /var/named/etc/namedb to /etc/namedb.
A second "make distrib-dirs" createed a symlink in /var/namedb/etc/namedb.
A third "make distrib-dirs" failed.
Add an additional struct inpcb * argument to pfil(9) in order to enable
passing along socket information. This is required to work around a LOR with
the socket code which results in an easy reproducible hard lockup with
debug.mpsafenet=1. This commit does *not* fix the LOR, but enables us to do
so later. The missing piece is to turn the filter locking into a leaf lock
and will follow in a seperate (later) commit.
This will hopefully be MT5'ed in order to fix the problem for RELENG_5 in
forseeable future.
Suggested by: rwatson
A lot of work by: csjp (he'd be even more helpful w/o mentor-reviews ;)
Reviewed by: rwatson, csjp
Tested by: -pf, -ipfw, LINT, csjp and myself
MFC after: 3 days
gshapiro assures me that uid bind is not necessary for /etc/namedb,
so we'll use the more secure default till I have a chance to prove
myself wrong. :)
Add a /var/stats directory to be enabled in named.conf.
Give users the ability to load a mac_bsdextended(4) ruleset on boot (defaults
to NO of course). Provide a basic ruleset file, rc.bsdextended, but allow
the filename to be overridden through rc.conf.
Use generic infrastructure for the ucom driver instead of local stuff.
This changes the naming of USB serial devices to: /dev/ttyU%d and
/dev/cuaU%d for call-in and call-out devices respectively. (Please
notice: capital 'U')
Please also note that we now have .init and .lock devices for USB
serial ports. These are not persistent across device removal. devd(8)
can be used to configure them on attachment time.
These changes also improve the chances of the system surviving if
the USB device is unplugged at an inconvenient time. At least we
do not rip things apart while there are any threads in the device
driver anymore.
Remove cdevsw, rely on the tty generic one.
Don't make_dev(), use ttycreate() which does all the magic.
In detach, do close procesing if we ripped things apart
while the device was open. Call ttyfree() once we're done
cleaning up.
Add functions to create and free the "tty-ness" of a serial port in a
generic way. This code will allow a similar amount of code to be
removed from most if not all serial port drivers.
Add generic cdevsw for tty devices.
Add generic slave cdevsw for init/lock devices.
Add ttypurge function which wakes up all know generic sleep
points in the tty code, and calls into the hw-driver if it
provides a method.
Add ttycreate function which creates tty device and optionally
cua device. In both cases .init/.lock devices are created
as well.
Change ttygone() slightly to also call the hw driver provided
purge routine.
Add ttyfree() which will purge and destroy the cdevs.
Add ttyconsole mode for setting console friendly termios
on a port.
improve the mbuf m_print function.. Only pull length from pkthdr if there
is one, detect mbuf loops and stop, add an extra arg so you can only print
the first x bytes of the data per mbuf (print all if arg is -1), print
flags using %b (bitmask)...
No code in the tree appears to use m_print, and it's just a maner of adding
-1 as an additional arg to m_print to restore original behavior..
Arrgh. Recently I tried using ugen(4) in an application that uses
select(2), and discovered to my horror that ugen(4)'s bulk in/out support
is horribly lobotomized. Bulk transfers are done using the synchronous
API instead of the asynchronous one. This causes the following broken
behavior to occur:
- You open the bulk in/out ugen device and get a descriptor
- You create some other descriptor (socket, other device, etc...)
- You select on both the descriptors waiting until either one has
data ready to read
- Because of ugen's brokenness, you block in usb_bulk_transfer() inside
ugen_do_read() instead of blocking in select()
- The non-USB descriptor becomes ready for reading, but you remain blocked
on select()
- The USB descriptor becomes ready for reading
- Only now are you woken up so that you can ready data from either
descriptor.
The result is select() can only wake up when there's USB data pending. If
any other descriptor becomes ready, you lose: until the USB descriptor
becomes ready, you stay asleep.
The correct approach is to use async bulk transfers, so I changed
the read code to use the async bulk transfer API. I left the write
side alone for now since it's less of an issue.
Note that the uscanner driver has the same brokenness in it.
fix jumbo frames as much as they can be fixed for re. We now cap the MTU
to 7422 since it appears that the 8169S can't transmit anything larger..
The 8169S can receive full jumbo frames, but we don't have an mru to let
the upper layers know this...
add fixup so that this driver should work on alignment constrained platforms
(!i386 && !amd64)
Add an assertion that the pcb_nsaved field of the pcb be less than
MAXWIN to the register window manipulation functions - rwindow_load()
calls rwindow_save() so this one addition should take care of both.
This should help find places that pcb_nsaved doesn't get initialized
properly.
Calling fuword from fuword32 with bl and without returning after is really a bad
idea.
Any way I get a customized CVS template with "Pointy hat to: cognet"
pre-filled ?
Amend the named chroot update instructions by adding a stop and start
of syslogd. The rc.d/syslogd script has the logic already to create
a socket in the chroot dir, it just needs to be restarted.
Create a named chroot directory structure in /var/named, and use it
by default when named is enabled. Also, improve our default directory
layout by creating /var/named/etc/namedb/{master|slave} directories,
and use the former for the generated localhost* files.
Rather than using pax to copy device entries, mount devfs in the
chroot directory.
There may be some corner cases where things need to be adjusted,
but overall this structure has been well tested on a production
network, and should serve the needs of the vast majority of users.
UPDATING has instructions on how to do the conversion for those
with existing configurations.
Turns out that revision 1.52 was a bad idea. It broke the long
standing ability to list a non-existant device in /etc/ttys to keep it
from dying. This is a documented feature of init(8):
The init utility can also be used to keep arbitrary daemons running,
automatically restarting them if they die. In this case, the first field
in the ttys(5) file must not reference the path to a configured device
node and will be passed to the daemon as the final argument on its com-
mand line. This is similar to the facility offered in the AT&T System V
UNIX /etc/inittab.
So rather than fix the man page to 'break' this feature, back out the change.
At the time this change was made, people felt that the spamage from
getty was annoying on headless consoles. Andrew Gallatin noted:
> Most of my machines are headless without video cards and use a serial
> console. With devfs this means that /dev/ttyv[1-N] do not exist and
> getty bitches like this:
>
> Sep 26 11:00:11 monet getty[543]: open /dev/ttyv1: No such file or directory
and we went off and applied this hack rather than fixing getty to
sleep forever when it gets an unknown device, as was Andrew's other
suggestion. Since it breaks things, I'm off to do that instead.
Avoid race while synchronizing components. It is very hard to bump into,
but it is possible:
1. Read data from good component for synchronization.
2. Write data to the same area.
3. Write synchronization data, which are now stale.
Initialize the count of saved register windows to 0 in the pcb created
for the new thread. The rest of the fields in the pcb wind up being
written to before they're read as a normal part of the pcb usage but
this field may be read upon return to userland, having it be uninitialized
garbage is bad.
Submitted by: Andrew Belashov (bel at orel dot ru)
Reviewed by: jake
MFC after: 3 days
Previously I thought I was seeing a failure to install the .5 man pages
with this configuration, but Ruslan tells me that I was probably mistaken,
and on retest the .5 pages are being installed just fine.
Therefore reverse the MAN[58] change in favor of the more modern syntax.
Avoid race while synchronizing components. It is very hard to bump into,
but it is possible:
1. Read data from good component for synchronization.
2. Write data to the same area.
3. Write synchronization data, which are now stale.