Back out the fan control changes that were merged in revision 1.2.2.5.
The necessary changes to the driver haven't been merged yet, which won't
happen before 6.1-RELEASE.
MFC 1.75: Fix a problem introduced by previous change, which causes
a seg-fault if the user specifies a keyword which is implemented as
an alias to some other keyword.
Submitted by: Kostik Belousov
Approved by: re (scottl)
Retire NETSMBCRYPTO as a kernel option and make its functionality
enabled by default in NETSMB and smbfs.ko.
With the most of modern SMB providers requiring encryption by
default, there is little sense left in keeping the crypto part
of NETSMB optional at the build time.
This will also return smbfs.ko to its former properties users
are rather accustomed to.
Convert the SYNOPSIS section to look like the ones used in other driver
manpages, mention module support.
Also add the crypto and cryptodev devices as the drivers are kind of useless
without them.
Convert the SYNOPSIS section to look like the ones used in other driver
manpages. Don't mention the include file, it's not important for the
operation of this driver.
MFC 1.73->1.74: Fix the case where the user specifies an alternate
heading for some output-format keyword, and the keyword they picked
is an alias to some other keyword.
andre [Tue, 4 Apr 2006 20:07:23 +0000 (20:07 +0000)]
MFC route.h rev. 1.65 and rtsock.c rev. 1.133:
- Fill in the correct rtm_index for RTM_ADD and RTM_CHANGE messages.
- Allow RTM_CHANGE to change a number of route flags as specified by
RTF_FMASK.
- The unused rtm_use field in struct rt_msghdr is redesignated as
rtm_fmask field to communicate route flag changes in RTM_CHANGE
messages from userland. The use count of a route was moved to
rtm_rmx a long time ago. For source code compatibility reasons
a define of rtm_use to rtm_fmask is provided.
Fix severe 8bit integer overflow during channel creation and
destruction, especially for vchans. It turns out that channel
numbering always depend on d->devcount counter (which keep
increasing), while PCMMKMINOR() truncate everything to 8bit length.
At some point the truncation cause the newly created character device
overlapped with the existed one, causing erratic overall system
behaviour and panic. Easily reproduce with something like:
(Luckily, only root can reproduce this)
while : ; do
sysctl hw.snd.pcm0.vchans=200
sysctl hw.snd.pcm0.vchans=100
done
- Enforce channel/chardev numbering within 8bit boundary. Return
E2BIG if necessary.
- Traverse d->channels SLIST and try to reclaim "free" counter during
channel creation. Don't rely on d->devcount at all.
- Determine open direction using 'flags', not 'mode'. This bug exist
since past 4 years.
- Don't allow opening the same device twice, be it in a same or
different direction.
- O_RDWR is allowed, provided that it is done by a single open (for
example by mixer(8)) and the underlying hardware support true
full-duplex operation.
- Seal the fate of long standing memory leak (4 years, 7 months)
during pcm_unregister(). While destroying cdevs, scan / detect
possible children and free its SLIST placeholder properly.
- Optimize channel allocation / numbering even further. Do brute
cyclic checking only if the channel numbering screwed.
- Mega vchan create/destroy cleanup:
o Implement pcm_setvchans() so everybody can use it freely instead
of implementing their own, be it through sysctl or channel auto
allocation.
o Increase vchan creation/destruction resiliency:
+ it's possible to increase/decrease total vchans even during
busy playback/recording. Busy channel will be left alone,
untouched. Abusive test sample:
# play whatever...
#
while : ; do
sysctl hw.snd.pcm0.vchans=1
sysctl hw.snd.pcm0.vchans=10
sysctl hw.snd.pcm0.vchans=100
sysctl hw.snd.pcm0.vchans=200
done
# Play something else, leave above loop running frantically.
+ Seal another 4 years old bug where it is possible to destroy
(virtual) channel even when its cdevs being referenced by other
process. The "First Come First Served" nature of dsp_clone() is
the main culprit of this issue, and usually manifest itself as
dangling channel <-> process association. Ensure that all of its
cdevs are free from being referenced before destroying it
(through ORPHAN_CDEVT() macross).
MFC (revision 1.37)
A pointer was checked for NULL after dereferencing it. The check is
not needed here, except there's a bug which results in detaching the
device twice.
Move the NULL pointer check to the beginning of the function and
convert it into a KASSERT.
CID: 483
Found with: Coverity Prevent(tm)
Approved by: re (scottl)
MFC (revision 1.63)
Don't set primary resume interrupt flag during channel initialization
since it can cause high interrupt rate (storm) and slowdown the entire
system.
Note: Please report back to me if this commit cause any abnormal
behaviour, especially during suspend / resume.
Reported/Submitted by: [1] Daan Vreeken [PA4DAN] <Danovitsch_at_vitsch dot net>
Reported/Confirmed by: [2] Angka H. K. <harikurniawan at gmail dot com>
MFC (revision 1.64)
Add device ID for nForce 410 MCP audio controller.
PR: kern/95257
Submitted by: cenix <cenixxx at gmail dot com>
- [1] Make the driver friendly towards kernel without PREEMPTION.
Use msleep(9) instead of simple unlock-check_variable-lock
mechanisme since the later not really effective in non-preemptible
kernel (especially during codec detection routine).
- Free most driver resources in a sane manner to avoid possible
double free and panics especially during device detach and codec
detection failure.
cel [Tue, 4 Apr 2006 15:29:51 +0000 (15:29 +0000)]
rick says:
The following bug was just identified in OpenBSD and it looks like the same
bug exists in the other BSDen NFS servers.
A Linux client (don't know which version, but you can look at
http://bugzilla.kernel.org/show_bug.cgi?id=6256)
does a Setattr of mtime to the server's time, where the file is mode 0664 and
the client user has group access (ie. caller is not the file owner).
The BSD servers fail the Setattr with EPERM, since the VA_UTIMES_NULL flag
isn't set before doing the VOP_SETATTR.
It seems to me that this should be allowed, since it is allowed for a local
utimes(2). If so, the fix is to set VA_UTIMES_NULL for the
"set-time-to-server-time" cases of setting atime and/or mtime.
MFC of revision 1.140 to RELENG_6.
Submitted by: rick@snowhite.cis.uoguelph.ca
Reviewed by: cel
Approved by: re (scottl), silby
cel [Sun, 2 Apr 2006 04:11:23 +0000 (04:11 +0000)]
If an NFS server returns more than a few EJUKEBOX errors for a given RPC
request, the FreeBSD NFS client will quickly back off to a excessively
long wait (days, then weeks) before retrying the request.
Change the behavior of the FreeBSD NFS client to match the behavior of
the reference NFS client implementation (Solaris). This provides a fixed
delay of 10 seconds between each retry by default. A sysctl, called
nfs3_jukebox_delay, is now available to tune the delay. Unlike Solaris,
the sysctl value on FreeBSD is in seconds, rather than in HZ.
MFC revision 1.136 to RELENG_6
Sponsored by: Network Appliance, Incorporated
Reviewed by: rick
Approved by: re (kensmith), silby
Vararg functions have a different calling convention than regular
functions on amd64. Casting a varag function to a regular one to
match the function pointer declaration will hide the varargs from
the caller and we will end up with an incorrectly setup stack.
Entirely remove the varargs from these functions and change the
functions to match the declaration of the function pointers.
Remove the now unnecessary casts.
Also change static struct ipprotosw[] to two independent
protosw/ip6protosw definitions to remove an unnecessary cast.
PR: amd64/95008
Submitted and tested by: Mats Palmgren
Reviewed by: rwatson
Approved by: re (mux)
Remove manual assignment of m_pkthdr from one mbuf to another in
ipsec_copypkt(), as this is already handled by the call to
M_MOVE_PKTHDR(), which also knows how to correctly handle MAC m_tags.
This corrects a panic when running with MAC and KAME IPSEC.
marius [Fri, 31 Mar 2006 23:48:12 +0000 (23:48 +0000)]
MFC: 1.32
- We only lock the local per-CPU page in the local dTLB, so accessing the
foreign per-CPU pages in cpu_ipi_send() in order to get the module IDs
of the other CPUs can cause a page fault. If this happens when doing a
TLB shootdown while dealing with another page fault this causes a panic
due to the recursive page fault. As I don't spot other code that assumes
or requires that accessing foreign per-CPU pages must not page fault
solve this by adding a statically allocated (and therefore locked as
part of the kernel pages) array which establishes a FreeBSD CPU ID ->
module ID relation and use that in cpu_ipi_selected().
- Fix a potential race in cpu_ipi_send(); as we don't serialize the access
to cpu_ipi_selected() between MI and MD use (only MI-MI and MD-MD) we
might catch the NACK bit caused by sending another IPI. Solve this by
checking the NACK bit in the contents of the interrupt dispatch status
reg read while interrupts were still turned off instead of reading that
reg anew after interrupts were turned on again. This is also what the
CPU docs suggest to do.
- Add a workaround for the SpitFire erratum #54 bug (affecting interrupt
dispatch). While public info regarding what this CPU bug actually causes
is not available testing shows that with the workaround in place it's
less likely to get a "couldn't send ipi" panic, it doesn't solve these
panics entirely though.
marius [Fri, 31 Mar 2006 23:40:42 +0000 (23:40 +0000)]
MFC: 1.10
Add convenience macros for the bits in ASI_ESTATE_ERROR_EN_REG (used
for ECC handling) and the additional uses of the ASIs 0x77 and 0x7f
as well as their bits (used for a CPU bug workaround).
marius [Fri, 31 Mar 2006 23:38:29 +0000 (23:38 +0000)]
MFC: 1.21
- Move the check for too high HZ values from tick_init() to tick_start()
as we have to call tick_init() before cninit() in order to provide the
low-level console drivers with a working DELAY() which in turn means we
cannot use panic() in tick_init().
- s,to high, too high, in the panic string
kris [Fri, 31 Mar 2006 07:39:24 +0000 (07:39 +0000)]
MFC r1.89:
- LK_RETRY means nothing when passed to VOP_LOCK. Call vn_lock instead.
- Move the vn_lock of the dvp until after we've unbusied the filesystem
to avoid a LOR with the mount point lock.
- In the v_mountedhere while loop we acquire a new instance of giant each
time through without releasing the first. This would cause us to leak
Giant.
Sponsored by: Isilon Systems, Inc.
Approved by: re (scottl)
kris [Fri, 31 Mar 2006 07:13:09 +0000 (07:13 +0000)]
MFC r1.137:
Fix a bug in the NFS/TCP retransmission path.
The bug was that earlier, if a request was retransmitted,
we would do subsequent retransmits every 10 msecs.
This can cause data corruption under moderate loads by reordering
operations as seen by the client NFS attribute cache, and on the
server side when the retransmission occurs after the original request
has left the duplicate cache, since the operation will be committed
for a second time.
Further work on retransmission handling is needed (e.g. they are still
being done sent too often since they are scaled by HZ, and the size of
the dup cache is too small and easily overwhelmed on busy servers).
csjp [Thu, 30 Mar 2006 16:46:56 +0000 (16:46 +0000)]
MFC 1.144 tty_pty.c
Allow root to open jail PTYs from the host environment. This un-breaks using
utilities like watch(8) (or other programs which use snp(4)) to monitor
behavior within prisons from the host environment. This regression was
introduced when we changed the ioctl(SNPSTTY) to use a file descriptor
instead of a dev_t
cel [Wed, 29 Mar 2006 18:11:32 +0000 (18:11 +0000)]
Fix a bug in NFSv3 READDIRPLUS reply processing
The client's READDIRPLUS logic skips the attributes and
filehandle of the ".." entry. If the server doesn't send
attributes but does send a filehandle for "..", the
client's logic doesn't account for the extra "value
Fix a bug in NFSv3 READDIRPLUS reply processing
The client's READDIRPLUS logic skips the attributes and
filehandle of the ".." entry. If the server doesn't send
attributes but does send a filehandle for "..", the
client's logic doesn't account for the extra "value
follows" field that indicates whether the filehandle is
present, causing the remaining entries in the reply
to be ignored.
This is an MFC of 1.264 in the CURRENT branch.
Sponsored by: Network Appliance, Inc.
Reviewed by: rick, mohans
Approved by: re, silby
rwatson [Wed, 29 Mar 2006 12:42:43 +0000 (12:42 +0000)]
Merge ip_ip.c:1.43,1.44 from HEAD to RELENG_6:
When the kernel is compiled with options IPXIP, run the network stack
with Giant, as there is current unsafety in the IPX tunneled over IP
code. There have been no reports of trouble, but there probably would
be if anyone were running this code at high speed on SMP systems.
Include kernel.h to get NET_NEEDS_GIANT() definition, which for some
reason compiled fine here. I may be running with other include file
changes locally.
ceri [Tue, 28 Mar 2006 15:52:12 +0000 (15:52 +0000)]
MFC revision 1.71:
The rpc.pcnfsd server was in the base for a little over seven
minutes back in 1994. Change the example entry to point at the
port, as per the entries for uucpd et al.
delphij [Tue, 28 Mar 2006 06:25:11 +0000 (06:25 +0000)]
MFC (by scottl@):
>
> Don peril sensitive sunglasses and jack up the MAX_BPAGES limit to 8192
> on amd64. If you're going to stuff >4GB into your box, reserving 32MB for
> bonce pages amounts to a rounding error in the overall scheme of things.
>
> Revision Changes Path
> 1.72 +1 -1 src/sys/amd64/amd64/busdma_machdep.c
marius [Sat, 25 Mar 2006 12:13:21 +0000 (12:13 +0000)]
- Clear the interrupt source flags before processing the interrupt
events and turn off NIC interrupts while in the interrupt handler.
This fixes the device timeouts seen with the VMware LANCE.
- Relax the watchdog timer somewhat; don't enable it until the last
packet is enqueued and if there is a TX interrupt but there are
still outstanding ones reload the timer.
iedowse [Sat, 25 Mar 2006 04:46:52 +0000 (04:46 +0000)]
MFC 1.26: Correct the calculation of the report size and only look
at reports that have the specified kind, instead of assuming that
there is only one report of the right kind in the report descriptor.
projects / FreeBSD / FreeBSD.git / log