Season's Greetings

[Saket Agarwal]

[image: Inline image 1]



Please reply to this email if you want to unsubscribe.

Best Regards
*Mousumi Nandan *
SARA | Business Development Executive
Mobile: +91 987 45678 47
Office: +91 33 400 88 333
Email: mousumi.sarainternatio...@gmail.com
  sales.sarainternatio...@gmail.com
   info.sarainternatio...@gmail.com
Sara International
“We believe in building long term relationship”
55 Ezra Street, 2nd Floor, Kolkata

West Bengal, India

Email marketing inside Gmail

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD_STABLE_10-i386 - Build #1644 - Still Failing

[jenkins-admin]

FreeBSD_STABLE_10-i386 - Build #1644 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1644/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1644/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1644/console

Change summaries:

312400 by marius:
MFC: r273180, r283754, r297329, r299414, r300707, r310309, r310340 (partial),
 r310341, r311664, r311793-311794

o Use correct response bits for MMC_RSP_R4-R7 types

o Make sdhci(4) work after suspend/resume for chipsets that require
  the frequency quirk. This makes it work on eg ThinkPad T420.

o Add a convenience macro that masks all the bits related to clock divisors
  in all versions of the sdhci spec (the HI bits are just unused reserved
  bits in earlier versions).

o sdhci/mmc: Minor whitespace cleanups

o Add Braswell PCI IDs for Intel Cherryview

o mmc: Accept even lower voltage for Cherryview

  And HP x2 210, per DragonFlyBSD 240bd9cd58f8259c12c14a8006837e698.

o In mmcsd_task(), bio_resid was not being set to 0 on a successful read
  or write, resulting in random short-read and short-write returns for
  requests. Fixing this fixes nominal block I/O via mmcsd(4).

  Obtained from: DragonFlyBSD (fd4b97583be1a1e57234713c25f6e81bc0411cb0)

o Add support for Intel Apollo Lake and Bay Trail eMMC PCI controllers.

o Flesh out the support for Intel Braswell eMMC controllers further.

o In sdhci_init_slot(), use the right capability field for determining
  the announced bus width based on MMC_CAP_*_BIT_DATA.

312398 by marius:
MFC: r296135

Replace several bus_alloc_resource() calls with bus_alloc_resource_any()

Most of these are BARs, and we allocate them in their entirety. The one
outlier in this is amdsbwd(4), which calls bus_set_resource() prior.

312397 by jhb:
MFC 310028: Use db_lookup_proc() in the DDB 'show procvm' command.

This allows processes to be identified by PID as well as a pointer address.



The end of the build log:

