svn commit: r244144 - in head/sys/amd64: amd64 include

2012-12-12 Thread Peter Grehan
Author: grehan
Date: Wed Dec 12 08:35:32 2012
New Revision: 244144
URL: http://svnweb.freebsd.org/changeset/base/244144

Log:
  Implement an API to allow a hypervisor to save/restore
  guest floating point state without having to know the
  size of floating-point state.
  
  Unstaticize fpurestore to allow the hypervisor to
  save/restore guest state using fpusave/fpurestore
  on the allocated FPU state area.
  
  Reviewed by:  kib
  Obtained from:NetApp/bhyve
  MFC after:1 week

Modified:
  head/sys/amd64/amd64/fpu.c
  head/sys/amd64/include/fpu.h

Modified: head/sys/amd64/amd64/fpu.c
==
--- head/sys/amd64/amd64/fpu.c  Wed Dec 12 07:29:38 2012(r244143)
+++ head/sys/amd64/amd64/fpu.c  Wed Dec 12 08:35:32 2012(r244144)
@@ -47,6 +47,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -134,6 +135,7 @@ SYSCTL_INT(_hw, HW_FLOATINGPT, floatingp
 static int use_xsaveopt;
 int use_xsave; /* non-static for cpu_switch.S */
 uint64_t xsave_mask;   /* the same */
+static uma_zone_t fpu_save_area_zone;
 static struct savefpu *fpu_initialstate;
 
 struct xsave_area_elm_descr {
@@ -151,7 +153,7 @@ fpusave(void *addr)
fxsave((char *)addr);
 }
 
-static void
+void
 fpurestore(void *addr)
 {
 
@@ -312,6 +314,10 @@ fpuinitstate(void *arg __unused)
}
}
 
+   fpu_save_area_zone = uma_zcreate("FPU_save_area",
+   cpu_max_ext_state_size, NULL, NULL, NULL, NULL,
+   XSAVE_AREA_ALIGN - 1, 0);
+
start_emulating();
intr_restore(saveintr);
 }
@@ -980,3 +986,27 @@ is_fpu_kern_thread(u_int flags)
return (0);
return ((curpcb->pcb_flags & PCB_KERNFPU) != 0);
 }
+
+/*
+ * FPU save area alloc/free/init utility routines
+ */
+struct savefpu *
+fpu_save_area_alloc(void)
+{
+
+   return (uma_zalloc(fpu_save_area_zone, 0));
+}
+
+void
+fpu_save_area_free(struct savefpu *fsa)
+{
+
+   uma_zfree(fpu_save_area_zone, fsa);
+}
+
+void
+fpu_save_area_reset(struct savefpu *fsa)
+{
+
+   bcopy(fpu_initialstate, fsa, cpu_max_ext_state_size);
+}

Modified: head/sys/amd64/include/fpu.h
==
--- head/sys/amd64/include/fpu.hWed Dec 12 07:29:38 2012
(r244143)
+++ head/sys/amd64/include/fpu.hWed Dec 12 08:35:32 2012
(r244144)
@@ -57,6 +57,7 @@ void  fpuexit(struct thread *td);
 intfpuformat(void);
 intfpugetregs(struct thread *td);
 void   fpuinit(void);
+void   fpurestore(void *addr);
 void   fpusave(void *addr);
 intfpusetregs(struct thread *td, struct savefpu *addr,
char *xfpustate, size_t xfpustate_size);
@@ -73,6 +74,10 @@ int  fpu_kern_leave(struct thread *td, st
 intfpu_kern_thread(u_int flags);
 intis_fpu_kern_thread(u_int flags);
 
+struct savefpu *fpu_save_area_alloc(void);
+void   fpu_save_area_free(struct savefpu *fsa);
+void   fpu_save_area_reset(struct savefpu *fsa);
+
 /*
  * Flags for fpu_kern_alloc_ctx(), fpu_kern_enter() and fpu_kern_thread().
  */
___
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: r244145 - head/sys/dev/sound/pci/hda

2012-12-12 Thread Alexander Motin
Author: mav
Date: Wed Dec 12 11:44:20 2012
New Revision: 244145
URL: http://svnweb.freebsd.org/changeset/base/244145

Log:
  Add quirks for AD1984A codec and Lenovo X300 laptop.
  
  PR:   kern/148741
  MFC after:2 weeks

Modified:
  head/sys/dev/sound/pci/hda/hdaa_patches.c
  head/sys/dev/sound/pci/hda/hdac.h

Modified: head/sys/dev/sound/pci/hda/hdaa_patches.c
==
--- head/sys/dev/sound/pci/hda/hdaa_patches.c   Wed Dec 12 08:35:32 2012
(r244144)
+++ head/sys/dev/sound/pci/hda/hdaa_patches.c   Wed Dec 12 11:44:20 2012
(r244145)
@@ -271,7 +271,17 @@ hdac_pin_patch(struct hdaa_widget *w)
}
 
