date:20160731

Re: IWM(7260), no connect

2016-07-31 Thread Larry Rosenman

Even with that reverted, I'm still having iffy connections. 

Current code:

FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 16:02:39 
CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 121

Current diff to that SVN Rev:

Index: sys/dev/iwm/if_iwm.c
===
--- sys/dev/iwm/if_iwm.c(revision 303597)
+++ sys/dev/iwm/if_iwm.c(working copy)
@@ -3357,15 +3357,12 @@
uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
 
if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
-   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
-   } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
-   } else {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
-   }
+   subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
+   tx->pm_frame_timeout = htole16(3);
+   else
+   tx->pm_frame_timeout = htole16(2);
} else {
-   tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
+   tx->pm_frame_timeout = htole16(0);
}
 
if (hdrlen & 3) {
Index: sys/dev/iwm/if_iwmreg.h
===
--- sys/dev/iwm/if_iwmreg.h (revision 303597)
+++ sys/dev/iwm/if_iwmreg.h (working copy)
@@ -4244,18 +4244,6 @@
IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
 }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
 
-/**
- * enum iwm_tx_pm_timeouts - pm timeout values in TX command
- * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
- * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
- * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
- */
-enum iwm_tx_pm_timeouts {
-   IWM_PM_FRAME_NONE   = 0,
-   IWM_PM_FRAME_MGMT   = 2,
-   IWM_PM_FRAME_ASSOC  = 3,
-};
-
 /*
  * TX command security control
  */



Scan Debug:
http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt

What next?

On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> +imre,
> 
> Hi! Larry is having issues with r303418. Would you be able to help him out?
> 
> (If it's not too bad, can we back this out until you figure out what's
> going on?)
> 
> Thanks!
> 
> 
> -a
> 
> 
> On 28 July 2016 at 18:05, Larry Rosenman  wrote:
> > On 2016-07-28 20:02, Adrian Chadd wrote:
> >>
> >> Hi,
> >>
> >> Which commit(s) did you revert?
> >>
> >>
> >>
> >> -a
> >
> >
> > revert r303418
> >
> > and now it connects again.
> >
> >
> > --
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IWM(7260), no connect

2016-07-31 Thread Larry Rosenman

I recompiled security/wpa_supplicant and seem to be able to get
associated. 

I'm not sure what is going on. 

Any suggestions?

On Sun, Jul 31, 2016 at 08:36:47PM -0500, Larry Rosenman wrote:
> Even with that reverted, I'm still having iffy connections. 
> 
> Current code:
> 
> FreeBSD pita 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r303597M: Sun Jul 31 
> 16:02:39 CDT 2016 root@pita:/usr/obj/usr/src/sys/IWM-DEBUG  amd64 121 
> 121
> 
> Current diff to that SVN Rev:
> 
> Index: sys/dev/iwm/if_iwm.c
> ===
> --- sys/dev/iwm/if_iwm.c  (revision 303597)
> +++ sys/dev/iwm/if_iwm.c  (working copy)
> @@ -3357,15 +3357,12 @@
>   uint8_t subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK;
>  
>   if (subtype == IEEE80211_FC0_SUBTYPE_ASSOC_REQ ||
> - subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ) {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_ASSOC);
> - } else if (subtype == IEEE80211_FC0_SUBTYPE_ACTION) {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> - } else {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_MGMT);
> - }
> + subtype == IEEE80211_FC0_SUBTYPE_REASSOC_REQ)
> + tx->pm_frame_timeout = htole16(3);
> + else
> + tx->pm_frame_timeout = htole16(2);
>   } else {
> - tx->pm_frame_timeout = htole16(IWM_PM_FRAME_NONE);
> + tx->pm_frame_timeout = htole16(0);
>   }
>  
>   if (hdrlen & 3) {
> Index: sys/dev/iwm/if_iwmreg.h
> ===
> --- sys/dev/iwm/if_iwmreg.h   (revision 303597)
> +++ sys/dev/iwm/if_iwmreg.h   (working copy)
> @@ -4244,18 +4244,6 @@
>   IWM_TX_CMD_FLG_HCCA_CHUNK   = (1 << 31)
>  }; /* IWM_TX_FLAGS_BITS_API_S_VER_1 */
>  
> -/**
> - * enum iwm_tx_pm_timeouts - pm timeout values in TX command
> - * @IWM_PM_FRAME_NONE: no need to suspend sleep mode
> - * @IWM_PM_FRAME_MGMT: fw suspend sleep mode for 100TU
> - * @IWM_PM_FRAME_ASSOC: fw suspend sleep mode for 10sec
> - */
> -enum iwm_tx_pm_timeouts {
> - IWM_PM_FRAME_NONE   = 0,
> - IWM_PM_FRAME_MGMT   = 2,
> - IWM_PM_FRAME_ASSOC  = 3,
> -};
> -
>  /*
>   * TX command security control
>   */
> 
> 
> 
> Scan Debug:
> http://www.lerctr.org/~ler/FreeBSD/WIFI-Scan.txt
> 
> What next?
> 
> On Thu, Jul 28, 2016 at 06:06:47PM -0700, Adrian Chadd wrote:
> > +imre,
> > 
> > Hi! Larry is having issues with r303418. Would you be able to help him out?
> > 
> > (If it's not too bad, can we back this out until you figure out what's
> > going on?)
> > 
> > Thanks!
> > 
> > 
> > -a
> > 
> > 
> > On 28 July 2016 at 18:05, Larry Rosenman  wrote:
> > > On 2016-07-28 20:02, Adrian Chadd wrote:
> > >>
> > >> Hi,
> > >>
> > >> Which commit(s) did you revert?
> > >>
> > >>
> > >>
> > >> -a
> > >
> > >
> > > revert r303418
> > >
> > > and now it connects again.
> > >
> > >
> > > --
> > > Larry Rosenman http://www.lerctr.org/~ler
> > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is back to stable : FreeBSD_HEAD #511

