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>
- Prevent possible unaligned access to struct whoent.
- Increase uptime column by one, to properly print hosts with an uptime
greater than 1000 days.
- Reduce code complexity by storing struct whod inside struct hs.
- Set WARNS to 6.
MFC after: 3 months
Third parties are encouraged to change the license on any files which have
a 4-clause license contributed to the NetBSD Foundation to a 2-clause
license. We would also encourage you to inform us about these files, so
that we can continue to track the many places in which NetBSD is used.
http://www.netbsd.org/about/redistribution.html#why2clause [1]
Requested by: joel@
