svn commit: r327581 - head/usr.sbin/pciconf

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:29:02 2018
New Revision: 327581
URL: https://svnweb.freebsd.org/changeset/base/327581

Log:
  Remove dead code (comma is either 0 or 1 for sure, no need to test).
  Close /dev/pci when we're done with it.
  
  CID: 1007450, 1007449, 1008615, 1008614

Modified:
  head/usr.sbin/pciconf/cap.c
  head/usr.sbin/pciconf/pciconf.c

Modified: head/usr.sbin/pciconf/cap.c
==
--- head/usr.sbin/pciconf/cap.c Fri Jan  5 07:28:58 2018(r327580)
+++ head/usr.sbin/pciconf/cap.c Fri Jan  5 07:29:02 2018(r327581)
@@ -161,7 +161,7 @@ cap_pcix(int fd, struct pci_conf *p, uint8_t ptr)
printf("supports");
comma = 0;
if (status & PCIXM_STATUS_133CAP) {
-   printf("%s 133MHz", comma ? "," : "");
+   printf(" 133MHz");
comma = 1;
}
if (status & PCIXM_STATUS_266CAP) {
@@ -351,10 +351,8 @@ cap_vendor(int fd, struct pci_conf *p, uint8_t ptr)
printf("%s SATA RAID-0/1/10", comma ? "," : "");
comma = 1;
}
-   if (fvec & (1 << 3)) {
-   printf("%s SATA AHCI", comma ? "," : "");
-   comma = 1;
-   }
+   if (fvec & (1 << 3))
+   printf(", SATA AHCI");
}
}
 }

Modified: head/usr.sbin/pciconf/pciconf.c
==
--- head/usr.sbin/pciconf/pciconf.c Fri Jan  5 07:28:58 2018
(r327580)
+++ head/usr.sbin/pciconf/pciconf.c Fri Jan  5 07:29:02 2018
(r327581)
@@ -1005,6 +1005,7 @@ writeit(const char *name, const char *reg, const char 
 
if (ioctl(fd, PCIOCWRITE, ) < 0)
err(1, "ioctl(PCIOCWRITE)");
+   close(fd);
 }
 
 static void
@@ -1024,4 +1025,5 @@ chkattached(const char *name)
 
exitstatus = pi.pi_data ? 0 : 2; /* exit(2), if NOT attached */
printf("%s: %s%s\n", name, pi.pi_data == 0 ? "not " : "", "attached");
+   close(fd);
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327579 - head/usr.sbin/fdcontrol

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:28:48 2018
New Revision: 327579
URL: https://svnweb.freebsd.org/changeset/base/327579

Log:
  Tag 'a' case as one we're intentionally falling through to
  the 'F' case.
  
  CID: 1008176

Modified:
  head/usr.sbin/fdcontrol/fdcontrol.c

Modified: head/usr.sbin/fdcontrol/fdcontrol.c
==
--- head/usr.sbin/fdcontrol/fdcontrol.c Fri Jan  5 07:24:43 2018
(r327578)
+++ head/usr.sbin/fdcontrol/fdcontrol.c Fri Jan  5 07:28:48 2018
(r327579)
@@ -82,6 +82,7 @@ main(int argc, char **argv)
 
case 'a':
autofmt = 1;
+   /*FALLTHROUGH*/
case 'F':
showfmt = 1;
show = 0;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327580 - head/usr.sbin/ifmcstat

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:28:58 2018
New Revision: 327580
URL: https://svnweb.freebsd.org/changeset/base/327580

Log:
  bits is never null when we call ot. Add an assert to that effect and
  remove test for NULL.
  
  CID: 270774

Modified:
  head/usr.sbin/ifmcstat/printb.c

