need to mask off the page offset bits. (This operation made some sense
prior to i386/i386/pmap.c revision 1.254 when we passed a physical address
rather than a vm_page pointer to pmap_enter().)
Discussed extensively with KAME. The API author's intent isn't clear at this
point, so rather than remove the code entirely, #if 0 out and put a big
comment in for now. The IPV6_RECVPATHMTU sockopt is available if the
application wants to be notified of the path MTU to optimize packet sizes.
Thanks to JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> for putting up
with my incessant badgering on this issue, and fenner for pointing out
the API issue and suggesting solutions.
data endpoints. The control endpoint doesn't need read/write/poll
operations, and more importantly, the thread counts should be
separate so that the control endpoint can properly reference itself
while deleting and recreating the data endpoints.
* Add some macros that handle referencing/releasing devices, and use them
for sleeping/woken-up and open/close operations as apppropriate.
* Use d_purge for FreeBSD, and a loop testing the open status for all
the endpoints for NetBSD and OpenBSD, so that when the device is
detached, the right thing always happens.
restart the current waiting transfer. If this isn't done, the device's
next transfer (that we would like to do a short read on) is going to
return an error -- for short transfer.
* For bulk transfer endpoints, restore the maximum transfer length each
time a transfer is done, or the first short transfer will make all the
rest that size or smaller.
* Remove impossibilities (malloc(M_WAITOK) == NULL, &var == NULL).
New device names are "{tty|cua}A$(card)$(port)[.init|.lock]"
Put a portname in the port structure if SI_DEBUG is defined to avoid
need to inspect minor number to construct name..
Constify some strings.
Remove duplicated DBG_ #defines.
uses predate the change in the pmap_enter() interface that replaced the
page's physical address by the address of its vm_page structure. The
PHYS_TO_VM_PAGE() was being used to compute the address of the same vm_page
structure that was being passed in.
is a no-op on little endian architectures, but fixes getting the MAC
address for some dc(4) cards on big endian architectures.
This is a RELENG_5 candidate.
Tested by: gallatin (powerpc), marius (sparc64)
First version of the patch written by: gallatin
1. Process p1 is currently being swapped in.
2. Process p2 calls linux_ptrace(PTRACE_GETFPXREGS, p1_pid, ...)
3. After acquiring a reference to FIRST_THREAD_IN_PROC(p1),
p2 blocks in faultin() while p1 finishes being swapped in.
This means p2 won't get back the lock on p1 until after p1's
threads are runnable.
4. After p1 is swapped in, the first thread in p1 exits.
5. p2 now uses its dangling reference to p1's first thread.
after loading such a kernel, "module_path" will be set to
an insane value. Fixed example by providing an equivalent
setting. For the record, when automatically loading a
kernel (commands "boot" and "boot-conf"), the following is
tried, in this order:
path=/boot/${kernel} file=${bootfile}
path=/boot/${kernel} file=${kernel}
path=${kernel} file=${bootfile}
path=${kernel} file=${kernel}
path=${module_path} file=${kernel}
MP machines (hopefully). CPU timers are OK on UP machines but we
don't keep the timers in sync on MP machines so if the CPU's timer
is chosen as the primary timecounter it's possible for time to
not be monotonically increasing because different CPU's counters
may be used at different times. But the CPU's counters are otherwise
one of the higher quality counters available. So, on UP machines
we'll use a relatively high quality value but on MP machines we'll
use a quality that should prevent the CPU's counters from being chosen.
Requested by: green (who did the first version of the patch)
Reviewed by: marius, green
MFC after: 1 week
the structure space had been obtained from malloc() its contents is
random garbage. The choice of value being set is part of a larger effort
to solve some timecounter issues on MP machines (while working on that
we noticed this problem).
Noticed by: marius
Reviewed by: marius, green
MFC after: 3 days
