ppp_profile variable can now contain multiple profiles.
Overrides for ppp mode and nat can go into ppp_$profile_mode
and ppp_$profile_nat variables respectively. If those are
not specified, defaults from ppp_mode and ppp_nat are used.
Submitted by: Yuri Kurenkov < y dot kurenkov at init dot ru >
Reviewed by: mtm
MFC after: 1 week
on multiple different audit pipes. The old method used cv_signal()
which would result in only one thread being woken up after we
appended a record to it's queue. This resulted in un-timely wake-ups
when processing audit records real-time.
- Assign PSOCK priority to threads that have been sleeping on a read(2).
This is the same priority threads are woken up with when they select(2)
or poll(2). This yields fairness between various forms of sleep on
the audit pipes.
Obtained from: TrustedBSD Project
Discussed with: rwatson
MFC after: 1 week
This fixes the process portion of the bpf(4) stats if the peer forks
into the background after it's opened the descriptor. This bug
results in the following behavior for netstat -B:
# netstat -B
Pid Netif Flags Recv Drop Match Sblen Hblen Command
netstat: kern.proc.pid failed: No such process
78023 em0 p--s-- 2237404 43119 2237404 13986 0 ??????
MFC after: 1 week
gets cleaned up upon receiving SIGINT. This un-breaks subsequent
executions of ipfwpcap and helps when debugging network/divert
issues like this:
ipfwpcap -r 6000 - | tcpdump -r -
MFC after: 1 week
lock experienced contention a number of processes would race to acquire
lock when it was released. This problem resulted in a lot of CPU
load as well as locks being picked up out of order.
Unfortunately, a regression snuck in which allowed multiple threads
to pickup the same lock when -k was not used. This could occur when
multiple processes open a file descriptor to inode X (one process
will be blocked) and the file is unlinked on unlock (thereby removing
the directory entry allow another process to create a new directory
entry for the same file name and lock it).
This changes restores the old algorithm of: wait for the lock, then
acquire lock when we want to unlink the file on exit (specifically
when -k is not used) and keeps the new algorithm for when -k is used,
which yields fairness and improved performance.
Also, update the man page to inform users that if lockf(1) is being
used to facilitate concurrency between a number of processes, it
is recommended that -k be used to reduce CPU load and yeld
fairness with regard to lock ordering.
Collaborated with: jdp
PR: bin/114341
PR: bin/116543
PR: bin/111101
MFC after: 1 week
success and zero pid from pidfile_read(). Return EAGAIN instead. Sleep
up to three times for 5 ms while waiting for pidfile to be written.
mount(8) does the kill(mountpid, SIGHUP). If mountd pidfile is truncated,
that would result in the SIGHUP delivered to the mount' process group
instead of the mountd.
Found and analyzed by: Peter Holm
Tested by: Peter Holm, kris
Reviewed by: pjd
MFC after: 1 week
- Add proper scanning support rather than letting the firmware grab the first
access point
- Overhaul state changes
- Use macros for locking and provide _locked() versions of some functions
- Increase debugging output
- Use a callout rather than the old watchdog interface
- Improve style, function names and defines
- Add WPA (TKIP) support
Based heavily on a patchset provided by Sam Leffler.
In particular, the previous code led to archives that had
non-empty bodies following directory entries. Not a fatal
problem, as bsdtar and GNU cpio are both happy to just skip
this bogus data, but it still shouldn't be there.
MFC after: 3 days
Return EOF immediately if an entry in a ZIP archive has no body.
In particular, the latter issue was causing bsdtar to emit spurious
warnings when extracting directory entries from ZIP archives.
MFC after: 3 days
VR_STICKHW register would result in unexpected results on these
hardwares. wpaul said the following for the issue.
The vr_attach() routine unconditionally does this for all supported
chips:
/*
* Windows may put the chip in suspend mode when it
* shuts down. Be sure to kick it in the head to wake it
* up again.
*/
VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1));
The problem is, the VR_STICKHW register is not valid on all Rhine
devices. The VT86C100A chip, which is present on the D-Link DFE-530TX
boards, doesn't support power management, and its register space is
only 128 bytes wide. The VR_STICKHW register offset falls outside this
range. This may go unnoticed in most scenarios, but if you happen to have
another PCI device in your system which is assigned the register
space immediately after that of the Rhine, the vr(4) driver will
incorrectly stomp it. In my case, the BIOS on my test board decided
to put the register space for my PRO/100 ethernet board right next
to the Rhine, and the Rhine driver ended up clobbering the IMR register
of the PRO/100 device. (Long story short: the board kept locking up on
boot. Took me the better part of the morning suss out why.)
The strictly correct thing to do would be to check the PCI config space
to make sure the device supports the power management capability and only
write to the VR_STICKHW register if it does.
Instead of inspecting chip revision numbers for the availability of
VR_STICKHW register, check the existence of power management capability
of the hardware as wpaul suggested.
Reported by: wpaul
Suggested by: wpaul
OK'ed by: jhb
1. The locking was changed to shared but roundrobin mode still updated a
pointer in the softc with the next tx interface to use. This will panic
under high load. Change this to an atomically incremented sequence number in
order to choose the tx port in round robin.
2. IFQ_HANDOFF will free the mbuf if the queue is full, this will then be freed
again by lagg_start() and panic. Reorganised the error handling and freeing
to fix this.
MFC after: 3 days
- Mention tzdata2007h update. An in advance &merged; is
added so that we don't have to change this again when
it is actually MFC'ed.
Approved by: re (bmah)
SAS-enabled cards. It also makes the driver MPSAFE, eliminating some
problems that resulted from CAM becoming MPSAFE. Many thanks to 3Ware/AMCC
for continuing to support FreeBSD.
Submitted by: Manjunath Ranganathaiah
Approved by: re
voltage of 0. This can result in a divide by zero trap. Add a guard
for this case. The value of lfcap is checked in acpi_battery_bif_valid()
just before this, so it is safe.
Reportd by: sam
Approved by: re
MFC after: 3 days
of directly from acpi0. Before it would attach prior to the sysresource
devices, causing the later allocation of its memory range to fail and
print a warning like "acpi0: reservation of fed00000, 1000 (3) failed".
Use an explicit define for our probe order base value of 10.
Help from: jhb
Tested by: Abdullah Ibn Hamad Al-Marri <almarrie / gmail.com>
MFC after: 3 days
Approved by: re
local rc.d scripts in the overall boot order was added.
Proper rc.d scripts are run by rc.subr in a subshell, whereas scripts that
end in .sh are sourced into rc's shell. The latter has potential to create
serious boot problems, and there is no reason that the same functionality
cannot be added by the user in the form of a proper rc.d script (as
opposed to being added by the user in the form of /etc/rc.early).
This script will be removed prior to the 8.0 branch.
Approved by: re (kensmith)