[...truncated 69111 lines...]
--- depend_subdir_BIG5 ---
===> share/i18n/csmapper/BIG5 (depend)
--- gnu.depend__D ---
--- _sub.depend ---
===> gnu/usr.bin/gperf/doc (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib 
-I/usr/src/gnu/usr.bin/gperf
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc   
--- share.depend__D ---
--- depend_subdir_CNS ---
===> share/i18n/csmapper/CNS (depend)
--- depend_subdir_CP ---
===> share/i18n/csmapper/CP (depend)
--- depend_subdir_EBCDIC ---
===> share/i18n/csmapper/EBCDIC (depend)
--- depend_subdir_GB ---
===> share/i18n/csmapper/GB (depend)
--- depend_subdir_GEORGIAN ---
===> share/i18n/csmapper/GEORGIAN (depend)
--- depend_subdir_ISO646 ---
===> share/i18n/csmapper/ISO646 (depend)
--- depend_subdir_ISO-8859 ---
===> share/i18n/csmapper/ISO-8859 (depend)
--- gnu.depend__D ---
echo gperf: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
echo gperf: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend
--- share.depend__D ---
--- depend_subdir_esdb ---
===> share/i18n/esdb (depend)
--- depend_subdir_csmapper ---
--- depend_subdir_JIS ---
===> share/i18n/csmapper/JIS (depend)
--- depend_subdir_KAZAKH ---
===> share/i18n/csmapper/KAZAKH (depend)
--- depend_subdir_esdb ---
--- depend_subdir_APPLE ---
===> share/i18n/esdb/APPLE (depend)
--- depend_subdir_csmapper ---
--- depend_subdir_KOI ---
===> share/i18n/csmapper/KOI (depend)
--- depend_subdir_KS ---
===> share/i18n/csmapper/KS (depend)
--- depend_subdir_MISC ---
===> share/i18n/csmapper/MISC (depend)
--- depend_subdir_esdb ---
--- depend_subdir_AST ---
===> share/i18n/esdb/AST (depend)
--- depend_subdir_csmapper ---
--- depend_subdir_TCVN ---
===> share/i18n/csmapper/TCVN (depend)
--- depend_subdir_esdb ---
--- depend_subdir_BIG5 ---
===> share/i18n/esdb/BIG5 (depend)
--- depend_subdir_keys ---
===> share/keys (depend)
--- _sub.depend ---
===> share/keys/pkg (depend)
--- _sub.depend ---
===> share/keys/pkg/trusted (depend)
--- depend_subdir_i18n ---
--- depend_subdir_CP ---
===> share/i18n/esdb/CP (depend)
--- sbin.depend__D ---
--- depend_subdir_ipfw ---
===> sbin/ipfw 

Re: NFS and amd on older FreeBSD [SOLVED]

[Karl Young]

Karl Young(ka...@kipshouse.org)@2017.01.12 11:00:07 -0800:
> Thanks Greg
> 
> One correction.  The new server is FreeBSD 9.2, not 9.3.  Replies below
> 
> Greg Byshenk(free...@byshenk.net)@2017.01.12 08:58:16 +0100:
> > On Wed, Jan 11, 2017 at 03:47:37PM -0800, Karl Young wrote:
> > > I inherited a lab that has a few hundred hosts running FreeBSD 7.2.
> > > These hosts run test scripts that access files that are stored on
> > > FreeBSD 6.3 host.  The 6.3 host exports a /data directory with NFS
> > > 
> > > [...]
> > >
> > > $ showmount -e  9.3-host
> > > Exports list on 9.3-host:
> > > /data   Everyone
> > > 
> > > But I can't automount it:
> > > 
> > > $ ls -l /net/9.3-host/data
> > > ls: /net/9.3-host/data: No such file or directory
> > > 
> > > If I manually mount the exported directory, it works:
> > > 
> > > $ sudo mount -t nfs 9.3-host:/data /mnt/data/
> > > $ mount | grep nfs
> > > 9.3-host:/data on /mnt/data (nfs)
> > > 
> > > $ ls -l /mnt/data
> > > total 4
> > > drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2
> > > 
> > > I've spent some time on Google, but haven't found a solution.  I realize
> > > these are very old versions, but I'm not in a position to upgrade them
> > > right now.  My last resort will be to use /etc/fstab to do the NFS
> > > mount, but I'd rather avoid that if I can.
> > 
> > If you can mount the share manually, there is almost 
> > certainly nothing wrong with the server. Based on the
> > error ("No such file or directory"), I would recommend
> > checking your amd config on the client.
> > 
> 
> Yes, that makes sense, but I'm using the same client in both cases.  In
> rc.conf on client, I have:
> 
>   nfs_reserved_port_only="YES"
>   nfs_client_enable="YES"
>   amd_enable="YES"
> 
> 
> And ps shows the amd process started with these flags:
> 
> /usr/sbin/amd -p -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map
> 
> amd.map is the default
> 
> $ cat /etc/amd.map 
> # $FreeBSD: src/etc/amd.map,v 1.10.8.1 2009/04/15 03:14:26 kensmith Exp
> # $
> #
> /defaults   type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
> *   opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev
> 
> This is the same default amd.map as 9.2.
> 
> Another data point: I see the same behavior with a 9.2 client:  I can
> automount a share from my 6.3 server, but not from the 9.2 server.

Well, I might have found a workaround, but it's weird, seems to be
DNS-related.

Something I left out (didn't think it was important) is that the 6.3
server is out on our corporate net, so I used a FQDN:

ls -l 6.3-server.example.com/data

But the new server lives in our lab, so it has an RFC1918 address, and
doesn't have a .com TLD.

ls -l 9.2-server.lab/data

I found that if I use the IP address, OR if I terminate the server name
with a '.', it now works.

ls -l /net/10.15.2.22/data/
total 4
drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2

$ ls -l /net/9.2-server.lab./data/ 
total 4
drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2

$ ls -l /net/9.2-server.lab/data/
ls: /net/9.2-server.lab/data/: No such file or directory

$ showmount -e 9.2-server.lab
Exports list on 9.2-server.lab:
/data   Everyone

Sorry for the diversion.

-karl

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Vestibular SENAI 2017/1 - 50% de desconto no 1º semestre para Industriários e Dependentes

[FIERGS | FATEC - Faculdade SENAI de Tecnologia]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

O Que Você Quer ser Amanhã? Cursos Técnicos 2017 na Faculdade SENAI

[FIERGS | FATEC - Faculdade SENAI de Tecnologia]

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing

[Pedro Giffuni]

On 01/18/17 12:46, Andriy Gapon wrote:

On 18/01/2017 18:58, jenkins-ad...@freebsd.org wrote:

FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/console

Change summaries:

312386 by pfg:
MFC r311947, r311981:

rpcgen(1): Avoid unused variable warning on generated code.

Avoid "unused variable 'i'" warnings in generated .c files by only
emitting the "int i;" for non-opaque arrays. Opaque arrays use
xdr_opaque() rather than iterating over the array.

Obtained from:  OpenBSD (CVS rev 1.28)

rpcgen(1): Check getrlimit() return for generated code.

Obtained from:  NetBSD (CVS rev 1.27, 1.28)

312382 by avg:
MFC r310630: libkvm: support access to vmm guest memory, allow writes to
fwmem and vmm

Sponsored by:Panzura



The end of the build log:


...


make[5]: make[5]: don't know how to make gzguts.h. Stop

make[5]: stopped in /usr/src/sys/boot/libstand32



gzguts.h in libstand32?
That does not seem to be related to any of the commits listed at the beginning.



It says "still failing" so the breakage comes from the past.

Pedro.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing

[Andriy Gapon]

On 18/01/2017 18:58, jenkins-ad...@freebsd.org wrote:
> FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing:
> 
> Build information: 
> https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/console
> 
> Change summaries:
> 
> 312386 by pfg:
> MFC r311947, r311981:
> 
> rpcgen(1): Avoid unused variable warning on generated code.
> 
> Avoid "unused variable 'i'" warnings in generated .c files by only
> emitting the "int i;" for non-opaque arrays. Opaque arrays use
> xdr_opaque() rather than iterating over the array.
> 
> Obtained from:OpenBSD (CVS rev 1.28)
> 
> rpcgen(1): Check getrlimit() return for generated code.
> 
> Obtained from:NetBSD (CVS rev 1.27, 1.28)
> 
> 312382 by avg:
> MFC r310630: libkvm: support access to vmm guest memory, allow writes to
> fwmem and vmm
> 
> Sponsored by:  Panzura
> 
> 
> 
> The end of the build log:

...

> make[5]: make[5]: don't know how to make gzguts.h. Stop
> 
> make[5]: stopped in /usr/src/sys/boot/libstand32


gzguts.h in libstand32?
That does not seem to be related to any of the commits listed at the beginning.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing

[jenkins-admin]

FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/console

Change summaries:

312386 by pfg:
MFC r311947, r311981:

rpcgen(1): Avoid unused variable warning on generated code.

Avoid "unused variable 'i'" warnings in generated .c files by only
emitting the "int i;" for non-opaque arrays. Opaque arrays use
xdr_opaque() rather than iterating over the array.

Obtained from:  OpenBSD (CVS rev 1.28)

rpcgen(1): Check getrlimit() return for generated code.

Obtained from:  NetBSD (CVS rev 1.27, 1.28)

312382 by avg:
MFC r310630: libkvm: support access to vmm guest memory, allow writes to
fwmem and vmm

Sponsored by:Panzura



The end of the build log:

[...truncated 69303 lines...]
echo gvinum: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libedit.a 
/usr/obj/usr/src/tmp/usr/lib/libtermcap.a 
/usr/obj/usr/src/tmp/usr/lib/libdevstat.a /usr/obj/usr/src/tmp/usr/lib/libkvm.a 
/usr/obj/usr/src/tmp/usr/lib/libgeom.a >> .depend
--- depend_subdir_hastctl ---
===> sbin/hastctl (depend)
--- share.depend__D ---
--- depend_subdir_vt ---
===> share/vt (depend)
--- sbin.depend__D ---
--- parse.c ---
yacc -d -v /usr/src/sbin/hastctl/../hastd/parse.y
--- share.depend__D ---
--- _sub.depend ---
===> share/vt/fonts (depend)
--- sbin.depend__D ---
cp y.tab.c parse.c
--- token.c ---
lex  -otoken.c /usr/src/sbin/hastctl/../hastd/token.l
--- share.depend__D ---
===> share/vt/keymaps (depend)
--- sbin.depend__D ---
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/hastctl/../hastd 
-DHAVE_CAPSICUM -DINET -DINET6 -DYY_NO_UNPUT -DYY_NO_INPUT -DHAVE_CRYPTO 
-std=gnu99/usr/src/sbin/hastctl/../hastd/activemap.c 
/usr/src/sbin/hastctl/../hastd/crc32.c /usr/src/sbin/hastctl/../hastd/ebuf.c 
/usr/src/sbin/hastctl/../hastd/hast_checksum.c 
/usr/src/sbin/hastctl/../hastd/hast_compression.c 
/usr/src/sbin/hastctl/../hastd/hast_proto.c /usr/src/sbin/hastctl/hastctl.c 
/usr/src/sbin/hastctl/../hastd/lzf.c /usr/src/sbin/hastctl/../hastd/metadata.c 
/usr/src/sbin/hastctl/../hastd/nv.c parse.c 
/usr/src/sbin/hastctl/../hastd/pjdlog.c /usr/src/sbin/hastctl/../hastd/proto.c 
/usr/src/sbin/hastctl/../hastd/proto_common.c 
/usr/src/sbin/hastctl/../hastd/proto_uds.c token.c 
/usr/src/sbin/hastctl/../hastd/subr.c
--- share.depend__D ---
--- depend_subdir_zoneinfo ---
===> share/zoneinfo (depend)
--- gnu.depend__D ---
--- depend_subdir_gperf ---
===> gnu/usr.bin/gperf (depend)
--- _sub.depend ---
===> gnu/usr.bin/gperf/doc (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib 
-I/usr/src/gnu/usr.bin/gperf
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/positions.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc   
--- secure.depend__D ---
echo ssh: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/private/libssh.a 
/usr/obj/usr/src/tmp/usr/lib/libutil.a 
/usr/obj/usr/src/tmp/usr/lib/private/libldns.a 
/usr/obj/usr/src/tmp/usr/lib/libgssapi.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypt.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypto.a /usr/obj/usr/src/tmp/usr/lib/libz.a >> 
.depend
--- depend_subdir_ssh-add ---
===> secure/usr.bin/ssh-add (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a
-I/usr/src/secure/usr.bin/ssh-add/../../../crypto/openssh -DHAVE_LDNS=1 
-std=gnu99   -include ssh_namespace.h 
/usr/src/secure/usr.bin/ssh-add/../../../crypto/openssh/ssh-add.c
--- gnu.depend__D ---
echo gperf: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
echo gperf: /usr/obj/usr/src/tmp/usr/lib/libc++.a >> .depend
--- secure.depend__D ---
--- depend_subdir_usr.sbin ---
===> secure/usr.sbin (depend)
--- depend_subdir_usr.bin ---
echo ssh-add: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/private/libssh.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypt.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypto.a /usr/obj/usr/src/tmp/usr/lib/libz.a >> 
.depend
--- depend_subdir_ssh-agent ---
===> secure/usr.bin/ssh-agent (depend)
--- 

FreeBSD_STABLE_10-i386 - Build #1642 - Failure

[jenkins-admin]

FreeBSD_STABLE_10-i386 - Build #1642 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1642/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1642/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1642/console

Change summaries:

312375 by delphij:
MFC r311275: Restructure libz.



The end of the build log:

[...truncated 68873 lines...]
--- share.depend__D ---
--- _sub.depend ---
===> share/vt/fonts (depend)
--- sbin.depend__D ---
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/geom/class/raid3/../.. 
-std=gnu99/usr/src/sbin/geom/class/raid3/geom_raid3.c 
/usr/src/sbin/geom/class/raid3/../../misc/subr.c
--- share.depend__D ---
===> share/vt/keymaps (depend)
--- depend_subdir_zoneinfo ---
===> share/zoneinfo (depend)
--- sbin.depend__D ---
echo geom_raid3.so: /usr/obj/usr/src/tmp/usr/lib/libmd.a >> .depend
===> sbin/geom/class/sched (depend)
--- depend_subdir_ggate ---
===> sbin/ggate (depend)
--- depend_subdir_geom ---
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/geom/class/sched/../.. 
-std=gnu99/usr/src/sbin/geom/class/sched/geom_sched.c 
/usr/src/sbin/geom/class/sched/../../misc/subr.c
--- depend_subdir_ggate ---
--- _sub.depend ---
===> sbin/ggate/ggatec (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-DMAX_SEND_SIZE=32768 -DLIBGEOM 
-I/usr/src/sbin/ggate/ggatec/../shared -std=gnu99
/usr/src/sbin/ggate/ggatec/ggatec.c /usr/src/sbin/ggate/ggatec/../shared/ggate.c
--- depend_subdir_geom ---
===> sbin/geom/class/shsec (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/geom/class/shsec/../.. 
-std=gnu99/usr/src/sbin/geom/class/shsec/geom_shsec.c 
/usr/src/sbin/geom/class/shsec/../../misc/subr.c
--- depend_subdir_ggate ---
echo ggatec: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libgeom.a /usr/obj/usr/src/tmp/usr/lib/libsbuf.a 
/usr/obj/usr/src/tmp/usr/lib/libbsdxml.a /usr/obj/usr/src/tmp/usr/lib/libutil.a 
/usr/obj/usr/src/tmp/usr/lib/libpthread.a >> .depend
===> sbin/ggate/ggated (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/ggate/ggated/../shared 
-std=gnu99/usr/src/sbin/ggate/ggated/ggated.c 
/usr/src/sbin/ggate/ggated/../shared/ggate.c
--- depend_subdir_geom ---
===> sbin/geom/class/stripe (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/geom/class/stripe/../.. 
-std=gnu99/usr/src/sbin/geom/class/stripe/geom_stripe.c 
/usr/src/sbin/geom/class/stripe/../../misc/subr.c
--- depend_subdir_ggate ---
echo ggated: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libpthread.a 
/usr/obj/usr/src/tmp/usr/lib/libutil.a >> .depend
===> sbin/ggate/ggatel (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-DLIBGEOM 
-I/usr/src/sbin/ggate/ggatel/../shared -std=gnu99
/usr/src/sbin/ggate/ggatel/ggatel.c /usr/src/sbin/ggate/ggatel/../shared/ggate.c
--- depend_subdir_geom ---
===> sbin/geom/class/virstor (depend)
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/sbin/geom/class/virstor/../.. 
-std=gnu99
/usr/src/sbin/geom/class/virstor/../../../../sys/geom/virstor/binstream.c 
/usr/src/sbin/geom/class/virstor/../../../../sys/geom/virstor/g_virstor_md.c 
/usr/src/sbin/geom/class/virstor/geom_virstor.c 
/usr/src/sbin/geom/class/virstor/../../misc/subr.c
--- depend_subdir_ggate ---
echo ggatel: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libgeom.a /usr/obj/usr/src/tmp/usr/lib/libsbuf.a 
/usr/obj/usr/src/tmp/usr/lib/libbsdxml.a /usr/obj/usr/src/tmp/usr/lib/libutil.a 
>> .depend
--- sys.depend__D ---
===> sys (depend)
--- _sub.depend ---
===> sys/boot (depend)
--- _sub.depend ---
===> sys/boot/ficl (depend)
--- secure.depend__D ---
echo ssh: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/private/libssh.a 
/usr/obj/usr/src/tmp/usr/lib/libutil.a 
/usr/obj/usr/src/tmp/usr/lib/private/libldns.a 
/usr/obj/usr/src/tmp/usr/lib/libgssapi.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypt.a 
/usr/obj/usr/src/tmp/usr/lib/libcrypto.a /usr/obj/usr/src/tmp/usr/lib/libz.a >> 
.depend
--- depend_subdir_ssh-add ---
===> secure/usr.bin/ssh-add (depend)
--- sbin.depend__D ---
--- depend_subdir_growfs ---
===> sbin/growfs (depend)
--- secure.depend__D ---
--- .depend ---
rm -f .depend
CC='cc ' mkdep -f .depend -a
-I/usr/src/secure/usr.bin/ssh-add/../../../crypto/openssh -DHAVE_LDNS=1 
-std=gnu99   -include ssh_namespace.h 
/usr/src/secure/usr.bin/ssh-add/../../../crypto/openssh/ssh-add.c
--- sys.depend__D ---
--- softcore.c ---
--- sbin.depend__D ---
--- .depend ---
--- sys.depend__D ---
(cd /usr/src/sys/boot/ficl/softwords; cat softcore.fr jhlocal.fr marker.fr 
freebsd.fr ficllocal.fr  ifbrack.fr  | awk -f softcore.awk -v 
datestamp="`LC_ALL=C date`") > softcore.c
--- sbin.depend__D ---
rm -f .depend
CC='cc ' 

Re: decent 40G network adapters

[Eugene M. Zheganin]

Hi.

On 18.01.2017 15:03, Slawa Olhovchenkov wrote:
> I am use Chelsio and Solarflare.
> Not sure about you workload -- I am have 40K+ TCP connections, you
> workload need different tuning.
> Do you planed to utilise both ports?
> For this case you need PCIe 16x card. This is Chelsio T6 and
> Solarflare 9200. 
Thanks. No, the number of connections in my case will be small -
hundreds, and right now target servers are utilizing 4-5 Gbit/sec
bandwidth, so I'm looking forward to something more performing, thats
all. The pps number is also way below Mpps - at this time it's about 200
kpps, so I really hope I won't be facing a situation with millions of
pps, - though seems like it will be slightly above 1 Mpps. Hopefully
with the help of the community I'll be able to tune the servers to
handle this ! :)

Thanks.
Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: decent 40G network adapters

[Andrew Rybchenko]

On 01/18/2017 12:48 PM, Eugene M. Zheganin wrote:

Hi.

Could someone recommend a decent 40Gbit adapter that are proven to be
working under FreeBSD ? The intended purpose - iSCSI traffic, not much
pps, but rates definitely above 10G. I've tried Supermicro-manufactured
Intel XL710 ones (two boards, different servers - same sad story:
packets loss, server unresponsive, spikes), seems like they have a
problem in a driver (or firmware), and though Intel support states this
is because the Supermicro tampered with the adapter, I'm still
suspicious about ixl(4). I've also seen in the ML a guy reported the
exact same problem with ixl(4) as I have found.

So, what would you say ? Chelsio ?

Hi,

Solarflare SFN8542 with sfxge driver will do the job

Andrew.


Thanks.
Eugene.

___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: decent 40G network adapters

[Slawa Olhovchenkov]

On Wed, Jan 18, 2017 at 02:48:19PM +0500, Eugene M. Zheganin wrote:

> Hi.
> 
> Could someone recommend a decent 40Gbit adapter that are proven to be
> working under FreeBSD ? The intended purpose - iSCSI traffic, not much
> pps, but rates definitely above 10G. I've tried Supermicro-manufactured
> Intel XL710 ones (two boards, different servers - same sad story:
> packets loss, server unresponsive, spikes), seems like they have a
> problem in a driver (or firmware), and though Intel support states this
> is because the Supermicro tampered with the adapter, I'm still
> suspicious about ixl(4). I've also seen in the ML a guy reported the
> exact same problem with ixl(4) as I have found.
> 
> So, what would you say ? Chelsio ?

I am use Chelsio and Solarflare.
Not sure about you workload -- I am have 40K+ TCP connections, you
workload need different tuning.
Do you planed to utilise both ports?
For this case you need PCIe 16x card. This is Chelsio T6 and
Solarflare 9200. 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: decent 40G network adapters

[Hans Petter Selasky]

On 01/18/17 10:48, Eugene M. Zheganin wrote:

Hi.

Could someone recommend a decent 40Gbit adapter that are proven to be
working under FreeBSD ? The intended purpose - iSCSI traffic, not much
pps, but rates definitely above 10G. I've tried Supermicro-manufactured
Intel XL710 ones (two boards, different servers - same sad story:
packets loss, server unresponsive, spikes), seems like they have a
problem in a driver (or firmware), and though Intel support states this
is because the Supermicro tampered with the adapter, I'm still
suspicious about ixl(4). I've also seen in the ML a guy reported the
exact same problem with ixl(4) as I have found.

So, what would you say ? Chelsio ?



Hi,

I think also the Mellanox, mlx4 and mlx5 drivers will support this. Are 
you using infiniband or TCP for backend?


--HPS

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

decent 40G network adapters

[Eugene M. Zheganin]

Hi.

Could someone recommend a decent 40Gbit adapter that are proven to be
working under FreeBSD ? The intended purpose - iSCSI traffic, not much
pps, but rates definitely above 10G. I've tried Supermicro-manufactured
Intel XL710 ones (two boards, different servers - same sad story:
packets loss, server unresponsive, spikes), seems like they have a
problem in a driver (or firmware), and though Intel support states this
is because the Supermicro tampered with the adapter, I'm still
suspicious about ixl(4). I've also seen in the ML a guy reported the
exact same problem with ixl(4) as I have found.

So, what would you say ? Chelsio ?

Thanks.
Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"