Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Gleb Smirnoff]

  Sean,

On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote:
S In our universe, this commit (right or wrong) resolved our panics.  I
S think that there is some room for improvement based on the commentary
S in this thread, but some people do indeed prefer stability over
S performance.  I hope we can come to a middle ground somewhere here.

Sorry, but this sounds very much like alchemy. We poured this stuff
into that stuff and yield in gold precipitate. We don't understand
what's going on, but let's record the recipe into our tome of aclhemy
wisdom.

So alchemy never came to a scientific level, and chemistry evolved
as science only when researchers started to measure, explain and
understand.

If we treat our precious kernel in alchemy way, we will follow
the path of alchemy, except that it took centuries for alchemy to
die, and for a software product it would take a few years.

So, for me Kip ideas sound very sensible. There could be a race
somewhere else. You tweak callout subsystem in any direction,
timings of events in kernel shift, your race is hidden.

If we fix problems w/o understanding them, we are going alchemy way.

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

Re: svn commit: r277486 - head/share/man/man9

[hiren panchasara]

On Wed, Jan 21, 2015 at 10:22 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
 On Wed, Jan 21, 2015 at 01:48:06PM +, Gavin Atkinson wrote:
 G Author: gavin
 G Date: Wed Jan 21 13:48:06 2015
 G New Revision: 277486
 G URL: https://svnweb.freebsd.org/changeset/base/277486
 G
 G Log:
 G   softc is short for software context, use that phrase in the
 G   device_get_softc(9) man page.

 Thanks for making this term official :)

Heh, yes. Thanks Gavin!

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

svn commit: r277497 - head

[Ed Maste]

Author: emaste
Date: Wed Jan 21 19:04:55 2015
New Revision: 277497
URL: https://svnweb.freebsd.org/changeset/base/277497

Log:
  Remove addr2line from cross elftoolchain tools list
  
  It is not required, and there is no reason to install it just because it
  came with the binutils cross tools.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jan 21 18:32:53 2015(r277496)
+++ head/Makefile.inc1  Wed Jan 21 19:04:55 2015(r277497)
@@ -1428,7 +1428,6 @@ _binutils=gnu/usr.bin/binutils
 .endif
 .if ${MK_ELFTOOLCHAIN_TOOLS} != no
 _elftctools=   lib/libelftc \
-   usr.bin/addr2line \
usr.bin/elfcopy \
usr.bin/nm \
usr.bin/size \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Adrian Chadd]

On 21 January 2015 at 10:15, Gleb Smirnoff gleb...@freebsd.org wrote:
   Sean,

 On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote:
 S In our universe, this commit (right or wrong) resolved our panics.  I
 S think that there is some room for improvement based on the commentary
 S in this thread, but some people do indeed prefer stability over
 S performance.  I hope we can come to a middle ground somewhere here.

 Sorry, but this sounds very much like alchemy. We poured this stuff
 into that stuff and yield in gold precipitate. We don't understand
 what's going on, but let's record the recipe into our tome of aclhemy
 wisdom.

 So alchemy never came to a scientific level, and chemistry evolved
 as science only when researchers started to measure, explain and
 understand.

 If we treat our precious kernel in alchemy way, we will follow
 the path of alchemy, except that it took centuries for alchemy to
 die, and for a software product it would take a few years.

 So, for me Kip ideas sound very sensible. There could be a race
 somewhere else. You tweak callout subsystem in any direction,
 timings of events in kernel shift, your race is hidden.

 If we fix problems w/o understanding them, we are going alchemy way.

Hi,

I don't think it's quite this bad.

They originally found that things were spinning for way too long.

Hans found something similar and determined/concluded that the
migration code in callouts was racy-by-design and dramatically
simplified it and also put very hard constraints on what is a valid
situation to support migrating from one callwheel to another. Now we
have fallout which we can either address or back out until the callout
stuff is again reviewed/fixed.

I don't think it's as alchemic as is being promoted.



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

svn commit: r277500 - head/sys/powerpc/aim

[Nathan Whitehorn]

Author: nwhitehorn
Date: Wed Jan 21 19:11:15 2015
New Revision: 277500
URL: https://svnweb.freebsd.org/changeset/base/277500

Log:
  Add POWER7+ and POWER8 to the list of CPUs with 32 SLB slots. This is
  mostly a no-op since all currently-supported instances of these CPUs give
  the number of SLB slots in the device tree, but keep it here as well just
  in case.

Modified:
  head/sys/powerpc/aim/machdep.c

Modified: head/sys/powerpc/aim/machdep.c
==
--- head/sys/powerpc/aim/machdep.c  Wed Jan 21 19:09:15 2015
(r277499)
+++ head/sys/powerpc/aim/machdep.c  Wed Jan 21 19:11:15 2015
(r277500)
@@ -394,6 +394,9 @@ powerpc_init(vm_offset_t fdt, vm_offset_
break;
#ifdef __powerpc64__
case IBMPOWER7:
+   case IBMPOWER7PLUS:
+   case IBMPOWER8:
+   case IBMPOWER8E:
/* XXX: get from ibm,slb-size in device tree */
n_slbs = 32;
break;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277501 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Will Andrews]

Author: will
Date: Wed Jan 21 19:20:36 2015
New Revision: 277501
URL: https://svnweb.freebsd.org/changeset/base/277501

