rather than usually returning 1 but in a few instances using a sysexits(3)
return value.
2. Remove a few unused variables from libfetch.
PR: docs/122470 (1, only)
Reviewed by: des
> Description of fields to fill in above: 76 columns --|
> PR: If a GNATS PR is affected by the change.
> Submitted by: If someone else sent in the change.
> Reviewed by: If someone else reviewed your modification.
> Approved by: If you needed approval for this commit.
> Obtained from: If the change is from a third party.
> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email.
> Security: Vulnerability reference (one per line) or description.
> Empty fields above will be automatically removed.
M usr.bin/fetch/fetch.c
M lib/libfetch/fetch.c
newline when it fails to obtain an address via DHCP. This made the next
rc script begin its output on the same line.
PR: conf
Submitted by: Bruce Cran <bruce at cran dot org dot uk>
MFC after: 3 days
- split bootstrap code into more modular routines, which will also be used for
the non-booting cores
- clean up registers usage
- improve comments to better reflect reality
- eliminate dead or redundant code
- other minor fixes
This refactoring is a preliminary step before importing dual-core (MPC8572)
support.
Obtained from: Freescale, Semihalf
had been the only flag with random usage patterns.
Switch inc_flags to be used as a real bit field by using
INC_ISIPV6 with bitops to check for the 'isipv6' condition.
While here fix a place or two where in case of v4 inc_flags
were not properly initialized before.[1]
Found by: rwatson during review [1]
Discussed with: rwatson
Reviewed by: rwatson
MFC after: 4 weeks
command whenever Tx completion interrupt is raised. The Tx poll
bit is cleared when all packets waiting to be transferred have been
processed. This means the second Tx poll command can be silently
ignored as the Tx poll bit could be still active while processing
of previous Tx poll command is in progress.
To address the issue re(4) used to invoke the Tx poll command in Tx
completion handler whenever it detects there are pending packets in
TxQ. However that still does not seem to completely eliminate
watchdog timeouts seen on RealTek PCIe controllers. To fix the
issue kick Tx poll command only after Tx completion interrupt is
raised as this would indicate Tx is now idle state such that it can
accept new Tx poll command again. While here apply this workaround
for PCIe based controllers as other controllers does not seem to
have this limitation.
Tested by: Victor Balada Diaz < victor <> bsdes DOT net >
out of sleep mode prior to accessing to PHY. This should fix device
attach failure seen on these controllers. Also enable the sleep
mode when device is put into sleep state.
PR: kern/123123, kern/123053
2. Ensure all &arch entities end with ';' (no effect on output).
3. Ensure all &arch lists for drivers/features are comma-separated.
PR: docs/127840 (item 2 only)
MFC after: 1 week
port.
2. Increase the known working maximum memory configuration from
8gb to 32gb.
PR: docs/102148 (1)
Submitted by: Mike Meyer <mwm@mired.org> (1 - partially)
Reviewed by: hrs
Approved by: re (hrs)
MFC after: 1 minute
* Remove trailing whitespace (added in r186162)
* Reduce indentation by rephrasing test
Submitted by: Christopher Mallon (christoph dot mallon at gmx dot de)
- threadA runs vfs_rel(mp1)
- threadB does unmount the mp1 fs, sets MNTK_UNMOUNT and drop MNT_ILOCK()
- threadA runs vfs_busy(mp1) and, as long as, MNTK_UNMOUNT is set, sleeps
waiting for threadB to complete the unmount
- threadB, in vfs_mount_destroy(), finds mnt_lock > 0 and sleeps waiting
for the refcount to expire.
Fix the deadlock by adding a flag called MNTK_REFEXPIRE which signals the
unmounter is waiting for mnt_ref to expire.
The vfs_busy contenders got awake, fails, and if they retry the
MNTK_REFEXPIRE won't allow them to sleep again.
2) Simplify significantly the code of vfs_mount_destroy() trimming
unnecessary codes:
- as long as any reference exited, it is no-more possible to have
write-op (primarty and secondary) in progress.
- it is no needed to drop and reacquire the mount lock.
- filling the structures with dummy values is unuseful as long as
it is going to be freed.
Tested by: pho, Andrea Barberio <insomniac at slackware dot it>
Discussed with: kib
anything other than 0. Make it so. This fixes
"panic: VOP_STRATEGY failed bp=0xc320dd90 vp=0xc3b9f648",
encountered when writing to an orphaned filesystem. Reason
for the panic was the following assert:
KASSERT(i == 0, ("VOP_STRATEGY failed bp=%p vp=%p", bp, bp->b_vp));
at vfs_bio:bufstrategy().
Reviewed by: scottl, phk
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
result in panic:
mdconfig -af blah.img -o force
mount /dev/md0 /mnt
mdconfig -du 0
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
o Add support for compiling elf64 for this file (the rest of the changes are
coming later)
o Fill in some misssing relocation types. We need to support these in
elf_machdep.c's relocation routines eventually, but that's future work
too.
the device, which means refcount on periph drivers never drops,
which means cam_sim_free() never returns, which results in umass
sleeping there ad infinitum.
Submitted by: pjd
Reviewed by: scottl, pjd
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
unregistration, and execution:
- Add some brackets for clarity and trim a bit of vertical whitespace.
- Remove comments that may not contribute to clarity, such as "Lock"
before acquiring a lock and "Get memory" before allocating memory.
- During hook registration, don't drop pfil_list_lock between checking
for a duplicate and registering the hook, as this leaves a race
condition by failing to enforce the "no duplicate hooks" invariant.
- Don't lock the hook during registration, since it's not yet in use.
- Document assumption that hooks will be quiesced before being
unregistered.
- Don't write-lock hooks during removal because they are assumed
quiesced.
- Rename "done" label to "locked_error" to be clear that it's an error
path on the way out of hook execution.
MFC after: pretty soon
does - in DragonFly, it's cam_sim_release() what actually frees the
SIM; cam_sim_free does nothing more than calling cam_sim_release().
Here, we drain in cam_sim_free, waiting for refcount to drop to zero.
We cannot do the same think DragonFly does, because after cam_sim_free
returns, client would destroy the sim->mtx, and CAM would trip over
an initialized mutex.
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
to actually use it would panic on mtx operation, as dead_sim doesn't
have a proper mutex. Even if it had a properly initialized mutex,
it wouldn't have properly locked and owned one.
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
