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.
order to make every operation of the partition editor fully revertable.
Under *no circumstances* will it any longer touch the disks until the user
presses Finish and confirms it.
MFC after: 3 days
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
inpcb object.
Skip the TCP_SIGNATURE check in that case as it is consistent with the
output path (no TCP_SIGNATURE for outcoming packets in TIMEWAIT state)
and also because for TIMEWAIT state the verify may be less effective.
Sponsored by: Sandvine Incorporated
Reported by: rwatson
No objections by: rwatson
MFC after: 3 days
itself, which sparc64 hardware doesn't support. One way to solve this
would be to directly call sched_preempt() instead of issuing a self-IPI.
However, quoting jhb@:
"On the other hand, you can probably just skip the IPI entirely if we are
going to send it to the current CPU. Presumably, once this routine
finishes, the current CPU will exit softlock (or will do so "soon") and
will then pick the next thread to run based on the adjustments made in
this routine, so there's no need to IPI the CPU running this routine
anyway. I think this is the better solution. Right now what is probably
happening on other platforms is as soon as this routine finishes the CPU
processes its self-IPI and causes mi_switch() which will just switch back
to the softclock thread it is already running."
- With r226054 and the the above change in place, sparc64 now no longer is
incompatible with ULE and vice versa. However, powerpc/E500 still is.
Submitted by: jhb
Reviewed by: jeff
and pc_pmap for SMP. This is key to allowing adding support for SCHED_ULE.
Thanks go to Peter Jeremy for additional testing.
- Add support for SCHED_ULE to cpu_switch().
Committed from: 201110DevSummit
valid - we don't allow for setting it on a file, for example - but it's
not something we should assert on.
For STABLE kernel, it changes nothing, because it's not compiled with
INVARIANTS. If it was, it would fix crashes. It also fixes an assert
in libc encountered with NFSv4 without nfsuserd(8) running.
Submitted by: Yuri Pankov (earlier version)
MFC after: 1 month
determine if a loopback route should be installed for an interface
IPv6 address. Another condition is the address must not belong to a
looopback interface.
Reviewed by: hrs
MFC after: 3 days
existing phys_avail[] table. If a hw.physmem setting causes a memory
domain to not be present in phys_avail[], the SRAT table will now be
ignored rather than triggering a panic when a CPU in the missing domain
tries to allocate a page.
MFC after: 1 week
