Check for this case and just return, so that the UCOM unit number zero is
not accidentially freed.
Submitted by: Danish FreeBSD user at EuroBSDcon 2011
MFC after: 3 days
This change fixes (theoretically) possible mbuf leak introduced in
r225586. Reorder code a bit and change return codes to be more specific
Reviewed by: glebius
Approved by: kib (mentor)
option is defined. This sysctl can be queried by feature_present(3).
Query for this feature in /sbin/atacontrol and /usr/sbin/burncd.
If these utilities detect that ATA_CAM is enabled, then these utilities
will error out. These utilities are compatible with the old ATA
driver, but are incomptible with the new ATA_CAM driver. By erroring out,
we give end-users an idea as to what remedies to use, and reduce the need for them
to file PR's. For atacontrol, camcontrol must be used instead,
and for burncd, alternative utilties from the ports collection must be used
such as sysutils/cdrtools.
In future, maybe someone can re-write burncd to work with ATA_CAM,
but at least for now, we give a somewhat useful error message to end users.
PR: 160979
Reviewed by: jh, Arnaud Lacombe <lacombar at gmail dot com>
Reported by: Joe Barbish <fbsd8 at a1poweruser dot com>
MFC after: 3 days
the unlikely event that sysctl_kmem_map_free() was performed on an
empty kmem map, it would incorrectly report the free space as zero.
Discussed with: avg
MFC after: 1 week
drivers that only ever attach to a particular MAC driver, i.e. inphy(4),
ruephy(4) and xlphy(4), to the directory where the respective MAC driver
lives and only compile it into the kernel when the latter is also there,
also removing it from miibus.ko and moving it into the module of the
respective MAC driver.
- While at it, rename exphy.c, which comes from NetBSD where the MAC driver
it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD
actually identifies itself as xlphy(4), and its function names accordingly
for consistency.
- Additionally while at it, fix some minor style issues like whitespace
in the register headers and add multi-inclusion protection to inphyreg.h.
remove explicit checks for BCM5716.
The BCM5709 and BCM5716 chips are virtually indistinguishable by
software except for the PCI device ID. The two chips differ in
that BCM5709 supports TCP/IP and iSCSI offload in Windows while
the BCM5716 doesn't.
While I'm here remove now unused definition of BCE_CHIP_NUM_5716
and BCE_CHIP_ID_5716_C0.
Reported by: sbruno
Reviewed by: davidch
Tested by: davidch
address if that interface does not support ARP. Otherwise the
system will generate error messages unnecessarily due to the missing
entry.
PR: kern/159602
Submitted by: pluknet
MFC after: 3 days
Zero any sense not transferred by the device as the SCSI specification
mandates that any untransferred data should be assumed to be zero.
Reviewed by: ken
address is being deleted. Only the last reference holder deletes the
loopback route. All other delete operations just clear the IFA_RTSELF
flag.
PR: kern/159601
Submitted by: pluknet
Reviewed by: discussed on net@
MFC after: 3 days
when reaching the zone limit of reassembly queue entries.
When the zone limit was reached not even the missing segment
that would complete the sequence space could be processed
preventing the TCP session forever from making any further
progress.
Solve this deadlock by using a temporary on-stack queue entry
for the missing segment followed by an immediate dequeue again
by delivering the contiguous sequence space to the socket.
Add logging under net.inet.tcp.log_debug for reassembly queue
issues.
Reviewed by: lsteward (previous version)
Tested by: Steven Hartland <killing-at-multiplay.co.uk>
MFC after: 3 days
raw IP sockets. It was deducted in ip_input() in preparation for
protocols interested only in the payload.
On raw sockets the IP header should be delivered as it at came in
from the network except for the byte order swaps in some fields.
This brings us in line with all other OS'es that provide raw
IP sockets.
Reported by: Matthew Cini Sarreo <mcins1-at-gmail.com>
MFC after: 3 days
It seems I was under the impression that a tab differs from a single
forward tabulation, namely that it blanks the underlying cells. This
seems not to be the case. They are identical.
This should fix applications like jove(1) that use tabs instead of
explicit cursor position setting.
Reported by: Brett Glass <brett lariat net>
MFC after: 3 days, after it's tested
As noted in kern/159780, printf() is not very jail-friendly, since it can't be easily monitored by jail management tools. This patch reports an error via log() instead, which, if nobody is watching the log file, still prints to the console.
Approved by: mentor (rwatson)
Submitted by: Eugene Grosbein <eugen@eg.sd.rdtc.ru>
MFC after: 5 days
* Add the interrupt bit in the configuration register
* Correctly set the counter register for the sampling overflow
interrupt. The interrupt is asserted when bit 31 is set.
So set the overflow value at 0x80000000 and subtract the
programmed value as appropriate.
heading "kernel panics with RPCSEC_GSS" appears to be caused by a
corrupted tailq list for the client structure. Looking at the code, calls
to the function svc_rpc_gss_forget_client() were done in an SMP unsafe
manner, with the svc_rpc_gss_lock only being acquired in the function
and not before it. As such, when multiple threads called
svc_rpc_gss_forget_client() concurrently, it could try and remove the
same client structure from the tailq lists multiple times.
The patch fixes this by moving the critical code into a separate
function called svc_rpc_gss_forget_client_locked(), which must be
called with the lock held. For the one case where the caller would
have no interest in the lock, svc_rpc_gss_forget_client() was retained,
but a loop was added to check that the client structure is still in
the tailq lists before removing it, to make it safe for multiple
concurrent calls.
Tested by: clinton.adams at gmail.com (earlier version)
Reviewed by: zkirsch
MFC after: 3 days
