in the log message for kern_sched.c 1.83 (which should have been
repo-copied to preserve history for this file), the (4BSD) scheduler
algorithm only works right if stathz is nearly 128 Hz. The old
commit lock said 64 Hz; the scheduler actually wants nearly 16 Hz
but there was a scale factor of 4 to give the requirement of 64 Hz,
and rev.1.83 changed the scale factor so that the requirement became
128 Hz. The change of the scale factor was incomplete in the SMP
case. Then scheduling ticks are provided by smp_ncpu CPUs, and the
scheduler cannot tell the difference between this and 1 CPU providing
scheduling ticks smp_ncpu times faster, so we need another scale
factor of smp_ncp or an algorithm change.
This quick fix uses the scale factor without even trying to optimize
the runtime divisions required for this as is done for the other
scale factor.
The main algorithmic problem is the clamp on the scheduling tick counts.
This was 295; it is now approximately 295 * smp_ncpu. When the limit
is reached, threads get free timeslices and scheduling becomes very
unfair to the threads that don't hit the limit. The limit can be
reached and maintained in the worst case if the load average is larger
than (limit / effective_stathz - 1) / 2 = 0.65 now (was just 0.08 with
2 CPUs before this change), so there are algorithmic problems even for
a load average of 1. Fortunately, the worst case isn't common enough
for the problem to be very noticeable (it is mainly for niced CPU hogs
competing with less nice CPU hogs).
thread being waken up. The thread waken up can run at a priority as
high as after tsleep().
- Replace selwakeup()s with selwakeuppri()s and pass appropriate
priorities.
- Add cv_broadcastpri() which raises the priority of the broadcast
threads. Used by selwakeuppri() if collision occurs.
Not objected in: -arch, -current
that msync(2) is its only caller.
- Migrate the parts of the old vm_map_clean() that examined the internals
of a vm object to a new function vm_object_sync() that is implemented in
vm_object.c. At the same, introduce the necessary vm object locking so
that vm_map_sync() and vm_object_sync() can be called without Giant.
Reviewed by: tegge
o Syscall return values do not fit in int on 64-bit architectures.
Change the type of retval in <arch>_syscall_exit() to long and
change the prototype of said function to return a long as well.
o Change the prototype of print_syscall_ret() to take a long for
the return address and change the format string accordingly.
o Replace the code sequence
tmp = malloc(X);
sprintf(tmp, format, ...);
with X by definition too small on 64-bit platforms by
asprintf(&tmp, format, ...);
With these changes the output makes sense again, although it does
mess up the tabulation on ia64. Go widescreen...
Not tested on: alpha, sparc64.
o Remove entries for 1510, 152x and 1535. These are supported, for some value
of supported, by the aic driver.
o Add notes about 1542-CP being plug and play, but it can still conflict with
other resources because all the resources it uses are set with the onboard
BIOS.
Comment out rather than totally remove the ipfilter pieces that we need
reconnected some day. This is now only ipnat as it is for configuring NAT.
ipfstat is meant for reporting statistics/filter lists. For /rescue it is
enough to configure lists but not view the installed ones.
signal handling mode, there is no chance to handle the signal, something
must be wrong in the library, just call kse_thr_interrupt to dump its core.
I have the code for a long time, but forgot to commit it.
are zx1 based machines and they don't particularly like it when we
poke at them with PC legacy code. The atkbd and psm devices were
disabled in the hints file so that one could enable them on machines
that support legacy devices, but that's not really something you can
expect from a first-time installer. This still leaves syscons (sc)
and the vga device, which were enabled by default and wrecking havoc
anyway. We could disable them by default like the atkbd and psm
devices, but there's really no point in pretending we're in a better
shape that way.
o pickup Giant in divert_packet to protect sbappendaddr since it
can be entered through MPSAFE callouts or through ip_input when
mpsafenet is 1
o add missing locking on output
o add locking to abort and shutdown
o add a ctlinput handler to invalidate held routing table references
on an ICMP redirect (may not be needed)
Supported by: FreeBSD Foundation
o add assertions in tcp_respond to validate inpcb locking assumptions
o use local variable instead of chasing pointers in tcp_respond
Supported by: FreeBSD Foundation
whether or not the isr needs to hold Giant when running; Giant-less
operation is also controlled by the setting of debug_mpsafenet
o mark all netisr's except NETISR_IP as needing Giant
o add a GIANT_REQUIRED assertion to the top of netisr's that need Giant
o pickup Giant (when debug_mpsafenet is 1) inside ip_input before
calling up with a packet
o change netisr handling so swi_net runs w/o Giant; instead we grab
Giant before invoking handlers based on whether the handler needs Giant
o change netisr handling so that netisr's that are marked MPSAFE may
have multiple instances active at a time
o add netisr statistics for packets dropped because the isr is inactive
Supported by: FreeBSD Foundation
in share/security in the trustedbsd_sebsd branch that are not present
in the main tree. Also, .include Makefile.inc from the parent directory
so that BINDIR is set right.
Pointed out by: bde
manpages: ahd(4), mly(4), vpo(4), rl(4), bktr(4), uscanner(4).
Tweak mlx(4) entry slightly.
Also trim USB hubs, ukbd(4) and ums(4). We can't seriously expect a
device list for these classes of devices that is inclusive enough to
be useful to anybody.
buildworld as src/etc/sendmail/freebsd.mc is missing. That example
was added 3 years ago, before the /etc/mail/ infrastructure was in
place for customized configurations. It is time to remove this example.
Noticed by: Robert Gray <bob@boulderlabs.com> in freebsd-stable
MFC after: 1 day
PALM_4 initialisation hack. I've not confirmed it myself, but
seeing as we already don't use it for the Sony Clie_41, let's drop
it from the Clie_40 also and see what happens.
(Question: What about the Clie_S360 and Clie_NX60 devices? Do we
need to drop Palm4 from those as well? Possibly, but I've not had
any reports about those so I don't know.)
PR: kern/56575
MFC after: 3 days