2016-07-31 Thread jenkins-admin

See 

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

Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #185

2016-07-31 Thread jenkins-admin

See 

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

Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

2016-07-31 Thread Nathan Whitehorn




On 07/30/16 23:20, Xin Li wrote:

Hi,

I finally got some time to explore the UEFI boot process (kudos to
everyone who made this work!) and getting myself familiarize with the
basics.

One quick question -- Is there some technical restriction that prevents
us from merging boot1.efi and loader.efi into one binary?

Cheers,



No technical reason (and, in fact, when you boot from CD, that's how it 
works). The reason they are different is that we traditionally don't 
mount the EFI partition and so make installworld can't replace things 
there. boot1.efi is a basically static piece of code that doesn't need 
updates and can load loader, which does get updates, from a UFS/ZFS system.


loader.efi additionally assumes that it is started from the same 
partition that contains the kernel, loader.conf, fstab, etc., which are 
also generally not on the EFI partition (except in the CD case).

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

[PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik

The patch can be found inline below and also here:
https://people.freebsd.org/~mjg/lock_backoff_complete.diff

The previous version of the patch was posted here:
https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html

This time around instead of a total hack I have something of reasonable
quality.

Problem description and the way to fix it stands, to quote:
> If the lock is contended, primitives like __mtx_lock_sleep will spin
> checking if the owner is running or the lock was freed. The problem is
> that once it is discovered that the lock is free, multiple CPUs are
> likely to try to do the atomic op which will make it more costly for
> everyone and throughput suffers.

> The standard thing to do is to have some sort of a randomized delay so
> that this kind of behaviour is reduced.

So, this time around lock_delay primitive accepts configuration including
min/max spin count per iteration, incrementation step per lock_delay
invocation and total spins allowed during one execution of the locking
primitive. The code "autotunes" with mp_ncpus on boot. Current values
were determined after testing the code on a 80-way and a 40-way system.
There is definitely room for improvement there, but the biggest gain as
it is is sufficient to get the patch in.

Parameters are settable by lock type.

Converted locks are: mtx, sx, rwlocks.

Trivial loops spinning as long as the lock owner is running are
modified. The rest was left untouched in order to keep the patch
simpler.

The following locks were not touched: spin mutexes, thread locks and
lockmgr. First two could be, but I don't have any suitable benchmarks
for them. lockmgr has support for spinning, but is compiled out.

In terms of results, this time around I got my hands on an 80-way
machine (pig1 in the testing cluster). Vanilla kernel performance drops
significantly with increased contention. For instance, the following is
make -j 80 buildkernel of 11.0 tree on a tmpfs:
  7681.08s user 17040.02s system 7014% cpu 5:52.43 total

And this is with the patched kernel:
  4585.85s user 2365.95s system 5675% cpu 2:02.48 total

Both results are reproducible.

I would like to get this in as fast as possible.

Note: lock_delay has a .cap parameter which is currently set to 0 and
has no sysctl to control it. It is there for later when it will replace
the unmodified spinning code in sx and rwlocks.

diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
index 453add4..ca9319c 100644
--- a/sys/kern/kern_mutex.c
+++ b/sys/kern/kern_mutex.c
@@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,37 @@ struct lock_class lock_class_mtx_spin = {
 #endif
 };
 
+#ifdef ADAPTIVE_MUTEXES
+static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging");
+
+static struct lock_delay_config mtx_delay = {
+   .initial= 1000,
+   .step   = 500,
+   .cap= 0,
+   .min= 100,
+   .max= 5000,
+};
+
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, _delay.initial,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, _delay.step,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, _delay.min,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, _delay.max,
+0, "");
+
+static void
+mtx_delay_sysinit(void *dummy)
+{
+
+   mtx_delay.initial = mp_ncpus * 25;
+   mtx_delay.min = mp_ncpus * 5;
+   mtx_delay.max = mp_ncpus * 25 * 10;
+}
+LOCK_DELAY_SYSINIT(mtx_delay_sysinit);
+#endif
+
 /*
  * System-wide mutexes
  */
