| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
| |
required due to a straight integer write in which minor races are not
a problem.
|
|
|
|
|
|
| |
one other style nit in the file.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers in argv and envv in userland and use that together with
kern_execve() and exec_free_args() to implement freebsd32_execve()
without using the stackgap.
- Fix freebsd32_adjtime() to call adjtime() rather than utimes(). Still
uses stackgap for now.
- Use kern_setitimer(), kern_getitimer(), kern_select(), kern_utimes(),
kern_statfs(), kern_fstatfs(), kern_fhstatfs(), kern_stat(),
kern_fstat(), and kern_lstat().
Tested by: cokane (amd64)
Silence on: amd64, ia64
|
|
|
|
|
|
| |
the rest of the accept filter code currently lives.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers in argv and envv in userland and use that together with
kern_execve() and exec_free_args() to implement linux_execve() for the
amd64/linux32 ABI without using the stackgap.
- Implement linux_nanosleep() using the recently added kern_nanosleep().
- Use linux_emul_convpath() instead of linux_emul_find() in
exec_linux_imgact_try().
Tested by: cokane
Silence on: amd64
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
returning accept.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the semantics in that the returned filename to use is now a kernel
pointer rather than a user space pointer. This required changing the
arguments to the CHECKALT*() macros some and changing the various system
calls that used pathnames to use the kern_foo() functions that can accept
kernel space filename pointers instead of calling the system call
directly.
- Use kern_open(), kern_stat(), kern_lstat(), kern_fstat(), kern_access(),
kern_truncate(), kern_pathconf(), kern_execve(), kern_select(),
kern_setitimer(), kern_getitimer(), kern_statfs(), and kern_fstatfs().
Silence on: alpha@
|
|
|
|
|
|
|
| |
exec_copyin_args(), kern_execve(), and exec_free_args() rather than
execve() to eliminate stackgap use from Alpha's linux_execve().
Silence on: alpha@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like a valid range. We already do this in the memory case (although
the code there is somewhat different than the I/o case because we have
to deal with different kinds of memory). Since most laptops don't
have non-subtractive bridges, this wasn't seen in practice.
Evidentally the Compaq R3000 hits this problem with PC Cards.
Some minor style fixes while I'm here.
Submitted by: Jung-uk Kim
|
|
|
|
| |
Obtained from: NetBSD
|
|
|
|
|
|
| |
rev. 1.145 of sys/sparc64/sparc64/pmap.c.
Submitted by: alc
|
|
|
|
|
| |
MFC after: 1 week
Discussed with: scottl
|
|
|
|
| |
Spotted by: Taku YAMAMOTO <taku@tackymt.homeip.net>
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
mounted (is it Joliet, RockRidge, High Sierra) based on bootverbose.
Most file systems don't generate log messages based on details of the
file system superblock, and these log messages disrupt sysinstall output
during a new install from CD. We may want to explore exposing this
status information using nmount() at some point.
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
Note that this results in more kernel virtual memory being reserved for
temporary storage of the args. The args temporary space is allocated out
of exec_map (a submap of kernel_map). This will use roughly 4MB of KVM.
OK'ed by: dg
|
| |
|
|
|
|
|
|
|
|
| |
copy op to shift arguments on the stack instead of transfering each
argument one by one through a register. Probably doesn't affect overall
operation, but makes the code a little less grotty and easier to update
later if I choose to make the wrapper handle more args. Also add
comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so->so_options when solisten() will succeed, rather than setting it
conditionally based on there not being queued sockets in the completed
socket queue. Otherwise, if the protocol exposes new sockets via the
completed queue before solisten() completes, the listen() system call
will succeed, but the socket and protocol state will be out of sync.
For TCP, this didn't happen in practice, as the TCP code will panic if
a new connection comes in after the tcpcb has been transitioned to a
listening state but the socket doesn't have SO_ACCEPTCONN set.
This is historical behavior resulting from bitrot since 4.3BSD, in which
that line of code was associated with the conditional NULL'ing of the
connection queue pointers (one-time initialization to be performed
during the transition to a listening socket), which are now initialized
separately.
Discussed with: fenner, gnn
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
| |
driver. This used to be handled by cpufreq_drv_settings() but it's
useful to get the type/flags separately from getting the settings.
(For example, you don't have to pass an array of cf_setting just to find
the driver type.)
Use this new method in our in-tree drivers to detect reliably if acpi_perf
is present and owns the hardware. This simplifies logic in drivers as well
as fixing a bug introduced in my last commit where too many drivers attached.
|
|
|
|
|
|
|
| |
function that is called from tcp_input(), so they oughta be passed on
the stack instead of stuck in the tcpcb.
Submitted by: Mohan Srinivasan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are equal to PCCARD_TPCE_FS_MEMSPACE_NONE, memspace will be zero, so
testing for this case inside of the if statement results in dead code.
We'd fail to set a value to zero that's already zero (since it is
initialized to 0 indirectly) with this code being there. Well, except
in the very rare case that we have a card that has a defualt entry
that includes a memory space followed by one that has no memory space
(these are extremely rare, I don't recall ever having seen one :-).
Fix this by setting num_memspace to 0 in a more appropriate place.
Submitted by: Coverity Prevent analysis tool
|
|
|
|
| |
now amd64 versions of CLI and 3DM2 available.
|
|
|
|
|
|
| |
we want to return EOPNOTSUPP for FFixedHW no matter what the address.
Submitted by: Bruno Ducrot
|
|
|
|
|
|
|
|
| |
than the generic ne-2000 string. This should have no effect on the
actual support of the parts, just reporting what the part was.
Also, rename a few functins and symbols to reflect a more generic
part support that grew out of the early specific support.
|
|
|
|
|
|
| |
detach it, but instead let the geom wither away.
Bump copyright year.
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
soref() to also covering the update of so_state. While no other user
threads can update the socket state here as it's not yet hooked up to
the file descriptor array yet, the protocol could also frob the
socket state here, leading to a lost update to the so_state field.
No reported instances of this bug (as yet).
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
| |
connection status before inserting the new socket into the listen
socket's accept queue, or there might be a race in which another thread
wakes up when the accept lock is released, and sees the socket before its
state is set correctly. The wakeup still occurs after the accept lock is
released. There have been no diagnoses of this bug in real-world systems
(as yet).
MFC after: 3 days
|
|
|
|
|
| |
Reminded by: ru
MFC after: 2 weeks
|
| |
|
| |
|
|
|
|
| |
MFC after: 2 weeks
|
|
|
|
|
|
| |
in "pfctl -vvsI" output when pf was statically linked to kernel.
Discussed with: mlaier
|
|
|
|
| |
ENOMEM. The manpage and ichss(4) are correct.
|
|
|
|
|
|
|
|
|
| |
or just offering info. In the former case, we don't probe/attach to allow
the ACPI driver precedence. A refinement of this would be to actually
use the info provided by acpi_perf(4) to get the real CPU clock rates
instead of estimating them but since all systems that support both
acpi_perf(4) and ichss(4) export the control registers to acpi_perf(4),
it can just handle the registers on its own.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loaded, the tick interrupt enabled and a handler that resets the tick
counter on every tick interrupt. While this isn't documented this can
cause DELAY() to wait for a value the tick counter will not reach when
used in early boot, i.e. before cpu_initclocks() is called, depending
on when in the cycle DELAY() is called, the delay value and the value
the tick compare register is set to. The excessive use of DELAY() in
uart(4) when probing Sun keyboards seems to always manage to trigger
this, resulting in a hang during boot.
Disable the tick interrupt in tick_init(), which is called early in
sparc64_init(), until the interrupt is enabled again in tick_start(),
called by cpu_initclocks(), with our own handler. This fixes the hang
during probing Sun keyboards on AXi boards and Ultra 10, with other
machines like Ultra 5 probably being affected but not tested.
Additional testing by: Matthias Muthmann
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
| |
aic7xxx.c:
Allow print_reg() to be called with a NULL column.
aic79xx.c:
Correct new usage of SCB_GET_TAG().
aic7xxx.c:
Fix stray ahd that snuck in here.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement from some files, so re-add it for the moment, until the
related legalese is sorted out. This change affects:
sys/kern/kern_mbuf.c
sys/vm/memguard.c
sys/vm/memguard.h
sys/vm/uma.h
sys/vm/uma_core.c
sys/vm/uma_dbg.c
sys/vm/uma_dbg.h
sys/vm/uma_int.h
|
| |
|
|
|
|
|
|
|
| |
UMA_ZONE_REFCNT and UMA_ZONE_MALLOC zones, as the page(s) undoubtedly
came from kmem_map for those two. Previously it would set it back
to NULL for UMA_ZONE_REFCNT zones and although this was probably not
fatal, it added MORE code for no reason.
|
|
|
|
| |
called with the wrong pointer.)
|
|
|
|
|
|
|
|
|
|
| |
for now) exactly the same as KfAcquireSpinLock() and KfReleaseSpinLock().
I implemented the former as small routines in subr_ntoskrnl.c that just
turned around and invoked the latter. But I don't really need the wrapper
routines: I can just create an entries in the ntoskrnl func table that
map KeAcquireSpinLockRaiseToDpc() and KeReleaseSpinLock() to
KfAcquireSpinLock() and KfReleaseSpinLock() directly. This means
the stubs can go away.
|
|
|
|
|
|
|
|
|
|
|
| |
close holes in detecting busfrees that occur after a packetized target
transitions to a non-packetized phase. The most common case where this
occurs is when a target is externally reset so the controller believes
a packetzied negotiation agreement is still in effect. Unfortunately,
disabling this feature seems to cause problems for the 7901B. Re-enable
ehanced busfree detection for this part until I can get my hands on a
samble to figure out if the old workaround is necessary and, if so, how
to make it work correctly.
|
|
|
|
|
| |
to the hardware_scb->tag field, limit max lun reported to CAM to 63,
return after a panic to silence a warning.
|