mlx5(4) jumbo receive
Hello,
the patch below is of interest for people who use Mellanox Connect-X/4
and 5 ethernet adapters and configure it for jumbo frames. The patch
should improve the system behavior on low or fragmented memory situations.
See the commit message for detailed description. Also, the patch should
not cause performance degradation for the normal 1500 MTU by keeping the
same configuration as currently unpatched driver.
I am interested in hearing about regressions (or not) caused by the
change.
commit f25c0c624177a1ca06ca051b0adb842acb66ec11
Author: Konstantin Belousov
Date: Wed Nov 22 20:14:53 2017 +0200
mlx5en: Handle jumbo frames without requiring big clusters.
The scatter list is formed by the chunks of MCLBYTES each, and larger
than default packets are returned to the stack as the mbuf chain.
This is an improvements over the original patch by ha...@mellanox.com
which solves some busdma issues and sizes WQEs scatter list to only
have the minimal sufficient number of elements. In particular, for
the default MTU 1500 bytes the receive queue format is not changed
comparing to the unpatched driver, avoiding a reported performance
regression.
Issue: 1065432
Issue: 1184316
Change-Id: Ib63a5ef55abd6ef1ec9b296e2cef88e4604bbd29
Signed-off-by: Konstantin Belousov
diff --git a/sys/dev/mlx5/mlx5_en/en.h b/sys/dev/mlx5/mlx5_en/en.h
index b5000c32eaf..ff5ef446e34 100644
--- a/sys/dev/mlx5/mlx5_en/en.h
+++ b/sys/dev/mlx5/mlx5_en/en.h
@@ -80,8 +80,19 @@
#defineMLX5E_PARAMS_DEFAULT_LOG_RQ_SIZE0xa
#defineMLX5E_PARAMS_MAXIMUM_LOG_RQ_SIZE0xe
-/* freeBSD HW LRO is limited by 16KB - the size of max mbuf */
+#defineMLX5E_MAX_RX_SEGS 7
+
+#ifndef MLX5E_MAX_RX_BYTES
+#defineMLX5E_MAX_RX_BYTES MCLBYTES
+#endif
+
+#if (MLX5E_MAX_RX_SEGS == 1)
+/* FreeBSD HW LRO is limited by 16KB - the size of max mbuf */
#defineMLX5E_PARAMS_DEFAULT_LRO_WQE_SZ MJUM16BYTES
+#else
+#defineMLX5E_PARAMS_DEFAULT_LRO_WQE_SZ \
+MIN(65535, MLX5E_MAX_RX_SEGS * MLX5E_MAX_RX_BYTES)
+#endif
#defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC 0x10
#defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC_FROM_CQE 0x3
#defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_PKTS 0x20
@@ -530,6 +541,7 @@ struct mlx5e_rq {
struct mtx mtx;
bus_dma_tag_t dma_tag;
u32 wqe_sz;
+ u32 nsegs;
struct mlx5e_rq_mbuf *mbuf;
struct ifnet *ifp;
struct mlx5e_rq_stats stats;
@@ -795,9 +807,12 @@ struct mlx5e_tx_wqe {
struct mlx5e_rx_wqe {
struct mlx5_wqe_srq_next_seg next;
- struct mlx5_wqe_data_seg data;
+ struct mlx5_wqe_data_seg data[];
};
+/* the size of the structure above must be power of two */
+CTASSERT(powerof2(sizeof(struct mlx5e_rx_wqe)));
+
struct mlx5e_eeprom {
int lock_bit;
int i2c_addr;
diff --git a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
index c2c4b0d7744..25544e561e3 100644
--- a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
+++ b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
@@ -33,9 +33,12 @@
#ifndef ETH_DRIVER_VERSION
#defineETH_DRIVER_VERSION "3.4.1"
#endif
+
char mlx5e_version[] = "Mellanox Ethernet driver"
" (" ETH_DRIVER_VERSION ")";
+static int mlx5e_get_wqe_sz(struct mlx5e_priv *priv, u32 *wqe_sz, u32 *nsegs);
+
struct mlx5e_channel_param {
struct mlx5e_rq_param rq;
struct mlx5e_sq_param sq;
@@ -810,6 +813,11 @@ mlx5e_create_rq(struct mlx5e_channel *c,
int wq_sz;
int err;
int i;
+ u32 nsegs, wqe_sz;
+
+ err = mlx5e_get_wqe_sz(priv, &wqe_sz, &nsegs);
+ if (err != 0)
+ goto done;
/* Create DMA descriptor TAG */
if ((err = -bus_dma_tag_create(
@@ -819,9 +827,9 @@ mlx5e_create_rq(struct mlx5e_channel *c,
BUS_SPACE_MAXADDR, /* lowaddr */
BUS_SPACE_MAXADDR, /* highaddr */
NULL, NULL, /* filter, filterarg */
- MJUM16BYTES,/* maxsize */
- 1, /* nsegments */
- MJUM16BYTES,/* maxsegsize */
+ nsegs * MLX5E_MAX_RX_BYTES, /* maxsize */
+ nsegs, /* nsegments */
+ nsegs * MLX5E_MAX_RX_BYTES, /* maxsegsize */
0, /* flags */
NULL, NULL, /* lockfunc, lockfuncarg */
&rq->dma_tag)))
@@ -834,23 +842,9 @@ mlx5e_create_rq(struct mlx5e_channel *c,
rq->wq.db = &rq->wq.db[MLX5_RCV_DBR];
- if (priv->params.hw_lro_en) {
- rq->wqe_sz = priv->params.lro_wqe_sz;
- } else {
- rq->wqe_sz = MLX5E_SW2MB_MTU(priv->ifp->if_mtu);
- }
- if (rq->wqe_sz > MJUM16BYTES) {
- err = -ENOMEM;
+ err = mlx5
Re: mlx5(4) jumbo receive
On 24 Apr, Konstantin Belousov wrote: Hello, the patch below is of interest for people who use Mellanox Connect-X/4 and 5 ethernet adapters and configure it for jumbo frames. Hi Konstantin, Good news ! Do you think your work could be easily ported to Connect-X/3 devices (mlx4 driver) ? Thank you very much, Ben For completeness regarding mlx4, some work has been started on it : https://reviews.freebsd.org/D11560 There's a discussion : https://lists.freebsd.org/pipermail/freebsd-net/2017-June/048293.html Which continues here : https://lists.freebsd.org/pipermail/freebsd-net/2017-September/048906.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mlx5(4) jumbo receive
On Tue, Apr 24, 2018 at 11:55:38AM +0200, Ben RUBSON wrote: > On 24 Apr, Konstantin Belousov wrote: > > > Hello, > > the patch below is of interest for people who use Mellanox Connect-X/4 > > and 5 ethernet adapters and configure it for jumbo frames. > > Hi Konstantin, > > Good news ! > Do you think your work could be easily ported to Connect-X/3 devices (mlx4 > driver) ? No, it cannot be easily ported. The port might happen, but I do not promise this. > > Thank you very much, > > Ben > > For completeness regarding mlx4, some work has been started on it : > https://reviews.freebsd.org/D11560 > There's a discussion : > https://lists.freebsd.org/pipermail/freebsd-net/2017-June/048293.html > Which continues here : > https://lists.freebsd.org/pipermail/freebsd-net/2017-September/048906.html ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mlx5(4) jumbo receive
> Hello,
> the patch below is of interest for people who use Mellanox Connect-X/4
> and 5 ethernet adapters and configure it for jumbo frames. The patch
> should improve the system behavior on low or fragmented memory situations.
> See the commit message for detailed description. Also, the patch should
> not cause performance degradation for the normal 1500 MTU by keeping the
> same configuration as currently unpatched driver.
>
> I am interested in hearing about regressions (or not) caused by the
> change.
I'll hopefully get to test this early next week, but my schedule
is very full until then.
I do have a fist full of sytle(9) and other comments though.
You can probably ignore my nits on capitalize start of comments,
it seems that this may be the style of this code
> commit f25c0c624177a1ca06ca051b0adb842acb66ec11
> Author: Konstantin Belousov
> Date: Wed Nov 22 20:14:53 2017 +0200
>
> mlx5en: Handle jumbo frames without requiring big clusters.
>
> The scatter list is formed by the chunks of MCLBYTES each, and larger
> than default packets are returned to the stack as the mbuf chain.
>
> This is an improvements over the original patch by ha...@mellanox.com
> which solves some busdma issues and sizes WQEs scatter list to only
> have the minimal sufficient number of elements. In particular, for
> the default MTU 1500 bytes the receive queue format is not changed
> comparing to the unpatched driver, avoiding a reported performance
> regression.
>
> Issue: 1065432
> Issue: 1184316
> Change-Id: Ib63a5ef55abd6ef1ec9b296e2cef88e4604bbd29
> Signed-off-by: Konstantin Belousov
>
> diff --git a/sys/dev/mlx5/mlx5_en/en.h b/sys/dev/mlx5/mlx5_en/en.h
> index b5000c32eaf..ff5ef446e34 100644
> --- a/sys/dev/mlx5/mlx5_en/en.h
> +++ b/sys/dev/mlx5/mlx5_en/en.h
> @@ -80,8 +80,19 @@
> #define MLX5E_PARAMS_DEFAULT_LOG_RQ_SIZE0xa
> #define MLX5E_PARAMS_MAXIMUM_LOG_RQ_SIZE0xe
>
> -/* freeBSD HW LRO is limited by 16KB - the size of max mbuf */
Though it is tempting to fix spelling errors and stylish things
while working on code it usually helps to sepeate those into
either a pre or post commit to reduce the lines of code change
that need to be looked at when reviewing a diff. This also helps
diff(1) to chunk things a bit better.
> +#define MLX5E_MAX_RX_SEGS 7
> +
> +#ifndef MLX5E_MAX_RX_BYTES
> +#define MLX5E_MAX_RX_BYTES MCLBYTES
> +#endif
> +
> +#if (MLX5E_MAX_RX_SEGS == 1)
> +/* FreeBSD HW LRO is limited by 16KB - the size of max mbuf */
> #define MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ MJUM16BYTES
> +#else
> +#define MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ \
> +MIN(65535, MLX5E_MAX_RX_SEGS * MLX5E_MAX_RX_BYTES)
> +#endif
> #define MLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC 0x10
> #define MLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC_FROM_CQE 0x3
> #define MLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_PKTS 0x20
> @@ -530,6 +541,7 @@ struct mlx5e_rq {
> struct mtx mtx;
> bus_dma_tag_t dma_tag;
> u32 wqe_sz;
> + u32 nsegs;
Alphabetic order, and should just use modify the current u32 line:
u32 nsegs, wqe_sz;
> struct mlx5e_rq_mbuf *mbuf;
> struct ifnet *ifp;
> struct mlx5e_rq_stats stats;
> @@ -795,9 +807,12 @@ struct mlx5e_tx_wqe {
>
> struct mlx5e_rx_wqe {
> struct mlx5_wqe_srq_next_seg next;
> - struct mlx5_wqe_data_seg data;
> + struct mlx5_wqe_data_seg data[];
None standard way to declare a pointer?
> };
>
> +/* the size of the structure above must be power of two */
the should be The.
> +CTASSERT(powerof2(sizeof(struct mlx5e_rx_wqe)));
> +
> struct mlx5e_eeprom {
> int lock_bit;
> int i2c_addr;
> diff --git a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> index c2c4b0d7744..25544e561e3 100644
> --- a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> +++ b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> @@ -33,9 +33,12 @@
> #ifndef ETH_DRIVER_VERSION
> #define ETH_DRIVER_VERSION "3.4.1"
> #endif
> +
Adding white space is a style change, and actually unwanted right here
as the next line is tightly coupled to the previous line.
> char mlx5e_version[] = "Mellanox Ethernet driver"
> " (" ETH_DRIVER_VERSION ")";
>
> +static int mlx5e_get_wqe_sz(struct mlx5e_priv *priv, u32 *wqe_sz, u32
> *nsegs);
> +
Could you move the function before use and eliminate the need
for the forward declare?
> struct mlx5e_channel_param {
> struct mlx5e_rq_param rq;
> struct mlx5e_sq_param sq;
> @@ -810,6 +813,11 @@ mlx5e_create_rq(struct mlx5e_channel *c,
> int wq_sz;
> int err;
> int i;
> + u32 nsegs, wqe_sz;
> +
> + err = mlx5e_get_wqe_sz(priv, &wqe_sz, &nsegs);
> + if (err != 0)
> + goto done;
>
> /* Create DMA descriptor TAG */
> if ((err = -bus_dma_tag_create(
>
Re: mlx5(4) jumbo receive
On Tue, Apr 24, 2018 at 06:44:24AM -0700, Rodney W. Grimes wrote:
> > Hello,
> > the patch below is of interest for people who use Mellanox Connect-X/4
> > and 5 ethernet adapters and configure it for jumbo frames. The patch
> > should improve the system behavior on low or fragmented memory situations.
> > See the commit message for detailed description. Also, the patch should
> > not cause performance degradation for the normal 1500 MTU by keeping the
> > same configuration as currently unpatched driver.
> >
> > I am interested in hearing about regressions (or not) caused by the
> > change.
>
> I'll hopefully get to test this early next week, but my schedule
> is very full until then.
>
> I do have a fist full of sytle(9) and other comments though.
>
> You can probably ignore my nits on capitalize start of comments,
> it seems that this may be the style of this code
>
> > commit f25c0c624177a1ca06ca051b0adb842acb66ec11
> > Author: Konstantin Belousov
> > Date: Wed Nov 22 20:14:53 2017 +0200
> >
> > mlx5en: Handle jumbo frames without requiring big clusters.
> >
> > The scatter list is formed by the chunks of MCLBYTES each, and larger
> > than default packets are returned to the stack as the mbuf chain.
> >
> > This is an improvements over the original patch by ha...@mellanox.com
> > which solves some busdma issues and sizes WQEs scatter list to only
> > have the minimal sufficient number of elements. In particular, for
> > the default MTU 1500 bytes the receive queue format is not changed
> > comparing to the unpatched driver, avoiding a reported performance
> > regression.
> >
> > Issue: 1065432
> > Issue: 1184316
> > Change-Id: Ib63a5ef55abd6ef1ec9b296e2cef88e4604bbd29
> > Signed-off-by: Konstantin Belousov
> >
> > diff --git a/sys/dev/mlx5/mlx5_en/en.h b/sys/dev/mlx5/mlx5_en/en.h
> > index b5000c32eaf..ff5ef446e34 100644
> > --- a/sys/dev/mlx5/mlx5_en/en.h
> > +++ b/sys/dev/mlx5/mlx5_en/en.h
> > @@ -80,8 +80,19 @@
> > #defineMLX5E_PARAMS_DEFAULT_LOG_RQ_SIZE0xa
> > #defineMLX5E_PARAMS_MAXIMUM_LOG_RQ_SIZE0xe
> >
> > -/* freeBSD HW LRO is limited by 16KB - the size of max mbuf */
> Though it is tempting to fix spelling errors and stylish things
> while working on code it usually helps to sepeate those into
> either a pre or post commit to reduce the lines of code change
> that need to be looked at when reviewing a diff. This also helps
> diff(1) to chunk things a bit better.
>
> > +#defineMLX5E_MAX_RX_SEGS 7
> > +
> > +#ifndef MLX5E_MAX_RX_BYTES
> > +#defineMLX5E_MAX_RX_BYTES MCLBYTES
> > +#endif
> > +
> > +#if (MLX5E_MAX_RX_SEGS == 1)
> > +/* FreeBSD HW LRO is limited by 16KB - the size of max mbuf */
> > #defineMLX5E_PARAMS_DEFAULT_LRO_WQE_SZ MJUM16BYTES
> > +#else
> > +#defineMLX5E_PARAMS_DEFAULT_LRO_WQE_SZ \
> > +MIN(65535, MLX5E_MAX_RX_SEGS * MLX5E_MAX_RX_BYTES)
> > +#endif
> > #defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC 0x10
> > #defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_USEC_FROM_CQE 0x3
> > #defineMLX5E_PARAMS_DEFAULT_RX_CQ_MODERATION_PKTS 0x20
> > @@ -530,6 +541,7 @@ struct mlx5e_rq {
> > struct mtx mtx;
> > bus_dma_tag_t dma_tag;
> > u32 wqe_sz;
> > + u32 nsegs;
>
> Alphabetic order, and should just use modify the current u32 line:
> u32 nsegs, wqe_sz;
>
> > struct mlx5e_rq_mbuf *mbuf;
> > struct ifnet *ifp;
> > struct mlx5e_rq_stats stats;
> > @@ -795,9 +807,12 @@ struct mlx5e_tx_wqe {
> >
> > struct mlx5e_rx_wqe {
> > struct mlx5_wqe_srq_next_seg next;
> > - struct mlx5_wqe_data_seg data;
> > + struct mlx5_wqe_data_seg data[];
>
> None standard way to declare a pointer?
This is not a pointer declaration. It is a flexible array member.
For the style issues, I will take look later.
>
> > };
> >
> > +/* the size of the structure above must be power of two */
> the should be The.
>
> > +CTASSERT(powerof2(sizeof(struct mlx5e_rx_wqe)));
> > +
> > struct mlx5e_eeprom {
> > int lock_bit;
> > int i2c_addr;
> > diff --git a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> > b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> > index c2c4b0d7744..25544e561e3 100644
> > --- a/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> > +++ b/sys/dev/mlx5/mlx5_en/mlx5_en_main.c
> > @@ -33,9 +33,12 @@
> > #ifndef ETH_DRIVER_VERSION
> > #defineETH_DRIVER_VERSION "3.4.1"
> > #endif
> > +
> Adding white space is a style change, and actually unwanted right here
> as the next line is tightly coupled to the previous line.
>
> > char mlx5e_version[] = "Mellanox Ethernet driver"
> > " (" ETH_DRIVER_VERSION ")";
> >
> > +static int mlx5e_get_wqe_sz(struct mlx5e_priv *priv, u32 *wqe_sz, u32
> > *nsegs);
> > +
>
> Could you move the function before use and eliminate the need
> for the forward declare?
>
> > struct mlx5e_channel_param {
> > struct ml
Deprecating the lmc(4) driver
The lmc(4) driver supports hardware for a number of legacy interfaces, including EIA612/613, T1/E1, T3, etc. The driver's license is ambiguous and attempts to contact the author failed. I would like to remove this driver from 12.0, and have a deprecation notice in review D15182 [1]; I would appreciate hearing from anyone who is currently using lmc(4) in case it is still providing some value. [1] https://reviews.freebsd.org/D15182 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
zfskern{txg_thread_enter} thread using 100% or more CPU
Hi,
Recently on multiple systems running CURRENT, I've been seeing the
system become unresponsive. Leaving top(1) running has lead me to notice
that when this happens, the system is still responding to ping and top
over ssh is still working, but no new processes can start and switching
to other tasks doesn't work. In top, I do see pid 17,
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO. Any
ideas how to troubleshoot this? It doesn't appear to be a hardware issue.
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfskern{txg_thread_enter} thread using 100% or more CPU
On Wed, Apr 25, 2018 at 2:30 AM, Steve Wills wrote:
Hi,
Recently on multiple systems running CURRENT, I've been seeing the
system become unresponsive. Leaving top(1) running has lead me to
notice that when this happens, the system is still responding to ping
and top over ssh is still working, but no new processes can start and
switching to other tasks doesn't work. In top, I do see pid 17,
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO.
Any ideas how to troubleshoot this? It doesn't appear to be a
hardware issue.
Hi,
Do you have something writing to a gzip compressed dataset? You can use
the vfssnoop DTrace script from
https://forums.freebsd.org/threads/sharing-of-dtrace-scripts.32855/#post-181816
to see who's writing what.
I don't remember if it was exactly txg_thread_enter or whatever, but
both CPU and disk sounds a lot like heavily compressed writes.
In my case, the Epiphany browser was downloading a large malware
database to ~/.config/epiphany/gsb-threats.db :D
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[no subject]
Hi, Today, suddenly pkg or bsdtar failed to core dumped. 'pkg info -aI' crashed with: root@vms:~ # pkg info -aI Segmentation fault (core dumped) root@vms:~ # ll *.core -rw--- 1 root wheel 9555968 Apr 25 10:48 pkg.core root@vms:~ # /usr/libexec/gdb /usr/local/sbin/pkg GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) core pkg.core Core was generated by `pkg info -aI'. Program terminated with signal 11, Segmentation fault. #0 0x000800306878 in ?? () (gdb) bt #0 0x000800306878 in ?? () #1 0x00080021307a in ?? () #2 0x000800af8980 in ?? () #3 0x000800af7c7c in ?? () #4 0x7fffdab8 in ?? () #5 0x000800234400 in ?? () #6 0x0003 in ?? () #7 0x7fffdb60 in ?? () #8 0x7fffdb40 in ?? () #9 0x0008002155ad in ?? () #10 0x7fffdb60 in ?? () #11 0x in ?? () (gdb) And 'make extract' in a port: root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make clean ===> Cleaning for vm-bhyve-devel-1.2b root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make deinstall ===> Deinstalling for vm-bhyve-devel ===> vm-bhyve-devel not installed, skipping root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # make -de extract ===> License BSD2CLAUSE accepted by the user ===> vm-bhyve-devel-1.2b depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by vm-bhyve-devel-1.2b for building ===> Extracting for vm-bhyve-devel-1.2b => SHA256 Checksum OK for churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb98b6cd2dc663f859881a12431_GH0.tar.gz. Segmentation fault (core dumped) *** Failed target: do-extract *** Failed command: for file in churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb98b6cd2dc663f859881a12431_GH0.tar.gz; do if ! (cd /var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work && /usr/bin/tar -xf /var/ports/distfiles//$file --no-same-owner --no-same-permissions); then exit 1; fi; done *** Error code 1 Stop. make: stopped in /var/ports/msrvms/sysutils/vm-bhyve-devel root@vms:/var/ports/msrvms/sysutils/vm-bhyve-devel # cd /var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work root@vms:/var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work # ll *.core -rw--- 1 root wheel 9465856 Apr 25 10:53 bsdtar.core root@vms:/var/ports/work/var/ports/msrvms/sysutils/vm-bhyve-devel/work # /usr/libexec/gdb /usr/bin/tar GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) core bsdtar.core warning: core file may not match specified executable file. Core was generated by `/usr/bin/tar -xf /var/ports/distfiles//churchers-vm-bhyve-v1.2b-c9ec4d05f61efeb9'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libarchive.so.7...Reading symbols from /usr/lib/debug//usr/lib/libarchive.so.7.debug...done. done. Loaded symbols for /usr/lib/libarchive.so.7 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libz.so.6...Reading symbols from /usr/lib/debug//lib/libz.so.6.debug...done. done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/libbz2.so.4...Reading symbols from /usr/lib/debug//usr/lib/libbz2.so.4.debug...done. done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/lib/liblzma.so.5...Reading symbols from /usr/lib/debug//usr/lib/liblzma.so.5.debug...done. done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /lib/libbsdxml.so.4...Reading symbols from /usr/lib/debug//lib/libbsdxml.so.4.debug...done. done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libcrypto.so.8...Reading symbols from /usr/lib/debug//lib/libcrypto.so.8.debug...done. done. Loaded symbols for /lib/libcrypto.so.8 Reading symbols from /lib/libthr.so.3...Reading symbols from /usr/lib/debug//lib/libthr.so.3.debug...done. done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 _init () at /ds/src/current/12.0/r331153/lib/csu/amd64/crti.S:34 34 subq$8,%rsp [New Thread 801075000 (LWP 100316/)] Current language: auto; currently asm
