Hi everyone,
I got the following error on a make tinderbox. It only affects i386
for whatever reason; I haven't debug into why:
linking kernel
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridden
ld: warning: common OPENSSL_ia32cap_P is overridd
Set it to 4k and move on. I'm not aware of any efforts in the VM
layer or network stack to make >PAGE_SIZE clusters usable in practical
situations. Honestly, at this point I wish that we'd just kill them
entirely.
On Fri, Dec 3, 2021 at 12:52 PM John Jasen wrote:
>
> Pretty close to two years a
You're trying to use different MACs with each vlan. I don't believe
that this is really a support configuration in our stack, although
putting the interface into promiscuous I guess works.
Recently at work we saw a panic in ip6_setpktopt() while it's using an
ifnet returned by ifnet_byindex, here:
https://cgit.freebsd.org/src/tree/sys/netinet6/ip6_output.c#n2969
The issue seems to be that rip6_output() calls into ip6_setpktopts()
outside of the net epoch. Should I just wrap the se
On Fri, Feb 12, 2021 at 4:14 PM Alexander V. Chernikov
wrote:
> The slightly different approach here: https://reviews.freebsd.org/D28629
> We indeed are running under epoch, so that prevents _immediate_ ifa
> destruction.
> However, we still can run into the situation when
> * in thread 1 we drop
Thanks! For reference, I tried this patch and it did resolve my leak:
https://github.com/rysto32/freebsd/commit/73caa71c351c072d673d477972fda2aeb369eb3d
I haven't exhaustively tested the routing code, though, so I can't say
for certain that the assert will always be true, nor am I certain that
n
On main I'm seeing leaks of ifaddr reference counts. I can reproduce
this in a bhyve VM by repeating this:
vlan=`ifconfig vlan create vlandev vtnet0 vlan 777`
ifconfig $vlan up
ifconfig $vlan 1.0.0.1/24
ifconfig $vlan destroy
If I watch the ifaddr column of vmstat -m
So what's the plan with the iflib watchdog? If it's not going to be
fixed, should it just be removed entirely? I don't think that's a
great idea but I remember that the Intel watchdogs got a lot of
rototilling to try and get them right so I'm nervous about going in
and just trying to reimplement
ric Joyner wrote:
>
> I'll add Piotr, the author of your linked patch, to this thread.
>
> Are you seeing a problem connected to the watchdog? Piotr tells me that
> IFLIB_QUEUE_WORKING isn't used now, but it wasn't even used before his patch.
>
> - Eric
>
&
https://svnweb.freebsd.org/base?view=revision&revision=356310
As of r356310, there does not appear to be a way that ift_qstatus can
be set to anything but IFLIB_QUEUE_IDLE. As a result, I don't see
that there is any way for the watchdog to ever fire.
I think that iflib has missed setting ift_qst
Today at $WORK we saw a panic due to a race between
in6_joingroup_locked and if_detach_internal. This happened on a
branch that's about 2 years behind head, but the relevant code in head
does not appear to have changed.
The backtrace of the panic was this:
panic: Fatal trap 9: general protection
Using min is definitely not correct. That would ensure that you
either got a pause of 1 tick or 0 ticks.
This may get you better granularity, depending on the system.
pause_sbt("e1000_delay", x * SBT_1US, x < 1000 ? 100 * SBT_1US : SBT_1MS, 0);
___
fre
On Fri, Sep 11, 2020 at 12:33 PM Scheffenegger, Richard
wrote:
>
> Hi,
>
> Currently, upstream head has only an IOCTL API to set up interface-wide
> default PCP marking:
>
> #define SIOCGVLANPCPSIOCGLANPCP /* Get VLAN PCP */
> #define SIOCSVLANPCPSIOCSLANPCP /* Set VLAN PCP */
On Tue, Aug 18, 2020 at 5:43 PM Marko Zec wrote:
> Since in ng_pipe we define BER as an one error in BER bits (integer
> value), wouldn't your formula P = 1 - BER yield results less than or
> equal to zero for all non-zero values of BER? The domain of P is
> [0..1], so that won't fly.
>
> Your an
On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein wrote:
> Sorry, missed that. But why wasn't possible?
There's a daemon running on the system that handles most network
configuration. It's quite inflexible and will override any manual
configuration changes. It manages firewall rules but is ignora
On Tue, Aug 18, 2020 at 1:17 PM Ryan Stone wrote:
> 4. The table calculation had two integer truncation bugs and used the
> wrong formula. I'm reasonably sure it would never calculate a
> probability other than 0 due a 64-bit constant being truncated to
> 32-bits.
I've
I recently needed to be able to simulate a lossy, high-latency network
in an environment where dummynet wasn't possible. I gave ng_pipe a
try, and hit some major issues
1. Instead of configuring a packet drop rate, you configure a bit
error rate, which I found significantly less intuitive
2. The
# ifconfig vtnet0 inet6 1::1
# ndp -P
panic: prefix 0xf80011c56700 has referencing addresses
cpuid = 1
time = 1591991817
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0022d08720
vpanic() at vpanic+0x19d/frame 0xfe0022d08770
panic() at panic+0x43/f
Thanks for the analysis. I haven't had much of an opportunity to get
into the guts of iflib and I'm not very successful at following the
round trips through mpring yet.
On Mon, Mar 23, 2020 at 12:50 AM Patrick Kelsey wrote:
>
>
>
> On Sun, Mar 22, 2020 at 2:31 PM Ryan St
I've been tracking down a bug at work that appears to be due to
excessive latency introduced on the TX side of a TCP connection. In
looking through the iflib code, I noticed the tunable
net.iflib.min_tx_latency. My reading of the iflib code is that if a
packet is enqueued to a tx ring but not pos
> At Wed, 2 Oct 2019 17:04:23 -0400,
> Ryan Stone wrote:
> >
> > At work, our product is putting through an IPv6 conformance test and
> > it's found an issue in our handling of Routing Advertisements (RAs).
> > If we receive an RA that does not specify an llad
At work, our product is putting through an IPv6 conformance test and
it's found an issue in our handling of Routing Advertisements (RAs).
If we receive an RA that does not specify an lladdr, then
nd6_cache_lladdr() is called with lladdr NULL:
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c
rrs@ has just posted the BBR patch to phabricator:
https://reviews.freebsd.org/D21582
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
I have put a CR up on phab for this:
https://reviews.freebsd.org/D17246
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
I didn't get a response to this, so I'm forwarding to a higher-traffic
list. Does anybody know if there is work in progress on a for for
stable/10?
-- Forwarded message -----
From: Ryan Stone
Date: Tue, Sep 11, 2018 at 2:37 PM
Subject: Status of 10.4 fixes for CVE
Recently at work I had a system crash while executing RTFREE() in
udp_notify(). In looking at the system I discovered that two threads
had called udp_notify() on the same pcb. This was possible because
the threads only held a read lock on the socket. The obvious solution
is to hold a write lock
On Tue, May 29, 2018 at 12:58 PM Sean Bruno wrote:
>
> Does anyone have a process for testing the VF drivers (ixgbe igb, etc)
> in FreeBSD without actually firing up linux to instantiate a VM or using
> EC2?
We have native support for creating VFs for ixl and ixgbe (and cxgbe).
For igb you're out
On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov
wrote:
> +#ifndef MLX5E_MAX_RX_BYTES
> +#defineMLX5E_MAX_RX_BYTES MCLBYTES
> +#endif
Why do you use a 2KB buffer rather than a PAGE_SIZE'd buffer?
MJUMPAGESIZE should offer significantly better performance for jumbo
frames without incre
Unfortunately, this is a known issue with the bxe driver. I was under
the impression that QLogic had committed a fix to -head, but I just
checked and it hasn't seen any updates from QLogic in over a year,
unfortunately.
___
freebsd-net@freebsd.org mailin
Currently, the FreeBSD stack gets itself into a bizarre state if you
try to change the source IP for a subnet route (yes, this implies
using two IPs on the same subnet on a system. Yes, I'm aware this is
a Bad Idea(TM). Unfortunately I have a customer that insists on this
configuration)
You can
A change a while back (r264986) broke the ability to change a route's
parameters if the gateway wasn't explicitly specified again. For
example, you used to be able to run "route change 10.0.0.0/8 -mtu
9000" to change the MTU without having to provide the gateway IP to
the command. I have a review
I've opened 3 phabricator reviews fixing issues with the inpcb llentry caching.
https://reviews.freebsd.org/D13988
This fix invalidates the llentry cache after the L3 route cache was
invalidated by the routing table's generation count incrementing.
Without this fix existing connections would cont
I'm going to prefix this question by noting that I realize that the
configuration that I am about to describe is quite nonsensical.
Unfortunately, it seems that under older versions of FreeBSD (possibly
FreeBSD 7-vintage), the configuration mostly "worked", and now at
$WORK I am responsible for mak
On Thu, Dec 7, 2017 at 4:59 PM, Ryan Stone wrote:
> https://reviews.freebsd.org/D13417
I still haven't received any feedback on this review. If nobody
raises an objection by Thursday, I will commit it.
___
freebsd-net@freebsd.org mailing li
I've put this phab review up that patches an ifaddr refcount leak in
the routing code. When a route is modified in a way that modifies
rt->rt_ifa, in most cases we don't release the reference on the old
one, which can cause it to leak. I have a simple script here that I
wrote to demonstrate the i
Do not allocate MJUM9BYTES clusters under any circumstances. Trying
to allocate them when the system is under memory pressure is
enormously expensive and stands a good chance of livelocking the
system if you try to allocate too many too quickly, even when
allocating with M_NOWAIT.
Honestly, suppo
Please try the following patch. It should resolve your issue:
https://people.freebsd.org/~rstone/patches/e1000-9k.diff
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "free
Ah, never mind. When I started to investigate this problem I was
looking at an old tree. I tried to verify that it was still a problem
on -head, but missed that r315956 fixed the problem in a different way
than I was expecting. Sorry for the noise.
___
About a year back we brought back lle (the ARP/NDP entry) caching back
into the network stack. As near as I can tell, the ethernet layer
will take a reference on the lle and place a pointer to it in the
ro_lle field in the struct route passed down from the upper layer.
The upper layer is expected
Hans and I have proposed different approaches to the problem. I was
taken off this issue at $WORK for a while, but coincidentally I just
picked it up again in the last week or so. I'm working on evaluating
the performance characteristics of the two approaches and once I'm
satisfied with that I'll
I've just put up a review that fixes mlx4_en to no longer use clusters
larger than PAGE_SIZE in its receive path. The patch is based off of the
older version of the driver which did the same, but keeps all of the
changes to the driver since then (including support for bus_dma). The
review can be
This isn't possible in general. When PCI Passthrough is in use, the VF
driver will run in the context of the VM's kernel and there is no device_t
corresponding to the PF at all. If you're looking to pass information from
the PF down to the VF, then you need to establish some kind of
device-mediat
Having looking at the original email more closely, I see that you showed an
mlxen interface with a 9020 MTU. Seeing allocation failures of 9k mbuf
clusters increase while you are far below the zone's limit means that
you're definitely running into the bug I'm describing, and this bug could
plausib
Is this setup using the mlx4_en driver? If so, recent versions of that
driver has a regression when using MTUs greater than the page size (4096 on
i386/amd64). The bug will cause the card to drop packets when the system
is under memory pressure, and in certain causes the card can get into a
state
On Wed, May 17, 2017 at 7:32 PM, Andrew Vylegzhanin
wrote:
>
> vmx0@pci0:4:0:0: class=0x02 card=0x07b015ad chip=0x07b015ad rev=0x01
> hdr=0x00
>
> vendor = 'VMware'
>
> device = 'VMXNET3 Ethernet Controller'
>
> class = network
>
> subclass = ethernet
>
> vmx1@p
The bug that you refer to does not appear to be related to your issue.
What does "pciconf -l" print in your FreeBSD VM?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "free
n the vlan interface (assuming
that the network that you are routing to can accept 1518 byte packets), or
only advertise a 1496 byte MTU in your internal network.
On Mon, Dec 5, 2016 at 2:10 PM, Chris Ross wrote:
>
> > On Dec 5, 2016, at 11:59, Ryan Stone wrote:
> >
> > What
What's the MTU on the bce and vlan interfaces? Does the bce interface show
VLAN_MTU option set (in ifconfig)?
On Mon, Dec 5, 2016 at 10:00 AM, Chris Ross
wrote:
>
> Hello all. I recently replaced my router with a FreeBSD/11 box
> (stable/11 r308579). I am running a lagg device across two bce
On Fri, Dec 2, 2016 at 3:42 PM, Chris Torek wrote:
> THE QUESTION:
>
> - Who is wrong, the bxe driver or the bridge code? I.e.,
>does the bridge driver need to release its lock here,
>and if so, is that actually safe to do? (We might need
>to restart the loop over all the members if
This revision was automatically updated to reflect the committed changes.
rstone marked an inline comment as done.
Closed by commit rS309372: Fix a false positive in a buf_ring assert (authored
by rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D8685?vs=22633&id=22651#toc
REPOSITO
rstone marked an inline comment as done.
rstone added inline comments.
INLINE COMMENTS
> hselasky wrote in buf_ring.h:71
> should "br->br_cons_head + 1" be masked by br->br_cons_mask ??
Absolutely correct. Nice catch, thank you
REVISION DETAIL
https://reviews.freebsd.org/D8685
EMAIL PREFERE
rstone updated this revision to Diff 22633.
rstone added a comment.
Ensure we don't walk off the end of the ring
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D8685?vs=22631&id=22633
REVISION DETAIL
https://reviews.freebsd.org/D8685
AFFECTED FILES
sys/sys/buf_ring.h
CHANGE DET
rstone added a subscriber: freebsd-net-list.
REVISION DETAIL
https://reviews.freebsd.org/D8685
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: rstone
Cc: freebsd-net-list, emaste
___
freebsd-net@freebsd.org mailin
On Thu, Sep 22, 2016 at 4:04 AM, Steven Hartland
wrote:
> The disappointing thing about this is we had a solution, all be it one not
> everyone liked, nearly a year ago now and yet here we are still stuck with
> a broken lagg implementation in the tree.
>
I would point out this 4-year-old thread
On Wed, Sep 21, 2016 at 7:57 PM, Gleb Smirnoff wrote:
> IMHO, the original patch was absolutely evil hack touching multiple
> layers, for the sake of a very special problem.
>
> I think, that in order to kick forwarding table on switches, lagg
> should:
>
> - allocate an mbuf itself
> - set its s
On Thu, Aug 18, 2016 at 4:48 PM, Paul A. Procacci
wrote:
> You should be able to ping the local subnet.
> Alternatively you can use net/arping.
>
> ~Paul
>
I'm specifically looking to test the handling of 255.255.255.255, so a
local broadcast address is out. Unfortunately, arping doesn't seem t
I want to test a change to broadcast packet handling and I want to confirm
that 255.255.255.255 is still handled correctly. Are there any command-line
tools in FreeBSD that can send to the broadcast address? ping
255.255.255.255 does not work correctly, unfortunately.
_
On Thu, Aug 4, 2016 at 11:33 AM, Ben RUBSON wrote:
> But even without RSS, I should be able to go up to 2x40Gbps, don't you
> think so ?
> Nobody already did this ?
>
Try this patch, which should improve performance when multiple TCP streams
are running in parallel over an mlx4_en port:
https:/
The use of mbuf clusters larger than a single page really doesn't work.
The problem is that over time physical memory becomes fragmented and
eventually 9K of contiguous memory can't be allocated anymore. This is why
many drivers now limit themselves to page-sized clusters.
On Mon, Jun 6, 2016 at
r299512 introduced breakage into dhclient, which was fixed in r300174.
That may be the source of the issue?
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsub
From a quick look at the vlan code, I can identify a few cases that might
cause that counter to increment:
1) Error from the underlying ixgbe device. Does "netstat -dI ix0" show
that the driver has been dropping packets?
2) Link down events on the underlying NIC. I believe that link flaps will
When you say the "connection drops", do you mean that the NIC loses link
and then has it comes back? Are you using DHCP to get the main address?
It sounds like perhaps dhclient is running and clearing the addresses it
doesn't know about.
___
freebsd-net@
An easier way to block ICMP redirects would be to set the sysctl:
sysctl net.inet.icmp.drop_redirect=1
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr.
On Wed, Nov 11, 2015 at 11:18 AM, Steven Hartland
wrote:
> Comparing this to the Linux driver which does detect the link down I've
> discovered it actually polls the link status by default in its watchdog.
>
> Disabling this with "ethtool --set-priv-flags eth1 LinkPolling off" and
> the Linux dri
At $WORK, we have observed that if you attempt to add a route with the
-iface flag, but you specify an incorrect interface name, the route command
will perform a DNS lookup of the interface name. It appears that if the
DNS lookup succeeds that it will treat the parameter to -iface as if it
were a
On Jul 28, 2015 11:07 AM, "Sergey Kandaurov" wrote:
>
> On 28 July 2015 at 20:55, Alexander V. Chernikov
wrote:
> > 28.07.2015, 15:32, "Arseny Nasokin" :
> >
> > Separate ifconfig_IF_description will be simpler to use.
> >
> > I was also insisting on this..
> > +pluknet@
> > Sergey, maybe we coul
On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan <
lakshm...@msystechnologies.com> wrote:
> [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c
> ixl_txrx.c.mod
> *** ixl_txrx.c Fri Jun 12 06:56:51 2015
> --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015
> *
rstone added inline comments.
INLINE COMMENTS
sys/net/if_lagg.c:1772 style(9) says to not include unnecessary braces (which
I personally disagree with, but what can you do?)
sys/net/if_lagg.c:1773 style(9): put brackets around the return value:
return (0);
sys/net/if_lagg.c:1811 I find
rstone added a comment.
RLOCK only gets a read lock. You want WLOCK to get a write lock to ensure
serialization.
REVISION DETAIL
https://reviews.freebsd.org/D1986
To: rpokala-panasas.com, rstone
Cc: ae, freebsd-net
___
freebsd-net@freebsd.org maili
I've just finished committing support for PCI Single Root I/O
Virtualization in the pci subsystem to head. This should be a no-op
for everyone right now, but there were some minor refactorings in the
pci code that could have a lingering bug. I did make sure to test
that it boots on a variety of s
rstone closed this revision.
rstone updated this revision to Diff 4043.
rstone added a comment.
Closed by commit rS279439 (authored by @rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1883?vs=3826&id=4043#toc
REVISION DETAIL
https://reviews.freebsd.org/D1883
AFFECTED FILES
h
rstone closed this revision.
rstone updated this revision to Diff 4041.
rstone added a comment.
Closed by commit rS279438 (authored by @rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1882?vs=3825&id=4041#toc
REVISION DETAIL
https://reviews.freebsd.org/D1882
AFFECTED FILES
h
rstone closed this revision.
rstone updated this revision to Diff 4039.
rstone added a comment.
Closed by commit rS279435 (authored by @rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1879?vs=3822&id=4039#toc
REVISION DETAIL
https://reviews.freebsd.org/D1879
AFFECTED FILES
h
rstone closed this revision.
rstone updated this revision to Diff 4040.
rstone added a comment.
Closed by commit rS279436 (authored by @rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1880?vs=3823&id=4040#toc
REVISION DETAIL
https://reviews.freebsd.org/D1880
AFFECTED FILES
h
rstone closed this revision.
rstone updated this revision to Diff 4038.
rstone added a comment.
Closed by commit rS279425 (authored by @rstone).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1870?vs=3862&id=4038#toc
REVISION DETAIL
https://reviews.freebsd.org/D1870
AFFECTED FILES
h
rstone added a subscriber: freebsd-net.
REVISION DETAIL
https://reviews.freebsd.org/D1986
To: rpokala-panasas.com, rstone
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, se
This is great! Thanks to both you and Intel. I'm planning on getting
SR-IOV support into head this week, which would allow you to create
ixlv instances (on the same hardware). Any chance that you'd have the
time to look into supporting SR-IOV for that driver too?
I think that you might be a bit confused about the behaviour. An ix
port will only be missing if
a) You have a non-Intel SFP+ installed
b) hw.ix.unsupported_sfp=1 is not set in loader.conf
ix ports that have no SFP+ installed do show up in ifconfig
___
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1881
To: rstone, jfvogel, will
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
rstone added a comment.
Err, that was supposed to be "installed it into a couple of *VMs*"
REVISION DETAIL
https://reviews.freebsd.org/D1881
To: rstone, jfvogel
Cc: will, emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.
rstone added a comment.
Ok, I did a full buildworld/buildkernel (with device zfs in my kernel config)
and installed it into a couple of zfs. I tested creating a zpool out of a mfs
disk, creating filesystems, setting some properties, doing a git clone into a
file system, and then doing a zfs se
rstone updated this revision to Diff 3862.
rstone added a comment.
This revision now requires review to proceed.
Fix the test case to actually test the clone
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1870?vs=3813&id=3862
BRANCH
review_D1870
REVISION DETAIL
https://reviews.fre
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1877
To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "fr
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1878
To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "fr
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1869
To: rstone, jfvogel
Cc: emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mai
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1868
To: rstone, jfvogel
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "fr
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1872
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1871
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1873
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1874
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1875
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1876
To: rstone, jfvogel, pjd
Cc: freebsd-net, pjd
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail t
rstone added a comment.
The primary testing that I did was to ensure that a kernel with "device zfs"
would still link. However, I suppose that doesn't exclude the possibility of
their being an zfs source file that is built wrong and doesn't include this
header. Is there a zfs test suite that
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1648
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1640
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1644
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1641
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1645
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1647
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
rstone closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1642
To: rstone, jfvogel
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
1 - 100 of 258 matches
Mail list logo
