| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's something strange going on with async events. They seem
to be be treated differently for different Fusion implementations.
Some will really tell you when it's okay to free the request that
started them. Some won't. Very disconcerting.
This is particularily bad when the chip (FC in this case) tells you
in the reply that it's not a continuation reply, which means you
can free the request that its associated with. However, if you do
that, I've found that additional async event replies come back for
that message context after you freed it. Very Bad Things Happen.
Put in a reply register debounce. Warn about out of range context
indices. Use more MPILIB defines where possible. Replace bzero with
memset. Add tons more KASSERTS. Do a *lot* more request free list
auditting and serial number usages. Get rid of the warning about
the short IOC Facts Reply. Go back to 16 bits of context index.
Do a lot more target state auditting as well. Make a tag out
of not only the ioindex but the request index as well and worry
less about keeping a full serial number.
|
|
|
|
| |
only and build the scc(4) module with MacIO attachment for powerpc.
|
| |
|
|
|
|
|
|
|
|
| |
a different register shift and is fed by a different clock than
we use for UltraSPARC hardware. To deal with this, the regshft and
rclk fields in the class structure are removed and bus frontends
now pass the right regshft and rclk to the probe function where
they're put in the BAS and passed in to subordinate drivers.
|
|
|
|
|
|
|
|
| |
this is used by some 3rd party applications when {e,f,g}cvt() are
not found. POSIX defines the xcvt() funtions but says they are
deprecated in favor or sprintf(). We'll import these functions
from OpenBSD and remove __gdtoa() from the exported interfaces
when libc version is bumped.
|
|
|
|
|
|
|
|
|
| |
vnode after vflush() has succeeded. This would cause a dangling vnode
panic at unmount time otherwise. Other filesystems may have this problem
via their VFS_VGET() routines.
Found by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
| |
to the vnode. Without a reference the vnode will never be vdestroy'd
and the memory will never be reclaimed.
Sponsored by: Isilon Systems, Inc.
|
|
|
|
| |
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
| |
the vnode is never recycled. It is bogus because the reference really
should be associated with the devfs dirent.
|
|
|
|
|
| |
Requested by: scottl
Tested by: scottl
|
|
|
|
| |
Pointy hat: marcel@
|
|
|
|
| |
it to be disabled if Safe Mode is selected.
|
|
|
|
| |
Requested by: scottl
|
|
|
|
|
|
| |
also used for the FHC bus.
Pointed out by: marius@
|
| |
|
|
|
|
|
| |
I'm piling on thise pointy hats on top of each other.
At least they nest..
|
|
|
|
|
| |
for over a month!
put {} around if clause with multiple statements
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--------------------
- 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).
All these fixes (including previous fixes) will be MFCed, later.
|
|
|
|
|
|
|
| |
to avoid possible device unregister race (impossible to reproduce, yet
possible).
- Extra sanity check to ensure proper parent channel is being selected.
- Reset parent channel once all of its children gone.
|
|
|
|
| |
MFC candidate.
|
|
|
|
|
|
| |
Discussed with: tegge
Tested by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
|
|
|
|
| |
called.
- vfs_getvfs has to return a reference to prevent the returned mountpoint
from changing identities.
- Release references acquired via vfs_getvfs.
Discussed with: tegge
Tested by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
|
| |
identity from changing. This is possible now that mounts are not freed.
Discussed with: tegge
Tested by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mount memory from being reclaimed. This resolves a number of race
conditions described in vfs_default.c and introduced with the
VFS_LOCK_GIANT macros.
- Let the mtx and lock remain valid after the mount structure has been
freed by using init and fini calls. Technically fini will never be
called but is included for completeness.
- Consistently use lockmgr directly rather than lockmgr to lock and
vfs_unbusy to unlock.
Discussed with: tegge
Tested by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
|
|
| |
and mnt_lock so that the mountpoint can be explicitly zeroed on
creation.
Discussed with: tegge
Tested by: kris
Sponsored by: Isilon Systems, Inc.
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
|
|
|
|
|
| |
requires Giant. It is set in bgetvp and cleared in brelvp.
- Create QUEUE_DIRTY_GIANT for dirty buffers that require giant.
- In the buf daemon, only grab giant when processing QUEUE_DIRTY_GIANT and
only if we think there are buffers in that queue.
Sponsored by: Isilon Systems, Inc.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
now really belongs in gdb, not binutils.. Plus, these don't resemble what
the new gdbserver looks like.
|
|
|
|
|
|
|
|
| |
failing, print a message when we fail for some reason as most callers do
not check the return value (e.g. 'cuz they're called from SYSINIT)
Reviewed by: scottl
MFC after: 1 week
|
|
|
|
| |
is configured.
|
|
|
|
|
|
|
|
|
|
|
|
| |
internal list of logfiles. So if writev(2) fails for potentially transient
errors like ENOSPC, syslogd requires a restart, even if the filesystem has
purged.
This change allows syslogd to ignore ENOSPC space errors, so that when the
filesystem is cleaned up, syslogd will automatically start logging again
without requiring the reset. This makes syslogd(8) a bit more reliable.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Avoid choosing an arena until it's certain that an arena is needed
for allocation.
* Convert division/multiplication to bitshifting where possible.
* Avoid accessing TLS variables in single-threaded code.
* Reduce the amount of pointer dereferencing.
* Move lock acquisition in critical paths to only protect the the code
that requires synchronization, and completely remove locking where
possible.
|
|
|
|
|
|
|
|
|
| |
uses them.
Now, we have res_nupdate and res_nmkupdate as well, but they are
still based on our old resolver for binary backward compatibility.
So, they don't provide new features such as TSIG support.
Reported by: pointyhat via kris
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
MFC after: 3 days
|
| |
|
|
|
|
|
|
| |
that 'unsigned char *' argument is 4 byte aligned.
MFC after: 3 days
|
|
|
|
|
| |
saying that scc(4) should be configured into the kernel. This
helps people to migrate away from puc(4) for these devices.
|
| |
|
|
|
|
|
|
| |
o Add the scc(4) manpage to the build.
o Update the uart(4) manpage to account for scc(4).
o Update the uart(4) module build to include support for scc(4).
|
| |
|
|
|
|
|
|
|
|
|
| |
controllers typically have multiple channels and support a number
of serial communications protocols. The scc(4) driver is itself
an umbrella driver that delegates the control over each channel
and mode to a subordinate driver (like uart(4)).
The scc(4) driver supports the Siemens SAB 82532 and the Zilog
Z8530 and replaces puc(4) for these devices.
|
|
|
|
|
| |
are related to internals, not user-visible state.
o Add a typedef for serdev_intr_t and protect it with !LOCORE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case panic on sparc64.
The problem is in MD5(9) implementation. The Encode() function takes
'unsigned char *output' as its first argument, which is then assigned to
'u_int32_t *op'. If the 'output' argument is not 4 byte aligned (and in
geli(8) case it is not), sparc64 machine will panic.
I don't know how to fix MD5(9) in a clean way, so I'm implementing a
work-around in geli(8).
Reported by: brueffer
MFC after: 3 days
|
|
|
|
| |
subdisks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
to post January 26 systems where gensnmptree(1) code was already fixed,
there was a timeframe between February 14 and February 27 when
usr.sbin/bsnmpd/ including gensnmptree was disconnected from build, so
if you upgraded in this timeframe, you ended up with the 700014 system
but still with a buggy gensnmptree binary. This also means not being
able to buildworld now.
Reported by: jhb
Attention: harti, keramida
|