Modified: head/usr.sbin/ifmcstat/printb.c
==
--- head/usr.sbin/ifmcstat/printb.c Fri Jan  5 07:28:48 2018
(r327579)
+++ head/usr.sbin/ifmcstat/printb.c Fri Jan  5 07:28:58 2018
(r327580)
@@ -32,6 +32,7 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+#include 
 #include 
 
 /*
@@ -43,7 +44,8 @@ printb(const char *s, unsigned int v, const char *bits
int i, any = 0;
char c;
 
-   if (bits && *bits == 8)
+   assert(bits != NULL);
+   if (*bits == 8)
printf("%s=%o", s, v);
else
printf("%s=%x", s, v);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327578 - head/usr.bin/units

2018-01-04 Thread Eitan Adler
Author: eadler
Date: Fri Jan  5 07:24:43 2018
New Revision: 327578
URL: https://svnweb.freebsd.org/changeset/base/327578

Log:
  units(1): add missing ':' for two short arguments
  
  PR:   209850
  MFC After:3 days

Modified:
  head/usr.bin/units/units.c

Modified: head/usr.bin/units/units.c
==
--- head/usr.bin/units/units.c  Fri Jan  5 07:14:39 2018(r327577)
+++ head/usr.bin/units/units.c  Fri Jan  5 07:24:43 2018(r327578)
@@ -763,7 +763,7 @@ main(int argc, char **argv)
history_file = NULL;
outputformat = numfmt;
quit = false;
-   while ((optchar = getopt_long(argc, argv, "+ehf:oqtvHUV", longopts, 
NULL)) != -1) {
+   while ((optchar = getopt_long(argc, argv, "+ehf:o:qtvH:UV", longopts, 
NULL)) != -1) {
switch (optchar) {
case 'e':
outputformat = "%6e";
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327577 - head/sys/cam/ata

2018-01-04 Thread Eitan Adler
Author: eadler
Date: Fri Jan  5 07:14:39 2018
New Revision: 327577
URL: https://svnweb.freebsd.org/changeset/base/327577

Log:
  cam/da: QUIRK: Add 4K quirks for WD Red and Black MHDDs
  
  PR:   188685
  Submitted by: Jeremy Chadwick 
  Reported by:  Martin Birgmeier 

Modified:
  head/sys/cam/ata/ata_da.c

Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c   Fri Jan  5 07:09:40 2018(r327576)
+++ head/sys/cam/ata/ata_da.c   Fri Jan  5 07:14:39 2018(r327577)
@@ -363,7 +363,12 @@ static struct ada_quirk_entry ada_quirk_table[] =
},
{
/* WDC Caviar Black Advanced Format (4k) drives */
-   { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WD??EX*", "*" },
+   { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WDAZEX*", "*" },
+   /*quirks*/ADA_Q_4K
+   },
+   {
+   /* WDC Caviar Black Advanced Format (4k) drives */
+   { T_DIRECT, SIP_MEDIA_FIXED, "*", "WDC WDFZEX*", "*" },
/*quirks*/ADA_Q_4K
},
{
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327576 - head/usr.sbin/dumpcis

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:09:40 2018
New Revision: 327576
URL: https://svnweb.freebsd.org/changeset/base/327576

Log:
  Add a number of sanity checks to the data that we're handling from the
  CIS. Coverity has tagged it as tainted. While this data is more
  trusted than your average data, we still need to do some basic
  validation on it. Check ioctl return value to ensure we switch memory
  targets between common and attribute as well as the lseek.
  
  CID: 1210464, 1006640, 1006868, 1007292, 1009091, 1009822, 1009824

Modified:
  head/usr.sbin/dumpcis/printcis.c
  head/usr.sbin/dumpcis/readcis.c
  head/usr.sbin/dumpcis/readcis.h

Modified: head/usr.sbin/dumpcis/printcis.c
==
--- head/usr.sbin/dumpcis/printcis.cFri Jan  5 07:09:29 2018
(r327575)
+++ head/usr.sbin/dumpcis/printcis.cFri Jan  5 07:09:40 2018
(r327576)
@@ -26,10 +26,8 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#ifndef lint
-static const char rcsid[] =
-  "$FreeBSD$";
-#endif /* not lint */
+#include 
+__FBSDID("$FreeBSD$");
 
 /* 
  * Code cleanup, bug-fix and extension
@@ -183,8 +181,7 @@ static void
 dump_config_map(struct tuple *tp)
 {
u_char *p = tp->data, x;
-   int rlen, mlen = 0;
-   int i;
+   unsigned int rlen, mlen = 0, i;
 
rlen = (p[0] & 3) + 1;
if (tp->code == CIS_CONF_MAP)

Modified: head/usr.sbin/dumpcis/readcis.c
==
--- head/usr.sbin/dumpcis/readcis.c Fri Jan  5 07:09:29 2018
(r327575)
+++ head/usr.sbin/dumpcis/readcis.c Fri Jan  5 07:09:40 2018
(r327576)
@@ -26,16 +26,15 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#ifndef lint
-static const char rcsid[] =
-  "$FreeBSD$";
-#endif /* not lint */
+#include 
+__FBSDID("$FreeBSD$");
 
 /*
  * Code cleanup, bug-fix and extension
  * by Tatsumi Hosokawa 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -52,42 +51,44 @@ static struct tuple_list *read_tuples(int);
 static struct tuple *find_tuple_in_list(struct tuple_list *, unsigned char);
 static struct tuple_info *get_tuple_info(unsigned char);
 
+#define LENGTH_ANY 255
+
 static struct tuple_info tuple_info[] = {
{"Null tuple", CIS_NULL, 0},
-   {"Common memory descriptor", CIS_MEM_COMMON, 255},
-   {"Long link to next chain for CardBus", CIS_LONGLINK_CB, 255},
-   {"Indirect access", CIS_INDIRECT, 255},
-   {"Configuration map for CardBus", CIS_CONF_MAP_CB, 255},
-   {"Configuration entry for CardBus", CIS_CONFIG_CB, 255},
-   {"Long link to next chain for MFC", CIS_LONGLINK_MFC, 255},
+   {"Common memory descriptor", CIS_MEM_COMMON, LENGTH_ANY},
+   {"Long link to next chain for CardBus", CIS_LONGLINK_CB, LENGTH_ANY},
+   {"Indirect access", CIS_INDIRECT, LENGTH_ANY},
+   {"Configuration map for CardBus", CIS_CONF_MAP_CB, LENGTH_ANY},
+   {"Configuration entry for CardBus", CIS_CONFIG_CB, LENGTH_ANY},
+   {"Long link to next chain for MFC", CIS_LONGLINK_MFC, LENGTH_ANY},
{"Base address register for CardBus", CIS_BAR, 6},
{"Checksum", CIS_CHECKSUM, 5},
{"Long link to attribute memory", CIS_LONGLINK_A, 4},
{"Long link to common memory", CIS_LONGLINK_C, 4},
{"Link target", CIS_LINKTARGET, 3},
{"No link", CIS_NOLINK, 0},
-   {"Version 1 info", CIS_INFO_V1, 255},
-   {"Alternate language string", CIS_ALTSTR, 255},
-   {"Attribute memory descriptor", CIS_MEM_ATTR, 255},
-   {"JEDEC descr for common memory", CIS_JEDEC_C, 255},
-   {"JEDEC descr for attribute memory", CIS_JEDEC_A, 255},
-   {"Configuration map", CIS_CONF_MAP, 255},
-   {"Configuration entry", CIS_CONFIG, 255},
-   {"Other conditions for common memory", CIS_DEVICE_OC, 255},
-   {"Other conditions for attribute memory", CIS_DEVICE_OA, 255},
-   {"Geometry info for common memory", CIS_DEVICEGEO, 255},
-   {"Geometry info for attribute memory", CIS_DEVICEGEO_A, 255},
+   {"Version 1 info", CIS_INFO_V1, LENGTH_ANY},
+   {"Alternate language string", CIS_ALTSTR, LENGTH_ANY},
+   {"Attribute memory descriptor", CIS_MEM_ATTR, LENGTH_ANY},
+   {"JEDEC descr for common memory", CIS_JEDEC_C, LENGTH_ANY},
+   {"JEDEC descr for attribute memory", CIS_JEDEC_A, LENGTH_ANY},
+   {"Configuration map", CIS_CONF_MAP, LENGTH_ANY},
+   {"Configuration entry", CIS_CONFIG, LENGTH_ANY},
+   {"Other conditions for common memory", CIS_DEVICE_OC, LENGTH_ANY},
+   {"Other conditions for attribute memory", CIS_DEVICE_OA, LENGTH_ANY},
+   {"Geometry info for common memory", CIS_DEVICEGEO, LENGTH_ANY},
+   {"Geometry info for attribute memory", CIS_DEVICEGEO_A, LENGTH_ANY},
{"Manufacturer ID", CIS_MANUF_ID, 4},
{"Functional ID", CIS_FUNC_ID, 

svn commit: r327575 - head/lib/libefivar

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:09:29 2018
New Revision: 327575
URL: https://svnweb.freebsd.org/changeset/base/327575

Log:
  Need to convert '/' back to '\' when creating a path. Ideally, this
  would be filesystem type dependent, but that's difficult to accomplish
  and it's unclear how the UEFI firmware will cope. Be conservative and
  make boot loaders cope instead.
  
  Sponsored by: Netflix

Modified:
  head/lib/libefivar/efivar-dp-xlate.c

Modified: head/lib/libefivar/efivar-dp-xlate.c
==
--- head/lib/libefivar/efivar-dp-xlate.cFri Jan  5 07:09:24 2018
(r327574)
+++ head/lib/libefivar/efivar-dp-xlate.cFri Jan  5 07:09:29 2018
(r327575)
@@ -527,12 +527,17 @@ find_geom_efimedia(struct gmesh *mesh, const char *dev
 static int
 build_dp(const char *efimedia, const char *relpath, efidp *dp)
 {
-   char *fp, *dptxt = NULL;
+   char *fp, *dptxt = NULL, *cp, *rp;
int rv = 0;
efidp out = NULL;
size_t len;
 
-   fp = path_to_file_dp(relpath);
+   rp = strdup(relpath);
+   for (cp = rp; *cp; cp++)
+   if (*cp == '/')
+   *cp = '\\';
+   fp = path_to_file_dp(rp);
+   free(rp);
if (fp == NULL) {
rv = ENOMEM;
goto errout;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327574 - in head: lib/libefivar usr.sbin/efidp

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:09:24 2018
New Revision: 327574
URL: https://svnweb.freebsd.org/changeset/base/327574

Log:
  Set dp to NULL when we free it, and tree a NULL dp as an error
  condition. This should prevent a double free. In addition, prevent a
  leak by freeing dp each loop and when we're done.
  
  CID: 1383577
  Sponsored by: Netflix

Modified:
  head/lib/libefivar/efivar-dp-xlate.c
  head/usr.sbin/efidp/efidp.c

Modified: head/lib/libefivar/efivar-dp-xlate.c
==
--- head/lib/libefivar/efivar-dp-xlate.cFri Jan  5 07:09:19 2018
(r327573)
+++ head/lib/libefivar/efivar-dp-xlate.cFri Jan  5 07:09:24 2018
(r327574)
@@ -663,6 +663,7 @@ errout:
free(rp);
if (rv != 0) {
free(*dp);
+   *dp = NULL;
}
return (rv);
 }

Modified: head/usr.sbin/efidp/efidp.c
==
--- head/usr.sbin/efidp/efidp.c Fri Jan  5 07:09:19 2018(r327573)
+++ head/usr.sbin/efidp/efidp.c Fri Jan  5 07:09:24 2018(r327574)
@@ -143,10 +143,13 @@ unix_to_efi(void)
char *walker;
int rv;
 
+   dp = NULL;
while (fgets(buffer, sizeof(buffer), stdin)) {
walker= trim(buffer);
+   free(dp);
+   dp = NULL;
rv = efivar_unix_path_to_device_path(walker, );
-   if (rv != 0) {
+   if (rv != 0 || dp == NULL) {
errno = rv;
warn("Can't convert '%s' to efi", walker);
continue;
@@ -158,6 +161,7 @@ unix_to_efi(void)
}
printf("%s\n", efi);
}
+   free(dp);
 }
 
 static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327572 - head/usr.sbin/efibootmgr

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:09:09 2018
New Revision: 327572
URL: https://svnweb.freebsd.org/changeset/base/327572

Log:
  Ensure that we have a description string. When unspecified, default to "".
  
  Sponsored by: Netflix

Modified:
  head/usr.sbin/efibootmgr/efibootmgr.c

Modified: head/usr.sbin/efibootmgr/efibootmgr.c
==
--- head/usr.sbin/efibootmgr/efibootmgr.c   Fri Jan  5 05:34:20 2018
(r327571)
+++ head/usr.sbin/efibootmgr/efibootmgr.c   Fri Jan  5 07:09:09 2018
(r327572)
@@ -591,12 +591,7 @@ create_loadopt(uint8_t *buf, size_t bufmax, uint32_t a
/*
 * Compute the length to make sure the passed in buffer is long enough.
 */
-   if (description)
-   utf8_to_ucs2(description, , _len);
-   else {
-   desc_len = 0;
-   bbuf = NULL;
-   }
+   utf8_to_ucs2(description, , _len);
len = sizeof(uint32_t) + sizeof(uint16_t) + desc_len + dp_size + 
optional_data_size;
if (len > bufmax) {
free(bbuf);
@@ -636,6 +631,8 @@ make_boot_var(const char *label, const char *loader, c
char *bootvar = NULL;
int ret;
 
+   assert(label != NULL);
+
bootvar = make_next_boot_var_name();
if (bootvar == NULL)
err(1, "bootvar creation");
@@ -755,7 +752,7 @@ print_loadopt_str(uint8_t *data, size_t datalen)
 }
 
 static char *
-get_descr(uint8_t* data)
+get_descr(uint8_t *data)
 {
uint8_t *pos = data;
efi_char *desc;
@@ -861,8 +858,8 @@ main(int argc, char *argv[])
/*
 * side effect, adds to boot order, but not yet active.
 */
-   make_boot_var(opts.label, opts.loader, opts.kernel, opts.env,
-   opts.dry_run);
+   make_boot_var(opts.label ? opts.label : "",
+   opts.loader, opts.kernel, opts.env, opts.dry_run);
else if (opts.set_active || opts.set_inactive )
handle_activity(opts.bootnum, opts.set_active);
else if (opts.order != NULL)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327573 - head/usr.sbin/efibootmgr

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 07:09:19 2018
New Revision: 327573
URL: https://svnweb.freebsd.org/changeset/base/327573

Log:
  Free options before setting them. This will prevent us from leaking
  memory when we have multiple copies of the same option from being
  specified.
  
  Sponsored by: Netflix

Modified:
  head/usr.sbin/efibootmgr/efibootmgr.c

Modified: head/usr.sbin/efibootmgr/efibootmgr.c
==
--- head/usr.sbin/efibootmgr/efibootmgr.c   Fri Jan  5 07:09:09 2018
(r327572)
+++ head/usr.sbin/efibootmgr/efibootmgr.c   Fri Jan  5 07:09:19 2018
(r327573)
@@ -217,6 +217,7 @@ parse_args(int argc, char *argv[])
opts.dry_run = true;
break;
case 'e':
+   free(opts.env);
opts.env = strdup(optarg);
break;
case 'h':
@@ -224,12 +225,15 @@ parse_args(int argc, char *argv[])
errx(1, "%s", USAGE);
break;
case 'k':
+   free(opts.kernel);
opts.kernel = strdup(optarg);
break;
case 'L':
+   free(opts.label);
opts.label = strdup(optarg);
break;
case 'l':
+   free(opts.loader);
opts.loader = strdup(optarg);
opts.loader = mangle_loader(opts.loader);
break;
@@ -244,6 +248,7 @@ parse_args(int argc, char *argv[])
opts.once = true;
break;
case 'o':
+   free(opts.order);
opts.order = strdup(optarg);
break;
case 'T':
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327571 - head/usr.sbin/fwcontrol

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 05:34:20 2018
New Revision: 327571
URL: https://svnweb.freebsd.org/changeset/base/327571

Log:
  Don't close fd twice. This line should have been deleted in r327279.
  
  CID: 1384015

Modified:
  head/usr.sbin/fwcontrol/fwdv.c

Modified: head/usr.sbin/fwcontrol/fwdv.c
==
--- head/usr.sbin/fwcontrol/fwdv.c  Fri Jan  5 05:34:14 2018
(r327570)
+++ head/usr.sbin/fwcontrol/fwdv.c  Fri Jan  5 05:34:20 2018
(r327571)
@@ -409,7 +409,6 @@ again:
err(1, "write failed");
}
}
-   close(fd);
fprintf(stderr, "\n");
 send_end:
gettimeofday(, NULL);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327570 - head/sbin/newfs_msdos

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 05:34:14 2018
New Revision: 327570
URL: https://svnweb.freebsd.org/changeset/base/327570

Log:
  Only call close if fd and fd1 are not -1.
  
  CID: 1384018, 1384017

Modified:
  head/sbin/newfs_msdos/mkfs_msdos.c

Modified: head/sbin/newfs_msdos/mkfs_msdos.c
==
--- head/sbin/newfs_msdos/mkfs_msdos.c  Fri Jan  5 05:02:09 2018
(r327569)
+++ head/sbin/newfs_msdos/mkfs_msdos.c  Fri Jan  5 05:34:14 2018
(r327570)
@@ -717,8 +717,10 @@ mkfs_msdos(const char *fname, const char *dtype, const
 rv = 0;
 done:
 free(img);
-close(fd);
-close(fd1);
+if (fd != -1)
+   close(fd);
+if (fd1 != -1)
+   close(fd1);
 
 return rv;
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327569 - head/usr.sbin/devmatch

2018-01-04 Thread Warner Losh
Author: imp
Date: Fri Jan  5 05:02:09 2018
New Revision: 327569
URL: https://svnweb.freebsd.org/changeset/base/327569

Log:
  Fix cut and paste error from devinfo.8 origin of this file
  
  Noticed by: kevans@

Modified:
  head/usr.sbin/devmatch/devmatch.8

Modified: head/usr.sbin/devmatch/devmatch.8
==
--- head/usr.sbin/devmatch/devmatch.8   Fri Jan  5 02:15:05 2018
(r327568)
+++ head/usr.sbin/devmatch/devmatch.8   Fri Jan  5 05:02:09 2018
(r327569)
@@ -29,7 +29,7 @@
 .Dt DEVMATCH 8
 .Os
 .Sh NAME
-.Nm devinfo
+.Nm devmatch
 .Nd print information about unattached devices
 .Sh SYNOPSIS
 .Nm
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Adrian Chadd
does it also happen when you actually enable RSS in the kernel? Since
like I went through a whole lot of pain to assign a flowid at
connection setup time.



-a


On 4 January 2018 at 15:37, Steven Hartland  wrote:
>
>
> On 04/01/2018 22:42, hiren panchasara wrote:
>
> On 01/04/18 at 09:52P, Steven Hartland wrote:
>
> On 04/01/2018 20:50, Eugene Grosbein wrote:
>
> 05.01.2018 3:05, Steven Hartland wrote:
>
> Author: smh
> Date: Thu Jan  4 20:05:47 2018
> New Revision: 327559
> URL: https://svnweb.freebsd.org/changeset/base/327559
>
> Log:
>Disabled the use of flowid for lagg by default
>
>Disabled the use of RSS hash from the network card aka flowid for
>lagg(4) interfaces by default as it's currently incompatible with
>the lacp and loadbalance protocols.
>
>The incompatibility is due to the fact that the flowid isn't know
>for the first packet of a new outbound stream which can result in
>the hash calculation method changing and hence a stream being
>incorrectly split across multiple interfaces during normal
>operation.
>
>This can be re-enabled by setting the following in loader.conf:
>net.link.lagg.default_use_flowid="1"
>
>Discussed with: kmacy
>Sponsored by:  Multiplay
>
> RSS by definition has meaning to received stream. What is "outbound" stream
> in this context, why can the hash calculatiom method change and what exactly
> does it mean "a stream being incorrectly split"?
>
> Yes RSS is indeed a received stream but that is used by lagg for lacp
> and loadbalance protocols to decide which port of the lagg to "send" the
> packet out of. As the flowid is not known when a new "output" stream is
> instigated the current code falls back to manual hash calculation to
> determine which port to send the initial packet from. Once a response is
> received a tx then uses the flowid. This change of hash calculation
> method can result in the initial packet being sent from a different port
> than the rest of the stream; this is what I meant by "incorrectly split".
>
> For my understanding, is this just an issue for the first packet when we
> originate the flow? Once we have a response and if flowid is there, we'd
> use it, right? OR am I missing something?
>
> Initially yes, but that can cause a whole cascading set of problems. If the
> source machine sends from two different ports then flow can traverse across
> the network using different paths and hence arrive at the destination on
> different ports too, causing the corresponding  issue on the other side.
>
> And with this change, we'd always go and do manual calculation even when
> we have a valid flowid (i.e. we didn't initiate a connection)?
>
> Correct, but there's potentially no easy way to correctly determine what the
> flowid and hence hash should be in this case, likely impossible if the lagg
> consists of different interface types.
>
> In addition if the hardware hash doesn't match the requested one as per
> laggproto then additional issues could also be triggered.
>
> Our TCP stack seems fragile during setup to out of order packets which this
> multipath behavior causes, we've seen this on our loadbalancers which is
> what triggered the investigation. The concrete result is many aborted TCP
> connections, over 300k ~2% on the machine I'm looking at.
>
> I hope there's some improvements that can be made, for example if we can
> determine the stream was instigated remotely then flowid would always be
> valid hence we can use it assuming it matches the requested spec or if we
> can make it clear to the user that laggproto is not the one they requested,
> I'm open to ideas?
>
> Regards
> Steve
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Eugene Grosbein
05.01.2018 6:37, Steven Hartland wrote:

> Our TCP stack seems fragile during setup to out of order packets 
> which this multipath behavior causes, we've seen this on our loadbalancers
> which is what triggered the investigation. The concrete result is many 
> aborted TCP connections,
> over 300k ~2% on the machine I'm looking at.

This is another problem that needs to be fixed in general and not hidden under 
the carpet.
Meantime, practical problems you see can be solved locally with any settings 
you like.

> I hope there's some improvements that can be made, for example if we can 
> determine
> the stream was instigated remotely then flowid would always be valid hence we 
> can use it assuming it
> matches the requested spec or if we can make it clear to the user that 
> laggproto is not the one they requested, I'm open to ideas?

We just need to clear flow id from incoming TCP segments and always generate 
new flow id for responses
keeping old flow id for IP forwarding case. Please back out your change to not 
degrade IP forwarding performance.



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


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Eugene Grosbein
05.01.2018 4:52, Steven Hartland wrote:

>> RSS by definition has meaning to received stream. What is "outbound" stream
>> in this context, why can the hash calculatiom method change and what exactly
>> does it mean "a stream being incorrectly split"?
> Yes RSS is indeed a received stream but that is used by lagg for lacp and 
> loadbalance protocols
> to decide which port of the lagg to "send" the packet out of.
> As the flowid is not known when a new "output" stream is instigated the 
> current code 
> falls back to manual hash calculation to determine which port to send the 
> initial packet from.
> Once a response is received a tx then uses the flowid.
> This change of hash calculation method can result in the initial packet being 
> sent
> from a different port than the rest of the stream; this is what I meant by 
> "incorrectly split".
> 
> See the following:
> https://github.com/freebsd/freebsd/blob/master/sys/net/if_lagg.c#L2066
> https://github.com/freebsd/freebsd/blob/master/sys/net/ieee8023ad_lacp.c#L846

I still do not get what is "output stream" for you.

If you are talking on forwarding (routing) transit packets at IP layer,
they all have flowid from the beginning and first packet does not differ from 
others at all.

If you are talking on locally originated (not transit) data streem from local 
TCP socket
being sent in response to corresponding incoming TCP segments, then these 
outgoing
packets should have their own fixed flow id by default in case of LACP
and thhis flow id should not depend on (possibly ever changing) flow id of 
incoming TCP segments.

If you insist that flow id of outgoing packets does depend on ever changing 
incoming packet's flow id,
then this is the bug that should be fixed and not lagg's defaults.

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


svn commit: r327567 - head/usr.bin/hexdump

2018-01-04 Thread Kyle Evans
Author: kevans
Date: Fri Jan  5 01:46:41 2018
New Revision: 327567
URL: https://svnweb.freebsd.org/changeset/base/327567

Log:
  hexdump(1): Speed up -s flag on devices
  
  Using the -s flag on devices is extraordinarily slow due to using fseek(3) a
  little too conservatively. Address this by using fseek on character/block
  devices as well, falling back to getchar(3) only if we fail to seek or we're
  operating on tape drives, where fseek may succeed while not actually being
  supported.
  
  PR:   86485
  Submitted by: arundel (originally; modified since then)
  Reviewed by:  cem
  Differential Revision:https://reviews.freebsd.org/D10939

Modified:
  head/usr.bin/hexdump/display.c

Modified: head/usr.bin/hexdump/display.c
==
--- head/usr.bin/hexdump/display.c  Thu Jan  4 23:07:51 2018
(r327566)
+++ head/usr.bin/hexdump/display.c  Fri Jan  5 01:46:41 2018
(r327567)
@@ -39,6 +39,8 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -57,6 +59,7 @@ static off_t address; /* address/offset in 
stream */
 static off_t eaddress; /* end address */
 
 static void print(PR *, u_char *);
+static void noseek(void);
 
 void
 display(void)
@@ -386,7 +389,7 @@ next(char **argv)
 void
 doskip(const char *fname, int statok)
 {
-   int cnt;
+   int type;
struct stat sb;
 
if (statok) {
@@ -398,16 +401,37 @@ doskip(const char *fname, int statok)
return;
}
}
-   if (statok && S_ISREG(sb.st_mode)) {
-   if (fseeko(stdin, skip, SEEK_SET))
+   if (!statok || S_ISFIFO(sb.st_mode) || S_ISSOCK(sb.st_mode)) {
+   noseek();
+   return;
+   }
+   if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) {
+   if (ioctl(fileno(stdin), FIODTYPE, ))
err(1, "%s", fname);
-   address += skip;
-   skip = 0;
-   } else {
-   for (cnt = 0; cnt < skip; ++cnt)
-   if (getchar() == EOF)
-   break;
-   address += cnt;
-   skip -= cnt;
+   /*
+* Most tape drives don't support seeking,
+* yet fseek() would succeed.
+*/
+   if (type & D_TAPE) {
+   noseek();
+   return;
+   }
}
+   if (fseeko(stdin, skip, SEEK_SET)) {
+   noseek();
+   return;
+   }
+   address += skip;
+   skip = 0;
+}
+
+static void
+noseek(void)
+{
+   int count;
+   for (count = 0; count < skip; ++count)
+   if (getchar() == EOF)
+   break;
+   address += count;
+   skip -= count;
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Steven Hartland



On 04/01/2018 22:42, hiren panchasara wrote:

On 01/04/18 at 09:52P, Steven Hartland wrote:

On 04/01/2018 20:50, Eugene Grosbein wrote:

05.01.2018 3:05, Steven Hartland wrote:


Author: smh
Date: Thu Jan  4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559

Log:
Disabled the use of flowid for lagg by default

Disabled the use of RSS hash from the network card aka flowid for

lagg(4) interfaces by default as it's currently incompatible with
the lacp and loadbalance protocols.

The incompatibility is due to the fact that the flowid isn't know

for the first packet of a new outbound stream which can result in
the hash calculation method changing and hence a stream being
incorrectly split across multiple interfaces during normal
operation.

This can be re-enabled by setting the following in loader.conf:

net.link.lagg.default_use_flowid="1"

Discussed with: kmacy

Sponsored by:   Multiplay

RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom method change and what exactly
does it mean "a stream being incorrectly split"?

Yes RSS is indeed a received stream but that is used by lagg for lacp
and loadbalance protocols to decide which port of the lagg to "send" the
packet out of. As the flowid is not known when a new "output" stream is
instigated the current code falls back to manual hash calculation to
determine which port to send the initial packet from. Once a response is
received a tx then uses the flowid. This change of hash calculation
method can result in the initial packet being sent from a different port
than the rest of the stream; this is what I meant by "incorrectly split".

For my understanding, is this just an issue for the first packet when we
originate the flow? Once we have a response and if flowid is there, we'd
use it, right? OR am I missing something?
Initially yes, but that can cause a whole cascading set of problems. If 
the source machine sends from two different ports then flow can traverse 
across the network using different paths and hence arrive at the 
destination on different ports too, causing the corresponding  issue on 
the other side.

And with this change, we'd always go and do manual calculation even when
we have a valid flowid (i.e. we didn't initiate a connection)?
Correct, but there's potentially no easy way to correctly determine what 
the flowid and hence hash should be in this case, likely impossible if 
the lagg consists of different interface types.


In addition if the hardware hash doesn't match the requested one as per 
laggproto then additional issues could also be triggered.


Our TCP stack seems fragile during setup to out of order packets which 
this multipath behavior causes, we've seen this on our loadbalancers 
which is what triggered the investigation. The concrete result is many 
aborted TCP connections, over 300k ~2% on the machine I'm looking at.


I hope there's some improvements that can be made, for example if we can 
determine the stream was instigated remotely then flowid would always be 
valid hence we can use it assuming it matches the requested spec or if 
we can make it clear to the user that laggproto is not the one they 
requested, I'm open to ideas?


    Regards
    Steve

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


svn commit: r327566 - head/sys/powerpc/pseries

2018-01-04 Thread Nathan Whitehorn
Author: nwhitehorn
Date: Thu Jan  4 23:07:51 2018
New Revision: 327566
URL: https://svnweb.freebsd.org/changeset/base/327566

Log:
  Revert r327360, which can cause boot problems on high-CPU-count (>60)
  POWER8 and POWER9 systems, pending further analysis.
  
  PR:   224841

Modified:
  head/sys/powerpc/pseries/platform_chrp.c

Modified: head/sys/powerpc/pseries/platform_chrp.c
==
--- head/sys/powerpc/pseries/platform_chrp.cThu Jan  4 22:59:24 2018
(r327565)
+++ head/sys/powerpc/pseries/platform_chrp.cThu Jan  4 23:07:51 2018
(r327566)
@@ -114,8 +114,6 @@ static platform_def_t chrp_platform = {
 
 PLATFORM_DEF(chrp_platform);
 
-#define BSP_MUST_BE_CPU_ZERO
-
 static int
 chrp_probe(platform_t plat)
 {
@@ -281,31 +279,13 @@ chrp_real_maxaddr(platform_t plat)
 static u_long
 chrp_timebase_freq(platform_t plat, struct cpuref *cpuref)
 {
-   char buf[8];
-   phandle_t cpu, dev, root;
-   int res;
+   phandle_t phandle;
int32_t ticks = -1;
 
-   root = OF_peer(0);
+   phandle = cpuref->cr_hwref;
 
-   dev = OF_child(root);
-   while (dev != 0) {
-   res = OF_getprop(dev, "name", buf, sizeof(buf));
-   if (res > 0 && strcmp(buf, "cpus") == 0)
-   break;
-   dev = OF_peer(dev);
-   }
+   OF_getencprop(phandle, "timebase-frequency", , sizeof(ticks));
 
-   for (cpu = OF_child(dev); cpu != 0; cpu = OF_peer(cpu)) {
-   res = OF_getprop(cpu, "device_type", buf, sizeof(buf));
-   if (res > 0 && strcmp(buf, "cpu") == 0)
-   break;
-   }
-   if (cpu == 0)
-   return (51200);
-
-   OF_getencprop(cpu, "timebase-frequency", , sizeof(ticks));
-
if (ticks <= 0)
panic("Unable to determine timebase frequency!");
 
@@ -313,11 +293,11 @@ chrp_timebase_freq(platform_t plat, struct cpuref *cpu
 }
 
 static int
-chrp_cpuref_for_server(struct cpuref *cpuref, int cpu_n, int server)
+chrp_smp_first_cpu(platform_t plat, struct cpuref *cpuref)
 {
char buf[8];
phandle_t cpu, dev, root;
-   int res, cpuid, i, j;
+   int res, cpuid;
 
root = OF_peer(0);
 
@@ -338,84 +318,71 @@ chrp_cpuref_for_server(struct cpuref *cpuref, int cpu_
return (ENOENT);
}
 
-   i = 0;
-   for (cpu = OF_child(dev); cpu != 0; cpu = OF_peer(cpu)) {
-   res = OF_getprop(cpu, "device_type", buf, sizeof(buf));
-   if (res <= 0 || strcmp(buf, "cpu") != 0)
-   continue;
+   cpu = OF_child(dev);
 
-   res = OF_getproplen(cpu, "ibm,ppc-interrupt-server#s");
-   if (res > 0) {
-   cell_t interrupt_servers[res/sizeof(cell_t)];
-   OF_getencprop(cpu, "ibm,ppc-interrupt-server#s",
-   interrupt_servers, res);
-   for (j = 0; j < res/sizeof(cell_t); j++) {
-   cpuid = interrupt_servers[j];
-   if (server != -1 && cpuid == server)
-   break;
-   if (cpu_n != -1 && cpu_n == i)
-   break;
-   i++;
-   }
-
-   if (j != res/sizeof(cell_t))
-   break;
-   } else {
-   res = OF_getencprop(cpu, "reg", , sizeof(cpuid));
-   if (res <= 0)
-   cpuid = 0;
-   if (server != -1 && cpuid == server)
-   break;
-   if (cpu_n != -1 && cpu_n == i)
-   break;
-   i++;
-   }
+   while (cpu != 0) {
+   res = OF_getprop(cpu, "device_type", buf, sizeof(buf));
+   if (res > 0 && strcmp(buf, "cpu") == 0)
+   break;
+   cpu = OF_peer(cpu);
}
-
if (cpu == 0)
return (ENOENT);
 
-   cpuref->cr_hwref = cpuid;
-   cpuref->cr_cpuid = i;
+   cpuref->cr_hwref = cpu;
+   res = OF_getencprop(cpu, "ibm,ppc-interrupt-server#s", ,
+   sizeof(cpuid));
+   if (res <= 0)
+   res = OF_getencprop(cpu, "reg", , sizeof(cpuid));
+   if (res <= 0)
+   cpuid = 0;
+   cpuref->cr_cpuid = cpuid;
 
return (0);
 }
 
 static int
-chrp_smp_first_cpu(platform_t plat, struct cpuref *cpuref)
-{
-#ifdef BSP_MUST_BE_CPU_ZERO
-   return (chrp_smp_get_bsp(plat, cpuref));
-#else
-   return (chrp_cpuref_for_server(cpuref, 0, -1));
-#endif
-}
-
-static int
 chrp_smp_next_cpu(platform_t plat, struct cpuref *cpuref)
 {
-#ifdef BSP_MUST_BE_CPU_ZERO
-   int bsp, ncpus, err;
-   struct 

svn commit: r327565 - head/usr.bin/find/tests

2018-01-04 Thread Jilles Tjoelker
Author: jilles
Date: Thu Jan  4 22:59:24 2018
New Revision: 327565
URL: https://svnweb.freebsd.org/changeset/base/327565

Log:
  find: Speed up tests by using touch -d instead of sleep for timestamps
  
  I have verified that the tests still detect the absence of the r327362 fix.

Modified:
  head/usr.bin/find/tests/find_test.sh

Modified: head/usr.bin/find/tests/find_test.sh
==
--- head/usr.bin/find/tests/find_test.shThu Jan  4 22:38:01 2018
(r327564)
+++ head/usr.bin/find/tests/find_test.shThu Jan  4 22:59:24 2018
(r327565)
@@ -36,10 +36,9 @@ find_newer_link_body()
 {
atf_check -s exit:0 mkdir test
atf_check -s exit:0 ln -s file1 test/link
-   atf_check -s exit:0 sleep 1.1
-   atf_check -s exit:0 touch test/file2
-   atf_check -s exit:0 sleep 1.1
-   atf_check -s exit:0 touch test/file1
+   atf_check -s exit:0 touch -d 2017-12-31T10:00:00Z -h test/link
+   atf_check -s exit:0 touch -d 2017-12-31T11:00:00Z test/file2
+   atf_check -s exit:0 touch -d 2017-12-31T12:00:00Z test/file1
 
# find(1) should evaluate 'link' as a symlink rather than its target
# (with -P / without -L flags).  Since link was created first, the
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread hiren panchasara
On 01/04/18 at 09:52P, Steven Hartland wrote:
> On 04/01/2018 20:50, Eugene Grosbein wrote:
> > 05.01.2018 3:05, Steven Hartland wrote:
> >
> >> Author: smh
> >> Date: Thu Jan  4 20:05:47 2018
> >> New Revision: 327559
> >> URL: https://svnweb.freebsd.org/changeset/base/327559
> >>
> >> Log:
> >>Disabled the use of flowid for lagg by default
> >>
> >>Disabled the use of RSS hash from the network card aka flowid for
> >>lagg(4) interfaces by default as it's currently incompatible with
> >>the lacp and loadbalance protocols.
> >>
> >>The incompatibility is due to the fact that the flowid isn't know
> >>for the first packet of a new outbound stream which can result in
> >>the hash calculation method changing and hence a stream being
> >>incorrectly split across multiple interfaces during normal
> >>operation.
> >>
> >>This can be re-enabled by setting the following in loader.conf:
> >>net.link.lagg.default_use_flowid="1"
> >>
> >>Discussed with: kmacy
> >>Sponsored by:   Multiplay
> > RSS by definition has meaning to received stream. What is "outbound" stream
> > in this context, why can the hash calculatiom method change and what exactly
> > does it mean "a stream being incorrectly split"?
> Yes RSS is indeed a received stream but that is used by lagg for lacp 
> and loadbalance protocols to decide which port of the lagg to "send" the 
> packet out of. As the flowid is not known when a new "output" stream is 
> instigated the current code falls back to manual hash calculation to 
> determine which port to send the initial packet from. Once a response is 
> received a tx then uses the flowid. This change of hash calculation 
> method can result in the initial packet being sent from a different port 
> than the rest of the stream; this is what I meant by "incorrectly split".

For my understanding, is this just an issue for the first packet when we
originate the flow? Once we have a response and if flowid is there, we'd
use it, right? OR am I missing something? 

And with this change, we'd always go and do manual calculation even when
we have a valid flowid (i.e. we didn't initiate a connection)?

Thanks,
Hiren
> 
> See the following:
> https://github.com/freebsd/freebsd/blob/master/sys/net/if_lagg.c#L2066
> https://github.com/freebsd/freebsd/blob/master/sys/net/ieee8023ad_lacp.c#L846
> 
> > Defaults should not be changed so easily just because they are not optimal
> > for some specific case. Each lagg has its own setting for flowid usage
> > and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases?
> >
> Yes we're already using -use_flowid to mitigate the problem, but the 
> defaults should never result in broken behavior hence the change, at 
> least for now.
> 
> For reference I did look at keeping the default of 1 but only using that 
> for protocols which weren't effected by the issue, and introducing a 2 
> to force those that are, but as its defined as acting on creation and we 
> always create lagg interfaces as failover and then amend them that 
> wasn't possible without making more invasive changes.
> 
>  ??? Regards
>  ??? Steve


pgpAnCnco5U0Y.pgp
Description: PGP signature


svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf

2018-01-04 Thread Kyle Evans
Author: kevans
Date: Thu Jan  4 22:37:15 2018
New Revision: 327563
URL: https://svnweb.freebsd.org/changeset/base/327563

Log:
  if_awg: Use syscon prop if it exists
  
  The emac bindings that are landing in Linux 4.15 specify a syscon property
  on the emac node that point to /soc/syscon. Use this property if it's
  specified, but maintain backwards compatibility with the old method.
  
  The older method is still used for boards that we get .dtb from u-boot, such
  as pine64, that did not yet have stable emac bindings.
  
  Tested on:Banana Pi-M3 (a83t)
  Tested on:Pine64 (a64)
  Reviewed by:  manu
  Differential Revision:https://reviews.freebsd.org/D13296

Modified:
  head/sys/arm/allwinner/files.allwinner
  head/sys/arm/allwinner/if_awg.c
  head/sys/arm/conf/GENERIC
  head/sys/arm64/conf/GENERIC
  head/sys/conf/files.arm64

Modified: head/sys/arm/allwinner/files.allwinner
==
--- head/sys/arm/allwinner/files.allwinner  Thu Jan  4 22:07:58 2018
(r327562)
+++ head/sys/arm/allwinner/files.allwinner  Thu Jan  4 22:37:15 2018
(r327563)
@@ -20,7 +20,7 @@ arm/allwinner/aw_usbphy.c optionalehci | 
ohci
 arm/allwinner/aw_wdog.cstandard
 arm/allwinner/axp209.c optionalaxp209
 arm/allwinner/axp81x.c optionalaxp81x
-arm/allwinner/if_awg.c optionalawg
+arm/allwinner/if_awg.c optionalawg ext_resources syscon
 arm/allwinner/if_emac.coptionalemac
 arm/allwinner/sunxi_dma_if.m   standard
 dev/iicbus/twsi/a10_twsi.c optionaltwsi

Modified: head/sys/arm/allwinner/if_awg.c
==
--- head/sys/arm/allwinner/if_awg.c Thu Jan  4 22:07:58 2018
(r327562)
+++ head/sys/arm/allwinner/if_awg.c Thu Jan  4 22:37:15 2018
(r327563)
@@ -69,7 +69,9 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
+#include "syscon_if.h"
 #include "miibus_if.h"
 #include "gpio_if.h"
 
@@ -105,6 +107,7 @@ __FBSDID("$FreeBSD$");
 #defineRX_BATCH_DEFAULT64
 
 /* syscon EMAC clock register */
+#defineEMAC_CLK_REG0x30
 #defineEMAC_CLK_EPHY_ADDR  (0x1f << 20)/* H3 */
 #defineEMAC_CLK_EPHY_ADDR_SHIFT 20
 #defineEMAC_CLK_EPHY_LED_POL   (1 << 17)   /* H3 */
@@ -203,6 +206,7 @@ struct awg_softc {
int link;
int if_flags;
enum awg_type   type;
+   struct syscon   *syscon;
 
struct awg_txring   tx;
struct awg_rxring   rx;
@@ -217,6 +221,9 @@ static struct resource_spec awg_spec[] = {
 
 static void awg_txeof(struct awg_softc *sc);
 
+static uint32_t syscon_read_emac_clk_reg(device_t dev);
+static void syscon_write_emac_clk_reg(device_t dev, uint32_t val);
+
 static int
 awg_miibus_readreg(device_t dev, int phy, int reg)
 {
@@ -1153,6 +1160,32 @@ awg_ioctl(if_t ifp, u_long cmd, caddr_t data)
return (error);
 }
 
+static uint32_t
+syscon_read_emac_clk_reg(device_t dev)
+{
+   struct awg_softc *sc;
+
+   sc = device_get_softc(dev);
+   if (sc->syscon != NULL)
+   return (SYSCON_READ_4(sc->syscon, EMAC_CLK_REG));
+   else if (sc->res[_RES_SYSCON] != NULL)
+   return (bus_read_4(sc->res[_RES_SYSCON], 0));
+
+   return (0);
+}
+
+static void
+syscon_write_emac_clk_reg(device_t dev, uint32_t val)
+{
+   struct awg_softc *sc;
+
+   sc = device_get_softc(dev);
+   if (sc->syscon != NULL)
+   SYSCON_WRITE_4(sc->syscon, EMAC_CLK_REG, val);
+   else if (sc->res[_RES_SYSCON] != NULL)
+   bus_write_4(sc->res[_RES_SYSCON], 0, val);
+}
+
 static int
 awg_setup_phy(device_t dev)
 {
@@ -1163,19 +1196,31 @@ awg_setup_phy(device_t dev)
phandle_t node;
uint32_t reg, tx_delay, rx_delay;
int error;
+   bool use_syscon;
 
sc = device_get_softc(dev);
node = ofw_bus_get_node(dev);
+   use_syscon = false;
 
if (OF_getprop_alloc(node, "phy-mode", 1, (void **)_type) == 0)
return (0);
 
+   if (sc->syscon != NULL || sc->res[_RES_SYSCON] != NULL)
+   use_syscon = true;
+
if (bootverbose)
device_printf(dev, "PHY type: %s, conf mode: %s\n", phy_type,
-   sc->res[_RES_SYSCON] != NULL ? "reg" : "clk");
+   use_syscon ? "reg" : "clk");
 
-   if (sc->res[_RES_SYSCON] != NULL) {
-   reg = bus_read_4(sc->res[_RES_SYSCON], 0);
+   if (use_syscon) {
+   /*
+* Abstract away writing to syscon for devices like the pine64.
+* For the pine64, we get dtb from U-Boot and it still uses the
+* legacy 

svn commit: r327562 - head/sys/kern

2018-01-04 Thread John Baldwin
Author: jhb
Date: Thu Jan  4 22:07:58 2018
New Revision: 327562
URL: https://svnweb.freebsd.org/changeset/base/327562

Log:
  Always use atomic_fetchadd() when updating per-user accounting values.
  
  This avoids re-reading a variable after it has been updated via an
  atomic op.  It is just a cosmetic cleanup as the read value was only
  used to control a diagnostic printf that should rarely occur (if ever).
  
  Reviewed by:  kib
  Differential Revision:https://reviews.freebsd.org/D13768

Modified:
  head/sys/kern/kern_resource.c

Modified: head/sys/kern/kern_resource.c
==
--- head/sys/kern/kern_resource.c   Thu Jan  4 21:59:34 2018
(r327561)
+++ head/sys/kern/kern_resource.c   Thu Jan  4 22:07:58 2018
(r327562)
@@ -1384,18 +1384,17 @@ ui_racct_foreach(void (*callback)(struct racct *racct,
 static inline int
 chglimit(struct uidinfo *uip, long *limit, int diff, rlim_t max, const char 
*name)
 {
+   long new;
 
/* Don't allow them to exceed max, but allow subtraction. */
+   new = atomic_fetchadd_long(limit, (long)diff) + diff;
if (diff > 0 && max != 0) {
-   if (atomic_fetchadd_long(limit, (long)diff) + diff > max) {
+   if (new < 0 || new > max) {
atomic_subtract_long(limit, (long)diff);
return (0);
}
-   } else {
-   atomic_add_long(limit, (long)diff);
-   if (*limit < 0)
-   printf("negative %s for uid = %d\n", name, uip->ui_uid);
-   }
+   } else if (new < 0)
+   printf("negative %s for uid = %d\n", name, uip->ui_uid);
return (1);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327561 - head/sys/kern

2018-01-04 Thread John Baldwin
Author: jhb
Date: Thu Jan  4 21:59:34 2018
New Revision: 327561
URL: https://svnweb.freebsd.org/changeset/base/327561

Log:
  Report offset relative to the backing object for kinfo_vmentry structures.
  
  For the pathname reported in kinfo_vmentry structures (kve_path), the
  sysctl handlers walk the object chain to find the bottom-most VM object.
  This permits a COW mapping of a file with dirty pages to report the
  pathname of the originally mapped file.  Do the same for the object
  offset (kve_offset) computing a cumulative offset during the same object
  walk so that the reported offset is relative to the reported pathname.
  
  Note that ptrace(PT_VM_ENTRY) already returns a cumulative offset
  rather than the raw offset of the VM map entry.
  
  Note also that this does not affect procstat -v output (even structured
  output) since that output does not include the kve_offset field.
  
  Reviewed by:  kib
  MFC after:2 weeks
  Sponsored by: DARPA / AFRL
  Differential Revision:https://reviews.freebsd.org/D13767

Modified:
  head/sys/kern/kern_proc.c

Modified: head/sys/kern/kern_proc.c
==
--- head/sys/kern/kern_proc.c   Thu Jan  4 21:57:37 2018(r327560)
+++ head/sys/kern/kern_proc.c   Thu Jan  4 21:59:34 2018(r327561)
@@ -2159,8 +2159,10 @@ sysctl_kern_proc_ovmmap(SYSCTL_HANDLER_ARGS)
}
 
for (lobj = tobj = obj; tobj; tobj = tobj->backing_object) {
-   if (tobj != obj)
+   if (tobj != obj) {
VM_OBJECT_RLOCK(tobj);
+   kve->kve_offset += tobj->backing_object_offset;
+   }
if (lobj != obj)
VM_OBJECT_RUNLOCK(lobj);
lobj = tobj;
@@ -2168,7 +2170,7 @@ sysctl_kern_proc_ovmmap(SYSCTL_HANDLER_ARGS)
 
kve->kve_start = (void*)entry->start;
kve->kve_end = (void*)entry->end;
-   kve->kve_offset = (off_t)entry->offset;
+   kve->kve_offset += (off_t)entry->offset;
 
if (entry->protection & VM_PROT_READ)
kve->kve_protection |= KVME_PROT_READ;
@@ -2389,6 +2391,7 @@ kern_proc_vmmap_out(struct proc *p, struct sbuf *sb, s
for (tobj = obj; tobj != NULL;
tobj = tobj->backing_object) {
VM_OBJECT_RLOCK(tobj);
+   kve->kve_offset += tobj->backing_object_offset;
lobj = tobj;
}
if (obj->backing_object == NULL)
@@ -2409,7 +2412,7 @@ kern_proc_vmmap_out(struct proc *p, struct sbuf *sb, s
 
kve->kve_start = entry->start;
kve->kve_end = entry->end;
-   kve->kve_offset = entry->offset;
+   kve->kve_offset += entry->offset;
 
if (entry->protection & VM_PROT_READ)
kve->kve_protection |= KVME_PROT_READ;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327560 - in head/sys/compat: cloudabi cloudabi32 cloudabi64

2018-01-04 Thread Ed Schouten
Author: ed
Date: Thu Jan  4 21:57:37 2018
New Revision: 327560
URL: https://svnweb.freebsd.org/changeset/base/327560

Log:
  Allow timed waits with relative timeouts on locks and condvars.
  
  Even though pthreads doesn't support this, there are various alternative
  APIs that use this. For example, uv_cond_timedwait() accepts a relative
  timeout. So does Rust's std::sync::Condvar::wait_timeout().
  
  Though I personally think that relative timeouts are bad (due to
  imprecision for repeated operations), it does seem that people want
  this. Extend the existing futex functions to keep track of whether an
  absolute timeout is used in a boolean flag.
  
  MFC after:1 month

Modified:
  head/sys/compat/cloudabi/cloudabi_futex.c
  head/sys/compat/cloudabi/cloudabi_util.h
  head/sys/compat/cloudabi32/cloudabi32_poll.c
  head/sys/compat/cloudabi64/cloudabi64_poll.c

Modified: head/sys/compat/cloudabi/cloudabi_futex.c
==
--- head/sys/compat/cloudabi/cloudabi_futex.c   Thu Jan  4 20:05:47 2018
(r327559)
+++ head/sys/compat/cloudabi/cloudabi_futex.c   Thu Jan  4 21:57:37 2018
(r327560)
@@ -197,7 +197,7 @@ static void futex_queue_requeue(struct futex_queue *, 
 unsigned int);
 static int futex_queue_sleep(struct futex_queue *, struct futex_lock *,
 struct futex_waiter *, struct thread *, cloudabi_clockid_t,
-cloudabi_timestamp_t, cloudabi_timestamp_t);
+cloudabi_timestamp_t, cloudabi_timestamp_t, bool);
 static cloudabi_tid_t futex_queue_tid_best(const struct futex_queue *);
 static void futex_queue_wake_up_all(struct futex_queue *);
 static void futex_queue_wake_up_best(struct futex_queue *);
@@ -427,7 +427,7 @@ futex_lock_lookup_locked(struct futex_address *fa)
 static int
 futex_lock_rdlock(struct futex_lock *fl, struct thread *td,
 cloudabi_lock_t *lock, cloudabi_clockid_t clock_id,
-cloudabi_timestamp_t timeout, cloudabi_timestamp_t precision)
+cloudabi_timestamp_t timeout, cloudabi_timestamp_t precision, bool abstime)
 {
struct futex_waiter fw;
int error;
@@ -438,7 +438,7 @@ futex_lock_rdlock(struct futex_lock *fl, struct thread
KASSERT(fl->fl_owner != LOCK_UNMANAGED,
("Attempted to sleep on an unmanaged lock"));
error = futex_queue_sleep(>fl_readers, fl, , td,
-   clock_id, timeout, precision);
+   clock_id, timeout, precision, abstime);
KASSERT((error == 0) == fw.fw_locked,
("Should have locked write lock on success"));
KASSERT(futex_queue_count(_donated) == 0,
@@ -707,7 +707,7 @@ futex_lock_wake_up_next(struct futex_lock *fl, cloudab
 static int
 futex_lock_wrlock(struct futex_lock *fl, struct thread *td,
 cloudabi_lock_t *lock, cloudabi_clockid_t clock_id,
-cloudabi_timestamp_t timeout, cloudabi_timestamp_t precision,
+cloudabi_timestamp_t timeout, cloudabi_timestamp_t precision, bool abstime,
 struct futex_queue *donated)
 {
struct futex_waiter fw;
@@ -735,7 +735,7 @@ futex_lock_wrlock(struct futex_lock *fl, struct thread
KASSERT(fl->fl_owner != LOCK_UNMANAGED,
("Attempted to sleep on an unmanaged lock"));
error = futex_queue_sleep(>fl_writers, fl, , td,
-   clock_id, timeout, precision);
+   clock_id, timeout, precision, abstime);
KASSERT((error == 0) == fw.fw_locked,
("Should have locked write lock on success"));
KASSERT(futex_queue_count(_donated) == 0,
@@ -789,16 +789,18 @@ futex_queue_convert_timestamp_relative(cloudabi_timest
 static int
 futex_queue_convert_timestamp(struct thread *td, cloudabi_clockid_t clock_id,
 cloudabi_timestamp_t timeout, cloudabi_timestamp_t precision,
-sbintime_t *sbttimeout, sbintime_t *sbtprecision)
+sbintime_t *sbttimeout, sbintime_t *sbtprecision, bool abstime)
 {
cloudabi_timestamp_t now;
int error;
 
-   /* Make the time relative. */
-   error = cloudabi_clock_time_get(td, clock_id, );
-   if (error != 0)
-   return (error);
-   timeout = timeout < now ? 0 : timeout - now;
+   if (abstime) {
+   /* Make the time relative. */
+   error = cloudabi_clock_time_get(td, clock_id, );
+   if (error != 0)
+   return (error);
+   timeout = timeout < now ? 0 : timeout - now;
+   }
 
*sbttimeout = futex_queue_convert_timestamp_relative(timeout);
*sbtprecision = futex_queue_convert_timestamp_relative(precision);
@@ -808,7 +810,7 @@ futex_queue_convert_timestamp(struct thread *td, cloud
 static int
 futex_queue_sleep(struct futex_queue *fq, struct futex_lock *fl,
 struct futex_waiter *fw, struct thread *td, cloudabi_clockid_t clock_id,
-cloudabi_timestamp_t timeout, cloudabi_timestamp_t 

Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Steven Hartland

On 04/01/2018 20:50, Eugene Grosbein wrote:

05.01.2018 3:05, Steven Hartland wrote:


Author: smh
Date: Thu Jan  4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559

Log:
   Disabled the use of flowid for lagg by default
   
   Disabled the use of RSS hash from the network card aka flowid for

   lagg(4) interfaces by default as it's currently incompatible with
   the lacp and loadbalance protocols.
   
   The incompatibility is due to the fact that the flowid isn't know

   for the first packet of a new outbound stream which can result in
   the hash calculation method changing and hence a stream being
   incorrectly split across multiple interfaces during normal
   operation.
   
   This can be re-enabled by setting the following in loader.conf:

   net.link.lagg.default_use_flowid="1"
   
   Discussed with: kmacy

   Sponsored by:Multiplay

RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom method change and what exactly
does it mean "a stream being incorrectly split"?
Yes RSS is indeed a received stream but that is used by lagg for lacp 
and loadbalance protocols to decide which port of the lagg to "send" the 
packet out of. As the flowid is not known when a new "output" stream is 
instigated the current code falls back to manual hash calculation to 
determine which port to send the initial packet from. Once a response is 
received a tx then uses the flowid. This change of hash calculation 
method can result in the initial packet being sent from a different port 
than the rest of the stream; this is what I meant by "incorrectly split".


See the following:
https://github.com/freebsd/freebsd/blob/master/sys/net/if_lagg.c#L2066
https://github.com/freebsd/freebsd/blob/master/sys/net/ieee8023ad_lacp.c#L846


Defaults should not be changed so easily just because they are not optimal
for some specific case. Each lagg has its own setting for flowid usage
and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases?

Yes we're already using -use_flowid to mitigate the problem, but the 
defaults should never result in broken behavior hence the change, at 
least for now.


For reference I did look at keeping the default of 1 but only using that 
for protocols which weren't effected by the issue, and introducing a 2 
to force those that are, but as its defined as acting on creation and we 
always create lagg interfaces as failover and then amend them that 
wasn't possible without making more invasive changes.


    Regards
    Steve
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Eugene Grosbein
05.01.2018 3:05, Steven Hartland wrote:

> Author: smh
> Date: Thu Jan  4 20:05:47 2018
> New Revision: 327559
> URL: https://svnweb.freebsd.org/changeset/base/327559
> 
> Log:
>   Disabled the use of flowid for lagg by default
>   
>   Disabled the use of RSS hash from the network card aka flowid for
>   lagg(4) interfaces by default as it's currently incompatible with
>   the lacp and loadbalance protocols.
>   
>   The incompatibility is due to the fact that the flowid isn't know
>   for the first packet of a new outbound stream which can result in
>   the hash calculation method changing and hence a stream being
>   incorrectly split across multiple interfaces during normal
>   operation.
>   
>   This can be re-enabled by setting the following in loader.conf:
>   net.link.lagg.default_use_flowid="1"
>   
>   Discussed with: kmacy
>   Sponsored by:   Multiplay

RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom method change and what exactly
does it mean "a stream being incorrectly split"?

Defaults should not be changed so easily just because they are not optimal
for some specific case. Each lagg has its own setting for flowid usage
and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases?


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


Re: svn commit: r327086 - head/sys/dev/lmc

2018-01-04 Thread Kurt Lidl

On 1/4/18 5:00 AM, Poul-Henning Kamp wrote:


In message <3f4a7247-e711-c65a-d973-c929ac872...@freebsd.org>, Stefan Esser 
writes:

Am 04.01.18 um 00:41 schrieb Pedro Giffuni:



It appears to be a strange beast that uses the Ethernet chip to generate a
bit stream which is then converted to HDLC. Not sure whether these were used
for Frame Relay or to connect to the British X.25 JANET, a few decades ago.
Perhaps also to connect to SS7 signaling networks?


They were actually pretty versatile, we used them both for "blank"
E1 and Nx64 scenarios, and I know they were used for Frame Relay
several places in US.

I don't think they could do SS7 or ISDN like the MUSYCC chip could.

But nobody uses T1/E1/T3/E3 lines any more for anything...


There's thousands upon thousands of customers that attach to networks
via T1 lines, running Frame-Relay to this day.  Granted, ADSL has
captured the consumer market, but NxT1 is still popular in the
business world.  (And pretty much all the T1s in the world are
actually delivered over 2Mmbps SDSL, which is then turned into the
1.544 mbps T1 interface, but that's not really germane to this...)

As for the lmc product itself, and that driver-  David Boggs, when
working at DEC-WRL (Dec's Western Research Lab) realized that the
Ethernet controller that ran the "de" Ethernet chips could be easily
plumbed into an FPGA and used as the front-end controller for the
framer for the serial line.

In 1999 I worked with David Boggs to modernize this driver (or more
precisely, the "sbe" version of it), so it had SMP locking for
FreeBSD and BSD/OS.  Dave is really easy to work with, and we were
able to make the driver deal with Frame Relay, in addition to the
"Cisco HDLC" (aka chdlc) framing.  I don't think we attempted to
get the synch PPP stuff working, as I only had access to a T1 line
with FR signaling on it.

T1 is just an electrical standard for interface, you can do all sorts
of different signaling and protocols over that interface.

I still have this hardware (but not in use), as well as a pair of
the HSSI boards (54mbps, suitable for use with a T3 circuit).

If you just want someone to test it, I can probably lash together
two machines with these cards as the interconnect.

-Kurt

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


svn commit: r327559 - in head: . sys/net

2018-01-04 Thread Steven Hartland
Author: smh
Date: Thu Jan  4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559

Log:
  Disabled the use of flowid for lagg by default
  
  Disabled the use of RSS hash from the network card aka flowid for
  lagg(4) interfaces by default as it's currently incompatible with
  the lacp and loadbalance protocols.
  
  The incompatibility is due to the fact that the flowid isn't know
  for the first packet of a new outbound stream which can result in
  the hash calculation method changing and hence a stream being
  incorrectly split across multiple interfaces during normal
  operation.
  
  This can be re-enabled by setting the following in loader.conf:
  net.link.lagg.default_use_flowid="1"
  
  Discussed with: kmacy
  Sponsored by: Multiplay

Modified:
  head/UPDATING
  head/sys/net/if_lagg.c

Modified: head/UPDATING
==
--- head/UPDATING   Thu Jan  4 19:47:01 2018(r327558)
+++ head/UPDATING   Thu Jan  4 20:05:47 2018(r327559)
@@ -51,6 +51,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
 
 ** SPECIAL WARNING: **
 
+20180104:
+   The use of RSS hash from the network card aka flowid has been
+   disabled by default for lagg(4) as it's currently incompatible with
+   the lacp and loadbalance protocols.
+
+   This can be re-enabled by setting the following in loader.conf:
+   net.link.lagg.default_use_flowid="1"
+
 20180102:
The SW_WATCHDOG option is no longer necessary to enable the
hardclock-based software watchdog if no hardware watchdog is

Modified: head/sys/net/if_lagg.c
==
--- head/sys/net/if_lagg.c  Thu Jan  4 19:47:01 2018(r327558)
+++ head/sys/net/if_lagg.c  Thu Jan  4 20:05:47 2018(r327559)
@@ -244,7 +244,7 @@ SYSCTL_INT(_net_link_lagg, OID_AUTO, failover_rx_all, 
 "Accept input from any interface in a failover lagg");
 
 /* Default value for using flowid */
-static VNET_DEFINE(int, def_use_flowid) = 1;
+static VNET_DEFINE(int, def_use_flowid) = 0;
 #defineV_def_use_flowidVNET(def_use_flowid)
 SYSCTL_INT(_net_link_lagg, OID_AUTO, default_use_flowid, CTLFLAG_RWTUN,
 _NAME(def_use_flowid), 0,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327558 - head/sys/dev/bhnd/cores/pmu

2018-01-04 Thread Landon J. Fuller
Author: landonf
Date: Thu Jan  4 19:47:01 2018
New Revision: 327558
URL: https://svnweb.freebsd.org/changeset/base/327558

Log:
  bhnd(4): Add missing BCM4312 backplane clock speed entry.
  
  The default 80MHz clock speed returned by bhnd_pmu_si_clock() was already
  correct; this just prevents the "No backplane clock specified" warning
  printf from being emitted when querying backplane clock speed.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/dev/bhnd/cores/pmu/bhnd_pmu_subr.c

Modified: head/sys/dev/bhnd/cores/pmu/bhnd_pmu_subr.c
==
--- head/sys/dev/bhnd/cores/pmu/bhnd_pmu_subr.c Thu Jan  4 19:43:42 2018
(r327557)
+++ head/sys/dev/bhnd/cores/pmu/bhnd_pmu_subr.c Thu Jan  4 19:47:01 2018
(r327558)
@@ -2394,6 +2394,7 @@ bhnd_pmu_si_clock(struct bhnd_pmu_query *sc)
clock = bhnd_pmu1_cpuclk0(sc);
break;
 
+   case BHND_CHIPID_BCM4312:
case BHND_CHIPID_BCM4313:
/* 80MHz backplane clock */
clock = 8 * 1000;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327555 - head/sys/vm

2018-01-04 Thread Konstantin Belousov
Author: kib
Date: Thu Jan  4 18:14:58 2018
New Revision: 327555
URL: https://svnweb.freebsd.org/changeset/base/327555

Log:
  Restructure swapout tests after vm map locking was removed.
  
  Consolidate the regions covered by the process lock.
  Combine similar conditions tests into one, e.g. all process flags can
  be test with one logical operation.
  Add check for in-exec state, since p_vmspace is dererenced.
  Remove labels and goto by explicitly tracking state.
  Update comments.
  
  Reviewed by:  alc, markj (previous version)
  Tested by:pho (previous version)
  Sponsored by: The FreeBSD Foundation
  MFC after:2 weeks
  Differential revision:https://reviews.freebsd.org/D13693

Modified:
  head/sys/vm/vm_swapout.c

Modified: head/sys/vm/vm_swapout.c
==
--- head/sys/vm/vm_swapout.cThu Jan  4 17:58:48 2018(r327554)
+++ head/sys/vm/vm_swapout.cThu Jan  4 18:14:58 2018(r327555)
@@ -734,126 +734,73 @@ swapout_procs(int action)
struct proc *p;
struct thread *td;
int slptime;
-   bool didswap;
+   bool didswap, doswap;
 
+   MPASS((action & (VM_SWAP_NORMAL | VM_SWAP_IDLE)) != 0);
+
didswap = false;
-retry:
sx_slock(_lock);
FOREACH_PROC_IN_SYSTEM(p) {
-   PROC_LOCK(p);
/*
-* Watch out for a process in
-* creation.  It may have no
-* address space or lock yet.
+* Filter out not yet fully constructed processes.  Do
+* not swap out held processes.  Avoid processes which
+* are system, exiting, execing, traced, already swapped
+* out or are in the process of being swapped in or out.
 */
-   if (p->p_state == PRS_NEW) {
+   PROC_LOCK(p);
+   if (p->p_state != PRS_NORMAL || p->p_lock != 0 || (p->p_flag &
+   (P_SYSTEM | P_WEXIT | P_INEXEC | P_STOPPED_SINGLE |
+   P_TRACED | P_SWAPPINGOUT | P_SWAPPINGIN | P_INMEM)) !=
+   P_INMEM) {
PROC_UNLOCK(p);
continue;
}
+
/*
-* An aio daemon switches its
-* address space while running.
-* Perform a quick check whether
-* a process has P_SYSTEM.
-* Filter out exiting processes.
+* Further consideration of this process for swap out
+* requires iterating over its threads.  We release
+* allproc_lock here so that process creation and
+* destruction are not blocked while we iterate.
+*
+* To later reacquire allproc_lock and resume
+* iteration over the allproc list, we will first have
+* to release the lock on the process.  We place a
+* hold on the process so that it remains in the
+* allproc list while it is unlocked.
 */
-   if ((p->p_flag & (P_SYSTEM | P_WEXIT)) != 0) {
-   PROC_UNLOCK(p);
-   continue;
-   }
_PHOLD_LITE(p);
-   PROC_UNLOCK(p);
sx_sunlock(_lock);
 
-   PROC_LOCK(p);
-   if (p->p_lock != 1 || (p->p_flag & (P_STOPPED_SINGLE |
-   P_TRACED | P_SYSTEM)) != 0)
-   goto nextproc;
-
/*
-* Only aiod changes vmspace.  However, it will be
-* skipped because of the if statement above checking 
-* for P_SYSTEM.
+* Do not swapout a realtime process.
+* Guarantee swap_idle_threshold1 time in memory.
+* If the system is under memory stress, or if we are
+* swapping idle processes >= swap_idle_threshold2,
+* then swap the process out.
 */
-   if ((p->p_flag & (P_INMEM | P_SWAPPINGOUT | P_SWAPPINGIN)) !=
-   P_INMEM)
-   goto nextproc;
-
-   switch (p->p_state) {
-   default:
-   /*
-* Don't swap out processes in any sort
-* of 'special' state.
-*/
-   break;
-
-   case PRS_NORMAL:
-   /*
-* do not swapout a realtime process
-* Check all the thread groups..
-*/
-   FOREACH_THREAD_IN_PROC(p, td) {
-   thread_lock(td);
-   if (PRI_IS_REALTIME(td->td_pri_class)) {
-   thread_unlock(td);
-   

svn commit: r327554 - head/share/misc

2018-01-04 Thread Jason Unovitch
Author: junovitch (ports committer)
Date: Thu Jan  4 17:58:48 2018
New Revision: 327554
URL: https://svnweb.freebsd.org/changeset/base/327554

Log:
  Remove myself from ports-secteam
  
  I will be moving on to other life commitments this year and will not have
  the time to support contributions as a ports committer, if able, until life
  settles at the end of the year.
  
  Discussed with:   portmgr

Modified:
  head/share/misc/organization.dot

Modified: head/share/misc/organization.dot
==
--- head/share/misc/organization.dotThu Jan  4 16:19:56 2018
(r327553)
+++ head/share/misc/organization.dotThu Jan  4 17:58:48 2018
(r327554)
@@ -34,7 +34,7 @@ portmgr [label="Port Management Team\nportmgr@FreeBSD.
 portmgrsecretary [label="Port Management Team 
Secretary\nportmgr-secret...@freebsd.org\nrene"]
 re [label="Primary Release Engineering Team\n...@freebsd.org\ngjb, 
kib,\nbdrewery, blackend,\nrgrimes, delphij,\nhrs, glebius,\nmarius, rwatson"]
 secteam [label="Security Team\nsect...@freebsd.org\ndelphij,\ndes, gavin, 
gjb,\nglebius, remko"]
-portssecteam [label="Ports Security Team\nports-sect...@freebsd.org\ndelphij, 
amdmi3, eadler, feld, jgh, junovitch, rea, sbz, simon, swills, zi"]
+portssecteam [label="Ports Security Team\nports-sect...@freebsd.org\ndelphij, 
amdmi3, eadler, feld, jgh, rea, sbz, simon, swills, zi"]
 secteamsecretary [label="Security Team 
Secretary\nsecteam-secret...@freebsd.org\nremko"]
 securityofficer [label="Security Officer 
Team\nsecurity-offi...@freebsd.org\ndelphij, des,\ngavin, gjb,\nglebius, remko"]
 srccommitters [label="Src Committers\nsrc-committ...@freebsd.org"]
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327086 - head/sys/dev/lmc

2018-01-04 Thread Warner Losh
On Wed, Jan 3, 2018 at 4:41 PM, Pedro Giffuni  wrote:

>
>
> On 03/01/2018 18:03, Warner Losh wrote:
>
>
>
> On Jan 3, 2018 3:17 PM, "Brooks Davis"  wrote:
>
> On Fri, Dec 22, 2017 at 05:15:02PM +, Pedro F. Giffuni wrote:
> > Author: pfg
> > Date: Fri Dec 22 17:15:02 2017
> > New Revision: 327086
> > URL: https://svnweb.freebsd.org/changeset/base/327086
> >
> > Log:
> >   SPDX: Reverse License ID tags from the lmc driver.
> >
> >   While the BSD-2-Clause license is there, the GPLv2 is also present.
> >   I am unsure of the implications of having both licenses as they are
> here.
> >
> >   I'll just leave it untagged and open for interpretation.
>
> Deleting lmc(4) is probably the appropriate fix.  You can buy the things
> on e-bay, but they look to be 32-bit PCI devices and it seems unlikely
> they are in use on systems that will run FreeBSD 12.  I've updated the
> wiki with a note to this effect.
>
>
> Which wiki?
>
>
> https://wiki.freebsd.org/GPLinBase
>

Ah, I was talking about deprecation, which we're really bad at
communicating. The ad-hoc methods we've used aren't so easy for users to
follow. I'll send a followup on that in a new thread.

Warner


>
> I'd like to formalize things a little.
>
>
> Either the license is very naively stated or the device should have been
> added in the contrib/gnu branches.
> I suspect the former but my attempts to contact the author were
> unsuccessful so it is probably better to just drop it.
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327086 - head/sys/dev/lmc

2018-01-04 Thread Poul-Henning Kamp

In message <3f4a7247-e711-c65a-d973-c929ac872...@freebsd.org>, Stefan Esser 
writes:
>Am 04.01.18 um 00:41 schrieb Pedro Giffuni:

>It appears to be a strange beast that uses the Ethernet chip to generate a
>bit stream which is then converted to HDLC. Not sure whether these were used
>for Frame Relay or to connect to the British X.25 JANET, a few decades ago.
>Perhaps also to connect to SS7 signaling networks?

They were actually pretty versatile, we used them both for "blank"
E1 and Nx64 scenarios, and I know they were used for Frame Relay
several places in US.

I don't think they could do SS7 or ISDN like the MUSYCC chip could.

But nobody uses T1/E1/T3/E3 lines any more for anything...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327086 - head/sys/dev/lmc

2018-01-04 Thread Stefan Esser
Am 04.01.18 um 00:41 schrieb Pedro Giffuni:
> Either the license is very naively stated or the device should have been added
> in the contrib/gnu branches.

This appears to be one of the dual-licensed drivers, that are the result of
some BSD driver having been ported to Linux with the original copyright left
intact. In the case of lmc, a comment states, that it was originally derived
from the "de" driver (DEC Ethernet) by Matt Thomas, although it appears to
have been rewritten from scratch (with the BSD copyright notice retained).

The same happened to the ncr 53c810 driver which was ported to Linux and then
back-ported to FreeBSD as with extensions developed under Linux to better
support later generations of the controller chip.

> I suspect the former but my attempts to contact the author were unsuccessful
> so it is probably better to just drop it.
> 
>> Inc is for very old interconnect to telco... So maybe that's safe to delete.

It appears to be a strange beast that uses the Ethernet chip to generate a
bit stream which is then converted to HDLC. Not sure whether these were used
for Frame Relay or to connect to the British X.25 JANET, a few decades ago.
Perhaps also to connect to SS7 signaling networks?

Regards, STefan
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r327541 - head/lib/libcasper/libcasper

2018-01-04 Thread Mariusz Zaborski
Author: oshogbo
Date: Thu Jan  4 08:23:23 2018
New Revision: 327541
URL: https://svnweb.freebsd.org/changeset/base/327541

Log:
  cap_unwrap should return a descriptor but also free the structure.

Modified:
  head/lib/libcasper/libcasper/libcasper.h

Modified: head/lib/libcasper/libcasper/libcasper.h
==
--- head/lib/libcasper/libcasper/libcasper.hThu Jan  4 04:11:40 2018
(r327540)
+++ head/lib/libcasper/libcasper/libcasper.hThu Jan  4 08:23:23 2018
(r327541)
@@ -122,7 +122,15 @@ cap_wrap(int sock)
 #ifdef WITH_CASPER
 intcap_unwrap(cap_channel_t *chan);
 #else
-#definecap_unwrap(chan)(chan->cch_fd)
+static inline int
+cap_unwrap(cap_channel_t *chan)
+{
+   int fd;
+
+   fd = chan->cch_fd;
+   free(chan);
+   return (fd);
+}
 #endif
 
 /*
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r327086 - head/sys/dev/lmc

2018-01-04 Thread Poul-Henning Kamp

In message 
, Warner Losh writes:

>Deleting lmc(4) is probably the appropriate fix.

>Inc is for very old interconnect to telco... So maybe that's safe to delete.

As the guy who put lmc(4) in the tree I concur.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"