Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
That way the radar errors aren't enabled prematurely.
A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.
Use the offset into the device tree from fdtp as the phandle instead
of using pointer into the device tree. This will make sure that the
phandle fits into a uint32_t type, even when compiled for 64bit.
Reviewed by: raj, nathanw, marcel
on the largest multi-write size.
From the submitter:
==
I looked further into the magic 88-byte threshold after which the bug
occurs. It turns out that figure included the 24-byte tx_desc, and up
to 64 bytes of beacon frame (header+data).
rum_write_multi doesn't seem happy with writing >64 bytes at a time to
the MAC register. If I break it up into separate calls (e.g. bytes
0-63, then bytes 64-65, written at the appropriate offset) I see the
proper beacon frames being transmitted now.
==
Submitted by: Steven Chamberlain <steven@pyro.eu.org>
MFC after: 3 days
for interfaces which were not configured for DHCP *unless* rc_force was set;
the correct logic is to run dhclient for those interfaces *only if* rc_force
is set.
Broken by: des@
Noticed by: everybody and his dog
Submitted by: rea@
PR: bin/161733
library," since complex.h, tgmath.h, and fenv.h are also part of the
math library. Replace the outdated sentence with some references to
the other parts.
Reading /dev/mem in 64 bit kernel crashes. This is because the page
used to call uiomove_fromphys() from memrw() does not have md.pv_list
initialized correctly.
The fix is to call pmap_page_init() on the page to initialize it.
separation rewrite changes. r196865 was committed to fix a scope
violation problem in the following test scenario:
box-1# ifconfig em0 inet6 2001:db8:1:: prefixlen 64 anycast
box-1# ifconfig em1 inet6 2001:db8:2::1 prefixlen 64
box-2# ifconfig re0 inet6 2001:db8:1::6 prefixlen 64
em0 and re0 are on the same link.
box-2# ping6 2001:db8:1::
PING6(56=40+8+8 bytes) 2001:db8:1::6 --> 2001:db8:1::
the ICMPv6 response should have a source address of em1, which
is 2001:db8:2::1, not the link-local address of em0.
That code is no longer necessary and breaks the IPv6-Ready logo
testing, so revert it now.
Reviewed by: hrs
MFC after: 3 days
and the caller requested other process' PID by passing non-NULL pidptr
argument, we will wait at most 100ms for the PID to show up in the file and if
it won't, we will store -1 in *pidptr.
From now on, pidfile_open() function never sets errno to EAGAIN on failure.
In collaboration with: des
MFC after: 1 week
long been superseded by the RFC3390 initial CWND sizing.
Also remove the remnants of TCP_METRICS_CWND which used the
TCP hostcache to set the initial CWND in a non-RFC compliant
way.
MFC after: 1 week
I focused so much on the 32-bits case where we have to cast SIZE_T_MAX
up in size, that I forgot about the 64-bits case, where off_t and size_t
are equal in size. Simply cast both numbers to uintmax_t, as we can
assume st_size is never negative.
Reported by: cperciva
- A race condition could happen if two threads were using RAS at the same time
as the code didn't reset RAS_END, the RAS code could believe we were not in
a RAS, when we were in fact.
- Using signed value logic to compare addresses wasn't such a good idea.
Many thanks to Ian to investigate on these issues.
Pointy hat to: cognet
PR: arm/161498
Submitted by: Ian Lepore <freebsd At damnhippie DOT dyndns dot org
MFC after: 1 week
page has been allocated, or we could end up using random values, and bad things
could happen.
PR: arm/161492
Submitted by: Ian Lepore <freebsd AT damnhippie dot dyndns DOT org>
MFC after: 1 week
This fixes a compiler warning at WARNS=6 when including the header files
as follows:
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip_var.h>
#include <netinet/udp.h>
#include <netinet/udp_var.h>
