changed to use the statclock. Make sure we calculate the value
of a tick correctly in userland.
Noticed by: Kazuaki Oda <kaakun at highway dot ne dot jp>
it is actually needed. This makes clear in which subblocks the variables
are not needed and which can easier be split out.
Submitted by: Max Okumoto <okumoto@ucsd.edu>
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.
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
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.
architecture independent. Besides the fixed-width types in
the header, the offsets are now stored as 64-bit off_t (also
in big endian format).
Tested on: i386, amd64, sparc64, ia64
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
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
