Author: tuexen
Date: Sat Aug 20 07:44:41 2016
New Revision: 304519
URL: https://svnweb.freebsd.org/changeset/base/304519
Log:
MFC r304292:
Use names for SCTP and UDPLite when reporting the input histogram.
MFC r304295:
Fix the output for scope statistics.
Modified:
stable/11/usr.bin/
Author: avg
Date: Sat Aug 20 09:12:01 2016
New Revision: 304520
URL: https://svnweb.freebsd.org/changeset/base/304520
Log:
fix bug introduced in r297521, set canmount=on doesn't mount filesystem
There are two cases where changing canmount should result in an action:
- canmount is set to o
Author: avg
Date: Sat Aug 20 09:13:14 2016
New Revision: 304521
URL: https://svnweb.freebsd.org/changeset/base/304521
Log:
JMicron JMB361 has only a single SATA port
Discussed with: mav
MFC after:3 days
Modified:
head/sys/dev/ahci/ahci_pci.c
Modified: head/sys/dev/ahci/ahci_
On 19/08/2016 8:59 AM, Ryan Stone wrote:
> Author: rstone
> Date: Thu Aug 18 22:59:00 2016
> New Revision: 304435
> URL: https://svnweb.freebsd.org/changeset/base/304435
>
> Log:
> Don't iterate over the ifnet addr list in ip_output()
>
> For almost every packet that is transmitted through
Author: tuexen
Date: Sat Aug 20 11:42:08 2016
New Revision: 304522
URL: https://svnweb.freebsd.org/changeset/base/304522
Log:
MFC r304519:
* Use names for SCTP and UDPLite when reporting the input histogram.
* Fix the output for scope statistics.
Approved by: re (kib)
Modified:
relen
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
On 18/08/16 23:59, Ryan Stone wrote:
Author: rstone
Date: Thu Aug 18
On 20/08/16 12:33, Bruce Simpson wrote:
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
I appreciate it probably looks
Author: kib
Date: Sat Aug 20 11:54:11 2016
New Revision: 304523
URL: https://svnweb.freebsd.org/changeset/base/304523
Log:
MFC r303794:
Create namespace for the symbols added during 12-CURRENT cycle.
Modified:
stable/11/lib/libc/Versions.def
Directory Properties:
stable/11/ (props chang
Author: kib
Date: Sat Aug 20 11:58:23 2016
New Revision: 304524
URL: https://svnweb.freebsd.org/changeset/base/304524
Log:
MFC r303795:
Add __cxa_thread_atexit(3) API implementation.
Added:
stable/11/lib/libc/stdlib/cxa_thread_atexit.c
- copied unchanged from r303795, head/lib/libc/std
Author: bdrewery
Date: Sat Aug 20 11:59:19 2016
New Revision: 304525
URL: https://svnweb.freebsd.org/changeset/base/304525
Log:
MFS r304512:
MFC r304288:
Garbage collect _umtx_lock(2)/_umtx_unlock(2) references removed in
r263318.
Approved by: re (gjb)
Modified:
re
Author: kib
Date: Sat Aug 20 12:23:27 2016
New Revision: 304526
URL: https://svnweb.freebsd.org/changeset/base/304526
Log:
MFC r303794:
Create namespace for the symbols added during 12-CURRENT cycle.
Modified:
stable/10/lib/libc/Versions.def
Directory Properties:
stable/10/ (props chang
Author: kib
Date: Sat Aug 20 12:26:44 2016
New Revision: 304527
URL: https://svnweb.freebsd.org/changeset/base/304527
Log:
MFC r303795:
Add __cxa_thread_atexit(3) API implementation.
Added:
stable/10/lib/libc/stdlib/cxa_thread_atexit.c
- copied unchanged from r303795, head/lib/libc/std
Author: dim
Date: Sat Aug 20 12:49:05 2016
New Revision: 304528
URL: https://svnweb.freebsd.org/changeset/base/304528
Log:
MFC r304319:
Pull in r262772 from upstream clang trunk (by Simon Pilgrim):
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a onl
Author: dim
Date: Sat Aug 20 13:29:58 2016
New Revision: 304529
URL: https://svnweb.freebsd.org/changeset/base/304529
Log:
MFC r304319:
Pull in r262772 from upstream clang trunk (by Simon Pilgrim):
[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE
btver1 is a SSSE3/SSE4a onl
Author: dim
Date: Sat Aug 20 14:04:51 2016
New Revision: 304530
URL: https://svnweb.freebsd.org/changeset/base/304530
Log:
Pull in r265122 from upstream llvm trunk (by James Molloy):
Fix for pr24346: arm asm label calculation error in sub
Some ARM instructions encode 32-bit immedia
On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote:
> Author: jhb
> Date: Sat Aug 20 00:49:29 2016
> New Revision: 304513
> URL: https://svnweb.freebsd.org/changeset/base/304513
>
> Log:
> Remove the ie(4) driver for Intel 82586 ISA Ethernet adapters.
>
> This driver only supports
On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote:
> On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote:
> > Author: jhb
> > Date: Fri Aug 19 22:27:14 2016
> > New Revision: 304506
> > URL: https://svnweb.freebsd.org/changeset/base/304506
> >
> > Log:
> > Remove the wl(4) driver and wlco
On Sat, Aug 20, 2016 at 7:48 AM, Bruce Simpson wrote:
> It is perfectly legal for broadcast packets to be addressed to the end of
> a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The
> classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the
> situation may be rea
On Sat, Aug 20, 2016 at 6:08 AM, Kubilay Kocak wrote:
> Hi Ryan,
>
> Could you elaborate on any of the potential performance implications of
> this?
>
As if r304437, skipping the call to in_broadcast() means that we avoid an
additional (potentially heavily contended) rlock acquire and release on
On 20/08/16 15:52, Ryan Stone wrote:
It is perfectly legal for broadcast packets to be addressed to the
end of a P2P or non-Ethernet link, which may not set M_BCAST or
M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access
(NBMA)) but the situation may be readily obse
On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote:
> - aha (ISA)
> - bt (ISA / EISA / PCI)
If anyone complains, tell them I'll ship them cards.
If they consider that a threat ... so be it :-)
(I *am* in the middle of a big decluttering, you know. I can find
them ...)
mcl
___
On Sat, Aug 20, 2016 at 11:01 AM, Bruce Simpson wrote:
> tun(4) on the other hand is a plain, PPP-like, IP tunnel.
>
Can you send a broadcast packet through an L3 tunnel? I thought that a L2
tunnel was required.
But this mbuf flag is not guaranteed to be set in all situations; e.g.
> where the
On 20/08/16 16:27, Ryan Stone wrote:
Can you send a broadcast packet through an L3 tunnel? I thought that a
L2 tunnel was required.
Yes. This is perfectly legal and necessary for forwarding of IPv4
broadcasts to work. (it is Internet Protocol after all, not
Infernal-ethernet-extension Protoc
On Sat, Aug 20, 2016 at 8:33 AM, John Baldwin wrote:
> On Friday, August 19, 2016 06:38:01 PM Warner Losh wrote:
>> On Fri, Aug 19, 2016 at 4:27 PM, John Baldwin wrote:
>> > Author: jhb
>> > Date: Fri Aug 19 22:27:14 2016
>> > New Revision: 304506
>> > URL: https://svnweb.freebsd.org/changeset/ba
Author: tsoome
Date: Sat Aug 20 16:23:19 2016
New Revision: 304532
URL: https://svnweb.freebsd.org/changeset/base/304532
Log:
loader is filling fixed length command_errbuf with sprintf() and is trusting
strings provided by user/config files. This update is replacing sprintf with
snprintf for
On Sat, Aug 20, 2016 at 8:51 AM, John Baldwin wrote:
> On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote:
>> Author: jhb
>> Date: Sat Aug 20 00:49:29 2016
>> New Revision: 304513
>> URL: https://svnweb.freebsd.org/changeset/base/304513
>>
>> Log:
>> Remove the ie(4) driver for Intel 82
On 20/08/16 16:42, Bruce Simpson wrote:
On 20/08/16 16:27, Ryan Stone wrote:
Can you send a broadcast packet through an L3 tunnel? I thought that a
L2 tunnel was required.
Yes. This is perfectly legal and necessary for forwarding of IPv4
broadcasts to work. (it is Internet Protocol after all,
Author: bapt
Date: Sat Aug 20 16:28:17 2016
New Revision: 304533
URL: https://svnweb.freebsd.org/changeset/base/304533
Log:
Import Dragonfly Mail agent snapshot from 2016-08-16
Modified:
vendor/dma/dist/VERSION
vendor/dma/dist/dma-mbox-create.c
vendor/dma/dist/dma.c
vendor/dma/dist/dma.
Author: bapt
Date: Sat Aug 20 16:29:08 2016
New Revision: 304534
URL: https://svnweb.freebsd.org/changeset/base/304534
Log:
tag import of Dragonfly Mail Agent 20160806
Added:
vendor/dma/20160806/
- copied from r304532, vendor/dma/dist/
Replaced:
vendor/dma/20160806/VERSION
- copie
On 20/08/16 17:27, Bruce Simpson wrote:
Alternatively, the L2 destination MAC may be rewritten for that specific
address, to avoid the destination being interpreted by routers in the
Metro Ethernet core.
s/routers/switches/ -- in some views of the world, they are the same :)
PBB is also known
Author: bapt
Date: Sat Aug 20 16:36:05 2016
New Revision: 304535
URL: https://svnweb.freebsd.org/changeset/base/304535
Log:
Import Dragonfly Mail Agent snapshort from 20160806 aka v0.11+
Most important change being:
dma - Fix security hole (#46)
Affecting DragonFly 4.6 and earlier, M
+ adrian@, who prompted me to look at UDP in the first place
I'm really not sure what my next step should be. I'm willing to revert
r304436, but I really don't want to revert r304437 because we've seen
crashes in the real world due to the missing locking. Unfortunately,
reverting r304436 would
On 20/08/16 17:36, Ryan Stone wrote:
+ adrian@, who prompted me to look at UDP in the first place
I'm really not sure what my next step should be. I'm willing to revert
r304436, but I really don't want to revert r304437 because we've seen
crashes in the real world due to the missing locking. U
On 20/08/16 17:49, Bruce Simpson wrote:
- Providing a mechanism for ip_input() to signal to udp_input() that the
packet was addressed to an L3 broadcast address would require
rototilling the pr_input interface, and I'd have to carefully ensure
that if anything might interpose itself between the t
On 8/16/2016 2:55 PM, Gleb Smirnoff wrote:
> Author: glebius
> Date: Tue Aug 16 21:55:34 2016
> New Revision: 304244
> URL: https://svnweb.freebsd.org/changeset/base/304244
>
> Log:
> We should not be allowing a timeout to reset when a drain is in progress on
> it (either async or sync drain).
On Sat, Aug 20, 2016 at 12:36:58PM -0400, Ryan Stone wrote:
> + adrian@, who prompted me to look at UDP in the first place
>
>
> I'm really not sure what my next step should be. I'm willing to revert
> r304436, but I really don't want to revert r304437 because we've seen
> crashes in the real w
On 20/08/16 18:30, Slawa Olhovchenkov wrote:
Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packets (with alien dst IP address) in L2 broadcas
packet.
That is exactly what the egress routers in chapter 6 of my PhD do, but
in a very controlled way -- by se
On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote:
> For host enought have [hidden] alias with broadcsts bits.
> Anyway, don't should relay on the L2 information, you can recive L3
> unicast addressed packets (with alien dst IP address) in L2 broadcas
> packet.
>
This is still handled co
On 20 August 2016 at 11:02, Ryan Stone wrote:
> On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote:
>>
>> For host enought have [hidden] alias with broadcsts bits.
>> Anyway, don't should relay on the L2 information, you can recive L3
>> unicast addressed packets (with alien dst IP address
On 20/08/16 19:09, Adrian Chadd wrote:
On 20 August 2016 at 11:02, Ryan Stone wrote:
On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote:
For host enought have [hidden] alias with broadcsts bits.
Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packe
[snip]
I ... may do some kind of anniversary related work to fix up wi support again.
Because - and this is pretty god damned hilarious - the same stack
features (no raw frames, 802.3 encapsulation, scan/join/etc done via
commands only, etc) that I need to 'fix' for wi are also required for
almos
On Sat, Aug 20, 2016 at 2:09 PM, Adrian Chadd wrote:
> Hi,
>
> So why not fix those paths?
>
>
>
> -adrian
>
Is there even a fix that can be done there? I wouldn't expect a
point-to-point protocol like PPP to have any need to explicitly signal that
a packet is a broadcast. Is the information e
On Sat, Aug 20, 2016 at 12:14 PM, Adrian Chadd wrote:
> [snip]
>
> I ... may do some kind of anniversary related work to fix up wi support again.
>
> Because - and this is pretty god damned hilarious - the same stack
> features (no raw frames, 802.3 encapsulation, scan/join/etc done via
> commands
On Sat, Aug 20, 2016 at 02:02:16PM -0400, Ryan Stone wrote:
> On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote:
>
> > For host enought have [hidden] alias with broadcsts bits.
> > Anyway, don't should relay on the L2 information, you can recive L3
> > unicast addressed packets (with ali
Author: rwatson
Date: Sat Aug 20 18:51:48 2016
New Revision: 304537
URL: https://svnweb.freebsd.org/changeset/base/304537
Log:
Audit additional vnode information in the implementation of the
ftruncate(2) system call. This was not required by the Common
Criteria, which needed only open-time
On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote:
> You also can recive this on ethernet too, IMHO, in case of /32.
> Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
> relaxed on this.
>
There is no broadcast address on a /32 network. Independent of my change,
we
On Sat, Aug 20, 2016 at 02:57:36PM -0400, Ryan Stone wrote:
> On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov wrote:
>
> > You also can recive this on ethernet too, IMHO, in case of /32.
> > Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
> > relaxed on this.
> >
>
> T
In message <1699917.hhfokya...@ralph.baldwin.cx>, John Baldwin writes:
> On Saturday, August 20, 2016 12:49:30 AM John Baldwin wrote:
> > Author: jhb
> > Date: Sat Aug 20 00:49:29 2016
> > New Revision: 304513
> > URL: https://svnweb.freebsd.org/changeset/base/304513
> >
> > Log:
> > Remove the
In message <20160820152406.ga8...@lonesome.com>, Mark Linimon writes:
> On Sat, Aug 20, 2016 at 07:51:55AM -0700, John Baldwin wrote:
> > - aha (ISA)
> > - bt (ISA / EISA / PCI)
>
> If anyone complains, tell them I'll ship them cards.
>
> If they consider that a threat ... so be it :-)
>
> (
On 20/08/16 19:57, Ryan Stone wrote:
On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov mailto:s...@zxy.spb.ru>> wrote:
You also can recive this on ethernet too, IMHO, in case of /32.
Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
relaxed on this.
There is
Author: tuexen
Date: Sat Aug 20 20:15:36 2016
New Revision: 304543
URL: https://svnweb.freebsd.org/changeset/base/304543
Log:
Unbreak sctp_connectx().
MFC after: 3 days
Modified:
head/sys/netinet/sctputil.c
Modified: head/sys/netinet/sctputil.c
==
Author: rwatson
Date: Sat Aug 20 20:28:08 2016
New Revision: 304544
URL: https://svnweb.freebsd.org/changeset/base/304544
Log:
Audit the accepted (or rejected) username argument to setlogin(2).
(NB: This was likely a mismerge from XNU in audit support, where the
text argument to setlogin(
On 20/08/16 21:05, Bruce Simpson wrote:
Unless I am missing something crucial here? As far as I can tell,
arpresolve() unconditionally resolves L2 next-hop to the value of
ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by
default for Ethernet ifnets: FF:FF:FF:FF:FF:FF.
Wou
On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote:
> On 20/08/16 21:05, Bruce Simpson wrote:
> > Unless I am missing something crucial here? As far as I can tell,
> > arpresolve() unconditionally resolves L2 next-hop to the value of
> > ifp->if_broadcastaddr. And that is always set to
Author: karels
Date: Sat Aug 20 20:46:53 2016
New Revision: 304545
URL: https://svnweb.freebsd.org/changeset/base/304545
Log:
Disable L2 caching for UDP over IPv6
The ip6_output routine is missing L2 cache invalication as done
in ip_output. Even with that code, some problems with UDP ove
Author: karels
Date: Sat Aug 20 20:56:36 2016
New Revision: 304546
URL: https://svnweb.freebsd.org/changeset/base/304546
Log:
MFC r304545: Disable L2 caching for UDP over IPv6
The ip6_output routine is missing L2 cache invalication as done
in ip_output. Even with that code, some problems
On 20/08/16 21:41, Slawa Olhovchenkov wrote:
On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote:
So, Ryan -- your original reading of how in_broadcast() behaves is
correct, modulo the all-ones bypassing it.
What purpose to analyse L2 header?
I was just checking for possible edge ca
On 20/08/16 22:17, Bruce Simpson wrote:
However, we still have to keep the FreeBSD-on-Ethernet ship sailing
smoothly. The intent of the original input path change is clearly for
performance, but perhaps slipping the M_BCAST tag in the stack is the
right way forward.
I would also suggest: we add
On Sat, Aug 20, 2016 at 10:17:27PM +0100, Bruce Simpson wrote:
> On 20/08/16 21:41, Slawa Olhovchenkov wrote:
> > On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote:
> >> So, Ryan -- your original reading of how in_broadcast() behaves is
> >> correct, modulo the all-ones bypassing it.
>
On 8/20/16, Konstantin Belousov wrote:
> Author: kib
> Date: Sat Aug 20 12:26:44 2016
> New Revision: 304527
> URL: https://svnweb.freebsd.org/changeset/base/304527
>
> Log:
> MFC r303795:
> Add __cxa_thread_atexit(3) API implementation.
>
> Added:
> stable/10/lib/libc/stdlib/cxa_thread_atex
Author: zec
Date: Sat Aug 20 22:12:26 2016
New Revision: 304548
URL: https://svnweb.freebsd.org/changeset/base/304548
Log:
Permit disabling net.inet.udp.require_l2_bcast in VIMAGE kernels.
The default value of the tunable introduced in r304436 couldn't be
effectively overrided on VIMAGE k
On 8/21/16, Oliver Pinter wrote:
> On 8/20/16, Konstantin Belousov wrote:
>> Author: kib
>> Date: Sat Aug 20 12:26:44 2016
>> New Revision: 304527
>> URL: https://svnweb.freebsd.org/changeset/base/304527
>>
>> Log:
>> MFC r303795:
>> Add __cxa_thread_atexit(3) API implementation.
>>
>> Added:
On 8/21/16, Oliver Pinter wrote:
> On 8/21/16, Oliver Pinter wrote:
>> On 8/20/16, Konstantin Belousov wrote:
>>> Author: kib
>>> Date: Sat Aug 20 12:26:44 2016
>>> New Revision: 304527
>>> URL: https://svnweb.freebsd.org/changeset/base/304527
>>>
>>> Log:
>>> MFC r303795:
>>> Add __cxa_thre
And one more.
On 8/21/16, Oliver Pinter wrote:
> On 8/21/16, Oliver Pinter wrote:
>> On 8/21/16, Oliver Pinter wrote:
>>> On 8/20/16, Konstantin Belousov wrote:
Author: kib
Date: Sat Aug 20 12:26:44 2016
New Revision: 304527
URL: https://svnweb.freebsd.org/changeset/base/30
On 20/08/16 23:05, Slawa Olhovchenkov wrote:
I am think this substitution is very bad idea (by design).
Also, on transmit side this is must be irrelevant on received L2
header (and this in many cases this is will be L2 unicast packet). For
other cases packet will be created on host and don't have
On 21/08/16 00:25, Bruce Simpson wrote:
[Use a predicted branch in favour of Ethernet to optimize common case
comments snipped]
...we ensure that M_BCAST is cleared at all times before possible
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols
decide themselves if re-ente
On 21/08/16 00:25, Bruce Simpson wrote:
On 20/08/16 23:05, Slawa Olhovchenkov wrote:
In router case receiving broadcast packet in any way need additional
check for dst IP address (host part is all zero or all one? what about
handling this broadcast type (RFC talk about conroling variation of
thi
[snip]
Just for everyone else on the list, would you mind distilling the
original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how
they're supposed to be used?
thanks,
-adrian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd
On 21/08/16 00:47, Adrian Chadd wrote:
[snip]
Just for everyone else on the list, would you mind distilling the
original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how
they're supposed to be used?
(With my best Liam Neeson 'Dad' voice from Fallout 3)
They stay as-is, but IP is
And an updated version of the fix.
On 8/21/16, Oliver Pinter wrote:
> And one more.
>
> On 8/21/16, Oliver Pinter wrote:
>> On 8/21/16, Oliver Pinter wrote:
>>> On 8/21/16, Oliver Pinter wrote:
On 8/20/16, Konstantin Belousov wrote:
> Author: kib
> Date: Sat Aug 20 12:26:44 2016
On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote:
> On 20/08/16 23:05, Slawa Olhovchenkov wrote:
> > I am think this substitution is very bad idea (by design).
> > Also, on transmit side this is must be irrelevant on received L2
> > header (and this in many cases this is will be L2 un
Author: adrian
Date: Sun Aug 21 00:48:41 2016
New Revision: 304552
URL: https://svnweb.freebsd.org/changeset/base/304552
Log:
[mips] add support for the "creative" GNU extensions and IRIX hilarity around
MIPS LO16/HI16 relocations.
This was .. an interesting headache.
There are two ha
On Fri, Aug 19, 2016 at 5:13 PM, John Baldwin wrote:
> Author: jhb
> Date: Fri Aug 19 22:13:01 2016
> New Revision: 304505
> URL: https://svnweb.freebsd.org/changeset/base/304505
>
> Log:
> Remove mentions of the mcd(4), scd(4), and si(4) drivers.
>
Hmm, looks like ie(4) also needs removal (in
On Thu, 18 Aug 2016, Alexander Motin wrote:
Author: mav
Date: Thu Aug 18 11:56:07 2016
New Revision: 304425
URL: https://svnweb.freebsd.org/changeset/base/304425
Log:
MFC r302504, r302666, r302668, r302932, r302933:
Add emulation for Intel e1000 (e82545) network adapter.
The code was succes
Author: ngie
Date: Sun Aug 21 05:08:37 2016
New Revision: 304553
URL: https://svnweb.freebsd.org/changeset/base/304553
Log:
Unbreak the build when MK_TESTS != no after r304527
- src.opts.mk should be bsd.own.mk on ^/stable/10
- LIBADD should be DPADD/LDADD on ^/stable/10
Pointyhat to
> On Aug 20, 2016, at 16:50, Oliver Pinter
> wrote:
>
> And an updated version of the fix.
Fixed in r304553 — thanks!
-Ngie
signature.asc
Description: Message signed with OpenPGP using GPGMail
76 matches
Mail list logo