@@ -408,8 +440,11 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
int contested = 0;
uint64_t waittime = 0;
 #endif
-#ifdef KDTRACE_HOOKS
+#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS)
uint64_t spin_cnt = 0;
+   uint64_t delay = 0;
+#endif
+#ifdef KDTRACE_HOOKS
uint64_t sleep_cnt = 0;
int64_t sleep_time = 0;
int64_t all_time = 0;
@@ -471,12 +506,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
"spinning", "lockname:\"%s\"",
m->lock_object.lo_name);
while (mtx_owner(m) == owner &&
-   TD_IS_RUNNING(owner)) {
-   cpu_spinwait();
-#ifdef KDTRACE_HOOKS
-   spin_cnt++;
-#endif
-   }
+   TD_IS_RUNNING(owner))
+   lock_delay(, _delay, 
_cnt);
KTR_STATE0(KTR_SCHED, "thread",
sched_tdname((struct thread *)tid),
"running");
diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c
index 496738d..cd93520 100644
---

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Konstantin Belousov

On Sun, Jul 31, 2016 at 11:57:06AM +0200, Mateusz Guzik wrote:
> The patch can be found inline below and also here:
> https://people.freebsd.org/~mjg/lock_backoff_complete.diff
> 
> The previous version of the patch was posted here:
> https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062320.html
> 
> This time around instead of a total hack I have something of reasonable
> quality.
> 
> Problem description and the way to fix it stands, to quote:
> > If the lock is contended, primitives like __mtx_lock_sleep will spin
> > checking if the owner is running or the lock was freed. The problem is
> > that once it is discovered that the lock is free, multiple CPUs are
> > likely to try to do the atomic op which will make it more costly for
> > everyone and throughput suffers.
> 
> > The standard thing to do is to have some sort of a randomized delay so
> > that this kind of behaviour is reduced.
> 
> So, this time around lock_delay primitive accepts configuration including
> min/max spin count per iteration, incrementation step per lock_delay
> invocation and total spins allowed during one execution of the locking
> primitive. The code "autotunes" with mp_ncpus on boot. Current values
> were determined after testing the code on a 80-way and a 40-way system.
> There is definitely room for improvement there, but the biggest gain as
> it is is sufficient to get the patch in.
> 
> Parameters are settable by lock type.
> 
> Converted locks are: mtx, sx, rwlocks.
> 
> Trivial loops spinning as long as the lock owner is running are
> modified. The rest was left untouched in order to keep the patch
> simpler.
> 
> The following locks were not touched: spin mutexes, thread locks and
> lockmgr. First two could be, but I don't have any suitable benchmarks
> for them. lockmgr has support for spinning, but is compiled out.
> 
> In terms of results, this time around I got my hands on an 80-way
> machine (pig1 in the testing cluster). Vanilla kernel performance drops
> significantly with increased contention. For instance, the following is
> make -j 80 buildkernel of 11.0 tree on a tmpfs:
>   7681.08s user 17040.02s system 7014% cpu 5:52.43 total
> 
> And this is with the patched kernel:
>   4585.85s user 2365.95s system 5675% cpu 2:02.48 total
> 
> Both results are reproducible.
> 
> I would like to get this in as fast as possible.
> 
> Note: lock_delay has a .cap parameter which is currently set to 0 and
> has no sysctl to control it. It is there for later when it will replace
> the unmodified spinning code in sx and rwlocks.
> 
> diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
> index 453add4..ca9319c 100644
> --- a/sys/kern/kern_mutex.c
> +++ b/sys/kern/kern_mutex.c
> @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -138,6 +139,37 @@ struct lock_class lock_class_mtx_spin = {
>  #endif
>  };
>  
> +#ifdef ADAPTIVE_MUTEXES
> +static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging");
> +
> +static struct lock_delay_config mtx_delay = {
> + .initial= 1000,
> + .step   = 500,
> + .cap= 0,
> + .min= 100,
> + .max= 5000,
> +};
> +
> +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, 
> _delay.initial,
> +0, "");
> +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, _delay.step,
> +0, "");
> +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, _delay.min,
> +0, "");
> +SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, _delay.max,
> +0, "");
> +
> +static void
> +mtx_delay_sysinit(void *dummy)
> +{
> +
> + mtx_delay.initial = mp_ncpus * 25;
> + mtx_delay.min = mp_ncpus * 5;
> + mtx_delay.max = mp_ncpus * 25 * 10;
> +}
> +LOCK_DELAY_SYSINIT(mtx_delay_sysinit);
> +#endif
> +
>  /*
>   * System-wide mutexes
>   */
> @@ -408,8 +440,11 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, 
> int opts,
>   int contested = 0;
>   uint64_t waittime = 0;
>  #endif
> -#ifdef KDTRACE_HOOKS
> +#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS)
>   uint64_t spin_cnt = 0;
> + uint64_t delay = 0;
> +#endif
> +#ifdef KDTRACE_HOOKS
>   uint64_t sleep_cnt = 0;
>   int64_t sleep_time = 0;
>   int64_t all_time = 0;
> @@ -471,12 +506,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, 
> int opts,
>   "spinning", "lockname:\"%s\"",
>   m->lock_object.lo_name);
>   while (mtx_owner(m) == owner &&
> - TD_IS_RUNNING(owner)) {
> - cpu_spinwait();
> -#ifdef KDTRACE_HOOKS
> - spin_cnt++;
> -#endif
> - }
> + TD_IS_RUNNING(owner))
> + lock_delay(, _delay, 
> _cnt);
>

EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

2016-07-31 Thread Xin Li

Hi,

I finally got some time to explore the UEFI boot process (kudos to
everyone who made this work!) and getting myself familiarize with the
basics.

One quick question -- Is there some technical restriction that prevents
us from merging boot1.efi and loader.efi into one binary?

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: EARLY_AP_STARTUP hangs during boot

2016-07-31 Thread Gary Jennejohn

On Sat, 30 Jul 2016 12:03:59 -0700
John Baldwin  wrote:

> On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote:
> > On Fri, 29 Jul 2016 13:17:42 -0700
> > John Baldwin  wrote:
> >   
> > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote:  
> > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP!  I
> > > > wasn't aware of that.  I prefer BSD and that's the scheduler I did
> > > > the first tests with.
> > > > 
> > > > But with the ULE scheduler the system comes up all the way.
> > > > 
> > > > It would be nice if the BSD scheduler could also be modified to
> > > > work with EARLY_AP_STARTUP.
> > > 
> > > I wasn't able to reproduce your hang with 4BSD, but I think I see a
> > > possible problem.  Try this:
> > > 
> > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > > index 7de56b6..d53331a 100644
> > > --- a/sys/kern/sched_4bsd.c
> > > +++ b/sys/kern/sched_4bsd.c
> > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td)
> > >*  - The current thread has a higher (numerically lower) or
> > >*equivalent priority.  Note that this prevents curthread from
> > >*trying to preempt to itself.
> > > -  *  - It is too early in the boot for context switches (cold is set).
> > >*  - The current thread has an inhibitor set or is in the process of
> > >*exiting.  In this case, the current thread is about to switch
> > >*out anyways, so there's no point in preempting.  If we did,
> > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td)
> > >   ("maybe_preempt: trying to run inhibited thread"));
> > >   pri = td->td_priority;
> > >   cpri = ctd->td_priority;
> > > - if (panicstr != NULL || pri >= cpri || cold /* || dumping */ ||
> > > + if (panicstr != NULL || pri >= cpri /* || dumping */ ||
> > >   TD_IS_INHIBITED(ctd))
> > >   return (0);
> > >  #ifndef FULL_PREEMPTION
> > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum)
> > >   if ((!forward_wakeup_enabled) ||
> > >(forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0))
> > >   return (0);
> > > - if (!smp_started || cold || panicstr)
> > > + if (!smp_started || panicstr)
> > >   return (0);
> > >  
> > >   forward_wakeups_requested++;
> > >   
> > 
> > Thanks, but with this patch the kernel hangs in exactly the same
> > place as before - after the HPET output.
> > 
> > Maybe I'm missing some kernel option which ULE works around, or
> > something like that.  
> 
> Hmm, ok.  Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is
> 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and
> 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)'
> 
> Please also add this patch (on top of the previous patch):
> 
> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 2973a23..bab2278 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags)
> KASSERT(td->td_flags & TDF_INMEM,
> ("sched_add: thread swapped out"));
>  
> +   CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid,
> +   sched_tdname(td));
> KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add",
> "prio:%d", td->td_priority, KTR_ATTR_LINKED,
> sched_tdname(curthread));
> diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c
> index f07b97e..1f418f1 100644
> --- a/sys/x86/x86/cpu_machdep.c
> +++ b/sys/x86/x86/cpu_machdep.c
> @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu)
> return (0);
> if (*state == STATE_MWAIT)
> *state = STATE_RUNNING;
> +   CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu);
> return (1);
>  }
> 
> (I haven't tried compiling it, you might have to add the sys/ktr.h
> header to cpu_machdep.c if it doesn't build.)
> 
> Hopefully we will get some better trace messages before it hangs
> with this added info.  The root issue seems to be that 4BSD is
> pinning thread0 to some other CPU (due to sched_bind that happens
> inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs)
> and that other CPU isn't waking up to realize it needs to run thread0.
> 

It compiled with no changes needed.

Even though I set MAXCPU to a mere 2, the boot still hadn't
completed after 90 minutes and I broke it off.  I still have
the kernel, so I can try it another time when I have less need
for my FreeBSD box.

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

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Adrian Chadd

Hi,

Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
any performance degredations on lower count CPUs?

Also, yeah, the MOD operator in each loop could get spendy on older
CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
achieve much the same autotuning with pow2 operations instead of
divide/mod?


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

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik

On Sun, Jul 31, 2016 at 01:49:28PM +0300, Konstantin Belousov wrote:
[snip]

After an irc discussion, the following was produced (also available at:
https://people.freebsd.org/~mjg/lock_backoff_complete4.diff):

Differences:
- uint64_t usage was converted to u_int (also see r303584)
- currently unused features (cap limit and return value) were removed
- lock_delay args got packed into a dedicated structure

Note this patch requires the tree to be at least at r303584.

diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
index 0555a78..9b07b8b 100644
--- a/sys/kern/kern_mutex.c
+++ b/sys/kern/kern_mutex.c
@@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,36 @@ struct lock_class lock_class_mtx_spin = {
 #endif
 };
 
+#ifdef ADAPTIVE_MUTEXES
+static SYSCTL_NODE(_debug, OID_AUTO, mtx, CTLFLAG_RD, NULL, "mtx debugging");
+
+static struct lock_delay_config mtx_delay = {
+   .initial= 1000,
+   .step   = 500,
+   .min= 100,
+   .max= 5000,
+};
+
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_initial, CTLFLAG_RW, _delay.initial,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_step, CTLFLAG_RW, _delay.step,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_min, CTLFLAG_RW, _delay.min,
+0, "");
+SYSCTL_INT(_debug_mtx, OID_AUTO, delay_max, CTLFLAG_RW, _delay.max,
+0, "");
+
+static void
+mtx_delay_sysinit(void *dummy)
+{
+
+   mtx_delay.initial = mp_ncpus * 25;
+   mtx_delay.min = mp_ncpus * 5;
+   mtx_delay.max = mp_ncpus * 25 * 10;
+}
+LOCK_DELAY_SYSINIT(mtx_delay_sysinit);
+#endif
+
 /*
  * System-wide mutexes
  */
@@ -408,8 +439,10 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
int contested = 0;
uint64_t waittime = 0;
 #endif
+#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS)
+   struct lock_delay_arg lda;
+#endif
 #ifdef KDTRACE_HOOKS
-   u_int spin_cnt = 0;
u_int sleep_cnt = 0;
int64_t sleep_time = 0;
int64_t all_time = 0;
@@ -418,6 +451,9 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
if (SCHEDULER_STOPPED())
return;
 
+#if defined(ADAPTIVE_MUTEXES) || defined(KDTRACE_HOOKS)
+   lock_delay_arg_init(, _delay);
+#endif
m = mtxlock2mtx(c);
 
if (mtx_owned(m)) {
@@ -451,7 +487,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
if (m->mtx_lock == MTX_UNOWNED && _mtx_obtain_lock(m, tid))
break;
 #ifdef KDTRACE_HOOKS
-   spin_cnt++;
+   lda.spin_cnt++;
 #endif
 #ifdef ADAPTIVE_MUTEXES
/*
@@ -471,12 +507,8 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
"spinning", "lockname:\"%s\"",
m->lock_object.lo_name);
while (mtx_owner(m) == owner &&
-   TD_IS_RUNNING(owner)) {
-   cpu_spinwait();
-#ifdef KDTRACE_HOOKS
-   spin_cnt++;
-#endif
-   }
+   TD_IS_RUNNING(owner))
+   lock_delay();
KTR_STATE0(KTR_SCHED, "thread",
sched_tdname((struct thread *)tid),
"running");
@@ -570,7 +602,7 @@ __mtx_lock_sleep(volatile uintptr_t *c, uintptr_t tid, int 
opts,
/*
 * Only record the loops spinning and not sleeping. 
 */
-   if (spin_cnt > sleep_cnt)
+   if (lda.spin_cnt > sleep_cnt)
LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time);
 #endif
 }
diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c
index d4cae61..363b042 100644
--- a/sys/kern/kern_rwlock.c
+++ b/sys/kern/kern_rwlock.c
@@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,15 +66,6 @@ PMC_SOFT_DECLARE( , , lock, failed);
  */
 #definerwlock2rw(c)(__containerof(c, struct rwlock, rw_lock))
 
-#ifdef ADAPTIVE_RWLOCKS
-static int rowner_retries = 10;
-static int rowner_loops = 1;
-static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL,
-"rwlock debugging");
-SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, _retries, 0, "");
-SYSCTL_INT(_debug_rwlock, OID_AUTO, loops, CTLFLAG_RW, _loops, 0, "");
-#endif
-
 #ifdef DDB
 #include 
 
@@ -100,6 +92,41 @@ struct lock_class lock_class_rw = {
 #endif
 };
 
+#ifdef ADAPTIVE_RWLOCKS
+static int rowner_retries = 10;
+static int rowner_loops = 1;
+static SYSCTL_NODE(_debug, OID_AUTO, rwlock, CTLFLAG_RD, NULL,
+"rwlock debugging");
+SYSCTL_INT(_debug_rwlock, OID_AUTO, retry, CTLFLAG_RW, _retries, 0, "");
+SYSCTL_INT(_debug_rwlock, OID_AUTO,

Jenkins build became unstable: FreeBSD_HEAD #513

2016-07-31 Thread jenkins-admin

See 

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

BSD grep dumps core

2016-07-31 Thread Steve Kargl


Script started on Sun Jul 31 08:30:56 2016
troutmask:sgk[200] cd gcc/gcc7
troutmask:sgk[201] svn status
?   7.diff
?   decl.c.diff
?   gcc/fortran/old
?   gcc/fortran/pr38351.diff
?   gcc/fortran/pr41922.diff
?   gcc/fortran/pr69860.diff
?   trans-decl.c.diff
?   typescript
?   z1.diff
troutmask:sgk[202] svn status | grep -v -E ^\?
Segmentation fault (core dumped)
troutmask:sgk[203] svn status | grep -v -E ^"\?"
troutmask:sgk[204] exit
exit

Script done on Sun Jul 31 08:31:54 2016

The core dump happens with both tcsh and sh.

The following works as expected

troutmask:sgk[202] svn status | gnugrep -v -E ^\?

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

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

2016-07-31 Thread Pedro Giffuni




On 07/31/16 11:56, Guy Yur wrote:

On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni  wrote:




Index: sbin/resolvconf/Makefile
===
--- sbin/resolvconf/Makefile(revision 303557)
+++ sbin/resolvconf/Makefile(working copy)
@@ -30,6 +30,7 @@
-e 's:@LIBEXECDIR@:${FILESDIR}:g' \
-e 's:@VARDIR@:${VARDIR}:g' \
-e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \
+   -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \
-e 's:@RCDIR@:${RCDIR}:g' \
-e 's: vpn : ng[0-9]*&:g' \
${DIST}/$@.in > $@





And the underscore was not a typo.
Thanks Guy!

Pedro.


Hi,

I meant for the RESTARTCMD_= statement to be added too.
I should have sent a patch file.



Ugh ... yeah I am really bad at "guessing" patches.

I will play with your patch. Thanks.

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

Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

2016-07-31 Thread Andrew Turner

On Sat, 30 Jul 2016 23:20:55 -0700
Xin Li  wrote:

> Hi,
> 
> I finally got some time to explore the UEFI boot process (kudos to
> everyone who made this work!) and getting myself familiarize with the
> basics.
> 
> One quick question -- Is there some technical restriction that
> prevents us from merging boot1.efi and loader.efi into one binary?

The only issue I know about is loader.efi will use the wrong partition
to load the kernel. This is because it assumes the kernel is to be
loaded from the same filesystem as it was.

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

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread Mateusz Guzik

On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote:
> Hi,
> 
> Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
> any performance degredations on lower count CPUs?
> 

I did not test on machines which physically that few cpus, but I did
test the impact on microbenchmark with 2 and 4 threads on the 80-way
machine. There was no difference.

For this iteration of the patch, given limited time I tried to be very
conservative as to not intoduce additional latency. In fact I would
argue the patch is undertuned (as in, it can do better in certain
workloads).

That said, I think it is safe to use.

> Also, yeah, the MOD operator in each loop could get spendy on older
> CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
> achieve much the same autotuning with pow2 operations instead of
> divide/mod?
> 

The % operation acts a randomizer. It is optional and I'm happy to ifdef
it based on the architecture. It does seem to be useful at least on
amd64.

As a side note, exponential backoff is not used to keep things smaller
(see above). It is definitely subject to change later.

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

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

2016-07-31 Thread Guy Yur

On Sun, Jul 31, 2016 at 5:46 AM, Pedro Giffuni  wrote:
>
>
>>> Index: sbin/resolvconf/Makefile
>>> ===
>>> --- sbin/resolvconf/Makefile(revision 303557)
>>> +++ sbin/resolvconf/Makefile(working copy)
>>> @@ -30,6 +30,7 @@
>>> -e 's:@LIBEXECDIR@:${FILESDIR}:g' \
>>> -e 's:@VARDIR@:${VARDIR}:g' \
>>> -e 's:@RESTARTCMD \(.*\)@:${RESTARTCMD}:g' \
>>> +   -e 's:@RESTARTCMD@:${RESTARTCMD}:g' \
>>> -e 's:@RCDIR@:${RCDIR}:g' \
>>> -e 's: vpn : ng[0-9]*&:g' \
>>> ${DIST}/$@.in > $@
>>
>>
>
> And the underscore was not a typo.
> Thanks Guy!
>
> Pedro.

Hi,

I meant for the RESTARTCMD_= statement to be added too.
I should have sent a patch file.

Issue could be seen during boot if using dhcpcd which invokes resolvconf
or by running 'resolvconf -r SERVICENAME'

With r303567, RESTARTCMD is now empty in the script so
dynamic detection for service command is done.

Attaching new patch.

1.
Renaming RESTARTCMD, CMD1, CMD2 to _WITH_ARG since it is only
used by pdns_recursor.in.
The other files have all moved to use $RESTARTCMD passed from resolvconf.

I will send a patch upstream to do the same for pdns_recursor.in.
The ugly _WITH_ARG vars can be removed when pdns_recursor.in
is updated to new style.

2.
Renaming RESTARTCMD_ to RESTARTCMD and adding the lines for
new CMD1, CMD2, RESTARTCMD statements.

Thanks,
Guy

resolvconf_RESTARTCMD.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: release name

2016-07-31 Thread Kurt Jaeger

Hi!

> Could somebody, please, explain this:
> Am I right to assume that CURRENT or "head" release number is now
> 12.0?

Yes.

> For in that case I'll have to reduild the ports in case of
> upgrading my system to the current head, right? Because my current
> system was build well before the 11.0-alpha releases statred
> appearing.

If you build them on 11.0-alpha, they are good enough. You
only need to rebuild those that no longer work.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is back to stable : FreeBSD_HEAD #514

2016-07-31 Thread jenkins-admin

See 

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

release name

2016-07-31 Thread Kostya Berger

Could somebody, please, explain this:
Am I right to assume that CURRENT or "head" release number is now 12.0?For in 
that case I'll have to reduild the ports in case of upgrading my system to the 
current head, right?Because my current system was build well before the 
11.0-alpfha releases statred appearing.


Sent from Yahoo Mail on Android
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EARLY_AP_STARTUP hangs during boot

2016-07-31 Thread John Baldwin

On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote:
> On Sat, 30 Jul 2016 12:03:59 -0700
> John Baldwin  wrote:
> 
> > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote:
> > > On Fri, 29 Jul 2016 13:17:42 -0700
> > > John Baldwin  wrote:
> > >   
> > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote:  
> > > > > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP!  I
> > > > > wasn't aware of that.  I prefer BSD and that's the scheduler I did
> > > > > the first tests with.
> > > > > 
> > > > > But with the ULE scheduler the system comes up all the way.
> > > > > 
> > > > > It would be nice if the BSD scheduler could also be modified to
> > > > > work with EARLY_AP_STARTUP.
> > > > 
> > > > I wasn't able to reproduce your hang with 4BSD, but I think I see a
> > > > possible problem.  Try this:
> > > > 
> > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > > > index 7de56b6..d53331a 100644
> > > > --- a/sys/kern/sched_4bsd.c
> > > > +++ b/sys/kern/sched_4bsd.c
> > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td)
> > > >  *  - The current thread has a higher (numerically lower) or
> > > >  *equivalent priority.  Note that this prevents curthread 
> > > > from
> > > >  *trying to preempt to itself.
> > > > -*  - It is too early in the boot for context switches (cold is 
> > > > set).
> > > >  *  - The current thread has an inhibitor set or is in the 
> > > > process of
> > > >  *exiting.  In this case, the current thread is about to 
> > > > switch
> > > >  *out anyways, so there's no point in preempting.  If we 
> > > > did,
> > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td)
> > > > ("maybe_preempt: trying to run inhibited 
> > > > thread"));
> > > > pri = td->td_priority;
> > > > cpri = ctd->td_priority;
> > > > -   if (panicstr != NULL || pri >= cpri || cold /* || dumping */ ||
> > > > +   if (panicstr != NULL || pri >= cpri /* || dumping */ ||
> > > > TD_IS_INHIBITED(ctd))
> > > > return (0);
> > > >  #ifndef FULL_PREEMPTION
> > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum)
> > > > if ((!forward_wakeup_enabled) ||
> > > >  (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop 
> > > > == 0))
> > > > return (0);
> > > > -   if (!smp_started || cold || panicstr)
> > > > +   if (!smp_started || panicstr)
> > > > return (0);
> > > >  
> > > > forward_wakeups_requested++;
> > > >   
> > > 
> > > Thanks, but with this patch the kernel hangs in exactly the same
> > > place as before - after the HPET output.
> > > 
> > > Maybe I'm missing some kernel option which ULE works around, or
> > > something like that.  
> > 
> > Hmm, ok.  Please add KTR_RUNQ and KTR_SMP to the KTR masks, that is
> > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and
> > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)'
> > 
> > Please also add this patch (on top of the previous patch):
> > 
> > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > index 2973a23..bab2278 100644
> > --- a/sys/kern/sched_4bsd.c
> > +++ b/sys/kern/sched_4bsd.c
> > @@ -1278,6 +1278,8 @@ sched_add(struct thread *td, int flags)
> > KASSERT(td->td_flags & TDF_INMEM,
> > ("sched_add: thread swapped out"));
> >  
> > +   CTR2(KTR_PROC, "sched_add: thread %d (%s)", td->td_tid,
> > +   sched_tdname(td));
> > KTR_STATE2(KTR_SCHED, "thread", sched_tdname(td), "runq add",
> > "prio:%d", td->td_priority, KTR_ATTR_LINKED,
> > sched_tdname(curthread));
> > diff --git a/sys/x86/x86/cpu_machdep.c b/sys/x86/x86/cpu_machdep.c
> > index f07b97e..1f418f1 100644
> > --- a/sys/x86/x86/cpu_machdep.c
> > +++ b/sys/x86/x86/cpu_machdep.c
> > @@ -440,6 +440,7 @@ cpu_idle_wakeup(int cpu)
> > return (0);
> > if (*state == STATE_MWAIT)
> > *state = STATE_RUNNING;
> > +   CTR1(KTR_PROC, "cpu_idle_wakeup: wokeup CPU %d", cpu);
> > return (1);
> >  }
> > 
> > (I haven't tried compiling it, you might have to add the sys/ktr.h
> > header to cpu_machdep.c if it doesn't build.)
> > 
> > Hopefully we will get some better trace messages before it hangs
> > with this added info.  The root issue seems to be that 4BSD is
> > pinning thread0 to some other CPU (due to sched_bind that happens
> > inside of bus_bind_intr() when the HPET driver pins IRQs to CPUs)
> > and that other CPU isn't waking up to realize it needs to run thread0.
> > 
> 
> It compiled with no changes needed.
> 
> Even though I set MAXCPU to a mere 2, the boot still hadn't
> completed after 90 minutes and I broke it off.  I still have
> the kernel, so I can try it another time when I have less need
> for my FreeBSD box.

Did you have the KTR options enabled from before?

Re: [PATCH] randomized delay in locking primitives, take 2

2016-07-31 Thread K. Macy

On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd  wrote:
> Hi,
>
> Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
> any performance degredations on lower count CPUs?

The adaptive spinning path will never run on a uniprocessor. Except
for potential i-cache displacement you're not going to actually see
any effect unless there is substantial contention. You'll need all
threads consistently contending for the same lock. A potential
workload to exercise this would be to run ncpu threads sending small
UDP packets on a driver with a legacy mutex protected IFQ interface.

> Also, yeah, the MOD operator in each loop could get spendy on older
> CPUs (eg my MIPS CPUs, older ARM stuff, etc.) Is it possible to
> achieve much the same autotuning with pow2 operations instead of
> divide/mod?
>
>
> -a
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI errors when booting laptop

2016-07-31 Thread K. Macy

Have you checked for BIOS updates? The BIOS on recent Skylake laptops
have been a running disaster. At least the Dell XPS laptops had ACPI
errors be fixed by an update.

-M

On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods  wrote:
> Hi everyone,
>
> I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750
> laptop with FreeBSD 12-current. I have noticed things not functioning
> correct (except suspend/resume not working), but then again I don't really
> know much about ACPI or what I should expect to see. Any ideas what the
> problem is?
>
> Full dmesg is also attached.
>
> acpi0:  on motherboard
> acpi_ec_ecdt_probe: can't get handle
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC._REG] (Node
> 0xf80005494980), AE_NOT_EXIST (20160527/psparse-559)
> acpi0: Power Button (fixed)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error:

Re: IWM(7260), no connect

Re: IWM(7260), no connect

Jenkins build is back to stable : FreeBSD_HEAD #511

Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #185

Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

[PATCH] randomized delay in locking primitives, take 2

Re: [PATCH] randomized delay in locking primitives, take 2

EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

Re: EARLY_AP_STARTUP hangs during boot

Re: [PATCH] randomized delay in locking primitives, take 2

Re: [PATCH] randomized delay in locking primitives, take 2

Jenkins build became unstable: FreeBSD_HEAD #513

BSD grep dumps core

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

Re: EFI boot: can we make loader.efi work as BOOT{x64, aa64, arm, ia32}.efi?

Re: [PATCH] randomized delay in locking primitives, take 2

Re: resolvconf needs @RESTARTCMD@ to be replaced after r303062

Re: release name

Jenkins build is back to stable : FreeBSD_HEAD #514

release name

Re: EARLY_AP_STARTUP hangs during boot

Re: [PATCH] randomized delay in locking primitives, take 2

Re: ACPI errors when booting laptop

23 matches

Site Navigation

Mail list logo

Footer information