/* New patches */
-   if (id == HDA_CODEC_AD1986A &&
+   if (id == HDA_CODEC_AD1984A &&
+   subid == LENOVO_X300_SUBVENDOR) {
+   switch (nid) {
+   case 17: /* Headphones with redirection */
+   patch = "as=1 seq=15";
+   break;
+   case 20: /* Two mics together */
+   patch = "as=2 seq=15";
+   break;
+   }
+   } else if (id == HDA_CODEC_AD1986A &&
(subid == ASUS_M2NPVMX_SUBVENDOR ||
subid == ASUS_A8NVMCSM_SUBVENDOR ||
subid == ASUS_P5PL2_SUBVENDOR)) {
@@ -372,6 +382,13 @@ hdaa_widget_patch(struct hdaa_widget *w)
HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_SHIFT;
w->waspin = 1;
}
+   /*
+* Clear "digital" flag from digital mic input, as its signal then goes
+* to "analog" mixer and this separation just limits functionaity.
+*/
+   if (hdaa_codec_id(devinfo) == HDA_CODEC_AD1984A &&
+   w->nid == 23)
+   w->param.widget_cap &= ~HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL_MASK;
HDA_BOOTVERBOSE(
if (w->param.widget_cap != orig) {
device_printf(w->devinfo->dev,

Modified: head/sys/dev/sound/pci/hda/hdac.h
==
--- head/sys/dev/sound/pci/hda/hdac.h   Wed Dec 12 08:35:32 2012
(r244144)
+++ head/sys/dev/sound/pci/hda/hdac.h   Wed Dec 12 11:44:20 2012
(r244145)
@@ -218,6 +218,7 @@
 #define LENOVO_3KN200_SUBVENDORHDA_MODEL_CONSTRUCT(LENOVO, 0x384e)
 #define LENOVO_B450_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x3a0d)
 #define LENOVO_TCA55_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x1015)
+#define LENOVO_X300_SUBVENDOR  HDA_MODEL_CONSTRUCT(LENOVO, 0x20ac)
 #define LENOVO_ALL_SUBVENDOR   HDA_MODEL_CONSTRUCT(LENOVO, 0x)
 
 /* Samsung */
___
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: r244146 - in head/sys/dev: ahci ata ata/chipsets

2012-12-12 Thread Alexander Motin
Author: mav
Date: Wed Dec 12 11:53:15 2012
New Revision: 244146
URL: http://svnweb.freebsd.org/changeset/base/244146

Log:
  Add IDs for SATA controllers on AMD Hudson-2 series chipsets.
  I am not exactly sure about the naming due to lack of specs on AMD site,
  but it is better to have some identification then none at all.
  
  MFC after:1 month

Modified:
  head/sys/dev/ahci/ahci.c
  head/sys/dev/ata/ata-pci.h
  head/sys/dev/ata/chipsets/ata-ati.c

Modified: head/sys/dev/ahci/ahci.c
==
--- head/sys/dev/ahci/ahci.cWed Dec 12 11:44:20 2012(r244145)
+++ head/sys/dev/ahci/ahci.cWed Dec 12 11:53:15 2012(r244146)
@@ -122,6 +122,11 @@ static struct {
{0x43931002, 0x00, "ATI IXP700",0},
{0x43941002, 0x00, "ATI IXP800",0},
{0x43951002, 0x00, "ATI IXP800",0},
+   {0x78001022, 0x00, "AMD Hudson-2",  0},
+   {0x78011022, 0x00, "AMD Hudson-2",  0},
+   {0x78021022, 0x00, "AMD Hudson-2",  0},
+   {0x78031022, 0x00, "AMD Hudson-2",  0},
+   {0x78041022, 0x00, "AMD Hudson-2",  0},
{0x06121b21, 0x00, "ASMedia ASM1061",   0},
{0x26528086, 0x00, "Intel ICH6",AHCI_Q_NOFORCE},
{0x26538086, 0x00, "Intel ICH6M",   AHCI_Q_NOFORCE},

Modified: head/sys/dev/ata/ata-pci.h
==
--- head/sys/dev/ata/ata-pci.h  Wed Dec 12 11:44:20 2012(r244145)
+++ head/sys/dev/ata/ata-pci.h  Wed Dec 12 11:53:15 2012(r244146)
@@ -101,6 +101,12 @@ struct ata_pci_controller {
 #define ATA_AMD768  0x74411022
 #define ATA_AMD8111 0x74691022
 #define ATA_AMD5536 0x209a1022
+#define ATA_AMD_HUDSON2_S1 0x78001022
+#define ATA_AMD_HUDSON2_S2 0x78011022
+#define ATA_AMD_HUDSON2_S3 0x78021022
+#define ATA_AMD_HUDSON2_S4 0x78031022
+#define ATA_AMD_HUDSON2_S5 0x78041022
+#define ATA_AMD_HUDSON20x780c1022
 
 #define ATA_ADAPTEC_ID  0x9005
 #define ATA_ADAPTEC_14200x02419005

Modified: head/sys/dev/ata/chipsets/ata-ati.c
==
--- head/sys/dev/ata/chipsets/ata-ati.c Wed Dec 12 11:44:20 2012
(r244145)
+++ head/sys/dev/ata/chipsets/ata-ati.c Wed Dec 12 11:53:15 2012
(r244146)
@@ -91,6 +91,12 @@ ata_ati_probe(device_t dev)
  { ATA_ATI_IXP700_S4, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP700/800" },
  { ATA_ATI_IXP800_S1, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP800" },
  { ATA_ATI_IXP800_S2, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP800" },
+ { ATA_AMD_HUDSON2, 0x00, ATI_PATA, 0, ATA_UDMA6, "Hudson-2" },
+ { ATA_AMD_HUDSON2_S1,  0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" },
+ { ATA_AMD_HUDSON2_S2,  0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" },
+ { ATA_AMD_HUDSON2_S3,  0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" },
+ { ATA_AMD_HUDSON2_S4,  0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" },
+ { ATA_AMD_HUDSON2_S5,  0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" },
  { 0, 0, 0, 0, 0, 0}};
 
 if (pci_get_vendor(dev) != ATA_ATI_ID)
___
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: r244153 - head/lib/libc/gen

2012-12-12 Thread Pawel Jakub Dawidek
Author: pjd
Date: Wed Dec 12 15:27:33 2012
New Revision: 244153
URL: http://svnweb.freebsd.org/changeset/base/244153

Log:
  Eliminate redundant variable.

Modified:
  head/lib/libc/gen/sysctlbyname.c

Modified: head/lib/libc/gen/sysctlbyname.c
==
--- head/lib/libc/gen/sysctlbyname.cWed Dec 12 13:33:11 2012
(r244152)
+++ head/lib/libc/gen/sysctlbyname.cWed Dec 12 15:27:33 2012
(r244153)
@@ -19,13 +19,10 @@ sysctlbyname(const char *name, void *old
 const void *newp, size_t newlen)
 {
int real_oid[CTL_MAXNAME+2];
-   int error;
size_t oidlen;
 
oidlen = sizeof(real_oid) / sizeof(int);
-   error = sysctlnametomib(name, real_oid, &oidlen);
-   if (error < 0) 
-   return (error);
-   error = sysctl(real_oid, oidlen, oldp, oldlenp, newp, newlen);
-   return (error);
+   if (sysctlnametomib(name, real_oid, &oidlen) < 0)
+   return (-1);
+   return (sysctl(real_oid, oidlen, oldp, oldlenp, newp, newlen));
 }
___
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: r244154 - head/bin/ps

2012-12-12 Thread Pawel Jakub Dawidek
Author: pjd
Date: Wed Dec 12 15:45:03 2012
New Revision: 244154
URL: http://svnweb.freebsd.org/changeset/base/244154

Log:
  Use kern.max_pid sysctl to obtain maximum PID number instead of using local
  define.
  
  Reviewed by:  jhb

Modified:
  head/bin/ps/ps.c

Modified: head/bin/ps/ps.c
==
--- head/bin/ps/ps.cWed Dec 12 15:27:33 2012(r244153)
+++ head/bin/ps/ps.cWed Dec 12 15:45:03 2012(r244154)
@@ -109,6 +109,7 @@ static int   needcomm;  /* -o "command" */
 static int  needenv;   /* -e */
 static int  needuser;  /* -o "user" */
 static int  optfatal;  /* Fatal error parsing some list-option. */
+static int  pid_max;   /* kern.max_pid */
 
 static enum sort { DEFAULT, SORTMEM, SORTCPU } sortby = DEFAULT;
 
@@ -148,6 +149,7 @@ static int   pscomp(const void *, const v
 static void saveuser(KINFO *);
 static void scanvars(void);
 static void sizevars(void);
+static void pidmax_init(void);
 static void usage(void);
 
 static char dfmt[] = "pid,tt,state,time,command";
@@ -200,6 +202,8 @@ main(int argc, char *argv[])
if (argc > 1)
argv[1] = kludge_oldps_options(PS_ARGS, argv[1], argv[2]);
 
+   pidmax_init();
+
all = descendancy = _fmt = nselectors = optfatal = 0;
prtheader = showthreads = wflag = xkeep_implied = 0;
xkeep = -1; /* Neither -x nor -X. */
@@ -722,7 +726,6 @@ addelem_gid(struct listinfo *inf, const 
return (1);
 }
 
-#defineBSD_PID_MAX 9   /* Copy of PID_MAX from 
sys/proc.h. */
 static int
 addelem_pid(struct listinfo *inf, const char *elem)
 {
@@ -740,7 +743,7 @@ addelem_pid(struct listinfo *inf, const 
if (*endp != '\0' || tempid < 0 || elem == endp) {
warnx("Invalid %s: %s", inf->lname, elem);
errno = ERANGE;
-   } else if (errno != 0 || tempid > BSD_PID_MAX) {
+   } else if (errno != 0 || tempid > pid_max) {
warnx("%s too large: %s", inf->lname, elem);
errno = ERANGE;
}
@@ -753,7 +756,6 @@ addelem_pid(struct listinfo *inf, const 
inf->l.pids[(inf->count)++] = tempid;
return (1);
 }
-#undef BSD_PID_MAX
 
 /*-
  * The user can specify a device via one of three formats:
@@ -1352,6 +1354,18 @@ kludge_oldps_options(const char *optlist
 }
 
 static void
+pidmax_init(void)
+{
+   size_t intsize;
+
+   intsize = sizeof(pid_max);
+   if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) {
+   warn("unable to read kern.pid_max");
+   pid_max = 9;
+   }
+}
+
+static void
 usage(void)
 {
 #defineSINGLE_OPTS "[-aCcde" OPT_LAZY_f "HhjlmrSTuvwXxZ]"
___
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: r244105 - in head/sys: kern sys

2012-12-12 Thread John Baldwin
On Monday, December 10, 2012 8:23:51 pm Alfred Perlstein wrote:
> Author: alfred
> Date: Tue Dec 11 01:23:50 2012
> New Revision: 244105
> URL: http://svnweb.freebsd.org/changeset/base/244105
> 
> Log:
>   Switch the hardwired WITNESS panics to kassert_panic.
>   
>   This is an ongoing effort to provide runtime debug information
>   useful in the field that does not panic existing installations.
>   
>   This gives us the flexibility needed when shipping images to a
>   potentially large audience with WITNESS enabled without worrying
>   about formerly non-fatal LORs hurting a release.
>   
>   Sponsored by: iXsystems

Witness doesn't panic on LORs.  These are all bigger violations for things 
like doing sx_sunlock() on a exclusively locked sx lock.  That is not safe and 
is merely going to result in data corruption and other unpleasantness.  This 
sounds like a very bad idea.  Did you talk about this anywhere (I have not 
caught up on various lists yet, so apologies if this has been discussed.)

-- 
John Baldwin
___
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: r244112 - head/sys/kern

2012-12-12 Thread John Baldwin
On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote:
> Author: alfred
> Date: Tue Dec 11 07:08:14 2012
> New Revision: 244112
> URL: http://svnweb.freebsd.org/changeset/base/244112
> 
> Log:
>   Cleanup more of the kassert_panic.
>   
>   fix compile warnings on !amd64 and NULL derefs that would happen
>   if kassert_panic() would return.

This is one reason why having kassert not panic is such a bad idea.  There are 
tons of places where the compiler knows that panic() is __dead2, and there is 
no cleanup code to handle what happens when an invariant is violated.  This is 
not safe to run in the field unless your customers do not care about their 
data.  If you are interested in doing regression tests, I am using a very 
different approach for some locking regression tests I am working on in p4 
that allow you to use a wrapper around setjmp/longjmp to "catch" panics 
somewhat like exception handling in C++/Java (though much cruder).  However, 
evne that is only intended for testing, not for production cases where 
production data is at stake.

-- 
John Baldwin
___
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: r244155 - in head/sys/cddl: compat/opensolaris/kern compat/opensolaris/sys contrib/opensolaris/uts/common/fs/zfs contrib/opensolaris/uts/common/fs/zfs/sys

2012-12-12 Thread Steven Hartland
Author: smh
Date: Wed Dec 12 16:14:14 2012
New Revision: 244155
URL: http://svnweb.freebsd.org/changeset/base/244155

Log:
  Renamed zfs trim stats removing duplicate zio_trim identifier from the name
  Added description option to kstats.
  Added descriptions for zio_trim kstats
  
  PR:   kern/173113
  Submitted by: Steven Hartland
  Reviewed by:  pjd
  Approved by:  pjd
  MFC after:2 weeks

Modified:
  head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c
  head/sys/cddl/compat/opensolaris/sys/kstat.h
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c

Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c
==
--- head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c   Wed Dec 12 
15:45:03 2012(r244154)
+++ head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c   Wed Dec 12 
16:14:14 2012(r244155)
@@ -118,7 +118,7 @@ kstat_install(kstat_t *ksp)
SYSCTL_ADD_PROC(&ksp->ks_sysctl_ctx,
SYSCTL_CHILDREN(ksp->ks_sysctl_root), OID_AUTO, ksent->name,
CTLTYPE_U64 | CTLFLAG_RD, ksent, sizeof(*ksent),
-   kstat_sysctl, "QU", "");
+   kstat_sysctl, "QU", ksent->desc);
}
 }
 

Modified: head/sys/cddl/compat/opensolaris/sys/kstat.h
==
--- head/sys/cddl/compat/opensolaris/sys/kstat.hWed Dec 12 15:45:03 
2012(r244154)
+++ head/sys/cddl/compat/opensolaris/sys/kstat.hWed Dec 12 16:14:14 
2012(r244155)
@@ -53,6 +53,8 @@ typedef struct kstat_named {
 #defineKSTAT_DATA_INT643
 #defineKSTAT_DATA_UINT64   4
uchar_t data_type;
+#defineKSTAT_DESCLEN   128
+   chardesc[KSTAT_DESCLEN];
union {
uint64_tui64;
} value;

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h   Wed Dec 
12 15:45:03 2012(r244154)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h   Wed Dec 
12 16:14:14 2012(r244155)
@@ -372,23 +372,23 @@ typedef struct zio_trim_stats {
/*
 * Number of bytes successfully TRIMmed.
 */
-   kstat_named_t zio_trim_bytes;
+   kstat_named_t bytes;
 
/*
 * Number of successful TRIM requests.
 */
-   kstat_named_t zio_trim_success;
+   kstat_named_t success;
 
/*
 * Number of TRIM requests that failed because TRIM is not
 * supported.
 */
-   kstat_named_t zio_trim_unsupported;
+   kstat_named_t unsupported;
 
/*
 * Number of TRIM requests that failed for other reasons.
 */
-   kstat_named_t zio_trim_failed;
+   kstat_named_t failed;
 } zio_trim_stats_t;
 
 extern zio_trim_stats_t zio_trim_stats;

Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c   Wed Dec 12 
15:45:03 2012(r244154)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c   Wed Dec 12 
16:14:14 2012(r244155)
@@ -48,14 +48,15 @@ TUNABLE_INT("vfs.zfs.zio.exclude_metadat
 SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, exclude_metadata, CTLFLAG_RDTUN, 
&zio_exclude_metadata, 0,
 "Exclude metadata buffers from dumps as well");
 
-/*
- * See zio.h for more information about these fields.
- */
 zio_trim_stats_t zio_trim_stats = {
-   { "zio_trim_bytes", KSTAT_DATA_UINT64 },
-   { "zio_trim_success",   KSTAT_DATA_UINT64 },
-   { "zio_trim_unsupported",   KSTAT_DATA_UINT64 },
-   { "zio_trim_failed",KSTAT_DATA_UINT64 },
+   { "bytes",  KSTAT_DATA_UINT64,
+ "Number of bytes successfully TRIMmed" },
+   { "success",KSTAT_DATA_UINT64,
+ "Number of successful TRIM requests" },
+   { "unsupported",KSTAT_DATA_UINT64,
+ "Number of TRIM requests that failed because TRIM is not supported" },
+   { "failed", KSTAT_DATA_UINT64,
+ "Number of TRIM requests that failed for reasons other than not 
supported" },
 };
 
 static kstat_t *zio_trim_ksp;
@@ -2660,14 +2661,14 @@ zio_vdev_io_assess(zio_t *zio)
if (zio->io_type == ZIO_TYPE_IOCTL && zio->io_cmd == DKIOCTRIM)
switch (zio->io_error) {
case 0:
-   ZIO_TRIM_STAT_INCR(zio_trim_bytes, zio->io_size);
-   ZIO_TRIM_STAT_BUMP(zio_trim_success);
+   ZIO_TRIM_STAT_INCR(bytes, zio->io_size);
+   

Re: svn commit: r244154 - head/bin/ps

2012-12-12 Thread Eitan Adler
On 12 December 2012 10:45, Pawel Jakub Dawidek  wrote:

> +   if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) {
> +   warn("unable to read kern.pid_max");

Silly question, when could this fail and not be fatal?

> +   pid_max = 9;

Why not use PID_MAX from sys/proc.h?


-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams
___
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: r244154 - head/bin/ps

2012-12-12 Thread Pawel Jakub Dawidek
On Wed, Dec 12, 2012 at 11:37:00AM -0500, Eitan Adler wrote:
> On 12 December 2012 10:45, Pawel Jakub Dawidek  wrote:
> 
> > +   if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) {
> > +   warn("unable to read kern.pid_max");
> 
> Silly question, when could this fail and not be fatal?

It isn't fatal, we can easly make some assumptions instead of turning
ps(1) unusable. Currently it will be hard to make it fail, which doesn't
mean we shouldn't handle this case. Some day it might fail for some
reason (someone changed sysctl name?).

> > +   pid_max = 9;
> 
> Why not use PID_MAX from sys/proc.h?

Because we are in userland and PID_MAX is only defined for the kernel.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgppOFYrdKMf4.pgp
Description: PGP signature


svn commit: r244156 - head/share/misc

2012-12-12 Thread Steven Hartland
Author: smh
Date: Wed Dec 12 16:59:07 2012
New Revision: 244156
URL: http://svnweb.freebsd.org/changeset/base/244156

Log:
  Add myself as a new src committer
  
  Approved by:  pjd (mentor)

Modified:
  head/share/misc/committers-src.dot

Modified: head/share/misc/committers-src.dot
==
--- head/share/misc/committers-src.dot  Wed Dec 12 16:14:14 2012
(r244155)
+++ head/share/misc/committers-src.dot  Wed Dec 12 16:59:07 2012
(r244156)
@@ -249,6 +249,7 @@ sephe [label="Sepherosa Ziehau\nsephe@Fr
 sepotvin [label="Stephane E. Potvin\nsepot...@freebsd.org\n2007/02/15"]
 simon [label="Simon L. Nielsen\nsi...@freebsd.org\n2006/03/07"]
 sjg [label="Simon J. Gerraty\n...@freebsd.org\n2012/10/23"]
+smh [label="Steven Hartland\s...@freebsd.org\n2012/11/12"]
 sobomax [label="Maxim Sobolev\nsobo...@freebsd.org\n2001/07/25"]
 sos [label="Soren Schmidt\n...@freebsd.org\n/??/??"]
 sson [label="Stacey Son\ns...@freebsd.org\n2008/07/08"]
@@ -307,6 +308,7 @@ anholt -> jkim
 
 avg -> art
 avg -> pluknet
+avg -> smh
 
 benno -> grehan
 
@@ -555,6 +557,7 @@ philip -> uqs
 
 pjd -> kib
 pjd -> lulf
+pjd -> smh
 pjd -> trociny
 
 rgrimes -> markm
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
kassert()s are already optional. Ie, you can choose to not compile them in.

So the __dead2() code path bit for doing KASSERT() -> kassert_panic()
at compile time isn't a problem.

The problem is where you do panic() -> kassert_panic() (eg in the
Witness code) which is what Alfred discovered shortly after doing up
his initial patch.

Anything which is a KASSERT() can and should be treated as a run-time
warning just as much as a run-time "crash here so I can figure out
what broke." Having the warning in a production box is going to be
helpful for developers.



Adrian

On 12 December 2012 07:46, John Baldwin  wrote:
> On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote:
>> Author: alfred
>> Date: Tue Dec 11 07:08:14 2012
>> New Revision: 244112
>> URL: http://svnweb.freebsd.org/changeset/base/244112
>>
>> Log:
>>   Cleanup more of the kassert_panic.
>>
>>   fix compile warnings on !amd64 and NULL derefs that would happen
>>   if kassert_panic() would return.
>
> This is one reason why having kassert not panic is such a bad idea.  There are
> tons of places where the compiler knows that panic() is __dead2, and there is
> no cleanup code to handle what happens when an invariant is violated.  This is
> not safe to run in the field unless your customers do not care about their
> data.  If you are interested in doing regression tests, I am using a very
> different approach for some locking regression tests I am working on in p4
> that allow you to use a wrapper around setjmp/longjmp to "catch" panics
> somewhat like exception handling in C++/Java (though much cruder).  However,
> evne that is only intended for testing, not for production cases where
> production data is at stake.
>
> --
> John Baldwin
___
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: r244157 - head/sys/netinet

2012-12-12 Thread Gleb Smirnoff
Author: glebius
Date: Wed Dec 12 17:41:21 2012
New Revision: 244157
URL: http://svnweb.freebsd.org/changeset/base/244157

Log:
Fix a crash in tcp_input(), that happens when mbuf has a fwd_tag on it,
  but later after processing and freeing the tag, we need to jump back again
  to the findpcb label. Since the fwd_tag pointer wasn't NULL we tried to
  process and free the tag for second time.
  
  Reported & tested by: Pawel Tyll 
  MFC after:3 days

Modified:
  head/sys/netinet/tcp_input.c

Modified: head/sys/netinet/tcp_input.c
==
--- head/sys/netinet/tcp_input.cWed Dec 12 16:59:07 2012
(r244156)
+++ head/sys/netinet/tcp_input.cWed Dec 12 17:41:21 2012
(r244157)
@@ -810,6 +810,7 @@ findpcb:
/* Remove the tag from the packet.  We don't need it anymore. */
m_tag_delete(m, fwd_tag);
m->m_flags &= ~M_IP_NEXTHOP;
+   fwd_tag = NULL;
} else if (isipv6) {
inp = in6_pcblookup_mbuf(&V_tcbinfo, &ip6->ip6_src,
th->th_sport, &ip6->ip6_dst, th->th_dport,
@@ -847,6 +848,7 @@ findpcb:
/* Remove the tag from the packet.  We don't need it anymore. */
m_tag_delete(m, fwd_tag);
m->m_flags &= ~M_IP_NEXTHOP;
+   fwd_tag = NULL;
} else
inp = in_pcblookup_mbuf(&V_tcbinfo, ip->ip_src,
th->th_sport, ip->ip_dst, th->th_dport,
___
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: r244158 - head/sys/boot/forth

2012-12-12 Thread Devin Teske
Author: dteske
Date: Wed Dec 12 17:49:01 2012
New Revision: 244158
URL: http://svnweb.freebsd.org/changeset/base/244158

Log:
  Fix a regression caused by SVN r222417.
  
  Prior to r222417, setting `password' in loader.conf(5) did not prevent boot
  but instead only prevented changes to boot options by prompting for password
  if autoboot failed or the user interrupted the countdown sequence.
  After r222417 the same machine with `password' set in loader.conf(5) would no
  longer boot without _always_ entering the password.
  
  This patch restores the old (8.x and older) functionality for password in
  loader.conf(5) while adding a new bootlock_password feature to replace the
  edge-case should anybody desire the regressed functionality (HINT: great for
  PXE servers and/or private distributions).
  
  loader.conf(5) was updated to be more clear with-respect to password setting
  (previous text was misleading).
  
  Documentation (loader.conf(5) and check-password.4th(8)) has been updated to
  include notes on the new bootlock_password setting.
  
  Special thanks to Alex Verbod for bringing this to my attention and helping to
  refine the loader.conf(5) text.
  
  PR:   conf/170110
  Submitted by: Vitaly Zakharov 
  Reviewed by:  Alexander Verbod 

Modified:
  head/sys/boot/forth/beastie.4th.8
  head/sys/boot/forth/check-password.4th
  head/sys/boot/forth/check-password.4th.8
  head/sys/boot/forth/loader.4th.8
  head/sys/boot/forth/loader.conf.5
  head/sys/boot/forth/menu.4th.8

Modified: head/sys/boot/forth/beastie.4th.8
==
--- head/sys/boot/forth/beastie.4th.8   Wed Dec 12 17:41:21 2012
(r244157)
+++ head/sys/boot/forth/beastie.4th.8   Wed Dec 12 17:49:01 2012
(r244158)
@@ -1,4 +1,4 @@
-.\" Copyright (c) 2011 Devin Teske
+.\" Copyright (c) 2011-2012 Devin Teske
 .\" All rights reserved.
 .\"
 .\" Redistribution and use in source and binary forms, with or without
@@ -94,8 +94,9 @@ The
 variable can be configured in
 .Xr loader.conf 5
 to the number of seconds you would like to delay loading the boot menu.
-During the delay the user can press Ctrl-C to fall back to autoboot or ENTER
-to proceed.
+During the delay the user can press Ctrl-C to fall back to
+.Ic autoboot
+or ENTER to proceed.
 The default behavior is to not delay.
 .El
 .Pp

Modified: head/sys/boot/forth/check-password.4th
==
--- head/sys/boot/forth/check-password.4th  Wed Dec 12 17:41:21 2012
(r244157)
+++ head/sys/boot/forth/check-password.4th  Wed Dec 12 17:49:01 2012
(r244158)
@@ -1,4 +1,4 @@
-\ Copyright (c) 2006-2011 Devin Teske 
+\ Copyright (c) 2006-2012 Devin Teske 
 \ All rights reserved.
 \ 
 \ Redistribution and use in source and binary forms, with or without
@@ -74,7 +74,7 @@ variable readlen\ input length
again
 ;
 
-: read ( -- String prompt )
+: read ( String prompt -- )
 
0 25 at-xy   \ Move the cursor to the bottom-left
dup 1+ read-start !  \ Store X offset after the prompt
@@ -134,23 +134,37 @@ variable readlen\ input length
 
 : check-password ( -- )
 
-   \ Exit if a password was not set
-   s" password" getenv dup -1 = if
-   drop exit
+   \ Do not allow the user to proceed beyond this point if a boot-lock
+   \ password has been set (preventing even boot from proceeding)
+   s" bootlock_password" getenv dup -1 <> if
+   begin
+   s" Boot Password: " read ( prompt -- )
+   2dup readval readlen @ compare 0<>
+   while
+   3000 ms ." loader: incorrect password" 10 emit
+   repeat
+   2drop ( c-addr/u )
+   else
+   drop ( -1 ) \ getenv cruft
then
 
-   begin \ Loop as long as it takes to get the right password
+   \ Exit if a password was not set
+   s" password" getenv -1 = if exit else drop then
+
+   \ We should prevent the user from visiting the menu or dropping to the
+   \ interactive loader(8) prompt, but still allow the machine to boot...
 
-   s" Password: " \ Output a prompt for a password
-   read   \ Read the user's input until Enter
+   0 autoboot
 
+   \ Only reached if autoboot fails for any reason (including if/when
+   \ the user aborts/escapes the countdown sequence leading to boot).
+
+   s" password" getenv
+   begin
+   s" Password: " read ( prompt -- )
2dup readval readlen @ compare 0= if
2drop exit \ Correct password
then
-
-   \ Bad Password
-   3000 ms
-   ." loader: incorrect password" 10 emit
-
-   again \ Not the right password; repeat
+   3000 ms ." loader: incorrect password" 10 emit
+   again
 ;


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

2012-12-12 Thread Alfred Perlstein

to all:

I am trying to take this offline with John so that we can discuss the 
reasoning behind the change and come to an agreement on how it is 
implemented, or if not to remove it.


-Alfred

On 12/12/12 7:46 AM, John Baldwin wrote:

On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote:

Author: alfred
Date: Tue Dec 11 07:08:14 2012
New Revision: 244112
URL: http://svnweb.freebsd.org/changeset/base/244112

Log:
   Cleanup more of the kassert_panic.
   
   fix compile warnings on !amd64 and NULL derefs that would happen

   if kassert_panic() would return.

This is one reason why having kassert not panic is such a bad idea.  There are
tons of places where the compiler knows that panic() is __dead2, and there is
no cleanup code to handle what happens when an invariant is violated.  This is
not safe to run in the field unless your customers do not care about their
data.  If you are interested in doing regression tests, I am using a very
different approach for some locking regression tests I am working on in p4
that allow you to use a wrapper around setjmp/longjmp to "catch" panics
somewhat like exception handling in C++/Java (though much cruder).  However,
evne that is only intended for testing, not for production cases where
production data is at stake.



___
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: r244154 - head/bin/ps

2012-12-12 Thread Konstantin Belousov
On Wed, Dec 12, 2012 at 03:45:04PM +, Pawel Jakub Dawidek wrote:
> Author: pjd
> Date: Wed Dec 12 15:45:03 2012
> New Revision: 244154
> URL: http://svnweb.freebsd.org/changeset/base/244154
> 
> Log:
>   Use kern.max_pid sysctl to obtain maximum PID number instead of using local
>   define.
It is pid_max, not max_pid.

But the change is wrong. The kern.pid_max only limits newly allocated pids,
it does not magically moves existing pids, which are out of range, to the
limited region. See the corresponding commit log for the description.
It was added to make it easier to run FreeBSD 1.x binaries on the modern
kernels.


pgpG4ptvoWqmK.pgp
Description: PGP signature


svn commit: r244162 - in head: bin/sh tools/regression/bin/sh/errors

2012-12-12 Thread Jilles Tjoelker
Author: jilles
Date: Wed Dec 12 22:01:10 2012
New Revision: 244162
URL: http://svnweb.freebsd.org/changeset/base/244162

Log:
  sh: Detect and flag write errors on stdout in builtins.
  
  If there is a write error on stdout, a message will be printed (to stderr)
  and the exit status will be changed to 2 if it would have been 0 or 1.
  
  PR:   bin/158206

Added:
  head/tools/regression/bin/sh/errors/write-error1.0   (contents, props changed)
Modified:
  head/bin/sh/eval.c
  head/bin/sh/output.c
  head/bin/sh/output.h

Modified: head/bin/sh/eval.c
==
--- head/bin/sh/eval.c  Wed Dec 12 20:55:30 2012(r244161)
+++ head/bin/sh/eval.c  Wed Dec 12 22:01:10 2012(r244162)
@@ -1070,6 +1070,7 @@ evalcommand(union node *cmd, int flags, 
}
handler = &jmploc;
redirect(cmd->ncmd.redirect, mode);
+   outclearerror(out1);
/*
 * If there is no command word, redirection errors should
 * not be fatal but assignment errors should.
@@ -1085,6 +1086,11 @@ evalcommand(union node *cmd, int flags, 
builtin_flags = flags;
exitstatus = (*builtinfunc[cmdentry.u.index])(argc, argv);
flushall();
+   if (outiserror(out1)) {
+   warning("write error on stdout");
+   if (exitstatus == 0 || exitstatus == 1)
+   exitstatus = 2;
+   }
 cmddone:
if (argc > 0)
bltinunsetlocale();

Modified: head/bin/sh/output.c
==
--- head/bin/sh/output.cWed Dec 12 20:55:30 2012(r244161)
+++ head/bin/sh/output.cWed Dec 12 22:01:10 2012(r244162)
@@ -239,6 +239,20 @@ freestdout(void)
 }
 
 
+int
+outiserror(struct output *file)
+{
+   return (file->flags & OUTPUT_ERR);
+}
+
+
+void
+outclearerror(struct output *file)
+{
+   file->flags &= ~OUTPUT_ERR;
+}
+
+
 void
 outfmt(struct output *file, const char *fmt, ...)
 {

Modified: head/bin/sh/output.h
==
--- head/bin/sh/output.hWed Dec 12 20:55:30 2012(r244161)
+++ head/bin/sh/output.hWed Dec 12 22:01:10 2012(r244162)
@@ -66,6 +66,8 @@ void emptyoutbuf(struct output *);
 void flushall(void);
 void flushout(struct output *);
 void freestdout(void);
+int outiserror(struct output *);
+void outclearerror(struct output *);
 void outfmt(struct output *, const char *, ...) __printflike(2, 3);
 void out1fmt(const char *, ...) __printflike(1, 2);
 void out2fmt_flush(const char *, ...) __printflike(1, 2);

Added: head/tools/regression/bin/sh/errors/write-error1.0
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/tools/regression/bin/sh/errors/write-error1.0  Wed Dec 12 22:01:10 
2012(r244162)
@@ -0,0 +1,3 @@
+# $FreeBSD$
+
+! echo >&- 2>/dev/null
___
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: r244112 - head/sys/kern

2012-12-12 Thread John Baldwin
On Wednesday, December 12, 2012 12:06:22 pm Adrian Chadd wrote:
> kassert()s are already optional. Ie, you can choose to not compile them in.
> 
> So the __dead2() code path bit for doing KASSERT() -> kassert_panic()
> at compile time isn't a problem.
> 
> The problem is where you do panic() -> kassert_panic() (eg in the
> Witness code) which is what Alfred discovered shortly after doing up
> his initial patch.
> 
> Anything which is a KASSERT() can and should be treated as a run-time
> warning just as much as a run-time "crash here so I can figure out
> what broke." Having the warning in a production box is going to be
> helpful for developers.

Hmmm, I'll have to chew on this.  Adding lots of returns because panic's are
now no longer dead2 was why I ended up backing the removal of the
RESTARTABLE_PANICS option.

I'm inclined to say that it's really bad to let a kernel known to be in a
bad state continue, and that if someone has asked for the slowdown of all
the extra checks INVARIANTS adds, they might as well minimize the chance for
data corruption by having the kernel stop as soon as a problem is detected.

(Note that the primary reason I know for people not running with INVARIANTS
enabled is not that they don't want panics, but that they don't want the
performance hit.)

-- 
John Baldwin
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
On 12 December 2012 13:58, John Baldwin  wrote:


>> Anything which is a KASSERT() can and should be treated as a run-time
>> warning just as much as a run-time "crash here so I can figure out
>> what broke." Having the warning in a production box is going to be
>> helpful for developers.
>
> Hmmm, I'll have to chew on this.  Adding lots of returns because panic's are
> now no longer dead2 was why I ended up backing the removal of the
> RESTARTABLE_PANICS option.

Yes, for panic() as it stands it should just do that - panic. We
should likely go over the panic()s and replace them with
kassert+handle gracefully wherever its appropriate (there are a few
places in net80211 for example that I'd like to do this.)

But you're right. For panic(), the rest of the code likely doesn't
handle or continue gracefully, so we shouldn't automatically disable
them.

But this is about KASSERT(). Alfred mixed this in with witness "non
panic" mode, which I think is what's confusing people.

> I'm inclined to say that it's really bad to let a kernel known to be in a
> bad state continue, and that if someone has asked for the slowdown of all
> the extra checks INVARIANTS adds, they might as well minimize the chance for
> data corruption by having the kernel stop as soon as a problem is detected.

Right, but that should be an option. It'd be nice if we were able to
dump out some system state when an invariant condition or witness
issue was hit (like a mini scripted ddb dump - say, log things like
the current lock state) but then continue.

> (Note that the primary reason I know for people not running with INVARIANTS
> enabled is not that they don't want panics, but that they don't want the
> performance hit.)

Well, it would be nice to be able to enable invariants on some
shipping "debug" versions of images in order to gather more data
without crashing the kernel.



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: r244163 - head/share/misc

2012-12-12 Thread Jim Harris
Author: jimharris
Date: Wed Dec 12 22:25:31 2012
New Revision: 244163
URL: http://svnweb.freebsd.org/changeset/base/244163

Log:
  Add my ex-mentors.

Modified:
  head/share/misc/committers-src.dot

Modified: head/share/misc/committers-src.dot
==
--- head/share/misc/committers-src.dot  Wed Dec 12 22:01:10 2012
(r244162)
+++ head/share/misc/committers-src.dot  Wed Dec 12 22:25:31 2012
(r244163)
@@ -241,6 +241,7 @@ rstone [label="Ryan Stone\nrstone@FreeBS
 ru [label="Ruslan Ermilov\n...@freebsd.org\n1999/05/27"]
 rwatson [label="Robert N. M. Watson\nrwat...@freebsd.org\n1999/12/16"]
 sam [label="Sam Leffler\n...@freebsd.org\n2002/07/02"]
+sbruno [label="Sean Bruno\nsbr...@freebsd.org\n/??/??"]
 sanpei [label="MIHIRA Sanpei Yoshiro\nsan...@freebsd.org\n2000/06/19"]
 scf [label="Sean C. Farley\n...@freebsd.org\n2007/06/24"]
 schweikh [label="Jens Schweikhardt\nschwe...@freebsd.org\n2001/04/06"]
@@ -602,8 +603,11 @@ sam -> andre
 sam -> benjsc
 sam -> sephe
 
+sbruno -> jimharris
+
 schweikh -> dds
 
+scottl -> jimharris
 scottl -> pjd
 scottl -> sah
 scottl -> yongari
___
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: r244112 - head/sys/kern

2012-12-12 Thread Alfred Perlstein

On 12/12/12 2:15 PM, Adrian Chadd wrote:

On 12 December 2012 13:58, John Baldwin  wrote:



(Note that the primary reason I know for people not running with INVARIANTS
enabled is not that they don't want panics, but that they don't want the
performance hit.)

Well, it would be nice to be able to enable invariants on some
shipping "debug" versions of images in order to gather more data
without crashing the kernel.
Yes, two of my employers were more of "we want to get more debug 
metrics, we have the spare cycles, but we can't deal with superfluous 
panics".


It also allows us "non-architects" to slip in a debug image when we have 
spare cpu without getting yelled at for "crashing the $foo".



-Alfred

___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 12/12/2012 23:58 John Baldwin said the following:
> Hmmm, I'll have to chew on this.  Adding lots of returns because panic's are
> now no longer dead2 was why I ended up backing the removal of the
> RESTARTABLE_PANICS option.
> 
> I'm inclined to say that it's really bad to let a kernel known to be in a
> bad state continue, and that if someone has asked for the slowdown of all
> the extra checks INVARIANTS adds, they might as well minimize the chance for
> data corruption by having the kernel stop as soon as a problem is detected.
> 
> (Note that the primary reason I know for people not running with INVARIANTS
> enabled is not that they don't want panics, but that they don't want the
> performance hit.)

Previously we had two alternatives:
- use INVARIANTS and be sure that the kernel is in sane state, that any bugs are
caught early, no corruptions / insanity is propagated to the point where
valuable data can be hurt; the price is lower (possibly much lower) performance
because of all other checks;
- do not use INVARIANTS and risk that some error would not be caught early and
would cause greater harm; the upside is better performance;

So people used (use) INVARIANTS to extensively test any new code/environments,
but then prefer to run production systems without INVARIANTS.

Now we get a new middle-ground: get both worse performance (because KASSERTs are
compiled in) and a risk of harming your data (because KASSERTs no longer panic).
 The upside: there is no panic!  There's just a log message (or etc).  and
chance to get more log messages because the insanity propagates.  And a chance
to lose your data (your customer's) - but I've already mentioned this.

I am not sure that I like this kind of middle-ground.

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 13/12/2012 00:27 Alfred Perlstein said the following:
> On 12/12/12 2:15 PM, Adrian Chadd wrote:
>> On 12 December 2012 13:58, John Baldwin  wrote:
>>
>>
>>> (Note that the primary reason I know for people not running with INVARIANTS
>>> enabled is not that they don't want panics, but that they don't want the
>>> performance hit.)
>> Well, it would be nice to be able to enable invariants on some
>> shipping "debug" versions of images in order to gather more data
>> without crashing the kernel.
> Yes, two of my employers were more of "we want to get more debug metrics, we
> have the spare cycles, but we can't deal with superfluous panics".
> 
> It also allows us "non-architects" to slip in a debug image when we have spare
> cpu without getting yelled at for "crashing the $foo".

There is clearly something wrong with this sort of mentality.

If you find instances where a developer put panic(9) (or KASSERT or etc) to mean
"maybe here is a bug, let's just panic", then let's get those things fixed.

But most of assertions in our code that are know to me really mean that a real
bug has already occurred, that portions of kernel state are corrupted and there
is no going back to a sane state, only going forward to corrupting more and 
more.


-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 12/12/2012 19:06 Adrian Chadd said the following:
> kassert()s are already optional. Ie, you can choose to not compile them in.
> 
> So the __dead2() code path bit for doing KASSERT() -> kassert_panic()
> at compile time isn't a problem.
> 
> The problem is where you do panic() -> kassert_panic() (eg in the
> Witness code) which is what Alfred discovered shortly after doing up
> his initial patch.
> 
> Anything which is a KASSERT() can and should be treated as a run-time
> warning just as much as a run-time "crash here so I can figure out
> what broke." Having the warning in a production box is going to be
> helpful for developers.

I have a quite different view on purpose and costs of KASSERTs.
Specifically referring to r243980 I do not think that "non-fatal asserts" should
really exist (or do exist).  I wish all this muddying of KASSERT meaning
would get reverted.

These quite sensitive changes were rushed in, IMO.


> On 12 December 2012 07:46, John Baldwin  wrote:
>> On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote:
>>> Author: alfred
>>> Date: Tue Dec 11 07:08:14 2012
>>> New Revision: 244112
>>> URL: http://svnweb.freebsd.org/changeset/base/244112
>>>
>>> Log:
>>>   Cleanup more of the kassert_panic.
>>>
>>>   fix compile warnings on !amd64 and NULL derefs that would happen
>>>   if kassert_panic() would return.
>>
>> This is one reason why having kassert not panic is such a bad idea.  There 
>> are
>> tons of places where the compiler knows that panic() is __dead2, and there is
>> no cleanup code to handle what happens when an invariant is violated.  This 
>> is
>> not safe to run in the field unless your customers do not care about their
>> data.  If you are interested in doing regression tests, I am using a very
>> different approach for some locking regression tests I am working on in p4
>> that allow you to use a wrapper around setjmp/longjmp to "catch" panics
>> somewhat like exception handling in C++/Java (though much cruder).  However,
>> evne that is only intended for testing, not for production cases where
>> production data is at stake.
>>
>> --
>> John Baldwin


-- 
Andriy Gapon

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
There are two parts to this;

* don't compile in invariants. Panics panic. Invariant conditions
aren't checked. You end up with data corruption still if there are
bugs.
* compile in invariants. Panics panic. Invariant conditions are
checked and immediately panic. You can't run this in production to get
debugging info because our debugging info is "create a crash dump and
reboot."

Now, the crash dump is great for us developers. But crap for say, a
file server. If it's some very subtle issue that only occasionally
pops up once a week and doesn't obviously screw with your data:

* you can enable invariants and get a crash dump each time - then us
developers get lots of information, but the user experiences outages
once a week;
* they just give the hell up, disable invariants in production and
occasionally hit odd issues they can't explain.

So now there's a third option:

* enable invariants, get told when you hit that condition, and continue running.

Now, we ship _right now_ generic with INVARIANTS disabled, because in
theory the releases are supposed to be stable enough for us not to
need the extra debugging information. That means that for those very
occasional, very subtle bugs that invariants may catch, we don't have
any way of getting told about them.

Now, enabling some alternative to panic() is a different story and not
what's being addressed here.

HTH,



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"


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

2012-12-12 Thread Adrian Chadd
On 12 December 2012 14:33, Andriy Gapon  wrote:

>> Yes, two of my employers were more of "we want to get more debug metrics, we
>> have the spare cycles, but we can't deal with superfluous panics".
>>
>> It also allows us "non-architects" to slip in a debug image when we have 
>> spare
>> cpu without getting yelled at for "crashing the $foo".
>
> There is clearly something wrong with this sort of mentality.
>
> If you find instances where a developer put panic(9) (or KASSERT or etc) to 
> mean
> "maybe here is a bug, let's just panic", then let's get those things fixed.
>
> But most of assertions in our code that are know to me really mean that a real
> bug has already occurred, that portions of kernel state are corrupted and 
> there
> is no going back to a sane state, only going forward to corrupting more and 
> more.

Dude, if you're running -STABLE right now, you don't have invariants
enabled and you aren't checking for them.
So right now, as it stands, large swaths of our kernel code are
falling afoul of what you're calling Alfred out on.

Before you all reply, please review and understand the difference
between "panic()" and "KASSERT()". panic() is not being changed here.
KASSERT() is what's being changed here. panic() is not optional.
KASSERT() is. With a non-INVARIANTS kernel, we _are not checking
invariants_ and we are continuing to run _after_ said non-compiled-in
invariants. With this in mind, please re-review this. :-)



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"


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

2012-12-12 Thread Alfred Perlstein

On 12/12/12 2:29 PM, Andriy Gapon wrote:
Now we get a new middle-ground: get both worse performance (because 
KASSERTs are compiled in) and a risk of harming your data (because 
KASSERTs no longer panic). The upside: there is no panic! There's just 
a log message (or etc). and chance to get more log messages because 
the insanity propagates. And a chance to lose your data (your 
customer's) - but I've already mentioned this. I am not sure that I 
like this kind of middle-ground. 

I have a number of points here:

The most important one being:
1) without kassert you would still have the bug, just that it would be 
unreported.
  The upside: there is no panic! There's **NO** log message (or etc). 
and chance to get more log messages because the insanity propagates.


Terrible!

Let me explain that again:
If you don't compile in KASSERT, then it's not like the condition is 
never going to happen.  Instead it will just be unreported.


So to put it in your own words, *without* KASSERT you get:

  The upside: there is no panic! There's **NO** log message (or etc). 
and chance to get more log messages because the insanity propagates.




Now let's get to the other points:

2) Since this is not the default, then I do not understand why you are 
so concerned.


3) Can you explain to me why it is so upsetting to you that someone 
might be able to use this functionality?


4) *puts on flame retardant suit* ... Linux has had this for over a 
decade and it's allowed them to find bugs in different ways.  Mind you, 
in Linux it was the default.


5) Adrian and I have both stated that we need this sort of functionality 
to avoid superfluous panics in our work environments while still getting 
bug feedback.


Can we now please stop arguing over a non-default option that will help 
some vendors report bugs to the project?


Thank you,
-Alfred

___
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: r244112 - head/sys/kern

2012-12-12 Thread Alfred Perlstein

On 12/12/12 2:38 PM, Adrian Chadd wrote:

There are two parts to this;

* don't compile in invariants. Panics panic. Invariant conditions
aren't checked. You end up with data corruption still if there are
bugs.
* compile in invariants. Panics panic. Invariant conditions are
checked and immediately panic. You can't run this in production to get
debugging info because our debugging info is "create a crash dump and
reboot."

Now, the crash dump is great for us developers. But crap for say, a
file server. If it's some very subtle issue that only occasionally
pops up once a week and doesn't obviously screw with your data:

* you can enable invariants and get a crash dump each time - then us
developers get lots of information, but the user experiences outages
once a week;
* they just give the hell up, disable invariants in production and
occasionally hit odd issues they can't explain.

So now there's a third option:

* enable invariants, get told when you hit that condition, and continue running.

Now, we ship _right now_ generic with INVARIANTS disabled, because in
theory the releases are supposed to be stable enough for us not to
need the extra debugging information. That means that for those very
occasional, very subtle bugs that invariants may catch, we don't have
any way of getting told about them.

Now, enabling some alternative to panic() is a different story and not
what's being addressed here.

HTH,



Yes.

-Alfred
___
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: r244112 - head/sys/kern

2012-12-12 Thread Navdeep Parhar
On 12/12/12 14:48, Alfred Perlstein wrote:
> On 12/12/12 2:29 PM, Andriy Gapon wrote:
>> Now we get a new middle-ground: get both worse performance (because
>> KASSERTs are compiled in) and a risk of harming your data (because
>> KASSERTs no longer panic). The upside: there is no panic! There's just
>> a log message (or etc). and chance to get more log messages because
>> the insanity propagates. And a chance to lose your data (your
>> customer's) - but I've already mentioned this. I am not sure that I
>> like this kind of middle-ground. 
> I have a number of points here:
> 
> The most important one being:
> 1) without kassert you would still have the bug, just that it would be
> unreported.
>   The upside: there is no panic! There's **NO** log message (or etc).
> and chance to get more log messages because the insanity propagates.
> 
> Terrible!
> 
> Let me explain that again:
> If you don't compile in KASSERT, then it's not like the condition is
> never going to happen.  Instead it will just be unreported.

A KASSERT() really is for a condition that should never happen.  It is
primarily useful during development and testing (and when the code is
reworked or redesigned).  I agree with Andriy here -- a non-fatal assert
shouldn't really exist.

Why not add a new facility (a "if (!foo) kdb_backtrace()" or similar),
call it what you want to, enable it (or not) even in release builds if
you want to, use it wherever you want to, but let KASSERT be just the
way it is?  Adding a global knob that changes the way KASSERT behaves
risks tripping others up.  Personally, in a debug kernel I _really_ want
the kernel to stop right away if any KASSERT in my code goes off so that
its state is as close as possible to what it was at the time the problem
occurred.  In a release kernel I _really_ do not want the overhead of
the KASSERT at all.  If it was a check for a condition I wasn't sure
about then I wouldn't have written it as a KASSERT.

That's my 2 cents in case you plan to revisit your changes and were
looking around for inputs... ;-)

Regards,
Navdeep

> 
> So to put it in your own words, *without* KASSERT you get:
> 
>   The upside: there is no panic! There's **NO** log message (or etc).
> and chance to get more log messages because the insanity propagates.
> 
> 
> 
> Now let's get to the other points:
> 
> 2) Since this is not the default, then I do not understand why you are
> so concerned.
> 
> 3) Can you explain to me why it is so upsetting to you that someone
> might be able to use this functionality?
> 
> 4) *puts on flame retardant suit* ... Linux has had this for over a
> decade and it's allowed them to find bugs in different ways.  Mind you,
> in Linux it was the default.
> 
> 5) Adrian and I have both stated that we need this sort of functionality
> to avoid superfluous panics in our work environments while still getting
> bug feedback.
> 
> Can we now please stop arguing over a non-default option that will help
> some vendors report bugs to the project?
> 
> Thank you,
> -Alfred
> 

___
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: r244112 - head/sys/kern

2012-12-12 Thread Alfred Perlstein

On 12/12/12 4:02 PM, Navdeep Parhar wrote:

On 12/12/12 14:48, Alfred Perlstein wrote:

On 12/12/12 2:29 PM, Andriy Gapon wrote:

Now we get a new middle-ground: get both worse performance (because
KASSERTs are compiled in) and a risk of harming your data (because
KASSERTs no longer panic). The upside: there is no panic! There's just
a log message (or etc). and chance to get more log messages because
the insanity propagates. And a chance to lose your data (your
customer's) - but I've already mentioned this. I am not sure that I
like this kind of middle-ground.

I have a number of points here:

The most important one being:
1) without kassert you would still have the bug, just that it would be
unreported.
   The upside: there is no panic! There's **NO** log message (or etc).
and chance to get more log messages because the insanity propagates.

Terrible!

Let me explain that again:
If you don't compile in KASSERT, then it's not like the condition is
never going to happen.  Instead it will just be unreported.

A KASSERT() really is for a condition that should never happen.  It is
primarily useful during development and testing (and when the code is
reworked or redesigned).  I agree with Andriy here -- a non-fatal assert
shouldn't really exist.



What do you think happens to a FreeBSD kernel when INVARIANTS is 
compiled in and it trips an assertion after my change?



-Alfred


___
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: r244112 - head/sys/kern

2012-12-12 Thread Navdeep Parhar
On 12/12/12 16:09, Alfred Perlstein wrote:
> On 12/12/12 4:02 PM, Navdeep Parhar wrote:
>> On 12/12/12 14:48, Alfred Perlstein wrote:
>>> On 12/12/12 2:29 PM, Andriy Gapon wrote:
 Now we get a new middle-ground: get both worse performance (because
 KASSERTs are compiled in) and a risk of harming your data (because
 KASSERTs no longer panic). The upside: there is no panic! There's just
 a log message (or etc). and chance to get more log messages because
 the insanity propagates. And a chance to lose your data (your
 customer's) - but I've already mentioned this. I am not sure that I
 like this kind of middle-ground.
>>> I have a number of points here:
>>>
>>> The most important one being:
>>> 1) without kassert you would still have the bug, just that it would be
>>> unreported.
>>>The upside: there is no panic! There's **NO** log message (or etc).
>>> and chance to get more log messages because the insanity propagates.
>>>
>>> Terrible!
>>>
>>> Let me explain that again:
>>> If you don't compile in KASSERT, then it's not like the condition is
>>> never going to happen.  Instead it will just be unreported.
>> A KASSERT() really is for a condition that should never happen.  It is
>> primarily useful during development and testing (and when the code is
>> reworked or redesigned).  I agree with Andriy here -- a non-fatal assert
>> shouldn't really exist.
> 
> 
> What do you think happens to a FreeBSD kernel when INVARIANTS is
> compiled in and it trips an assertion after my change?

I know the new knob has sane defaults.  My point was that invariants
should be considered inviolable.  A knob that allows for
it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their
meaning, so it may have been better to introduce a new macro for the
kind of tests you had in mind.  I would use it too instead of the if
(!foo) kdb_backtrace() that I often resort to for conditions that I'm
not sure about.

Regards,
Navdeep
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
If a kassert is inviolable, then make it a panic() and include in the
default kernel.

Right now there's no distinction between "kassert for a condition that
shouldn't happen, but we fail gracefully" and "kassert for a condition
that shouldn't happen, and we don't handle at all."

Ideally we'd create two separate macros to express that, t.hen we
should make all kassert's that don't fail gracefully to fail
gracefully.
Anything left over should've been a panic() in the first place.

Right now, with no INVARIANTS compiled in, we don't check KASSERT().
Again, the difference between panic and KASSERT.

TL;DR - we're doing panic/assert sub-optimally; we don't have a
consistent definition of what an invariant check is; Alfred's work
doesn't change that.




Adrian

On 12 December 2012 16:25, Navdeep Parhar  wrote:
> On 12/12/12 16:09, Alfred Perlstein wrote:
>> On 12/12/12 4:02 PM, Navdeep Parhar wrote:
>>> On 12/12/12 14:48, Alfred Perlstein wrote:
 On 12/12/12 2:29 PM, Andriy Gapon wrote:
> Now we get a new middle-ground: get both worse performance (because
> KASSERTs are compiled in) and a risk of harming your data (because
> KASSERTs no longer panic). The upside: there is no panic! There's just
> a log message (or etc). and chance to get more log messages because
> the insanity propagates. And a chance to lose your data (your
> customer's) - but I've already mentioned this. I am not sure that I
> like this kind of middle-ground.
 I have a number of points here:

 The most important one being:
 1) without kassert you would still have the bug, just that it would be
 unreported.
The upside: there is no panic! There's **NO** log message (or etc).
 and chance to get more log messages because the insanity propagates.

 Terrible!

 Let me explain that again:
 If you don't compile in KASSERT, then it's not like the condition is
 never going to happen.  Instead it will just be unreported.
>>> A KASSERT() really is for a condition that should never happen.  It is
>>> primarily useful during development and testing (and when the code is
>>> reworked or redesigned).  I agree with Andriy here -- a non-fatal assert
>>> shouldn't really exist.
>>
>>
>> What do you think happens to a FreeBSD kernel when INVARIANTS is
>> compiled in and it trips an assertion after my change?
>
> I know the new knob has sane defaults.  My point was that invariants
> should be considered inviolable.  A knob that allows for
> it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their
> meaning, so it may have been better to introduce a new macro for the
> kind of tests you had in mind.  I would use it too instead of the if
> (!foo) kdb_backtrace() that I often resort to for conditions that I'm
> not sure about.
>
> Regards,
> Navdeep
___
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: r244164 - head/share/syscons/keymaps

2012-12-12 Thread Eitan Adler
Author: eadler
Date: Thu Dec 13 00:44:23 2012
New Revision: 244164
URL: http://svnweb.freebsd.org/changeset/base/244164

Log:
  Give credit where credit is due.
  
  Requested by: Álvaro Castillo
  Approved by:  cperciva (implicit)

Modified:
  head/share/syscons/keymaps/spanish.dvorak.kbd

Modified: head/share/syscons/keymaps/spanish.dvorak.kbd
==
--- head/share/syscons/keymaps/spanish.dvorak.kbd   Wed Dec 12 22:25:31 
2012(r244163)
+++ head/share/syscons/keymaps/spanish.dvorak.kbd   Thu Dec 13 00:44:23 
2012(r244164)
@@ -1,4 +1,6 @@
 # $FreeBSD$
+#
+# Submitted by:�lvaro Castillo 
 # alt
 # scan   cntrl  altalt   cntrl lock
 # code  base   shift  cntrl  shift  altshift  cntrl  shift state
___
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: r244112 - head/sys/kern

2012-12-12 Thread Alfred Perlstein

On 12/12/12 4:25 PM, Navdeep Parhar wrote:

On 12/12/12 16:09, Alfred Perlstein wrote:

What do you think happens to a FreeBSD kernel when INVARIANTS is 
compiled in and it trips an assertion after my change? 

I know the new knob has sane defaults.  My point was that invariants
should be considered inviolable.  A knob that allows for
it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their
meaning, so it may have been better to introduce a new macro for the
kind of tests you had in mind.  I would use it too instead of the if
(!foo) kdb_backtrace() that I often resort to for conditions that I'm
not sure about.



The problem again is that not all the KASSERTS are inviolable, if you 
want to do a project to split them, then please do, it would really be 
helpful, as for now, they are a mis-mash of death/warnings and there are 
at least three vendors who approve of this as well as 3 long term 
committers that approved my change (not including Adrian).


I'll be completely honest, I struggled very much with this KASSERT 
problem at a previous employer, and the second that Adrian brought up 
the idea of "optional panic" I was kicking myself so hard because the 
solution to so many problems suddenly jumped out at me.


I will assure you that taking a stand on this one issue has the 
following problems:
1) Makes it harder for at LEAST three vendors to shake out and report 
bugs back to the project.
2) Makes it more likely that someone who has useful (to some, but not 
all) patches to keep them private to avoid such arguments.


Anyhow after all this back and forth on changes that really do not 
effect anyone, ie defaults stay the same, it really has me questioning 
the sanity of contributing and/or taking the time to give this sort of 
thing to the project.  It really seems like people are getting very bent 
out of shape over minor enhancements that offer flexibility.


Like what if I do gzipp'd kernel dumps next? (on my todo list)  How many 
people will complain that "gzip is too dangerous in kernel context foo 
foo"


Not sure, I guess I'll find out?


-Alfred
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
.. just make sure you've preallocated all the space needed by the gzip
code when writing those dumps. :-)



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: r244165 - head/usr.sbin/portsnap/portsnap

2012-12-12 Thread Alfred Perlstein
Author: alfred
Date: Thu Dec 13 01:39:49 2012
New Revision: 244165
URL: http://svnweb.freebsd.org/changeset/base/244165

Log:
  Change progress indicator for downloading patches.
  
  Use a percent style indicator instead of emitting one
  long line of patch numbers.

Modified:
  head/usr.sbin/portsnap/portsnap/portsnap.sh

Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh
==
--- head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 00:44:23 2012
(r244164)
+++ head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 01:39:49 2012
(r244165)
@@ -612,6 +612,28 @@ fetch_progress() {
echo -n " "
 }
 
+pct_fmt()
+{
+   printf " \r"
+   printf "($1/$2) %02.2f%% " `echo "scale=4;$LNC / $TOTAL * 100"|bc`
+}
+
+fetch_progress_percent() {
+   TOTAL=$1
+   LNC=0
+   pct_fmt $LNC $TOTAL
+   while read x; do
+   LNC=$(($LNC + 1))
+   if [ $(($LNC % 100)) = 0 ]; then
+ pct_fmt $LNC $TOTAL
+   elif [ $(($LNC % 10)) = 0 ]; then
+   echo -n .
+   fi
+   done
+   pct_fmt $LNC $TOTAL
+   echo " done. "
+}
+
 # Sanity-check an index file
 fetch_index_sanity() {
if grep -qvE "^[-_+./@0-9A-Za-z]+\|[0-9a-f]{64}$" INDEX.new ||
@@ -781,11 +803,13 @@ fetch_update() {
echo " done." 1>${QUIETREDIR}
 
 # Attempt to fetch ports patches
-   echo -n "Fetching `wc -l < patchlist | tr -d ' '` "
+   patchcnt=`wc -l < patchlist | tr -d ' '`  
+   echo -n "Fetching $patchcnt "
echo ${NDEBUG} "patches.${DDSTATS}"
+   echo " "
tr '|' '-' < patchlist | lam -s "bp/" - |
xargs ${XARGST} ${PHTTPGET} ${SERVERNAME}   \
-   2>${STATSREDIR} | fetch_progress
+   2>${STATSREDIR} | fetch_progress_percent $patchcnt
echo "done."
 
 # Attempt to apply ports patches
___
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: r244165 - head/usr.sbin/portsnap/portsnap

2012-12-12 Thread Alfred Perlstein

Reviewed by: eadler

On 12/12/12 5:39 PM, Alfred Perlstein wrote:

Author: alfred
Date: Thu Dec 13 01:39:49 2012
New Revision: 244165
URL: http://svnweb.freebsd.org/changeset/base/244165

Log:
   Change progress indicator for downloading patches.
   
   Use a percent style indicator instead of emitting one

   long line of patch numbers.

Modified:
   head/usr.sbin/portsnap/portsnap/portsnap.sh

Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh
==
--- head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 00:44:23 2012
(r244164)
+++ head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 01:39:49 2012
(r244165)
@@ -612,6 +612,28 @@ fetch_progress() {
echo -n " "
  }
  
+pct_fmt()

+{
+   printf " \r"
+   printf "($1/$2) %02.2f%% " `echo "scale=4;$LNC / $TOTAL * 100"|bc`
+}
+
+fetch_progress_percent() {
+   TOTAL=$1
+   LNC=0
+   pct_fmt $LNC $TOTAL
+   while read x; do
+   LNC=$(($LNC + 1))
+   if [ $(($LNC % 100)) = 0 ]; then
+ pct_fmt $LNC $TOTAL
+   elif [ $(($LNC % 10)) = 0 ]; then
+   echo -n .
+   fi
+   done
+   pct_fmt $LNC $TOTAL
+   echo " done. "
+}
+
  # Sanity-check an index file
  fetch_index_sanity() {
if grep -qvE "^[-_+./@0-9A-Za-z]+\|[0-9a-f]{64}$" INDEX.new ||
@@ -781,11 +803,13 @@ fetch_update() {
echo " done." 1>${QUIETREDIR}
  
  # Attempt to fetch ports patches

-   echo -n "Fetching `wc -l < patchlist | tr -d ' '` "
+   patchcnt=`wc -l < patchlist | tr -d ' '`
+   echo -n "Fetching $patchcnt "
echo ${NDEBUG} "patches.${DDSTATS}"
+   echo " "
tr '|' '-' < patchlist | lam -s "bp/" - |
xargs ${XARGST} ${PHTTPGET} ${SERVERNAME}   \
-   2>${STATSREDIR} | fetch_progress
+   2>${STATSREDIR} | fetch_progress_percent $patchcnt
echo "done."
  
  # Attempt to apply ports patches




___
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: r244166 - head/usr.bin/calendar

2012-12-12 Thread Greg Lehey
Author: grog
Date: Thu Dec 13 01:44:58 2012
New Revision: 244166
URL: http://svnweb.freebsd.org/changeset/base/244166

Log:
  Reluctantly remove one of the most extraordinary numeric conversion
  routines I have ever seen and replace with something far more boring.

Modified:
  head/usr.bin/calendar/parsedata.c

Modified: head/usr.bin/calendar/parsedata.c
==
--- head/usr.bin/calendar/parsedata.c   Thu Dec 13 01:39:49 2012
(r244165)
+++ head/usr.bin/calendar/parsedata.c   Thu Dec 13 01:44:58 2012
(r244166)
@@ -940,15 +940,13 @@ indextooffset(char *s)
 {
int i;
struct fixs *n;
+   char *es;
 
if (s[0] == '+' || s[0] == '-') {
-   char ss[9];
-   for (i = -100; i < 100; i++) {
-   sprintf(ss, "%s%d", (i > 0) ? "+" : "", i);
-   if (strcmp(ss, s) == 0)
-   return (i);
-   }
-   return (0);
+   i = strtod (s, &es);
+   if (*es != '\0')  /* trailing junk */
+   errx (1, "Invalid specifier format: %s\n", s);
+   return (i);
}
 
for (i = 0; i < 6; 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"


svn commit: r244168 - head/usr.bin/calendar

2012-12-12 Thread Greg Lehey
Author: grog
Date: Thu Dec 13 02:21:05 2012
New Revision: 244168
URL: http://svnweb.freebsd.org/changeset/base/244168

Log:
  Use even more conventional conversion routines.
  
  Reported by: peterj@

Modified:
  head/usr.bin/calendar/parsedata.c

Modified: head/usr.bin/calendar/parsedata.c
==
--- head/usr.bin/calendar/parsedata.c   Thu Dec 13 01:58:11 2012
(r244167)
+++ head/usr.bin/calendar/parsedata.c   Thu Dec 13 02:21:05 2012
(r244168)
@@ -943,7 +943,7 @@ indextooffset(char *s)
char *es;
 
if (s[0] == '+' || s[0] == '-') {
-   i = strtod (s, &es);
+   i = strtol (s, &es, 10);
if (*es != '\0')  /* trailing junk */
errx (1, "Invalid specifier format: %s\n", s);
return (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"


svn commit: r244169 - head/sys/dev/smc

2012-12-12 Thread Oleksandr Tymoshenko
Author: gonzo
Date: Thu Dec 13 03:33:01 2012
New Revision: 244169
URL: http://svnweb.freebsd.org/changeset/base/244169

Log:
  Disable interrupts in filter in order to avoid interrupt storm and
  CPU starvation

Modified:
  head/sys/dev/smc/if_smc.c

Modified: head/sys/dev/smc/if_smc.c
==
--- head/sys/dev/smc/if_smc.c   Thu Dec 13 02:21:05 2012(r244168)
+++ head/sys/dev/smc/if_smc.c   Thu Dec 13 03:33:01 2012(r244169)
@@ -807,6 +807,10 @@ smc_intr(void *context)
struct smc_softc*sc;

sc = (struct smc_softc *)context;
+   /*
+* Block interrupts in order to let smc_task_intr to kick in
+*/
+   smc_write_1(sc, MSK, 0);
taskqueue_enqueue_fast(sc->smc_tq, &sc->smc_intr);
return (FILTER_HANDLED);
 }
@@ -827,13 +831,6 @@ smc_task_intr(void *context, int pending
smc_select_bank(sc, 2);
 
/*
-* Get the current mask, and then block all interrupts while we're
-* working.
-*/
-   if ((ifp->if_capenable & IFCAP_POLLING) == 0)
-   smc_write_1(sc, MSK, 0);
-
-   /*
 * Find out what interrupts are flagged.
 */
status = smc_read_1(sc, IST) & sc->smc_mask;
___
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: r244170 - head/sys/dev/sym

2012-12-12 Thread Oleksandr Tymoshenko
Author: gonzo
Date: Thu Dec 13 03:34:24 2012
New Revision: 244170
URL: http://svnweb.freebsd.org/changeset/base/244170

Log:
  Add memory barrier macros for ARM

Modified:
  head/sys/dev/sym/sym_hipd.c

Modified: head/sys/dev/sym/sym_hipd.c
==
--- head/sys/dev/sym/sym_hipd.c Thu Dec 13 03:33:01 2012(r244169)
+++ head/sys/dev/sym/sym_hipd.c Thu Dec 13 03:34:24 2012(r244170)
@@ -135,6 +135,8 @@ typedef u_int32_t u32;
 #define MEMORY_BARRIER()   __asm__ volatile("mf.a; mf" : : : "memory")
 #elif  defined __sparc64__
 #define MEMORY_BARRIER()   __asm__ volatile("membar #Sync" : : : "memory")
+#elif  defined __arm__
+#define MEMORY_BARRIER()   __do_dmb()
 #else
 #error "Not supported platform"
 #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: r244171 - head/sys/dev/uart

2012-12-12 Thread Oleksandr Tymoshenko
Author: gonzo
Date: Thu Dec 13 03:35:47 2012
New Revision: 244171
URL: http://svnweb.freebsd.org/changeset/base/244171

Log:
  Prevent possible usage of uninitialized pbase variable by checking
  return value of fdt_get_range

Modified:
  head/sys/dev/uart/uart_bus_fdt.c

Modified: head/sys/dev/uart/uart_bus_fdt.c
==
--- head/sys/dev/uart/uart_bus_fdt.cThu Dec 13 03:34:24 2012
(r244170)
+++ head/sys/dev/uart/uart_bus_fdt.cThu Dec 13 03:35:47 2012
(r244171)
@@ -206,8 +206,10 @@ uart_cpu_getdev(int devtype, struct uart
err = fdt_regsize(node, &start, &size);
if (err)
return (ENXIO);
+   err = fdt_get_range(OF_parent(node), 0, &pbase, &psize);
+   if (err)
+   pbase = 0;
 
-   fdt_get_range(OF_parent(node), 0, &pbase, &psize);
start += pbase;
 
return (bus_space_map(di->bas.bst, start, size, 0, &di->bas.bsh));
___
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: r244179 - head/sys/powerpc/wii

2012-12-12 Thread Rui Paulo
Author: rpaulo
Date: Thu Dec 13 06:42:44 2012
New Revision: 244179
URL: http://svnweb.freebsd.org/changeset/base/244179

Log:
  Add the common FreeBSD SVN properties.

Modified:
Directory Properties:
  head/sys/powerpc/wii/locore.S   (props changed)
___
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: r244180 - head/contrib/top

2012-12-12 Thread Rui Paulo
Author: rpaulo
Date: Thu Dec 13 06:45:45 2012
New Revision: 244180
URL: http://svnweb.freebsd.org/changeset/base/244180

Log:
  Bump MAX_COLS to 512 to take advantage of wider terminals.

Modified:
  head/contrib/top/top.h

Modified: head/contrib/top/top.h
==
--- head/contrib/top/top.h  Thu Dec 13 06:42:44 2012(r244179)
+++ head/contrib/top/top.h  Thu Dec 13 06:45:45 2012(r244180)
@@ -14,7 +14,7 @@
 extern int Header_lines;   /* 7 */
 
 /* Maximum number of columns allowed for display */
-#define MAX_COLS   128
+#define MAX_COLS   512
 
 /* Log base 2 of 1024 is 10 (2^10 == 1024) */
 #define LOG102410
___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 13/12/2012 00:38 Adrian Chadd said the following:
> There are two parts to this;
> 
> * don't compile in invariants. Panics panic. Invariant conditions
> aren't checked. You end up with data corruption still if there are
> bugs.
> * compile in invariants. Panics panic. Invariant conditions are
> checked and immediately panic. You can't run this in production to get
> debugging info because our debugging info is "create a crash dump and
> reboot."
> 
> Now, the crash dump is great for us developers. But crap for say, a
> file server. If it's some very subtle issue that only occasionally
> pops up once a week and doesn't obviously screw with your data:
> 
> * you can enable invariants and get a crash dump each time - then us
> developers get lots of information, but the user experiences outages
> once a week;
> * they just give the hell up, disable invariants in production and
> occasionally hit odd issues they can't explain.
> 
> So now there's a third option:
> 
> * enable invariants, get told when you hit that condition, and continue 
> running.
> 
> Now, we ship _right now_ generic with INVARIANTS disabled, because in
> theory the releases are supposed to be stable enough for us not to
> need the extra debugging information. That means that for those very
> occasional, very subtle bugs that invariants may catch, we don't have
> any way of getting told about them.
> 
> Now, enabling some alternative to panic() is a different story and not
> what's being addressed here.
> 
> HTH,

Let me see if it does...
So basically a violated assertion means that something has already gone wrong.
With assertions you catch that sooner and get full debug information and can fix
it.  Without assertions you crash anyway (in 99% cases), but later and get much
less useful information.
Now you have an option to crash later while having the worse performance and the
only benefit is a log message which may or may not be useful for debugging.

No, this doesn't help.



-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
Let me restate it again.

We can ship a STABLE kernel with INVARIANTS enabled, and it not be any
less stable than the STABLE kernel is today.



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"


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

2012-12-12 Thread Andriy Gapon
on 13/12/2012 00:43 Adrian Chadd said the following:
> On 12 December 2012 14:33, Andriy Gapon  wrote:
> 
>>> Yes, two of my employers were more of "we want to get more debug metrics, we
>>> have the spare cycles, but we can't deal with superfluous panics".
>>>
>>> It also allows us "non-architects" to slip in a debug image when we have 
>>> spare
>>> cpu without getting yelled at for "crashing the $foo".
>>
>> There is clearly something wrong with this sort of mentality.
>>
>> If you find instances where a developer put panic(9) (or KASSERT or etc) to 
>> mean
>> "maybe here is a bug, let's just panic", then let's get those things fixed.
>>
>> But most of assertions in our code that are know to me really mean that a 
>> real
>> bug has already occurred, that portions of kernel state are corrupted and 
>> there
>> is no going back to a sane state, only going forward to corrupting more and 
>> more.
> 
> Dude, if you're running -STABLE right now, you don't have invariants
> enabled and you aren't checking for them.
> So right now, as it stands, large swaths of our kernel code are
> falling afoul of what you're calling Alfred out on.

Pal, it's because there are people who thoroughly and regularly test code with
INVARIANTS that the code with or without INVARIANTS does not crash as often as
it could.  When I tested the code with INVARIANTS I trust it to run without
those and if a user get a mystery panic one of the first things to advise is to
enable various debugging options.

> Before you all reply, please review and understand the difference
> between "panic()" and "KASSERT()". panic() is not being changed here.
> KASSERT() is what's being changed here. panic() is not optional.
> KASSERT() is. With a non-INVARIANTS kernel, we _are not checking
> invariants_ and we are continuing to run _after_ said non-compiled-in
> invariants. With this in mind, please re-review this. :-)

KASSERT is not optional contrary to your opinion.
We elect to not compile it in for performance reasons, but it is not optional
when it is compiled in.

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 13/12/2012 00:48 Alfred Perlstein said the following:
> On 12/12/12 2:29 PM, Andriy Gapon wrote:
>> Now we get a new middle-ground: get both worse performance (because KASSERTs
>> are compiled in) and a risk of harming your data (because KASSERTs no longer
>> panic). The upside: there is no panic! There's just a log message (or etc).
>> and chance to get more log messages because the insanity propagates. And a
>> chance to lose your data (your customer's) - but I've already mentioned this.
>> I am not sure that I like this kind of middle-ground. 
> I have a number of points here:
> 
> The most important one being:
> 1) without kassert you would still have the bug, just that it would be 
> unreported.
>   The upside: there is no panic! There's **NO** log message (or etc). and 
> chance
> to get more log messages because the insanity propagates.
> 
> Terrible!
> 
> Let me explain that again:
> If you don't compile in KASSERT, then it's not like the condition is never 
> going
> to happen.  Instead it will just be unreported.
> 
> So to put it in your own words, *without* KASSERT you get:
> 
>   The upside: there is no panic! There's **NO** log message (or etc). and 
> chance
> to get more log messages because the insanity propagates.

I disagree with your base premise.  I think that the issue will get reported
anyway.  If the code has gone insane you will get a crash, it just would be much
harder to debug.

> Now let's get to the other points:
> 
> 2) Since this is not the default, then I do not understand why you are so
> concerned.

I am concerned about the code becoming less clear and thus harder to maintain.
I am also concerned about code with INVARIANTS becoming even more slow.

> 3) Can you explain to me why it is so upsetting to you that someone might be
> able to use this functionality?

That is not upsetting to me at all.
'Someone' could develop the code in his branch / repo.  Someone can provide the
code for testing and review to his customers and other interested users.
Someone may evaluate practical usefulness of the code and only then commit it to
the tree.
As far as I can see, no one had a chance yet to see how this code is really
useful in practice.  Yet the code is already in the tree.

> 4) *puts on flame retardant suit* ... Linux has had this for over a decade and
> it's allowed them to find bugs in different ways.  Mind you, in Linux it was 
> the
> default.

Can't comment.
But if you wanted to add some equivalent of WARN_ON, then I would have zero
objection to that.  I want to have a clear distinction between "this can't
happen" and "it's weird that this happened".  KASSERT is not for error checking
or for spotting funny situations.  It's for asserting sanity in the code as its
name implies.

> 5) Adrian and I have both stated that we need this sort of functionality to
> avoid superfluous panics in our work environments while still getting bug 
> feedback.

Good.  Please use this code.

> Can we now please stop arguing over a non-default option that will help some
> vendors report bugs to the project?

Please do use this code, please do report the bugs.
Please postpone putting this code into the tree until its benefits are seen.

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
Andriy,

If you are willing to enable INVARIANTS by default in GENERIC, right
now, then I think we should remove Alfred's work.




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"


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

2012-12-12 Thread Andriy Gapon
on 13/12/2012 08:49 Adrian Chadd said the following:
> Let me restate it again.
> 
> We can ship a STABLE kernel with INVARIANTS enabled, and it not be any
> less stable than the STABLE kernel is today.

STABLE != stable, of course.
And it will be much much slower, so no one (of the regular users) would use it.

It seems like you are missing a point of KASSERT a little bit, the part why it
is a compile-time option and not a run-time thing.

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Andriy Gapon
on 13/12/2012 09:07 Adrian Chadd said the following:
> Andriy,
> 
> If you are willing to enable INVARIANTS by default in GENERIC, right
> now, then I think we should remove Alfred's work.

I do not see any connection.
INVARIANTS in !CURRENT will not be enabled in GENERIC regardless of Alfred'd
work.  INVARIANTS in CURRENT are and will be enabled in GENERIC regardless of
Alfred'd work.

-- 
Andriy Gapon
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
Hi,

I think the fundamental problem here is we have some pretty different
ideas of what KASSERT should be, versus what it actually is in various
parts of the code.

Since we're lost in semantics, we're not going to get any further on
this discussion just for now, so let's take a break and think about
other things for now.



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"


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

2012-12-12 Thread Navdeep Parhar
On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote:
> Andriy,
> 
> If you are willing to enable INVARIANTS by default in GENERIC, right
> now, then I think we should remove Alfred's work.

It's already enabled by default in GENERIC in the development branch
(aka head), which is exactly the right thing to do.  Surely, you're not
advocating we enable it by default in any release branch?

Regards,
Navdeep
___
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: r244112 - head/sys/kern

2012-12-12 Thread Adrian Chadd
On 12 December 2012 23:19, Navdeep Parhar  wrote:
> On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote:
>> Andriy,
>>
>> If you are willing to enable INVARIANTS by default in GENERIC, right
>> now, then I think we should remove Alfred's work.
>
> It's already enabled by default in GENERIC in the development branch
> (aka head), which is exactly the right thing to do.  Surely, you're not
> advocating we enable it by default in any release branch?

I'm sure at least one vendor out there would love to ship GENERIC +
INVARIANTS minus the panic bit, so they get all of the invariants
reporting and checking, but none of the panicing (which wouldn't occur
if INVARIANTS wasn't compiled in.)

WITNESS is still slow, but after I fixed a rather hilarious strlen()
abuse in it, it actually started to be more useful to enable at
runtime on my test equipment by default. Before I fixed that strlen()
issue, I couldn't get anywhere near line rate ethernet/wifi
throughput, so I didn't want to leave it on.


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"