It is built in the same module as IPv4 multicast forwarding, i.e. ip_mroute.ko,
if and only if IPv6 support is enabled for loadable modules.
Export IPv6 forwarding structs to userland netstat(1) via sysctl(9).
- Dont "return" in linux_clone() after we forked the new process in a case
of problems.
- Move the copyout of p2->p_pid outside the emul_lock coverage in
linux_clone().
- Cache the em->pdeath_signal in a local variable and move the copyout
out of the emul_lock coverage.
- Move the free() out of the emul_shared_lock coverage in a preparation
to switch emul_lock to non-sleepable lock (mutex).
Submitted by: rdivacky
an ICB. This shows up on card restarts, and usually for
2200-2300 cards. What happens is that we start up,
attempting to acquire a hard address. We end up instead
being an F-port topology, which reports out a loop id
of 0xff (or 0xffff for 2K Login f/w). Then, if we restart,
we end up telling the card to go off an acquire this loop
address, which the card then rejects. Bah.
Compilation fixes from Solaris port.
bad or illegal. This prevents matching on systems that
have a name that matches the query.
PR: conf/107560
Submitted by: Christian Laursen <cfsl at pil dot dk>
MFC after: 3 days
Approved by: imp (mentor)
I created and tested this with a custom FreeSBIE cd-image.
PR: i386/96452
Submitted by: Yuichiro Goto <y7goto at gmail dot com>
MFC after: 3 days
Approved by: imp (mentor)
inode's i_flag.
It's possible that after ufs_infactive() calls softdep_releasefile(),
i_nlink stays >0 for a considerable amount of time (> 60 seconds here).
During this period, any ffs allocation routines that alter di_blocks
must also account for the blocks in the filesystem's fs_pendingblocks
value.
This change fixes an eventual df/du discrepency that will happen as
the result of fs_pendingblocks being reduced to <0.
The only manifestation of this that people may recognise is the
following message on boot:
/somefs: update error: blocks -N files M
at which point the negative pending block count is adjusted to zero.
Reviewed by: tegge
MFC after: 3 weeks
freshly-loaded kernel module. To avoid various unload races, hide linker
files whose sysinit's are being run from userland so that they can't be
kldunloaded until after all the sysinit's have finished.
Tested by: gallatin
changes. This should ease the job of maintaining codebase since much
of the regression tests are done across os versions.
- bus_setup_intr() -> snd_setup_intr().
triggers a KASSERT) or local variables. In the case of kern_ndis, the
tsleep() actually used a common sleep address (curproc) making it
susceptible to a premature wakeup.
want an equivalent of DELAY(9) that sleeps instead of spins. It accepts
a wmesg and a timeout and is not interrupted by signals. It uses a private
wait channel that should never be woken up by wakeup(9) or wakeup_one(9).
Glanced at by: phk
Use bus_get_dma_tag() to obtain the parent DMA tag to make the drivers
a little bit more non-ia32/amd64 friendly.
There is no man page for bus_get_dma_tag, so this is modelled after
rev. 1.62 of src/sys/dev/sound/pci/es137x.c by marius.
Inspired by: commit by marius
attachment of new devices that arrive (and we notice them
via async Fibre Channel events). We've always had the
right thing (of sorts) happen when devices go away- this
is the corollary function that makes multipath failover
actually work.
MFC after: 2 weeks
rescan requests. The purpose of this is to allow a SIM
(or other entities) to request a bus rescan and have it
then fielded in a different (process) context from the
caller.
There are probably better ways to accomplish this, but
it's a very small change that helps solve a number of
problems.
Reviewed by: Justin, Ken and Scott.
MFC after: 2 weeks
early, we haven't set board type, so we can't correctly check for
some options. Fix this by splitting option setting/getting into
generic, pci and then later board specific, option setting/getting.
This was noticed when setting 'iid' (or 'hard loop id') didn't work
all of a sudden.
Noticed by: Mike Drangula (thanks!) via Jung-uk Kim (thanks!)
complete the boot and enter into sysinstall, and only then inserts
a CD into the CDROM drive and tries to select that as the install
media the first call to mount(2) generates EIO but the second call
to mount(2) will succeed. This was 100% reproducible on 6.2-RELEASE,
RELENG_6, and HEAD. If the user inserts the disc into the CDROM
while the machine is booting off the floppies the first call to mount(2)
succeeds with no problems. The problem was originally reported in
PR #56952 against 5.1-CURRENT so it's been there for a while now.
PR: bin/56952
MFC after: 2 weeks
This has no impact unless USE_BRK is defined (32-bit platforms), in
which case user allocations are allocated via mmap() if at all possible,
in order to avoid the possibility of unreclaimable chunks in the data
segment.
Fix an obscure bug in base_alloc() that could have allowed undefined
behavior if an application were to use sbrk() in conjunction with a
USE_BRK-enabled malloc.
