Revision tags: vendor/ipfilter/3.4.16, vendor/ipfilter-sys/v3-4-16, vendor/acpica/20010125, vendor/sendmail/8.11.2, vendor/kerberosIV/1.0.5, vendor/acpica/20001215, vendor/gcc/cvs-20000711-1732, vendor/kerberosIV/1.0-tfutil, vendor/kerberosIV/1.0-kdc_reply, vendor/kerberosIV/1.0-extra, vendor/acpica/20001201, vendor/groff/1.16.1, vendor/openssh/2.3.0, vendor/acpica/20001115, vendor/tcsh/6.10, vendor/file/3.33, vendor/binutils/2.10.1, vendor/binutils/2.10.0, release/4.2.0, vendor/openssh/20001110, vendor/openssl/0.9.6, vendor/bind/8.2.3-aa-patch, vendor/file/3.32, vendor/tcsh/6.09.01-20001031, vendor/isc-dhcp/2.0pl5_v3_fixes, vendor/isc-dhcp/FBSD_ISC_DHCP_2_0_PL5_+_V3_FIXES, vendor/isc-dhcp/FBSD_ISC_DHCP_2_0_PL5, vendor/isc-dhcp/2.0pl5, vendor/bind/8.2.3.t6b, vendor/ipfilter/3.4.13, vendor/ipfilter-sys/v3-4-13, vendor/acpica/20001020, vendor/ipfilter/3.4.12, vendor/ipfilter-sys/v3-4-12, vendor/tzdata/tzdata2000g |
|
#
35e0e5b3 |
| 20-Oct-2000 |
John Baldwin <jhb@FreeBSD.org> |
Catch up to moving headers: - machine/ipl.h -> sys/ipl.h - machine/mutex.h -> sys/mutex.h
|
#
dc13e6df |
| 19-Oct-2000 |
John Baldwin <jhb@FreeBSD.org> |
Axe the idle_event eventhandler, and add a MD cpu_idle function used for things such as halting CPU's, idling CPU's, etc.
Discussed with: msmith
|
#
5d391f75 |
| 18-Oct-2000 |
Peter Wemm <peter@FreeBSD.org> |
EVENTHANDLER_INVOKE() takes two arguments.
|
#
86bc23af |
| 18-Oct-2000 |
John Baldwin <jhb@FreeBSD.org> |
Don't needlessly pass the diagnostic counter to the idle_event event handlers.
|
#
3650b375 |
| 17-Oct-2000 |
John Baldwin <jhb@FreeBSD.org> |
- Wrap the sanity checks for staying in the idle loop for absurdly long amounts of time in #ifdef DIAGNOSTIC - Call vm_page_zero_idle() during the idle loop.
|
Revision tags: vendor/gperf/2.7.2, vendor/ncurses/5.1-20001009 |
|
#
1931cf94 |
| 05-Oct-2000 |
John Baldwin <jhb@FreeBSD.org> |
- Heavyweight interrupt threads on the alpha for device I/O interrupts. - Make softinterrupts (SWI's) almost completely MI, and divorce them completely from the x86 hardware interrupt code. - The
- Heavyweight interrupt threads on the alpha for device I/O interrupts. - Make softinterrupts (SWI's) almost completely MI, and divorce them completely from the x86 hardware interrupt code. - The ihandlers array is now gone. Instead, there is a MI shandlers array that just contains SWI handlers. - Most of the former machine/ipl.h files have moved to a new sys/ipl.h. - Stub out all the spl*() functions on all architectures.
Submitted by: dfr
show more ...
|
Revision tags: vendor/misc-GNU/cvs/1.11, vendor/sendmail/8.11.1, release/4.1.1_cvs |
|
#
bdf3d8b9 |
| 22-Sep-2000 |
Mike Smith <msmith@FreeBSD.org> |
Create an event (idle_event) which is invoked every time around the idle loop. Machine-dependant code can elect to eg. take power-saving actions when this event is invoked.
|
#
4cc6117e |
| 15-Sep-2000 |
John Baldwin <jhb@FreeBSD.org> |
Remove some commented out cruft.
|
#
7ab37af1 |
| 15-Sep-2000 |
John Baldwin <jhb@FreeBSD.org> |
- Add a new process flag P_NOLOAD that marks a process that should be ignored during load average calcuations. - Set this flag for the idle processes and the softinterrupt process.
|
#
f6a0af80 |
| 15-Sep-2000 |
John Baldwin <jhb@FreeBSD.org> |
Idle processes are always runnable, so let them state at SRUN.
|
Revision tags: vendor/openssh/2.2.0-2000-09-09 |
|
#
0384fff8 |
| 07-Sep-2000 |
Jason Evans <jasone@FreeBSD.org> |
Major update to the way synchronization is done in the kernel. Highlights include:
* Mutual exclusion is used instead of spl*(). See mutex(9). (Note: The alpha port is still in transition and c
Major update to the way synchronization is done in the kernel. Highlights include:
* Mutual exclusion is used instead of spl*(). See mutex(9). (Note: The alpha port is still in transition and currently uses both.)
* Per-CPU idle processes.
* Interrupts are run in their own separate kernel threads and can be preempted (i386 only).
Partially contributed by: BSDi (BSD/OS) Submissions by (at least): cp, dfr, dillon, grog, jake, jhb, sheldonh
show more ...
|