Log:
  Eliminate an #ifdef illumos for zfs_ioc_rename().
  
  Since allow_mounted is a FreeBSD-specific change, default to B_TRUE, then
  locally check for the magic bit.  Unconditionally check allow_mounted below.
  Convert the setting of allow_mounted to an explicit boolean.
  
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 672578 (in part) on 2013/07/19

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Wed Jan 
21 19:11:15 2015(r277500)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Wed Jan 
21 19:20:36 2015(r277501)
@@ -3751,10 +3751,12 @@ static int
 zfs_ioc_rename(zfs_cmd_t *zc)
 {
boolean_t recursive = zc-zc_cookie  1;
+   char *at;
+   boolean_t allow_mounted = B_TRUE;
+
 #ifdef __FreeBSD__
-   boolean_t allow_mounted = zc-zc_cookie  2;
+   allow_mounted = (zc-zc_cookie  2) != 0;
 #endif
-   char *at;
 
zc-zc_value[sizeof (zc-zc_value) - 1] = '\0';
if (dataset_namecheck(zc-zc_value, NULL, NULL) != 0 ||
@@ -3769,11 +3771,7 @@ zfs_ioc_rename(zfs_cmd_t *zc)
if (strncmp(zc-zc_name, zc-zc_value, at - zc-zc_name + 1))
return (SET_ERROR(EXDEV));
*at = '\0';
-#ifdef illumos
-   if (zc-zc_objset_type == DMU_OST_ZFS) {
-#else
if (zc-zc_objset_type == DMU_OST_ZFS  allow_mounted) {
-#endif
error = dmu_objset_find(zc-zc_name,
recursive_unmount, at + 1,
recursive ? DS_FIND_CHILDREN : 0);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277506 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 19:59:09 2015
New Revision: 277506
URL: https://svnweb.freebsd.org/changeset/base/277506

Log:
  Fix one cause of firewire panics.
  
  sys/dev/firewire/firewire.c:
In fw_xfer_unload(), clear the FWXF_INQ flag on the
xfer under protection of the FW_GMTX, after the
xfer is removeed from the tx/rx queue.  Otherwise
it is possible for the xfer to be removed again
(corrupting the list or immediately panicing) from
another thread that has found this xfer in the
transaction label table.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110200 on 2015/01/02

Modified:
  head/sys/dev/firewire/firewire.c

Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 19:53:52 2015
(r277505)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 19:59:09 2015
(r277506)
@@ -1166,6 +1166,7 @@ fw_xfer_unload(struct fw_xfer *xfer)
s = splfw();
FW_GLOCK(xfer-fc);
STAILQ_REMOVE(xfer-q-q, xfer, fw_xfer, link);
+   xfer-flag = ~FWXF_INQ;
 #if 0
xfer-q-queued--;
 #endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277495 - head/sys/kern

[Mateusz Guzik]

Author: mjg
Date: Wed Jan 21 18:05:42 2015
New Revision: 277495
URL: https://svnweb.freebsd.org/changeset/base/277495

Log:
  filedesc: return 0 from badfo_close
  
  The only potential in-tree consumer (_fdrop) special-cased it and returns 0
  0 on its own instead of calling badfo_close.
  
  Remove the special case since it is not needed and very unlikely to encounter
  anyway.
  
  No objections from:   kib

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 18:02:28 2015
(r277494)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:05:42 2015
(r277495)
@@ -2680,11 +2680,9 @@ _fdrop(struct file *fp, struct thread *t
 {
int error;
 
-   error = 0;
if (fp-f_count != 0)
panic(fdrop: count %d, fp-f_count);
-   if (fp-f_ops != badfileops)
-   error = fo_close(fp, td);
+   error = fo_close(fp, td);
atomic_subtract_int(openfiles, 1);
crfree(fp-f_cred);
free(fp-f_advice, M_FADVISE);
@@ -3664,7 +3662,7 @@ static int
 badfo_close(struct file *fp, struct thread *td)
 {
 
-   return (EBADF);
+   return (0);
 }
 
 static int
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277505 - head/sys/dev/dcons

[Will Andrews]

Author: will
Date: Wed Jan 21 19:53:52 2015
New Revision: 277505
URL: https://svnweb.freebsd.org/changeset/base/277505

Log:
  Garbage collect dragonfly and legacy FreeBSD system support from dcons(4).
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110990 on 2015/01/06

Modified:
  head/sys/dev/dcons/dcons.c
  head/sys/dev/dcons/dcons_crom.c
  head/sys/dev/dcons/dcons_os.h

Modified: head/sys/dev/dcons/dcons.c
==
--- head/sys/dev/dcons/dcons.c  Wed Jan 21 19:30:01 2015(r277504)
+++ head/sys/dev/dcons/dcons.c  Wed Jan 21 19:53:52 2015(r277505)
@@ -37,11 +37,9 @@
 
 #include sys/param.h
 
-#if defined(__DragonFly__) || defined(_BOOT)
-#include dcons.h
 #if defined(_BOOT)
+#include dcons.h
 #include stand.h
-#endif
 #else
 #include dev/dcons/dcons.h
 #endif

Modified: head/sys/dev/dcons/dcons_crom.c
==
--- head/sys/dev/dcons/dcons_crom.c Wed Jan 21 19:30:01 2015
(r277504)
+++ head/sys/dev/dcons/dcons_crom.c Wed Jan 21 19:53:52 2015
(r277505)
@@ -46,40 +46,25 @@
 #include sys/bus.h
 #include machine/bus.h
 
-#ifdef __DragonFly__
-#include bus/firewire/firewire.h
-#include bus/firewire/firewirereg.h
-#include bus/firewire/iec13213.h
-#include dcons.h
-#include dcons_os.h
-#else
 #include dev/firewire/firewire.h
 #include dev/firewire/firewirereg.h
 #include dev/firewire/iec13213.h
 #include dev/dcons/dcons.h
 #include dev/dcons/dcons_os.h
-#endif
 
 #include sys/cons.h
 
-#define EXPOSE_IDT_ADDR 1
-
-#if (defined(__i386__) || defined(__amd64__))  defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
 #include vm/vm.h
 #include vm/vm_param.h
 #include vm/pmap.h
 #include machine/segments.h /* for idt */
 #endif
+
 static bus_addr_t dcons_paddr;
 
-#if __FreeBSD_version = 50
 static int force_console = 0;
 TUNABLE_INT(hw.firewire.dcons_crom.force_console, force_console);
-#endif
-
-#ifndef CSRVAL_VENDOR_PRIVATE
-#define NEED_NEW_DRIVER
-#endif
 
 #define ADDR_HI(x) (((x)  24)  0xff)
 #define ADDR_LO(x) ((x)  0xff)
@@ -115,8 +100,7 @@ dcons_crom_probe(device_t dev)
return (0);
 }
 
-#ifndef NEED_NEW_DRIVER
-#if (defined(__i386__) || defined(__amd64__))  defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
 static void
 dcons_crom_expose_idt(struct dcons_crom_softc *sc)
 {
@@ -129,6 +113,7 @@ dcons_crom_expose_idt(struct dcons_crom_
crom_add_entry(sc-unit, DCONS_CSR_KEY_RESET_LO, ADDR_LO(idt_paddr));
 }
 #endif
+
 static void
 dcons_crom_post_busreset(void *arg)
 {
@@ -149,11 +134,10 @@ dcons_crom_post_busreset(void *arg)
crom_add_simple_text(src, sc-unit, sc-ver, dcons);
crom_add_entry(sc-unit, DCONS_CSR_KEY_HI, ADDR_HI(dcons_paddr));
crom_add_entry(sc-unit, DCONS_CSR_KEY_LO, ADDR_LO(dcons_paddr));
-#if (defined(__i386__) || defined(__amd64__))  defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
dcons_crom_expose_idt(sc);
 #endif
 }
-#endif
 
 static void
 dmamap_cb(void *arg, bus_dma_segment_t *segments, int seg, int error)
@@ -168,11 +152,7 @@ dmamap_cb(void *arg, bus_dma_segment_t *
 
bus_dmamap_sync(sc-dma_tag, sc-dma_map, BUS_DMASYNC_PREWRITE);
device_printf(sc-fd.dev,
-#if __FreeBSD_version  50
-   bus_addr 0x%x\n, sc-bus_addr);
-#else
bus_addr 0x%jx\n, (uintmax_t)sc-bus_addr);
-#endif
if (dcons_paddr != 0) {
/* XXX */
device_printf(sc-fd.dev, dcons_paddr is already set\n);
@@ -182,11 +162,9 @@ dmamap_cb(void *arg, bus_dma_segment_t *
dcons_conf-dma_map = sc-dma_map;
dcons_paddr = sc-bus_addr;
 
-#if __FreeBSD_version = 50
/* Force to be the high-level console */
if (force_console)
cnselect(dcons_conf-cdev);
-#endif
 }
 
 static void
@@ -200,10 +178,6 @@ dcons_crom_poll(void *p, int arg)
 static int
 dcons_crom_attach(device_t dev)
 {
-#ifdef NEED_NEW_DRIVER
-   printf(dcons_crom: you need newer firewire driver\n);
-   return (-1);
-#else
struct dcons_crom_softc *sc;
int error;
 
@@ -227,10 +201,8 @@ dcons_crom_attach(device_t dev)
/*nsegments*/ 1,
/*maxsegsz*/ BUS_SPACE_MAXSIZE_32BIT,
/*flags*/ BUS_DMA_ALLOCNOW,
-#if __FreeBSD_version = 501102
/*lockfunc*/busdma_lock_mutex,
/*lockarg*/Giant,
-#endif
sc-dma_tag);
if (error != 0)
return (error);
@@ -245,7 +217,6 @@ dcons_crom_attach(device_t dev)
sc-ehand = EVENTHANDLER_REGISTER(dcons_poll, dcons_crom_poll,
 (void *)sc, 0);
return (0);
-#endif
 }
 
 static int

Modified: head/sys/dev/dcons/dcons_os.h
==
--- 

svn commit: r277508 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 20:03:46 2015
New Revision: 277508
URL: https://svnweb.freebsd.org/changeset/base/277508

Log:
  Fix panic in firewire and creation of invalid config ROM.
  
  sys/boot/i386/libfirewire/firewire.c:
  sys/dev/firewire/firewire.c:
Fix configuration ROM generation count wrapping logic
so that the generation count is never outside of
allowed limits (0x2 - 0xF).
  
  sys/dev/firewire/firewire.c:
In fw_xfer_unload(), xfer-fc may be NULL.  Protect
against this before taking the fc lock.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110685 on 2015/01/05

Modified:
  head/sys/dev/firewire/firewire.c

Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 20:02:16 2015
(r277507)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:03:46 2015
(r277508)
@@ -761,8 +761,15 @@ fw_busreset(struct firewire_comm *fc, ui
src = fc-crom_src_buf-src;
crom_load(src, newrom, CROMSIZE);
if (bcmp(newrom, fc-config_rom, CROMSIZE) != 0) {
-   if (src-businfo.generation++  FW_MAX_GENERATION)
+   /* Bump generation and reload. */
+   src-businfo.generation++;
+
+   /* Handle generation count wraps. */
+   if (src-businfo.generation  FW_GENERATION_CHANGEABLE)
src-businfo.generation = FW_GENERATION_CHANGEABLE;
+
+   /* Recalculate CRC to account for generation change. */
+   crom_load(src, newrom, CROMSIZE);
bcopy(newrom, fc-config_rom, CROMSIZE);
}
free(newrom, M_FW);
@@ -1156,16 +1163,18 @@ fw_xfer_unload(struct fw_xfer *xfer)
 
if (xfer == NULL)
return;
-   FW_GLOCK(xfer-fc);
-   if (xfer-flag  FWXF_INQ) {
-   STAILQ_REMOVE(xfer-q-q, xfer, fw_xfer, link);
-   xfer-flag = ~FWXF_INQ;
-#if 0
-   xfer-q-queued--;
-#endif
-   }
-   FW_GUNLOCK(xfer-fc);
+
if (xfer-fc != NULL) {
+   FW_GLOCK(xfer-fc);
+   if (xfer-flag  FWXF_INQ) {
+   STAILQ_REMOVE(xfer-q-q, xfer, fw_xfer, link);
+   xfer-flag = ~FWXF_INQ;
+   #if 0
+   xfer-q-queued--;
+   #endif
+   }
+   FW_GUNLOCK(xfer-fc);
+
/*
 * Ensure that any tlabel owner can't access this
 * xfer after it's freed.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277489 - head/sys/kern

[Gleb Smirnoff]

On Wed, Jan 21, 2015 at 04:32:55PM +, Konstantin Belousov wrote:
K Author: kib
K Date: Wed Jan 21 16:32:54 2015
K New Revision: 277489
K URL: https://svnweb.freebsd.org/changeset/base/277489
K 
K Log:
K   Do not assert that the new pipepair mutex is not initialized.  The
K   backing memory contains garbage and might trigger the assertion.

I have touched dozen of places in kernel where I do explicit M_ZERO on
allocation just to satisfy later assertion in the mtx_init. Is the
correct fix to use MTX_NEW?

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

svn commit: r277496 - head/sys/kern

[Mateusz Guzik]

Author: mjg
Date: Wed Jan 21 18:32:53 2015
New Revision: 277496
URL: https://svnweb.freebsd.org/changeset/base/277496

Log:
  filedesc: avoid spurious copying of capabilities in fget_unlocked
  
  We obtain a stable copy and store it in local 'fde' variable. Storing another
  copy (based on aforementioned variable) does not serve any purpose.
  
  No functional changes.

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 18:05:42 2015
(r277495)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:32:53 2015
(r277496)
@@ -2337,7 +2337,7 @@ fget_unlocked(struct filedesc *fdp, int 
u_int count;
 #ifdef CAPABILITIES
seq_t seq;
-   cap_rights_t haverights;
+   cap_rights_t *haverights;
int error;
 #endif
 
@@ -2367,9 +2367,9 @@ fget_unlocked(struct filedesc *fdp, int 
if (fp == NULL)
return (EBADF);
 #ifdef CAPABILITIES
-   haverights = *cap_rights_fde(fde);
+   haverights = cap_rights_fde(fde);
if (needrightsp != NULL) {
-   error = cap_check(haverights, needrightsp);
+   error = cap_check(haverights, needrightsp);
if (error != 0)
return (error);
if (cap_rights_is_set(needrightsp, CAP_FCNTL)) {
@@ -2408,7 +2408,7 @@ fget_unlocked(struct filedesc *fdp, int 
*fpp = fp;
if (haverightsp != NULL) {
 #ifdef CAPABILITIES
-   *haverightsp = haverights;
+   *haverightsp = *haverights;
 #else
CAP_ALL(haverightsp);
 #endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277498 - in head/sys/powerpc: aim include

[Nathan Whitehorn]

Author: nwhitehorn
Date: Wed Jan 21 19:07:45 2015
New Revision: 277498
URL: https://svnweb.freebsd.org/changeset/base/277498

Log:
  Make 64-bit AIM trap handlers relocatable by changing all absolute branch
  instructions to call through pointers instead. In general, these are set
  implicitly through relocation processing. One has to be set explicitly in
  machdep.c, however, to fit one handler in the tiny (8 instruction) space
  available.
  
  Reviewed by:  andreast
  Differential revision:D1554
  Tested on:UP and SMP G5, Cell, POWER5+

Modified:
  head/sys/powerpc/aim/machdep.c
  head/sys/powerpc/aim/trap_subr64.S
  head/sys/powerpc/include/trap.h

Modified: head/sys/powerpc/aim/machdep.c
==
--- head/sys/powerpc/aim/machdep.c  Wed Jan 21 19:04:55 2015
(r277497)
+++ head/sys/powerpc/aim/machdep.c  Wed Jan 21 19:07:45 2015
(r277498)
@@ -238,7 +238,7 @@ extern void *trapcode64;
 #endif
 
 extern void*rstcode, *rstsize;
-extern void*trapcode, *trapsize;
+extern void*trapcode, *trapsize, *trapcode2;
 extern void*slbtrap, *slbtrapsize;
 extern void*alitrap, *alisize;
 extern void*dsitrap, *dsisize;
@@ -506,6 +506,7 @@ powerpc_init(vm_offset_t fdt, vm_offset_
generictrap = trapcode;
 
/* Set TOC base so that the interrupt code can get at it */
+   *((void **)TRAP_GENTRAP) = trapcode2;
*((register_t *)TRAP_TOCBASE) = toc;
#endif
 

Modified: head/sys/powerpc/aim/trap_subr64.S
==
--- head/sys/powerpc/aim/trap_subr64.S  Wed Jan 21 19:04:55 2015
(r277497)
+++ head/sys/powerpc/aim/trap_subr64.S  Wed Jan 21 19:07:45 2015
(r277498)
@@ -302,8 +302,13 @@ CNAME(rstcode):
insrdi  %r9,%r8,1,0
mtmsrd  %r9
isync
+   bl  1f
+   .llong  cpu_reset
+1: mflr%r9
+   ld  %r9,0(%r9)
+   mtlr%r9
 
-   ba  cpu_reset
+   blr
 CNAME(rstsize) = . - CNAME(rstcode)
 
 cpu_reset:
@@ -342,16 +347,20 @@ cpu_reset:
 
 /*
  * This code gets copied to all the trap vectors
- * (except ISI/DSI, ALI, and the interrupts)
+ * (except ISI/DSI, ALI, and the interrupts). Has to fit in 8 instructions!
  */
 
.globl  CNAME(trapcode),CNAME(trapsize)
+   .p2align 3
 CNAME(trapcode):
mtsprg1 %r1 /* save SP */
mflr%r1 /* Save the old LR in r1 */
mtsprg2 %r1 /* And then in SPRG2 */
+   li  %r1,TRAP_GENTRAP
+   ld  %r1,0(%r1)
+   mtlr%r1
li  %r1, 0xA0   /* How to get the vector from LR */
-   bla generictrap /* LR  SPRG3 is exception # */
+   blrl/* Branch to generictrap */
 CNAME(trapsize) = .-CNAME(trapcode)
 
 /*
@@ -361,6 +370,7 @@ CNAME(trapsize) = .-CNAME(trapcode)
  * the only time this can be called.
  */
.globl  CNAME(slbtrap),CNAME(slbtrapsize)
+   .p2align 3
 CNAME(slbtrap):
mtsprg1 %r1 /* save SP */
GET_CPUINFO(%r1)
@@ -369,17 +379,31 @@ CNAME(slbtrap):
std %r2,(PC_SLBSAVE+104)(%r1)
mfsrr1  %r2 /* test kernel mode */
mtcr%r2
-   bf  17,1f   /* branch if PSL_PR is false */
+   bf  17,2f   /* branch if PSL_PR is false */
/* User mode */
ld  %r2,(PC_SLBSAVE+104)(%r1) /* Restore CR */
mtcr%r2
ld  %r2,(PC_SLBSAVE+16)(%r1) /* Restore R2 */
mflr%r1 /* Save the old LR in r1 */
mtsprg2 %r1 /* And then in SPRG2 */
+   /* 52 bytes so far */
+   bl  1f
+   .llong  generictrap
+1: mflr%r1
+   ld  %r1,0(%r1)
+   mtlr%r1
li  %r1, 0x80   /* How to get the vector from LR */
-   bla generictrap /* LR  SPRG3 is exception # */
-1: mflr%r2 /* Save the old LR in r2 */
-   bla kern_slbtrap
+   blrl/* Branch to generictrap */
+   /* 84 bytes */
+2: mflr%r2 /* Save the old LR in r2 */
+   nop
+   bl  3f  /* Begin dance to jump to kern_slbtrap*/
+   .llong  kern_slbtrap
+3: mflr%r1
+   ld  %r1,0(%r1)
+   mtlr%r1
+   GET_CPUINFO(%r1)
+   blrl/* 124 bytes -- 4 to spare */
 CNAME(slbtrapsize) = .-CNAME(slbtrap)
 
 kern_slbtrap:
@@ -518,6 +542,16 @@ CNAME(alitrap):
mflr%r28/* save LR */
mfcr%r29/* save CR */
 
+   /* Begin dance to branch to s_trap in a bit */
+   b   1f
+   .p2align 3

svn commit: r277499 - in head/sys/powerpc: aim powerpc

[Nathan Whitehorn]

Author: nwhitehorn
Date: Wed Jan 21 19:09:15 2015
New Revision: 277499
URL: https://svnweb.freebsd.org/changeset/base/277499

Log:
  Make sure to relocate tmpstk with everything else and avoid processing
  non-relative relocations that the UART code makes for absent modules.

Modified:
  head/sys/powerpc/aim/locore64.S
  head/sys/powerpc/powerpc/elf64_machdep.c

Modified: head/sys/powerpc/aim/locore64.S
==
--- head/sys/powerpc/aim/locore64.S Wed Jan 21 19:07:45 2015
(r277498)
+++ head/sys/powerpc/aim/locore64.S Wed Jan 21 19:09:15 2015
(r277499)
@@ -126,9 +126,14 @@ ASENTRY_NOPROF(__start)
ld  %r1,0(%r2)
add %r2,%r1,%r2
 
+   /* Get load offset */
+   ld  %r31,-0x8000(%r2) /* First TOC entry is TOC base */
+   subf%r31,%r31,%r2   /* Subtract from real TOC base to get base */
+
/* Set up the stack pointer */
ld  %r1,TOC_REF(tmpstk)(%r2)
addi%r1,%r1,TMPSTKSZ-96
+   add %r1,%r1,%r31
 
/* Relocate kernel */
std %r3,48(%r1)
@@ -140,8 +145,7 @@ ASENTRY_NOPROF(__start)
 1: mflr%r3
ld  %r4,0(%r3)
add %r3,%r4,%r3
-   ld  %r4,-0x8000(%r2) /* First TOC entry is TOC base */
-   subf%r4,%r4,%r2 /* Subtract from real TOC base to get base */
+   mr  %r4,%r31
bl  elf_reloc_self
nop
ld  %r3,48(%r1)

Modified: head/sys/powerpc/powerpc/elf64_machdep.c
==
--- head/sys/powerpc/powerpc/elf64_machdep.cWed Jan 21 19:07:45 2015
(r277498)
+++ head/sys/powerpc/powerpc/elf64_machdep.cWed Jan 21 19:09:15 2015
(r277499)
@@ -226,6 +226,8 @@ elf_reloc_self(Elf_Dyn *dynp, Elf_Addr r
 */
relalim = (Elf_Rela *)((caddr_t)rela + relasz);
for (; rela  relalim; rela++) {
+   if (ELF_R_TYPE(rela-r_info) != R_PPC_RELATIVE)
+   continue;
where = (Elf_Addr *)(relocbase + rela-r_offset);
*where = (Elf_Addr)(relocbase + rela-r_addend);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277507 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 20:02:16 2015
New Revision: 277507
URL: https://svnweb.freebsd.org/changeset/base/277507

Log:
  Fix a FWXF_INQ race in the firewire driver.
  
  sys/dev/firewire/firewire.c:
In fw_xfer_unload() expand lock coverage so that
the test for FWXF_INQ doesn't race with it being
cleared in another thread.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110207 on 2015/01/02

Modified:
  head/sys/dev/firewire/firewire.c

Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 19:59:09 2015
(r277506)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:02:16 2015
(r277507)
@@ -1022,9 +1022,7 @@ static void
 fw_tl_free(struct firewire_comm *fc, struct fw_xfer *xfer)
 {
struct fw_xfer *txfer;
-   int s;
 
-   s = splfw();
mtx_lock(fc-tlabel_lock);
if (xfer-tl  0) {
mtx_unlock(fc-tlabel_lock);
@@ -1042,14 +1040,12 @@ fw_tl_free(struct firewire_comm *fc, str
fw_dump_hdr(xfer-recv.hdr, recv);
kdb_backtrace();
mtx_unlock(fc-tlabel_lock);
-   splx(s);
return;
}
 
STAILQ_REMOVE(fc-tlabels[xfer-tl], xfer, fw_xfer, tlabel);
xfer-tl = -1;
mtx_unlock(fc-tlabel_lock);
-   splx(s);
return;
 }
 
@@ -1157,22 +1153,18 @@ fw_xfer_done(struct fw_xfer *xfer)
 void
 fw_xfer_unload(struct fw_xfer *xfer)
 {
-   int s;
 
if (xfer == NULL)
return;
+   FW_GLOCK(xfer-fc);
if (xfer-flag  FWXF_INQ) {
-   printf(fw_xfer_free FWXF_INQ\n);
-   s = splfw();
-   FW_GLOCK(xfer-fc);
STAILQ_REMOVE(xfer-q-q, xfer, fw_xfer, link);
xfer-flag = ~FWXF_INQ;
 #if 0
xfer-q-queued--;
 #endif
-   FW_GUNLOCK(xfer-fc);
-   splx(s);
}
+   FW_GUNLOCK(xfer-fc);
if (xfer-fc != NULL) {
/*
 * Ensure that any tlabel owner can't access this
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277487 - in head/sys: dev/drm2 dev/drm2/i915 dev/drm2/radeon modules/drm2/i915kms

[Shawn Webb]

On Wed, 2015-01-21 at 16:10 +, Konstantin Belousov wrote:
 Author: kib
 Date: Wed Jan 21 16:10:37 2015
 New Revision: 277487
 URL: https://svnweb.freebsd.org/changeset/base/277487
 
 Log:
   An update for the i915 GPU driver, which brings the code up to Linux
   commit 4d93914ae3db4a897ead4b.  Some related drm infrastructure
   changes are imported as needed.
   
   Biggest update is the rewrite of the i915 gem io to more closely
   follow Linux model, althought the mechanism used by FreeBSD port is
   different.

Hey Kostik,

This causes my Haswell laptop to just display a blank screen on bootup.
Is there something I should be doing? I just have i915kms_load=YES
in /boot/loader.conf.

Thanks,

Shawn


signature.asc
Description: This is a digitally signed message part

svn commit: r277502 - head/sys/arm/ti

[Oleksandr Tymoshenko]

Author: gonzo
Date: Wed Jan 21 19:23:46 2015
New Revision: 277502
URL: https://svnweb.freebsd.org/changeset/base/277502

Log:
  Remove #define DEBUG that conflicts with option DEBUG in kernel config

Modified:
  head/sys/arm/ti/ti_mbox.c
  head/sys/arm/ti/ti_pruss.c

Modified: head/sys/arm/ti/ti_mbox.c
==
--- head/sys/arm/ti/ti_mbox.c   Wed Jan 21 19:20:36 2015(r277501)
+++ head/sys/arm/ti/ti_mbox.c   Wed Jan 21 19:23:46 2015(r277502)
@@ -54,7 +54,6 @@ __FBSDID($FreeBSD$);
 
 #include mbox_if.h
 
-#define DEBUG
 #ifdef DEBUG
 #defineDPRINTF(fmt, ...)   do {\
printf(%s: , __func__);   \

Modified: head/sys/arm/ti/ti_pruss.c
==
--- head/sys/arm/ti/ti_pruss.c  Wed Jan 21 19:20:36 2015(r277501)
+++ head/sys/arm/ti/ti_pruss.c  Wed Jan 21 19:23:46 2015(r277502)
@@ -52,7 +52,6 @@ __FBSDID($FreeBSD$);
 #include arm/ti/ti_prcm.h
 #include arm/ti/ti_pruss.h
 
-#define DEBUG
 #ifdef DEBUG
 #defineDPRINTF(fmt, ...)   do {\
printf(%s: , __func__);   \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277504 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Will Andrews]

Author: will
Date: Wed Jan 21 19:30:01 2015
New Revision: 277504
URL: https://svnweb.freebsd.org/changeset/base/277504

Log:
  Remove commented log messages.

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c   Wed Jan 21 
19:25:57 2015(r277503)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c   Wed Jan 21 
19:30:01 2015(r277504)
@@ -2090,7 +2090,6 @@ zil_replay(objset_t *os, void *arg, zil_
zil_destroy(zilog, B_TRUE);
return;
}
-   //printf(ZFS: Replaying ZIL on %s...\n, os-os-os_spa-spa_name);
 
zr.zr_replay = replay_func;
zr.zr_arg = arg;
@@ -2112,7 +2111,6 @@ zil_replay(objset_t *os, void *arg, zil_
zil_destroy(zilog, B_FALSE);
txg_wait_synced(zilog-zl_dmu_pool, zilog-zl_destroy_txg);
zilog-zl_replay = B_FALSE;
-   //printf(ZFS: Replay of ZIL on %s finished.\n, 
os-os-os_spa-spa_name);
 }
 
 boolean_t
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277494 - head/sys/kern

[Mateusz Guzik]

Author: mjg
Date: Wed Jan 21 18:02:28 2015
New Revision: 277494
URL: https://svnweb.freebsd.org/changeset/base/277494

Log:
  filedesc: fix whitespace nits in fget and fget_read
  
  No functional changes.

Modified:
  head/sys/kern/kern_descrip.c

Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 17:59:32 2015
(r277493)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:02:28 2015
(r277494)
@@ -2499,7 +2499,7 @@ int
 fget(struct thread *td, int fd, cap_rights_t *rightsp, struct file **fpp)
 {
 
-   return(_fget(td, fd, fpp, 0, rightsp, NULL));
+   return (_fget(td, fd, fpp, 0, rightsp, NULL));
 }
 
 int
@@ -2514,7 +2514,7 @@ int
 fget_read(struct thread *td, int fd, cap_rights_t *rightsp, struct file **fpp)
 {
 
-   return(_fget(td, fd, fpp, FREAD, rightsp, NULL));
+   return (_fget(td, fd, fpp, FREAD, rightsp, NULL));
 }
 
 int
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277486 - head/share/man/man9

[Gleb Smirnoff]

On Wed, Jan 21, 2015 at 01:48:06PM +, Gavin Atkinson wrote:
G Author: gavin
G Date: Wed Jan 21 13:48:06 2015
G New Revision: 277486
G URL: https://svnweb.freebsd.org/changeset/base/277486
G 
G Log:
G   softc is short for software context, use that phrase in the
G   device_get_softc(9) man page.

Thanks for making this term official :)

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

svn commit: r277503 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Will Andrews]

Author: will
Date: Wed Jan 21 19:25:57 2015
New Revision: 277503
URL: https://svnweb.freebsd.org/changeset/base/277503

Log:
  Ignore sync requests from the system syncher, i.e. VFS_SYNC(waitfor=MNT_LAZY).
  
  ZFS already commits outstanding data every zfs_txg_timeout seconds, so these
  syncs are unnecessarily intrusive.
  
  Submitted by: gibbs
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1105759 on 2014/12/11

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.cWed Jan 
21 19:23:46 2015(r277502)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.cWed Jan 
21 19:25:57 2015(r277503)
@@ -132,6 +132,13 @@ zfs_sync(vfs_t *vfsp, int waitfor)
if (panicstr)
return (0);
 
+   /*
+* Ignore the system syncher.  ZFS already commits async data
+* at zfs_txg_timeout intervals.
+*/
+   if (waitfor == MNT_LAZY)
+   return (0);
+
if (vfsp != NULL) {
/*
 * Sync a specific filesystem.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277489 - head/sys/kern

[Konstantin Belousov]

Author: kib
Date: Wed Jan 21 16:32:54 2015
New Revision: 277489
URL: https://svnweb.freebsd.org/changeset/base/277489

Log:
  Do not assert that the new pipepair mutex is not initialized.  The
  backing memory contains garbage and might trigger the assertion.
  
  Reported and tested by:   pho
  Sponsored by: The FreeBSD Foundation
  MFC after:2 weeks

Modified:
  head/sys/kern/sys_pipe.c

Modified: head/sys/kern/sys_pipe.c
==
--- head/sys/kern/sys_pipe.cWed Jan 21 16:13:37 2015(r277488)
+++ head/sys/kern/sys_pipe.cWed Jan 21 16:32:54 2015(r277489)
@@ -318,7 +318,7 @@ pipe_zone_init(void *mem, int size, int 
 
pp = (struct pipepair *)mem;
 
-   mtx_init(pp-pp_mtx, pipe mutex, NULL, MTX_DEF);
+   mtx_init(pp-pp_mtx, pipe mutex, NULL, MTX_DEF | MTX_NEW);
return (0);
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277490 - in head/lib/libthr: . arch/amd64 arch/amd64/amd64 arch/amd64/include arch/arm arch/arm/arm arch/arm/include arch/common arch/i386 arch/i386/i386 arch/i386/include arch/mips ar...

[Andrew Turner]

Author: andrew
Date: Wed Jan 21 16:41:05 2015
New Revision: 277490
URL: https://svnweb.freebsd.org/changeset/base/277490

Log:
  Merge all the copies of _tcb_ctor and _tcb_dtor.
  
  The amd64, i386, and sparc64 versions were identical, with the one
  difference where the former two used inline asm instead of _tcb_get. I
  have compared the function before and after replacing the asm with _tcb_get
  and found the object files to be identical.
  
  The arm, mips, and powerpc versions were almost identical. The only
  difference was the powerpc version used an alignment of 1 where arm and
  mips used 16. As this is an increase in alignment is will be safe.
  
  Along with this arm, mips, and powerpc all passed, when initial was true,
  the value returned from _tcb_get as the first argument to
  _rtld_allocate_tls. This would then return this pointer back to the caller.
  We can remove these extra calls by checking if initial is set and setting
  the thread control block directly. As this is what the sparc64 code does
  we can use it directly.
  
  As after these observations all the architectures can now have identical
  code we can merge them into a common file.
  
  Differential Revision:https://reviews.freebsd.org/D1556
  Reviewed by:  kib
  Sponsored by: The FreeBSD Foundation

Added:
  head/lib/libthr/arch/common/
  head/lib/libthr/thread/thr_ctrdtr.c
 - copied, changed from r277373, 
head/lib/libthr/arch/sparc64/sparc64/pthread_md.c
Deleted:
  head/lib/libthr/arch/amd64/amd64/pthread_md.c
  head/lib/libthr/arch/arm/Makefile.inc
  head/lib/libthr/arch/arm/arm/
  head/lib/libthr/arch/i386/i386/pthread_md.c
  head/lib/libthr/arch/mips/Makefile.inc
  head/lib/libthr/arch/mips/mips/
  head/lib/libthr/arch/powerpc/Makefile.inc
  head/lib/libthr/arch/powerpc/powerpc/
  head/lib/libthr/arch/sparc64/sparc64/pthread_md.c
Modified:
  head/lib/libthr/Makefile
  head/lib/libthr/arch/amd64/Makefile.inc
  head/lib/libthr/arch/amd64/include/pthread_md.h
  head/lib/libthr/arch/arm/include/pthread_md.h
  head/lib/libthr/arch/i386/Makefile.inc
  head/lib/libthr/arch/i386/include/pthread_md.h
  head/lib/libthr/arch/mips/include/pthread_md.h
  head/lib/libthr/arch/powerpc/include/pthread_md.h
  head/lib/libthr/arch/sparc64/Makefile.inc
  head/lib/libthr/arch/sparc64/include/pthread_md.h
  head/lib/libthr/thread/Makefile.inc
  head/lib/libthr/thread/thr_private.h

Modified: head/lib/libthr/Makefile
==
--- head/lib/libthr/MakefileWed Jan 21 16:32:54 2015(r277489)
+++ head/lib/libthr/MakefileWed Jan 21 16:41:05 2015(r277490)
@@ -45,7 +45,9 @@ PRECIOUSLIB=
 
 .PATH: ${.CURDIR}/arch/${MACHINE_CPUARCH}/${MACHINE_CPUARCH}
 
+.if exists(${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc)
 .include ${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc
+.endif
 .include ${.CURDIR}/sys/Makefile.inc
 .include ${.CURDIR}/thread/Makefile.inc
 

Modified: head/lib/libthr/arch/amd64/Makefile.inc
==
--- head/lib/libthr/arch/amd64/Makefile.inc Wed Jan 21 16:32:54 2015
(r277489)
+++ head/lib/libthr/arch/amd64/Makefile.inc Wed Jan 21 16:41:05 2015
(r277490)
@@ -1,3 +1,3 @@
 #$FreeBSD$
 
-SRCS+= pthread_md.c _umtx_op_err.S
+SRCS+= _umtx_op_err.S

Modified: head/lib/libthr/arch/amd64/include/pthread_md.h
==
--- head/lib/libthr/arch/amd64/include/pthread_md.h Wed Jan 21 16:32:54 
2015(r277489)
+++ head/lib/libthr/arch/amd64/include/pthread_md.h Wed Jan 21 16:41:05 
2015(r277490)
@@ -77,9 +77,6 @@ struct tcb {
__result;   \
 })
 
-struct tcb *_tcb_ctor(struct pthread *, int);
-void   _tcb_dtor(struct tcb *tcb);
-
 static __inline void
 _tcb_set(struct tcb *tcb)
 {

Modified: head/lib/libthr/arch/arm/include/pthread_md.h
==
--- head/lib/libthr/arch/arm/include/pthread_md.h   Wed Jan 21 16:32:54 
2015(r277489)
+++ head/lib/libthr/arch/arm/include/pthread_md.h   Wed Jan 21 16:41:05 
2015(r277490)
@@ -47,12 +47,6 @@ struct tcb {
struct pthread  *tcb_thread;/* our hook */
 };
 
-/*
- * The tcb constructors.
- */
-struct tcb *_tcb_ctor(struct pthread *, int);
-void   _tcb_dtor(struct tcb *);
-
 /* Called from the thread to set its private data. */
 static __inline void
 _tcb_set(struct tcb *tcb)

Modified: head/lib/libthr/arch/i386/Makefile.inc
==
--- head/lib/libthr/arch/i386/Makefile.inc  Wed Jan 21 16:32:54 2015
(r277489)
+++ head/lib/libthr/arch/i386/Makefile.inc  Wed Jan 21 16:41:05 2015
(r277490)
@@ -1,3 +1,3 @@
 # $FreeBSD$
 
-SRCS+= pthread_md.c 

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Adrian Chadd]

On 21 January 2015 at 06:00, Lawrence Stewart lstew...@freebsd.org wrote:
 On 01/20/15 09:22, Adrian Chadd wrote:
 Yeah, it looks like you set c_cpu to timeout_cpu in
 _callout_init_locked(), but then you only handle the case of the CPU
 being changed in certain circumstances. You aren't handling the CPU
 being initialised when the callout is first added.

 And, callout_restart_async() calls callout_lock(), which calls
 CC_LOCK() on the callout CPU, which initially is zero. Then, it never
 seems to be 'moved' into the correct CPU, even though it's being
 called with a CPU id.

 So, if I am reading this all correctly, you aren't really handling
 multi CPU callwheels at all. ;)

 In my instance, I'm seeing quite a lot of lock contention between the
 userland threads, the network RX threads and the clock thread, all
 contending on a single callout wheel being used for TCP timers. One of
 the early goals for fixing up the RSS stuff in -HEAD was to make
 per-CPU (Well, per-RSS-bucket really) TCP timers not contend with the
 NIC RX processing path, and now it does. :(

 To clarify, you're seeing this with net.inet.tcp.per_cpu_timers=1?

Yup, RSS enables that by default.



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

svn commit: r277491 - head/sys/dev/ofw

[Andrew Turner]

Author: andrew
Date: Wed Jan 21 16:52:24 2015
New Revision: 277491
URL: https://svnweb.freebsd.org/changeset/base/277491

Log:
  Update the parsing of the cpu node. We are unable to use the reg property
  as the cpu id on arm64 as it may use two cells. In it's place we can use
  the device id.
  
  It is expected we will use the reg data on arm64 to enable cores so we
  still need to read and store it even if it is not yet used.
  
  Differential Revision:https://reviews.freebsd.org/D1555
  Reviewed by:  nwhitehorn
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/dev/ofw/ofw_cpu.c

Modified: head/sys/dev/ofw/ofw_cpu.c
==
--- head/sys/dev/ofw/ofw_cpu.c  Wed Jan 21 16:41:05 2015(r277490)
+++ head/sys/dev/ofw/ofw_cpu.c  Wed Jan 21 16:52:24 2015(r277491)
@@ -51,6 +51,10 @@ static const struct ofw_bus_devinfo *ofw
 
 static MALLOC_DEFINE(M_OFWCPU, ofwcpu, OFW CPU device information);
 
+struct ofw_cpulist_softc {
+   pcell_t  sc_addr_cells;
+};
+
 static device_method_t ofw_cpulist_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, ofw_cpulist_probe),
@@ -74,7 +78,7 @@ static device_method_t ofw_cpulist_metho
 static driver_t ofw_cpulist_driver = {
cpulist,
ofw_cpulist_methods,
-   0
+   sizeof(struct ofw_cpulist_softc)
 };
 
 static devclass_t ofw_cpulist_devclass;
@@ -100,12 +104,18 @@ ofw_cpulist_probe(device_t dev) 
 static int 
 ofw_cpulist_attach(device_t dev) 
 {
+   struct ofw_cpulist_softc *sc;
phandle_t root, child;
device_t cdev;
struct ofw_bus_devinfo *dinfo;
 
+   sc = device_get_softc(dev);
root = ofw_bus_get_node(dev);
 
+   sc-sc_addr_cells = 1;
+   OF_getencprop(root, #address-cells, sc-sc_addr_cells,
+   sizeof(sc-sc_addr_cells));
+
for (child = OF_child(root); child != 0; child = OF_peer(child)) {
dinfo = malloc(sizeof(*dinfo), M_OFWCPU, M_WAITOK | M_ZERO);
 
@@ -141,6 +151,8 @@ static int  ofw_cpu_read_ivar(device_t de
 struct ofw_cpu_softc {
struct pcpu *sc_cpu_pcpu;
uint32_t sc_nominal_mhz;
+   boolean_tsc_reg_valid;
+   pcell_t  sc_reg[2];
 };
 
 static device_method_t ofw_cpu_methods[] = {
@@ -185,17 +197,39 @@ ofw_cpu_probe(device_t dev)
 static int
 ofw_cpu_attach(device_t dev)
 {
+   struct ofw_cpulist_softc *psc;
struct ofw_cpu_softc *sc;
phandle_t node;
-   uint32_t cell;
+   pcell_t cell;
+   int rv;
 
sc = device_get_softc(dev);
-   node = ofw_bus_get_node(dev);
-   if (OF_getencprop(node, reg, cell, sizeof(cell))  0) {
-   cell = device_get_unit(dev);
-   device_printf(dev, missing 'reg' property, using %u\n, cell);
+   psc = device_get_softc(device_get_parent(dev));
+
+   if (nitems(sc-sc_reg)  psc-sc_addr_cells) {
+   if (bootverbose)
+   device_printf(dev, Too many address cells\n);
+   return (EINVAL);
}
-   sc-sc_cpu_pcpu = pcpu_find(cell);
+
+   node = ofw_bus_get_node(dev);
+
+   /* Read and validate the reg property for use later */
+   sc-sc_reg_valid = false;
+   rv = OF_getencprop(node, reg, sc-sc_reg, sizeof(sc-sc_reg));
+   if (rv  0)
+   device_printf(dev, missing 'reg' property\n);
+   else if ((rv % 4) != 0) {
+   if (bootverbose)
+   device_printf(dev, Malformed reg property\n);
+   } else if ((rv / 4) != psc-sc_addr_cells) {
+   if (bootverbose)
+   device_printf(dev, Invalid reg size %u\n, rv);
+   } else
+   sc-sc_reg_valid = true;
+
+   sc-sc_cpu_pcpu = pcpu_find(device_get_unit(dev));
+
if (OF_getencprop(node, clock-frequency, cell, sizeof(cell))  0) {
if (bootverbose)
device_printf(dev,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277492 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Will Andrews]

Author: will
Date: Wed Jan 21 17:03:11 2015
New Revision: 277492
URL: https://svnweb.freebsd.org/changeset/base/277492

Log:
  Add vfs.zfs.reference_tracking_enable sysctl/tunable.
  
  This is primarily for developer/debugging use; it enables built-in tagged
  tracking of refcounts inside ZFS.  It can only be enabled from the loader,
  since it modifies how in-core state is managed.  Default remains disabled.
  
  MFC after:1 week
  Sponsored by: Spectra Logic

Modified:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c  Wed Jan 
21 16:52:24 2015(r277491)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c  Wed Jan 
21 17:03:11 2015(r277492)
@@ -30,6 +30,10 @@
 
 #ifdef _KERNEL
 int reference_tracking_enable = FALSE; /* runs out of memory too easily */
+SYSCTL_DECL(_vfs_zfs);
+SYSCTL_INT(_vfs_zfs, OID_AUTO, reference_tracking_enable, CTLFLAG_RDTUN,
+reference_tracking_enable, 0,
+Track reference holders to refcount_t objects, used mostly by ZFS);
 #else
 int reference_tracking_enable = TRUE;
 #endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277488 - head/lib/libthr/thread

[Konstantin Belousov]

Author: kib
Date: Wed Jan 21 16:13:37 2015
New Revision: 277488
URL: https://svnweb.freebsd.org/changeset/base/277488

Log:
  Fix bug in r276630.  Do not allow pthread_sigmask() to block SIGCANCEL.
  
  Reported and tested by:   royger
  Sponsored by: The FreeBSD Foundation
  MFC after:3 days

Modified:
  head/lib/libthr/thread/thr_sig.c

Modified: head/lib/libthr/thread/thr_sig.c
==
--- head/lib/libthr/thread/thr_sig.cWed Jan 21 16:10:37 2015
(r277487)
+++ head/lib/libthr/thread/thr_sig.cWed Jan 21 16:13:37 2015
(r277488)
@@ -604,7 +604,8 @@ __weak_reference(_pthread_sigmask, pthre
 int
 _pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
 {
-   if (_sigprocmask(how, set, oset))
+
+   if (__thr_sigprocmask(how, set, oset))
return (errno);
return (0);
 }
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277487 - in head/sys: dev/drm2 dev/drm2/i915 dev/drm2/radeon modules/drm2/i915kms

[Konstantin Belousov]

Author: kib
Date: Wed Jan 21 16:10:37 2015
New Revision: 277487
URL: https://svnweb.freebsd.org/changeset/base/277487

Log:
  An update for the i915 GPU driver, which brings the code up to Linux
  commit 4d93914ae3db4a897ead4b.  Some related drm infrastructure
  changes are imported as needed.
  
  Biggest update is the rewrite of the i915 gem io to more closely
  follow Linux model, althought the mechanism used by FreeBSD port is
  different.
  
  Sponsored by: The FreeBSD Foundation
  MFC after:2 month

Added:
  head/sys/dev/drm2/i915/i915_gem_stolen.c   (contents, props changed)
  head/sys/dev/drm2/i915/intel_ddi.c   (contents, props changed)
  head/sys/dev/drm2/i915/intel_pm.c   (contents, props changed)
Modified:
  head/sys/dev/drm2/drm.h
  head/sys/dev/drm2/drmP.h
  head/sys/dev/drm2/drm_crtc.c
  head/sys/dev/drm2/drm_crtc.h
  head/sys/dev/drm2/drm_crtc_helper.c
  head/sys/dev/drm2/drm_crtc_helper.h
  head/sys/dev/drm2/drm_drv.c
  head/sys/dev/drm2/drm_edid.c
  head/sys/dev/drm2/drm_edid.h
  head/sys/dev/drm2/drm_edid_modes.h
  head/sys/dev/drm2/drm_fb_helper.c
  head/sys/dev/drm2/drm_ioctl.c
  head/sys/dev/drm2/drm_irq.c
  head/sys/dev/drm2/drm_memory.c
  head/sys/dev/drm2/drm_mode.h
  head/sys/dev/drm2/drm_pciids.h
  head/sys/dev/drm2/drm_stub.c
  head/sys/dev/drm2/i915/i915_debug.c
  head/sys/dev/drm2/i915/i915_dma.c
  head/sys/dev/drm2/i915/i915_drm.h
  head/sys/dev/drm2/i915/i915_drv.c
  head/sys/dev/drm2/i915/i915_drv.h
  head/sys/dev/drm2/i915/i915_gem.c
  head/sys/dev/drm2/i915/i915_gem_context.c
  head/sys/dev/drm2/i915/i915_gem_evict.c
  head/sys/dev/drm2/i915/i915_gem_execbuffer.c
  head/sys/dev/drm2/i915/i915_gem_gtt.c
  head/sys/dev/drm2/i915/i915_gem_tiling.c
  head/sys/dev/drm2/i915/i915_irq.c
  head/sys/dev/drm2/i915/i915_reg.h
  head/sys/dev/drm2/i915/i915_suspend.c
  head/sys/dev/drm2/i915/intel_bios.c
  head/sys/dev/drm2/i915/intel_crt.c
  head/sys/dev/drm2/i915/intel_display.c
  head/sys/dev/drm2/i915/intel_dp.c
  head/sys/dev/drm2/i915/intel_drv.h
  head/sys/dev/drm2/i915/intel_fb.c
  head/sys/dev/drm2/i915/intel_hdmi.c
  head/sys/dev/drm2/i915/intel_iic.c
  head/sys/dev/drm2/i915/intel_lvds.c
  head/sys/dev/drm2/i915/intel_modes.c
  head/sys/dev/drm2/i915/intel_overlay.c
  head/sys/dev/drm2/i915/intel_panel.c
  head/sys/dev/drm2/i915/intel_ringbuffer.c
  head/sys/dev/drm2/i915/intel_ringbuffer.h
  head/sys/dev/drm2/i915/intel_sdvo.c
  head/sys/dev/drm2/i915/intel_sprite.c
  head/sys/dev/drm2/i915/intel_tv.c
  head/sys/dev/drm2/radeon/atombios_encoders.c
  head/sys/dev/drm2/radeon/radeon_legacy_encoders.c
  head/sys/modules/drm2/i915kms/Makefile

Modified: head/sys/dev/drm2/drm.h
==
--- head/sys/dev/drm2/drm.h Wed Jan 21 13:48:06 2015(r277486)
+++ head/sys/dev/drm2/drm.h Wed Jan 21 16:10:37 2015(r277487)
@@ -1018,6 +1018,9 @@ struct drm_event_vblank {
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
+
 #include drm_mode.h
 
 /**
@@ -1126,6 +1129,8 @@ struct drm_event_vblank {
 #define DRM_IOCTL_MODE_GETPLANEDRM_IOWR(0xB6, struct 
drm_mode_get_plane)
 #define DRM_IOCTL_MODE_SETPLANEDRM_IOWR(0xB7, struct 
drm_mode_set_plane)
 #define DRM_IOCTL_MODE_ADDFB2  DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
+#define DRM_IOCTL_MODE_OBJ_GETPROPERTIES   DRM_IOWR(0xB9, struct 
drm_mode_obj_get_properties)
+#define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct 
drm_mode_obj_set_property)
 
 #define DRM_IOCTL_MM_INIT   DRM_IOWR(0xc0, struct drm_mm_init_arg)
 #define DRM_IOCTL_MM_TAKEDOWN   DRM_IOWR(0xc1, struct drm_mm_type_arg)

Modified: head/sys/dev/drm2/drmP.h
==
--- head/sys/dev/drm2/drmP.hWed Jan 21 13:48:06 2015(r277486)
+++ head/sys/dev/drm2/drmP.hWed Jan 21 16:10:37 2015(r277487)
@@ -1246,6 +1246,7 @@ int   drm_ati_pcigart_cleanup(struct drm_d
 
 /* Cache management (drm_memory.c) */
 void   drm_clflush_pages(vm_page_t *pages, unsigned long num_pages);
+void   drm_clflush_virt_range(char *addr, unsigned long length);
 
 /* Locking IOCTL support (drm_drv.c) */
 intdrm_lock(struct drm_device *dev, void *data,

Modified: head/sys/dev/drm2/drm_crtc.c
==
--- head/sys/dev/drm2/drm_crtc.cWed Jan 21 13:48:06 2015
(r277486)
+++ head/sys/dev/drm2/drm_crtc.cWed Jan 21 16:10:37 2015
(r277487)
@@ -352,7 +352,7 @@ void drm_framebuffer_cleanup(struct drm_
  * @funcs: callbacks for the new CRTC
  *
  * LOCKING:
- * Caller must hold mode config lock.
+ * Takes mode_config lock.
  *
  * Inits a new object created as base part of an driver crtc object.
  *
@@ -372,8 +372,11 @@ int drm_crtc_init(struct drm_device *dev
if (ret)
 

svn commit: r277514 - head/sys/dev/isp

[Will Andrews]

Author: will
Date: Wed Jan 21 20:27:11 2015
New Revision: 277514
URL: https://svnweb.freebsd.org/changeset/base/277514

Log:
  Force commit to record the correct log for r277513.
  
  If the user sends an XPT_RESET_DEV CCB, make sure to reset the
  Fibre Channel Command Reference Number if we're running on a FC
  controller.
  
  We send a SCSI Target Reset when we get this CCB, and as a result
  need to reset the CRN to 1 on the next command.
  
  isp_freebsd.c:
In the XPT_RESET_DEV implementation in isp_action(), reset
the CRN if we're on a FC controller.
  
  Submitted by: ken
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1112787 on 2015/01/15

Modified:
  head/sys/dev/isp/isp_freebsd.c

Modified: head/sys/dev/isp/isp_freebsd.c
==
--- head/sys/dev/isp/isp_freebsd.c  Wed Jan 21 20:22:53 2015
(r277513)
+++ head/sys/dev/isp/isp_freebsd.c  Wed Jan 21 20:27:11 2015
(r277514)
@@ -29,6 +29,7 @@
  */
 #include sys/cdefs.h
 __FBSDID($FreeBSD$);
+
 #include dev/isp/isp_freebsd.h
 #include sys/unistd.h
 #include sys/kthread.h
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277497 - head

[Ed Maste]

On 21 January 2015 at 15:20, Ian Lepore i...@freebsd.org wrote:
 I don't think
 there's a single addr2line binary I can install that will work with
 every object on the system.

There is, in fact - ELF Tool Chain's addr2line will work regardless of
the object's architecture.

However, I'm happy enough to revert this change (and add a comment
about non-build use cases) if you like.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277497 - head

[Ed Maste]

On 21 January 2015 at 14:04, Ed Maste ema...@freebsd.org wrote:

 Author: emaste
 Date: Wed Jan 21 19:04:55 2015
 New Revision: 277497
 URL: https://svnweb.freebsd.org/changeset/base/277497

 Log:
   Remove addr2line from cross elftoolchain tools list

   It is not required, and there is no reason to install it just because it
   came with the binutils cross tools.

I left some detail out of this commit message and it confused a couple
of people, so to be clear: this doesn't remove addr2line from the
world build, only the cross-tools stage.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277515 - head/sys/dev/isp

[Will Andrews]

Author: will
Date: Wed Jan 21 20:32:36 2015
New Revision: 277515
URL: https://svnweb.freebsd.org/changeset/base/277515

Log:
  Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
  
  The newer boards don't have the response field that indicates
  whether the SCSI status byte is present.  You have to just look to
  see whether it is non-zero.
  
  The code was looking to see whether the sense length was valid
  before propagating the SCSI status byte (and sense information) up
  the stack.  With a status like Reservation Conflict, there is no
  sense information, only the SCSI status byte.  So it wasn't getting
  correctly returned.
  
  isp.c:
In isp_intr(), if we are on a 2400 or 2500 type board and
get a response, look at the actual contents of the
SCSI status value and set the RQSF_GOT_STATUS flag
accordingly so that return any SCSI status value we get.  The
RQSF_GOT_SENSE flag will get set later on if there is
actual sense information returned.
  
  Submitted by: ken
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1112791 on 2015/01/15

Modified:
  head/sys/dev/isp/isp.c

Modified: head/sys/dev/isp/isp.c
==
--- head/sys/dev/isp/isp.c  Wed Jan 21 20:27:11 2015(r277514)
+++ head/sys/dev/isp/isp.c  Wed Jan 21 20:32:36 2015(r277515)
@@ -5224,7 +5224,10 @@ again:
}
scsi_status = sp2-req_scsi_status;
completion_status = sp2-req_completion_status;
-   req_state_flags = 0;
+   if ((scsi_status  0xff) != 0)
+   req_state_flags = RQSF_GOT_STATUS;
+   else
+   req_state_flags = 0;
resid = sp2-req_resid;
} else if (etype == RQSTYPE_RESPONSE) {
isp_get_response(isp, (ispstatusreq_t *) hp, sp);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277512 - in head/sys/arm: arm include

[Ian Lepore]

Author: ian
Date: Wed Jan 21 20:12:35 2015
New Revision: 277512
URL: https://svnweb.freebsd.org/changeset/base/277512

Log:
  Micro-optimize the new arm inline bus_space implementation by grouping all
  the data the inline functions access together at the start of the bus_space
  struct.  The start-of part isn't so important, it's the grouping-together
  that's the point: now all the most-accessed data should be in one cache line.
  
  Suggested by:   cognet

Modified:
  head/sys/arm/arm/bus_space_base.c
  head/sys/arm/include/bus.h

Modified: head/sys/arm/arm/bus_space_base.c
==
--- head/sys/arm/arm/bus_space_base.c   Wed Jan 21 20:08:24 2015
(r277511)
+++ head/sys/arm/arm/bus_space_base.c   Wed Jan 21 20:12:35 2015
(r277512)
@@ -150,7 +150,7 @@ static struct bus_space arm_base_bus_spa
.bs_wr_2_s  = generic_bs_wr_2,
.bs_wr_4_s  = generic_bs_wr_4,
.bs_wr_8_s  = BS_UNIMPLEMENTED,
-};
+} __aligned(CACHE_LINE_SIZE);
 
 #ifdef FDT
 bus_space_tag_t fdtbus_bs_tag = arm_base_bus_space;

Modified: head/sys/arm/include/bus.h
==
--- head/sys/arm/include/bus.h  Wed Jan 21 20:08:24 2015(r277511)
+++ head/sys/arm/include/bus.h  Wed Jan 21 20:12:35 2015(r277512)
@@ -79,9 +79,27 @@
 #defineBUS_SPACE_MAP_LINEAR0x02
 #defineBUS_SPACE_MAP_PREFETCHABLE  0x04
 
+/*
+ * Bus space for ARM.
+ *
+ * The functions used most often are grouped together at the beginning to 
ensure
+ * that all the data fits into a single cache line.  The inline implementations
+ * of single read/write access these values a lot.
+ */
 struct bus_space {
-   /* cookie */
-   void*bs_privdata;
+   /* Read/write single and barrier: the most commonly used functions. */
+   uint8_t  (*bs_r_1)(bus_space_tag_t, bus_space_handle_t, bus_size_t);
+   uint32_t (*bs_r_4)(bus_space_tag_t, bus_space_handle_t, bus_size_t);
+   void (*bs_w_1)(bus_space_tag_t, bus_space_handle_t,
+  bus_size_t, uint8_t);
+   void (*bs_w_4)(bus_space_tag_t, bus_space_handle_t,
+  bus_size_t, uint32_t);
+   void (*bs_barrier)(bus_space_tag_t, bus_space_handle_t,
+  bus_size_t, bus_size_t, int);
+
+   /* Backlink to parent (if copied), and implementation private data. */
+   struct bus_space *bs_parent;
+   void *bs_privdata;
 
/* mapping/unmapping */
int (*bs_map) (bus_space_tag_t, bus_addr_t, bus_size_t,
@@ -97,15 +115,8 @@ struct bus_space {
void(*bs_free) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
 
-   /* get kernel virtual address */
-   /* barrier */
-   void(*bs_barrier) (bus_space_tag_t, bus_space_handle_t,
-   bus_size_t, bus_size_t, int);
-
-   /* read (single) */
-   uint8_t (*bs_r_1) (bus_space_tag_t, bus_space_handle_t, 
bus_size_t);
+   /* Read single, the less commonly used functions. */
uint16_t(*bs_r_2) (bus_space_tag_t, bus_space_handle_t, 
bus_size_t);
-   uint32_t(*bs_r_4) (bus_space_tag_t, bus_space_handle_t, 
bus_size_t);
uint64_t(*bs_r_8) (bus_space_tag_t, bus_space_handle_t, 
bus_size_t);
 
/* read multiple */
@@ -128,13 +139,9 @@ struct bus_space {
void(*bs_rr_8) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint64_t *, bus_size_t);

-   /* write (single) */
-   void(*bs_w_1) (bus_space_tag_t, bus_space_handle_t,
-   bus_size_t, uint8_t);
+   /* Write single, the less commonly used functions. */
void(*bs_w_2) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint16_t);
-   void(*bs_w_4) (bus_space_tag_t, bus_space_handle_t,
-   bus_size_t, uint32_t);
void(*bs_w_8) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint64_t);
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277511 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 20:08:24 2015
New Revision: 277511
URL: https://svnweb.freebsd.org/changeset/base/277511

Log:
  Fix remote DMA based firewire debugging when targeting
  systems with more than 4GB of physical memory.
  
  To remotely debug the system 'stealthy' which has a kernel
  with this change installed and firewire properly configured:
  
% fwcontrol -m stealthy (or stealthy's firewire EUI64)
% kgdb kernel /dev/fwmem0.0
  
  sys/dev/firewire/fwohci.c:
Rather than hard code the upper limit for hw based
automatic responses to remote DMA requests at 4GB,
program the hardware using Maxmem, the page number
one higher than the highest physical page detected
in the system.
  
While here, garbage collect more useless splfw()
calls.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110994 on 2015/01/06

Modified:
  head/sys/dev/firewire/fwohci.c

Modified: head/sys/dev/firewire/fwohci.c
==
--- head/sys/dev/firewire/fwohci.c  Wed Jan 21 20:06:25 2015
(r277510)
+++ head/sys/dev/firewire/fwohci.c  Wed Jan 21 20:08:24 2015
(r277511)
@@ -48,6 +48,7 @@
 #include sys/kdb.h
 
 #include machine/bus.h
+#include machine/md_var.h
 
 #include dev/firewire/firewire.h
 #include dev/firewire/firewirereg.h
@@ -188,6 +189,7 @@ static void fwohci_task_dma(void *, int)
 #defineOHCI_PREQLO 0x118
 #defineOHCI_PREQLOCLR  0x11c
 #defineOHCI_PREQUPPER  0x120
+#define OHCI_PREQUPPER_MAX 0x
 
 #defineOHCI_SID_BUF0x64
 #defineOHCI_SID_CNT0x68
@@ -854,7 +856,7 @@ fwohci_execute_db2(void *arg, bus_dma_se
 static void
 fwohci_start(struct fwohci_softc *sc, struct fwohci_dbch *dbch)
 {
-   int i, s;
+   int i;
int tcode, hdr_len, pl_off;
int fsegment = -1;
uint32_t off;
@@ -880,7 +882,6 @@ fwohci_start(struct fwohci_softc *sc, st
if (dbch-flags  FWOHCI_DBCH_FULL)
return;
 
-   s = splfw();
db_tr = dbch-top;
 txloop:
xfer = STAILQ_FIRST(dbch-xferq.q);
@@ -1030,7 +1031,6 @@ kick:
}
 
dbch-top = db_tr;
-   splx(s);
return;
 }
 
@@ -1821,6 +1821,7 @@ static void
 fwohci_intr_core(struct fwohci_softc *sc, uint32_t stat, int count)
 {
struct firewire_comm *fc = (struct firewire_comm *)sc;
+   uintmax_t prequpper;
uint32_t node_id, plen;
 
FW_GLOCK_ASSERT(fc);
@@ -1852,8 +1853,17 @@ fwohci_intr_core(struct fwohci_softc *sc
/* allow from all nodes */
OWRITE(sc, OHCI_PREQHI, 0x7fff);
OWRITE(sc, OHCI_PREQLO, 0x);
-   /* 0 to 4GB region */
-   OWRITE(sc, OHCI_PREQUPPER, 0x1);
+   prequpper = ((uintmax_t)Maxmem  PAGE_SHIFT)  16;
+   if (prequpper  OHCI_PREQUPPER_MAX) {
+   device_printf(fc-dev,
+   Physical memory size of 0x%jx exceeds 
+   fire wire address space.  Limiting dma 
+   to memory below 0x%jx\n,
+   (uintmax_t)Maxmem  PAGE_SHIFT,
+   (uintmax_t)OHCI_PREQUPPER_MAX  16);
+   prequpper = OHCI_PREQUPPER_MAX;
+   }
+   OWRITE(sc, OHCI_PREQUPPER, prequpper  0x);
}
/* Set ATRetries register */
OWRITE(sc, OHCI_ATRETRY, 1(13 + 16) | 0xfff);
@@ -2171,7 +2181,7 @@ fwohci_rbuf_update(struct fwohci_softc *
struct fw_bulkxfer *chunk;
struct fw_xferq *ir;
uint32_t stat;
-   int s, w = 0, ldesc;
+   int w = 0, ldesc;
 
ir = fc-ir[dmach];
ldesc = sc-ir[dmach].ndesc - 1;
@@ -2179,7 +2189,6 @@ fwohci_rbuf_update(struct fwohci_softc *
 #if 0
dump_db(sc, dmach);
 #endif
-   s = splfw();
if ((ir-flag  FWXFERQ_HANDLER) == 0)
FW_GLOCK(fc);
fwdma_sync_multiseg_all(sc-ir[dmach].am, BUS_DMASYNC_POSTREAD);
@@ -2218,7 +2227,6 @@ fwohci_rbuf_update(struct fwohci_softc *
}
if ((ir-flag  FWXFERQ_HANDLER) == 0)
FW_GUNLOCK(fc);
-   splx(s);
if (w == 0)
return;
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277516 - head/sys/arm/arm

[Ian Lepore]

Author: ian
Date: Wed Jan 21 21:31:26 2015
New Revision: 277516
URL: https://svnweb.freebsd.org/changeset/base/277516

Log:
  Move the __aligned() declaration to where it will actually do something.

Modified:
  head/sys/arm/arm/bus_space_base.c

Modified: head/sys/arm/arm/bus_space_base.c
==
--- head/sys/arm/arm/bus_space_base.c   Wed Jan 21 20:32:36 2015
(r277515)
+++ head/sys/arm/arm/bus_space_base.c   Wed Jan 21 21:31:26 2015
(r277516)
@@ -45,7 +45,7 @@ bs_protos(generic);
  * The bus space tag.  This is constant for all instances, so
  * we never have to explicitly create it.
  */
-static struct bus_space arm_base_bus_space = {
+static struct bus_space arm_base_bus_space __aligned(CACHE_LINE_SIZE) = {
/* privdata is whatever the implementer wants; unused in base tag */
.bs_privdata= NULL,
 
@@ -150,7 +150,7 @@ static struct bus_space arm_base_bus_spa
.bs_wr_2_s  = generic_bs_wr_2,
.bs_wr_4_s  = generic_bs_wr_4,
.bs_wr_8_s  = BS_UNIMPLEMENTED,
-} __aligned(CACHE_LINE_SIZE);
+};
 
 #ifdef FDT
 bus_space_tag_t fdtbus_bs_tag = arm_base_bus_space;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r276747 - head/sys/netpfil/pf

[Gleb Smirnoff]

On Wed, Jan 07, 2015 at 11:46:31PM +0300, Gleb Smirnoff wrote:
T On Tue, Jan 06, 2015 at 09:03:04AM +, Craig Rodrigues wrote:
T C Author: rodrigc
T C Date: Tue Jan  6 09:03:03 2015
T C New Revision: 276747
T C URL: https://svnweb.freebsd.org/changeset/base/276747
T C 
T C Log:
T C   Instead of creating a purge thread for every vnet, create
T C   a single purge thread and clean up all vnets from this thread.
T C   
T C   PR: 194515
T C   Differential Revision:  D1315
T C   Submitted by:   Nikos Vassiliadis nv...@gmx.com
T 
T I am not sure that this is a good idea. The core idea of VNETs
T is that they are isolated from each other. If we serialize purging,
T then vnets are strongly affecting each other.
T 
T AFAIU, from the PR there is some panic fixed. What is the actual bug
T and why couldn't it be fixed with having per-vnet thread?

So, after closer inspection, this commit is a completely messed up.

You blindly remove kproc_exit(). What do you think would happen on
'kldunload -f pf'?

You removed PF_RULES_RLOCK(). Cool! Now the purging thread doesn't
acquire the pf lock.

You substitute rw_sleep() with tsleep(). And the latter requires
Giant to be held. If you tried your change with INVARIANTS, it
would panic immediately.

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

svn commit: r277517 - head

[Ed Maste]

Author: emaste
Date: Wed Jan 21 21:49:03 2015
New Revision: 277517
URL: https://svnweb.freebsd.org/changeset/base/277517

Log:
  Fix bootstrap on systems with old libdwarf and WITHOUT_CDDL
  
  ELF Tool Chain tools need libelf and libdwarf.
  
  Submitted by: jmallett (earlier version)
  Reviewed by:  jmallett
  Sponsored by: The FreeBSD Foundation

Modified:
  head/Makefile.inc1

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Wed Jan 21 21:31:26 2015(r277516)
+++ head/Makefile.inc1  Wed Jan 21 21:49:03 2015(r277517)
@@ -1292,12 +1292,16 @@ _clang_tblgen= \
usr.bin/clang/clang-tblgen
 .endif
 
+# ELF Tool Chain libraries are needed for ELF tools and dtrace tools.
 # dtrace tools are required for older bootstrap env and cross-build
 # pre libdwarf
-.if ${MK_CDDL} != no  (${BOOTSTRAPPING}  116 \
-  || (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH}))
-_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
-lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
+.if ${BOOTSTRAPPING}  116 || (${MACHINE} != ${TARGET} || \
+${MACHINE_ARCH} != ${TARGET_ARCH})
+_elftoolchain_libs= lib/libelf lib/libdwarf 
+.if ${MK_CDDL} != no
+_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf cddl/usr.bin/ctfconvert \
+cddl/usr.bin/ctfmerge
+.endif
 .endif
 
 # Default to building the GPL DTC, but build the BSDL one if users explicitly
@@ -1324,6 +1328,7 @@ bootstrap-tools: .MAKE
 .for _tool in \
 ${_clang_tblgen} \
 ${_kerberos5_bootstrap_tools} \
+${_elftoolchain_libs} \
 ${_dtrace_tools} \
 ${_strfile} \
 ${_gperf} \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277513 - head/sys/dev/isp

[Will Andrews]

Author: will
Date: Wed Jan 21 20:22:53 2015
New Revision: 277513
URL: https://svnweb.freebsd.org/changeset/base/277513

Log:
  Change 1112791 by kenm@ken.spectrabsd8 on 2015/01/15 16:45:13
  
  Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
  
  The newer boards don't have the response field that indicates
  whether the SCSI status byte is present.  You have to just look to
  see whether it is non-zero.
  
  The code was looking to see whether the sense length was valid
  before propagating the SCSI status byte (and sense information) up
  the stack.  With a status like Reservation Conflict, there is no
  sense information, only the SCSI status byte.  So it wasn't getting
  correctly returned.
  
  isp.c:
In isp_intr(), if we are on a 2400 or 2500 type board and
get a response, look at the actual contents of the
SCSI status value and set the RQSF_GOT_STATUS flag
accordingly so that return any SCSI status value we get.  The
RQSF_GOT_SENSE flag will get set later on if there is
actual sense information returned.
  
  Submitted by: ken
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1112791 on 2015/01/15

Modified:
  head/sys/dev/isp/isp_freebsd.c

Modified: head/sys/dev/isp/isp_freebsd.c
==
--- head/sys/dev/isp/isp_freebsd.c  Wed Jan 21 20:12:35 2015
(r277512)
+++ head/sys/dev/isp/isp_freebsd.c  Wed Jan 21 20:22:53 2015
(r277513)
@@ -5123,19 +5123,34 @@ isp_action(struct cam_sim *sim, union cc
break;
 #endif
case XPT_RESET_DEV: /* BDR the specified SCSI device */
+   {
+   struct isp_fc *fc;
 
bus = cam_sim_bus(xpt_path_sim(ccb-ccb_h.path));
tgt = ccb-ccb_h.target_id;
tgt |= (bus  16);
+   if (IS_FC(isp))
+   fc = ISP_FC_PC(isp, bus);
+   else
+   fc = NULL;
 
error = isp_control(isp, ISPCTL_RESET_DEV, bus, tgt);
if (error) {
ccb-ccb_h.status = CAM_REQ_CMP_ERR;
} else {
+   /*
+* If we have a FC device, reset the Command
+* Reference Number, because the target will expect
+* that we re-start the CRN at 1 after a reset.
+*/
+   if (fc != NULL)
+   isp_fcp_reset_crn(fc, tgt, /*tgt_set*/ 1);
+
ccb-ccb_h.status = CAM_REQ_CMP;
}
xpt_done(ccb);
break;
+   }
case XPT_ABORT: /* Abort the specified CCB */
{
union ccb *accb = ccb-cab.abort_ccb;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277204 - head/sys/amd64/conf

[John-Mark Gurney]

Adrian Chadd wrote this message on Fri, Jan 16, 2015 at 10:43 -0800:
 When I've done what you're doing, I end up having these options in my
 minimal config file so opt_xxx.h is correctly populated. That way when
 I point SYSDIR (or whichever variable it is) at the configured kernel
 directory with the opt_xxx.h files, it all works out correctly.
 
 (I still think we shouldn't be relying on defaults, but should ship
 the opt_xxx.h files or something to derive the opt_xxx.h and makefile
 config bits so things like external module building is possible
 against a kernel. Or, we just kill all module options that change
 behaviour/ABI of things in an incompatible way.)

I have the commands that are able to stash the opt files in a kernel
section, and then be able to extract them again so that when you build
a kernel module it will use the correct options to match the kernel..

This is most useful for things like PAE which have a big impact...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[K. Macy]

 HPS: Your change failed to meet these guidelines. Some of us are upset
 because these guidelines are fairly fundamental for the on-going
 viability of FreeBSD. Due to linguistic / time zone / cultural
 differences these expectations have not been adequately communicated
 to you. You are not in the USB sandbox where others need for your
 support outweighs the inconvenience of random breakage.

 It sounds like you are making progress towards updating the concerns
 that have been voiced. If kib's observations are in fact comprehensive
 then adding a callout_init_cpu function and updating all clients so
 that their callouts continue to be scheduled on a CPU other than the
 BSP will suffice and we can all move on.

 Is there some reason that we can’t back things out, break things down into
 smaller pieces and have everything pass through phabric with a wide
 ranging review? Given the fundamental nature of these changes, they
 really need better review and doing it after the fact seems to be to be
 too risky. I’m not debating that this “fixes” some issues, but given the
 performance regression, it sure seems like we may need a different
 solution to be implemented and hashing that out in a branch might be
 the best approach.

Thank you. A more incremental approach would be appreciated by many of
us. To avoid the bystander effect we can permit explicit timeouts for
review-to-commit (72 hours?) so that we don't collectively end up
sandbagging him.


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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Adrian Chadd]

On 21 January 2015 at 16:07, K. Macy km...@freebsd.org wrote:
 HPS: Your change failed to meet these guidelines. Some of us are upset
 because these guidelines are fairly fundamental for the on-going
 viability of FreeBSD. Due to linguistic / time zone / cultural
 differences these expectations have not been adequately communicated
 to you. You are not in the USB sandbox where others need for your
 support outweighs the inconvenience of random breakage.

 It sounds like you are making progress towards updating the concerns
 that have been voiced. If kib's observations are in fact comprehensive
 then adding a callout_init_cpu function and updating all clients so
 that their callouts continue to be scheduled on a CPU other than the
 BSP will suffice and we can all move on.

 Is there some reason that we can’t back things out, break things down into
 smaller pieces and have everything pass through phabric with a wide
 ranging review? Given the fundamental nature of these changes, they
 really need better review and doing it after the fact seems to be to be
 too risky. I’m not debating that this “fixes” some issues, but given the
 performance regression, it sure seems like we may need a different
 solution to be implemented and hashing that out in a branch might be
 the best approach.

 Thank you. A more incremental approach would be appreciated by many of
 us. To avoid the bystander effect we can permit explicit timeouts for
 review-to-commit (72 hours?) so that we don't collectively end up
 sandbagging him.

I'm +1 for this.



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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[K. Macy]

 They originally found that things were spinning for way too long.

 Hans found something similar and determined/concluded that the
 migration code in callouts was racy-by-design and dramatically
 simplified it and also put very hard constraints on what is a valid
 situation to support migrating from one callwheel to another. Now we
 have fallout which we can either address or back out until the callout
 stuff is again reviewed/fixed.

 I don't think it's as alchemic as is being promoted.


Let's not get drawn into semantic debates. To me alchemy implies
voodoo debugging, whereas this is, in part, disabling functionality
that exposes races - which is more like disabling preemption or fine
grained locking.


Normally I would advocate backing this out on the basis of precedence.
That is to say, back it out so that developers will get it right the
first time. However, it appears that hps@ and some others don't
understand what was done wrong. So I'm going to state some basic
premises and then the implied basic guidelines required of a commit
that were not met. If these guidelines are violated by a change in the
future I will agitate for a rapid back out.

Premises:
A) A performance regression is a bug every bit as much as a locking
race. Stability OR performance (where we are talking about _current_
performance) is a false dichotomy.
   - This means that a change that fixes a bug by introducing a
substantial performance regression does not constitute a fix.
B) Existing behavior and performance characteristics should not be
adversely changed unless there is widespread consensus.
  - Sometimes it is necessary to break a KPI but that should not be
discovered by svn or scanning back through the mailing lists.

Guidelines:
A) Performance should not measurably regress.
B) If a KPI changes behavior e.g. callout_reset_on being crippled, all
clients need to be updated so that they maintain their current
behavior by the committer changing the KPI. The client code
maintainers aren't responsible for reacting to these types of changes.
That is OK for marginal architectures like sun4v or pc98.
C) If there is a non-zero possibility that these changes break the
client code, committers who have touched that code in the last few
years should be notified.



HPS: Your change failed to meet these guidelines. Some of us are upset
because these guidelines are fairly fundamental for the on-going
viability of FreeBSD. Due to linguistic / time zone / cultural
differences these expectations have not been adequately communicated
to you. You are not in the USB sandbox where others need for your
support outweighs the inconvenience of random breakage.

It sounds like you are making progress towards updating the concerns
that have been voiced. If kib's observations are in fact comprehensive
then adding a callout_init_cpu function and updating all clients so
that their callouts continue to be scheduled on a CPU other than the
BSP will suffice and we can all move on.

Thanks in advance.


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

Re: svn commit: r277497 - head

[Ed Maste]

On 21 January 2015 at 16:49, Ian Lepore i...@freebsd.org wrote:
 On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote:
 On 21 January 2015 at 15:20, Ian Lepore i...@freebsd.org wrote:
  I don't think
  there's a single addr2line binary I can install that will work with
  every object on the system.

 There is, in fact - ELF Tool Chain's addr2line will work regardless of
 the object's architecture.

 However, I'm happy enough to revert this change (and add a comment
 about non-build use cases) if you like.

 Do you mean the new one you're working on?  Because that doesn't seem to
 be true of the one installed on my 10-stable system right now.  If it is
 true of the new one, that's a much better solution, and I can get by
 until it's ready for prime time, I think.

Yes, the new one I've been working on. It's now the default in HEAD
(along with nm, strings, size, etc.).

Bringing this to stable/10 would be tricky because it depends on the
new libdwarf in 11 that's not backwards compatible. For that reason
perhaps I ought to just leave them in the cross-tools stage, until we
can assume developers are generally cross building from an 11.x host.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Warner Losh]

 On Jan 21, 2015, at 4:38 PM, K. Macy km...@freebsd.org wrote:
 
 They originally found that things were spinning for way too long.
 
 Hans found something similar and determined/concluded that the
 migration code in callouts was racy-by-design and dramatically
 simplified it and also put very hard constraints on what is a valid
 situation to support migrating from one callwheel to another. Now we
 have fallout which we can either address or back out until the callout
 stuff is again reviewed/fixed.
 
 I don't think it's as alchemic as is being promoted.
 
 
 Let's not get drawn into semantic debates. To me alchemy implies
 voodoo debugging, whereas this is, in part, disabling functionality
 that exposes races - which is more like disabling preemption or fine
 grained locking.
 
 
 Normally I would advocate backing this out on the basis of precedence.
 That is to say, back it out so that developers will get it right the
 first time. However, it appears that hps@ and some others don't
 understand what was done wrong. So I'm going to state some basic
 premises and then the implied basic guidelines required of a commit
 that were not met. If these guidelines are violated by a change in the
 future I will agitate for a rapid back out.
 
 Premises:
 A) A performance regression is a bug every bit as much as a locking
 race. Stability OR performance (where we are talking about _current_
 performance) is a false dichotomy.
   - This means that a change that fixes a bug by introducing a
 substantial performance regression does not constitute a fix.
 B) Existing behavior and performance characteristics should not be
 adversely changed unless there is widespread consensus.
  - Sometimes it is necessary to break a KPI but that should not be
 discovered by svn or scanning back through the mailing lists.
 
 Guidelines:
 A) Performance should not measurably regress.
 B) If a KPI changes behavior e.g. callout_reset_on being crippled, all
 clients need to be updated so that they maintain their current
 behavior by the committer changing the KPI. The client code
 maintainers aren't responsible for reacting to these types of changes.
 That is OK for marginal architectures like sun4v or pc98.
 C) If there is a non-zero possibility that these changes break the
 client code, committers who have touched that code in the last few
 years should be notified.
 
 
 
 HPS: Your change failed to meet these guidelines. Some of us are upset
 because these guidelines are fairly fundamental for the on-going
 viability of FreeBSD. Due to linguistic / time zone / cultural
 differences these expectations have not been adequately communicated
 to you. You are not in the USB sandbox where others need for your
 support outweighs the inconvenience of random breakage.
 
 It sounds like you are making progress towards updating the concerns
 that have been voiced. If kib's observations are in fact comprehensive
 then adding a callout_init_cpu function and updating all clients so
 that their callouts continue to be scheduled on a CPU other than the
 BSP will suffice and we can all move on.

Is there some reason that we can’t back things out, break things down into
smaller pieces and have everything pass through phabric with a wide
ranging review? Given the fundamental nature of these changes, they
really need better review and doing it after the fact seems to be to be
too risky. I’m not debating that this “fixes” some issues, but given the
performance regression, it sure seems like we may need a different
solution to be implemented and hashing that out in a branch might be
the best approach.

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

svn commit: r277518 - head/tools/tools/nanobsd

[Will Andrews]

Author: will
Date: Thu Jan 22 00:52:34 2015
New Revision: 277518
URL: https://svnweb.freebsd.org/changeset/base/277518

Log:
  Enable nanobsd.sh to be executed when pwd != NANO_SRC.
  
  While here, fix a bug in which NANO_PMAKE would not be appended at the
  appropriate time.
  
  Simply move both checks to after the call to set_defaults_and_export().
  
  Tested by:lstewart
  Sponsored by: Spectra Logic

Modified:
  head/tools/tools/nanobsd/nanobsd.sh   (contents, props changed)

Modified: head/tools/tools/nanobsd/nanobsd.sh
==
--- head/tools/tools/nanobsd/nanobsd.sh Wed Jan 21 21:49:03 2015
(r277517)
+++ head/tools/tools/nanobsd/nanobsd.sh Thu Jan 22 00:52:34 2015
(r277518)
@@ -121,6 +121,13 @@ if [ $# -gt 0 ] ; then
usage
 fi
 
+###
+# And then it is as simple as that...
+
+# File descriptor 3 is used for logging output, see pprint
+exec 31
+set_defaults_and_export
+
 if [ ! -d ${NANO_TOOLS} ]; then
echo NANO_TOOLS directory does not exist 12
exit 1
@@ -130,13 +137,6 @@ if ! $do_clean; then
NANO_PMAKE=${NANO_PMAKE} -DNO_CLEAN
 fi
 
-###
-# And then it is as simple as that...
-
-# File descriptor 3 is used for logging output, see pprint
-exec 31
-set_defaults_and_export
-
 pprint 1 NanoBSD image ${NANO_NAME} build starting
 
 if $do_world ; then
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277497 - head

[Warner Losh]

 On Jan 21, 2015, at 5:35 PM, Ed Maste ema...@freebsd.org wrote:
 
 On 21 January 2015 at 16:49, Ian Lepore i...@freebsd.org wrote:
 On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote:
 On 21 January 2015 at 15:20, Ian Lepore i...@freebsd.org wrote:
 I don't think
 there's a single addr2line binary I can install that will work with
 every object on the system.
 
 There is, in fact - ELF Tool Chain's addr2line will work regardless of
 the object's architecture.
 
 However, I'm happy enough to revert this change (and add a comment
 about non-build use cases) if you like.
 
 Do you mean the new one you're working on?  Because that doesn't seem to
 be true of the one installed on my 10-stable system right now.  If it is
 true of the new one, that's a much better solution, and I can get by
 until it's ready for prime time, I think.
 
 Yes, the new one I've been working on. It's now the default in HEAD
 (along with nm, strings, size, etc.).
 
 Bringing this to stable/10 would be tricky because it depends on the
 new libdwarf in 11 that's not backwards compatible. For that reason
 perhaps I ought to just leave them in the cross-tools stage, until we
 can assume developers are generally cross building from an 11.x host.

There’s little harm in leaving it in, and some harm in taking it out… The time 
to build
this stuff is tiny...

Warner

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

Re: svn commit: r275832 - head/tools/tools/nanobsd

[Lawrence Stewart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/22/15 02:23, Will Andrews wrote:
 On Wed, Jan 21, 2015 at 06:51:23PM +1100, Lawrence Stewart wrote:
 I think this change introduced a bug - I'm seeing nanobsd error 
 out with the NANO_TOOLS directory does not exist message.
 
 The problem is that NANO_TOOLS is initialised to 
 tools/tools/nanobsd, and you changed the test in nanobsd.sh to 
 *not* check for ${NANO_SRC}/${NANO_TOOLS}, which errors out 
 except if the cwd is ${NANO_SRC}.
 
 You tweak NANO_TOOLS appropriately in set_defaults_and_export() 
 but it's run after the dir test. There are a couple of ways to 
 fix but I'll leave it to you to decide which you prefer.
 
 Will this work for you?
 
 https://people.freebsd.org/~will/patches/nanobsd.sh.diff
 
 This also fixes another bug where NANO_PMAKE would be modified too 
 early.

Yes, looks good to me and fixes the issue I reported. Please commit.

Cheers,
Lawrence
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJUwC4GXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RkIyRTlBMzM5RUE3OEExNUUxREI4QTI5
QTUwQkNGQ0Y0MEQ5QjA5AAoJEJpQvPz0DZsJ40QP+gOt9Sl11w5jLOxwfEYYKNCb
AjFkwhpmbAlpLMFR7OR7DvlRG6svHaO7RzK7pTbEHID3igdSx3+NRpBE+tyAe8fC
dl2hSmGLcGq6007HCGOZGW181tfv9BrRRxKwEXEP7sGhByR5hyFy0JweaLr0TpGb
8CruuZ3hUjDEaTMIBPhBaMWMNsWHJy6Qszj3iE8FwFnmMLnC9yXbfKTXP3iT88wd
y+Aq86Y5NT4HytcbWOaNa6mvQTsZfxnFIVppN+u3AWpgzhh76HzOgeFKK4Wj32/j
eK3v/hi/aSmOaW5AKR10n2ADutjFvMLaHhMVVIOIBTJ6KQ7W38PGR4/sTqbxkAqa
AUsTm53Bz9w3fjr4YhNzOtu0nwgcD1LyUJKnwoyUig97BL8Ogphj+I/4rzB150uD
dnvgLoqY8Qh2ck0eciFiKZdY9k5t0cpQPNwpRl/L+wssKbdKGg4/0Ob5/fy9HVkx
JrcrkmNyIMpLsN683OMNgvbIB5ow6Ya2cNmJtHVS8N8sJ7/Sd4RYPfEWIk7UUX9b
lv+NQm42CyERE98TvE6felmb+iLFF79D2e0wJAis+pbDf8KlMIC3DBjdXls+BEZm
048o1sulxUuo2YMnQHF1sP6bZgeCwI9LslJGlXmLG8WA2oL5I9GJfnkwyD6rbJyx
668QEgpTzhLuAUBXGMT8
=QGdi
-END PGP SIGNATURE-
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277497 - head

[Ian Lepore]

On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote:
 On 21 January 2015 at 15:20, Ian Lepore i...@freebsd.org wrote:
  I don't think
  there's a single addr2line binary I can install that will work with
  every object on the system.
 
 There is, in fact - ELF Tool Chain's addr2line will work regardless of
 the object's architecture.
 
 However, I'm happy enough to revert this change (and add a comment
 about non-build use cases) if you like.

Do you mean the new one you're working on?  Because that doesn't seem to
be true of the one installed on my 10-stable system right now.  If it is
true of the new one, that's a much better solution, and I can get by
until it's ready for prime time, I think.

-- Ian


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

Re: svn commit: r275832 - head/tools/tools/nanobsd

[Will Andrews]

On Thu, Jan 22, 2015 at 09:54:04AM +1100, Lawrence Stewart wrote:
 Yes, looks good to me and fixes the issue I reported. Please commit.

Done in r277518.  Thanks for the quick test.

-- 
wca


pgp76MlrXeDmC.pgp
Description: PGP signature

Re: svn commit: r277421 - head/sys/powerpc/powerpc

[Warner Losh]

 On Jan 21, 2015, at 12:54 AM, Konstantin Belousov kostik...@gmail.com wrote:
 
 On Tue, Jan 20, 2015 at 07:59:08PM -0800, Nathan Whitehorn wrote:
 
 On 01/20/15 11:14, Konstantin Belousov wrote:
 On Tue, Jan 20, 2015 at 04:21:59PM +, Nathan Whitehorn wrote:
 Author: nwhitehorn
 Date: Tue Jan 20 16:21:59 2015
 New Revision: 277421
 URL: https://svnweb.freebsd.org/changeset/base/277421
 
 Log:
   There does not seem to be any reason to acquire GIANT here. Follow amd64
   in removing it.
 
   MFC after:   1 month
 
 Modified:
   head/sys/powerpc/powerpc/mem.c
 
 Modified: head/sys/powerpc/powerpc/mem.c
 ==
 --- head/sys/powerpc/powerpc/mem.c Tue Jan 20 15:45:09 2015
 (r277420)
 +++ head/sys/powerpc/powerpc/mem.c Tue Jan 20 16:21:59 2015
 (r277421)
 @@ -100,8 +100,6 @@ memrw(struct cdev *dev, struct uio *uio,
cnt = 0;
error = 0;
 
 -  GIANT_REQUIRED;
 -
 This is not an acquisition, to be pedantic.  Really, it is cdevsw which
 has D_NEEDGIANT flag which acquires Giant.  After architectures get
 rid of GIANT_REQUIRED, flag can be removed.
 
 Just so I understand, you are not objecting to this commit, right?
 Absolutely not, this is the right thing to do.
 
 Just 
 pointing out that (a) my commit message was wrong and that (b) once all 
 architectures make this change (presumably more involved) we can get rid 
 of the D_NEEDGIANT in /sys/dev/mem/memdev.c?
 Exactly.

There doesn’t seem to be a reason for i386 either. Was just looking at the code 
today on the plane for unrelated reasons.

Warner

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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Warner Losh]

 On Jan 20, 2015, at 12:51 AM, Konstantin Belousov kostik...@gmail.com wrote:
 Do other people consider this situation acceptable ?

Not even a little.

Warner

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

Re: svn commit: r276747 - head/sys/netpfil/pf

[Gleb Smirnoff]

On Tue, Jan 06, 2015 at 09:03:04AM +, Craig Rodrigues wrote:
C Author: rodrigc
C Date: Tue Jan  6 09:03:03 2015
C New Revision: 276747
C URL: https://svnweb.freebsd.org/changeset/base/276747
C 
C Log:
C   Instead of creating a purge thread for every vnet, create
C   a single purge thread and clean up all vnets from this thread.
C   
C   PR: 194515
C   Differential Revision:  D1315
C   Submitted by:   Nikos Vassiliadis nv...@gmx.com

Sorry guys, I backed this out due to broken kldunload of pf module, which
is critical when you are working with pf bugs.

I had to backout r276746 as well, since it has numerous build breakages,
that are addressed by later revisions.

That's my fault that I don't review in time, and I will try to improve
the situation.

Can you please replay r276746 again, addressing all the build problems
and send the patch to me? You can user reviews.freebsd.org if you want.

I'd like to get this in, but in a better quality.

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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Warner Losh]

 On Jan 20, 2015, at 12:35 AM, Hans Petter Selasky h...@selasky.org wrote:
 
 On 01/20/15 06:22, Adrian Chadd wrote:
 Sweet, thanks. I'l test it, but anything that changes the locking to
 TCP is going to need a more thorough review. The there be dragons
 disclaimer is appropriate.:)
 
 No changes in locking - simply some minor code reordering.

This isn’t entirely true. You changed the INFO_WLOCK protocol, and also drop 
the WLOCK to acquire the INFO_WLOCK in places, and it isn’t clear to me at all 
why this is safe to do. Please document the analysis you did to show that was 
safe.

Warner

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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Warner Losh]

 On Jan 20, 2015, at 2:37 AM, Hans Petter Selasky h...@selasky.org wrote:
 
 On 01/20/15 10:00, Konstantin Belousov wrote:
 On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
 On 01/20/15 08:51, Konstantin Belousov wrote:
 On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
 On 01/19/15 22:59, Adrian Chadd wrote:
 Hi,
 
 Would you please check what the results of this are with CPU specific
 callwheels?
 
 I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
 ixgbe) and with this setup, the per-CPU TCP callwheel stuff is
 enabled. But all the callwheels are now back on clock(0) and so is the
 lock contention. :(
 
 Thanks,
 
 
 Hi,
 
 Like stated in the manual page, callout_reset_curcpu/on() does not work
 with MPSAFE callouts any more!
 I.e. you 'fixed' some undeterminate bugs in callout migration by not
 doing migration at all anymore.
 
 
 You need to use callout_init_{mtx,rm,rw} and remove the custom locking
 inside the callback in the TCP stack to get it working like before!
 
 No, you need to do this, if you think that whole callout KPI must be
 rototiled.  It is up to the person who modifies the KPI, to ensure that
 existing code is not broken.
 
 Hi,
 
 It is not very hard to update existing callout clients and you can do it too, 
 if you need the extra bits of performance.
 
 Are there more API's than the TCP stack which you think needs an update and 
 are performance critical?
 
 
 As I understand, currently we are back to the one-cpu callouts.
 Do other people consider this situation acceptable ?
 
 For the TCP stack - yes, but not for other clients like cv_timedwait() and 
 such.
 
 If you think you have a better way to solve the callout problems, please tell 
 me! In order for a callout to change its CPU you need a lock to protect which 
 CPU the callout is on. Instead of introducing a third lock in the callout 
 path, which will be a congestion point, to protect against changing the CPU 
 number, I decided that we will use the client's mutex and the MPSAFE implies 
 the client doesn't have any mutex. So it won't work with callout clients 
 which use the CALLOUT_MPSAFE flag. Honestly CALLOUT_MPSAFE should not be 
 used, because it leads to extra complexity in the clients catching the race 
 when tearing down the callouts and any pending callbacks.

Then it is incumbent on you to fix them. You can’t just fix one instance and 
wash your hands of the problem.

Maybe this is a real and legitimate bug. However, until you’ve followed your 
solution through by actually fixing the abusers of it, my confidence that 
another issue won’t present itself is quite low. The code seems half baked to 
me. And from reading this thread, it seems like perhaps I’m not the only one.

 Please read the callout 9 manual page first.
 
 Assume I read it.  How this changes any of my points above ?
 
 A change in the CPU selection cannot happen if this function is
 re-scheduled inside a callout function. Else the callback function given
 by the func argument will be executed on the same CPU like previously
 done.
 
 You cannot do this without fixing consumers.
 
 
 The code simply needs an update. It is not broken in any ways - right? If it 
 is not broken, fixing it is not that urgent.

Radically changing the performance characteristics is breaking the code. 
Performance regression in the TCP stack is urgent to fix. Not being able to 
enumerate what all the consumers are that use this and provide an analysis 
about why they aren’t important to fix is a bug in your process, and in your 
interaction with the project. We simply do not operate that way.

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

Re: svn commit: r277517 - head

[Juli Mallett]

On Wed, Jan 21, 2015 at 1:49 PM, Ed Maste ema...@freebsd.org wrote:
 Author: emaste
 Date: Wed Jan 21 21:49:03 2015
 New Revision: 277517
 URL: https://svnweb.freebsd.org/changeset/base/277517

 Log:
   Fix bootstrap on systems with old libdwarf and WITHOUT_CDDL

   ELF Tool Chain tools need libelf and libdwarf.

Thanks very much!
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277523 - head/sys/arm/arm

[Oleksandr Tymoshenko]

Author: gonzo
Date: Thu Jan 22 03:33:51 2015
New Revision: 277523
URL: https://svnweb.freebsd.org/changeset/base/277523

Log:
  Add last_fault_code used in pmap-v6.c if kernel is compiled with option 
DEBUG

Modified:
  head/sys/arm/arm/trap-v6.c

Modified: head/sys/arm/arm/trap-v6.c
==
--- head/sys/arm/arm/trap-v6.c  Thu Jan 22 03:32:04 2015(r277522)
+++ head/sys/arm/arm/trap-v6.c  Thu Jan 22 03:33:51 2015(r277523)
@@ -67,6 +67,10 @@ __FBSDID($FreeBSD$);
 
 extern char fusubailout[];
 
+#ifdef DEBUG
+int last_fault_code;   /* For the benefit of pmap_fault_fixup() */
+#endif
+
 struct ksig {
int sig;
u_long code;
@@ -457,6 +461,10 @@ abort_handler(struct trapframe *tf, int 
if (prefetch)
ftype |= VM_PROT_EXECUTE;
 
+#ifdef DEBUG
+   last_fault_code = fsr;
+#endif
+
 #ifndef ARM_NEW_PMAP
if (pmap_fault_fixup(vmspace_pmap(td-td_proc-p_vmspace), va, ftype,
usermode)) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277519 - in head/sys: net netpfil/pf

[Gleb Smirnoff]

Author: glebius
Date: Thu Jan 22 01:23:16 2015
New Revision: 277519
URL: https://svnweb.freebsd.org/changeset/base/277519

Log:
  Back out r276841, r276756, r276747, r276746. The change in r276747 is very
  very questionable, since it makes vimages more dependent on each other. But
  the reason for the backout is that it screwed up shutting down the pf purge
  threads, and now kernel immedially panics on pf module unload. Although module
  unloading isn't an advertised feature of pf, it is very important for
  development process.
  
  I'd like to not backout r276746, since in general it is good. But since it
  has introduced numerous build breakages, that later were addressed in
  r276841, r276756, r276747, I need to back it out as well. Better replay it
  in clean fashion from scratch.

Modified:
  head/sys/net/pfvar.h
  head/sys/netpfil/pf/pf.c
  head/sys/netpfil/pf/pf_if.c
  head/sys/netpfil/pf/pf_ioctl.c
  head/sys/netpfil/pf/pf_norm.c
  head/sys/netpfil/pf/pf_table.c

Modified: head/sys/net/pfvar.h
==
--- head/sys/net/pfvar.hThu Jan 22 00:52:34 2015(r277518)
+++ head/sys/net/pfvar.hThu Jan 22 01:23:16 2015(r277519)
@@ -829,6 +829,7 @@ typedef int pflog_packet_t(struct pfi_ki
 struct pf_ruleset *, struct pf_pdesc *, int);
 extern pflog_packet_t  *pflog_packet_ptr;
 
+#defineV_pf_end_threadsVNET(pf_end_threads)
 #endif /* _KERNEL */
 
 #definePFSYNC_FLAG_SRCNODE 0x04
@@ -1494,7 +1495,7 @@ VNET_DECLARE(struct pf_altqqueue *,pf_
 VNET_DECLARE(struct pf_rulequeue, pf_unlinked_rules);
 #defineV_pf_unlinked_rules VNET(pf_unlinked_rules)
 
-voidpf_vnet_initialize(void);
+voidpf_initialize(void);
 voidpf_mtag_initialize(void);
 voidpf_mtag_cleanup(void);
 voidpf_cleanup(void);
@@ -1586,7 +1587,7 @@ int   pf_match_addr_range(struct pf_addr *
struct pf_addr *, sa_family_t);
 intpf_match_port(u_int8_t, u_int16_t, u_int16_t, u_int16_t);
 
-void   pf_vnet_normalize_init(void);
+void   pf_normalize_init(void);
 void   pf_normalize_cleanup(void);
 intpf_normalize_ip(struct mbuf **, int, struct pfi_kif *, u_short *,
struct pf_pdesc *);
@@ -1648,7 +1649,7 @@ MALLOC_DECLARE(PFI_MTYPE);
 VNET_DECLARE(struct pfi_kif *,  pfi_all);
 #defineV_pfi_allVNET(pfi_all)
 
-voidpfi_vnet_initialize(void);
+voidpfi_initialize(void);
 voidpfi_cleanup(void);
 voidpfi_kif_ref(struct pfi_kif *);
 voidpfi_kif_unref(struct pfi_kif *);

Modified: head/sys/netpfil/pf/pf.c
==
--- head/sys/netpfil/pf/pf.cThu Jan 22 00:52:34 2015(r277518)
+++ head/sys/netpfil/pf/pf.cThu Jan 22 01:23:16 2015(r277519)
@@ -151,7 +151,6 @@ static VNET_DEFINE(struct pf_send_head, 
 #defineV_pf_sendqueue  VNET(pf_sendqueue)
 
 static struct mtx pf_sendqueue_mtx;
-MTX_SYSINIT(pf_sendqueue_mtx, pf_sendqueue_mtx, pf send queue, MTX_DEF);
 #definePF_SENDQ_LOCK() mtx_lock(pf_sendqueue_mtx)
 #definePF_SENDQ_UNLOCK()   mtx_unlock(pf_sendqueue_mtx)
 
@@ -173,15 +172,11 @@ static VNET_DEFINE(struct task, pf_overl
 #defineV_pf_overloadtask   VNET(pf_overloadtask)
 
 static struct mtx pf_overloadqueue_mtx;
-MTX_SYSINIT(pf_overloadqueue_mtx, pf_overloadqueue_mtx,
-pf overload/flush queue, MTX_DEF);
 #definePF_OVERLOADQ_LOCK() mtx_lock(pf_overloadqueue_mtx)
 #definePF_OVERLOADQ_UNLOCK()   mtx_unlock(pf_overloadqueue_mtx)
 
 VNET_DEFINE(struct pf_rulequeue, pf_unlinked_rules);
 struct mtx pf_unlnkdrules_mtx;
-MTX_SYSINIT(pf_unlnkdrules_mtx, pf_unlnkdrules_mtx, pf unlinked rules,
-MTX_DEF);
 
 static VNET_DEFINE(uma_zone_t, pf_sources_z);
 #defineV_pf_sources_z  VNET(pf_sources_z)
@@ -295,6 +290,8 @@ static void  pf_route6(struct mbuf **, 
 
 int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len);
 
+VNET_DECLARE(int, pf_end_threads);
+
 VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]);
 
 #definePACKET_LOOPED(pd)   ((pd)-pf_mtag
\
@@ -731,7 +728,7 @@ pf_mtag_initialize()
 
 /* Per-vnet data storage structures initialization. */
 void
-pf_vnet_initialize()
+pf_initialize()
 {
struct pf_keyhash   *kh;
struct pf_idhash*ih;
@@ -791,9 +788,13 @@ pf_vnet_initialize()
STAILQ_INIT(V_pf_sendqueue);
SLIST_INIT(V_pf_overloadqueue);
TASK_INIT(V_pf_overloadtask, 0, pf_overload_task, curvnet);
+   mtx_init(pf_sendqueue_mtx, pf send queue, NULL, MTX_DEF);
+   mtx_init(pf_overloadqueue_mtx, pf overload/flush queue, NULL,
+   MTX_DEF);
 
/* Unlinked, 

svn commit: r277522 - head/sys/arm/ti/am335x

[Oleksandr Tymoshenko]

Author: gonzo
Date: Thu Jan 22 03:32:04 2015
New Revision: 277522
URL: https://svnweb.freebsd.org/changeset/base/277522

Log:
  Write ACK for all kinds of LCDC interrupts

Modified:
  head/sys/arm/ti/am335x/am335x_lcd.c

Modified: head/sys/arm/ti/am335x/am335x_lcd.c
==
--- head/sys/arm/ti/am335x/am335x_lcd.c Thu Jan 22 02:24:42 2015
(r277521)
+++ head/sys/arm/ti/am335x/am335x_lcd.c Thu Jan 22 03:32:04 2015
(r277522)
@@ -365,7 +365,7 @@ am335x_lcd_intr(void *arg)
reg = LCD_READ4(sc, LCD_RASTER_CTRL);
reg |= RASTER_CTRL_LCDEN;
LCD_WRITE4(sc, LCD_RASTER_CTRL, reg); 
-   return;
+   goto done;
}
 
if (reg  IRQ_PL) {
@@ -376,7 +376,7 @@ am335x_lcd_intr(void *arg)
reg = LCD_READ4(sc, LCD_RASTER_CTRL);
reg |= RASTER_CTRL_LCDEN;
LCD_WRITE4(sc, LCD_RASTER_CTRL, reg); 
-   return;
+   goto done;
}
 
if (reg  IRQ_EOF0) {
@@ -399,6 +399,7 @@ am335x_lcd_intr(void *arg)
/* TODO: Handle ACB */
}
 
+done:
LCD_WRITE4(sc, LCD_END_OF_INT_IND, 0);
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277524 - in head/sys: dev/hwpmc sys

[Ryan Stone]

Author: rstone
Date: Thu Jan 22 03:56:23 2015
New Revision: 277524
URL: https://svnweb.freebsd.org/changeset/base/277524

Log:
  style(9) cleanup

Modified:
  head/sys/dev/hwpmc/hwpmc_core.c
  head/sys/dev/hwpmc/pmc_events.h
  head/sys/sys/pmc.h

Modified: head/sys/dev/hwpmc/hwpmc_core.c
==
--- head/sys/dev/hwpmc/hwpmc_core.c Thu Jan 22 03:33:51 2015
(r277523)
+++ head/sys/dev/hwpmc/hwpmc_core.c Thu Jan 22 03:56:23 2015
(r277524)
@@ -680,7 +680,8 @@ static struct iap_event_descr iap_events
 IAPDESCR(08H_0EH, 0x08, 0x0E, IAP_F_FM | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(08H_10H, 0x08, 0x10, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB |
IAP_F_SBX | IAP_F_HW | IAP_F_HWX),
-IAPDESCR(08H_20H, 0x08, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(08H_20H, 0x08, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW |
+IAP_F_HWX),
 IAPDESCR(08H_40H, 0x08, 0x40, IAP_F_FM | IAP_F_I7O | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(08H_60H, 0x08, 0x60, IAP_F_FM | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(08H_80H, 0x08, 0x80, IAP_F_FM | IAP_F_I7 | IAP_F_HW | IAP_F_HWX),
@@ -710,9 +711,12 @@ static struct iap_event_descr iap_events
 IAPDESCR(0EH_01H, 0x0E, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB |
IAP_F_IB | IAP_F_SBX | IAP_F_IBX | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(0EH_02H, 0x0E, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM),
-IAPDESCR(0EH_10H, 0x0E, 0x10, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
-IAPDESCR(0EH_20H, 0x0E, 0x20, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
-IAPDESCR(0EH_40H, 0x0E, 0x40, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(0EH_10H, 0x0E, 0x10, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
+IAPDESCR(0EH_20H, 0x0E, 0x20, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
+IAPDESCR(0EH_40H, 0x0E, 0x40, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
 
 IAPDESCR(0FH_01H, 0x0F, 0x01, IAP_F_FM | IAP_F_I7),
 IAPDESCR(0FH_02H, 0x0F, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM),
@@ -826,7 +830,8 @@ static struct iap_event_descr iap_events
 IAPDESCR(24H_AAH, 0x24, 0xAA, IAP_F_FM | IAP_F_I7 | IAP_F_WM),
 IAPDESCR(24H_F8H, 0x24, 0xF8, IAP_F_FM | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(24H_3FH, 0x24, 0x3F, IAP_F_FM | IAP_F_HW | IAP_F_HWX),
-IAPDESCR(24H_FFH, 0x24, 0xFF, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(24H_FFH, 0x24, 0xFF, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW |
+IAP_F_HWX),
 
 IAPDESCR(25H, 0x25, IAP_M_CORE, IAP_F_ALLCPUSCORE2),
 
@@ -967,7 +972,8 @@ static struct iap_event_descr iap_events
 IAPDESCR(49H_20H, 0x49, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(49H_40H, 0x49, 0x40, IAP_F_FM | IAP_F_I7O | IAP_F_HW | IAP_F_HWX),
 IAPDESCR(49H_60H, 0x49, 0x60, IAP_F_FM | IAP_F_HW | IAP_F_HWX),
-IAPDESCR(49H_80H, 0x49, 0x80, IAP_F_FM | IAP_F_WM | IAP_F_I7 | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(49H_80H, 0x49, 0x80, IAP_F_FM | IAP_F_WM | IAP_F_I7 | IAP_F_HW |
+IAP_F_HWX),
 
 IAPDESCR(4BH_00H, 0x4B, 0x00, IAP_F_FM | IAP_F_ALLCPUSCORE2),
 IAPDESCR(4BH_01H, 0x4B, 0x01, IAP_F_FM | IAP_F_ALLCPUSCORE2 | IAP_F_I7O),
@@ -1008,10 +1014,14 @@ static struct iap_event_descr iap_events
 
 IAPDESCR(53H_01H, 0x53, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM),
 
-IAPDESCR(58H_01H, 0x58, 0x01, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
-IAPDESCR(58H_02H, 0x58, 0x02, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
-IAPDESCR(58H_04H, 0x58, 0x04, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
-IAPDESCR(58H_08H, 0x58, 0x08, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(58H_01H, 0x58, 0x01, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
+IAPDESCR(58H_02H, 0x58, 0x02, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
+IAPDESCR(58H_04H, 0x58, 0x04, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
+IAPDESCR(58H_08H, 0x58, 0x08, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
 
 IAPDESCR(59H_20H, 0x59, 0x20, IAP_F_FM | IAP_F_SB | IAP_F_SBX),
 IAPDESCR(59H_40H, 0x59, 0x40, IAP_F_FM | IAP_F_SB | IAP_F_SBX),
@@ -1114,8 +1124,8 @@ static struct iap_event_descr iap_events
 
 IAPDESCR(79H_30H, 0x79, 0x30, IAP_F_FM | IAP_F_SB | IAP_F_IB |
IAP_F_SBX | IAP_F_IBX | IAP_F_HW | IAP_F_HWX),
-
-IAPDESCR(79H_3CH, 0x79, 0x3C, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | 
IAP_F_HWX),
+IAPDESCR(79H_18H, 0x79, 0x18, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW |
+IAP_F_HWX),
 
 IAPDESCR(7AH, 0x7A, IAP_M_AGENT, IAP_F_CA | IAP_F_CC2),
 
@@ -1367,7 +1377,8 @@ static struct iap_event_descr iap_events
 IAPDESCR(B6H_04H, 0xB6, 0x04, IAP_F_CAS),
 
 IAPDESCR(B7H_01H, 0xB7, 0x01, 

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Hans Petter Selasky]

On 01/22/15 06:26, Warner Losh wrote:


The code simply needs an update. It is not broken in any ways - right? If it is 
not broken, fixing it is not that urgent.


Radically changing the performance characteristics is breaking the code. 
Performance regression in the TCP stack is urgent to fix. Not being able to 
enumerate what all the consumers are that use this and provide an analysis 
about why they aren’t important to fix is a bug in your process, and in your 
interaction with the project. We simply do not operate that way.


Hi,

My plan is to work out a patch for the TCP stack today, which only 
change the callout_init() call or its function. This should not need any 
particular review. I'll let adrian test and review, because I think he 
is closer to me timezone wise and you're standing on my head saying its 
urgent. If he is still not happy, I can back my change out. Else it 
remains in -current AS-IS. MFC to 10-stable I can delay for sure until 
all issues you report to me are fixed.


Thank you for your patience!

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

svn commit: r277509 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 20:05:10 2015
New Revision: 277509
URL: https://svnweb.freebsd.org/changeset/base/277509

Log:
  Properly lock accesss to the firewire_comm-devices list.
  
  sys/dev/firewire/firewire.c:
Add missing FW_GLOCK/UNLOCK() usage to fw_noderesolve_nodeid().
  
  sys/dev/firewire/firewire.c:
  sys/dev/firewire/fwmem.c:
Remove no-op splfw() calls from functions that have been
audited for proper lock usage.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110992 on 2015/01/06

Modified:
  head/sys/dev/firewire/firewire.c
  head/sys/dev/firewire/fwmem.c

Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 20:03:46 2015
(r277508)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:05:10 2015
(r277509)
@@ -146,13 +146,12 @@ struct fw_device *
 fw_noderesolve_nodeid(struct firewire_comm *fc, int dst)
 {
struct fw_device *fwdev;
-   int s;
 
-   s = splfw();
+   FW_GLOCK(fc);
STAILQ_FOREACH(fwdev, fc-devices, link)
if (fwdev-dst == dst  fwdev-status != FWDEVINVAL)
break;
-   splx(s);
+   FW_GUNLOCK(fc);
 
return fwdev;
 }
@@ -164,15 +163,12 @@ struct fw_device *
 fw_noderesolve_eui64(struct firewire_comm *fc, struct fw_eui64 *eui)
 {
struct fw_device *fwdev;
-   int s;
 
-   s = splfw();
FW_GLOCK(fc);
STAILQ_FOREACH(fwdev, fc-devices, link)
if (FW_EUI64_EQUAL(fwdev-eui, *eui))
break;
FW_GUNLOCK(fc);
-   splx(s);
 
if (fwdev == NULL)
return NULL;
@@ -301,9 +297,7 @@ static void
 fw_asystart(struct fw_xfer *xfer)
 {
struct firewire_comm *fc = xfer-fc;
-   int s;
 
-   s = splfw();
/* Protect from interrupt/timeout */
FW_GLOCK(fc);
xfer-flag = FWXF_INQ;
@@ -312,7 +306,6 @@ fw_asystart(struct fw_xfer *xfer)
xfer-q-queued++;
 #endif
FW_GUNLOCK(fc);
-   splx(s);
/* XXX just queue for mbuf */
if (xfer-mbuf == NULL)
xfer-q-start(fc);
@@ -332,6 +325,7 @@ firewire_probe(device_t dev)
return (0);
 }
 
+/* Just use a per-packet callout? */
 static void
 firewire_xfer_timeout(void *arg, int pending)
 {
@@ -340,7 +334,7 @@ firewire_xfer_timeout(void *arg, int pen
struct timeval tv;
struct timeval split_timeout;
STAILQ_HEAD(, fw_xfer) xfer_timeout;
-   int i, s;
+   int i;
 
split_timeout.tv_sec = 0;
split_timeout.tv_usec = 200 * 1000;  /* 200 msec */
@@ -349,9 +343,8 @@ firewire_xfer_timeout(void *arg, int pen
timevalsub(tv, split_timeout);
STAILQ_INIT(xfer_timeout);
 
-   s = splfw();
mtx_lock(fc-tlabel_lock);
-   for (i = 0; i  0x40; i++) {
+   for (i = 0; i  nitems(fc-tlabels); i++) {
while ((xfer = STAILQ_FIRST(fc-tlabels[i])) != NULL) {
if ((xfer-flag  FWXF_SENT) == 0)
/* not sent yet */
@@ -370,7 +363,6 @@ firewire_xfer_timeout(void *arg, int pen
}
}
mtx_unlock(fc-tlabel_lock);
-   splx(s);
fc-timeout(fc);
 
STAILQ_FOREACH_SAFE(xfer, xfer_timeout, tlabel, txfer)

Modified: head/sys/dev/firewire/fwmem.c
==
--- head/sys/dev/firewire/fwmem.c   Wed Jan 21 20:03:46 2015
(r277508)
+++ head/sys/dev/firewire/fwmem.c   Wed Jan 21 20:05:10 2015
(r277509)
@@ -348,12 +348,11 @@ fwmem_strategy(struct bio *bp)
struct fw_device *fwdev;
struct fw_xfer *xfer;
struct cdev *dev;
-   int err = 0, s, iolen;
+   int err = 0, iolen;
 
dev = bp-bio_dev;
/* XXX check request length */
 
-   s = splfw();
fms = dev-si_drv1;
fwdev = fw_noderesolve_eui64(fms-sc-fc, fms-eui);
if (fwdev == NULL) {
@@ -395,7 +394,6 @@ fwmem_strategy(struct bio *bp)
/* XXX */
bp-bio_resid = bp-bio_bcount - iolen;
 error:
-   splx(s);
if (err != 0) {
if (fwmem_debug)
printf(%s: err=%d\n, __func__, err);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277510 - head/sys/dev/firewire

[Will Andrews]

Author: will
Date: Wed Jan 21 20:06:25 2015
New Revision: 277510
URL: https://svnweb.freebsd.org/changeset/base/277510

Log:
  Fix firewire panic when issuing a reply to an unhandled
  asynchronous remote dma request (DMA request that the
  hardware cannot automatically handle).
  
  sys/dev/firewire/firewire.c
In fw_rcv(), add missing early return in the error
path for DMA requests to unregistered regions.
  
  Submitted by: gibbs
  MFC after:1 week
  Sponsored by: Spectra Logic
  MFSpectraBSD: 1110993 on 2015/01/06

Modified:
  head/sys/dev/firewire/firewire.c

Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 20:05:10 2015
(r277509)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:06:25 2015
(r277510)
@@ -2030,6 +2030,7 @@ fw_rcv(struct fw_rcv_buf *rb)
rb-xfer-hand = fw_xfer_free;
if (fw_asyreq(rb-fc, -1, rb-xfer))
fw_xfer_free(rb-xfer);
+   return;
}
len = 0;
for (i = 0; i  rb-nvec; i++)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277497 - head

[Ian Lepore]

On Wed, 2015-01-21 at 15:10 -0500, Ed Maste wrote:
 On 21 January 2015 at 14:04, Ed Maste ema...@freebsd.org wrote:
 
  Author: emaste
  Date: Wed Jan 21 19:04:55 2015
  New Revision: 277497
  URL: https://svnweb.freebsd.org/changeset/base/277497
 
  Log:
Remove addr2line from cross elftoolchain tools list
 
It is not required, and there is no reason to install it just because it
came with the binutils cross tools.
 
 I left some detail out of this commit message and it confused a couple
 of people, so to be clear: this doesn't remove addr2line from the
 world build, only the cross-tools stage.
 

This is still not good for me.  I use the cross-addr2line tool all the
time, and objdump and other such tools.  I have many different sandboxes
with different arch builds of different freebsd versions, and each one
is a self-contained little development world that includes the cross
tools that are known to work with that source base.  I don't think
there's a single addr2line binary I can install that will work with
every object on the system.

If the time spent building these things is bothering people, maybe we
need a WITH_CROSS_BINUTILS knob or something?

-- Ian


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

svn commit: r277484 - head/cddl/contrib/opensolaris/lib/libzpool/common/sys

[Garrett Cooper]

Author: ngie
Date: Wed Jan 21 10:47:28 2015
New Revision: 277484
URL: https://svnweb.freebsd.org/changeset/base/277484

Log:
  Follow up to r277449 by fixing the remaining NSEC_TO_TICK macro to have the 
same
  named parameters
  
  Reported by: Ben Perrault ben.perra...@gmail.com, Willem Jan Withagen 
w...@digiware.nl

Modified:
  head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h

Modified: head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
==
--- head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h Wed Jan 
21 09:45:48 2015(r277483)
+++ head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h Wed Jan 
21 10:47:28 2015(r277484)
@@ -535,7 +535,7 @@ extern vnode_t *rootdir;
 extern void delay(clock_t ticks);
 
 #defineSEC_TO_TICK(sec)((sec) * hz)
-#defineNSEC_TO_TICK(usec)  ((usec) / (NANOSEC / hz))
+#defineNSEC_TO_TICK(nsec)  ((nsec) / (NANOSEC / hz))
 
 #definegethrestime_sec() time(NULL)
 #definegethrestime(t) \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Alexey Dokuchaev]

On Tue, Jan 20, 2015 at 07:06:14PM -0800, Adrian Chadd wrote:
 On 20 January 2015 at 18:19, Alexey Dokuchaev da...@freebsd.org wrote:
  Seconded.  Putting extra harness on the code to avoid bugs in the
  compiler that were actually fixed upsteam is totally bogus.

 Right, but:
 [...]
 * some of us have to use the gcc that's in tree;
 * .. and apparently updating that gcc to something  4.2 is verboten.

To be clear: I did not suggest moving to external toolchain (I hate to do
it myself).  I was talking about merging the fix to base gcc4.2 (provided
that it can be licensed under GPLv2).  Now that most people had lost their
interest in 8.x, it can be a problem of organizational nature, but not
technical.

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

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Dimitry Andric]

On 21 Jan 2015, at 09:10, Navdeep Parhar n...@freebsd.org wrote:
 
 On Wed, Jan 21, 2015 at 09:00:03AM +0100, Dimitry Andric wrote:
 On 21 Jan 2015, at 06:53, Navdeep Parhar n...@freebsd.org wrote:
 
 On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
...
 Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
 I specifically introduced for this issue.
 
 Ah, a rose with another name.  I'm happy to use this but it's not clear why
 there is a GCC in the macro's name when clang deals with -fms-extensions
 just as well.

It's because only gcc (in base) requires this flag to support anonymous
unions, whereas clang also supports them without the flag.  None of the
sources requiring this flag use actual Microsoft C extensions.


  (It's not even clear why the longer ${GCC_MS_EXTENSIONS}
 should be preferred to -fms-extentions.  Isn't this like #define ONE 1 ?)

Using -fms-extensions with clang can lead to other trouble, since it is
stricter about conflicts with Microsoft-reserved type names.  Last time
I ran into this problem, several of our system headers tried to override
type names which are reserved by Microsoft, leading to compile errors.

Meanwhile, that issue may have been solved, but the crutches are still
there.  Instead of the macro, you could also use:

CFLAGS.gcc+= -fms-extensions

But note that this flag is probably superfluous with newer gcc's, so
using the macro is still a better solution, because the compiler version
can be checked in a central location, such as sys/conf/kern.mk.


 In any case I'm perfectly fine with any change that doesn't involve a commit
 from me to gcc.

Fixing this version of gcc is not really worth the trouble, indeed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r277449 - head/sys/cddl/compat/opensolaris/sys

[Adrian Chadd]

... common/sys/zfs_context.h:538 ?



-a


On 20 January 2015 at 14:29, Will Andrews w...@freebsd.org wrote:
 Author: will
 Date: Tue Jan 20 22:29:27 2015
 New Revision: 277449
 URL: https://svnweb.freebsd.org/changeset/base/277449

 Log:
   NSEC_TO_TICK(usec) - NSEC_TO_TICK(nsec)

 Modified:
   head/sys/cddl/compat/opensolaris/sys/time.h

 Modified: head/sys/cddl/compat/opensolaris/sys/time.h
 ==
 --- head/sys/cddl/compat/opensolaris/sys/time.h Tue Jan 20 22:27:45 2015  
   (r277448)
 +++ head/sys/cddl/compat/opensolaris/sys/time.h Tue Jan 20 22:29:27 2015  
   (r277449)
 @@ -51,7 +51,7 @@ typedef longlong_thrtime_t;
  #endif

  #defineSEC_TO_TICK(sec)((sec) * hz)
 -#defineNSEC_TO_TICK(usec)  ((usec) / (NANOSEC / hz))
 +#defineNSEC_TO_TICK(nsec)  ((nsec) / (NANOSEC / hz))

  #ifdef _KERNEL
  static __inline hrtime_t

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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Hans Petter Selasky]

On 01/21/15 01:49, Adrian Chadd wrote:

You should totally try say, 100,000 active TCP connections on a box.
See what happens to swi0 (clock).

TL;DR - the lock contention sucks and it takes a chunk of the core up.
The lock contention is highly not good.

That's why I'd like to see both the callout stuff in its
slightly-better-defined-and-sane state from you/and/  make it so TCP
can use it.

I'll have to double-check to see if the RSS stuff is all lined up
correctly so we can use it when we create the callouts (well, at inpcb
creation time, right), rather than when we first schedule them. Then
we can experiment with having the initial CPU be specified at callout
create time rather than expecting to be able to move it when we first
schedule it.

Or, hm, maybe have it so we don't have a CPU chosen until the first
time we schedule the timeout, and if it hasn't been scheduled before,
allow the CPU to be set? Because at that point we aren't migrating it
off f timeout_cpu - it's never been added to it in the first place.


Hi Adrian,

What you are saying is correct. If you set the initial c_cpu value when 
the callout is initialized it will run on SWI#X instead of SWI#0. This 
is fully allowed, so maybe a callout_init_cpu() would be appropriate, to 
set the initial CPU number for callouts. With regard to the callout the 
c_cpu value can be different from zero, only the it must remain 
fixed/constant when there is no lock protecting updates to it!


Kip and Gleb: Does adding a callout_init_cpu() function which can be 
used for existing callouts and in conjunction with CALLOUT_MPSAFE change 
anything?


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

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Garrett Cooper]

On Jan 21, 2015, at 0:17, Steve Kargl s...@troutmask.apl.washington.edu wrote:

 On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote:
 
 On 01/20/15 22:52, Steve Kargl wrote:
 On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
 On 01/20/15 22:06, Adrian Chadd wrote:
 * .. and apparently updating that gcc to something  4.2 is verboten.
 The external toolchain can't be that bad(?).
 
 Are the ever change knobs documented somewhere?
 
 https://wiki.freebsd.org/ExternalToolchain
 
 IHMO, the wiki is not proper documentation.  'man src.conf'
 should have the information needed.

build(7) seems like a more appropriate area, but I wholeheartedly agree.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

svn commit: r277481 - head/sys/dev/mii

[Kevin Lo]

Author: kevlo
Date: Wed Jan 21 09:01:48 2015
New Revision: 277481
URL: https://svnweb.freebsd.org/changeset/base/277481

Log:
  Typo: ivalid - invalid.

Modified:
  head/sys/dev/mii/mii.c

Modified: head/sys/dev/mii/mii.c
==
--- head/sys/dev/mii/mii.c  Wed Jan 21 05:31:54 2015(r277480)
+++ head/sys/dev/mii/mii.c  Wed Jan 21 09:01:48 2015(r277481)
@@ -374,7 +374,7 @@ mii_attach(device_t dev, device_t *miibu
}
 
if (offloc != MII_OFFSET_ANY  (offloc  0 || offloc = MII_NPHY)) {
-   printf(%s: ivalid offloc %d\n, __func__, offloc);
+   printf(%s: invalid offloc %d\n, __func__, offloc);
return (EINVAL);
}
 
@@ -383,7 +383,7 @@ mii_attach(device_t dev, device_t *miibu
phymax = MII_NPHY - 1;
} else {
if (phyloc  0 || phyloc = MII_NPHY) {
-   printf(%s: ivalid phyloc %d\n, __func__, phyloc);
+   printf(%s: invalid phyloc %d\n, __func__, phyloc);
return (EINVAL);
}
phymin = phymax = phyloc;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Baptiste Daroussin]

On Wed, Jan 21, 2015 at 12:17:14AM -0800, Steve Kargl wrote:
 On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote:
  
  On 01/20/15 22:52, Steve Kargl wrote:
   On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
   On 01/20/15 22:06, Adrian Chadd wrote:
   * .. and apparently updating that gcc to something  4.2 is verboten.
   The external toolchain can't be that bad(?).
  
   Are the ever change knobs documented somewhere?
  
  https://wiki.freebsd.org/ExternalToolchain
  
 
 IHMO, the wiki is not proper documentation.  'man src.conf'
 should have the information needed.
 
Planned into build(7) but not yet done as it is work in progress aka some knobs
might or might not change

Bapt


pgpCWPh3nrMQA.pgp
Description: PGP signature

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Konstantin Belousov]

On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote:
 On 01/21/15 00:53, Sean Bruno wrote:
  Unkown to me.  Nor am I aware of anyone else who ever hit our panics
  either.  Our environment, and the failure, was only seen in the Intel
  10GE space (ixgbe).  This is an artifact of our use cases, and hasn't
  been expanded nor tested in our environment with other vendor interfaces.
 
  sean
 
 Hi,
 
 I've seen this with Mellanox hardware when running some special tests, 
 but not during regular use yet. That was the reason for going into the 
 callout subsystem in the first place. 40GE.
 
 Also I would like to mention during the heat of this discussion, that 
 during X-mas this year, I had a very heavy discussion with Attilio and a 
 few other FreeBSD developers, who's name was on a patch (r220456) that 
 changed how the return value of callout_active() works. 
 callout_active() is heavily used inside the TCP stack and what was 
 found is there is a potential race related to migrating the callout from 
 one CPU to the other, which in turn might give other symptoms than a 
 spinlock hang.
 
 FYI:
 
 https://svnweb.freebsd.org/base?view=revisionrevision=225057
 
 Cite: If the newly scheduled thread wants to acquire the old queue it 
 will just spin forever.
 
 This description reminds me very much of what Jason Wolfe, others and 
 myself have seen.
 
 Konstantin, you're responsible for r220456 (Approved by: kib). I would 
I definitely do not see anything related to my freefall login in the
log message for r220456, nor I participated in any way in the work
which lead to that revision.

If you mean r225057, note that approval by re != review.
 like to ask what investigation you did to ensure that you solved the 
 problem as described in the commit message and didn't introduce a new one?
 
 In r220456 the callout_reset_on() function was changed in a way that 
 directly conflicts with how the TCP stack works, by not always ensuring 
 that callout_active() returns non-zero after a callout is restarted! 
 See return at line 821:
 
  https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057view=markuppathrev=225057#l821
 
 Kib: Any comments?

With the re hat on, explanation for the proposed commit looked reasonable,
and committer provided enough evidence that change got adequate testing.
Since change fixed a bug, and this is exactly what re wants to see
during release cycle, I see no reason why commit should be denied.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Hans Petter Selasky]

On 01/21/15 09:51, Konstantin Belousov wrote:

On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote:

On 01/21/15 00:53, Sean Bruno wrote:

Unkown to me.  Nor am I aware of anyone else who ever hit our panics
either.  Our environment, and the failure, was only seen in the Intel
10GE space (ixgbe).  This is an artifact of our use cases, and hasn't
been expanded nor tested in our environment with other vendor interfaces.

sean




Hi,



I've seen this with Mellanox hardware when running some special tests,
but not during regular use yet. That was the reason for going into the
callout subsystem in the first place. 40GE.

Also I would like to mention during the heat of this discussion, that
during X-mas this year, I had a very heavy discussion with Attilio and a
few other FreeBSD developers, who's name was on a patch (r220456) that
changed how the return value of callout_active() works.
callout_active() is heavily used inside the TCP stack and what was
found is there is a potential race related to migrating the callout from
one CPU to the other, which in turn might give other symptoms than a
spinlock hang.

FYI:

https://svnweb.freebsd.org/base?view=revisionrevision=225057

Cite: If the newly scheduled thread wants to acquire the old queue it
will just spin forever.

This description reminds me very much of what Jason Wolfe, others and
myself have seen.

Konstantin, you're responsible for r220456 (Approved by: kib). I would

I definitely do not see anything related to my freefall login in the
log message for r220456, nor I participated in any way in the work
which lead to that revision.

If you mean r225057, note that approval by re != review.


Yes, I meant r225057.


like to ask what investigation you did to ensure that you solved the
problem as described in the commit message and didn't introduce a new one?

In r220456 the callout_reset_on() function was changed in a way that
directly conflicts with how the TCP stack works, by not always ensuring
that callout_active() returns non-zero after a callout is restarted!
See return at line 821:


https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057view=markuppathrev=225057#l821


Kib: Any comments?


With the re hat on, explanation for the proposed commit looked reasonable,
and committer provided enough evidence that change got adequate testing.
Since change fixed a bug, and this is exactly what re wants to see
during release cycle, I see no reason why commit should be denied.


The problem is Attilio is no longer an active committer and he was not 
been very willing to do more work in this area. When people writing code 
in an area no longer respond - what should we do?


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

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Navdeep Parhar]

On Wed, Jan 21, 2015 at 09:00:03AM +0100, Dimitry Andric wrote:
 On 21 Jan 2015, at 06:53, Navdeep Parhar n...@freebsd.org wrote:
  
  On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
  
  On 01/20/15 22:06, Adrian Chadd wrote:
  On 20 January 2015 at 18:19, Alexey Dokuchaev da...@freebsd.org wrote:
  On Tue, Jan 20, 2015 at 07:50:23PM -0500, Pedro Giffuni wrote:
  But the fix is rather ugly, isn't it? I would personally prefer to just
  kill the older gcc but in the meantime updating it so that it behaves
  like the updated gcc/clang would be better. IMHO.
  Seconded.  Putting extra harness on the code to avoid bugs in the 
  compiler
  that were actually fixed upsteam is totally bogus.
  Right, but:
  
  * not all of us work on compilers;
  * not all of us want to currently be working on compilers;
  * some of us have to use the gcc that's in tree;
  * .. and apparently updating that gcc to something  4.2 is verboten.
  
  The external toolchain can't be that bad(?).
  
  So if someone wants to help Navdeep by backporting those options,
  
  Hmm .. didn't I post a patch?
  
  please do. I bet he'd love the help.
  
  Ugh he doesn't and TBH, I don't care enough to look for
  consensus either.
  
  Let's please just move on from this discussion then.  I am not familiar
  with gcc internals so I can't vouch for this patch, and gcc is the
  default compiler on platforms that I cannot test.  Given that, it would
  be reckless of me to push a gcc patch just to get it to play nice with
  one single file in the tree.  High risk, little reward (given that
  -fms-extensions can be applied to just the file in question without
  disturbing anything else in the tree).
 
 Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
 I specifically introduced for this issue.

Ah, a rose with another name.  I'm happy to use this but it's not clear why
there is a GCC in the macro's name when clang deals with -fms-extensions
just as well.  (It's not even clear why the longer ${GCC_MS_EXTENSIONS}
should be preferred to -fms-extentions.  Isn't this like #define ONE 1 ?)

In any case I'm perfectly fine with any change that doesn't involve a commit
from me to gcc.

Regards,
Navdeep

 
 See e.g. sys/modules/ibcore/Makefile for an example.
 
 -Dimitry
 


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

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Steve Kargl]

On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote:
 
 On 01/20/15 22:52, Steve Kargl wrote:
  On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
  On 01/20/15 22:06, Adrian Chadd wrote:
  * .. and apparently updating that gcc to something  4.2 is verboten.
  The external toolchain can't be that bad(?).
 
  Are the ever change knobs documented somewhere?
 
 https://wiki.freebsd.org/ExternalToolchain
 

IHMO, the wiki is not proper documentation.  'man src.conf'
should have the information needed.

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

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Konstantin Belousov]

On Tue, Jan 20, 2015 at 04:37:44PM -0800, K. Macy wrote:
 I would pick stability over performance any day. However, it _seems_
 to me, and maybe I simply don't understand some key details, that the
 fix consisted of largely single-threading the callout system. And as I
 say I may simply not understand the specifics, but this sort of large
 scale disabling does not constitute a fix but is a workaround.  It's
 more like disabling preemption because it fixes a panic. Yes, it might
 fix a whole array of bugs that crop up but it could not be seen as a
 fix to an otherwise working system.

Well, this is not a complete truth. Let me try to explain my
understanding, I spent some time actually looking at the new code. Would
be nice if corrections to my understanding is posted, if needed.

Now, when callout_reset() is directed to change cpu, the change only
happens when the callout is associated with a lock, and that lock is
owned by the caller of callout_reset(). There are two consequences. One,
which is good, is significant simplification of the migration code,
together with the drain. This is exactly the place where there bugs
which make my head hurt, see e.g. r234952 and r243901.  Note that some
callouts follow this pattern already, e.g. process timers after r243869.

Another consequence, which is very visible and which causes the roar, is
that all lockless callers of callout_reset_on(9) now silently changed
the behaviour to callout_reset(9). There is no audit performed to
identify such callers, and there is no even a plan to fix them.  The
answer to the complains seems to be 'if you think that the fix is needed,
go and fix'.

My impression is that some set of vocal active developers consider
the second consequence unacceptable, myself included. IMO, committing
the change, however good the consequence one is, without fixing the
consequence two, is inappropriate.  And the onus of doing this is on
the person doing the change.

Yes, it is very interesting is the change actually good WRT fixing
migration, since indeed there is serious reduction in the migration
amount due to locked callout_reset() being not universally used.
It is possible that the bugs are only covered.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Hans Petter Selasky]

On 01/21/15 00:53, Sean Bruno wrote:

Unkown to me.  Nor am I aware of anyone else who ever hit our panics
either.  Our environment, and the failure, was only seen in the Intel
10GE space (ixgbe).  This is an artifact of our use cases, and hasn't
been expanded nor tested in our environment with other vendor interfaces.

sean


Hi,

I've seen this with Mellanox hardware when running some special tests, 
but not during regular use yet. That was the reason for going into the 
callout subsystem in the first place. 40GE.


Also I would like to mention during the heat of this discussion, that 
during X-mas this year, I had a very heavy discussion with Attilio and a 
few other FreeBSD developers, who's name was on a patch (r220456) that 
changed how the return value of callout_active() works. 
callout_active() is heavily used inside the TCP stack and what was 
found is there is a potential race related to migrating the callout from 
one CPU to the other, which in turn might give other symptoms than a 
spinlock hang.


FYI:

https://svnweb.freebsd.org/base?view=revisionrevision=225057

Cite: If the newly scheduled thread wants to acquire the old queue it 
will just spin forever.


This description reminds me very much of what Jason Wolfe, others and 
myself have seen.


Konstantin, you're responsible for r220456 (Approved by: kib). I would 
like to ask what investigation you did to ensure that you solved the 
problem as described in the commit message and didn't introduce a new one?


In r220456 the callout_reset_on() function was changed in a way that 
directly conflicts with how the TCP stack works, by not always ensuring 
that callout_active() returns non-zero after a callout is restarted! 
See return at line 821:



https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057view=markuppathrev=225057#l821


Kib: Any comments?

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

Re: svn commit: r277467 - in head/sys/arm: arm at91 cavium/cns11xx mv samsung/s3c2xx0 versatile xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa

[Andrew Turner]

On Wed, 21 Jan 2015 02:56:14 + (UTC)
Ian Lepore i...@freebsd.org wrote:

 Author: ian
 Date: Wed Jan 21 02:56:13 2015
 New Revision: 277467
 URL: https://svnweb.freebsd.org/changeset/base/277467
 
 Log:
   For some reason, all the arm bus_space functions that work with
 uint16 values have armv4 in the name.  There's nothing armv4-special
 about them, so just use the same sort of names as all the other
 functions.

This is because ARMv3 lacked half word load and store instructions. We
got this code from NetBSD who appears to have support for these older
ARM processors.

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

Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Dimitry Andric]

On 21 Jan 2015, at 06:53, Navdeep Parhar n...@freebsd.org wrote:
 
 On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
 
 On 01/20/15 22:06, Adrian Chadd wrote:
 On 20 January 2015 at 18:19, Alexey Dokuchaev da...@freebsd.org wrote:
 On Tue, Jan 20, 2015 at 07:50:23PM -0500, Pedro Giffuni wrote:
 But the fix is rather ugly, isn't it? I would personally prefer to just
 kill the older gcc but in the meantime updating it so that it behaves
 like the updated gcc/clang would be better. IMHO.
 Seconded.  Putting extra harness on the code to avoid bugs in the compiler
 that were actually fixed upsteam is totally bogus.
 Right, but:
 
 * not all of us work on compilers;
 * not all of us want to currently be working on compilers;
 * some of us have to use the gcc that's in tree;
 * .. and apparently updating that gcc to something  4.2 is verboten.
 
 The external toolchain can't be that bad(?).
 
 So if someone wants to help Navdeep by backporting those options,
 
 Hmm .. didn't I post a patch?
 
 please do. I bet he'd love the help.
 
 Ugh he doesn't and TBH, I don't care enough to look for
 consensus either.
 
 Let's please just move on from this discussion then.  I am not familiar
 with gcc internals so I can't vouch for this patch, and gcc is the
 default compiler on platforms that I cannot test.  Given that, it would
 be reckless of me to push a gcc patch just to get it to play nice with
 one single file in the tree.  High risk, little reward (given that
 -fms-extensions can be applied to just the file in question without
 disturbing anything else in the tree).

Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
I specifically introduced for this issue.

See e.g. sys/modules/ibcore/Makefile for an example.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r275832 - head/tools/tools/nanobsd

[Lawrence Stewart]

Hi Will,

On 12/17/14 04:59, Will Andrews wrote:
 Author: will
 Date: Tue Dec 16 17:59:05 2014
 New Revision: 275832
 URL: https://svnweb.freebsd.org/changeset/base/275832
 
 Log:
   Make NanoBSD source-able from other scripts.
   
   Summary:
   This change converts NanoBSD into a two-script bundle.
   - defaults.sh contains all non-CLI code.  Most NanoBSD code is moved into
 this file.
   - nanobsd.sh now consists just of a command line interface that calls into
 functions in defaults.sh.
   
   Test Plan: Run NanoBSD using a previously-working configuration.
   
   Reviewers: imp
   
   Reviewed By: imp
   
   Differential Revision: https://reviews.freebsd.org/D1321
 
 Added:
   head/tools/tools/nanobsd/defaults.sh   (contents, props changed)
 Modified:
   head/tools/tools/nanobsd/nanobsd.sh

I think this change introduced a bug - I'm seeing nanobsd error out with
the NANO_TOOLS directory does not exist message.

The problem is that NANO_TOOLS is initialised to tools/tools/nanobsd,
and you changed the test in nanobsd.sh to *not* check for
${NANO_SRC}/${NANO_TOOLS}, which errors out except if the cwd is
${NANO_SRC}.

You tweak NANO_TOOLS appropriately in set_defaults_and_export() but it's
run after the dir test. There are a couple of ways to fix but I'll leave
it to you to decide which you prefer.

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

svn commit: r277485 - head/usr.sbin/pmcstudy

[Randall Stewart]

Author: rrs
Date: Wed Jan 21 13:03:18 2015
New Revision: 277485
URL: https://svnweb.freebsd.org/changeset/base/277485

Log:
  Fix minor errors found by coverity. Thanks Gleb for
  the pointers to the email!

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

Modified: head/usr.sbin/pmcstudy/pmcstudy.c
==
--- head/usr.sbin/pmcstudy/pmcstudy.c   Wed Jan 21 10:47:28 2015
(r277484)
+++ head/usr.sbin/pmcstudy/pmcstudy.c   Wed Jan 21 13:03:18 2015
(r277485)
@@ -1808,6 +1808,9 @@ process_file(char *filename)
if (cnts == NULL) {
/* Nothing we can do */
printf(Nothing to do -- no counters built\n);
+   if (io) {
+   fclose(io);
+   }
return;
}
lace_cpus_together();
@@ -2044,7 +2047,7 @@ get_cpuid_set(void)
printf(No memory3 allocation fails at 
startup?\n);
exit(-1);
}
-   memset(more, sz, 0);
+   memset(more, 0, sz);
memcpy(more, valid_pmcs, sz);
pmc_allocated_cnt *= 2;
free(valid_pmcs);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

svn commit: r277486 - head/share/man/man9

[Gavin Atkinson]

Author: gavin
Date: Wed Jan 21 13:48:06 2015
New Revision: 277486
URL: https://svnweb.freebsd.org/changeset/base/277486

Log:
  softc is short for software context, use that phrase in the
  device_get_softc(9) man page.
  
  MFC after:1 week

Modified:
  head/share/man/man9/device_get_softc.9

Modified: head/share/man/man9/device_get_softc.9
==
--- head/share/man/man9/device_get_softc.9  Wed Jan 21 13:03:18 2015
(r277485)
+++ head/share/man/man9/device_get_softc.9  Wed Jan 21 13:48:06 2015
(r277486)
@@ -28,7 +28,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd August 2, 2005
+.Dd January 21, 2015
 .Dt DEVICE_GET_SOFTC 9
 .Os
 .Sh NAME
@@ -40,7 +40,7 @@
 .Ft void *
 .Fn device_get_softc device_t dev
 .Sh DESCRIPTION
-Return the driver-specific state of
+Return the driver-specific software context of
 .Fa dev .
 The softc is automatically allocated and zeroed when the device is
 attached.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Lawrence Stewart]

On 01/20/15 09:22, Adrian Chadd wrote:
 Yeah, it looks like you set c_cpu to timeout_cpu in
 _callout_init_locked(), but then you only handle the case of the CPU
 being changed in certain circumstances. You aren't handling the CPU
 being initialised when the callout is first added.
 
 And, callout_restart_async() calls callout_lock(), which calls
 CC_LOCK() on the callout CPU, which initially is zero. Then, it never
 seems to be 'moved' into the correct CPU, even though it's being
 called with a CPU id.
 
 So, if I am reading this all correctly, you aren't really handling
 multi CPU callwheels at all. ;)
 
 In my instance, I'm seeing quite a lot of lock contention between the
 userland threads, the network RX threads and the clock thread, all
 contending on a single callout wheel being used for TCP timers. One of
 the early goals for fixing up the RSS stuff in -HEAD was to make
 per-CPU (Well, per-RSS-bucket really) TCP timers not contend with the
 NIC RX processing path, and now it does. :(

To clarify, you're seeing this with net.inet.tcp.per_cpu_timers=1?

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

Re: svn commit: r275832 - head/tools/tools/nanobsd

[Will Andrews]

On Wed, Jan 21, 2015 at 06:51:23PM +1100, Lawrence Stewart wrote:
 I think this change introduced a bug - I'm seeing nanobsd error out with
 the NANO_TOOLS directory does not exist message.
 
 The problem is that NANO_TOOLS is initialised to tools/tools/nanobsd,
 and you changed the test in nanobsd.sh to *not* check for
 ${NANO_SRC}/${NANO_TOOLS}, which errors out except if the cwd is
 ${NANO_SRC}.
 
 You tweak NANO_TOOLS appropriately in set_defaults_and_export() but it's
 run after the dir test. There are a couple of ways to fix but I'll leave
 it to you to decide which you prefer.

Will this work for you?

https://people.freebsd.org/~will/patches/nanobsd.sh.diff

This also fixes another bug where NANO_PMAKE would be modified too early.

Thanks,
--Will.


pgpuHepTMzjaF.pgp
Description: PGP signature