From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 12:14:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A747B302; Sun, 4 Jan 2015 12:14:29 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D0B53E3D; Sun, 4 Jan 2015 12:14:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4F5291FE022; Sun, 4 Jan 2015 13:14:26 +0100 (CET) Message-ID: <54A92ED1.2070906@selasky.org> Date: Sun, 04 Jan 2015 13:15:13 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivan Klymenko Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> In-Reply-To: <54A53F4F.2000003@selasky.org> Content-Type: multipart/mixed; boundary="------------070009030809080804000507" Cc: FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 12:14:29 -0000 This is a multi-part message in MIME format. --------------070009030809080804000507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Please find attached an updated timeout patch which also updates clients in the kernel area to use the callout API properly, like cv_timedwait(). Previously there was some custom sleepqueue code in the callout subsystem. All of that has now been removed and we allow callouts to be protected by spinlocks. This allows us to tear down the callback like done with regular mutexes, and a "td_slpmutex" has been added to "struct thread" to atomically teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and "SWT_SLEEPQTIMO" states can now be completely removed. Summary of changes: 1) Make consistent callout API which also supports spinlocks for the callback function. This has been done to allow atomic callout stop of "td_slpcallout" without the need of many kernel threading quirks. 2) It is not allowed to migrate CPU if the timeout is restarted while the timeout callback is executing. Callouts must be stopped before CPU migration is allowed. Optionally drained. 3) Shared lock support has been removed, because it prevents atomic stop of the callback function. 4) A new API to drain callouts asynchronously has been added, called "callout_drain_async()". Please test and report any errors! Patch applies to FreeBSD-11-current as of today. Thank you! --HPS --------------070009030809080804000507 Content-Type: text/x-patch; name="kern_timeout_wip_v2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kern_timeout_wip_v2.diff" Index: sys/ofed/include/linux/completion.h =================================================================== --- sys/ofed/include/linux/completion.h (revision 276531) +++ sys/ofed/include/linux/completion.h (working copy) @@ -105,7 +105,9 @@ if (c->done) break; sleepq_add(c, NULL, "completion", flags, 0); + sleepq_release(c); sleepq_set_timeout(c, end - ticks); + sleepq_lock(c); if (flags & SLEEPQ_INTERRUPTIBLE) { if (sleepq_timedwait_sig(c, 0) != 0) return (-ERESTARTSYS); Index: sys/kern/init_main.c =================================================================== --- sys/kern/init_main.c (revision 276531) +++ sys/kern/init_main.c (working copy) @@ -504,7 +504,8 @@ callout_init_mtx(&p->p_itcallout, &p->p_mtx, 0); callout_init_mtx(&p->p_limco, &p->p_mtx, 0); - callout_init(&td->td_slpcallout, CALLOUT_MPSAFE); + mtx_init(&td->td_slpmutex, "td_slpmutex", NULL, MTX_SPIN); + callout_init_mtx(&td->td_slpcallout, &td->td_slpmutex, 0); /* Create credentials. */ p->p_ucred = crget(); Index: sys/kern/kern_condvar.c =================================================================== --- sys/kern/kern_condvar.c (revision 276531) +++ sys/kern/kern_condvar.c (working copy) @@ -313,15 +313,13 @@ DROP_GIANT(); sleepq_add(cvp, lock, cvp->cv_description, SLEEPQ_CONDVAR, 0); + sleepq_release(cvp); sleepq_set_timeout_sbt(cvp, sbt, pr, flags); if (lock != &Giant.lock_object) { - if (class->lc_flags & LC_SLEEPABLE) - sleepq_release(cvp); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); - if (class->lc_flags & LC_SLEEPABLE) - sleepq_lock(cvp); } + sleepq_lock(cvp); rval = sleepq_timedwait(cvp, 0); #ifdef KTRACE @@ -383,15 +381,13 @@ sleepq_add(cvp, lock, cvp->cv_description, SLEEPQ_CONDVAR | SLEEPQ_INTERRUPTIBLE, 0); + sleepq_release(cvp); sleepq_set_timeout_sbt(cvp, sbt, pr, flags); if (lock != &Giant.lock_object) { - if (class->lc_flags & LC_SLEEPABLE) - sleepq_release(cvp); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); - if (class->lc_flags & LC_SLEEPABLE) - sleepq_lock(cvp); } + sleepq_lock(cvp); rval = sleepq_timedwait_sig(cvp, 0); #ifdef KTRACE Index: sys/kern/kern_lock.c =================================================================== --- sys/kern/kern_lock.c (revision 276531) +++ sys/kern/kern_lock.c (working copy) @@ -210,9 +210,11 @@ GIANT_SAVE(); sleepq_add(&lk->lock_object, NULL, wmesg, SLEEPQ_LK | (catch ? SLEEPQ_INTERRUPTIBLE : 0), queue); - if ((flags & LK_TIMELOCK) && timo) + if ((flags & LK_TIMELOCK) && timo) { + sleepq_release(&lk->lock_object); sleepq_set_timeout(&lk->lock_object, timo); - + sleepq_lock(&lk->lock_object); + } /* * Decisional switch for real sleeping. */ Index: sys/kern/kern_switch.c =================================================================== --- sys/kern/kern_switch.c (revision 276531) +++ sys/kern/kern_switch.c (working copy) @@ -93,8 +93,6 @@ &DPCPU_NAME(sched_switch_stats[SWT_TURNSTILE]), ""); SCHED_STAT_DEFINE_VAR(sleepq, &DPCPU_NAME(sched_switch_stats[SWT_SLEEPQ]), ""); -SCHED_STAT_DEFINE_VAR(sleepqtimo, - &DPCPU_NAME(sched_switch_stats[SWT_SLEEPQTIMO]), ""); SCHED_STAT_DEFINE_VAR(relinquish, &DPCPU_NAME(sched_switch_stats[SWT_RELINQUISH]), ""); SCHED_STAT_DEFINE_VAR(needresched, Index: sys/kern/kern_synch.c =================================================================== --- sys/kern/kern_synch.c (revision 276531) +++ sys/kern/kern_synch.c (working copy) @@ -236,13 +236,17 @@ * return from cursig(). */ sleepq_add(ident, lock, wmesg, sleepq_flags, 0); - if (sbt != 0) - sleepq_set_timeout_sbt(ident, sbt, pr, flags); if (lock != NULL && class->lc_flags & LC_SLEEPABLE) { sleepq_release(ident); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); + if (sbt != 0) + sleepq_set_timeout_sbt(ident, sbt, pr, flags); sleepq_lock(ident); + } else if (sbt != 0) { + sleepq_release(ident); + sleepq_set_timeout_sbt(ident, sbt, pr, flags); + sleepq_lock(ident); } if (sbt != 0 && catch) rval = sleepq_timedwait_sig(ident, pri); @@ -306,8 +310,11 @@ * We put ourselves on the sleep queue and start our timeout. */ sleepq_add(ident, &mtx->lock_object, wmesg, SLEEPQ_SLEEP, 0); - if (sbt != 0) + if (sbt != 0) { + sleepq_release(ident); sleepq_set_timeout_sbt(ident, sbt, pr, flags); + sleepq_lock(ident); + } /* * Can't call ktrace with any spin locks held so it can lock the Index: sys/kern/kern_thread.c =================================================================== --- sys/kern/kern_thread.c (revision 276531) +++ sys/kern/kern_thread.c (working copy) @@ -149,6 +149,9 @@ audit_thread_alloc(td); #endif umtx_thread_alloc(td); + + mtx_init(&td->td_slpmutex, "td_slpmutex", NULL, MTX_SPIN); + callout_init_mtx(&td->td_slpcallout, &td->td_slpmutex, 0); return (0); } @@ -162,6 +165,10 @@ td = (struct thread *)mem; + /* make sure to drain any use of the "td->td_slpcallout" */ + callout_drain(&td->td_slpcallout); + mtx_destroy(&td->td_slpmutex); + #ifdef INVARIANTS /* Verify that this thread is in a safe state to free. */ switch (td->td_state) { @@ -544,7 +551,6 @@ LIST_INIT(&td->td_lprof[0]); LIST_INIT(&td->td_lprof[1]); sigqueue_init(&td->td_sigqueue, p); - callout_init(&td->td_slpcallout, CALLOUT_MPSAFE); TAILQ_INSERT_TAIL(&p->p_threads, td, td_plist); p->p_numthreads++; } Index: sys/kern/kern_timeout.c =================================================================== --- sys/kern/kern_timeout.c (revision 276531) +++ sys/kern/kern_timeout.c (working copy) @@ -54,6 +54,8 @@ #include #include #include +#include +#include #include #include #include @@ -124,37 +126,216 @@ */ u_int callwheelsize, callwheelmask; +typedef void callout_mutex_op_t(struct lock_object *); +typedef int callout_owned_op_t(struct lock_object *); + +struct callout_mutex_ops { + callout_mutex_op_t *lock; + callout_mutex_op_t *unlock; + callout_owned_op_t *owned; +}; + +enum { + CALLOUT_LC_UNUSED_0, + CALLOUT_LC_UNUSED_1, + CALLOUT_LC_UNUSED_2, + CALLOUT_LC_UNUSED_3, + CALLOUT_LC_SPIN, + CALLOUT_LC_MUTEX, + CALLOUT_LC_RW, + CALLOUT_LC_RM, +}; + +static void +callout_mutex_op_none(struct lock_object *lock) +{ +} + +static int +callout_owned_op_none(struct lock_object *lock) +{ + return (0); +} + +static void +callout_mutex_lock(struct lock_object *lock) +{ + mtx_lock((struct mtx *)lock); +} + +static void +callout_mutex_unlock(struct lock_object *lock) +{ + mtx_unlock((struct mtx *)lock); +} + +static void +callout_mutex_lock_spin(struct lock_object *lock) +{ + mtx_lock_spin((struct mtx *)lock); +} + +static void +callout_mutex_unlock_spin(struct lock_object *lock) +{ + mtx_unlock_spin((struct mtx *)lock); +} + +static int +callout_mutex_owned(struct lock_object *lock) +{ + return (mtx_owned((struct mtx *)lock)); +} + +static void +callout_rm_wlock(struct lock_object *lock) +{ + rm_wlock((struct rmlock *)lock); +} + +static void +callout_rm_wunlock(struct lock_object *lock) +{ + rm_wunlock((struct rmlock *)lock); +} + +static int +callout_rm_owned(struct lock_object *lock) +{ + return (rm_wowned((struct rmlock *)lock)); +} + +static void +callout_rw_wlock(struct lock_object *lock) +{ + rw_wlock((struct rwlock *)lock); +} + +static void +callout_rw_wunlock(struct lock_object *lock) +{ + rw_wunlock((struct rwlock *)lock); +} + +static int +callout_rw_owned(struct lock_object *lock) +{ + return (rw_wowned((struct rwlock *)lock)); +} + +static const struct callout_mutex_ops callout_mutex_ops[8] = { + [CALLOUT_LC_UNUSED_0] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_1] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_2] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_3] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_SPIN] = { + .lock = callout_mutex_lock_spin, + .unlock = callout_mutex_unlock_spin, + .owned = callout_mutex_owned, + }, + [CALLOUT_LC_MUTEX] = { + .lock = callout_mutex_lock, + .unlock = callout_mutex_unlock, + .owned = callout_mutex_owned, + }, + [CALLOUT_LC_RW] = { + .lock = callout_rw_wlock, + .unlock = callout_rw_wunlock, + .owned = callout_rw_owned, + }, + [CALLOUT_LC_RM] = { + .lock = callout_rm_wlock, + .unlock = callout_rm_wunlock, + .owned = callout_rm_owned, + }, +}; + +static void +callout_lock_client(int c_flags, struct lock_object *c_lock) +{ + callout_mutex_ops[CALLOUT_GET_LC(c_flags)].lock(c_lock); +} + +static void +callout_unlock_client(int c_flags, struct lock_object *c_lock) +{ + callout_mutex_ops[CALLOUT_GET_LC(c_flags)].unlock(c_lock); +} + +#ifdef SMP +static int +callout_lock_owned_client(int c_flags, struct lock_object *c_lock) +{ + return (callout_mutex_ops[CALLOUT_GET_LC(c_flags)].owned(c_lock)); +} +#endif + /* - * The callout cpu exec entities represent informations necessary for - * describing the state of callouts currently running on the CPU and the ones - * necessary for migrating callouts to the new callout cpu. In particular, - * the first entry of the array cc_exec_entity holds informations for callout - * running in SWI thread context, while the second one holds informations - * for callout running directly from hardware interrupt context. - * The cached informations are very important for deferring migration when - * the migrating callout is already running. + * The callout CPU exec structure represent information necessary for + * describing the state of callouts currently running on the CPU and + * for handling deferred callout restarts. + * + * In particular, the first entry of the array cc_exec_entity holds + * information for callouts running from the SWI thread context, while + * the second one holds information for callouts running directly from + * the hardware interrupt context. */ struct cc_exec { - struct callout *cc_next; + /* + * The "cc_curr" points to the currently executing callout and + * is protected by the "cc_lock" spinlock. If no callback is + * currently executing it is equal to "NULL". + */ struct callout *cc_curr; -#ifdef SMP - void (*ce_migration_func)(void *); - void *ce_migration_arg; - int ce_migration_cpu; - sbintime_t ce_migration_time; - sbintime_t ce_migration_prec; -#endif - bool cc_cancel; - bool cc_waiting; + /* + * The "cc_restart_args" structure holds the argument for a + * deferred callback restart and is protected by the "cc_lock" + * spinlock. The structure is only valid if "cc_restart" is + * "true". If "cc_restart" is "false" the information in the + * "cc_restart_args" structure shall be ignored. + */ + struct callout_args cc_restart_args; + bool cc_restart; + /* + * The "cc_cancel" variable allows the currently pending + * callback to be atomically cancelled. This field is write + * protected by the "cc_lock" spinlock. + */ + bool cc_cancel; + /* + * The "cc_drain_fn" points to a function which shall be + * called with the argument stored in "cc_drain_arg" when an + * asynchronous drain is performed. This field is write + * protected by the "cc_lock" spinlock. + */ + callout_func_t *cc_drain_fn; + void *cc_drain_arg; }; /* - * There is one struct callout_cpu per cpu, holding all relevant + * There is one "struct callout_cpu" per CPU, holding all relevant * state for the callout processing thread on the individual CPU. */ struct callout_cpu { struct mtx_padalign cc_lock; struct cc_exec cc_exec_entity[2]; + struct callout *cc_exec_next_dir; struct callout *cc_callout; struct callout_list *cc_callwheel; struct callout_tailq cc_expireq; @@ -166,27 +347,7 @@ char cc_ktr_event_name[20]; }; -#define cc_exec_curr cc_exec_entity[0].cc_curr -#define cc_exec_next cc_exec_entity[0].cc_next -#define cc_exec_cancel cc_exec_entity[0].cc_cancel -#define cc_exec_waiting cc_exec_entity[0].cc_waiting -#define cc_exec_curr_dir cc_exec_entity[1].cc_curr -#define cc_exec_next_dir cc_exec_entity[1].cc_next -#define cc_exec_cancel_dir cc_exec_entity[1].cc_cancel -#define cc_exec_waiting_dir cc_exec_entity[1].cc_waiting - #ifdef SMP -#define cc_migration_func cc_exec_entity[0].ce_migration_func -#define cc_migration_arg cc_exec_entity[0].ce_migration_arg -#define cc_migration_cpu cc_exec_entity[0].ce_migration_cpu -#define cc_migration_time cc_exec_entity[0].ce_migration_time -#define cc_migration_prec cc_exec_entity[0].ce_migration_prec -#define cc_migration_func_dir cc_exec_entity[1].ce_migration_func -#define cc_migration_arg_dir cc_exec_entity[1].ce_migration_arg -#define cc_migration_cpu_dir cc_exec_entity[1].ce_migration_cpu -#define cc_migration_time_dir cc_exec_entity[1].ce_migration_time -#define cc_migration_prec_dir cc_exec_entity[1].ce_migration_prec - struct callout_cpu cc_cpu[MAXCPU]; #define CPUBLOCK MAXCPU #define CC_CPU(cpu) (&cc_cpu[(cpu)]) @@ -211,62 +372,11 @@ static MALLOC_DEFINE(M_CALLOUT, "callout", "Callout datastructures"); -/** - * Locked by cc_lock: - * cc_curr - If a callout is in progress, it is cc_curr. - * If cc_curr is non-NULL, threads waiting in - * callout_drain() will be woken up as soon as the - * relevant callout completes. - * cc_cancel - Changing to 1 with both callout_lock and cc_lock held - * guarantees that the current callout will not run. - * The softclock() function sets this to 0 before it - * drops callout_lock to acquire c_lock, and it calls - * the handler only if curr_cancelled is still 0 after - * cc_lock is successfully acquired. - * cc_waiting - If a thread is waiting in callout_drain(), then - * callout_wait is nonzero. Set only when - * cc_curr is non-NULL. - */ - /* - * Resets the execution entity tied to a specific callout cpu. + * Kernel low level callwheel initialization called from cpu0 during + * kernel startup: */ static void -cc_cce_cleanup(struct callout_cpu *cc, int direct) -{ - - cc->cc_exec_entity[direct].cc_curr = NULL; - cc->cc_exec_entity[direct].cc_next = NULL; - cc->cc_exec_entity[direct].cc_cancel = false; - cc->cc_exec_entity[direct].cc_waiting = false; -#ifdef SMP - cc->cc_exec_entity[direct].ce_migration_cpu = CPUBLOCK; - cc->cc_exec_entity[direct].ce_migration_time = 0; - cc->cc_exec_entity[direct].ce_migration_prec = 0; - cc->cc_exec_entity[direct].ce_migration_func = NULL; - cc->cc_exec_entity[direct].ce_migration_arg = NULL; -#endif -} - -/* - * Checks if migration is requested by a specific callout cpu. - */ -static int -cc_cce_migrating(struct callout_cpu *cc, int direct) -{ - -#ifdef SMP - return (cc->cc_exec_entity[direct].ce_migration_cpu != CPUBLOCK); -#else - return (0); -#endif -} - -/* - * Kernel low level callwheel initialization - * called on cpu0 during kernel startup. - */ -static void callout_callwheel_init(void *dummy) { struct callout_cpu *cc; @@ -324,8 +434,6 @@ LIST_INIT(&cc->cc_callwheel[i]); TAILQ_INIT(&cc->cc_expireq); cc->cc_firstevent = SBT_MAX; - for (i = 0; i < 2; i++) - cc_cce_cleanup(cc, i); snprintf(cc->cc_ktr_event_name, sizeof(cc->cc_ktr_event_name), "callwheel cpu %d", cpu); if (cc->cc_callout == NULL) /* Only cpu0 handles timeout(9) */ @@ -333,42 +441,12 @@ for (i = 0; i < ncallout; i++) { c = &cc->cc_callout[i]; callout_init(c, 0); - c->c_flags = CALLOUT_LOCAL_ALLOC; + c->c_flags |= CALLOUT_LOCAL_ALLOC; SLIST_INSERT_HEAD(&cc->cc_callfree, c, c_links.sle); } } -#ifdef SMP /* - * Switches the cpu tied to a specific callout. - * The function expects a locked incoming callout cpu and returns with - * locked outcoming callout cpu. - */ -static struct callout_cpu * -callout_cpu_switch(struct callout *c, struct callout_cpu *cc, int new_cpu) -{ - struct callout_cpu *new_cc; - - MPASS(c != NULL && cc != NULL); - CC_LOCK_ASSERT(cc); - - /* - * Avoid interrupts and preemption firing after the callout cpu - * is blocked in order to avoid deadlocks as the new thread - * may be willing to acquire the callout cpu lock. - */ - c->c_cpu = CPUBLOCK; - spinlock_enter(); - CC_UNLOCK(cc); - new_cc = CC_CPU(new_cpu); - CC_LOCK(new_cc); - spinlock_exit(); - c->c_cpu = new_cpu; - return (new_cc); -} -#endif - -/* * Start standard softclock thread. */ static void @@ -444,9 +522,8 @@ #ifdef CALLOUT_PROFILING int depth_dir = 0, mpcalls_dir = 0, lockcalls_dir = 0; #endif - cc = CC_SELF(); - mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); + CC_LOCK(cc); /* Compute the buckets of the last scan and present times. */ firstb = callout_hash(cc->cc_lastscan); @@ -549,7 +626,7 @@ avg_mpcalls_dir += (mpcalls_dir * 1000 - avg_mpcalls_dir) >> 8; avg_lockcalls_dir += (lockcalls_dir * 1000 - avg_lockcalls_dir) >> 8; #endif - mtx_unlock_spin_flags(&cc->cc_lock, MTX_QUIET); + CC_UNLOCK(cc); /* * swi_sched acquires the thread lock, so we don't want to call it * with cc_lock held; incorrect locking order. @@ -562,49 +639,55 @@ callout_lock(struct callout *c) { struct callout_cpu *cc; - int cpu; - - for (;;) { - cpu = c->c_cpu; -#ifdef SMP - if (cpu == CPUBLOCK) { - while (c->c_cpu == CPUBLOCK) - cpu_spinwait(); - continue; - } -#endif - cc = CC_CPU(cpu); - CC_LOCK(cc); - if (cpu == c->c_cpu) - break; - CC_UNLOCK(cc); - } + cc = CC_CPU(c->c_cpu); + CC_LOCK(cc); return (cc); } -static void -callout_cc_add(struct callout *c, struct callout_cpu *cc, - sbintime_t sbt, sbintime_t precision, void (*func)(void *), - void *arg, int cpu, int flags) +static struct callout_cpu * +callout_cc_add_locked(struct callout *c, struct callout_cpu *cc, + struct callout_args *coa, bool can_swap_cpu) { +#ifndef NO_EVENTTIMERS + sbintime_t sbt; +#endif int bucket; CC_LOCK_ASSERT(cc); - if (sbt < cc->cc_lastscan) - sbt = cc->cc_lastscan; - c->c_arg = arg; - c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); - if (flags & C_DIRECT_EXEC) - c->c_flags |= CALLOUT_DIRECT; - c->c_flags &= ~CALLOUT_PROCESSED; - c->c_func = func; - c->c_time = sbt; - c->c_precision = precision; + + /* update flags before swapping locks, if any */ + c->c_flags &= ~(CALLOUT_PROCESSED | CALLOUT_DIRECT | CALLOUT_DEFRESTART); + if (coa->flags & C_DIRECT_EXEC) + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING | CALLOUT_DIRECT); + else + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); + +#ifdef SMP + /* + * Check if we are changing the CPU on which the callback + * should be executed and if we have a lock protecting us: + */ + if (can_swap_cpu != false && coa->cpu != c->c_cpu && + callout_lock_owned_client(c->c_flags, c->c_lock) != 0) { + CC_UNLOCK(cc); + c->c_cpu = coa->cpu; + cc = callout_lock(c); + } +#endif + if (coa->time < cc->cc_lastscan) + coa->time = cc->cc_lastscan; + c->c_arg = coa->arg; + c->c_func = coa->func; + c->c_time = coa->time; + c->c_precision = coa->precision; + bucket = callout_get_bucket(c->c_time); CTR3(KTR_CALLOUT, "precision set for %p: %d.%08x", c, (int)(c->c_precision >> 32), (u_int)(c->c_precision & 0xffffffff)); LIST_INSERT_HEAD(&cc->cc_callwheel[bucket], c, c_links.le); + + /* Ensure we are first to be scanned, if called via a callback */ if (cc->cc_bucket == bucket) cc->cc_exec_next_dir = c; #ifndef NO_EVENTTIMERS @@ -617,9 +700,10 @@ sbt = c->c_time + c->c_precision; if (sbt < cc->cc_firstevent) { cc->cc_firstevent = sbt; - cpu_new_callout(cpu, sbt, c->c_time); + cpu_new_callout(coa->cpu, sbt, c->c_time); } #endif + return (cc); } static void @@ -626,8 +710,6 @@ callout_cc_del(struct callout *c, struct callout_cpu *cc) { - if ((c->c_flags & CALLOUT_LOCAL_ALLOC) == 0) - return; c->c_func = NULL; SLIST_INSERT_HEAD(&cc->cc_callfree, c, c_links.sle); } @@ -639,20 +721,10 @@ #endif int direct) { - struct rm_priotracker tracker; - void (*c_func)(void *); + callout_func_t *c_func; void *c_arg; - struct lock_class *class; struct lock_object *c_lock; - uintptr_t lock_status; int c_flags; -#ifdef SMP - struct callout_cpu *new_cc; - void (*new_func)(void *); - void *new_arg; - int flags, new_cpu; - sbintime_t new_prec, new_time; -#endif #if defined(DIAGNOSTIC) || defined(CALLOUT_PROFILING) sbintime_t sbt1, sbt2; struct timespec ts2; @@ -663,37 +735,43 @@ KASSERT((c->c_flags & (CALLOUT_PENDING | CALLOUT_ACTIVE)) == (CALLOUT_PENDING | CALLOUT_ACTIVE), ("softclock_call_cc: pend|act %p %x", c, c->c_flags)); - class = (c->c_lock != NULL) ? LOCK_CLASS(c->c_lock) : NULL; - lock_status = 0; - if (c->c_flags & CALLOUT_SHAREDLOCK) { - if (class == &lock_class_rm) - lock_status = (uintptr_t)&tracker; - else - lock_status = 1; - } c_lock = c->c_lock; c_func = c->c_func; c_arg = c->c_arg; c_flags = c->c_flags; - if (c->c_flags & CALLOUT_LOCAL_ALLOC) - c->c_flags = CALLOUT_LOCAL_ALLOC; - else - c->c_flags &= ~CALLOUT_PENDING; + + /* remove pending bit */ + c->c_flags &= ~CALLOUT_PENDING; + + /* reset our local state */ cc->cc_exec_entity[direct].cc_curr = c; cc->cc_exec_entity[direct].cc_cancel = false; - CC_UNLOCK(cc); + cc->cc_exec_entity[direct].cc_restart = false; + cc->cc_exec_entity[direct].cc_drain_fn = NULL; + cc->cc_exec_entity[direct].cc_drain_arg = NULL; + if (c_lock != NULL) { - class->lc_lock(c_lock, lock_status); + CC_UNLOCK(cc); + + /* unlocked region for switching locks */ + + callout_lock_client(c_flags, c_lock); + /* - * The callout may have been cancelled - * while we switched locks. + * Check if the callout may have been cancelled while + * we were switching locks. Even though the callout is + * specifying a lock, it might not be certain this + * lock is locked when starting and stopping callouts. */ + CC_LOCK(cc); if (cc->cc_exec_entity[direct].cc_cancel) { - class->lc_unlock(c_lock); - goto skip; + callout_unlock_client(c_flags, c_lock); + goto skip_cc_locked; } - /* The callout cannot be stopped now. */ + /* The callout cannot be stopped now! */ cc->cc_exec_entity[direct].cc_cancel = true; + CC_UNLOCK(cc); + if (c_lock == &Giant.lock_object) { #ifdef CALLOUT_PROFILING (*gcalls)++; @@ -708,6 +786,8 @@ c, c_func, c_arg); } } else { + CC_UNLOCK(cc); + /* unlocked region */ #ifdef CALLOUT_PROFILING (*mpcalls)++; #endif @@ -740,85 +820,40 @@ #endif KTR_STATE0(KTR_SCHED, "callout", cc->cc_ktr_event_name, "idle"); CTR1(KTR_CALLOUT, "callout %p finished", c); + + /* + * At this point the callback structure might have been freed, + * so we need to check the previously copied value of + * "c->c_flags": + */ if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0) - class->lc_unlock(c_lock); -skip: + callout_unlock_client(c_flags, c_lock); + CC_LOCK(cc); + +skip_cc_locked: KASSERT(cc->cc_exec_entity[direct].cc_curr == c, ("mishandled cc_curr")); cc->cc_exec_entity[direct].cc_curr = NULL; - if (cc->cc_exec_entity[direct].cc_waiting) { + + /* Check if there is anything which needs draining */ + if (cc->cc_exec_entity[direct].cc_drain_fn != NULL) { /* - * There is someone waiting for the - * callout to complete. - * If the callout was scheduled for - * migration just cancel it. + * Unlock the CPU callout last, so that any use of + * structures belonging to the callout are complete: */ - if (cc_cce_migrating(cc, direct)) { - cc_cce_cleanup(cc, direct); - - /* - * It should be assert here that the callout is not - * destroyed but that is not easy. - */ - c->c_flags &= ~CALLOUT_DFRMIGRATION; - } - cc->cc_exec_entity[direct].cc_waiting = false; CC_UNLOCK(cc); - wakeup(&cc->cc_exec_entity[direct].cc_waiting); + /* call drain function unlocked */ + cc->cc_exec_entity[direct].cc_drain_fn( + cc->cc_exec_entity[direct].cc_drain_arg); CC_LOCK(cc); - } else if (cc_cce_migrating(cc, direct)) { - KASSERT((c_flags & CALLOUT_LOCAL_ALLOC) == 0, - ("Migrating legacy callout %p", c)); -#ifdef SMP - /* - * If the callout was scheduled for - * migration just perform it now. - */ - new_cpu = cc->cc_exec_entity[direct].ce_migration_cpu; - new_time = cc->cc_exec_entity[direct].ce_migration_time; - new_prec = cc->cc_exec_entity[direct].ce_migration_prec; - new_func = cc->cc_exec_entity[direct].ce_migration_func; - new_arg = cc->cc_exec_entity[direct].ce_migration_arg; - cc_cce_cleanup(cc, direct); - - /* - * It should be assert here that the callout is not destroyed - * but that is not easy. - * - * As first thing, handle deferred callout stops. - */ - if ((c->c_flags & CALLOUT_DFRMIGRATION) == 0) { - CTR3(KTR_CALLOUT, - "deferred cancelled %p func %p arg %p", - c, new_func, new_arg); - callout_cc_del(c, cc); - return; - } - c->c_flags &= ~CALLOUT_DFRMIGRATION; - - new_cc = callout_cpu_switch(c, cc, new_cpu); - flags = (direct) ? C_DIRECT_EXEC : 0; - callout_cc_add(c, new_cc, new_time, new_prec, new_func, - new_arg, new_cpu, flags); - CC_UNLOCK(new_cc); - CC_LOCK(cc); -#else - panic("migration should not happen"); -#endif + } else if (c_flags & CALLOUT_LOCAL_ALLOC) { + /* return callout back to freelist */ + callout_cc_del(c, cc); + } else if (cc->cc_exec_entity[direct].cc_restart) { + /* [re-]schedule callout, if any */ + cc = callout_cc_add_locked(c, cc, + &cc->cc_exec_entity[direct].cc_restart_args, false); } - /* - * If the current callout is locally allocated (from - * timeout(9)) then put it on the freelist. - * - * Note: we need to check the cached copy of c_flags because - * if it was not local, then it's not safe to deref the - * callout pointer. - */ - KASSERT((c_flags & CALLOUT_LOCAL_ALLOC) == 0 || - c->c_flags == CALLOUT_LOCAL_ALLOC, - ("corrupted callout")); - if (c_flags & CALLOUT_LOCAL_ALLOC) - callout_cc_del(c, cc); } /* @@ -899,10 +934,11 @@ /* XXX Attempt to malloc first */ panic("timeout table full"); SLIST_REMOVE_HEAD(&cc->cc_callfree, c_links.sle); - callout_reset(new, to_ticks, ftn, arg); handle.callout = new; CC_UNLOCK(cc); + callout_reset(new, to_ticks, ftn, arg); + return (handle); } @@ -910,6 +946,7 @@ untimeout(timeout_t *ftn, void *arg, struct callout_handle handle) { struct callout_cpu *cc; + bool match; /* * Check for a handle that was initialized @@ -920,9 +957,11 @@ return; cc = callout_lock(handle.callout); - if (handle.callout->c_func == ftn && handle.callout->c_arg == arg) + match = (handle.callout->c_func == ftn && handle.callout->c_arg == arg); + CC_UNLOCK(cc); + + if (match) callout_stop(handle.callout); - CC_UNLOCK(cc); } void @@ -931,6 +970,119 @@ handle->callout = NULL; } +static int +callout_restart_async(struct callout *c, struct callout_args *coa, + callout_func_t *drain_fn, void *drain_arg) +{ + struct callout_cpu *cc; + int cancelled; + int direct; + + cc = callout_lock(c); + + /* Figure out if the callout is direct or not */ + direct = ((c->c_flags & CALLOUT_DIRECT) != 0); + + /* + * Check if the callback is currently scheduled for + * completion: + */ + if (cc->cc_exec_entity[direct].cc_curr == c) { + /* + * Try to prevent the callback from running by setting + * the "cc_cancel" variable to "true". Also check if + * the callout was previously subject to a deferred + * callout restart: + */ + if (cc->cc_exec_entity[direct].cc_cancel == false || + (c->c_flags & CALLOUT_DEFRESTART) != 0) { + cc->cc_exec_entity[direct].cc_cancel = true; + cancelled = 1; + } else { + cancelled = 0; + } + + /* + * Prevent callback restart if "callout_drain_xxx()" + * is being called or we are stopping the callout or + * the callback was preallocated by us: + */ + if (cc->cc_exec_entity[direct].cc_drain_fn != NULL || + coa == NULL || (c->c_flags & CALLOUT_LOCAL_ALLOC) != 0) { + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "cancelled and draining" : "draining", + c, c->c_func, c->c_arg); + + /* clear old flags, if any */ + c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART | CALLOUT_PROCESSED); + + /* clear restart flag, if any */ + cc->cc_exec_entity[direct].cc_restart = false; + + /* set drain function, if any */ + if (drain_fn != NULL) { + cc->cc_exec_entity[direct].cc_drain_fn = drain_fn; + cc->cc_exec_entity[direct].cc_drain_arg = drain_arg; + cancelled |= 2; /* XXX define the value */ + } + } else { + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "cancelled and restarting" : "restarting", + c, c->c_func, c->c_arg); + + /* get us back into the game */ + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART); + c->c_flags &= ~CALLOUT_PROCESSED; + + /* enable deferred restart */ + cc->cc_exec_entity[direct].cc_restart = true; + + /* store arguments for the deferred restart, if any */ + cc->cc_exec_entity[direct].cc_restart_args = *coa; + } + } else { + /* stop callout */ + if (c->c_flags & CALLOUT_PENDING) { + /* + * The callback has not yet been executed, and + * we simply just need to unlink it: + */ + if ((c->c_flags & CALLOUT_PROCESSED) == 0) { + if (cc->cc_exec_next_dir == c) + cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); + LIST_REMOVE(c, c_links.le); + } else { + TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); + } + cancelled = 1; + } else { + cancelled = 0; + } + + /* [re-]schedule callout, if any */ + if (coa != NULL) { + cc = callout_cc_add_locked(c, cc, coa, true); + } else { + /* clear old flags, if any */ + c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART | CALLOUT_PROCESSED); + + /* return callback to pre-allocated list, if any */ + if ((c->c_flags & CALLOUT_LOCAL_ALLOC) && cancelled != 0) { + callout_cc_del(c, cc); + } + } + + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "rescheduled" : "scheduled", + c, c->c_func, c->c_arg); + } + CC_UNLOCK(cc); + return (cancelled); +} + /* * New interface; clients allocate their own callout structures. * @@ -949,25 +1101,32 @@ */ int callout_reset_sbt_on(struct callout *c, sbintime_t sbt, sbintime_t precision, - void (*ftn)(void *), void *arg, int cpu, int flags) + callout_func_t *ftn, void *arg, int cpu, int flags) { - sbintime_t to_sbt, pr; - struct callout_cpu *cc; - int cancelled, direct; + struct callout_args coa; - cancelled = 0; - if (flags & C_ABSOLUTE) { - to_sbt = sbt; + /* store arguments for callout add function */ + coa.func = ftn; + coa.arg = arg; + coa.precision = precision; + coa.flags = flags; + coa.cpu = cpu; + + /* compute the rest of the arguments needed */ + if (coa.flags & C_ABSOLUTE) { + coa.time = sbt; } else { - if ((flags & C_HARDCLOCK) && (sbt < tick_sbt)) + sbintime_t pr; + + if ((coa.flags & C_HARDCLOCK) && (sbt < tick_sbt)) sbt = tick_sbt; - if ((flags & C_HARDCLOCK) || + if ((coa.flags & C_HARDCLOCK) || #ifdef NO_EVENTTIMERS sbt >= sbt_timethreshold) { - to_sbt = getsbinuptime(); + coa.time = getsbinuptime(); /* Add safety belt for the case of hz > 1000. */ - to_sbt += tc_tick_sbt - tick_sbt; + coa.time += tc_tick_sbt - tick_sbt; #else sbt >= sbt_tickthreshold) { /* @@ -977,101 +1136,29 @@ * active ones. */ #ifdef __LP64__ - to_sbt = DPCPU_GET(hardclocktime); + coa.time = DPCPU_GET(hardclocktime); #else spinlock_enter(); - to_sbt = DPCPU_GET(hardclocktime); + coa.time = DPCPU_GET(hardclocktime); spinlock_exit(); #endif #endif - if ((flags & C_HARDCLOCK) == 0) - to_sbt += tick_sbt; + if ((coa.flags & C_HARDCLOCK) == 0) + coa.time += tick_sbt; } else - to_sbt = sbinuptime(); - if (SBT_MAX - to_sbt < sbt) - to_sbt = SBT_MAX; + coa.time = sbinuptime(); + if (SBT_MAX - coa.time < sbt) + coa.time = SBT_MAX; else - to_sbt += sbt; - pr = ((C_PRELGET(flags) < 0) ? sbt >> tc_precexp : - sbt >> C_PRELGET(flags)); - if (pr > precision) - precision = pr; + coa.time += sbt; + pr = ((C_PRELGET(coa.flags) < 0) ? sbt >> tc_precexp : + sbt >> C_PRELGET(coa.flags)); + if (pr > coa.precision) + coa.precision = pr; } - /* - * Don't allow migration of pre-allocated callouts lest they - * become unbalanced. - */ - if (c->c_flags & CALLOUT_LOCAL_ALLOC) - cpu = c->c_cpu; - direct = (c->c_flags & CALLOUT_DIRECT) != 0; - KASSERT(!direct || c->c_lock == NULL, - ("%s: direct callout %p has lock", __func__, c)); - cc = callout_lock(c); - if (cc->cc_exec_entity[direct].cc_curr == c) { - /* - * We're being asked to reschedule a callout which is - * currently in progress. If there is a lock then we - * can cancel the callout if it has not really started. - */ - if (c->c_lock != NULL && !cc->cc_exec_entity[direct].cc_cancel) - cancelled = cc->cc_exec_entity[direct].cc_cancel = true; - if (cc->cc_exec_entity[direct].cc_waiting) { - /* - * Someone has called callout_drain to kill this - * callout. Don't reschedule. - */ - CTR4(KTR_CALLOUT, "%s %p func %p arg %p", - cancelled ? "cancelled" : "failed to cancel", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - return (cancelled); - } - } - if (c->c_flags & CALLOUT_PENDING) { - if ((c->c_flags & CALLOUT_PROCESSED) == 0) { - if (cc->cc_exec_next_dir == c) - cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); - LIST_REMOVE(c, c_links.le); - } else - TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); - cancelled = 1; - c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING); - } -#ifdef SMP - /* - * If the callout must migrate try to perform it immediately. - * If the callout is currently running, just defer the migration - * to a more appropriate moment. - */ - if (c->c_cpu != cpu) { - if (cc->cc_exec_entity[direct].cc_curr == c) { - cc->cc_exec_entity[direct].ce_migration_cpu = cpu; - cc->cc_exec_entity[direct].ce_migration_time - = to_sbt; - cc->cc_exec_entity[direct].ce_migration_prec - = precision; - cc->cc_exec_entity[direct].ce_migration_func = ftn; - cc->cc_exec_entity[direct].ce_migration_arg = arg; - c->c_flags |= CALLOUT_DFRMIGRATION; - CTR6(KTR_CALLOUT, - "migration of %p func %p arg %p in %d.%08x to %u deferred", - c, c->c_func, c->c_arg, (int)(to_sbt >> 32), - (u_int)(to_sbt & 0xffffffff), cpu); - CC_UNLOCK(cc); - return (cancelled); - } - cc = callout_cpu_switch(c, cc, cpu); - } -#endif - - callout_cc_add(c, cc, to_sbt, precision, ftn, arg, cpu, flags); - CTR6(KTR_CALLOUT, "%sscheduled %p func %p arg %p in %d.%08x", - cancelled ? "re" : "", c, c->c_func, c->c_arg, (int)(to_sbt >> 32), - (u_int)(to_sbt & 0xffffffff)); - CC_UNLOCK(cc); - - return (cancelled); + /* get callback started, if any */ + return (callout_restart_async(c, &coa, NULL, NULL)); } /* @@ -1090,189 +1177,79 @@ } int -_callout_stop_safe(struct callout *c, int safe) +callout_stop(struct callout *c) { - struct callout_cpu *cc, *old_cc; - struct lock_class *class; - int direct, sq_locked, use_lock; + /* get callback stopped, if any */ + return (callout_restart_async(c, NULL, NULL, NULL)); +} - /* - * Some old subsystems don't hold Giant while running a callout_stop(), - * so just discard this check for the moment. - */ - if (!safe && c->c_lock != NULL) { - if (c->c_lock == &Giant.lock_object) - use_lock = mtx_owned(&Giant); - else { - use_lock = 1; - class = LOCK_CLASS(c->c_lock); - class->lc_assert(c->c_lock, LA_XLOCKED); - } - } else - use_lock = 0; - direct = (c->c_flags & CALLOUT_DIRECT) != 0; - sq_locked = 0; - old_cc = NULL; -again: - cc = callout_lock(c); +static void +callout_drain_function(void *arg) +{ + wakeup(arg); +} - /* - * If the callout was migrating while the callout cpu lock was - * dropped, just drop the sleepqueue lock and check the states - * again. - */ - if (sq_locked != 0 && cc != old_cc) { -#ifdef SMP - CC_UNLOCK(cc); - sleepq_release(&old_cc->cc_exec_entity[direct].cc_waiting); - sq_locked = 0; - old_cc = NULL; - goto again; -#else - panic("migration should not happen"); -#endif - } +int +callout_drain_async(struct callout *c, callout_func_t *fn, void *arg) +{ + /* get callback stopped, if any */ + return (callout_restart_async(c, NULL, fn, arg) & 2); +} - /* - * If the callout isn't pending, it's not on the queue, so - * don't attempt to remove it from the queue. We can try to - * stop it by other means however. - */ - if (!(c->c_flags & CALLOUT_PENDING)) { - c->c_flags &= ~CALLOUT_ACTIVE; +int +callout_drain(struct callout *c) +{ + int cancelled; + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, + "Draining callout"); + + callout_lock_client(c->c_flags, c->c_lock); + + /* at this point the "c->c_cpu" field is not changing */ + + cancelled = callout_drain_async(c, &callout_drain_function, c); + + if (cancelled != 0) { + struct callout_cpu *cc; + int direct; + + CTR3(KTR_CALLOUT, "need to drain %p func %p arg %p", + c, c->c_func, c->c_arg); + + cc = callout_lock(c); + direct = ((c->c_flags & CALLOUT_DIRECT) != 0); + /* - * If it wasn't on the queue and it isn't the current - * callout, then we can't stop it, so just bail. + * We've gotten our callout CPU lock, it is safe to + * drop the initial lock: */ - if (cc->cc_exec_entity[direct].cc_curr != c) { - CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - if (sq_locked) - sleepq_release( - &cc->cc_exec_entity[direct].cc_waiting); - return (0); - } + callout_unlock_client(c->c_flags, c->c_lock); - if (safe) { - /* - * The current callout is running (or just - * about to run) and blocking is allowed, so - * just wait for the current invocation to - * finish. - */ - while (cc->cc_exec_entity[direct].cc_curr == c) { - /* - * Use direct calls to sleepqueue interface - * instead of cv/msleep in order to avoid - * a LOR between cc_lock and sleepqueue - * chain spinlocks. This piece of code - * emulates a msleep_spin() call actually. - * - * If we already have the sleepqueue chain - * locked, then we can safely block. If we - * don't already have it locked, however, - * we have to drop the cc_lock to lock - * it. This opens several races, so we - * restart at the beginning once we have - * both locks. If nothing has changed, then - * we will end up back here with sq_locked - * set. - */ - if (!sq_locked) { - CC_UNLOCK(cc); - sleepq_lock( - &cc->cc_exec_entity[direct].cc_waiting); - sq_locked = 1; - old_cc = cc; - goto again; - } + /* Wait for drain to complete */ - /* - * Migration could be cancelled here, but - * as long as it is still not sure when it - * will be packed up, just let softclock() - * take care of it. - */ - cc->cc_exec_entity[direct].cc_waiting = true; - DROP_GIANT(); - CC_UNLOCK(cc); - sleepq_add( - &cc->cc_exec_entity[direct].cc_waiting, - &cc->cc_lock.lock_object, "codrain", - SLEEPQ_SLEEP, 0); - sleepq_wait( - &cc->cc_exec_entity[direct].cc_waiting, - 0); - sq_locked = 0; - old_cc = NULL; + while (cc->cc_exec_entity[direct].cc_curr == c) + msleep_spin(c, (struct mtx *)&cc->cc_lock, "codrain", 0); - /* Reacquire locks previously released. */ - PICKUP_GIANT(); - CC_LOCK(cc); - } - } else if (use_lock && - !cc->cc_exec_entity[direct].cc_cancel) { - /* - * The current callout is waiting for its - * lock which we hold. Cancel the callout - * and return. After our caller drops the - * lock, the callout will be skipped in - * softclock(). - */ - cc->cc_exec_entity[direct].cc_cancel = true; - CTR3(KTR_CALLOUT, "cancelled %p func %p arg %p", - c, c->c_func, c->c_arg); - KASSERT(!cc_cce_migrating(cc, direct), - ("callout wrongly scheduled for migration")); - CC_UNLOCK(cc); - KASSERT(!sq_locked, ("sleepqueue chain locked")); - return (1); - } else if ((c->c_flags & CALLOUT_DFRMIGRATION) != 0) { - c->c_flags &= ~CALLOUT_DFRMIGRATION; - CTR3(KTR_CALLOUT, "postponing stop %p func %p arg %p", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - return (1); - } - CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p", - c, c->c_func, c->c_arg); CC_UNLOCK(cc); - KASSERT(!sq_locked, ("sleepqueue chain still locked")); - return (0); + } else { + callout_unlock_client(c->c_flags, c->c_lock); } - if (sq_locked) - sleepq_release(&cc->cc_exec_entity[direct].cc_waiting); - c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING); - CTR3(KTR_CALLOUT, "cancelled %p func %p arg %p", c, c->c_func, c->c_arg); - if ((c->c_flags & CALLOUT_PROCESSED) == 0) { - if (cc->cc_exec_next_dir == c) - cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); - LIST_REMOVE(c, c_links.le); - } else - TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); - callout_cc_del(c, cc); - CC_UNLOCK(cc); - return (1); + return (cancelled & 1); } void callout_init(struct callout *c, int mpsafe) { - bzero(c, sizeof *c); if (mpsafe) { - c->c_lock = NULL; - c->c_flags = CALLOUT_RETURNUNLOCKED; + _callout_init_lock(c, NULL, CALLOUT_RETURNUNLOCKED); } else { - c->c_lock = &Giant.lock_object; - c->c_flags = 0; + _callout_init_lock(c, &Giant.lock_object, 0); } - c->c_cpu = timeout_cpu; } void @@ -1279,15 +1256,26 @@ _callout_init_lock(struct callout *c, struct lock_object *lock, int flags) { bzero(c, sizeof *c); + KASSERT((flags & ~CALLOUT_RETURNUNLOCKED) == 0, + ("callout_init_lock: bad flags 0x%08x", flags)); + flags &= CALLOUT_RETURNUNLOCKED; + if (lock != NULL) { + struct lock_class *class = LOCK_CLASS(lock); + if (class == &lock_class_mtx_sleep) + flags |= CALLOUT_SET_LC(CALLOUT_LC_MUTEX); + else if (class == &lock_class_mtx_spin) + flags |= CALLOUT_SET_LC(CALLOUT_LC_SPIN); + else if (class == &lock_class_rm) + flags |= CALLOUT_SET_LC(CALLOUT_LC_RM); + else if (class == &lock_class_rw) + flags |= CALLOUT_SET_LC(CALLOUT_LC_RW); + else + panic("callout_init_lock: Unsupported lock class '%s'\n", class->lc_name); + } else { + flags |= CALLOUT_SET_LC(CALLOUT_LC_UNUSED_0); + } c->c_lock = lock; - KASSERT((flags & ~(CALLOUT_RETURNUNLOCKED | CALLOUT_SHAREDLOCK)) == 0, - ("callout_init_lock: bad flags %d", flags)); - KASSERT(lock != NULL || (flags & CALLOUT_RETURNUNLOCKED) == 0, - ("callout_init_lock: CALLOUT_RETURNUNLOCKED with no lock")); - KASSERT(lock == NULL || !(LOCK_CLASS(lock)->lc_flags & - (LC_SPINLOCK | LC_SLEEPABLE)), ("%s: invalid lock class", - __func__)); - c->c_flags = flags & (CALLOUT_RETURNUNLOCKED | CALLOUT_SHAREDLOCK); + c->c_flags = flags; c->c_cpu = timeout_cpu; } Index: sys/kern/subr_sleepqueue.c =================================================================== --- sys/kern/subr_sleepqueue.c (revision 276531) +++ sys/kern/subr_sleepqueue.c (working copy) @@ -152,7 +152,8 @@ */ static int sleepq_catch_signals(void *wchan, int pri); static int sleepq_check_signals(void); -static int sleepq_check_timeout(void); +static int sleepq_check_timeout(struct thread *); +static void sleepq_stop_timeout(struct thread *); #ifdef INVARIANTS static void sleepq_dtor(void *mem, int size, void *arg); #endif @@ -373,17 +374,14 @@ sleepq_set_timeout_sbt(void *wchan, sbintime_t sbt, sbintime_t pr, int flags) { - struct sleepqueue_chain *sc; struct thread *td; td = curthread; - sc = SC_LOOKUP(wchan); - mtx_assert(&sc->sc_lock, MA_OWNED); - MPASS(TD_ON_SLEEPQ(td)); - MPASS(td->td_sleepqueue == NULL); - MPASS(wchan != NULL); + + mtx_lock_spin(&td->td_slpmutex); callout_reset_sbt_on(&td->td_slpcallout, sbt, pr, sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); + mtx_unlock_spin(&td->td_slpmutex); } /* @@ -559,11 +557,8 @@ * Check to see if we timed out. */ static int -sleepq_check_timeout(void) +sleepq_check_timeout(struct thread *td) { - struct thread *td; - - td = curthread; THREAD_LOCK_ASSERT(td, MA_OWNED); /* @@ -573,28 +568,21 @@ td->td_flags &= ~TDF_TIMEOUT; return (EWOULDBLOCK); } - - /* - * If TDF_TIMOFAIL is set, the timeout ran after we had - * already been woken up. - */ - if (td->td_flags & TDF_TIMOFAIL) - td->td_flags &= ~TDF_TIMOFAIL; - - /* - * If callout_stop() fails, then the timeout is running on - * another CPU, so synchronize with it to avoid having it - * accidentally wake up a subsequent sleep. - */ - else if (callout_stop(&td->td_slpcallout) == 0) { - td->td_flags |= TDF_TIMEOUT; - TD_SET_SLEEPING(td); - mi_switch(SW_INVOL | SWT_SLEEPQTIMO, NULL); - } return (0); } /* + * Atomically stop the timeout by using a mutex. + */ +static void +sleepq_stop_timeout(struct thread *td) +{ + mtx_lock_spin(&td->td_slpmutex); + callout_stop(&td->td_slpcallout); + mtx_unlock_spin(&td->td_slpmutex); +} + +/* * Check to see if we were awoken by a signal. */ static int @@ -664,9 +652,11 @@ MPASS(!(td->td_flags & TDF_SINTR)); thread_lock(td); sleepq_switch(wchan, pri); - rval = sleepq_check_timeout(); + rval = sleepq_check_timeout(td); thread_unlock(td); + sleepq_stop_timeout(td); + return (rval); } @@ -677,12 +667,18 @@ int sleepq_timedwait_sig(void *wchan, int pri) { + struct thread *td; int rcatch, rvalt, rvals; + td = curthread; + rcatch = sleepq_catch_signals(wchan, pri); - rvalt = sleepq_check_timeout(); + rvalt = sleepq_check_timeout(td); rvals = sleepq_check_signals(); - thread_unlock(curthread); + thread_unlock(td); + + sleepq_stop_timeout(td); + if (rcatch) return (rcatch); if (rvals) @@ -889,64 +885,49 @@ static void sleepq_timeout(void *arg) { - struct sleepqueue_chain *sc; - struct sleepqueue *sq; - struct thread *td; - void *wchan; - int wakeup_swapper; + struct thread *td = arg; + int wakeup_swapper = 0; - td = arg; - wakeup_swapper = 0; CTR3(KTR_PROC, "sleepq_timeout: thread %p (pid %ld, %s)", (void *)td, (long)td->td_proc->p_pid, (void *)td->td_name); - /* - * First, see if the thread is asleep and get the wait channel if - * it is. - */ + /* Handle the three cases which can happen */ + thread_lock(td); - if (TD_IS_SLEEPING(td) && TD_ON_SLEEPQ(td)) { - wchan = td->td_wchan; - sc = SC_LOOKUP(wchan); - THREAD_LOCKPTR_ASSERT(td, &sc->sc_lock); - sq = sleepq_lookup(wchan); - MPASS(sq != NULL); - td->td_flags |= TDF_TIMEOUT; - wakeup_swapper = sleepq_resume_thread(sq, td, 0); - thread_unlock(td); - if (wakeup_swapper) - kick_proc0(); - return; - } + if (TD_ON_SLEEPQ(td)) { + if (TD_IS_SLEEPING(td)) { + struct sleepqueue_chain *sc; + struct sleepqueue *sq; + void *wchan; - /* - * If the thread is on the SLEEPQ but isn't sleeping yet, it - * can either be on another CPU in between sleepq_add() and - * one of the sleepq_*wait*() routines or it can be in - * sleepq_catch_signals(). - */ - if (TD_ON_SLEEPQ(td)) { - td->td_flags |= TDF_TIMEOUT; - thread_unlock(td); - return; + /* + * Case I - thread is asleep and needs to be + * awoken: + */ + wchan = td->td_wchan; + sc = SC_LOOKUP(wchan); + THREAD_LOCKPTR_ASSERT(td, &sc->sc_lock); + sq = sleepq_lookup(wchan); + MPASS(sq != NULL); + td->td_flags |= TDF_TIMEOUT; + wakeup_swapper = sleepq_resume_thread(sq, td, 0); + } else { + /* + * Case II - cancel going to sleep by setting + * the timeout flag because the target thread + * is not asleep yet. It can be on another CPU + * in between sleepq_add() and one of the + * sleepq_*wait*() routines or it can be in + * sleepq_catch_signals(). + */ + td->td_flags |= TDF_TIMEOUT; + } + } else { + /* + * Case III - thread is already woken up by a wakeup + * call and should not timeout. Nothing to do! + */ } - - /* - * Now check for the edge cases. First, if TDF_TIMEOUT is set, - * then the other thread has already yielded to us, so clear - * the flag and resume it. If TDF_TIMEOUT is not set, then the - * we know that the other thread is not on a sleep queue, but it - * hasn't resumed execution yet. In that case, set TDF_TIMOFAIL - * to let it know that the timeout has already run and doesn't - * need to be canceled. - */ - if (td->td_flags & TDF_TIMEOUT) { - MPASS(TD_IS_SLEEPING(td)); - td->td_flags &= ~TDF_TIMEOUT; - TD_CLR_SLEEPING(td); - wakeup_swapper = setrunnable(td); - } else - td->td_flags |= TDF_TIMOFAIL; thread_unlock(td); if (wakeup_swapper) kick_proc0(); Index: sys/sys/_callout.h =================================================================== --- sys/sys/_callout.h (revision 276531) +++ sys/sys/_callout.h (working copy) @@ -46,6 +46,17 @@ SLIST_HEAD(callout_slist, callout); TAILQ_HEAD(callout_tailq, callout); +typedef void callout_func_t(void *); + +struct callout_args { + sbintime_t time; /* absolute time for the event */ + sbintime_t precision; /* delta allowed wrt opt */ + void *arg; /* function argument */ + callout_func_t *func; /* function to call */ + int flags; /* flags passed to callout_reset() */ + int cpu; /* CPU we're scheduled on */ +}; + struct callout { union { LIST_ENTRY(callout) le; @@ -52,13 +63,13 @@ SLIST_ENTRY(callout) sle; TAILQ_ENTRY(callout) tqe; } c_links; - sbintime_t c_time; /* ticks to the event */ + sbintime_t c_time; /* absolute time for the event */ sbintime_t c_precision; /* delta allowed wrt opt */ void *c_arg; /* function argument */ - void (*c_func)(void *); /* function to call */ - struct lock_object *c_lock; /* lock to handle */ + callout_func_t *c_func; /* function to call */ + struct lock_object *c_lock; /* callback lock */ int c_flags; /* state of this entry */ - volatile int c_cpu; /* CPU we're scheduled on */ + int c_cpu; /* CPU we're scheduled on */ }; #endif Index: sys/sys/callout.h =================================================================== --- sys/sys/callout.h (revision 276531) +++ sys/sys/callout.h (working copy) @@ -45,10 +45,12 @@ #define CALLOUT_PENDING 0x0004 /* callout is waiting for timeout */ #define CALLOUT_MPSAFE 0x0008 /* callout handler is mp safe */ #define CALLOUT_RETURNUNLOCKED 0x0010 /* handler returns with mtx unlocked */ -#define CALLOUT_SHAREDLOCK 0x0020 /* callout lock held in shared mode */ -#define CALLOUT_DFRMIGRATION 0x0040 /* callout in deferred migration mode */ +#define CALLOUT_UNUSED_5 0x0020 /* --available-- */ +#define CALLOUT_DEFRESTART 0x0040 /* callout restart is deferred */ #define CALLOUT_PROCESSED 0x0080 /* callout in wheel or processing list? */ #define CALLOUT_DIRECT 0x0100 /* allow exec from hw int context */ +#define CALLOUT_SET_LC(x) (((x) & 7) << 16) /* set lock class */ +#define CALLOUT_GET_LC(x) (((x) >> 16) & 7) /* get lock class */ #define C_DIRECT_EXEC 0x0001 /* direct execution of callout */ #define C_PRELBITS 7 @@ -65,7 +67,8 @@ #ifdef _KERNEL #define callout_active(c) ((c)->c_flags & CALLOUT_ACTIVE) #define callout_deactivate(c) ((c)->c_flags &= ~CALLOUT_ACTIVE) -#define callout_drain(c) _callout_stop_safe(c, 1) +int callout_drain(struct callout *); +int callout_drain_async(struct callout *, callout_func_t *, void *); void callout_init(struct callout *, int); void _callout_init_lock(struct callout *, struct lock_object *, int); #define callout_init_mtx(c, mtx, flags) \ @@ -79,7 +82,7 @@ NULL, (flags)) #define callout_pending(c) ((c)->c_flags & CALLOUT_PENDING) int callout_reset_sbt_on(struct callout *, sbintime_t, sbintime_t, - void (*)(void *), void *, int, int); + callout_func_t *, void *, int, int); #define callout_reset_sbt(c, sbt, pr, fn, arg, flags) \ callout_reset_sbt_on((c), (sbt), (pr), (fn), (arg), (c)->c_cpu, (flags)) #define callout_reset_sbt_curcpu(c, sbt, pr, fn, arg, flags) \ @@ -103,8 +106,7 @@ int callout_schedule_on(struct callout *, int, int); #define callout_schedule_curcpu(c, on_tick) \ callout_schedule_on((c), (on_tick), PCPU_GET(cpuid)) -#define callout_stop(c) _callout_stop_safe(c, 0) -int _callout_stop_safe(struct callout *, int); +int callout_stop(struct callout *); void callout_process(sbintime_t now); #endif Index: sys/sys/proc.h =================================================================== --- sys/sys/proc.h (revision 276531) +++ sys/sys/proc.h (working copy) @@ -308,6 +308,7 @@ } td_uretoff; /* (k) Syscall aux returns. */ #define td_retval td_uretoff.tdu_retval struct callout td_slpcallout; /* (h) Callout for sleep. */ + struct mtx td_slpmutex; /* (h) Mutex for sleep callout */ struct trapframe *td_frame; /* (k) */ struct vm_object *td_kstack_obj;/* (a) Kstack object. */ vm_offset_t td_kstack; /* (a) Kernel VA of kstack. */ @@ -364,7 +365,7 @@ #define TDF_ALLPROCSUSP 0x00000200 /* suspended by SINGLE_ALLPROC */ #define TDF_BOUNDARY 0x00000400 /* Thread suspended at user boundary */ #define TDF_ASTPENDING 0x00000800 /* Thread has some asynchronous events. */ -#define TDF_TIMOFAIL 0x00001000 /* Timeout from sleep after we were awake. */ +#define TDF_UNUSED12 0x00001000 /* --available-- */ #define TDF_SBDRY 0x00002000 /* Stop only on usermode boundary. */ #define TDF_UPIBLOCKED 0x00004000 /* Thread blocked on user PI mutex. */ #define TDF_NEEDSUSPCHK 0x00008000 /* Thread may need to suspend. */ @@ -704,7 +705,7 @@ #define SWT_OWEPREEMPT 2 /* Switching due to opepreempt. */ #define SWT_TURNSTILE 3 /* Turnstile contention. */ #define SWT_SLEEPQ 4 /* Sleepq wait. */ -#define SWT_SLEEPQTIMO 5 /* Sleepq timeout wait. */ +#define SWT_UNUSED5 5 /* --available-- */ #define SWT_RELINQUISH 6 /* yield call. */ #define SWT_NEEDRESCHED 7 /* NEEDRESCHED was set. */ #define SWT_IDLE 8 /* Switching from the idle thread. */ --------------070009030809080804000507-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 17:56:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E5B0D8 for ; Sun, 4 Jan 2015 17:56:42 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC2073022 for ; Sun, 4 Jan 2015 17:56:41 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id z20so1493724igj.16 for ; Sun, 04 Jan 2015 09:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=glgRM+BUmY77EE57mc61HZZTcuG/L3xe5ErwSna3MHI=; b=K3bAgSxejWV5xwiHaamVo8GpfmaK0Hxj8Vm3rR50szR7oKciDdFHPIMPjQPnZLpUFG aVBXgsm+g9PQwSUANklI3HljG8iDH+sTtnY02zTcqhaMhu8JwPXFA9hB59jYDA2P5MCq 9MCFVweRvHU/nPJ6kS8agVug343ANK4lLv+jR8gdV5uCNxLLU/ZW3Ea+PEKIURB2cUgc cNxXoFnvGC96YiGtNb0wRmkhNgnsr50B6Ekxxf5WUWAdpjBe9wiMXca8aiKg7PHrRdZe RApN32FlQZ6DFkQgr1QiuDtL1QF2fyvo/BNpih0EYDWOe98VSwBCmp/uqagnIIgDEL5t gK7w== X-Gm-Message-State: ALoCoQnpAvImgNmAh/cLi3Fx3O7Tb7PEtDIx4no2KCClwnotHSViw9NS1v+H0xYJPVUDh9fUU/I5 X-Received: by 10.107.170.166 with SMTP id g38mr30604447ioj.2.1420394194836; Sun, 04 Jan 2015 09:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.217 with HTTP; Sun, 4 Jan 2015 09:56:14 -0800 (PST) X-Originating-IP: [72.177.7.16] From: Bryan Venteicher Date: Sun, 4 Jan 2015 11:56:14 -0600 Message-ID: Subject: [CFT] Paravirtualized KVM clock To: FreeBSD-current Content-Type: multipart/mixed; boundary=001a11425fb46ce52b050bd74b4a X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 17:56:42 -0000 --001a11425fb46ce52b050bd74b4a Content-Type: text/plain; charset=UTF-8 For the last few weeks, I've been working on adding support for KVM clock in the projects/paravirt branch. Currently, a KVM VM guest will end up selecting either the HPET or ACPI as the timecounter source. Unfortunately, this is very costly since every timecounter fetch causes a VM exit. KVM clock allows the guest to use the TSC instead; it is very similar to the existing Xen timer. The performance difference between HPET/ACPI and KVMCLOCK can be dramatic: a simple disk benchmark goes from 10K IOPs to 100K IOPs. The patch is attached is attached or available at [1]. I'd appreciate any testing. Also as a part of this, I've tried to generalized a bit of our existing hypervisor guest code, with the eventual goal of being able to support more invasive PV operations. The patch series is viewable in Phabricator. https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the XEN timer code into pvclock https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate the TSC frequency from pvclock https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor registration and detection interface https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve using new hypervisor interface https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware using new hypervisor interface https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using new hypervisor interface https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter support My current plan is to MFC this series to 10-STABLE, and commit a self-contained KVM clock to the other stable branches. [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch --001a11425fb46ce52b050bd74b4a Content-Type: text/x-patch; charset=US-ASCII; name="kvm_clock-1.patch" Content-Disposition: attachment; filename="kvm_clock-1.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4ipow0z0 ZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL3B2Y2xvY2suaCBiL3N5cy9hbWQ2NC9pbmNs dWRlL3B2Y2xvY2suaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5mMDFmYWM2 Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvcHZjbG9jay5oCkBAIC0wLDAg KzEsNiBAQAorLyotCisgKiBUaGlzIGZpbGUgaXMgaW4gdGhlIHB1YmxpYyBkb21haW4uCisgKi8K Ky8qICRGcmVlQlNEJCAqLworCisjaW5jbHVkZSA8eDg2L3B2Y2xvY2suaD4KZGlmZiAtLWdpdCBh L3N5cy9jb25mL2ZpbGVzLmFtZDY0IGIvc3lzL2NvbmYvZmlsZXMuYW1kNjQKaW5kZXggYmJiZTgy Ny4uN2Q4NTc0MiAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMuYW1kNjQKKysrIGIvc3lzL2Nv bmYvZmlsZXMuYW1kNjQKQEAgLTU1NSwxMyArNTU1LDE3IEBAIHg4Ni9pc2Evbm1pLmMJCQlzdGFu ZGFyZAogeDg2L2lzYS9vcm0uYwkJCW9wdGlvbmFsCWlzYQogeDg2L3BjaS9wY2lfYnVzLmMJCW9w dGlvbmFsCXBjaQogeDg2L3BjaS9xcGkuYwkJCW9wdGlvbmFsCXBjaQoreDg2L3g4Ni9iaHl2ZS5j CQkJc3RhbmRhcmQKIHg4Ni94ODYvYnVzZG1hX2JvdW5jZS5jCQlzdGFuZGFyZAogeDg2L3g4Ni9i dXNkbWFfbWFjaGRlcC5jCXN0YW5kYXJkCiB4ODYveDg2L2R1bXBfbWFjaGRlcC5jCQlzdGFuZGFy ZAogeDg2L3g4Ni9mZHRfbWFjaGRlcC5jCQlvcHRpb25hbAlmZHQKK3g4Ni94ODYvaHlwZXJ2aXNv ci5jCQlzdGFuZGFyZAogeDg2L3g4Ni9pZGVudGNwdS5jCQlzdGFuZGFyZAogeDg2L3g4Ni9pbnRy X21hY2hkZXAuYwkJc3RhbmRhcmQKIHg4Ni94ODYvaW9fYXBpYy5jCQlzdGFuZGFyZAoreDg2L3g4 Ni9rdm0uYwkJCXN0YW5kYXJkCit4ODYveDg2L2t2bV9jbG9jay5jCQlzdGFuZGFyZAogeDg2L3g4 Ni9sZWdhY3kuYwkJc3RhbmRhcmQKIHg4Ni94ODYvbG9jYWxfYXBpYy5jCQlzdGFuZGFyZAogeDg2 L3g4Ni9tY2EuYwkJCXN0YW5kYXJkCkBAIC01NjksOCArNTczLDEwIEBAIHg4Ni94ODYvbXB0YWJs ZS5jCQlvcHRpb25hbAltcHRhYmxlCiB4ODYveDg2L21wdGFibGVfcGNpLmMJCW9wdGlvbmFsCW1w dGFibGUgcGNpCiB4ODYveDg2L21zaS5jCQkJb3B0aW9uYWwJcGNpCiB4ODYveDg2L25leHVzLmMJ CQlzdGFuZGFyZAoreDg2L3g4Ni9wdmNsb2NrLmMJCXN0YW5kYXJkCiB4ODYveDg2L3RzYy5jCQkJ c3RhbmRhcmQKIHg4Ni94ODYvZGVsYXkuYwkJCXN0YW5kYXJkCit4ODYveDg2L3Ztd2FyZS5jCQlz dGFuZGFyZAogeDg2L3hlbi9odm0uYwkJCW9wdGlvbmFsCXhlbmh2bQogeDg2L3hlbi94ZW5faW50 ci5jCQlvcHRpb25hbAl4ZW4gfCB4ZW5odm0KIHg4Ni94ZW4vcHYuYwkJCW9wdGlvbmFsCXhlbmh2 bQpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuaTM4NiBiL3N5cy9jb25mL2ZpbGVzLmkzODYK aW5kZXggOTY4NzliOC4uY2E4M2M0YyAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMuaTM4Ngor KysgYi9zeXMvY29uZi9maWxlcy5pMzg2CkBAIC01NzMsMTMgKzU3MywxNyBAQCB4ODYvaXNhL25t aS5jCQkJc3RhbmRhcmQKIHg4Ni9pc2Evb3JtLmMJCQlvcHRpb25hbCBpc2EKIHg4Ni9wY2kvcGNp X2J1cy5jCQlvcHRpb25hbCBwY2kKIHg4Ni9wY2kvcXBpLmMJCQlvcHRpb25hbCBwY2kKK3g4Ni94 ODYvYmh5dmUuYwkJCXN0YW5kYXJkCiB4ODYveDg2L2J1c2RtYV9ib3VuY2UuYwkJc3RhbmRhcmQK IHg4Ni94ODYvYnVzZG1hX21hY2hkZXAuYwlzdGFuZGFyZAogeDg2L3g4Ni9kdW1wX21hY2hkZXAu YwkJc3RhbmRhcmQKIHg4Ni94ODYvZmR0X21hY2hkZXAuYwkJb3B0aW9uYWwgZmR0Cit4ODYveDg2 L2h5cGVydmlzb3IuYwkJc3RhbmRhcmQKIHg4Ni94ODYvaWRlbnRjcHUuYwkJc3RhbmRhcmQKIHg4 Ni94ODYvaW50cl9tYWNoZGVwLmMJCXN0YW5kYXJkCiB4ODYveDg2L2lvX2FwaWMuYwkJb3B0aW9u YWwgYXBpYworeDg2L3g4Ni9rdm0uYwkJCXN0YW5kYXJkCit4ODYveDg2L2t2bV9jbG9jay5jCQlz dGFuZGFyZAogeDg2L3g4Ni9sZWdhY3kuYwkJb3B0aW9uYWwgbmF0aXZlCiB4ODYveDg2L2xvY2Fs X2FwaWMuYwkJb3B0aW9uYWwgYXBpYwogeDg2L3g4Ni9tY2EuYwkJCXN0YW5kYXJkCkBAIC01ODgs NyArNTkyLDkgQEAgeDg2L3g4Ni9tcHRhYmxlX3BjaS5jCQlvcHRpb25hbCBhcGljIG5hdGl2ZSBw Y2kKIHg4Ni94ODYvbXNpLmMJCQlvcHRpb25hbCBhcGljIHBjaQogeDg2L3g4Ni9uZXh1cy5jCQkJ c3RhbmRhcmQKIHg4Ni94ODYvdHNjLmMJCQlzdGFuZGFyZAoreDg2L3g4Ni9wdmNsb2NrLmMJCXN0 YW5kYXJkCiB4ODYveDg2L2RlbGF5LmMJCQlzdGFuZGFyZAoreDg2L3g4Ni92bXdhcmUuYwkJc3Rh bmRhcmQKIHg4Ni94ZW4vaHZtLmMJCQlvcHRpb25hbCB4ZW5odm0KIHg4Ni94ZW4veGVuX2ludHIu YwkJb3B0aW9uYWwgeGVuIHwgeGVuaHZtCiB4ODYveGVuL3hlbl9hcGljLmMJCW9wdGlvbmFsIHhl bmh2bQpkaWZmIC0tZ2l0IGEvc3lzL2Rldi94ZW4vdGltZXIvdGltZXIuYyBiL3N5cy9kZXYveGVu L3RpbWVyL3RpbWVyLmMKaW5kZXggNTc0MzA3Ni4uNTNhZmYwYSAxMDA2NDQKLS0tIGEvc3lzL2Rl di94ZW4vdGltZXIvdGltZXIuYworKysgYi9zeXMvZGV2L3hlbi90aW1lci90aW1lci5jCkBAIC01 OSw2ICs1OSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxtYWNoaW5lL2Ns b2NrLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9faW50dHlwZXMuaD4KICNpbmNsdWRlIDxtYWNoaW5l L3NtcC5oPgorI2luY2x1ZGUgPG1hY2hpbmUvcHZjbG9jay5oPgogCiAjaW5jbHVkZSA8ZGV2L3hl bi90aW1lci90aW1lci5oPgogCkBAIC05NSw5ICs5Niw2IEBAIHN0cnVjdCB4ZW50aW1lcl9zb2Z0 YyB7CiAJc3RydWN0IGV2ZW50dGltZXIgZXQ7CiB9OwogCi0vKiBMYXN0IHRpbWU7IHRoaXMgZ3Vh cmFudGVlcyBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jay4gKi8KLXZvbGF0aWxlIHVp bnQ2NF90IHhlbl90aW1lcl9sYXN0X3RpbWUgPSAwOwotCiBzdGF0aWMgdm9pZAogeGVudGltZXJf aWRlbnRpZnkoZHJpdmVyX3QgKmRyaXZlciwgZGV2aWNlX3QgcGFyZW50KQogewpAQCAtMTQ4LDEy OCArMTQ2LDIwIEBAIHhlbnRpbWVyX3Byb2JlKGRldmljZV90IGRldikKIAlyZXR1cm4gKEJVU19Q Uk9CRV9OT1dJTERDQVJEKTsKIH0KIAotLyoKLSAqIFNjYWxlIGEgNjQtYml0IGRlbHRhIGJ5IHNj YWxpbmcgYW5kIG11bHRpcGx5aW5nIGJ5IGEgMzItYml0IGZyYWN0aW9uLAotICogeWllbGRpbmcg YSA2NC1iaXQgcmVzdWx0LgotICovCi1zdGF0aWMgaW5saW5lIHVpbnQ2NF90Ci1zY2FsZV9kZWx0 YSh1aW50NjRfdCBkZWx0YSwgdWludDMyX3QgbXVsX2ZyYWMsIGludCBzaGlmdCkKLXsKLQl1aW50 NjRfdCBwcm9kdWN0OwotCi0JaWYgKHNoaWZ0IDwgMCkKLQkJZGVsdGEgPj49IC1zaGlmdDsKLQll bHNlCi0JCWRlbHRhIDw8PSBzaGlmdDsKLQotI2lmIGRlZmluZWQoX19pMzg2X18pCi0JewotCQl1 aW50MzJfdCB0bXAxLCB0bXAyOwotCi0JCS8qKgotCQkgKiBGb3IgaTM4NiwgdGhlIGZvcm11bGEg bG9va3MgbGlrZToKLQkJICoKLQkJICogICBsb3dlciA9IChtdWxfZnJhYyAqIChkZWx0YSAmIFVJ TlRfTUFYKSkgPj4gMzIKLQkJICogICB1cHBlciA9IG11bF9mcmFjICogKGRlbHRhID4+IDMyKQot CQkgKiAgIHByb2R1Y3QgPSBsb3dlciArIHVwcGVyCi0JCSAqLwotCQlfX2FzbV9fICgKLQkJCSJt dWwgICU1ICAgICAgIDsgIgotCQkJIm1vdiAgJTQsJSVlYXggOyAiCi0JCQkibW92ICAlJWVkeCwl NCA7ICIKLQkJCSJtdWwgICU1ICAgICAgIDsgIgotCQkJInhvciAgJTUsJTUgICAgOyAiCi0JCQki YWRkICAlNCwlJWVheCA7ICIKLQkJCSJhZGMgICU1LCUlZWR4IDsgIgotCQkJOiAiPUEiIChwcm9k dWN0KSwgIj1yIiAodG1wMSksICI9ciIgKHRtcDIpCi0JCQk6ICJhIiAoKHVpbnQzMl90KWRlbHRh KSwgIjEiICgodWludDMyX3QpKGRlbHRhID4+IDMyKSksCi0JCQkgICIyIiAobXVsX2ZyYWMpICk7 Ci0JfQotI2VsaWYgZGVmaW5lZChfX2FtZDY0X18pCi0JewotCQl1bnNpZ25lZCBsb25nIHRtcDsK LQotCQlfX2FzbV9fICgKLQkJCSJtdWxxICVbbXVsX2ZyYWNdIDsgc2hyZCAkMzIsICVbaGldLCAl W2xvXSIKLQkJCTogW2xvXSI9YSIgKHByb2R1Y3QpLCBbaGldIj1kIiAodG1wKQotCQkJOiAiMCIg KGRlbHRhKSwgW211bF9mcmFjXSJybSIoKHVpbnQ2NF90KW11bF9mcmFjKSk7Ci0JfQotI2Vsc2UK LSNlcnJvciAieGVudGltZXI6IHVuc3VwcG9ydGVkIGFyY2hpdGVjdHVyZSIKLSNlbmRpZgotCi0J cmV0dXJuIChwcm9kdWN0KTsKLX0KLQotc3RhdGljIHVpbnQ2NF90Ci1nZXRfbnNlY19vZmZzZXQo c3RydWN0IHZjcHVfdGltZV9pbmZvICp0aW5mbykKLXsKLQotCXJldHVybiAoc2NhbGVfZGVsdGEo cmR0c2MoKSAtIHRpbmZvLT50c2NfdGltZXN0YW1wLAotCSAgICB0aW5mby0+dHNjX3RvX3N5c3Rl bV9tdWwsIHRpbmZvLT50c2Nfc2hpZnQpKTsKLX0KLQotLyoKLSAqIFJlYWQgdGhlIGN1cnJlbnQg aHlwZXJ2aXNvciBzeXN0ZW0gdXB0aW1lIHZhbHVlIGZyb20gWGVuLgotICogU2VlIDx4ZW4vaW50 ZXJmYWNlL3hlbi5oPiBmb3IgYSBkZXNjcmlwdGlvbiBvZiBob3cgdGhpcyB3b3Jrcy4KLSAqLwot c3RhdGljIHVpbnQzMl90Ci14ZW5fZmV0Y2hfdmNwdV90aW5mbyhzdHJ1Y3QgdmNwdV90aW1lX2lu Zm8gKmRzdCwgc3RydWN0IHZjcHVfdGltZV9pbmZvICpzcmMpCi17Ci0KLQlkbyB7Ci0JCWRzdC0+ dmVyc2lvbiA9IHNyYy0+dmVyc2lvbjsKLQkJcm1iKCk7Ci0JCWRzdC0+dHNjX3RpbWVzdGFtcCA9 IHNyYy0+dHNjX3RpbWVzdGFtcDsKLQkJZHN0LT5zeXN0ZW1fdGltZSA9IHNyYy0+c3lzdGVtX3Rp bWU7Ci0JCWRzdC0+dHNjX3RvX3N5c3RlbV9tdWwgPSBzcmMtPnRzY190b19zeXN0ZW1fbXVsOwot CQlkc3QtPnRzY19zaGlmdCA9IHNyYy0+dHNjX3NoaWZ0OwotCQlybWIoKTsKLQl9IHdoaWxlICgo c3JjLT52ZXJzaW9uICYgMSkgfCAoZHN0LT52ZXJzaW9uIF4gc3JjLT52ZXJzaW9uKSk7Ci0KLQly ZXR1cm4gKGRzdC0+dmVyc2lvbik7Ci19Ci0KIC8qKgogICogXGJyaWVmIEdldCB0aGUgY3VycmVu dCB0aW1lLCBpbiBuYW5vc2Vjb25kcywgc2luY2UgdGhlIGh5cGVydmlzb3IgYm9vdGVkLgogICoK ICAqIFxwYXJhbSB2Y3B1CQl2Y3B1X2luZm8gc3RydWN0dXJlIHRvIGZldGNoIHRoZSB0aW1lIGZy b20uCiAgKgotICogXG5vdGUgVGhpcyBmdW5jdGlvbiByZXR1cm5zIHRoZSBjdXJyZW50IENQVSdz IGlkZWEgb2YgdGhpcyB2YWx1ZSwgdW5sZXNzCi0gKiAgICAgICBpdCBoYXBwZW5zIHRvIGJlIGxl c3MgdGhhbiBhbm90aGVyIENQVSdzIHByZXZpb3VzbHkgZGV0ZXJtaW5lZCB2YWx1ZS4KICAqLwog c3RhdGljIHVpbnQ2NF90CiB4ZW5fZmV0Y2hfdmNwdV90aW1lKHN0cnVjdCB2Y3B1X2luZm8gKnZj cHUpCiB7Ci0Jc3RydWN0IHZjcHVfdGltZV9pbmZvIGRzdDsKLQlzdHJ1Y3QgdmNwdV90aW1lX2lu Zm8gKnNyYzsKLQl1aW50MzJfdCBwcmVfdmVyc2lvbjsKLQl1aW50NjRfdCBub3c7Ci0Jdm9sYXRp bGUgdWludDY0X3QgbGFzdDsKLQotCXNyYyA9ICZ2Y3B1LT50aW1lOwotCi0JZG8gewotCQlwcmVf dmVyc2lvbiA9IHhlbl9mZXRjaF92Y3B1X3RpbmZvKCZkc3QsIHNyYyk7Ci0JCWJhcnJpZXIoKTsK LQkJbm93ID0gZHN0LnN5c3RlbV90aW1lICsgZ2V0X25zZWNfb2Zmc2V0KCZkc3QpOwotCQliYXJy aWVyKCk7Ci0JfSB3aGlsZSAocHJlX3ZlcnNpb24gIT0gc3JjLT52ZXJzaW9uKTsKKwlzdHJ1Y3Qg cHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGltZTsKIAotCS8qCi0JICogRW5mb3JjZSBhIG1vbm90 b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jayB0aW1lIGFjcm9zcyBhbGwKLQkgKiBWQ1BVcy4gIElm IG91ciB0aW1lIGlzIHRvbyBvbGQsIHVzZSB0aGUgbGFzdCB0aW1lIGFuZCByZXR1cm4uCi0JICog T3RoZXJ3aXNlLCB0cnkgdG8gdXBkYXRlIHRoZSBsYXN0IHRpbWUuCi0JICovCi0JZG8gewotCQls YXN0ID0geGVuX3RpbWVyX2xhc3RfdGltZTsKLQkJaWYgKGxhc3QgPiBub3cpIHsKLQkJCW5vdyA9 IGxhc3Q7Ci0JCQlicmVhazsKLQkJfQotCX0gd2hpbGUgKCFhdG9taWNfY21wc2V0XzY0KCZ4ZW5f dGltZXJfbGFzdF90aW1lLCBsYXN0LCBub3cpKTsKKwl0aW1lID0gKHN0cnVjdCBwdmNsb2NrX3Zj cHVfdGltZV9pbmZvICopICZ2Y3B1LT50aW1lOwogCi0JcmV0dXJuIChub3cpOworCXJldHVybiAo cHZjbG9ja19nZXRfdGltZWNvdW50KHRpbWUpKTsKIH0KIAogc3RhdGljIHVpbnQzMl90CkBAIC0z MDIsMTUgKzE5MiwxMSBAQCBzdGF0aWMgdm9pZAogeGVuX2ZldGNoX3dhbGxjbG9jayhzdHJ1Y3Qg dGltZXNwZWMgKnRzKQogewogCXNoYXJlZF9pbmZvX3QgKnNyYyA9IEhZUEVSVklTT1Jfc2hhcmVk X2luZm87Ci0JdWludDMyX3QgdmVyc2lvbiA9IDA7CisJc3RydWN0IHB2Y2xvY2tfd2FsbF9jbG9j ayAqd2M7CiAKLQlkbyB7Ci0JCXZlcnNpb24gPSBzcmMtPndjX3ZlcnNpb247Ci0JCXJtYigpOwot CQl0cy0+dHZfc2VjID0gc3JjLT53Y19zZWM7Ci0JCXRzLT50dl9uc2VjID0gc3JjLT53Y19uc2Vj OwotCQlybWIoKTsKLQl9IHdoaWxlICgoc3JjLT53Y192ZXJzaW9uICYgMSkgfCAodmVyc2lvbiBe IHNyYy0+d2NfdmVyc2lvbikpOworCXdjID0gKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKikg JnNyYy0+d2NfdmVyc2lvbjsKKworCXB2Y2xvY2tfZ2V0X3dhbGxjbG9jayh3YywgdHMpOwogfQog CiBzdGF0aWMgdm9pZApAQCAtNTc0LDcgKzQ2MCw3IEBAIHhlbnRpbWVyX3Jlc3VtZShkZXZpY2Vf dCBkZXYpCiAJfQogCiAJLyogUmVzZXQgdGhlIGxhc3QgdXB0aW1lIHZhbHVlICovCi0JeGVuX3Rp bWVyX2xhc3RfdGltZSA9IDA7CisJcHZjbG9ja19yZXN1bWUoKTsKIAogCS8qIFJlc2V0IHRoZSBS VEMgY2xvY2sgKi8KIAlpbml0dG9kcih0aW1lX3NlY29uZCk7CmRpZmYgLS1naXQgYS9zeXMvaTM4 Ni9pbmNsdWRlL3B2Y2xvY2suaCBiL3N5cy9pMzg2L2luY2x1ZGUvcHZjbG9jay5oCm5ldyBmaWxl IG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmYwMWZhYzYKLS0tIC9kZXYvbnVsbAorKysgYi9z eXMvaTM4Ni9pbmNsdWRlL3B2Y2xvY2suaApAQCAtMCwwICsxLDYgQEAKKy8qLQorICogVGhpcyBm aWxlIGlzIGluIHRoZSBwdWJsaWMgZG9tYWluLgorICovCisvKiAkRnJlZUJTRCQgKi8KKworI2lu Y2x1ZGUgPHg4Ni9wdmNsb2NrLmg+CmRpZmYgLS1naXQgYS9zeXMva2Vybi9zdWJyX3BhcmFtLmMg Yi9zeXMva2Vybi9zdWJyX3BhcmFtLmMKaW5kZXggOTVmMzI1MC4uNTMzMjA1NSAxMDA2NDQKLS0t IGEvc3lzL2tlcm4vc3Vicl9wYXJhbS5jCisrKyBiL3N5cy9rZXJuL3N1YnJfcGFyYW0uYwpAQCAt MTU5LDYgKzE1OSw4IEBAIHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCB2bV9ndWVzdF9zeXNjdGxf bmFtZXNbXSA9IHsKIAkieGVuIiwKIAkiaHYiLAogCSJ2bXdhcmUiLAorCSJiaHl2ZSIsCisJImt2 bSIsCiAJTlVMTAogfTsKIENUQVNTRVJUKG5pdGVtcyh2bV9ndWVzdF9zeXNjdGxfbmFtZXMpIC0g MSA9PSBWTV9MQVNUKTsKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc3lzdG0uaCBiL3N5cy9zeXMvc3lz dG0uaAppbmRleCBkMzgzM2QwLi41MGE0OWQyIDEwMDY0NAotLS0gYS9zeXMvc3lzL3N5c3RtLmgK KysrIGIvc3lzL3N5cy9zeXN0bS5oCkBAIC03Myw3ICs3Myw3IEBAIGV4dGVybiBpbnQgdm1fZ3Vl c3Q7CQkvKiBSdW5uaW5nIGFzIHZpcnR1YWwgbWFjaGluZSBndWVzdD8gKi8KICAqIEtlZXAgaW4g c3luYyB3aXRoIHZtX2d1ZXN0X3N5c2N0bF9uYW1lc1tdLgogICovCiBlbnVtIFZNX0dVRVNUIHsg Vk1fR1VFU1RfTk8gPSAwLCBWTV9HVUVTVF9WTSwgVk1fR1VFU1RfWEVOLCBWTV9HVUVTVF9IViwK LQkJVk1fR1VFU1RfVk1XQVJFLCBWTV9MQVNUIH07CisJCVZNX0dVRVNUX1ZNV0FSRSwgVk1fR1VF U1RfQkhZVkUsIFZNX0dVRVNUX0tWTSwgVk1fTEFTVCB9OwogCiAjaWYgZGVmaW5lZChXSVRORVNT KSB8fCBkZWZpbmVkKElOVkFSSUFOVFMpCiB2b2lkCWthc3NlcnRfcGFuaWMoY29uc3QgY2hhciAq Zm10LCAuLi4pICBfX3ByaW50Zmxpa2UoMSwgMik7CmRpZmYgLS1naXQgYS9zeXMveDg2L2luY2x1 ZGUvaHlwZXJ2aXNvci5oIGIvc3lzL3g4Ni9pbmNsdWRlL2h5cGVydmlzb3IuaApuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5kNWQzMGViCi0tLSAvZGV2L251bGwKKysrIGIvc3lz L3g4Ni9pbmNsdWRlL2h5cGVydmlzb3IuaApAQCAtMCwwICsxLDU2IEBACisvKi0KKyAqIENvcHly aWdodCAoYykgMjAxNCBCcnlhbiBWZW50ZWljaGVyIDxicnlhbnZARnJlZUJTRC5vcmc+CisgKiBB bGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBh cmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWlu IHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBp biBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJv dmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFO WSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlU RUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4g Tk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBG T1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwg T1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQg VE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NT IE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICog SE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElO IENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJ R0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNF IE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YK KyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAorICovCisKKyNpZm5kZWYgX1g4Nl9I WVBFUlZJU09SX0hfCisjZGVmaW5lIF9YODZfSFlQRVJWSVNPUl9IXworCisjaW5jbHVkZSA8c3lz L3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorCit0eXBlZGVmIHZvaWQgaHlwZXJ2 aXNvcl9pbml0X2Z1bmNfdCh2b2lkKTsKKworLyoKKyAqIFRoZSBndWVzdCBoeXBlcnZpc29yIHN1 cHBvcnQgbWF5IHByb3ZpZGUgcGFyYXZpcnR1YWxpemVkIG9yIGhhdmUgc3BlY2lhbAorICogcmVx dWlyZW1lbnRzIGZvciB2YXJpb3VzIG9wZXJhdGlvbnMuIFRoZSBjYWxsYmFjayBmdW5jdGlvbnMg YXJlIHByb3ZpZGVkCisgKiB3aGVuIGEgaHlwZXJ2aXNvciBpcyBkZXRlY3RlZCBhbmQgcmVnaXN0 ZXJlZC4KKyAqLworc3RydWN0IGh5cGVydmlzb3Jfb3BzIHsKK307CisKK3ZvaWQJaHlwZXJ2aXNv cl9zeXNpbml0KHZvaWQgKmZ1bmMpOwordm9pZAloeXBlcnZpc29yX3JlZ2lzdGVyKGNvbnN0IGNo YXIgKnZlbmRvciwgZW51bSBWTV9HVUVTVCBndWVzdCwKKwkgICAgc3RydWN0IGh5cGVydmlzb3Jf b3BzICpvcHMpOworaW50CWh5cGVydmlzb3JfY3B1aWRfYmFzZShjb25zdCBjaGFyICpzaWduYXR1 cmUsIGludCBsZWF2ZXMsCisJICAgIHVpbnQzMl90ICpiYXNlLCB1aW50MzJfdCAqaGlnaCk7Cit2 b2lkCWh5cGVydmlzb3JfcHJpbnRfaW5mbyh2b2lkKTsKKworI2RlZmluZSBIWVBFUlZJU09SX1NZ U0lOSVQobmFtZSwgZnVuYykJCQkJXAorCVNZU0lOSVQobmFtZSAjIyBfaHlwZXJ2aXNvcl9zeXNp bml0LCBTSV9TVUJfSFlQRVJWSVNPUiwJXAorCSAgICBTSV9PUkRFUl9GSVJTVCwgaHlwZXJ2aXNv cl9zeXNpbml0LCBmdW5jKQorCisjZW5kaWYgLyogIV9YODZfSFlQRVJWSVNPUl9IXyAqLwpkaWZm IC0tZ2l0IGEvc3lzL3g4Ni9pbmNsdWRlL2t2bS5oIGIvc3lzL3g4Ni9pbmNsdWRlL2t2bS5oCm5l dyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmI1MzkwMzgKLS0tIC9kZXYvbnVsbAor KysgYi9zeXMveDg2L2luY2x1ZGUva3ZtLmgKQEAgLTAsMCArMSw0OSBAQAorLyotCisgKiBDb3B5 cmlnaHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICog QWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwg YXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICog YXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFp biB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRp b25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMg aW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAg bm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFp bWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHBy b3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBS T1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBB TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J VEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICog Rk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlks IE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9T UyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAq IEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJ TiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdM SUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9G CisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqLworCisjaWZuZGVmIF9YODZf S1ZNX0hfCisjZGVmaW5lIF9YODZfS1ZNX0hfCisKKyNkZWZpbmUgS1ZNX0NQVUlEX0ZFQVRVUkVT X0xFQUYJCTB4NDAwMDAwMDEKKworI2RlZmluZSBLVk1fRkVBVFVSRV9DTE9DS1NPVVJDRQkJMHgw MDAwMDAwMQorI2RlZmluZSBLVk1fRkVBVFVSRV9DTE9DS1NPVVJDRTIJMHgwMDAwMDAwOAorCisv KiBEZXByZWNhdGVkOiBmb3IgdGhlIENMT0NLU09VUkNFIGZlYXR1cmUuICovCisjZGVmaW5lIEtW TV9NU1JfV0FMTF9DTE9DSwkJMHgxMQorI2RlZmluZSBLVk1fTVNSX1NZU1RFTV9USU1FCQkweDEy CisKKyNkZWZpbmUgS1ZNX01TUl9XQUxMX0NMT0NLX05FVwkJMHg0YjU2NGQwMAorI2RlZmluZSBL Vk1fTVNSX1NZU1RFTV9USU1FX05FVwkJMHg0YjU2NGQwMQorCitpbnQJCWt2bV9wYXJhdmlydF9z dXBwb3J0ZWQodm9pZCk7Cit1aW50MzJfdAlrdm1fZ2V0X2ZlYXR1cmVzKHZvaWQpOworCit1aW50 NjRfdAlrdm1fY2xvY2tfdHNjX2ZyZXEodm9pZCk7CisKKyNlbmRpZiAvKiAhX1g4Nl9LVk1fSF8g Ki8KZGlmZiAtLWdpdCBhL3N5cy94ODYvaW5jbHVkZS9wdmNsb2NrLmggYi9zeXMveDg2L2luY2x1 ZGUvcHZjbG9jay5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjI1YWJhOTkK LS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L2luY2x1ZGUvcHZjbG9jay5oCkBAIC0wLDAgKzEs NTggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0LCBCcnlhbiBWZW50ZWljaGVyIDxicnlh bnZARnJlZUJTRC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAq IDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq IFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JT IGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5D TFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAq IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMK KyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAor ICovCisKKyNpZm5kZWYgWDg2X1BWQ0xPQ0sKKyNkZWZpbmUgWDg2X1BWQ0xPQ0sKKworc3RydWN0 IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8geworCXVpbnQzMl90CXZlcnNpb247CisJdWludDMyX3QJ cGFkMDsKKwl1aW50NjRfdAl0c2NfdGltZXN0YW1wOworCXVpbnQ2NF90CXN5c3RlbV90aW1lOwor CXVpbnQzMl90CXRzY190b19zeXN0ZW1fbXVsOworCWludDhfdAkJdHNjX3NoaWZ0OworCXVpbnQ4 X3QJCWZsYWdzOworCXVpbnQ4X3QJCXBhZFsyXTsKK30gX19wYWNrZWQ7CisKKyNkZWZpbmUgUFZD TE9DS19GTEFHX1RTQ19TVEFCTEUJCTB4MDEKKyNkZWZpbmUgUFZDTE9DS19GTEFHX0dVRVNUX1BB U1VFRAkweDAyCisKK3N0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgeworCXVpbnQzMl90CXZlcnNp b247CisJdWludDMyX3QJc2VjOworCXVpbnQzMl90CW5zZWM7Cit9IF9fcGFja2VkOworCit2b2lk CQlwdmNsb2NrX3Jlc3VtZSh2b2lkKTsKK3VpbnQ2NF90CXB2Y2xvY2tfdHNjX2ZyZXEoc3RydWN0 IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpKTsKK3VpbnQ2NF90CXB2Y2xvY2tfZ2V0X3RpbWVj b3VudChzdHJ1Y3QgcHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGkpOwordm9pZAkJcHZjbG9ja19n ZXRfd2FsbGNsb2NrKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKndjLAorCQkgICAgc3RydWN0 IHRpbWVzcGVjICp0cyk7CisKKyNlbmRpZgpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni9pbmNsdWRlL3Zt d2FyZS5oIGIvc3lzL3g4Ni9pbmNsdWRlL3Ztd2FyZS5oCmluZGV4IGM3MmY0OGQuLjg5NjE2YzUg MTAwNjQ0Ci0tLSBhL3N5cy94ODYvaW5jbHVkZS92bXdhcmUuaAorKysgYi9zeXMveDg2L2luY2x1 ZGUvdm13YXJlLmgKQEAgLTQ0LDQgKzQ0LDYgQEAgdm13YXJlX2h2Y2FsbCh1X2ludCBjbWQsIHVf aW50ICpwKQogCTogIm1lbW9yeSIpOwogfQogCit1aW50NjRfdAl2bXdhcmVfdHNjX2ZyZXEodm9p ZCk7CisKICNlbmRpZiAvKiAhX1g4Nl9WTVdBUkVfSF8gKi8KZGlmZiAtLWdpdCBhL3N5cy94ODYv eDg2L2JoeXZlLmMgYi9zeXMveDg2L3g4Ni9iaHl2ZS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAuLmQyMWU4MDgKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4Ni9iaHl2 ZS5jCkBAIC0wLDAgKzEsNTggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0IEJyeWFuIFZl bnRlaWNoZXIgPGJyeWFudkBGcmVlQlNELm9yZz4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisg KgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywg d2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3Ry aWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVw cm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3Vt ZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmli dXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFO RCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVE IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVU SE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVD VCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBE QU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9G SVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04g QU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICog TElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFS SVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZF TiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8K KworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5j bHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNpbmNsdWRlIDx4 ODYvaHlwZXJ2aXNvci5oPgorCitzdGF0aWMgdWludDMyX3QgYmh5dmVfY3B1aWRfYmFzZSA9IC0x Oworc3RhdGljIHVpbnQzMl90IGJoeXZlX2NwdWlkX2hpZ2ggPSAtMTsKKworc3RhdGljIGludAor Ymh5dmVfY3B1aWRfaWRlbnRpZnkodm9pZCkKK3sKKworCWlmIChiaHl2ZV9jcHVpZF9iYXNlID09 IC0xKSB7CisJCWh5cGVydmlzb3JfY3B1aWRfYmFzZSgiYmh5dmUgYmh5dmUiLCAwLCAmYmh5dmVf Y3B1aWRfYmFzZSwKKwkJICAgICZiaHl2ZV9jcHVpZF9oaWdoKTsKKwl9CisKKwlyZXR1cm4gKGJo eXZlX2NwdWlkX2Jhc2UgPiAwKTsKK30KKworc3RhdGljIHZvaWQKK2JoeXZlX2luaXQodm9pZCkK K3sKKworCWlmIChiaHl2ZV9jcHVpZF9pZGVudGlmeSgpICE9IDApCisJCWh5cGVydmlzb3JfcmVn aXN0ZXIoImJoeXZlIiwgVk1fR1VFU1RfQkhZVkUsIE5VTEwpOworfQorCitIWVBFUlZJU09SX1NZ U0lOSVQoYmh5dmUsIGJoeXZlX2luaXQpOwpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni94ODYvaHlwZXJ2 aXNvci5jIGIvc3lzL3g4Ni94ODYvaHlwZXJ2aXNvci5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAuLjMwYzcwZGYKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4Ni9oeXBl cnZpc29yLmMKQEAgLTAsMCArMSw5OSBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTQgQnJ5 YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZl ZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZv cm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92 aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJl ZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJp Z2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93 aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVz dCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qg b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAg ZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRp c3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRI T1IgQU5EIENPTlRSSUJVVE9SUyBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBM SUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisg KiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0Yg U1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQ Uk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQg T04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAor ICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwg RVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisg Ki8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisj aW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorI2luY2x1ZGUg PHN5cy9zeXN0bS5oPgorCisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjaW5jbHVkZSA8 bWFjaGluZS9jcHUuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL21kX3Zhci5oPgorI2luY2x1ZGUgPG1h Y2hpbmUvc3BlY2lhbHJlZy5oPgorCisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KKworY2hh ciBodl92ZW5kb3JbMTZdOworU1lTQ1RMX1NUUklORyhfaHcsIE9JRF9BVVRPLCBodl92ZW5kb3Is IENUTEZMQUdfUkQsIGh2X3ZlbmRvciwgMCwKKyAgICAiSHlwZXJ2aXNvciB2ZW5kb3IiKTsKKwor dm9pZAoraHlwZXJ2aXNvcl9zeXNpbml0KHZvaWQgKmZ1bmMpCit7CisJaHlwZXJ2aXNvcl9pbml0 X2Z1bmNfdCAqaW5pdDsKKworCWluaXQgPSBmdW5jOworCisJLyoKKwkgKiBDYWxsIHRoZSBpbml0 IGZ1bmN0aW9uIGlmIHdlIGhhdmUgbm90IGFscmVhZHkgaWRlbnRpZmllZCB0aGUKKwkgKiBoeXBl cnZpc29yIHlldC4gV2UgYXNzdW1lIHRoZSBkZXRlY3RhYmxlIGh5cGVydmlzb3JzIHdpbGwKKwkg KiBhbm5vdW5jZSBpdHMgcHJlc2VuY2UgdmlhIHRoZSBDUFVJRCBiaXQuCisJICovCisJaWYgKHZt X2d1ZXN0ID09IFZNX0dVRVNUX1ZNICYmIGNwdV9mZWF0dXJlMiAmIENQVUlEMl9IVikKKwkJKCpp bml0KSgpOworfQorCit2b2lkCitoeXBlcnZpc29yX3JlZ2lzdGVyKGNvbnN0IGNoYXIgKnZlbmRv ciwgZW51bSBWTV9HVUVTVCBndWVzdCwKKyAgICBzdHJ1Y3QgaHlwZXJ2aXNvcl9vcHMgKm9wcykK K3sKKworCXN0cmxjcHkoaHZfdmVuZG9yLCB2ZW5kb3IsIHNpemVvZihodl92ZW5kb3IpKTsKKwl2 bV9ndWVzdCA9IGd1ZXN0OworfQorCisvKgorICogW1JGQ10gQ1BVSUQgdXNhZ2UgZm9yIGludGVy YWN0aW9uIGJldHdlZW4gSHlwZXJ2aXNvcnMgYW5kIExpbnV4LgorICogaHR0cDovL2xrbWwub3Jn L2xrbWwvMjAwOC8xMC8xLzI0NgorICovCitpbnQKK2h5cGVydmlzb3JfY3B1aWRfYmFzZShjb25z dCBjaGFyICpzaWduYXR1cmUsIGludCBsZWF2ZXMsIHVpbnQzMl90ICpiYXNlLAorICAgIHVpbnQz Ml90ICpoaWdoKQoreworCXVpbnQzMl90IGxlYWYsIHJlZ3NbNF07CisKKwlmb3IgKGxlYWYgPSAw eDQwMDAwMDAwOyBsZWFmIDwgMHg0MDAxMDAwMDsgbGVhZiArPSAweDEwMCkgeworCQlkb19jcHVp ZChsZWFmLCByZWdzKTsKKwkJaWYgKCFtZW1jbXAoc2lnbmF0dXJlLCAmcmVnc1sxXSwgMTIpICYm CisJCSAgICAobGVhdmVzID09IDAgfHwgKHJlZ3NbMF0gLSBsZWFmID49IGxlYXZlcykpKSB7CisJ CQkqYmFzZSA9IGxlYWY7CisJCQkqaGlnaCA9IHJlZ3NbMF07CisJCQlyZXR1cm4gKDApOworCQl9 CisJfQorCisJcmV0dXJuICgxKTsKK30KKwordm9pZAoraHlwZXJ2aXNvcl9wcmludF9pbmZvKHZv aWQpCit7CisKKwlpZiAoKmh2X3ZlbmRvcikKKwkJcHJpbnRmKCJIeXBlcnZpc29yOiBPcmlnaW4g PSBcIiVzXCJcbiIsIGh2X3ZlbmRvcik7Cit9CmRpZmYgLS1naXQgYS9zeXMveDg2L3g4Ni9pZGVu dGNwdS5jIGIvc3lzL3g4Ni94ODYvaWRlbnRjcHUuYwppbmRleCBiYWU0MzBhLi5jMjgzOTBjIDEw MDY0NAotLS0gYS9zeXMveDg2L3g4Ni9pZGVudGNwdS5jCisrKyBiL3N5cy94ODYveDg2L2lkZW50 Y3B1LmMKQEAgLTY0LDYgKzY0LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVk ZSA8YW1kNjQvdm1tL2ludGVsL3ZteF9jb250cm9scy5oPgogI2luY2x1ZGUgPHg4Ni9pc2EvaWN1 Lmg+CisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KICNpbmNsdWRlIDx4ODYvdm13YXJlLmg+ CiAKICNpZmRlZiBfX2kzODZfXwpAQCAtNzgsNyArNzksNiBAQCBzdGF0aWMgdV9pbnQgZmluZF9j cHVfdmVuZG9yX2lkKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfQU1EX2luZm8odm9pZCk7CiBz dGF0aWMgdm9pZCBwcmludF9JTlRFTF9pbmZvKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfSU5U RUxfVExCKHVfaW50IGRhdGEpOwotc3RhdGljIHZvaWQgcHJpbnRfaHlwZXJ2aXNvcl9pbmZvKHZv aWQpOwogc3RhdGljIHZvaWQgcHJpbnRfc3ZtX2luZm8odm9pZCk7CiBzdGF0aWMgdm9pZCBwcmlu dF92aWFfcGFkbG9ja19pbmZvKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfdm14X2luZm8odm9p ZCk7CkBAIC0xMjMsMTEgKzEyMyw2IEBAIHN0YXRpYyBpbnQgaHdfY2xvY2tyYXRlOwogU1lTQ1RM X0lOVChfaHcsIE9JRF9BVVRPLCBjbG9ja3JhdGUsIENUTEZMQUdfUkQsCiAgICAgJmh3X2Nsb2Nr cmF0ZSwgMCwgIkNQVSBpbnN0cnVjdGlvbiBjbG9jayByYXRlIik7CiAKLXVfaW50IGh2X2hpZ2g7 Ci1jaGFyIGh2X3ZlbmRvclsxNl07Ci1TWVNDVExfU1RSSU5HKF9odywgT0lEX0FVVE8sIGh2X3Zl bmRvciwgQ1RMRkxBR19SRCwgaHZfdmVuZG9yLCAwLAotICAgICJIeXBlcnZpc29yIHZlbmRvciIp OwotCiBzdGF0aWMgZXZlbnRoYW5kbGVyX3RhZyB0c2NfcG9zdF90YWc7CiAKIHN0YXRpYyBjaGFy IGNwdV9icmFuZFs0OF07CkBAIC05ODUsNyArOTgwLDcgQEAgcHJpbnRjcHVpbmZvKHZvaWQpCiAj ZW5kaWYKIAl9CiAKLQlwcmludF9oeXBlcnZpc29yX2luZm8oKTsKKwloeXBlcnZpc29yX3ByaW50 X2luZm8oKTsKIH0KIAogdm9pZApAQCAtMTIxOCwyNSArMTIxMywxMiBAQCBpZGVudGlmeV9oeXBl cnZpc29yKHZvaWQpCiAJaW50IGk7CiAKIAkvKgotCSAqIFtSRkNdIENQVUlEIHVzYWdlIGZvciBp bnRlcmFjdGlvbiBiZXR3ZWVuIEh5cGVydmlzb3JzIGFuZCBMaW51eC4KLQkgKiBodHRwOi8vbGtt bC5vcmcvbGttbC8yMDA4LzEwLzEvMjQ2Ci0JICoKLQkgKiBLQjEwMDk0NTg6IE1lY2hhbmlzbXMg dG8gZGV0ZXJtaW5lIGlmIHNvZnR3YXJlIGlzIHJ1bm5pbmcgaW4KLQkgKiBhIFZNd2FyZSB2aXJ0 dWFsIG1hY2hpbmUKLQkgKiBodHRwOi8va2Iudm13YXJlLmNvbS9rYi8xMDA5NDU4CisJICogTW9k ZXJuIGh5cGVydmlzb3JzIHNldCB0aGUgSFYgcHJlc2VudCBmZWF0dXJlIGJpdCBhbmQgYXJlIHRo ZW4KKwkgKiBpZGVudGlmaWFibGUgdGhyb3VnaCBhIHNwZWNpYWwgQ1BVSUQgbGVhZi4gSHlwZXJ2 aXNvcnMgd2Uga25vdworCSAqIGFib3V0IGFyZSBsYXRlciBkZXRlY3RlZCB2aWEgdGhlIFNJX1NV Ql9IWVBFUlZJU09SIFNZU0lOSVQoKS4KIAkgKi8KIAlpZiAoY3B1X2ZlYXR1cmUyICYgQ1BVSUQy X0hWKSB7CiAJCXZtX2d1ZXN0ID0gVk1fR1VFU1RfVk07Ci0JCWRvX2NwdWlkKDB4NDAwMDAwMDAs IHJlZ3MpOwotCQlpZiAocmVnc1swXSA+PSAweDQwMDAwMDAwKSB7Ci0JCQlodl9oaWdoID0gcmVn c1swXTsKLQkJCSgodV9pbnQgKikmaHZfdmVuZG9yKVswXSA9IHJlZ3NbMV07Ci0JCQkoKHVfaW50 ICopJmh2X3ZlbmRvcilbMV0gPSByZWdzWzJdOwotCQkJKCh1X2ludCAqKSZodl92ZW5kb3IpWzJd ID0gcmVnc1szXTsKLQkJCWh2X3ZlbmRvclsxMl0gPSAnXDAnOwotCQkJaWYgKHN0cmNtcChodl92 ZW5kb3IsICJWTXdhcmVWTXdhcmUiKSA9PSAwKQotCQkJCXZtX2d1ZXN0ID0gVk1fR1VFU1RfVk1X QVJFOwotCQl9CiAJCXJldHVybjsKIAl9CiAKQEAgLTIxNTAsMTEgKzIxMzIsMyBAQCBwcmludF92 bXhfaW5mbyh2b2lkKQogCQkpOwogCX0KIH0KLQotc3RhdGljIHZvaWQKLXByaW50X2h5cGVydmlz b3JfaW5mbyh2b2lkKQotewotCi0JaWYgKCpodl92ZW5kb3IpCi0JCXByaW50ZigiSHlwZXJ2aXNv cjogT3JpZ2luID0gXCIlc1wiXG4iLCBodl92ZW5kb3IpOwotfQpkaWZmIC0tZ2l0IGEvc3lzL3g4 Ni94ODYva3ZtLmMgYi9zeXMveDg2L3g4Ni9rdm0uYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRl eCAwMDAwMDAwLi5iNDdlYjc2Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL3g4Ni94ODYva3ZtLmMK QEAgLTAsMCArMSw4MyBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVp Y2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisg KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0 aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAg ICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2Ns YWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1 Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRh dGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlv bi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENP TlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJB TlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1Ig T1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJ TkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElU VVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7 IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkg VEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFC SUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lO RyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisj aW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRl IDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2luY2x1ZGUgPG1hY2hp bmUvY3B1ZnVuYy5oPgorCisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4 ODYva3ZtLmg+CisKK3N0YXRpYyBpbnQJCWt2bV9jcHVpZF9pZGVudGlmeSh2b2lkKTsKKworc3Rh dGljIHVpbnQzMl90IGt2bV9jcHVpZF9iYXNlID0gLTE7CitzdGF0aWMgdWludDMyX3Qga3ZtX2Nw dWlkX2hpZ2ggPSAtMTsKKworc3RhdGljIGludAora3ZtX2NwdWlkX2lkZW50aWZ5KHZvaWQpCit7 CisKKwlpZiAoa3ZtX2NwdWlkX2Jhc2UgPT0gLTEpIHsKKwkJaHlwZXJ2aXNvcl9jcHVpZF9iYXNl KCJLVk1LVk1LVk1cMFwwIiwgMCwgJmt2bV9jcHVpZF9iYXNlLAorCQkgICAgJmt2bV9jcHVpZF9o aWdoKTsKKwl9CisKKwlyZXR1cm4gKGt2bV9jcHVpZF9iYXNlID4gMCk7Cit9CisKK2ludAora3Zt X3BhcmF2aXJ0X3N1cHBvcnRlZCh2b2lkKQoreworCisJcmV0dXJuIChrdm1fY3B1aWRfYmFzZSA+ IDApOworfQorCit1aW50MzJfdAora3ZtX2dldF9mZWF0dXJlcyh2b2lkKQoreworCXVfaW50IHJl Z3NbNF07CisKKwlpZiAoa3ZtX3BhcmF2aXJ0X3N1cHBvcnRlZCgpKQorCQlkb19jcHVpZChrdm1f Y3B1aWRfYmFzZSB8IEtWTV9DUFVJRF9GRUFUVVJFU19MRUFGLCByZWdzKTsKKwllbHNlCisJCXJl Z3NbMF0gPSAwOworCisJcmV0dXJuIChyZWdzWzBdKTsKK30KKworc3RhdGljIHZvaWQKK2t2bV9p bml0KHZvaWQpCit7CisKKwlpZiAoa3ZtX2NwdWlkX2lkZW50aWZ5KCkgIT0gMCkKKwkJaHlwZXJ2 aXNvcl9yZWdpc3RlcigiS1ZNIiwgVk1fR1VFU1RfS1ZNLCBOVUxMKTsKK30KKworSFlQRVJWSVNP Ul9TWVNJTklUKGt2bSwga3ZtX2luaXQpOwpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni94ODYva3ZtX2Ns b2NrLmMgYi9zeXMveDg2L3g4Ni9rdm1fY2xvY2suYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRl eCAwMDAwMDAwLi43ZGE2MzYzCi0tLSAvZGV2L251bGwKKysrIGIvc3lzL3g4Ni94ODYva3ZtX2Ns b2NrLmMKQEAgLTAsMCArMSwxMzIgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0IEJyeWFu IFZlbnRlaWNoZXIgPGJyeWFudkBGcmVlQlNELm9yZz4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQu CisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jt cywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlk ZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRp c3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdo dAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9m IGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRv Y3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0 cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9S IEFORCBDT05UUklCVVRPUlMgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQg V0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElF RCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFV VEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJF Q1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICog REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNV QlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJP RklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAq IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICov CisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2lu Y2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxz eXMvbGltaXRzLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisjaW5jbHVkZSA8c3lzL3BjcHUu aD4KKyNpbmNsdWRlIDxzeXMvc21wLmg+CisjaW5jbHVkZSA8c3lzL3RpbWV0Yy5oPgorCisjaW5j bHVkZSA8dm0vdm0uaD4KKyNpbmNsdWRlIDx2bS9wbWFwLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5l L3B2Y2xvY2suaD4KKyNpbmNsdWRlIDx4ODYva3ZtLmg+CisKK3N0YXRpYyB1X2ludAlrdm1fY2xv Y2tfZ2V0X3RpbWVjb3VudGVyKHN0cnVjdCB0aW1lY291bnRlciAqKTsKK3N0YXRpYyB2b2lkCWt2 bV9jbG9ja19wY3B1X3N5c3RlbV90aW1lKHZvaWQgKik7CisKK0RQQ1BVX0RFRklORShzdHJ1Y3Qg cHZjbG9ja192Y3B1X3RpbWVfaW5mbywga3ZtX2Nsb2NrX3ZjcHVfdGltZV9pbmZvKTsKKworc3Rh dGljIHN0cnVjdCB0aW1lY291bnRlciBrdm1fY2xvY2tfdGltZWNvdW50ZXIgPSB7CisJa3ZtX2Ns b2NrX2dldF90aW1lY291bnRlciwKKwlOVUxMLAorCX4wdSwKKwkxMDAwMDAwMDAwVUxMLAorCSJL Vk1DTE9DSyIsCisJMTAwMCwKK307CisKK3N0YXRpYyBpbnQJCWt2bV9jbG9ja19yZWdpc3RlcmVk Oworc3RhdGljIHVpbnQzMl90CQlrdm1fY2xvY2tfd2FsbF9jbG9ja19tc3I7CitzdGF0aWMgdWlu dDMyX3QJCWt2bV9jbG9ja19zeXN0ZW1fdGltZV9tc3I7CisKK3VpbnQ2NF90Citrdm1fY2xvY2tf dHNjX2ZyZXEodm9pZCkKK3sKKwlzdHJ1Y3QgcHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGk7CisJ dWludDY0X3QgZnJlcTsKKworCWNyaXRpY2FsX2VudGVyKCk7CisJdGkgPSBEUENQVV9QVFIoa3Zt X2Nsb2NrX3ZjcHVfdGltZV9pbmZvKTsKKwlmcmVxID0gcHZjbG9ja190c2NfZnJlcSh0aSk7CisJ Y3JpdGljYWxfZXhpdCgpOworCisJcmV0dXJuIChmcmVxKTsKK30KKworc3RhdGljIHVfaW50Citr dm1fY2xvY2tfZ2V0X3RpbWVjb3VudGVyKHN0cnVjdCB0aW1lY291bnRlciAqdGMpCit7CisJc3Ry dWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpOworCXVpbnQ2NF90IHRpbWU7CisKKwljcml0 aWNhbF9lbnRlcigpOworCXRpID0gRFBDUFVfUFRSKGt2bV9jbG9ja192Y3B1X3RpbWVfaW5mbyk7 CisJdGltZSA9IHB2Y2xvY2tfZ2V0X3RpbWVjb3VudCh0aSk7CisJY3JpdGljYWxfZXhpdCgpOwor CisJcmV0dXJuICh0aW1lICYgVUlOVF9NQVgpOworfQorCitzdGF0aWMgdm9pZAora3ZtX2Nsb2Nr X3BjcHVfc3lzdGVtX3RpbWUodm9pZCAqYXJnKQoreworCXVpbnQ2NF90IGRhdGE7CisJaW50IGVu YWJsZTsKKworCWVuYWJsZSA9ICooaW50ICopIGFyZzsKKworCWlmIChlbmFibGUgIT0gMCkKKwkJ ZGF0YSA9IHZ0b3BoeXMoRFBDUFVfUFRSKGt2bV9jbG9ja192Y3B1X3RpbWVfaW5mbykpIHwgMTsK KwllbHNlCisJCWRhdGEgPSAwOworCisJd3Jtc3Ioa3ZtX2Nsb2NrX3N5c3RlbV90aW1lX21zciwg ZGF0YSk7Cit9CisKK3N0YXRpYyB2b2lkCitrdm1fY2xvY2tfaW5pdCh2b2lkKQoreworCXVpbnQz Ml90IGZlYXR1cmVzOworCisJaWYgKHZtX2d1ZXN0ICE9IFZNX0dVRVNUX0tWTSB8fCAha3ZtX3Bh cmF2aXJ0X3N1cHBvcnRlZCgpKQorCQlyZXR1cm47CisKKwlmZWF0dXJlcyA9IGt2bV9nZXRfZmVh dHVyZXMoKTsKKworCWlmIChmZWF0dXJlcyAmIEtWTV9GRUFUVVJFX0NMT0NLU09VUkNFMikgewor CQlrdm1fY2xvY2tfd2FsbF9jbG9ja19tc3IgPSBLVk1fTVNSX1dBTExfQ0xPQ0tfTkVXOworCQlr dm1fY2xvY2tfc3lzdGVtX3RpbWVfbXNyID0gS1ZNX01TUl9TWVNURU1fVElNRV9ORVc7CisJfSBl bHNlIGlmIChmZWF0dXJlcyAmIEtWTV9GRUFUVVJFX0NMT0NLU09VUkNFKSB7CisJCWt2bV9jbG9j a193YWxsX2Nsb2NrX21zciA9IEtWTV9NU1JfV0FMTF9DTE9DSzsKKwkJa3ZtX2Nsb2NrX3N5c3Rl bV90aW1lX21zciA9IEtWTV9NU1JfU1lTVEVNX1RJTUU7CisJfSBlbHNlCisJCXJldHVybjsKKwor CWt2bV9jbG9ja19yZWdpc3RlcmVkID0gMTsKKwlzbXBfcmVuZGV6dm91cyhzbXBfbm9fcmVuZGV2 b3VzX2JhcnJpZXIsIGt2bV9jbG9ja19wY3B1X3N5c3RlbV90aW1lLAorCSAgICBzbXBfbm9fcmVu ZGV2b3VzX2JhcnJpZXIsICZrdm1fY2xvY2tfcmVnaXN0ZXJlZCk7CisKKwl0Y19pbml0KCZrdm1f Y2xvY2tfdGltZWNvdW50ZXIpOworfQorCitTWVNJTklUKGt2bV9jbG9jaywgU0lfU1VCX1NNUCwg U0lfT1JERVJfQU5ZLCBrdm1fY2xvY2tfaW5pdCwgTlVMTCk7CmRpZmYgLS1naXQgYS9zeXMveDg2 L3g4Ni9wdmNsb2NrLmMgYi9zeXMveDg2L3g4Ni9wdmNsb2NrLmMKbmV3IGZpbGUgbW9kZSAxMDA2 NDQKaW5kZXggMDAwMDAwMC4uZDBlZWYxODUKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4 Ni9wdmNsb2NrLmMKQEAgLTAsMCArMSwxOTcgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDA5 IEFkcmlhbiBDaGFkZAorICogQ29weXJpZ2h0IChjKSAyMDEyIFNwZWN0cmEgTG9naWMgQ29ycG9y YXRpb24KKyAqIENvcHlyaWdodCAoYykgMjAxNCBCcnlhbiBWZW50ZWljaGVyCisgKiBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBS RVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8s IFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZF TlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5Z IERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09O U0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBS T0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZF UiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0Ug T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNV Q0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJl ZUJTRCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5o PgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2NwdWZ1bmMuaD4K KyNpbmNsdWRlIDxtYWNoaW5lL2NwdS5oPgorI2luY2x1ZGUgPG1hY2hpbmUvYXRvbWljLmg+Cisj aW5jbHVkZSA8bWFjaGluZS9wdmNsb2NrLmg+CisKKy8qCisgKiBMYXN0IHRpbWU7IHRoaXMgZ3Vh cmFudGVlcyBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jayBmb3Igd2hlbgorICogYSBz dGFibGUgVFNDIGlzIG5vdCBwcm92aWRlZC4KKyAqLworc3RhdGljIHZvbGF0aWxlIHVpbnQ2NF90 IHB2Y2xvY2tfbGFzdF9jeWNsZXM7CisKK3ZvaWQKK3B2Y2xvY2tfcmVzdW1lKHZvaWQpCit7CisK KwlhdG9taWNfc3RvcmVfcmVsXzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVzLCAwKTsKK30KKwordWlu dDY0X3QKK3B2Y2xvY2tfdHNjX2ZyZXEoc3RydWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRp KQoreworCXVpbnQ2NF90IGZyZXE7CisKKwlmcmVxID0gKDEwMDAwMDAwMDBVTEwgPDwgMzIpIC8g dGktPnRzY190b19zeXN0ZW1fbXVsOworCisJaWYgKHRpLT50c2Nfc2hpZnQgPCAwKQorCQlmcmVx IDw8PSAtdGktPnRzY19zaGlmdDsKKwllbHNlCisJCWZyZXEgPj49IHRpLT50c2Nfc2hpZnQ7CisK KwlyZXR1cm4gKGZyZXEpOworfQorCisvKgorICogU2NhbGUgYSA2NC1iaXQgZGVsdGEgYnkgc2Nh bGluZyBhbmQgbXVsdGlwbHlpbmcgYnkgYSAzMi1iaXQgZnJhY3Rpb24sCisgKiB5aWVsZGluZyBh IDY0LWJpdCByZXN1bHQuCisgKi8KK3N0YXRpYyBpbmxpbmUgdWludDY0X3QKK3B2Y2xvY2tfc2Nh bGVfZGVsdGEodWludDY0X3QgZGVsdGEsIHVpbnQzMl90IG11bF9mcmFjLCBpbnQgc2hpZnQpCit7 CisJdWludDY0X3QgcHJvZHVjdDsKKworCWlmIChzaGlmdCA8IDApCisJCWRlbHRhID4+PSAtc2hp ZnQ7CisJZWxzZQorCQlkZWx0YSA8PD0gc2hpZnQ7CisKKyNpZiBkZWZpbmVkKF9faTM4Nl9fKQor CXsKKwkJdWludDMyX3QgdG1wMSwgdG1wMjsKKworCQkvKioKKwkJICogRm9yIGkzODYsIHRoZSBm b3JtdWxhIGxvb2tzIGxpa2U6CisJCSAqCisJCSAqICAgbG93ZXIgPSAobXVsX2ZyYWMgKiAoZGVs dGEgJiBVSU5UX01BWCkpID4+IDMyCisJCSAqICAgdXBwZXIgPSBtdWxfZnJhYyAqIChkZWx0YSA+ PiAzMikKKwkJICogICBwcm9kdWN0ID0gbG93ZXIgKyB1cHBlcgorCQkgKi8KKwkJX19hc21fXyAo CisJCQkibXVsICAlNSAgICAgICA7ICIKKwkJCSJtb3YgICU0LCUlZWF4IDsgIgorCQkJIm1vdiAg JSVlZHgsJTQgOyAiCisJCQkibXVsICAlNSAgICAgICA7ICIKKwkJCSJ4b3IgICU1LCU1ICAgIDsg IgorCQkJImFkZCAgJTQsJSVlYXggOyAiCisJCQkiYWRjICAlNSwlJWVkeCA7ICIKKwkJCTogIj1B IiAocHJvZHVjdCksICI9ciIgKHRtcDEpLCAiPXIiICh0bXAyKQorCQkJOiAiYSIgKCh1aW50MzJf dClkZWx0YSksICIxIiAoKHVpbnQzMl90KShkZWx0YSA+PiAzMikpLAorCQkJICAiMiIgKG11bF9m cmFjKSApOworCX0KKyNlbGlmIGRlZmluZWQoX19hbWQ2NF9fKQorCXsKKwkJdW5zaWduZWQgbG9u ZyB0bXA7CisKKwkJX19hc21fXyAoCisJCQkibXVscSAlW211bF9mcmFjXSA7IHNocmQgJDMyLCAl W2hpXSwgJVtsb10iCisJCQk6IFtsb10iPWEiIChwcm9kdWN0KSwgW2hpXSI9ZCIgKHRtcCkKKwkJ CTogIjAiIChkZWx0YSksIFttdWxfZnJhY10icm0iKCh1aW50NjRfdCltdWxfZnJhYykpOworCX0K KyNlbHNlCisjZXJyb3IgInB2Y2xvY2s6IHVuc3VwcG9ydGVkIHg4NiBhcmNoaXRlY3R1cmU/Igor I2VuZGlmCisKKwlyZXR1cm4gKHByb2R1Y3QpOworfQorCitzdGF0aWMgdWludDY0X3QKK3B2Y2xv Y2tfZ2V0X25zZWNfb2Zmc2V0KHN0cnVjdCBwdmNsb2NrX3ZjcHVfdGltZV9pbmZvICp0aSkKK3sK Kwl1aW50NjRfdCBkZWx0YTsKKworCWRlbHRhID0gcmR0c2MoKSAtIHRpLT50c2NfdGltZXN0YW1w OworCisJcmV0dXJuIChwdmNsb2NrX3NjYWxlX2RlbHRhKGRlbHRhLCB0aS0+dHNjX3RvX3N5c3Rl bV9tdWwsCisJICAgIHRpLT50c2Nfc2hpZnQpKTsKK30KKworc3RhdGljIHZvaWQKK3B2Y2xvY2tf cmVhZF90aW1lX2luZm8oc3RydWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpLAorICAgIHVp bnQ2NF90ICpjeWNsZXMsIHVpbnQ4X3QgKmZsYWdzKQoreworCXVpbnQzMl90IHZlcnNpb247CisK KwlkbyB7CisJCXZlcnNpb24gPSB0aS0+dmVyc2lvbjsKKwkJcm1iKCk7CisJCSpjeWNsZXMgPSB0 aS0+c3lzdGVtX3RpbWUgKyBwdmNsb2NrX2dldF9uc2VjX29mZnNldCh0aSk7CisJCSpmbGFncyA9 IHRpLT5mbGFnczsKKwkJcm1iKCk7CisJfSB3aGlsZSAoKHRpLT52ZXJzaW9uICYgMSkgIT0gMCB8 fCB0aS0+dmVyc2lvbiAhPSB2ZXJzaW9uKTsKK30KKworc3RhdGljIHZvaWQKK3B2Y2xvY2tfcmVh ZF93YWxsX2Nsb2NrKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKndjLCB1aW50MzJfdCAqc2Vj LAorICAgIHVpbnQzMl90ICpuc2VjKQoreworCXVpbnQzMl90IHZlcnNpb247CisKKwlkbyB7CisJ CXZlcnNpb24gPSB3Yy0+dmVyc2lvbjsKKwkJcm1iKCk7CisJCSpzZWMgPSB3Yy0+c2VjOworCQkq bnNlYyA9IHdjLT5uc2VjOworCQlybWIoKTsKKwl9IHdoaWxlICgod2MtPnZlcnNpb24gJiAxKSAh PSAwIHx8IHdjLT52ZXJzaW9uICE9IHZlcnNpb24pOworfQorCit1aW50NjRfdAorcHZjbG9ja19n ZXRfdGltZWNvdW50KHN0cnVjdCBwdmNsb2NrX3ZjcHVfdGltZV9pbmZvICp0aSkKK3sKKwl1aW50 NjRfdCBub3c7CisJdWludDhfdCBmbGFnczsKKwl2b2xhdGlsZSB1aW50NjRfdCBsYXN0OworCisJ cHZjbG9ja19yZWFkX3RpbWVfaW5mbyh0aSwgJm5vdywgJmZsYWdzKTsKKworCWlmIChmbGFncyAm IFBWQ0xPQ0tfRkxBR19UU0NfU1RBQkxFKQorCQlyZXR1cm4gKG5vdyk7CisKKwkvKgorCSAqIEVu Zm9yY2UgYSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgY2xvY2sgdGltZSBhY3Jvc3MgYWxsIFZD UFVzLgorCSAqIElmIG91ciB0aW1lIGlzIHRvbyBvbGQsIHVzZSB0aGUgbGFzdCB0aW1lIGFuZCBy ZXR1cm4uIE90aGVyd2lzZSwKKwkgKiB0cnkgdG8gdXBkYXRlIHRoZSBsYXN0IHRpbWUuCisJICov CisJZG8geworCQlsYXN0ID0gYXRvbWljX2xvYWRfYWNxXzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVz KTsKKwkJaWYgKGxhc3QgPiBub3cpCisJCQlyZXR1cm4gKGxhc3QpOworCX0gd2hpbGUgKCFhdG9t aWNfY21wc2V0XzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVzLCBsYXN0LCBub3cpKTsKKworCXJldHVy biAobm93KTsKK30KKwordm9pZAorcHZjbG9ja19nZXRfd2FsbGNsb2NrKHN0cnVjdCBwdmNsb2Nr X3dhbGxfY2xvY2sgKndjLCBzdHJ1Y3QgdGltZXNwZWMgKnRzKQoreworCXVpbnQzMl90IHNlYywg bnNlYzsKKworCXB2Y2xvY2tfcmVhZF93YWxsX2Nsb2NrKHdjLCAmc2VjLCAmbnNlYyk7CisJdHMt PnR2X3NlYyA9IHNlYzsKKwl0cy0+dHZfbnNlYyA9IG5zZWM7Cit9CmRpZmYgLS1naXQgYS9zeXMv eDg2L3g4Ni90c2MuYyBiL3N5cy94ODYveDg2L3RzYy5jCmluZGV4IDRjYTU3NGUuLmE4MzRjYjUg MTAwNjQ0Ci0tLSBhL3N5cy94ODYveDg2L3RzYy5jCisrKyBiL3N5cy94ODYveDg2L3RzYy5jCkBA IC0xMDQsMjIgKzEwNCw2IEBAIHN0YXRpYyBzdHJ1Y3QgdGltZWNvdW50ZXIgdHNjX3RpbWVjb3Vu dGVyID0gewogfTsKIAogc3RhdGljIHZvaWQKLXRzY19mcmVxX3Ztd2FyZSh2b2lkKQotewotCXVf aW50IHJlZ3NbNF07Ci0KLQlpZiAoaHZfaGlnaCA+PSAweDQwMDAwMDEwKSB7Ci0JCWRvX2NwdWlk KDB4NDAwMDAwMTAsIHJlZ3MpOwotCQl0c2NfZnJlcSA9IHJlZ3NbMF0gKiAxMDAwOwotCX0gZWxz ZSB7Ci0JCXZtd2FyZV9odmNhbGwoVk1XX0hWQ01EX0dFVEhaLCByZWdzKTsKLQkJaWYgKHJlZ3Nb MV0gIT0gVUlOVF9NQVgpCi0JCQl0c2NfZnJlcSA9IHJlZ3NbMF0gfCAoKHVpbnQ2NF90KXJlZ3Nb MV0gPDwgMzIpOwotCX0KLQl0c2NfaXNfaW52YXJpYW50ID0gMTsKLX0KLQotc3RhdGljIHZvaWQK IHRzY19mcmVxX2ludGVsKHZvaWQpCiB7CiAJY2hhciBicmFuZFs0OF07CkBAIC0yMDEsNyArMTg1 LDggQEAgcHJvYmVfdHNjX2ZyZXEodm9pZCkKIAl9CiAKIAlpZiAodm1fZ3Vlc3QgPT0gVk1fR1VF U1RfVk1XQVJFKSB7Ci0JCXRzY19mcmVxX3Ztd2FyZSgpOworCQl0c2NfZnJlcSA9IHZtd2FyZV90 c2NfZnJlcSgpOworCQl0c2NfaXNfaW52YXJpYW50ID0gMTsKIAkJcmV0dXJuOwogCX0KIApkaWZm IC0tZ2l0IGEvc3lzL3g4Ni94ODYvdm13YXJlLmMgYi9zeXMveDg2L3g4Ni92bXdhcmUuYwpuZXcg ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5lMTZhY2JiCi0tLSAvZGV2L251bGwKKysr IGIvc3lzL3g4Ni94ODYvdm13YXJlLmMKQEAgLTAsMCArMSw4NCBAQAorLyotCisgKiBDb3B5cmln aHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxs IHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJl IG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0 aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4g YmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy IGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3Zp ZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJ REVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkg RVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJ VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5P IEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9S IEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9S IENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhP V0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBD T05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdF TkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBP RiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisg KiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgi JEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvc3lz dG0uaD4KKyNpbmNsdWRlIDxzeXMvbGltaXRzLmg+CisKKyNpbmNsdWRlIDx4ODYvaHlwZXJ2aXNv ci5oPgorI2luY2x1ZGUgPHg4Ni92bXdhcmUuaD4KKworc3RhdGljIHVpbnQzMl90IHZtd2FyZV9j cHVpZF9iYXNlID0gLTE7CitzdGF0aWMgdWludDMyX3Qgdm13YXJlX2NwdWlkX2hpZ2ggPSAtMTsK Kworc3RhdGljIGludAordm13YXJlX2NwdWlkX2lkZW50aWZ5KHZvaWQpCit7CisKKwkvKgorCSAq IEtCMTAwOTQ1ODogTWVjaGFuaXNtcyB0byBkZXRlcm1pbmUgaWYgc29mdHdhcmUgaXMgcnVubmlu ZyBpbiBhCisJICogVk13YXJlIHZpcnR1YWwgbWFjaGluZTogaHR0cDovL2tiLnZtd2FyZS5jb20v a2IvMTAwOTQ1OAorCSAqLworCWlmICh2bXdhcmVfY3B1aWRfYmFzZSA9PSAtMSkgeworCQloeXBl cnZpc29yX2NwdWlkX2Jhc2UoIlZNd2FyZVZNd2FyZSIsIDAsICZ2bXdhcmVfY3B1aWRfYmFzZSwK KwkJICAgICZ2bXdhcmVfY3B1aWRfaGlnaCk7CisJfQorCisJcmV0dXJuICh2bXdhcmVfY3B1aWRf YmFzZSA+IDApOworfQorCit1aW50NjRfdAordm13YXJlX3RzY19mcmVxKHZvaWQpCit7CisJdWlu dDY0X3QgZnJlcTsKKwl1X2ludCByZWdzWzRdOworCisJaWYgKHZtd2FyZV9jcHVpZF9oaWdoID49 IDB4NDAwMDAwMTApIHsKKwkJZG9fY3B1aWQoMHg0MDAwMDAxMCwgcmVncyk7CisJCWZyZXEgPSBy ZWdzWzBdICogMTAwMDsKKwl9IGVsc2UgeworCQl2bXdhcmVfaHZjYWxsKFZNV19IVkNNRF9HRVRI WiwgcmVncyk7CisJCWlmIChyZWdzWzFdICE9IFVJTlRfTUFYKQorCQkJZnJlcSA9IHJlZ3NbMF0g fCAoKHVpbnQ2NF90KXJlZ3NbMV0gPDwgMzIpOworCQllbHNlCisJCQlmcmVxID0gMDsKKwl9CisK KwlyZXR1cm4gKGZyZXEpOworfQorCitzdGF0aWMgdm9pZAordm13YXJlX2luaXQodm9pZCkKK3sK KworCWlmICh2bXdhcmVfY3B1aWRfaWRlbnRpZnkoKSAhPSAwKQorCQloeXBlcnZpc29yX3JlZ2lz dGVyKCJWTXdhcmUiLCBWTV9HVUVTVF9WTVdBUkUsIE5VTEwpOworfQorCitIWVBFUlZJU09SX1NZ U0lOSVQodm13YXJlLCB2bXdhcmVfaW5pdCk7Cg== --001a11425fb46ce52b050bd74b4a-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 18:58:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C6E6FD; Sun, 4 Jan 2015 18:58:56 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D718BC5; Sun, 4 Jan 2015 18:58:56 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u56so6828619wes.2; Sun, 04 Jan 2015 10:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lj6uNzZ5qyAiIDb22ODPg/1yflQdnaoZogrV9T//nDs=; b=p8rn4vJ0Yt9kiRQdfWpELDgollVxo2UdLbIU0MmpiRcAyzf65gIDPd/Sj9istgVqoP Bd3tHFrTk9W38/eaw4sTmCZTu0dR03UwgMUMiGtNe4w5j9qr4TM6I/Dg/pRa16D3Z6Ou +LwWCKhuWIZFb+D9DDzCYpPh6TtmxSlId9A/Xe7PS2KfVVAaT94SP9IzSP/uDr4I1voZ u6wsHu1p06dv7rlgtyEK7lzgkNNQiRW3b3Y1czrHongybP0ReDeerLPb9bZYcfK19NUF 8IW+geFCBdYngxbEoFuLL5PwIyXCKS7EpTbBKyL4D4cfIb3e1zlbKf/O7MNmS+XblT8E 2sLw== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr50584701wjp.20.1420397934515; Sun, 04 Jan 2015 10:58:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sun, 4 Jan 2015 10:58:54 -0800 (PST) In-Reply-To: <54A92ED1.2070906@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> Date: Sun, 4 Jan 2015 10:58:54 -0800 X-Google-Sender-Auth: zPrMzqvbPxhpXxB-ysT2PDMSxIY Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Ivan Klymenko , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 18:58:56 -0000 Hi! Can you throw this into reviews.freebsd.org please? This is something that should be very closely reviewed and tested. (I'm going to go over this quite closely as it related to a lot of the random crap I do ..) -adrian On 4 January 2015 at 04:15, Hans Petter Selasky wrote: > Hi, > > Please find attached an updated timeout patch which also updates clients in > the kernel area to use the callout API properly, like cv_timedwait(). > Previously there was some custom sleepqueue code in the callout subsystem. > All of that has now been removed and we allow callouts to be protected by > spinlocks. This allows us to tear down the callback like done with regular > mutexes, and a "td_slpmutex" has been added to "struct thread" to atomically > teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and > "SWT_SLEEPQTIMO" states can now be completely removed. > > Summary of changes: > > 1) Make consistent callout API which also supports spinlocks for the > callback function. This has been done to allow atomic callout stop of > "td_slpcallout" without the need of many kernel threading quirks. > > 2) It is not allowed to migrate CPU if the timeout is restarted while the > timeout callback is executing. Callouts must be stopped before CPU migration > is allowed. Optionally drained. > > 3) Shared lock support has been removed, because it prevents atomic stop of > the callback function. > > 4) A new API to drain callouts asynchronously has been added, called > "callout_drain_async()". > > Please test and report any errors! > > Patch applies to FreeBSD-11-current as of today. > > Thank you! > > --HPS > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 19:00:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 396373E8; Sun, 4 Jan 2015 19:00:52 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0038BFF; Sun, 4 Jan 2015 19:00:51 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so26400090wgg.5; Sun, 04 Jan 2015 11:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=r9Jjxl4IBQeMusxhS2QvouJHSLOShUwuWSjeAieLjpU=; b=Q91lWExQMe09Vzn7uL1vG9IIv9noofo4QyylXYARcuzsC9COj6kqZhBcJKghg1Uti8 vkXmS9A+nleU4fw0ZBenH6FyhGtzCUpfOXNH2oo+uO0qDlqu5e190JvqgE3rYvwsvPht dzeOx5nxm+xJVwwvmB52WPp10U+0mMpj1dltPCfnVtFFoirjg9hbVyXp070IXJZnvZG3 Qsh6i9r1XUsXHcl8iScYKeOfVAM5aAX+cWnv+Uo7aiEvSJuKbplx86Vvi17qSyezUZ2R y2XkIYKwsMLYAkgXERuhLTJE2XID5eBuZslFpXioqXH5VR7SUKyM9OKbhmLJjt32heiF E/YQ== MIME-Version: 1.0 X-Received: by 10.180.14.136 with SMTP id p8mr18159102wic.20.1420398050052; Sun, 04 Jan 2015 11:00:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sun, 4 Jan 2015 11:00:49 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Jan 2015 11:00:49 -0800 X-Google-Sender-Auth: SmBt7x2ob9AwSZZGjIXV4ldzyeA Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock From: Adrian Chadd To: Bryan Venteicher Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:00:52 -0000 ... so, out of pure curiousity - what's making the benchmark go faster? Is it userland side of things calling clock methods, or something in the kernel, or both? -adrian On 4 January 2015 at 09:56, Bryan Venteicher wrote: > For the last few weeks, I've been working on adding support for KVM clock > in the projects/paravirt branch. Currently, a KVM VM guest will end up > selecting either the HPET or ACPI as the timecounter source. Unfortunately, > this is very costly since every timecounter fetch causes a VM exit. KVM > clock allows the guest to use the TSC instead; it is very similar to the > existing Xen timer. > > The performance difference between HPET/ACPI and KVMCLOCK can be dramatic: > a simple disk benchmark goes from 10K IOPs to 100K IOPs. > > The patch is attached is attached or available at [1]. I'd appreciate any > testing. > > Also as a part of this, I've tried to generalized a bit of our existing > hypervisor guest code, with the eventual goal of being able to support more > invasive PV operations. The patch series is viewable in Phabricator. > > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the XEN > timer code into pvclock > https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate > the TSC frequency from pvclock > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor > registration and detection interface > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve using > new hypervisor interface > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware using > new hypervisor interface > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using > new hypervisor interface > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter > support > > My current plan is to MFC this series to 10-STABLE, and commit a > self-contained KVM clock to the other stable branches. > > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 20:47:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A276DE15; Sun, 4 Jan 2015 20:47:45 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6031C64C8E; Sun, 4 Jan 2015 20:47:45 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 21E3D1FE022; Sun, 4 Jan 2015 21:47:43 +0100 (CET) Message-ID: <54A9A71E.70609@selasky.org> Date: Sun, 04 Jan 2015 21:48:30 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ivan Klymenko , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 20:47:45 -0000 On 01/04/15 19:58, Adrian Chadd wrote: > Hi! > > Can you throw this into reviews.freebsd.org please? This is something > that should be very closely reviewed and tested. > > (I'm going to go over this quite closely as it related to a lot of the > random crap I do ..) > Hi Adrian, Here you go: https://reviews.freebsd.org/D1438 Thank you for your time to review this! --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 21:04:42 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93CE23FD; Sun, 4 Jan 2015 21:04:42 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5845964F94; Sun, 4 Jan 2015 21:04:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9D07E7300A; Sun, 4 Jan 2015 22:09:19 +0100 (CET) Date: Sun, 4 Jan 2015 22:09:19 +0100 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org, tegge@freebsd.org Subject: BOOTP_SETTLE_DELAY in sys/nfs/bootp_subr.c ? Message-ID: <20150104210919.GA22198@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 21:04:42 -0000 [I realize this is code from 15 years ago so i am not sure if anyone still knows or remembers the answer] sys/nfs/bootp_subr.c is used to request via bootp or dhcp an address and a boot path. The negotiation is done in a loop, and apparently when replies are received on _all_ interfaces, the code extends the loop by another 3 seconds (BOOTP_SETTLE_DELAY) with a logic that is not documented and I do not follow. Any idea ? I would understand not stopping at the first reply in case we want to pick the 'best' one from multiple responses (which is implemented, to some degree, in bootpc_received() ). But if that is the case, one should either 1) use an unconditionally large timeout, or 2) take the first incoming packet (not necessarily valid) on _any_ interface as a signal that "ok this interface is now on" and apply the grace period from there. Why do i care ? I am booting a diskless kernel with bhyve and BOOTP_SETTLE_DELAY unnecessarily extends the boot time a lot, and even worse delays happen if you have multiple interfaces that do not respond due to some other unclear logic. Depending on what is the original intention i would like to implement either option #1 or #2 above. Also, I would like to use environment variables to set/override the in-kernel bootp settings cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Jan 4 21:28:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1DC48FE; Sun, 4 Jan 2015 21:28:40 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B21BF1308; Sun, 4 Jan 2015 21:28:40 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6D98F7300B; Sun, 4 Jan 2015 22:33:25 +0100 (CET) Date: Sun, 4 Jan 2015 22:33:25 +0100 From: Luigi Rizzo To: Neel Natu Subject: Re: any primer on running bhyve guests sharing disk with host ? Message-ID: <20150104213325.GB22198@onelab2.iet.unipi.it> References: <20150103161511.GA94237@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD current , Neel Natu , Peter Grehan X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 21:28:41 -0000 On Sat, Jan 03, 2015 at 11:00:13AM -0800, Neel Natu wrote: > Hi Luigi, > > On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo wrote: > > Hi, > > in order to do some kernel testing, I would like to run bhyve guests > > using (through NFS, probably) the host's file system. > > diskless(8) is probably one way to go, i was wondering if > > someone has instructions for that. > > Specifically: > > - how to "bhyveload" a kernel (rather than the full disk image); > > as an alternative, given a kernel, something to build an image > > that can be passed to bhyveload > > > > You can use the "-h" option to bhyveload(8) to do this. thank you, i have it up and running now. For the records this is what I am using: sudo bhyveload -m 512 -h /tmp/diskless vm1 and in /tmp/diskless i have the following: boot/ loader.rc: set hint.uart.0.at="isa" set hint.uart.0.port="0x3F8" set hint.uart.0.flags="0x10" set vfs.root.mountfrom=nfs:192.168.1.126:/ boot /boot/kernel.diskless kernel.diskless The 'set' commands in loader.rc are enough to have the serial console detected and the root path. They could be given through -e options to bhyveload so in the end you only need to put a suitable kernel into /some/place/boot/kernel/kernel and call bhyveload -h /some/place -e hint.uart.0.at=isa ... Current issues which I am investigating: - for some reason the guest sends packets with invalid UDP checksums over vtnet0, which can be solved by removing (in if_vtnet.c) TXCSUM from if_capenable. - when using NFS root there seems to be no way to avoid the dhcp phase, which is unfortunate because it adds unnecessary delays to the boot. This can be probably fixed easily because there are already kenv variables (boot.netif.name and friends) for the purpose. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 02:01:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AC4D903; Mon, 5 Jan 2015 02:01:20 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 339A964C84; Mon, 5 Jan 2015 02:01:20 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id id10so8066973vcb.19; Sun, 04 Jan 2015 18:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t7rMM6MMyKZFrTvYCUE4IflJQSpSfmYn1gqwyUyMM0Q=; b=NZ9E4zhnSxuttyW0aweyKKsFLYBL/8uso8gWUqhvSJsV80nwCHAmFio/hlS4IPM0Fc xeGZBY5qU+VoA8Nj60gTLyonAL4B7n8GRVvkrP05yhVpTUkpGkkk2ZYR2FMKq/DGa/Lz L11fSk/4BXFjugEyv6u0LygRotfAZCsmi9YApIZKrNcsPxiuPmRLStRQE1b9Z2bKWxGk Ji48urfh+s8iQtb1gHtQMFd+GN6nfmLMR/j3yHg4N6x1ohzQf3P5KarMpxooaoJrGzqm 9FkJVn20qJYcrYqEVk+ZhyNHXcM1ucGLrrix+NYBq8EXEwNhF08HOtFBTEp04p+11cEi r+Cw== MIME-Version: 1.0 X-Received: by 10.52.66.200 with SMTP id h8mr46352692vdt.97.1420423279034; Sun, 04 Jan 2015 18:01:19 -0800 (PST) Received: by 10.52.117.108 with HTTP; Sun, 4 Jan 2015 18:01:18 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Jan 2015 19:01:18 -0700 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock From: Jim Harris To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-current , Bryan Venteicher , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 02:01:20 -0000 On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd wrote: > ... so, out of pure curiousity - what's making the benchmark go > faster? Is it userland side of things calling clock methods, or > something in the kernel, or both? > > Most likely GEOM statistic gathering in the kernel but Bryan would have to confirm. I intermittently saw this same kind of massive slowdown in nvme(4) performance a couple of years back due to a bug in the TSC self-check code which has since been fixed. The bug would result in falling back to HPET and all of the clock calls from the GEOM code for each I/O would kill performance. > > -adrian > > > On 4 January 2015 at 09:56, Bryan Venteicher > wrote: > > For the last few weeks, I've been working on adding support for KVM clock > > in the projects/paravirt branch. Currently, a KVM VM guest will end up > > selecting either the HPET or ACPI as the timecounter source. > Unfortunately, > > this is very costly since every timecounter fetch causes a VM exit. KVM > > clock allows the guest to use the TSC instead; it is very similar to the > > existing Xen timer. > > > > The performance difference between HPET/ACPI and KVMCLOCK can be > dramatic: > > a simple disk benchmark goes from 10K IOPs to 100K IOPs. > > > > The patch is attached is attached or available at [1]. I'd appreciate any > > testing. > > > > Also as a part of this, I've tried to generalized a bit of our existing > > hypervisor guest code, with the eventual goal of being able to support > more > > invasive PV operations. The patch series is viewable in Phabricator. > > > > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the > XEN > > timer code into pvclock > > https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate > > the TSC frequency from pvclock > > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor > > registration and detection interface > > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve > using > > new hypervisor interface > > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware > using > > new hypervisor interface > > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using > > new hypervisor interface > > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter > > support > > > > My current plan is to MFC this series to 10-STABLE, and commit a > > self-contained KVM clock to the other stable branches. > > > > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch > > > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 04:49:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEFD2BDD for ; Mon, 5 Jan 2015 04:49:50 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6F6F19DE for ; Mon, 5 Jan 2015 04:49:50 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id h15so1936931igd.13 for ; Sun, 04 Jan 2015 20:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=19nMuSJjgms/sP+RScuQsC3HdrI3WazmNhVjDevVAgI=; b=S1CzRK5hqgNFxB2DXfx57hBlxuu6M4IaypD9nban6ATeRh8GFS+xxdWIyMZDiN0GnL 2ZOTUbN2a331wgoSnQEpn71WNAAprJEmN61WrydAlSebOm313bfXSCafoFQ98tAiC70L Q5ApOTG+kySX/xvW9p+uTrEEvBsmcFLV+sa2x9Kq0w9KbNopVkAszg6IJL4ZbT9NZgdA dh8MKmggAW/jEfpke3k1Rs+FjfwzPRwDQKLqhxB0Q2mfvXJdZNE1+qkmrjHkGJUsjkWx F9Sf+RZGQtk+QoLgrOf2MkUkeTNNVz3og7BzPo/BC89pDAlfradFhM5HLGhXa+yJT87d bRNA== X-Gm-Message-State: ALoCoQnBWCUViHYJP1CxqoaRqBc5pcCJPUKxkw00FWMWjwcPvJ6oO6w5/omYPj6hoVhsxiNmiU2m X-Received: by 10.50.7.34 with SMTP id g2mr9297153iga.36.1420433383960; Sun, 04 Jan 2015 20:49:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.217 with HTTP; Sun, 4 Jan 2015 20:49:23 -0800 (PST) X-Originating-IP: [72.177.7.16] In-Reply-To: References: From: Bryan Venteicher Date: Sun, 4 Jan 2015 22:49:23 -0600 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock To: Jim Harris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:49:51 -0000 On Sun, Jan 4, 2015 at 8:01 PM, Jim Harris wrote: > > > On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd wrote: > >> ... so, out of pure curiousity - what's making the benchmark go >> faster? Is it userland side of things calling clock methods, or >> something in the kernel, or both? >> >> > Most likely GEOM statistic gathering in the kernel but Bryan would have t= o > confirm. > > Yes =E2=80=8B - t=E2=80=8B hat's the main =E2=80=8B source=E2=80=8B . A similar issue exists in the network stack =E2=80=8BBPF.=E2=80=8B I haven't looked or thought too much if it make sense / is possible to use kvmclock in userland too (I think kib@ added fast gettimeofday & friends support a few years back). I intermittently saw this same kind of massive slowdown in nvme(4) > performance a couple of years back due to a bug in the TSC self-check cod= e > which has since been fixed. The bug would result in falling back to HPET > and all of the clock calls from the GEOM code for each I/O would kill > performance. > > >> >> -adrian >> >> >> On 4 January 2015 at 09:56, Bryan Venteicher >> wrote: >> > For the last few weeks, I've been working on adding support for KVM >> clock >> > in the projects/paravirt branch. Currently, a KVM VM guest will end up >> > selecting either the HPET or ACPI as the timecounter source. >> Unfortunately, >> > this is very costly since every timecounter fetch causes a VM exit. KV= M >> > clock allows the guest to use the TSC instead; it is very similar to t= he >> > existing Xen timer. >> > >> > The performance difference between HPET/ACPI and KVMCLOCK can be >> dramatic: >> > a simple disk benchmark goes from 10K IOPs to 100K IOPs. >> > >> > The patch is attached is attached or available at [1]. I'd appreciate >> any >> > testing. >> > >> > Also as a part of this, I've tried to generalized a bit of our existin= g >> > hypervisor guest code, with the eventual goal of being able to support >> more >> > invasive PV operations. The patch series is viewable in Phabricator. >> > >> > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the >> XEN >> > timer code into pvclock >> > https://reviews.freebsd.org/D1430 - paravirt: Add interface to >> calculate >> > the TSC frequency from pvclock >> > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor >> > registration and detection interface >> > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounte= r >> > support >> > >> > My current plan is to MFC this series to 10-STABLE, and commit a >> > self-contained KVM clock to the other stable branches. >> > >> > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch >> > >> > _______________________________________________ >> > freebsd-arch@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org= " >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 06:18:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75A19645 for ; Mon, 5 Jan 2015 06:18:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 65C8626CD for ; Mon, 5 Jan 2015 06:18:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 61065C63 for ; Mon, 5 Jan 2015 06:18:34 +0000 (UTC) Date: Mon, 5 Jan 2015 06:18:33 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1458234386.53.1420438713878.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #518 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 06:18:36 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 11:02:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4DFBE43 for ; Mon, 5 Jan 2015 11:02:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7DC66338 for ; Mon, 5 Jan 2015 11:02:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 07067F2C for ; Mon, 5 Jan 2015 11:02:26 +0000 (UTC) Date: Mon, 5 Jan 2015 11:02:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <962393435.56.1420455745978.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1458234386.53.1420438713878.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1458234386.53.1420438713878.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #519 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:02:25 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 12:56:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C35E879 for ; Mon, 5 Jan 2015 12:56:47 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6002E67103 for ; Mon, 5 Jan 2015 12:56:47 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 3301F5C002 for ; Mon, 5 Jan 2015 15:56:24 +0300 (MSK) Message-ID: <54AA8A09.6090507@FreeBSD.org> Date: Mon, 05 Jan 2015 15:56:41 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: FreeBSD-current Subject: vt and VirtualBox? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 12:56:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is here any possibility to add "virtualbox" driver to vt? Now console of -CURRENT guest in VirtualBox (using "vga" driver) is almost unusable slow! I'm not sure, that VirtualBox has API for paravirtualized screen output, though (guest addons?). - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUqooJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePKr0P/R1zqoNqgda2PjWrOwZYeCed gwWVzSEahFsxd+qNpEeKVXvcD4MP8oFMMjUsoNOqf9jonk3vVkzDfpHwHziRxBxL KhojqPvONZH75WF0PREOpx8/Ff3wtuZNggeyShZPb4ZiyZkXTScDxxn5ZhzGjDG4 OWViWEGK1Sw8U7gbyXPZs2D5B5kcExK5NFQyyIEnaRkGhwqHUCRsa5UP1we0QMsw YB8XswSf0z9GqpGv0KYSJqFqieSsxmzt3fE34vGTVE+vm1LToEdq6hWkHAgACuqa KmpAxaam1L4adH+SaPI9jMfpaPChE3RhwUpKMhexy64basyCC49yvXLXiF/28K35 ztsknr8tBmSv3lvMAFyxJqjZiq34WR7PcAbiPCLPy7FPwmvwbx6CSf1lUs96nuOw MfHB1eRzOlA2ABz/WwXMBKEmzNUdAsV1X1ILaCpRPQdDy2liIQpqsiNQS83obfw3 8pY+y7BH0hmI5auUbC5sk/kE/YbmAwoqS7FygV7rujb7pAOJQ6e4MlyTC3+pA+3J Qjspxe0YfOXO+tIH5/ydFMvZPGvrDwh+gx50d5INKAk57DFWzV4qCxnjYjJIbXys pifLOV2oh2sURd4atMEG2SfN8gYeDHMzOeav7sFo7XIM1S+9/i33LG9iSXwpukec eOjKYLgaSeGEy24lgCLs =tA47 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 13:17:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 342B3AF8 for ; Mon, 5 Jan 2015 13:17:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB6A267364 for ; Mon, 5 Jan 2015 13:17:32 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CFA371FE022; Mon, 5 Jan 2015 14:17:29 +0100 (CET) Message-ID: <54AA8F19.9030300@selasky.org> Date: Mon, 05 Jan 2015 14:18:17 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: FreeBSD Current , markb@mellanox.com Subject: [RFC] Start SMP subsystem earlier Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:17:33 -0000 Hi, There is a limitiation on the number of interrupt vectors available when only a single processor is running. To have more interrupts available we need to start SMP earlier when building a monotolith kernel and not loading drivers as modules. The driver in question is a network driver and because it cannot be started after SI_SUB_ROOT_CONF due to PXE support I see no other option than to move SI_SUB_SMP earlier. Suggested patch: > Index: sys/kernel.h > =================================================================== > --- sys/kernel.h (revision 276691) > +++ sys/kernel.h (working copy) > @@ -152,6 +152,7 @@ > SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ > SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout events*/ > SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled config */ > + SI_SUB_SMP = 0xa850000, /* start the APs*/ > SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ > SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ > SI_SUB_RAID = 0xb380000, /* Configure GEOM classes */ > @@ -165,7 +166,6 @@ > SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ > SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ > SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ > - SI_SUB_SMP = 0xf000000, /* start the APs*/ > SI_SUB_RACCTD = 0xf100000, /* start racctd*/ > SI_SUB_LAST = 0xfffffff /* final initialization */ > }; This fixes a problem for Mellanox drivers in the OFED layer. Possibly we need to move the SMP even earlier to not miss the generic FreeBSD PCI device enumeration or maybe this is not possible. Does anyone know how early we can start SMP? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 13:43:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39BFE40A for ; Mon, 5 Jan 2015 13:43:23 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A060E64456 for ; Mon, 5 Jan 2015 13:43:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t05DhGdn083338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2015 15:43:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t05DhGdn083338 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t05DhGj3083337; Mon, 5 Jan 2015 15:43:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jan 2015 15:43:16 +0200 From: Konstantin Belousov To: Hans Petter Selasky Subject: Re: [RFC] Start SMP subsystem earlier Message-ID: <20150105134316.GE42409@kib.kiev.ua> References: <54AA8F19.9030300@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AA8F19.9030300@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:43:23 -0000 On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote: > Hi, > > There is a limitiation on the number of interrupt vectors available when > only a single processor is running. To have more interrupts available we > need to start SMP earlier when building a monotolith kernel and not > loading drivers as modules. The driver in question is a network driver > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE > support I see no other option than to move SI_SUB_SMP earlier. > > Suggested patch: > > > Index: sys/kernel.h > > =================================================================== > > --- sys/kernel.h (revision 276691) > > +++ sys/kernel.h (working copy) > > @@ -152,6 +152,7 @@ > > SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ > > SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout events*/ > > SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled config */ > > + SI_SUB_SMP = 0xa850000, /* start the APs*/ > > SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ > > SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ > > SI_SUB_RAID = 0xb380000, /* Configure GEOM classes */ > > @@ -165,7 +166,6 @@ > > SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ > > SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ > > SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ > > - SI_SUB_SMP = 0xf000000, /* start the APs*/ > > SI_SUB_RACCTD = 0xf100000, /* start racctd*/ > > SI_SUB_LAST = 0xfffffff /* final initialization */ > > }; Did you inspected all reordered sysinit routines and ensured that the reordering is safe ? At very least, SUB_SMP starts event timers, while KTHREAD_IDLE is about configuring some hardware which might be required/not ready for that. > > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we > need to move the SMP even earlier to not miss the generic FreeBSD PCI > device enumeration or maybe this is not possible. Does anyone know how > early we can start SMP? From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 14:08:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A463BE1 for ; Mon, 5 Jan 2015 14:08:04 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD5626484C for ; Mon, 5 Jan 2015 14:08:03 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B00341FE022; Mon, 5 Jan 2015 15:08:01 +0100 (CET) Message-ID: <54AA9AF1.5020807@selasky.org> Date: Mon, 05 Jan 2015 15:08:49 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: [RFC] Start SMP subsystem earlier References: <54AA8F19.9030300@selasky.org> <20150105134316.GE42409@kib.kiev.ua> In-Reply-To: <20150105134316.GE42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:08:04 -0000 On 01/05/15 14:43, Konstantin Belousov wrote: > On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote: >> Hi, >> >> There is a limitiation on the number of interrupt vectors available when >> only a single processor is running. To have more interrupts available we >> need to start SMP earlier when building a monotolith kernel and not >> loading drivers as modules. The driver in question is a network driver >> and because it cannot be started after SI_SUB_ROOT_CONF due to PXE >> support I see no other option than to move SI_SUB_SMP earlier. >> >> Suggested patch: >> >>> Index: sys/kernel.h >>> =================================================================== >>> --- sys/kernel.h (revision 276691) >>> +++ sys/kernel.h (working copy) >>> @@ -152,6 +152,7 @@ >>> SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ >>> SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout events*/ >>> SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled config */ >>> + SI_SUB_SMP = 0xa850000, /* start the APs*/ >>> SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ >>> SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ >>> SI_SUB_RAID = 0xb380000, /* Configure GEOM classes */ >>> @@ -165,7 +166,6 @@ >>> SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ >>> SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ >>> SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ >>> - SI_SUB_SMP = 0xf000000, /* start the APs*/ >>> SI_SUB_RACCTD = 0xf100000, /* start racctd*/ >>> SI_SUB_LAST = 0xfffffff /* final initialization */ >>> }; > Did you inspected all reordered sysinit routines and ensured that the > reordering is safe ? At very least, SUB_SMP starts event timers, > while KTHREAD_IDLE is about configuring some hardware which might > be required/not ready for that. Hi, I did not inspect everything myself yet regarding this change. That's why I'm sending this e-mail out. The problem is simply that the total number of interrupts appears to be limited by "APIC_NUM_IOINTS" and "NUM_IO_INTS" which is per CPU from what I understand. Until SMP is activated the newbus code is simply distributing the IRQ vectors on the available IRQs, then when SMP is up it is re-shuffling them all. I was initially thinking that a hack might be possible, like using RF_SHARED for the IRQ resource, but then noticed that we were using MSI interrupts, which are not allocated in the same manner. The other issue is that the IRQs should be functional too, so that PXE boot can work. --HPS > >> >> This fixes a problem for Mellanox drivers in the OFED layer. Possibly we >> need to move the SMP even earlier to not miss the generic FreeBSD PCI >> device enumeration or maybe this is not possible. Does anyone know how >> early we can start SMP? > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 14:27:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2501FC7 for ; Mon, 5 Jan 2015 14:27:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 12A9964BC9 for ; Mon, 5 Jan 2015 14:27:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4A7122F4 for ; Mon, 5 Jan 2015 14:27:42 +0000 (UTC) Date: Mon, 5 Jan 2015 14:27:42 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <790549503.58.1420468062275.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <962393435.56.1420455745978.JavaMail.jenkins@jenkins-9.freebsd.org> References: <962393435.56.1420455745978.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #520 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:27:42 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 16:27:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 480216F0 for ; Mon, 5 Jan 2015 16:27:23 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE71E2AA3 for ; Mon, 5 Jan 2015 16:27:22 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l15so3640095wiw.8 for ; Mon, 05 Jan 2015 08:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DXyLmzY/q5+PK4SX+AH3ynn8pe66dKfpfCH6pzGIl28=; b=hrU96sVuVV7CKFJvNrdysrDeB3cv2sAlU1dXS9pWFjw4HKppBfbPkzxp0Pw//W+/Dd 5apAdCXOv8eMLME5jIfuhvOLOQ80hTlXIjeWObY5LWAGHeTyG2vaXa6sk/RwGqdLCN3w Oz4iH/vE2T3TalqeGttwQ8cNWfnuDceMs4Ai7e9VjFykRx0MAcFlhTdBA1GWgTeZEjl1 DiC7U6JgHaJU7U2DfaqL08Byj23xx2OIBMb2DIF4/WTbaVOG+h5gD8f+1+S8rT9UyyOc uvJR9wE1A8psGbCPzdmQhNhWkid+ZhfDBRq4HQt+WdI7E1ZRpFYNNWqCylEapczb1HyU XGGA== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr177944715wjb.68.1420475241277; Mon, 05 Jan 2015 08:27:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 08:27:21 -0800 (PST) In-Reply-To: <54AA9AF1.5020807@selasky.org> References: <54AA8F19.9030300@selasky.org> <20150105134316.GE42409@kib.kiev.ua> <54AA9AF1.5020807@selasky.org> Date: Mon, 5 Jan 2015 08:27:21 -0800 X-Google-Sender-Auth: mVFdtvEqLcftTyAuZmfnfh8QmLE Message-ID: Subject: Re: [RFC] Start SMP subsystem earlier From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:27:23 -0000 On 5 January 2015 at 06:08, Hans Petter Selasky wrote: > On 01/05/15 14:43, Konstantin Belousov wrote: >> >> On Mon, Jan 05, 2015 at 02:18:17PM +0100, Hans Petter Selasky wrote: >>> >>> Hi, >>> >>> There is a limitiation on the number of interrupt vectors available when >>> only a single processor is running. To have more interrupts available we >>> need to start SMP earlier when building a monotolith kernel and not >>> loading drivers as modules. The driver in question is a network driver >>> and because it cannot be started after SI_SUB_ROOT_CONF due to PXE >>> support I see no other option than to move SI_SUB_SMP earlier. >>> >>> Suggested patch: >>> >>>> Index: sys/kernel.h >>>> =================================================================== >>>> --- sys/kernel.h (revision 276691) >>>> +++ sys/kernel.h (working copy) >>>> @@ -152,6 +152,7 @@ >>>> SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ >>>> SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout >>>> events*/ >>>> SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled >>>> config */ >>>> + SI_SUB_SMP = 0xa850000, /* start the APs*/ >>>> SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ >>>> SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ >>>> SI_SUB_RAID = 0xb380000, /* Configure GEOM >>>> classes */ >>>> @@ -165,7 +166,6 @@ >>>> SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ >>>> SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ >>>> SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ >>>> - SI_SUB_SMP = 0xf000000, /* start the APs*/ >>>> SI_SUB_RACCTD = 0xf100000, /* start racctd*/ >>>> SI_SUB_LAST = 0xfffffff /* final initialization >>>> */ >>>> }; >> >> Did you inspected all reordered sysinit routines and ensured that the >> reordering is safe ? At very least, SUB_SMP starts event timers, >> while KTHREAD_IDLE is about configuring some hardware which might >> be required/not ready for that. > > > Hi, > > I did not inspect everything myself yet regarding this change. That's why > I'm sending this e-mail out. The problem is simply that the total number of > interrupts appears to be limited by "APIC_NUM_IOINTS" and "NUM_IO_INTS" > which is per CPU from what I understand. Until SMP is activated the newbus > code is simply distributing the IRQ vectors on the available IRQs, then when > SMP is up it is re-shuffling them all. > > I was initially thinking that a hack might be possible, like using RF_SHARED > for the IRQ resource, but then noticed that we were using MSI interrupts, > which are not allocated in the same manner. > > The other issue is that the IRQs should be functional too, so that PXE boot > can work. > I'm also starting to see increasing amounts of wifi hardware that expects interrupts to be up and working during probe/attach. (I think i915kms has the same issue too, no?) -adrian From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 17:11:46 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 876AFAB7; Mon, 5 Jan 2015 17:11:46 +0000 (UTC) Message-ID: <54AAC5D2.4090404@FreeBSD.org> Date: Mon, 05 Jan 2015 12:11:46 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: lev@FreeBSD.org, FreeBSD-current Subject: Re: vt and VirtualBox? References: <54AA8A09.6090507@FreeBSD.org> In-Reply-To: <54AA8A09.6090507@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:11:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/05/2015 07:56, Lev Serebryakov wrote: > > Is here any possibility to add "virtualbox" driver to vt? Now > console of -CURRENT guest in VirtualBox (using "vga" driver) is > almost unusable slow! Sorry, we do not have KMS for VirtualBox guest yet. > I'm not sure, that VirtualBox has API for paravirtualized screen > output, though (guest addons?). Someone with copious free time and enough knowledge should be able to port Linux KMS/DRM2 driver for us. https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux It shouldn't be too hard. ;-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUqsXNAAoJEHyflib82/FGni4H/RJrYLCNoYKdny70LJ0O6+o0 Mh5sf/fdfUkmfynrbyDAgCFfXdzD2/3p2NIX4WGgysUxOTgtWGFTLW67VNnQupwK pBSwz7Ute4LrSmXgHiKeNsduYtiIsOTY6744iFnEeELRgcY+g/ZDGxa6+zH2YxVW 82wWvbkgQA6wWtJw9sPOTYn2SjXRC+TUUcZcIqhcFxSdnJwpMzJ0QFEzrWxwV7hy ip3fi5XLlGqiPrv6C67m0L+YgZPRfMe2vA1/nDvOqzdVari+72TnffcKx/xvVgEO ZqQRG2P61Itut8b8LDS2bLEQQRpBILFbe7mpdlcAaYoLhdHFGfjjEYvrYcAn9cI= =o1su -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 17:27:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33269287; Mon, 5 Jan 2015 17:27:33 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id ECBA134A9; Mon, 5 Jan 2015 17:27:32 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 5FA135C003; Mon, 5 Jan 2015 20:27:21 +0300 (MSK) Message-ID: <54AAC98A.7040008@FreeBSD.org> Date: Mon, 05 Jan 2015 20:27:38 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jung-uk Kim , FreeBSD-current Subject: Re: vt and VirtualBox? References: <54AA8A09.6090507@FreeBSD.org> <54AAC5D2.4090404@FreeBSD.org> In-Reply-To: <54AAC5D2.4090404@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:27:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.01.2015 20:11, Jung-uk Kim wrote: > Someone with copious free time and enough knowledge should be able > to port Linux KMS/DRM2 driver for us. > > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux > > It shouldn't be too hard. ;-) This driver looks empty to me :) On the other hand here is https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/freebsd/drm/ - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUqsmJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePfL0P+gJAtX5zpJAOL5xczPwPU5JL d6CFQMDOBAnbHk7RaBSuY4JIuvyLE/9xORSYgM4ll8t1Uhn8f33nFLNiD2kIbJsF ntMlYIS1axJubvSNBs+u1U08tEANlyxFMKEaVvzNQ8L0e3wx1MTjwNCJcN3kU9AY nUu1Twwn6YB5K1E6JJ0cICzmdgw3LAJOUjql8sZh6amyFwWk2xInV7Bxf8+DYG4S 2U1xRmmxxiEhtksPesnVsHe1u4I4gS36U15yjwycsyMLyaNEwUe412pyTGKAeeWZ iwCRpSQbmXb3uMsZbQcC8Xb5F1dsMMWgIqQl/4IWhDnyY4eaYNqMeNnDEYmXv5IR Qo/m3mzFoUEs8A0U7JyH3GOrSnGtHeEBdqs1t+aGbZfU4dfiDql8TLcV1Z7uKksq Sl0seAV29jPSB5YBazPsxVJkFsR25qv2TFOvYzGlwsfF39mJHsjZRIgz7cLWaLbM PU0E96EUn6cnL72bHJkaYKzs5ZOBa2ThvgXLo31Uqj4jbgR6kembT9iGId295pIb Lo9Tf2bJWzAvPoEwNulc4mMagUiUez6jSYez09+iN3km0c1/EkIMqDdfK5DXWiQN 2cYyUEDF+WInZwqW7Fa9Rq99xILrUNgv1ENs587Ixs5mOnDlInpvs7cLVlf5YsYj 2iecQhYsC6aYTneYV52s =6MF5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 17:33:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 3A58C40F; Mon, 5 Jan 2015 17:33:01 +0000 (UTC) Message-ID: <54AACACC.7090908@FreeBSD.org> Date: Mon, 05 Jan 2015 12:33:00 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: lev@FreeBSD.org, FreeBSD-current Subject: Re: vt and VirtualBox? References: <54AA8A09.6090507@FreeBSD.org> <54AAC5D2.4090404@FreeBSD.org> <54AAC98A.7040008@FreeBSD.org> In-Reply-To: <54AAC98A.7040008@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:33:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/05/2015 12:27, Lev Serebryakov wrote: > On 05.01.2015 20:11, Jung-uk Kim wrote: > >> Someone with copious free time and enough knowledge should be >> able to port Linux KMS/DRM2 driver for us. > >> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux > >> It shouldn't be too hard. ;-) > This driver looks empty to me :) I meant: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm > On the other hand here is > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/freebsd/drm/ This > driver is UMS/DRM1. vt(4) cannot use this driver. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUqsrIAAoJEHyflib82/FGSWIH/3pS+JUOsVCJTV/jWle+3a0Y QXrCBOZCjL/dMH3r0ZRe3OvQWMwab396lMT+sSsQW59LjeVq7jf7H+nocIxHxoQr 82zkFUZazELkcjEwkguaYiGiIPgM6/HKq3wQQvGFA1Y/t8Hjs/LtEEcEjAksBeE3 bIYfLa5BWoNv+3WfVJeelbinACgp6W9V8oLZRnWzK1f6yiMfMaFwSbgGnEQuHRMz YWfL5RGlVA9Z9B7IxXN+HWvctP0cCXTpQ3uyQJ+/TFWnlFlVQs4DBYcqsJ+B1QPV MZAlVTTQgiHF7tn6LIm5E6Su7647szDF3fNCnvc/8g4bHqVDl4JMEGLWH4W/dxU= =X78W -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 18:30:45 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 902743C7; Mon, 5 Jan 2015 18:30:45 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 53E932251; Mon, 5 Jan 2015 18:30:44 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E56E97300A; Mon, 5 Jan 2015 19:35:29 +0100 (CET) Date: Mon, 5 Jan 2015 19:35:29 +0100 From: Luigi Rizzo To: Bryan Venteicher , current@freebsd.org Subject: false alarm (Re: invalid checksum with vtnet and in_kernel BOOTP) Message-ID: <20150105183529.GF22916@onelab2.iet.unipi.it> References: <20150103190022.GA95892@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150103190022.GA95892@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:30:45 -0000 for the records, this was not a problem with vtnet but a bug in some bhyve modifications of ours. Thanks to Bryan who pointed out the potential location of the problem. cheers luigi On Sat, Jan 03, 2015 at 08:00:22PM +0100, Luigi Rizzo wrote: > I am trying to run a diskless bhyve client diskless using in-kernel > bootp support and vtnet connected to tap and bridge on the host side > and I am having the problem in the subject which may be vtnet-related. > > Packets generated by the in-kernel DHCP arrive to the host tap > interface with a corrupt checksum, which is consistent with vtnet0 > having the TXCSUM capability enabled. > > Unfortunately, when the packet reaches the bridge0 on the host: > > uname -a > FreeBSD bsd9.casa 10.0-STABLE FreeBSD 10.0-STABLE #0 r269180: > >ifconfig bridge0 > > bridge0: flags=8843 metric 0 mtu 1500 > ether 02:01:85:b1:55:00 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: re0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 200000 > member: tap0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 55 > > The packet goes out with a broken checksum and the (external) > dhcp server does not respond. > > When the guest is up, i can run dhclient on the same guest interface > and packets exit with a correct checksum. > Maybe dhclient generates correct packets ignoring the TXCSUM setting. > > In any case i applied a quick fix (disable TXCSUM in if_vtnet.c) > and at least can get the dhcp request reach the router and get > a response back. > > Also note that subsequent (tcp) traffic through the interface > is reported on the host with a correct checksum, so i suspect > that either the kernel-bootp code does not pass the correct > checksum flags, or somehow it is sent to the device too early > in the initialization process. > > any idea ? > > cheers > luigi From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 18:48:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 2C13BD62; Mon, 5 Jan 2015 18:48:38 +0000 (UTC) Message-ID: <54AADC85.60608@FreeBSD.org> Date: Mon, 05 Jan 2015 13:48:37 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: lev@FreeBSD.org, FreeBSD-current Subject: Re: vt and VirtualBox? References: <54AA8A09.6090507@FreeBSD.org> <54AAC5D2.4090404@FreeBSD.org> <54AAC98A.7040008@FreeBSD.org> <54AACACC.7090908@FreeBSD.org> In-Reply-To: <54AACACC.7090908@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:48:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/05/2015 12:33, Jung-uk Kim wrote: > On 01/05/2015 12:27, Lev Serebryakov wrote: >> On 05.01.2015 20:11, Jung-uk Kim wrote: > >>> Someone with copious free time and enough knowledge should be >>> able to port Linux KMS/DRM2 driver for us. > >>> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux > >>> >>> >>> It shouldn't be too hard. ;-) >> This driver looks empty to me :) > > I meant: > > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm I > realized Linux KMS driver was removed by this commit. https://www.virtualbox.org/changeset/48364 Sorry, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 00:46:46 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F12CC297 for ; Tue, 6 Jan 2015 00:46:46 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D23DC6609E for ; Tue, 6 Jan 2015 00:46:46 +0000 (UTC) Received: from [10.12.76.163] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 72317192A3B for ; Tue, 6 Jan 2015 00:46:40 +0000 (UTC) Message-ID: <54AB306F.2070509@ignoranthack.me> Date: Mon, 05 Jan 2015 16:46:39 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Haswell CPU Feature Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 00:46:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "\014" I don't know what this cpu feature2 flag means, but my x240 haswell laptop has a "b11" feature2 set. sean dmesg | grep -i features Features=0xbfebfbff Features2=0x7ffafbbf,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUqzBsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ktYUH/A/2P6aNyBfBMhM7pRThx/DC kulQbmHCuqOFwzJnE8qI/1YTvItNFG2sAsspd0iT2FmC2oEY/z6+j2ba2UizMJmH +ppjseAzs4+GY2N6cxT0BHf1yNoMDqlwdeWVeSODCn2HCc9Cc9Wz0e0RUOpwQ4zx Hmm1zI0Rla1izMIm437Lv38RFP1q/KaNLailcwgYrjvd90RaqobDeE2If3BYe8uv qvYUeap3hRk0EOrjMRBuGyMSIGkssHa1NyfQFYEmzg3F9F8lgTnCBYlspovjacoy I+LRWBUpOGS89vBxCjnLuBZO9fFajSJ0b6X8K8Cw4QWZmefPZWutujgf5ObzBhI= =oXdb -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 00:57:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9B7E569; Tue, 6 Jan 2015 00:57:28 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F50166235; Tue, 6 Jan 2015 00:57:28 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so4393446wiw.16; Mon, 05 Jan 2015 16:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wN+NTfRr75yHAx/n2NyyrGU2K7qTnD3tKoBbofLgDeU=; b=SfzRX0fNvwKSvUzcl97XU7JuBY0QxNvjUD3/mIqZRV+Zkw5XVNSWO4ldvcS7NvMFC7 d2cL5MM4mLe49DrX2DBukqO/UwuxcnuRycJs8Qiw8uvLUGM5Gy7EX7+LUSMaQVuuPYch gTC6ltjuHh5MReyXxE+1oznaxhBC+2ddmrxgWzTeJjsf9Ys1q2nqJaPSOfts7g8kq78D Ww2ZhDbEp4qrug+b7gJwc92VnpLrEd33qj+0b7lUbvlIa28a5D/7d/2iKEnjSaYxP2e6 U8vlJcfzaz8+PApm9EZxvzwKWdYpiStqXeN58Dknzro6Zwt+pl2DGZr/Xxi/XYznSX5z eLsw== MIME-Version: 1.0 X-Received: by 10.180.109.46 with SMTP id hp14mr31637276wib.54.1420505846772; Mon, 05 Jan 2015 16:57:26 -0800 (PST) Received: by 10.27.5.207 with HTTP; Mon, 5 Jan 2015 16:57:26 -0800 (PST) In-Reply-To: <54AB306F.2070509@ignoranthack.me> References: <54AB306F.2070509@ignoranthack.me> Date: Mon, 5 Jan 2015 16:57:26 -0800 Message-ID: Subject: Re: Haswell CPU Feature From: Neel Natu To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 00:57:28 -0000 Hi Sean, On Mon, Jan 5, 2015 at 4:46 PM, Sean Bruno wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > "\014" > > > I don't know what this cpu feature2 flag means, but my x240 haswell > laptop has a "b11" feature2 set. > > sean > > dmesg | grep -i features > > Features=0xbfebfbff > > Features2=0x7ffafbbf,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> Congratulations, you have the ability to debug the Haswell silicon :-) >From the Intel SDM, "Table 3-20. Feature Information Returned in the ECX Register" 11 | SDBG | A value of 1 indicates the processor supports IA32_DEBUG_INTERFACE MSR for silicon debug. best Neel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJUqzBsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ktYUH/A/2P6aNyBfBMhM7pRThx/DC > kulQbmHCuqOFwzJnE8qI/1YTvItNFG2sAsspd0iT2FmC2oEY/z6+j2ba2UizMJmH > +ppjseAzs4+GY2N6cxT0BHf1yNoMDqlwdeWVeSODCn2HCc9Cc9Wz0e0RUOpwQ4zx > Hmm1zI0Rla1izMIm437Lv38RFP1q/KaNLailcwgYrjvd90RaqobDeE2If3BYe8uv > qvYUeap3hRk0EOrjMRBuGyMSIGkssHa1NyfQFYEmzg3F9F8lgTnCBYlspovjacoy > I+LRWBUpOGS89vBxCjnLuBZO9fFajSJ0b6X8K8Cw4QWZmefPZWutujgf5ObzBhI= > =oXdb > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 01:24:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 720ECBD7 for ; Tue, 6 Jan 2015 01:24:32 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F74064419 for ; Tue, 6 Jan 2015 01:24:32 +0000 (UTC) Received: from [10.12.76.163] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id A0762192A3B for ; Tue, 6 Jan 2015 01:24:31 +0000 (UTC) Message-ID: <54AB394E.5040601@ignoranthack.me> Date: Mon, 05 Jan 2015 17:24:30 -0800 From: Sean Bruno Reply-To: Sean Bruno User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 CC: FreeBSD current Subject: Re: Haswell CPU Feature References: <54AB306F.2070509@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:24:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/05/15 16:57, Neel Natu wrote: > Congratulations, you have the ability to debug the Haswell silicon > HA! Is this turned on purposefully (its a feature of the CPU) or is this turned on unintentionally and is a bug in manufacturing? sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUqzlLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k3GUIAJIbfTFkgiz1yuMkTbJtXUGe e9orU4iOoULSBksHMSrT1FYr3LoK1XTBJtqBadOtLa9BU7VPLeaDELr1HoPK9dHr h3ps4qkG7yAen3bH6U2oo64UAkjjEBRaY82LgkuSMFCFq1Y96EzphL+O7AKzbGYJ VblMY/Yrm45NiG8l2TuniRyBoiLhkdeYcBSPR8ErTbxyiO3l6bCilz5dI/h8icoR gps0v+0f6Bk1O5LuO33ctgf1iZKdP+yckmk2NCYNoe6oXO2+f4Y9u8jhTXar+5ey B2pG0IWK/cqEk1/53c6I+/X85YL+YNw9D9fObxZapml6nb06FHmTiBlnLcWL/PM= =Civ3 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 01:50:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F67D31D; Tue, 6 Jan 2015 01:50:20 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9180647EC; Tue, 6 Jan 2015 01:50:19 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id n12so28403701wgh.22; Mon, 05 Jan 2015 17:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Our7LC/uAFp9hIo6+A6HHf+uEidotmpaLmLXK0o6Okc=; b=OQ5vImr3JqdpCpuj9sPqrVuZ2/ITr33zXx+iL7GblS2LY1Yc06ulGkthFbKS940VLg m9XPht3mcsmGE5t3pLajYwH60CNb+5j2wopFCjqovMX1V/gYD6fDbI74GA2TrgRHudQM fTGzAUS4meLNPFnJz1UzbLsfJyIz5g9JIr3J44vjID8Ow5m/Iv22RTqD7NRUYqlRqceC /mPQ1Artn5vPCRLhxCOgI/5n7ehu4CRPrCjfkmwAnKhNxdm3Y765eRHw1+KgzSHBdSTM KsdMTRDWnZzgiqHldTCNfUhaIMLeCzWBKYxyZIe3pCXvZcackRTYkc3kR0F9R+ktrjpB ggzw== MIME-Version: 1.0 X-Received: by 10.194.90.229 with SMTP id bz5mr75259310wjb.63.1420509018219; Mon, 05 Jan 2015 17:50:18 -0800 (PST) Received: by 10.194.216.226 with HTTP; Mon, 5 Jan 2015 17:50:18 -0800 (PST) In-Reply-To: <54AB394E.5040601@ignoranthack.me> References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> Date: Tue, 6 Jan 2015 05:50:18 +0400 Message-ID: Subject: Re: Haswell CPU Feature From: Andrey Fesenko To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:50:20 -0000 On Tue, Jan 6, 2015 at 4:24 AM, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/05/15 16:57, Neel Natu wrote: >> Congratulations, you have the ability to debug the Haswell silicon >> > HA! > > Is this turned on purposefully (its a feature of the CPU) or is this > turned on unintentionally and is a bug in manufacturing? > > sean My desktop i5-4570 contain this flag too Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 Features=0xbfebfbff Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 02:34:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 223B0C56 for ; Tue, 6 Jan 2015 02:34:45 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F27E366D18 for ; Tue, 6 Jan 2015 02:34:44 +0000 (UTC) Received: from [10.12.76.163] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id D855F192A3B; Tue, 6 Jan 2015 02:34:42 +0000 (UTC) Message-ID: <54AB49C2.9020005@ignoranthack.me> Date: Mon, 05 Jan 2015 18:34:42 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrey Fesenko Subject: Re: Haswell CPU Feature References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 02:34:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/05/15 17:50, Andrey Fesenko wrote: > On Tue, Jan 6, 2015 at 4:24 AM, Sean Bruno > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 01/05/15 16:57, Neel Natu wrote: >>> Congratulations, you have the ability to debug the Haswell >>> silicon >>> >> HA! >> >> Is this turned on purposefully (its a feature of the CPU) or is >> this turned on unintentionally and is a bug in manufacturing? >> >> sean > > My desktop i5-4570 contain this flag too > > Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c > Stepping=3 > Features=0xbfebfbff > > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > > I'm thinking something like this: Index: sys/x86/x86/identcpu.c =================================================================== - --- sys/x86/x86/identcpu.c (revision 276729) +++ sys/x86/x86/identcpu.c (working copy) @@ -781,7 +781,7 @@ "\011TM2" /* Thermal Monitor 2 */ "\012SSSE3" /* SSSE3 */ "\013CNXT-ID" /* L1 context ID available */ - - "\014" + "\014SDBG" /* IA32_DEBUG_INTERFACE debug*/ "\015FMA" /* Fused Multiply Add */ "\016CX16" /* CMPXCHG16B Instruction */ "\017xTPR" /* Send Task Priority Messages*/ sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUq0m+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kigkIAI2Naiv2TENl+1SFAQ5oHTUu HR+sbz3o7p71W8/9WhdkiMhHLwpF5ZGrpqh9Jc4CYuyNax4OvzD9du8b1RFVVBtx AR6K+zFE1/wHC8S+iEB2QsWLWjd6Y0NbZL1MvgEQTybFwLzdtEXafOi2gSsa2lK0 RFMd0VbE2xn2q9mp5GuTnR8fvqWGPSJLEtWTpEZri8vFnBIMC+kocb//kOhY6JsF SNcpJ2RfhXiQyOOZT/ETe47s7A29R9VW5u/+Hg8VnNuq5rV5o2PXa68VvSmAu4gr IxPMoodFUITXTpS/lfmkOf4W+uTSqUji+Y/u1yjNzS4MgodoEh6mc7gDuH9Xoj0= =j1kZ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 05:23:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 288A0B2; Tue, 6 Jan 2015 05:23:12 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB0C9212D; Tue, 6 Jan 2015 05:23:11 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id k48so9008345wev.5; Mon, 05 Jan 2015 21:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XY3xULCa+a27RP7NZHzlhVyGtY0sM2FPBNgDn34dMEk=; b=Yg+dQehva1kM8yY1tpMpmiXGWPqdSESRSGf8kKT2b3ys/Z5XPr09/WuG/w5aoCDicA 1cXItiYSABSkdaOaygdh7jP2mVf9OB7FSHcPah7oiRPIYeDgTKlxjlwHNv3GVuzPX2VU lmZ5VHT0Kglw7Bqo5YJd2Emla/edmVIia1GFIzs/YUDh1utvj/31Jb0qUOL9Fj1mqPAk uvrbxa19UdQLmLOOcE+Yv8Sktujb93TCyG4nEvwOBmdY5Z0ulNQ01tfkXI6nhWpbrlv6 rtF8dL+v4xOFshYZnmTpRNv/dHd28lBdIuBvREdNLRPaqsBuGEd5JqdrJRcH5iXDrq7V ar/w== MIME-Version: 1.0 X-Received: by 10.195.12.35 with SMTP id en3mr190935639wjd.129.1420521790164; Mon, 05 Jan 2015 21:23:10 -0800 (PST) Received: by 10.27.5.207 with HTTP; Mon, 5 Jan 2015 21:23:10 -0800 (PST) In-Reply-To: <54AB49C2.9020005@ignoranthack.me> References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> <54AB49C2.9020005@ignoranthack.me> Date: Mon, 5 Jan 2015 21:23:10 -0800 Message-ID: Subject: Re: Haswell CPU Feature From: Neel Natu To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: Andrey Fesenko , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 05:23:12 -0000 Hi Sean, On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/05/15 17:50, Andrey Fesenko wrote: >> On Tue, Jan 6, 2015 at 4:24 AM, Sean Bruno >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>> >>> On 01/05/15 16:57, Neel Natu wrote: >>>> Congratulations, you have the ability to debug the Haswell >>>> silicon >>>> >>> HA! >>> >>> Is this turned on purposefully (its a feature of the CPU) or is >>> this turned on unintentionally and is a bug in manufacturing? >>> >>> sean >> >> My desktop i5-4570 contain this flag too >> >> Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c >> Stepping=3 >> Features=0xbfebfbff >> >> > Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> >> >> > I'm thinking something like this: > > Index: sys/x86/x86/identcpu.c > =================================================================== > - --- sys/x86/x86/identcpu.c (revision 276729) > +++ sys/x86/x86/identcpu.c (working copy) > @@ -781,7 +781,7 @@ > "\011TM2" /* Thermal Monitor 2 */ > "\012SSSE3" /* SSSE3 */ > "\013CNXT-ID" /* L1 context ID available */ > - - "\014" > + "\014SDBG" /* IA32_DEBUG_INTERFACE debug*/ > "\015FMA" /* Fused Multiply Add */ > "\016CX16" /* CMPXCHG16B Instruction */ > "\017xTPR" /* Send Task Priority Messages*/ > > Looks good. best Neel > sean > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJUq0m+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kigkIAI2Naiv2TENl+1SFAQ5oHTUu > HR+sbz3o7p71W8/9WhdkiMhHLwpF5ZGrpqh9Jc4CYuyNax4OvzD9du8b1RFVVBtx > AR6K+zFE1/wHC8S+iEB2QsWLWjd6Y0NbZL1MvgEQTybFwLzdtEXafOi2gSsa2lK0 > RFMd0VbE2xn2q9mp5GuTnR8fvqWGPSJLEtWTpEZri8vFnBIMC+kocb//kOhY6JsF > SNcpJ2RfhXiQyOOZT/ETe47s7A29R9VW5u/+Hg8VnNuq5rV5o2PXa68VvSmAu4gr > IxPMoodFUITXTpS/lfmkOf4W+uTSqUji+Y/u1yjNzS4MgodoEh6mc7gDuH9Xoj0= > =j1kZ > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 05:44:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3AE088F; Tue, 6 Jan 2015 05:44:36 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A01D124CB; Tue, 6 Jan 2015 05:44:36 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id tr6so1119824ieb.7; Mon, 05 Jan 2015 21:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sKWSVyMaNFZZmANRlJeKVBqzGzMdXnj5K1NfPKaLTFw=; b=YLKLkMwTXLCCUrjW6Z9y6d1QTqMnja4ofF3rMb/J2UM7fLw4vCFSR2wPhTpQ6qOf1a hWROKBBrs6eQpHQbCHpH5eMBw3mRPrxxbF7QA/FgSDajGOCkeEDvGZlq6jV8dktpqPe3 sfObf51ptgdRV4hYv5D+LtlMUd/JTlNIIJs9j/oIyDyq8G+p+zlzr6UD/ZKVbcVGYFvg AULXnUcJGbzfnBMT7UayA66mQHAq1AoTs7uKhOSvqHiwgK+VgkMXjUceSR5G/Qu7Z8qm wQ99a+1RGuHmDIBwQ9iXERhN3OVYas1j7NlHx35TKeOCOX/MHzlIcUxLtoAH732ZB4W+ vpAg== X-Received: by 10.50.112.8 with SMTP id im8mr838885igb.18.1420523073550; Mon, 05 Jan 2015 21:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.4 with HTTP; Mon, 5 Jan 2015 21:44:02 -0800 (PST) In-Reply-To: References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> <54AB49C2.9020005@ignoranthack.me> From: Jia-Shiun Li Date: Tue, 6 Jan 2015 13:44:02 +0800 Message-ID: Subject: Re: Haswell CPU Feature To: Neel Natu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD current , Andrey Fesenko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 05:44:37 -0000 On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu wrote: > Hi Sean, > > On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno wrote: > > I'm thinking something like this: > > > > Index: sys/x86/x86/identcpu.c > > =================================================================== > > - --- sys/x86/x86/identcpu.c (revision 276729) > > +++ sys/x86/x86/identcpu.c (working copy) > > @@ -781,7 +781,7 @@ > > "\011TM2" /* Thermal Monitor 2 */ > > "\012SSSE3" /* SSSE3 */ > > "\013CNXT-ID" /* L1 context ID > available */ > > - - "\014" > > + "\014SDBG" /* IA32_DEBUG_INTERFACE > debug*/ > > "\015FMA" /* Fused Multiply Add */ > > "\016CX16" /* CMPXCHG16B > Instruction */ > > "\017xTPR" /* Send Task Priority > Messages*/ > > > > > > Looks good. > Maybe also this for completeness? # svnlite diff Index: sys/x86/include/specialreg.h =================================================================== --- sys/x86/include/specialreg.h (revision 276737) +++ sys/x86/include/specialreg.h (working copy) @@ -154,6 +154,7 @@ #define CPUID2_TM2 0x00000100 #define CPUID2_SSSE3 0x00000200 #define CPUID2_CNXTID 0x00000400 +#define CPUID2_SDBG 0x00000800 #define CPUID2_FMA 0x00001000 #define CPUID2_CX16 0x00002000 #define CPUID2_XTPR 0x00004000 -Jia-Shiun From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 11:14:34 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 178AB68A; Tue, 6 Jan 2015 11:14:34 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D01BE66650; Tue, 6 Jan 2015 11:14:33 +0000 (UTC) Received: from [100.96.81.24] (unknown [78.25.123.17]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2DB795C002; Tue, 6 Jan 2015 14:14:18 +0300 (MSK) Message-ID: <54ABC39D.5020201@FreeBSD.org> Date: Tue, 06 Jan 2015 14:14:37 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jung-uk Kim , FreeBSD-current Subject: Re: vt and VirtualBox? References: <54AA8A09.6090507@FreeBSD.org> <54AAC5D2.4090404@FreeBSD.org> <54AAC98A.7040008@FreeBSD.org> <54AACACC.7090908@FreeBSD.org> In-Reply-To: <54AACACC.7090908@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:14:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.01.2015 20:33, Jung-uk Kim wrote: >> This driver looks empty to me :) > I meant: > https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm > Yes, I understand. I've wrote about this one that it seems empty. No big method tables, no custom vbox-related code, nothing, looks like driver skeleton. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUq8OcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP1noQAMT0QQTbT8oBDn1C/AsNH15b fs0vz/BbEkM3KrHSrOYHR1CRmupBCHunzbaIUn0emooSjI4HSHSHLzd6JQ4P6mAw iSs7hmDvu7wJqoQyQpKfh99ZMnSl46PeR7uhlP9yJ8M+nCs5pIJNLVWMc+bclHi2 5Bb0X3K0eChuMP44GqIBBTABejXX+jsE8/0XUAilutLmFbHzdB9Il6YINFb2fb08 yyL4BDqpbiVQT4M4M9tFO88QvBej6lAAnNExAkdJdIj/KBHGsZOz0Ky+IWwQHfIi ErlKr8EcVgxYVBMat1eUQA66uwclr8aJm2mGHXAlDiFSAbi/r17irdjVdgSM9EZ9 Ga7EJ4vLZIpyDvzXmaVqvBXtmaNbqaiOPg6HsXgfkSGt49x8V5Vocw4hqk/R6jDa dhFEUZzvmxkuq70XywoYT1mt1kqzl0h83A5/c8fcPjeoxQMG5cfPl5q5iGiW9DjV 0NBC8nc+Qm1evu9DZO0jz0QCEWmmyUJxLsQjtsJkEpUWGc62TJXE6sz4KyQY9qvW jYVAI9OhQQVwLd7p7LKbRuePb43kNmAvCw6PGIb6r/EhqVurYf/l0zx3uzRkx06D dbg+3OvXa7eq5vkNnJiFslai6DGXbulOpH6ksOuNBKq2Pfw0xu+lilEHtkyEcbJy imtO+NSzbzgAlgS41kN1 =mOlA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 14:37:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FC4876D for ; Tue, 6 Jan 2015 14:37:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD2AD6676F for ; Tue, 6 Jan 2015 14:37:32 +0000 (UTC) Received: from new-host.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 131FBB946; Tue, 6 Jan 2015 09:37:31 -0500 (EST) Message-ID: <54ABF32A.6010409@FreeBSD.org> Date: Tue, 06 Jan 2015 09:37:30 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky , FreeBSD Current , markb@mellanox.com Subject: Re: [RFC] Start SMP subsystem earlier References: <54AA8F19.9030300@selasky.org> In-Reply-To: <54AA8F19.9030300@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 Jan 2015 09:37:31 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:37:33 -0000 On 1/5/15 8:18 AM, Hans Petter Selasky wrote: > Hi, > > There is a limitiation on the number of interrupt vectors available when > only a single processor is running. To have more interrupts available we > need to start SMP earlier when building a monotolith kernel and not > loading drivers as modules. The driver in question is a network driver > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE > support I see no other option than to move SI_SUB_SMP earlier. > > Suggested patch: > >> Index: sys/kernel.h >> =================================================================== >> --- sys/kernel.h (revision 276691) >> +++ sys/kernel.h (working copy) >> @@ -152,6 +152,7 @@ >> SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ >> SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout >> events*/ >> SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled >> config */ >> + SI_SUB_SMP = 0xa850000, /* start the APs*/ >> SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ >> SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ >> SI_SUB_RAID = 0xb380000, /* Configure GEOM classes */ >> @@ -165,7 +166,6 @@ >> SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ >> SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ >> SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ >> - SI_SUB_SMP = 0xf000000, /* start the APs*/ >> SI_SUB_RACCTD = 0xf100000, /* start racctd*/ >> SI_SUB_LAST = 0xfffffff /* final initialization */ >> }; > > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we > need to move the SMP even earlier to not miss the generic FreeBSD PCI > device enumeration or maybe this is not possible. Does anyone know how > early we can start SMP? We need a lot more work before this is ready. This is one of the goals of the multipass new-bus stuff. In particular, we have to enumerate enough devices to bring event timer hardware up so that timer interrupts work so that tsleep() will actually sleep. In addition, we also need idle threads created and working before APs are started as otherwise they will have no thread to run initially. This is certainly a desired feature, but it is not as simple as moving the sysinit up I'm afraid. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 14:48:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ACD7A34 for ; Tue, 6 Jan 2015 14:48:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC3218B1 for ; Tue, 6 Jan 2015 14:48:02 +0000 (UTC) Received: from new-host.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F342B946; Tue, 6 Jan 2015 09:48:01 -0500 (EST) Message-ID: <54ABF5A0.7020709@FreeBSD.org> Date: Tue, 06 Jan 2015 09:48:00 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jia-Shiun Li , Neel Natu Subject: Re: Haswell CPU Feature References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> <54AB49C2.9020005@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 Jan 2015 09:48:01 -0500 (EST) Cc: Andrey Fesenko , FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:48:02 -0000 On 1/6/15 12:44 AM, Jia-Shiun Li wrote: > On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu wrote: > >> Hi Sean, >> >> On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno wrote: >>> I'm thinking something like this: >>> >>> Index: sys/x86/x86/identcpu.c >>> =================================================================== >>> - --- sys/x86/x86/identcpu.c (revision 276729) >>> +++ sys/x86/x86/identcpu.c (working copy) >>> @@ -781,7 +781,7 @@ >>> "\011TM2" /* Thermal Monitor 2 */ >>> "\012SSSE3" /* SSSE3 */ >>> "\013CNXT-ID" /* L1 context ID >> available */ >>> - - "\014" >>> + "\014SDBG" /* IA32_DEBUG_INTERFACE >> debug*/ >>> "\015FMA" /* Fused Multiply Add */ >>> "\016CX16" /* CMPXCHG16B >> Instruction */ >>> "\017xTPR" /* Send Task Priority >> Messages*/ >>> >>> >> >> Looks good. >> > > Maybe also this for completeness? > > # svnlite diff > Index: sys/x86/include/specialreg.h > =================================================================== > --- sys/x86/include/specialreg.h (revision 276737) > +++ sys/x86/include/specialreg.h (working copy) > @@ -154,6 +154,7 @@ > #define CPUID2_TM2 0x00000100 > #define CPUID2_SSSE3 0x00000200 > #define CPUID2_CNXTID 0x00000400 > +#define CPUID2_SDBG 0x00000800 > #define CPUID2_FMA 0x00001000 > #define CPUID2_CX16 0x00002000 > #define CPUID2_XTPR 0x00004000 Yes, please include both. SDBG matches the label in the Intel SDM, so that's the preferred name. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 14:50:37 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C67CCB65 for ; Tue, 6 Jan 2015 14:50:37 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65F3A1996 for ; Tue, 6 Jan 2015 14:50:36 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t06EoZMu020355 for ; Tue, 6 Jan 2015 06:50:35 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t06EoZ6E020354 for current@freebsd.org; Tue, 6 Jan 2015 06:50:35 -0800 (PST) (envelope-from david) Date: Tue, 6 Jan 2015 06:50:35 -0800 From: David Wolfskill To: current@freebsd.org Subject: iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting... Message-ID: <20150106145035.GY14822@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DejVYFcqCV4p9T4J" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:50:37 -0000 --DejVYFcqCV4p9T4J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable One of the things I've noticed for a bit (but failed ot mention, as it's been something I find difficult to describe adequately) is that when I run head on my laptop -- generally, just to perform a source-based upgrade-in-place (so it tends to be rather busy), the machine acts as if it's failing to pay attention to some of the interrupts sometimes. E.g., moving the mouse is extremely laggy & jerky (with a fair amount of overshooting once the position settles). And the wireless NIC (iwn) will often lose ... well, everything it can. And I'm seeing messages such as this in /var/log/messages: =2E.. Jan 6 06:24:12 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530= 501 Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_tx_data: m=3D0xd2a33c00: seqno (25= 151) (63) !=3D ring index (0) ! Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_intr: fatal firmware error Jan 6 06:24:14 g1-253 kernel: firmware error log: Jan 6 06:24:14 g1-253 kernel: error type =3D "SYSASSERT" (0x00000005) Jan 6 06:24:14 g1-253 kernel: program counter =3D 0x0000C210 Jan 6 06:24:14 g1-253 kernel: source line =3D 0x00000E4E Jan 6 06:24:14 g1-253 kernel: error data =3D 0x0000000000000E4E Jan 6 06:24:14 g1-253 kernel: branch link =3D 0x0000C1280000C128 Jan 6 06:24:14 g1-253 kernel: interrupt link =3D 0x0000091600000000 Jan 6 06:24:14 g1-253 kernel: time =3D 1199025467 Jan 6 06:24:14 g1-253 kernel: driver status: Jan 6 06:24:14 g1-253 kernel: tx ring 0: qid=3D0 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 1: qid=3D1 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 2: qid=3D2 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 3: qid=3D3 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 4: qid=3D4 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 5: qid=3D5 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 6: qid=3D6 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 7: qid=3D7 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 8: qid=3D8 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 9: qid=3D9 cur=3D28 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 10: qid=3D10 cur=3D1 queued=3D1 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 11: qid=3D11 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 12: qid=3D12 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 13: qid=3D13 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 14: qid=3D14 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 15: qid=3D15 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 16: qid=3D16 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 17: qid=3D17 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 18: qid=3D18 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: tx ring 19: qid=3D19 cur=3D0 queued=3D0 = =20 Jan 6 06:24:14 g1-253 kernel: rx ring: cur=3D32 Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_panicked: controller panicked, iv_= state =3D 5; resetting... Jan 6 06:24:14 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530= 501 Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_tx_data: m=3D0xd2a41500: seqno (25= 152) (64) !=3D ring index (0) ! Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_intr: fatal firmware error Jan 6 06:24:16 g1-253 kernel: firmware error log: Jan 6 06:24:16 g1-253 kernel: error type =3D "SYSASSERT" (0x00000005) Jan 6 06:24:16 g1-253 kernel: program counter =3D 0x0000C210 Jan 6 06:24:16 g1-253 kernel: source line =3D 0x00000E4E Jan 6 06:24:16 g1-253 kernel: error data =3D 0x0000000000000E4E Jan 6 06:24:16 g1-253 kernel: branch link =3D 0x0000C1280000C128 Jan 6 06:24:16 g1-253 kernel: interrupt link =3D 0x0000091600000000 Jan 6 06:24:16 g1-253 kernel: time =3D 1201317618 Jan 6 06:24:16 g1-253 kernel: driver status: Jan 6 06:24:16 g1-253 kernel: tx ring 0: qid=3D0 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 1: qid=3D1 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 2: qid=3D2 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 3: qid=3D3 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 4: qid=3D4 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 5: qid=3D5 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 6: qid=3D6 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 7: qid=3D7 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 8: qid=3D8 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 9: qid=3D9 cur=3D27 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 10: qid=3D10 cur=3D1 queued=3D1 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 11: qid=3D11 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 12: qid=3D12 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 13: qid=3D13 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 14: qid=3D14 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 15: qid=3D15 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 16: qid=3D16 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 17: qid=3D17 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 18: qid=3D18 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: tx ring 19: qid=3D19 cur=3D0 queued=3D0 = =20 Jan 6 06:24:16 g1-253 kernel: rx ring: cur=3D30 Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_panicked: controller panicked, iv_= state =3D 5; resetting... Jan 6 06:24:16 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530= 501 Jan 6 06:24:17 g1-253 kernel: iwn0: iwn_tx_data: m=3D0xd2a36900: seqno (25= 153) (65) !=3D ring index (0) ! Jan 6 06:24:17 g1-253 kernel: iwn0: iwn_intr: fatal firmware error Jan 6 06:24:17 g1-253 kernel: firmware error log: Jan 6 06:24:17 g1-253 kernel: error type =3D "SYSASSERT" (0x00000005) Jan 6 06:24:17 g1-253 kernel: program counter =3D 0x0000C210 Jan 6 06:24:17 g1-253 kernel: source line =3D 0x00000E4E Jan 6 06:24:17 g1-253 kernel: error data =3D 0x0000000000000E4E Jan 6 06:24:17 g1-253 kernel: branch link =3D 0x0000C1280000C128 Jan 6 06:24:17 g1-253 kernel: interrupt link =3D 0x0000091600000000 Jan 6 06:24:17 g1-253 kernel: time =3D 1202473968 Jan 6 06:24:17 g1-253 kernel: driver status: Jan 6 06:24:17 g1-253 kernel: tx ring 0: qid=3D0 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 1: qid=3D1 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 2: qid=3D2 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 3: qid=3D3 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 4: qid=3D4 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 5: qid=3D5 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 6: qid=3D6 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 7: qid=3D7 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 8: qid=3D8 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 9: qid=3D9 cur=3D26 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 10: qid=3D10 cur=3D1 queued=3D1 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 11: qid=3D11 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 12: qid=3D12 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 13: qid=3D13 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 14: qid=3D14 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 15: qid=3D15 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 16: qid=3D16 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 17: qid=3D17 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 18: qid=3D18 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: tx ring 19: qid=3D19 cur=3D0 queued=3D0 = =20 Jan 6 06:24:17 g1-253 kernel: rx ring: cur=3D59 Jan 6 06:24:17 g1-253 kernel: iwn0: iwn_panicked: controller panicked, iv_= state =3D 5; resetting... Jan 6 06:24:17 g1-253 kernel: iwn0: iwn_read_firmware: ucode rev=3D0x08530= 501 =2E.... For the above, this is while running: FreeBSD g1-253.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1475 r276= 694M/276694:1100052: Mon Jan 5 20:04:17 PST 2015 root@g1-253.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 while building the kernel as part of an update to head @r276749. Stable/10: FreeBSD g1-253.catwhisker.org 10.1-STABLE FreeBSD 10.1-STABLE #1434 r27674= 4M/276749:1001505: Tue Jan 6 04:52:54 PST 2015 root@g1-253.catwhisker.= org:/common/S1/obj/usr/src/sys/CANARY i386 has few (if any) problems of that nature in this environment (presently at home). The iwn(4) device shows up as: iwn0@pci0:12:0:0: class=3D0x028000 card=3D0x11218086 chip=3D0x4235808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ultimate N WiFi Link 5300' class =3D network and in dmesg.boot, I see: =2E.. iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at= device 0.0 on pci12 =2E.. wlan0: Ethernet address: 00:21:6a:26:34:c0 iwn0: iwn_read_firmware: ucode rev=3D0x08530501 ifconfig says: iwn0: flags=3D8843 metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=3D21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: associated and: g1-253(11.0-C)[5] ifconfig -v wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 00:21:6a:26:34:c0 inet 172.17.1.253 netmask 0xffff0000 broadcast 172.17.255.255=20 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid lmdhw-net channel 11 (2462 MHz 11g ht/20) bssid 04:18:d6:22:22= :1f regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps -tsn privacy ON deftxkey UNDEF AES-CCM 2:128-bit powersavemode OFF powersavesleep 100 txpower 15 txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 10 11a ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11b ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 11g ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 turboA ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 turboG ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 sturbo ucast NONE mgmt 6 Mb/s mcast 6 Mb/s maxretry 6 11na ucast NONE mgmt 12 MCS mcast 12 MCS maxretry 6 11ng ucast NONE mgmt 2 MCS mcast 2 MCS maxretry 6 half ucast NONE mgmt 3 Mb/s mcast 3 Mb/s maxretry 6 quarter ucast NONE mgmt 1 Mb/s mcast 1 Mb/s maxretry 6 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:11a rssi 7dBm rate 12 Mb/s roam:11b rssi 7dBm rate 1 Mb/s roam:11g rssi 7dBm rate 5 Mb/s roam:turboA rssi 7dBm rate 12 Mb/s roam:turboG rssi 7dBm rate 12 Mb/s roam:sturbo rssi 7dBm rate 12 Mb/s roam:11na rssi 7dBm MCS 1 =20 roam:11ng rssi 7dBm MCS 1 =20 roam:half rssi 7dBm rate 6 Mb/s roam:quarter rssi 7dBm rate 3 Mb/s -pureg protmode CTS ht htcompat ampdu ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi htprotmode RTSCTS -puren -smps -rifs wme -burst -dwds roaming MANUAL bintval 100 AC_BE cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 4 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 94 -acm AC_VO cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm ack cwmin 2 cwmax 3 aifs 2 txopLimit 47 -acm groups: wlan=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 g1-253(11.0-C)[6]=20 [Remember that I mentioned something about "interrupts" up there? The above silliness with the extraneous linefeeds is another symptom of that, I think: I had only hit "Enter" the minimum number of times..] So: what can be done about this? I'm happy to test.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Actions have consequences ... as do inactions. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --DejVYFcqCV4p9T4J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUq/Y7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk70eAP/2U9J9eyb0MEhIuxio1iUUVo cDB2A04QTzyshAKjMtGgdoJ+2WG3x0HafqpaFgRqCL/VSqal+z/fhlYC3LoLXeFo K5vfgIARuAzats1zwHueCOok1dFoyebZFZ7oJ1L/XxdDFEDYrvARh4hUDFkUiZle dtgCnqcfXN8p3hMhZAP62T14v/+8JTrBR07WzJg9MF2cH1QntVlb+sQY0NCY5rKT CdqiiulGuqXAJWE6tyR2XmF2lTbVBpCHGVGJHR/OofUhcJScUAKvsuWqfP5aE9PG iWLV2R72nFYDtnd9VkMVydY33wqxCAE2dF1dirwVyvVnT42U85rgm+6Nlf6j8HTl toMHUqf2Omco0/aFkEYLFgahmkjXO17bXoIEMu5VOgjIxJJYO+IKCUKt2cSQ0fQN ReM6YAd9j6Nl2JNF/CqHSrJ8MGMIX7RvZtQYtpt00M+iUGFyZppSi9IrCJZesWCK wGfBS5jS3+QAv4/1Mlwbs3FV7he8WoFf6Qs0QLCjROldhEkwDb4e/tapJb0qBzEc K4Ky63slsZaXZjUXoWeTT0FndjB95f0l+AHYAp0Y/hsXR6iQoX4sNfHkWrEhifBA aqrlO6tqm2TdGIjhmriu9zZD6noNMTHrdx0MONXE1p/HNTChadLcrgjT1eSvFGKd e8fThyxn1/FRYy9sXhFL =emIL -----END PGP SIGNATURE----- --DejVYFcqCV4p9T4J-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 14:55:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87946E99; Tue, 6 Jan 2015 14:55:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D70B1A92; Tue, 6 Jan 2015 14:55:27 +0000 (UTC) Received: from new-host.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A82EB94F; Tue, 6 Jan 2015 09:55:26 -0500 (EST) Message-ID: <54ABF75D.5060302@FreeBSD.org> Date: Tue, 06 Jan 2015 09:55:25 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Craig Rodrigues , Luigi Rizzo Subject: Re: any primer on running bhyve guests sharing disk with host ? References: <20150103161511.GA94237@onelab2.iet.unipi.it> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 Jan 2015 09:55:26 -0500 (EST) Cc: freebsd-current Current , Neel Natu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:55:27 -0000 On 1/3/15 1:43 PM, Craig Rodrigues wrote: > On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo wrote: > >> Hi, >> in order to do some kernel testing, I would like to run bhyve guests >> using (through NFS, probably) the host's file system. >> diskless(8) is probably one way to go, i was wondering if >> someone has instructions for that. >> Specifically: >> - how to "bhyveload" a kernel (rather than the full disk image); >> as an alternative, given a kernel, something to build an image >> that can be passed to bhyveload >> >> - how to pass the necessary config (rootpath) to the client >> without having to rely on a specialized dhcp server >> >> I used to be familiar with diskless configs, so i can probably sort >> out the server side myself. >> < Neel already covered -h with bhyveload which you can also use with -H to vmrun.sh, though the other way I do this is to NFS export my work tree from the host to the guest so I can run kgdb on the host but do the build / install in the guest itself. > > I don't think there is a way to do exactly what you want. > I would recommend doing the following: > > (1) Enable bvmdebug in your kernel config: > https://wiki.freebsd.org/BHyVe/gdb > This allows you to do kgdb remote debugging into a bhyve VM. At this point it is probably simpler to use the serial port instead. I have hacked up vmrun.sh locally to always create a /dev/nmdm2B device hooked up to com2 and to add 0x80 to the flags for uart1 in device.hints in all my VMs. You can then use kgdb from the host and 'target remote /dev/nmdm2A'. --- /usr/share/examples/bhyve/vmrun.sh 2014-11-20 18:38:34.000000000 -0500 +++ /home/john/bhyve/vmrun.sh 2015-01-06 09:54:47.000000000 -0500 @@ -230,6 +230,9 @@ nextslot=$(($nextslot + 1)) i=$(($i + 1)) done + if kldstat -qm nmdm; then + devargs="$devargs -l com2,/dev/nmdm${vmname}2B" + fi ${FBSDRUN} -c ${cpus} -m ${memsize} ${apic_opt} -A -H -P \ -g ${gdbport} \ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 14:56:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76BC7B2; Tue, 6 Jan 2015 14:56:16 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 370111AC5; Tue, 6 Jan 2015 14:56:15 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AAF6E1FE022; Tue, 6 Jan 2015 15:56:07 +0100 (CET) Message-ID: <54ABF7B7.6090007@selasky.org> Date: Tue, 06 Jan 2015 15:56:55 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , FreeBSD Current , markb@mellanox.com Subject: Re: [RFC] Start SMP subsystem earlier References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> In-Reply-To: <54ABF32A.6010409@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:56:16 -0000 On 01/06/15 15:37, John Baldwin wrote: > We need a lot more work before this is ready. This is one of the goals > of the multipass new-bus stuff. In particular, we have to enumerate > enough devices to bring event timer hardware up so that timer interrupts > work so that tsleep() will actually sleep. In addition, we also need > idle threads created and working before APs are started as otherwise > they will have no thread to run initially. This is certainly a desired > feature, but it is not as simple as moving the sysinit up I'm afraid. Got it. Thank you! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 15:12:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7A897E7; Tue, 6 Jan 2015 15:12:17 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B88F1E59; Tue, 6 Jan 2015 15:12:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t06FCBOD072920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 17:12:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t06FCBOD072920 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t06FCBKd072919; Tue, 6 Jan 2015 17:12:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Jan 2015 17:12:11 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: [RFC] Start SMP subsystem earlier Message-ID: <20150106151211.GH42409@kib.kiev.ua> References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ABF32A.6010409@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Hans Petter Selasky , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:12:18 -0000 On Tue, Jan 06, 2015 at 09:37:30AM -0500, John Baldwin wrote: > On 1/5/15 8:18 AM, Hans Petter Selasky wrote: > > Hi, > > > > There is a limitiation on the number of interrupt vectors available when > > only a single processor is running. To have more interrupts available we > > need to start SMP earlier when building a monotolith kernel and not > > loading drivers as modules. The driver in question is a network driver > > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE > > support I see no other option than to move SI_SUB_SMP earlier. > > > > Suggested patch: > > > >> Index: sys/kernel.h > >> =================================================================== > >> --- sys/kernel.h (revision 276691) > >> +++ sys/kernel.h (working copy) > >> @@ -152,6 +152,7 @@ > >> SI_SUB_KPROF = 0x9000000, /* kernel profiling*/ > >> SI_SUB_KICK_SCHEDULER = 0xa000000, /* start the timeout > >> events*/ > >> SI_SUB_INT_CONFIG_HOOKS = 0xa800000, /* Interrupts enabled > >> config */ > >> + SI_SUB_SMP = 0xa850000, /* start the APs*/ > >> SI_SUB_ROOT_CONF = 0xb000000, /* Find root devices */ > >> SI_SUB_DUMP_CONF = 0xb200000, /* Find dump devices */ > >> SI_SUB_RAID = 0xb380000, /* Configure GEOM classes */ > >> @@ -165,7 +166,6 @@ > >> SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ > >> SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ > >> SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ > >> - SI_SUB_SMP = 0xf000000, /* start the APs*/ > >> SI_SUB_RACCTD = 0xf100000, /* start racctd*/ > >> SI_SUB_LAST = 0xfffffff /* final initialization */ > >> }; > > > > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we > > need to move the SMP even earlier to not miss the generic FreeBSD PCI > > device enumeration or maybe this is not possible. Does anyone know how > > early we can start SMP? > > We need a lot more work before this is ready. This is one of the goals > of the multipass new-bus stuff. In particular, we have to enumerate > enough devices to bring event timer hardware up so that timer interrupts > work so that tsleep() will actually sleep. In addition, we also need > idle threads created and working before APs are started as otherwise > they will have no thread to run initially. This is certainly a desired > feature, but it is not as simple as moving the sysinit up I'm afraid. > I believe that idle threads are still created before the APs start with the patch posted, this was the thing I checked first. It is SUB_SCHED_IDLE, which is done long before even drivers are configured. From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 15:55:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CCC3ECD; Tue, 6 Jan 2015 15:55:20 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E678127A2; Tue, 6 Jan 2015 15:55:19 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y8WTV-000KPb-KP; Tue, 06 Jan 2015 15:55:18 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t06FtFAG040316; Tue, 6 Jan 2015 08:55:15 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19VA/Av/rKVML1X7clwPwxr Message-ID: <1420559715.14601.25.camel@freebsd.org> Subject: Re: [RFC] Start SMP subsystem earlier From: Ian Lepore To: John Baldwin Date: Tue, 06 Jan 2015 08:55:15 -0700 In-Reply-To: <54ABF32A.6010409@FreeBSD.org> References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:55:20 -0000 On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: > On 1/5/15 8:18 AM, Hans Petter Selasky wrote: > > Hi, > > > > There is a limitiation on the number of interrupt vectors available when > > only a single processor is running. To have more interrupts available we > > need to start SMP earlier when building a monotolith kernel and not > > loading drivers as modules. The driver in question is a network driver > > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE > > support I see no other option than to move SI_SUB_SMP earlier. > > > > Suggested patch: > > > >>[...] > > > > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we > > need to move the SMP even earlier to not miss the generic FreeBSD PCI > > device enumeration or maybe this is not possible. Does anyone know how > > early we can start SMP? > > We need a lot more work before this is ready. This is one of the goals > of the multipass new-bus stuff. In particular, we have to enumerate > enough devices to bring event timer hardware up so that timer interrupts > work so that tsleep() will actually sleep. In addition, we also need > idle threads created and working before APs are started as otherwise > they will have no thread to run initially. This is certainly a desired > feature, but it is not as simple as moving the sysinit up I'm afraid. > Just an FYI, the ARM world is now using the multipass newbus stuff. It works well, with some quirks... The predefined pass names don't always makes sense for the arm world. There aren't enough predefined pass names and even though the number space for them is 4 billion wide all the predefined names are in the range < 100 and separated by only 10 so it's tricky to wedge things between the existing names. The strangest bit is when you have interdependent drivers at different early pass numbers. Sometimes it's necessary to do almost nothing in the attach() routine and do all the real attach-time type stuff in a bus_new_pass() routine after the pass number becomes high enough that your co-dependent driver peers are available. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 15:57:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E655B261; Tue, 6 Jan 2015 15:57:30 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7990C285A; Tue, 6 Jan 2015 15:57:30 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id k11so9880862wes.34; Tue, 06 Jan 2015 07:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g/blWvkMEWWOjnUyA8cWzNat/dnaSBvep2uZWMFYRsI=; b=ucvJi3+2sFLyP8HQePm8ZX5w6P9YnRh2AlNHKeTltdcDYZEhL2RuD+Lebx+jg6M+LV RQ5JTM8NrTa5xQ1dlzSOwknE24QQSKYivyrR4vwkMIGP9tmh7SjMReDh6ndpr1t18SHU vu82R3vG5xJaopmxSsYFPAsUPljswQcDprlPomIMdeTqvAUUCHvEXEkZrb1tNS8FFELP 06gl6LRRPKX5nTtIA5lljChsPEk5wloZACCFk4i3ldme9OG4gMEthZOlm1lVbnCQ1SaT /x+4n/uPdtQYaTL2I744vrETXxYlmpHTcmn3pmFbPnxE/V7plfasmC1EEEOmVXQBAtk0 w+Uw== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr189340697wjb.68.1420559848802; Tue, 06 Jan 2015 07:57:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 07:57:28 -0800 (PST) In-Reply-To: <1420559715.14601.25.camel@freebsd.org> References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> <1420559715.14601.25.camel@freebsd.org> Date: Tue, 6 Jan 2015 07:57:28 -0800 X-Google-Sender-Auth: eQKsSs6iB3qqDYJNccG1zMZ0Cn0 Message-ID: Subject: Re: [RFC] Start SMP subsystem earlier From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:57:31 -0000 On 6 January 2015 at 07:55, Ian Lepore wrote: > On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: >> On 1/5/15 8:18 AM, Hans Petter Selasky wrote: >> > Hi, >> > >> > There is a limitiation on the number of interrupt vectors available when >> > only a single processor is running. To have more interrupts available we >> > need to start SMP earlier when building a monotolith kernel and not >> > loading drivers as modules. The driver in question is a network driver >> > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE >> > support I see no other option than to move SI_SUB_SMP earlier. >> > >> > Suggested patch: >> > >> >>[...] >> > >> > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we >> > need to move the SMP even earlier to not miss the generic FreeBSD PCI >> > device enumeration or maybe this is not possible. Does anyone know how >> > early we can start SMP? >> >> We need a lot more work before this is ready. This is one of the goals >> of the multipass new-bus stuff. In particular, we have to enumerate >> enough devices to bring event timer hardware up so that timer interrupts >> work so that tsleep() will actually sleep. In addition, we also need >> idle threads created and working before APs are started as otherwise >> they will have no thread to run initially. This is certainly a desired >> feature, but it is not as simple as moving the sysinit up I'm afraid. >> > > Just an FYI, the ARM world is now using the multipass newbus stuff. It > works well, with some quirks... > > The predefined pass names don't always makes sense for the arm world. > There aren't enough predefined pass names and even though the number > space for them is 4 billion wide all the predefined names are in the > range < 100 and separated by only 10 so it's tricky to wedge things > between the existing names. Maybe we need a RENUM script? :) -adrian > > The strangest bit is when you have interdependent drivers at different > early pass numbers. Sometimes it's necessary to do almost nothing in > the attach() routine and do all the real attach-time type stuff in a > bus_new_pass() routine after the pass number becomes high enough that > your co-dependent driver peers are available. > > -- Ian > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 16:01:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DF324CE; Tue, 6 Jan 2015 16:01:48 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 219F42A16; Tue, 6 Jan 2015 16:01:47 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Y8WZg-000BOs-TL; Tue, 06 Jan 2015 16:01:41 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t06G1dJv040389; Tue, 6 Jan 2015 09:01:39 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Cm/DAOYpyqzl8CEJMZF5B Message-ID: <1420560099.14601.28.camel@freebsd.org> Subject: Re: [RFC] Start SMP subsystem earlier From: Ian Lepore To: Adrian Chadd Date: Tue, 06 Jan 2015 09:01:39 -0700 In-Reply-To: References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> <1420559715.14601.25.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:01:48 -0000 On Tue, 2015-01-06 at 07:57 -0800, Adrian Chadd wrote: > On 6 January 2015 at 07:55, Ian Lepore wrote: > > On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: > >> On 1/5/15 8:18 AM, Hans Petter Selasky wrote: > >> > Hi, > >> > > >> > There is a limitiation on the number of interrupt vectors available when > >> > only a single processor is running. To have more interrupts available we > >> > need to start SMP earlier when building a monotolith kernel and not > >> > loading drivers as modules. The driver in question is a network driver > >> > and because it cannot be started after SI_SUB_ROOT_CONF due to PXE > >> > support I see no other option than to move SI_SUB_SMP earlier. > >> > > >> > Suggested patch: > >> > > >> >>[...] > >> > > >> > This fixes a problem for Mellanox drivers in the OFED layer. Possibly we > >> > need to move the SMP even earlier to not miss the generic FreeBSD PCI > >> > device enumeration or maybe this is not possible. Does anyone know how > >> > early we can start SMP? > >> > >> We need a lot more work before this is ready. This is one of the goals > >> of the multipass new-bus stuff. In particular, we have to enumerate > >> enough devices to bring event timer hardware up so that timer interrupts > >> work so that tsleep() will actually sleep. In addition, we also need > >> idle threads created and working before APs are started as otherwise > >> they will have no thread to run initially. This is certainly a desired > >> feature, but it is not as simple as moving the sysinit up I'm afraid. > >> > > > > Just an FYI, the ARM world is now using the multipass newbus stuff. It > > works well, with some quirks... > > > > The predefined pass names don't always makes sense for the arm world. > > There aren't enough predefined pass names and even though the number > > space for them is 4 billion wide all the predefined names are in the > > range < 100 and separated by only 10 so it's tricky to wedge things > > between the existing names. > > Maybe we need a RENUM script? :) > I wanted to renumber them but it was pointed out to me that the existing names and numbers are part of the ABI and we're not free to do so except on -current, and that would make all related work going forward ineligible for MFC. (Personally, I'm a bit skeptical that there's any big out-of-tree use of the existing names/numbers.) -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 16:10:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C27087D; Tue, 6 Jan 2015 16:10:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6DF52B0D; Tue, 6 Jan 2015 16:10:03 +0000 (UTC) Received: from new-host.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C724CB913; Tue, 6 Jan 2015 11:10:00 -0500 (EST) Message-ID: <54AC08D7.4030800@FreeBSD.org> Date: Tue, 06 Jan 2015 11:09:59 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [RFC] Start SMP subsystem earlier References: <54AA8F19.9030300@selasky.org> <54ABF32A.6010409@FreeBSD.org> <1420559715.14601.25.camel@freebsd.org> In-Reply-To: <1420559715.14601.25.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 Jan 2015 11:10:00 -0500 (EST) Cc: Hans Petter Selasky , markb@mellanox.com, FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:10:04 -0000 On 1/6/15 10:55 AM, Ian Lepore wrote: > On Tue, 2015-01-06 at 09:37 -0500, John Baldwin wrote: >> On 1/5/15 8:18 AM, Hans Petter Selasky wrote: >>> Hi, >>> >>> There is a limitiation on the number of interrupt vectors available when >>> only a single processor is running. To have more interrupts available we >>> need to start SMP earlier when building a monotolith kernel and not >>> loading drivers as modules. The driver in question is a network driver >>> and because it cannot be started after SI_SUB_ROOT_CONF due to PXE >>> support I see no other option than to move SI_SUB_SMP earlier. >>> >>> Suggested patch: >>> >>>> [...] >>> >>> This fixes a problem for Mellanox drivers in the OFED layer. Possibly we >>> need to move the SMP even earlier to not miss the generic FreeBSD PCI >>> device enumeration or maybe this is not possible. Does anyone know how >>> early we can start SMP? >> >> We need a lot more work before this is ready. This is one of the goals >> of the multipass new-bus stuff. In particular, we have to enumerate >> enough devices to bring event timer hardware up so that timer interrupts >> work so that tsleep() will actually sleep. In addition, we also need >> idle threads created and working before APs are started as otherwise >> they will have no thread to run initially. This is certainly a desired >> feature, but it is not as simple as moving the sysinit up I'm afraid. >> > > Just an FYI, the ARM world is now using the multipass newbus stuff. It > works well, with some quirks... > > The predefined pass names don't always makes sense for the arm world. > There aren't enough predefined pass names and even though the number > space for them is 4 billion wide all the predefined names are in the > range < 100 and separated by only 10 so it's tricky to wedge things > between the existing names. > > The strangest bit is when you have interdependent drivers at different > early pass numbers. Sometimes it's necessary to do almost nothing in > the attach() routine and do all the real attach-time type stuff in a > bus_new_pass() routine after the pass number becomes high enough that > your co-dependent driver peers are available. Yes, I almost want another downcall through the tree that is something like 'bus_pass_completed', though the original design was to override bus_new_pass as you have done. And yes, in many cases the logic needs to move out of attach. The pci bus will end up only doing enumeration but no resource assignment in its attach routine once things are fleshed out more for example. However, for now I've found that even on x86 I've had to add a new pass level for ACPI and some other things like acpi_sysresource. :( It almost wants more of a provides-requires setup than hardcoded pass levels, but that's more complicated to implement. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 20:22:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F27ECE38 for ; Tue, 6 Jan 2015 20:22:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E08C523C for ; Tue, 6 Jan 2015 20:22:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E4B57335 for ; Tue, 6 Jan 2015 20:22:19 +0000 (UTC) Date: Tue, 6 Jan 2015 20:22:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1450230080.2.1420575739521.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <790549503.58.1420468062275.JavaMail.jenkins@jenkins-9.freebsd.org> References: <790549503.58.1420468062275.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #521 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:22:20 -0000 See From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 20:03:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DA74C1B; Tue, 6 Jan 2015 20:03:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 91F1264ABA; Tue, 6 Jan 2015 19:07:18 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id ED7C526D; Tue, 6 Jan 2015 19:07:17 +0000 (UTC) Date: Tue, 6 Jan 2015 19:07:10 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, imp@FreeBSD.org, emaste@FreeBSD.org, loos@FreeBSD.org, markj@FreeBSD.org, ngie@FreeBSD.org, adrian@FreeBSD.org, rodrigc@FreeBSD.org, np@FreeBSD.org, rwatson@FreeBSD.org, jhb@FreeBSD.org, trasz@FreeBSD.org, jhibbits@FreeBSD.org, marius@FreeBSD.org, nwhitehorn@FreeBSD.org, hselasky@FreeBSD.org, br@FreeBSD.org Message-ID: <317937692.1.1420571236060.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2167 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Tue, 06 Jan 2015 20:25:02 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:03:51 -0000 See From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 23:10:51 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B9F4479; Tue, 6 Jan 2015 23:10:51 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1C3EDE3; Tue, 6 Jan 2015 23:10:50 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so6361876wiv.12; Tue, 06 Jan 2015 15:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lnrLaNsFaFkFMjelQPyk8KgJabfGUzCgSP1eLfyynQA=; b=gIiFWNj8dhfoG5SQdojgEn9V0RR0wVnZlg/AF42yCruGfy/hU3Q9ulfb9pfEndkJ43 h0NqmBrFVDXFe2d23unjDJu4uQDmtVdlIVO69J0YllD/tCFg/hXlkefoZsaxhpkSsZ3B hnH4+bY/yyq1Aq2RAo5j/Np5cOpyCO1TfG7w9nZTstPf1pYI4TU3zwnecW7qM5HcormY 23sU/xfz2QW3c/FYJzuHrT54Dj3hgvVtPKN9sKosMbmpPWWxvJx3o6g4lzbLm2lblU7W E/Uz5fE/fQLwRWRyj0u7f86sK4GBxr2jOlZEo+OjyHH1Xbm34Dqt1OA9i4KkEcI+PbFd 6hrw== MIME-Version: 1.0 X-Received: by 10.180.73.108 with SMTP id k12mr1275504wiv.24.1420585849407; Tue, 06 Jan 2015 15:10:49 -0800 (PST) Received: by 10.217.118.194 with HTTP; Tue, 6 Jan 2015 15:10:49 -0800 (PST) In-Reply-To: <54A9A71E.70609@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> Date: Tue, 6 Jan 2015 16:10:49 -0700 Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Jason Wolfe To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 06 Jan 2015 23:19:49 +0000 Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:10:51 -0000 On Sun, Jan 4, 2015 at 1:48 PM, Hans Petter Selasky wrote: > On 01/04/15 19:58, Adrian Chadd wrote: >> >> Hi! >> >> Can you throw this into reviews.freebsd.org please? This is something >> that should be very closely reviewed and tested. >> >> (I'm going to go over this quite closely as it related to a lot of the >> random crap I do ..) >> > > Hi Adrian, > > Here you go: > > https://reviews.freebsd.org/D1438 > > Thank you for your time to review this! > > > --HPS Hans, We've been running into 'spin lock held too long' panics in the kernel idle threads on 10-STABLE over the past 6 months, so I was interested to see your work here in the callout code. I went ahead and brought this patch back to a recent 10.1-STABLE base without much issue, kern_timeout.c was actually the only piece with some easily resolvable rejections. I've had a box running stable under load with this patch for a few days, and 10 more have just been added to the rotation. Anyway just figured you might be interested in the some feedback while the changes are reviewed. Thanks! Jason From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 05:59:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D956DC38; Wed, 7 Jan 2015 05:59:03 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD9EEF0; Wed, 7 Jan 2015 05:59:03 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-233-252.lns20.per1.internode.on.net [121.45.233.252]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t075wsEK007209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 Jan 2015 21:58:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54ACCB18.4060107@freebsd.org> Date: Wed, 07 Jan 2015 13:58:48 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , Craig Rodrigues , Luigi Rizzo Subject: Re: any primer on running bhyve guests sharing disk with host ? References: <20150103161511.GA94237@onelab2.iet.unipi.it> <54ABF75D.5060302@FreeBSD.org> In-Reply-To: <54ABF75D.5060302@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current Current , Neel Natu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 05:59:04 -0000 On 1/6/15 10:55 PM, John Baldwin wrote: > On 1/3/15 1:43 PM, Craig Rodrigues wrote: >> On Sat, Jan 3, 2015 at 8:15 AM, Luigi Rizzo wrote: >> >>> Hi, >>> in order to do some kernel testing, I would like to run bhyve guests >>> using (through NFS, probably) the host's file system. >>> diskless(8) is probably one way to go, i was wondering if >>> someone has instructions for that. >>> Specifically: >>> - how to "bhyveload" a kernel (rather than the full disk image); >>> as an alternative, given a kernel, something to build an image >>> that can be passed to bhyveload >>> >>> - how to pass the necessary config (rootpath) to the client >>> without having to rely on a specialized dhcp server >>> >>> I used to be familiar with diskless configs, so i can probably sort >>> out the server side myself. >>> > < Neel already covered -h with bhyveload which you can also use with -H > to vmrun.sh, though the other way I do this is to NFS export my work > tree from the host to the guest so I can run kgdb on the host but do the > build / install in the guest itself. > > >> I don't think there is a way to do exactly what you want. >> I would recommend doing the following: >> >> (1) Enable bvmdebug in your kernel config: >> https://wiki.freebsd.org/BHyVe/gdb >> This allows you to do kgdb remote debugging into a bhyve VM. > At this point it is probably simpler to use the serial port instead. I > have hacked up vmrun.sh locally to always create a /dev/nmdm2B > device hooked up to com2 and to add 0x80 to the flags for uart1 in > device.hints in all my VMs. You can then use kgdb from the host and > 'target remote /dev/nmdm2A'. I've found the main good part of using bvmdebug is the ability to attach to it from a different machine using tcp. I think bhyve should offer the opportunity to make ALL serial ports or similar be attached to sockets.. > > --- /usr/share/examples/bhyve/vmrun.sh 2014-11-20 18:38:34.000000000 -0500 > +++ /home/john/bhyve/vmrun.sh 2015-01-06 09:54:47.000000000 -0500 > @@ -230,6 +230,9 @@ > nextslot=$(($nextslot + 1)) > i=$(($i + 1)) > done > + if kldstat -qm nmdm; then > + devargs="$devargs -l com2,/dev/nmdm${vmname}2B" > + fi > > ${FBSDRUN} -c ${cpus} -m ${memsize} ${apic_opt} -A -H -P \ > -g ${gdbport} \ > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 06:01:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD4EBE44; Wed, 7 Jan 2015 06:01:23 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 97A16FC3; Wed, 7 Jan 2015 06:01:22 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 89CE28C389; Wed, 7 Jan 2015 06:01:16 +0000 (UTC) Message-ID: <54ACCBB3.1080906@freebsd.org> Date: Wed, 07 Jan 2015 01:01:23 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org, kib@freebsd.org Subject: i915 crash Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5Ir4PV4FMnOpOSWQtk3hPjtxPMKxVf2BH" Cc: "grembo@freebsd.org >> Michael Gmelin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 06:01:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Ir4PV4FMnOpOSWQtk3hPjtxPMKxVf2BH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I grabbed the latest i915.8.patch from kib@'s website and compiled it against r276774 (today) Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled. CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (2594.16-MHz K8-class CPU) It is an Ivy-bridge CPU/GPU I installed xorg and kde, and when I try to start KDE, it loads, and gets so far as showing the FreeBSD wallpaper, then panics: text dump: http://www.allanjude.com/bsd/i915_core.3.txt Full dump: (26mb compressed, 740mb original) http://www.allanjude.com/bsd/i915_vmcore.3.xz Unread portion of the kernel message buffer: panic: In GPU write domain cpuid =3D 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe045e52e600 vpanic() at vpanic+0x189/frame 0xfffffe045e52e680 kassert_panic() at kassert_panic+0x132/frame 0xfffffe045e52e6f0 i915_gem_pread_ioctl() at i915_gem_pread_ioctl+0x678/frame 0xfffffe045e52e790 drm_ioctl() at drm_ioctl+0x318/frame 0xfffffe045e52e800 devfs_ioctl_f() at devfs_ioctl_f+0x122/frame 0xfffffe045e52e860 kern_ioctl() at kern_ioctl+0x2c0/frame 0xfffffe045e52e8c0 sys_ioctl() at sys_ioctl+0x153/frame 0xfffffe045e52e9a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe045e52eab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe045e52eab0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x8022a56fa, rsp =3D 0x7fffffffe718, rbp =3D 0x7fffffffe740 --- KDB: enter: panic Uptime: 9m19s Dumping 739 out of 16176 MB:..3%..11%..22%..31%..42%..52%..61%..72%..81%..91% Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 ) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3DUnhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0xffffffff80965d27 in kern_reboot (howto=3DUnhandled dwarf expression= opcode 0x93 ) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80966318 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff80966142 in kassert_panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:635 #4 0xffffffff81e1de88 in i915_gem_pread_ioctl (dev=3D0xfffff8002ffd1000,= data=3D0xfffffe045e52e8f0, file=3D) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010 #5 0xffffffff81e9a398 in drm_ioctl (kdev=3D, cmd=3D2149606492, data=3D0xfffffe045e52e8f0 "y", flags=3DUnhandled dw= arf expression opcode 0x93 ) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942 #6 0xffffffff80849942 in devfs_ioctl_f (fp=3D0xfffff80009c15690, com=3D2149606492, data=3D0xfffffe045e52e8f0, cred=3D0xfffffe045e52e8f= 0, td=3D0xfffff80009c74000) at /usr/src/sys/fs/devfs/devfs_vnops.c:775 #7 0xffffffff809c3ad0 in kern_ioctl (td=3D0xfffff80009c74000, fd=3D, com=3D0, data=3D) at= file.h:318 #8 0xffffffff809c3763 in sys_ioctl (td=3D0xfffff80009c74000, uap=3D0xfffffe045e52ea40) at /usr/src/sys/kern/sys_generic.c:718 #9 0xffffffff80d8590a in amd64_syscall (td=3D0xfffff80009c74000, traced=3D= 0) at subr_syscall.c:133 #10 0xffffffff80d632ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #11 0x00000008022a56fa in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal --=20 Allan Jude --5Ir4PV4FMnOpOSWQtk3hPjtxPMKxVf2BH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUrMuzAAoJEJrBFpNRJZKfwqMP/A/QkMq1iFfNutzwmGNGbELK MD+9ceiX8BsOFSZHsmTnJQwSdEfUXXst6wCVPq04RXe96svwJ/ujwFr38dQDWSLg 1YnUpaPV2mP2kKJrBLpZDgDAkghXWOpgdPDeIvRIqTUdMqV9ZdNksXQX6lB2+vOp eYiqYLMV/dvq5YO7aIojVLVMeA2fCAsngZNF3jPxGM2fUjd26g4b+1gsrDjjaHAT /mqLsGff0DecdKaLDOsxKPZuO966a+/SZB0tF3y/lHGdRQFHpMO4cNJ9t1yJ3N8z MXueMdjQMMAKVgAWj7y4IZygc9iER7sxGZy2q9FFt7o10Yxa9iCx4vt9TAo3yPu6 cDmUT1TFMTtoSTScialpfwe2Aaxuid7Do5dPTzUd/W92X9vjkc0IjqP+oVMKFtDR NrtcvxJSyOpJqTz4xbQmTmfw/m2ugUGa6k3SjizRe1JqKObk304KIUZRVAZG4vU3 iJCodT7PnBKyJmX+XBLIHfP28YFxz63F9Xpl8A9dlWST09obxG/zZSo0Id60BM+W k6kf19FTI40+w4g3wqZ1s0fB/9Z1dpGbk8CXbn6iz2me2EDF6xqC+cGzAWZmVN7t mSzhIUCNn/dPP4yhTX+aD1fD7+nmFxQp/J7EXYQ6yZ23dql1Dof8qNrIGSXW3eDL bd4DbzTMdoEn8OKtVQh/ =jaNq -----END PGP SIGNATURE----- --5Ir4PV4FMnOpOSWQtk3hPjtxPMKxVf2BH-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 08:33:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50299250; Wed, 7 Jan 2015 08:33:43 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0785C66582; Wed, 7 Jan 2015 08:33:42 +0000 (UTC) Received: from [89.204.130.178] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Y8m3Z-0005s4-1v; Wed, 07 Jan 2015 09:33:33 +0100 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id t078XUL8002231; Wed, 7 Jan 2015 09:33:30 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id t078XTKc002230; Wed, 7 Jan 2015 09:33:29 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Wed, 7 Jan 2015 09:33:29 +0100 From: Matthias Apitz To: freebsd-mobile@freebsd.org Subject: Acer C720 Chromebook (was: Re: looking for new netbook) Message-ID: <20150107083329.GA2063@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-mobile@freebsd.org, freebsd-current@freebsd.org References: <20141127094342.GA1628@unixarea.DDR.dd> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141127094342.GA1628@unixarea.DDR.dd> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.130.178 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 08:33:43 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit El día Thursday, November 27, 2014 a las 10:43:42AM +0100, Matthias Apitz escribió: > I'm looking for a new netbook laptop; my old EeePC 900 (from 2008) has > to short battery time, and the Acer Aspire One D250 has a problem with the > display (from time to time goes completely white, the system is running, > but one has to reboot to get an image again); > > What I want is more or less: > > -- 1-2 GByte RAM > -- 1024x600 display, ~10 inch > -- 50++ GByte SSD disk > -- normal QWERTY/Z keyboard (i.o. no tablet) > -- Wifi supported in head > -- USB ports for UMTS dongle > -- and of course, it should run FreeBSD; > > Any pointers to a modern device? Some week ago I have asked the above question and with the free time during the change of the year I can now answer it an I want to share some experiences: I found the Acer C720 Chromebook with the following technical data: -- 2 GByte RAM (soldered on board, not update-able) -- 2 core CPU, each 1.4 GHz -- display 1366x768, ~11 inch, very nicely support by Xorg VESA driver -- Wifi Atheros AR946x/AR948x, supported by ah(4) -- sound supported by snd_hda(4) -- 16 GByte SSD, can be swapped by, for example, MTS400 M.2 SSD 128GB SATA III, MLC (128 GByte) I will attach a dmesg output; The problem was: 1. It needs take apart the device to unlock the BIOS protection to be able to use a SeaBIOS for legacy boot from SSD or USB; 2. One needs some patches against -HEAD; All this is very good documented by the author of the patches, Michael Gmelin, in his blog: http://blog.grem.de/pages/c720.html Thanks to him for this work and his helping hand during my first steps with this nice device. I think, the patches should be incorporated into SVN, at the moment they are against -HEAD as of January 5th. The keyboard of the C720, in principle a normal PC105, mine with German layout QWERTZ, is a bit tricky: it has - only F-keys from F1 to F10 and they are labeled with symbols for the ChromeOS applications; - no hardware power-off (only by an ACPI key which is situated where F11 would be, i.e. right above the Backspace key, you see the risk :-) ) - no Windows key which could be used as Modifier-key in X11; - no PageUP/DOWN keys - no 'blue Fn' key for additional functions (like audio or brightnes) In his blog Michael documents as well ways to help out of this. It now runs very nicely -HEAD (still booted from an USB stick because I'm waiting for the 128 GByte SSD to swap it). I'm really surprised about the battery: lasts for 6-8 hours. Wow!!! HIH matthias -- Matthias Apitz, guru@unixarea.de, http://www.unixarea.de/ +49-170-4527211 1989-2014: The Wall was torn down so that we go to war together again. El Muro ha sido derribado para que nos unimos en ir a la guerra otra vez. Diese Grenze wurde aufgehoben damit wir gemeinsam wieder in den Krieg ziehen. --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="dmesg.c720" Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r272526M: Thu Jan 1 05:30:48 CET 2015 guru@vm-poudriere-r269739:/usr/local/acerC720/obj/usr/local/acerC720/src/sys/GENERIC i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.79-MHz 686-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x45daebbf,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,RDRAND> AMD Features=0x2c100000 AMD Features2=0x21 Structured Extended Features=0x2603 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 2079817728 (1983 MB) avail memory = 2014519296 (1921 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0 irqs 0-39 on motherboard kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0f98550, 0) error 19 random: initialized acpi0: on motherboard acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x77 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: irq 37 on acpi0 acpi_button2: irq 38 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x183f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff at device 2.0 on pci0 vgapci0: Boot video device hdac0: mem 0xe0510000-0xe0513fff at device 3.0 on pci0 xhci0: mem 0xe0500000-0xe050ffff at device 20.0 on pci0 xhci0: 32 byte context size. xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 pci0: at device 21.0 (no driver attached) pci0: at device 21.1 (no driver attached) pci0: at device 21.2 (no driver attached) hdac1: mem 0xe0514000-0xe0517fff at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 ath0: mem 0xe0400000-0xe047ffff at device 0.0 on pci1 ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 1638.7 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 ehci0: mem 0xe051f800-0xe051fbff at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1860-0x1867,0x1870-0x1873,0x1868-0x186f,0x1874-0x1877,0x1840-0x185f mem 0xe051f000-0xe051f7ff irq 22 at device 31.2 on pci0 ahci0: AHCI v1.30 with 2 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 uart0: <8250 or 16450 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 ppc0: parallel port not found. est0: on cpu0 est1: on cpu1 Timecounters tick every 1.000 msec IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 hdaa1: hdaa_audio_as_parse: Pin 26 has wrong direction for association 1! Disabling association. hdaa1: hdaa_audio_as_parse: Pin 33 has wrong direction for association 2! Disabling association. random: unblocking device. usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: <0x8086> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 13 ports with 13 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 ugen1.2: at usbus1 uhub2: on usbus1 uhub2: 8 ports with 8 removable, self powered usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-10 SATA 3.x device ada0: Serial Number 50026B723A00B1B7 ada0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 15272MB (31277232 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1396794312 Hz quality 1000 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen0.3: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:3:0: Attached to scbus3 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 11082000053285 da0: 40.000MB/s transfers da0: 7560MB (15482880 512 byte sectors: 255H 63S/T 963C) da0: quirks=0x2 wlan0: Ethernet address: 80:56:f2:83:c1:17 wlan0: link state changed to UP --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 10:42:58 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C2267A2 for ; Wed, 7 Jan 2015 10:42:58 +0000 (UTC) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D65546682A for ; Wed, 7 Jan 2015 10:42:57 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id 9so470862ykp.36 for ; Wed, 07 Jan 2015 02:42:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1V2Db0fju1SjVFoc8l2dyQEcv/RNC+KGELAzReMfv3I=; b=AeKRQPHgT83giW+GZK5p9zabRGZt0cc4URNF2pBCQj0jCyZJfnx9792qIHl1oancgT M1QCxQpKcKKxQeUyRp4xSqxJ/EMOjPvXoLNnqkqLp4b23wu9vO9kWrzmLLsgUVOf2dFH iueZkHoV+lYLFW1YQQyLuSZZcifP4Jp5+mGr+tOFQYSkZ/0EXcrZJ+Y8gjxs7BCC007J Di2O/VaoHKK32p1qRMMDjr1xuu8k6LZCoQFypvuqJ8lSy6UcNdpRHYGIvIXJG/WC+m4v 5Hfcwd0m+c0ThdwjC6811dHGAdOI/x5BWzV6J895Bo6+gszccgZ8RIF9hORK04/SpphT eDRA== X-Gm-Message-State: ALoCoQlq0n0smIMBvLb9s1Y6idxRqAWX7PUBy3lMA7Y8L8zyGQlzdZPcBc74gQm9TF1APA4cPVFK MIME-Version: 1.0 X-Received: by 10.236.203.193 with SMTP id f41mr1541136yho.191.1420627371746; Wed, 07 Jan 2015 02:42:51 -0800 (PST) Received: by 10.170.46.213 with HTTP; Wed, 7 Jan 2015 02:42:51 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Jan 2015 11:42:51 +0100 Message-ID: Subject: Re: sendmail make distribution error and fix From: Oliver Pinter To: gshapiro Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 10:42:58 -0000 On 1/7/15, Oliver Pinter wrote: > Hi! > > I got this error, when I try to make distribution*: > > cd /target/usr/src/etc/sendmail; make distribution > install -o root -g wheel -m 644 > /target/usr/src/etc/sendmail/freebsd.mc freebsd.cf /target/etc/mail > install: freebsd.cf: No such file or directory > *** Error code 71 > > Stop. > make[3]: stopped in /target/usr/src/etc/sendmail > *** Error code 1 > > Stop. > make[2]: stopped in /target/usr/src/etc > *** Error code 1 > > Stop. > make[1]: stopped in /target/usr/src > *** Error code 1 > > Stop. > make: stopped in /target/usr/src > > The attached patch fixed the problem. > > *: > #!/usr/bin/env csh > > set MAKEOBJDIRPREFIX="/target/usr/obj" > set SRC_DIR="/target/usr/src" > set DESTDIR="/target" > > cd ${SRC_DIR} > > make -j5 buildworld MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} > make -j5 kernel MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} > > make installworld DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} > make distribution DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} > > cp /etc/make.conf /target/etc/ > cp /etc/src.conf /target/etc/ > cp /etc/rc.conf /target/etc/ > please ignore this report, I found the bug elsewhere... From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 10:45:42 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DC99904 for ; Wed, 7 Jan 2015 10:45:42 +0000 (UTC) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5232366877 for ; Wed, 7 Jan 2015 10:45:42 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id 9so472563ykp.36 for ; Wed, 07 Jan 2015 02:45:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=7q0FslY44v/0zR7HjcjbqPA/g8/O++mH7riZRVMKeXg=; b=io2UimhynCmRa+J+8nI5ymmNCwUE2tR5nqNWsmqY5M6K940Hq7uhlwhhiezWTd20w1 zOG07ZUIVnxhkKTbib3Z/aUjrS9k0xbuF1eP6ljH5Lx2Lz8HA1Mh50wvvl5pSLmK1bXP 5NUP7d+kFd8WFAhmm8XiE3LQDeJTTJwkTv7KiPE/M8fT+3e5ijqY2jagbpvZNTH9fLFI xtD7Rla7sCb7KuYdYmLLQhCO/OBLynODQnVJH7xxlnVGV628K32wLS5EDzJu7i3TEui3 ix1pV6RILCagsJSxgJYFSJshAAvVGMbPArQuM9N2v6d/aORXoBSeJEY0gzwXHiUY7Yuz JDwQ== X-Gm-Message-State: ALoCoQlswT+o7u5f5Ov1BHd2InnmgNr7312ehEz3NuGxswcQ1/adJDN7mj62/PmSenAbhgZK7ucS MIME-Version: 1.0 X-Received: by 10.170.216.131 with SMTP id i125mr1919940ykf.61.1420627151783; Wed, 07 Jan 2015 02:39:11 -0800 (PST) Received: by 10.170.46.213 with HTTP; Wed, 7 Jan 2015 02:39:11 -0800 (PST) Date: Wed, 7 Jan 2015 11:39:11 +0100 Message-ID: Subject: sendmail make distribution error and fix From: Oliver Pinter To: gshapiro Content-Type: multipart/mixed; boundary=001a1139fb00bda25e050c0d8843 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 10:45:42 -0000 --001a1139fb00bda25e050c0d8843 Content-Type: text/plain; charset=UTF-8 Hi! I got this error, when I try to make distribution*: cd /target/usr/src/etc/sendmail; make distribution install -o root -g wheel -m 644 /target/usr/src/etc/sendmail/freebsd.mc freebsd.cf /target/etc/mail install: freebsd.cf: No such file or directory *** Error code 71 Stop. make[3]: stopped in /target/usr/src/etc/sendmail *** Error code 1 Stop. make[2]: stopped in /target/usr/src/etc *** Error code 1 Stop. make[1]: stopped in /target/usr/src *** Error code 1 Stop. make: stopped in /target/usr/src The attached patch fixed the problem. *: #!/usr/bin/env csh set MAKEOBJDIRPREFIX="/target/usr/obj" set SRC_DIR="/target/usr/src" set DESTDIR="/target" cd ${SRC_DIR} make -j5 buildworld MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} make -j5 kernel MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} make installworld DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} make distribution DESTDIR=${DESTDIR} MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX} cp /etc/make.conf /target/etc/ cp /etc/src.conf /target/etc/ cp /etc/rc.conf /target/etc/ --001a1139fb00bda25e050c0d8843 Content-Type: application/octet-stream; name="0001-HBSD-fix-make-distribution.patch" Content-Disposition: attachment; filename="0001-HBSD-fix-make-distribution.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 RnJvbSA0ODUxMWQyMDA4ZWJhMWNhZDQ5OGU5ODg4M2Y3YjA0NjgyZmM3OTExIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBPbGl2ZXIgUGludGVyIDxvbGl2ZXIucG50ckBnbWFpbC5jb20+ CkRhdGU6IFdlZCwgNyBKYW4gMjAxNSAxMTozMzo1NSArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIEhC U0Q6IGZpeCBtYWtlIGRpc3RyaWJ1dGlvbgoKY2QgL3RhcmdldC91c3Ivc3JjL2V0Yy9zZW5kbWFp bDsgbWFrZSBkaXN0cmlidXRpb24KaW5zdGFsbCAtbyByb290IC1nIHdoZWVsIC1tIDY0NCAgL3Rh cmdldC91c3Ivc3JjL2V0Yy9zZW5kbWFpbC9mcmVlYnNkLm1jIGZyZWVic2QuY2YgL3RhcmdldC9l dGMvbWFpbAppbnN0YWxsOiBmcmVlYnNkLmNmOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Cioq KiBFcnJvciBjb2RlIDcxCgpTdG9wLgptYWtlWzNdOiBzdG9wcGVkIGluIC90YXJnZXQvdXNyL3Ny Yy9ldGMvc2VuZG1haWwKKioqIEVycm9yIGNvZGUgMQoKU3RvcC4KbWFrZVsyXTogc3RvcHBlZCBp biAvdGFyZ2V0L3Vzci9zcmMvZXRjCioqKiBFcnJvciBjb2RlIDEKClN0b3AuCm1ha2VbMV06IHN0 b3BwZWQgaW4gL3RhcmdldC91c3Ivc3JjCioqKiBFcnJvciBjb2RlIDEKClN0b3AuCm1ha2U6IHN0 b3BwZWQgaW4gL3RhcmdldC91c3Ivc3JjCjUzMTUuNDExdSA3ODQuMjgxcyAyODo0OC45OCAzNTIu NyUgICAgICAzNTc4OSs4NTRrIDkyMzcrMjE3ODBpbyA3NzBwZiswdwpyb290QHBhbmRvcmEtZCAv dGFyZ2V0IwoKU2lnbmVkLW9mZi1ieTogT2xpdmVyIFBpbnRlciA8b2xpdmVyLnBudHJAZ21haWwu Y29tPgotLS0KIGV0Yy9zZW5kbWFpbC9NYWtlZmlsZSB8IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAx IGluc2VydGlvbigrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2V0Yy9zZW5kbWFpbC9N YWtlZmlsZSBiL2V0Yy9zZW5kbWFpbC9NYWtlZmlsZQppbmRleCBiNzllNzIyLi41Njc2MzgyIDEw MDY0NAotLS0gYS9ldGMvc2VuZG1haWwvTWFrZWZpbGUKKysrIGIvZXRjL3NlbmRtYWlsL01ha2Vm aWxlCkBAIC02Miw3ICs2Miw3IEBAICR7bWM6VDpSfS5jZjogJHttY30KIAogYWxsOiAke0FMTH0K IAotZGlzdHJpYnV0aW9uOgorZGlzdHJpYnV0aW9uOiBmcmVlYnNkLmNmIGZyZWVic2Quc3VibWl0 LmNmCiAJJHtJTlNUQUxMfSAtbyAke0JJTk9XTn0gLWcgJHtCSU5HUlB9IC1tIDY0NCBcCiAJICAg ICR7LkNVUkRJUn0vZnJlZWJzZC5tYyBmcmVlYnNkLmNmICR7REVTVERJUn0vZXRjL21haWwKIAkk e0lOU1RBTEx9IC1vICR7QklOT1dOfSAtZyAke0JJTkdSUH0gLW0gNDQ0IFwKLS0gCjIuMi4xCgo= --001a1139fb00bda25e050c0d8843-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 13:05:14 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AFA850D; Wed, 7 Jan 2015 13:05:14 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E9DF366CD8; Wed, 7 Jan 2015 13:05:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,714,1413270000"; d="asc'?scan'208";a="225705171" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx12-out.netapp.com with ESMTP; 07 Jan 2015 05:03:55 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 7 Jan 2015 05:03:53 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Wed, 7 Jan 2015 05:03:53 -0800 From: "Eggert, Lars" To: Dimitry Andric Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 Thread-Topic: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 Thread-Index: AQHQJTo5/20s5rXTzUyqkX8ruL4BApy1MG2A Date: Wed, 7 Jan 2015 13:03:53 +0000 Message-ID: References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> In-Reply-To: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1993) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A319FEF9-2586-4533-A707-D3D1E8DD75DE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 13:05:14 -0000 --Apple-Mail=_A319FEF9-2586-4533-A707-D3D1E8DD75DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-12-31, at 21:41, Dimitry Andric wrote: > I just committed an upgrade of clang, llvm and lldb to 3.5.0 to head, = in > r276479. there seem to be issues when building with -DWITH_OFED: --- contrib/ofed.all__D --- = /usr/home/elars/src/contrib/ofed/usr.bin/opensm/../../management/opensm/op= ensm/osm_ucast_ftree.c:2996:8: error: taking the absolute value of = unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value] if (abs(p_sw->rank - p_remote_sw->rank) !=3D 1) = { Lars --Apple-Mail=_A319FEF9-2586-4533-A707-D3D1E8DD75DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVK0uudZcnpRveo1xAQIVxwP8DIBuPthHvnYa9EprjnWcfu62vg6sEdRc 6OCGEZ7Kpx6ypNqt46LZ5n8nAGVNE1aRW7/eb7vP76ym6awtpqNWeLWLnm5nYhIg m9YSEKvKVLpilAmTyuZ7LAAP2DjCRZ3ZE6M33jtaJCU5XipKGmz8WSRn7KlPn7kE x4KI/kZfqoM= =0W3V -----END PGP SIGNATURE----- --Apple-Mail=_A319FEF9-2586-4533-A707-D3D1E8DD75DE-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 13:57:59 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88610E50 for ; Wed, 7 Jan 2015 13:57:59 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 564AC6457D for ; Wed, 7 Jan 2015 13:57:58 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t07Dvu4T029946 for ; Wed, 7 Jan 2015 05:57:56 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t07Dvuq6029945 for current@freebsd.org; Wed, 7 Jan 2015 05:57:56 -0800 (PST) (envelope-from david) Date: Wed, 7 Jan 2015 05:57:56 -0800 From: David Wolfskill To: current@freebsd.org Subject: "*** [kernel.debug] Error code 139"? Message-ID: <20150107135756.GC14822@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="01b0+GAtiOmVD9T6" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 13:57:59 -0000 --01b0+GAtiOmVD9T6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable During an attempt to build & install a GENERIC i386 kernel @r276775 (while running head/i386 @r276694), I encountered the above; more context: =2E.. --- vers.o --- cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-proto= types -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-p= ointe r-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-optio= n -W no-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body = -Wno- error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-s= ign - Wno-error-format -Wno-error-parentheses -nostdinc -I. -I/usr/src/sys -I/us= r/src /sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPT= ION_H EADERS -include opt_global.h -mno-mmx -mno-sse -msoft-float -ffreestanding= -fst ack-protector -gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-bo= dy - Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-point= er-si gn -Wno-error-format -Wno-error-parentheses -Wall -Wredundant-decls -Wneste= d-ext erns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wc= ast-q ual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs = -fdia gnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare= -Wno -error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-functi= on - Wno-error-pointer-sign -Wno-error-format -Wno-error-parentheses -mno-aes -= mno-a vx -std=3Diso9899:1999 -Werror vers.c ctfconvert -L VERSION -g vers.o --- kernel.debug --- linking kernel.debug ctfmerge -L VERSION -g -o kernel.debug ... Segmentation fault (core dumped) *** [kernel.debug] Error code 139 bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC 1 error bmake: stopped in /common/S4/obj/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake: stopped in /usr/src 1 error =2E... src.conf is empty; make.conf merely has: SENDMAIL_MC=3D/etc/mail/client.mc I puzzled over it for a bit, then re-ran the "make -DNOCLEAN -j4 buildkernel" -- and the second time around, there were no complaints; the machine is now running: FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1712 r= 276775M/276775:1100052: Wed Jan 7 05:09:01 PST 2015 root@freebeast.cat= whisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 My laptop didn't encounter the issue (and is installing its kernel as I type). I'm mostly wondering what "Error code 139" is intended to mean.... :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Actions have consequences ... as do inactions. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --01b0+GAtiOmVD9T6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUrTtkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7XNQP/iR209VVwB3TgCY+3i10oHXa zeagTtQHO+RDpm7dJeKBazhG0Pp+EXIUanJHRnZAc3oO8d4RPgqUvlQBHnnab8LU +0bfYx/Qkq998F3Eyw1X9lNYNmsoAvJvBUsyN/rUBT40tLVYXCJ4jxKxnyl6KCRi J5z1oiUv6/mDfNepfloAd4ujq0LnmfID8aBJrWXDZSw3QjXFLpHEEB1NGr76iL46 /OpSUH4tTouNSK1HRVla7LXz9krpHa8ZYxh9nM/kWEzz5HkwKGmulqvMavRVdtCu BXCrggqD891vHtwrzF1r12FGSU2NYBJC0k+GJ9yZUKylwdxoKoJ6PXPmHAk36oIs JIQakvjfi/JYDQ9PwQDuuRiVfTDA0A/C0ar6af7NGF1ydZQdpX1KvMzPYNIzjqWB v7fwsBvEsmgcEyCy842dW9WCJKagPxeaKyFaiestDioN1lsEltqChgRydvINIzAj oknOzUBP7/yGd5t12cbD/s9xOYRNyZvVletLx2am4Nz5sQJJXW8QiR6qt4qi+lZa ijKB+HNd8H+FmbxxnUP8u3IiIYAKm30gcD93Wb5mEPecM+xDG8nAEBb3BX4nqtCe hVI2fJL2LQun2Tnlp4cT3AP4SvrTlJrQMwfc7L0zMflz6K4M+Fmz7Ekw4Kmvuadv zmc54LDevB4l7OMbpQ0/ =t9yW -----END PGP SIGNATURE----- --01b0+GAtiOmVD9T6-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 14:14:04 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD2E23C9 for ; Wed, 7 Jan 2015 14:14:04 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7555D6494A for ; Wed, 7 Jan 2015 14:14:04 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id rp18so3733394iec.11 for ; Wed, 07 Jan 2015 06:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=W3Ij1rnr9EEjuyLBD0I+Vzjv7jojLFw6XD8yL8STerw=; b=vN9sCZ8wevck7S/B6ZrMlJx5CoffPVJWNmb0rmj4322sC/Tb2ABEy8nzyZUoeUsgnR WvJkzZPeu0THCVopnzHne0m+VQGl3Q7P0HbXl+kFBlOBp0vIz/3ITq66U/miyCOgx58C 3aklpUVn4fqbaskz/6Wwhqii3THL5JuHgO6UyPhBinrT1S00yyQgy2K4nsq9KYZhDdUV vwSh8j83pMBUhVR4CeM+Ghq81rPFiSrAtv8IvPEOvsQQ7hlixlXY58pVRp2SyXNCNDE4 yUEj3H8qm3/1ffkQZJEsxFD01OcCKSNb+gsCI0wyserIzkPCb2GKMQehS9C5owdgMUjZ vvCw== X-Received: by 10.42.211.200 with SMTP id gp8mr1224274icb.93.1420640043791; Wed, 07 Jan 2015 06:14:03 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Wed, 7 Jan 2015 06:13:43 -0800 (PST) In-Reply-To: <20150107135756.GC14822@albert.catwhisker.org> References: <20150107135756.GC14822@albert.catwhisker.org> From: Ed Maste Date: Wed, 7 Jan 2015 09:13:43 -0500 X-Google-Sender-Auth: 4PahpWvFFTA4nPfF3swrbT6PnWw Message-ID: Subject: Re: "*** [kernel.debug] Error code 139"? To: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:14:04 -0000 On 7 January 2015 at 08:57, David Wolfskill wrote: > --- kernel.debug --- > linking kernel.debug > ctfmerge -L VERSION -g -o kernel.debug ... > Segmentation fault (core dumped) > *** [kernel.debug] Error code 139 ... > I'm mostly wondering what "Error code 139" is intended to mean.... :-} It's the way termination due to a signal is reported. The exit status is 128 + the signal number and SIGSEGV = 11. From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 15:02:51 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B503B40; Wed, 7 Jan 2015 15:02:51 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50F6966F34; Wed, 7 Jan 2015 15:02:51 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id DFEFD25D3891; Wed, 7 Jan 2015 15:02:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 165EDC76FE6; Wed, 7 Jan 2015 15:02:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gzDEmOCYiBfu; Wed, 7 Jan 2015 15:02:45 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6343BC76FCE; Wed, 7 Jan 2015 15:02:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: "*** [kernel.debug] Error code 139"? From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 7 Jan 2015 15:02:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107135756.GC14822@albert.catwhisker.org> To: Ed Maste X-Mailer: Apple Mail (2.1993) Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:02:51 -0000 > On 07 Jan 2015, at 14:13 , Ed Maste wrote: >=20 > On 7 January 2015 at 08:57, David Wolfskill = wrote: >> --- kernel.debug --- >> linking kernel.debug >> ctfmerge -L VERSION -g -o kernel.debug ... >> Segmentation fault (core dumped) >> *** [kernel.debug] Error code 139 > ... >> I'm mostly wondering what "Error code 139" is intended to mean.... = :-} >=20 > It's the way termination due to a signal is reported. The exit status > is 128 + the signal number and SIGSEGV =3D 11. I did see it twice last night while doing HEAD builds, and i386.GENERIC = only. For later builds it was just gone again. Not sure if anyone = wants to figure out what was special about the two SVN revisions. For = me it was a cross-build from amd64 as part of make universe. =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 15:28:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3112DCC; Wed, 7 Jan 2015 15:28:11 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0DA21356; Wed, 7 Jan 2015 15:28:10 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so5492553pad.1; Wed, 07 Jan 2015 07:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=V6u32JTrRiBPqo/yxmJSKRxg45AdRnOVqY32MyWZb6U=; b=r+tTvUuOUdPDTTnV2STQzCs6xOqy2mmzhs8YzeQo/x+KxcsIlipEkDBRkPfN8hwvgO WkHgSXRgwr3iVY1QRZ8AyMrLIrux/2CWoqThaqkggGkoVjKjHgOX1mfRMekeQZJwzyCL 0u3m2PwlfRqcciWUyQ3J4WoW4wOC0CPZuXwPFJbwjq/sZqhlbdl242oKuolSkDn7rNeE YmPxnizlL2CqRZ0ASUkyi24qJwPQDn2qhkGxEYdUQ4fneX8WwifLqsB3rdSqA6RwcIOw 2QrgFabKLy0SFHF9BYEYxfkH3uXyOUFHUzegNkleYVGsvaBWZj/0rYpAqAuZFN1sltTV dRnQ== X-Received: by 10.70.49.16 with SMTP id q16mr6498008pdn.2.1420644490287; Wed, 07 Jan 2015 07:28:10 -0800 (PST) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id pv3sm2107995pbb.56.2015.01.07.07.28.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Jan 2015 07:28:09 -0800 (PST) References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B440) From: Garrett Cooper Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 Date: Wed, 7 Jan 2015 07:28:08 -0800 To: "Eggert, Lars" Cc: FreeBSD-Current , Dimitry Andric , hselasky@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:28:11 -0000 > On Jan 7, 2015, at 05:03, Eggert, Lars wrote: >=20 > Hi, >=20 >> On 2014-12-31, at 21:41, Dimitry Andric wrote: >> I just committed an upgrade of clang, llvm and lldb to 3.5.0 to head, in >> r276479. >=20 > there seem to be issues when building with -DWITH_OFED: >=20 > --- contrib/ofed.all__D --- > /usr/home/elars/src/contrib/ofed/usr.bin/opensm/../../management/opensm/op= ensm/osm_ucast_ftree.c:2996:8: error: taking the absolute value of unsigned t= ype 'unsigned int' has no effect [-Werror,-Wabsolute-value] > if (abs(p_sw->rank - p_remote_sw->rank) !=3D 1) { Please open a bug and cc hselasky@ on it. Thanks!= From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 16:08:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3660A5A; Wed, 7 Jan 2015 16:08:05 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9C5F1BCF; Wed, 7 Jan 2015 16:08:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.07,715,1413270000"; d="asc'?scan'208";a="225801065" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx12-out.netapp.com with ESMTP; 07 Jan 2015 08:07:57 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 7 Jan 2015 08:07:56 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Wed, 7 Jan 2015 08:07:57 -0800 From: "Eggert, Lars" To: Garrett Cooper Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 Thread-Topic: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 Thread-Index: AQHQJTo5/20s5rXTzUyqkX8ruL4BApy1MG2AgAAoTgCAAAsfAA== Date: Wed, 7 Jan 2015 16:07:56 +0000 Message-ID: <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1993) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_5B3DEC3D-57F0-4B2B-B3BD-F998F8669E37"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD-Current , Dimitry Andric , "hselasky@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:08:06 -0000 --Apple-Mail=_5B3DEC3D-57F0-4B2B-B3BD-F998F8669E37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2015-1-7, at 16:28, Garrett Cooper wrote: > Please open a bug and cc hselasky@ on it. Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196597 Lars --Apple-Mail=_5B3DEC3D-57F0-4B2B-B3BD-F998F8669E37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVK1Z3NZcnpRveo1xAQKGswQAmsnLpmm5/9UAbVyt/7JaP5lDmfQ56NMW CbyInMH1H2QCpte1gxAsQPRwwfzKdR6SWi8VJs41g4YdKxIp/ReSTXBDxtNjFgnp N8OVrkjbjvGTxFweD6Qu6OKPOYOoxkCz0I86A6Ld6RQiIGlwhFTil20MoXfCW0Hx V5C2PzEqoFM= =X3B+ -----END PGP SIGNATURE----- --Apple-Mail=_5B3DEC3D-57F0-4B2B-B3BD-F998F8669E37-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 18:23:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FC6112C; Wed, 7 Jan 2015 18:23:22 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4B1C64449; Wed, 7 Jan 2015 18:23:21 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t07INFND071812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 20:23:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t07INFND071812 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t07INFR9071811; Wed, 7 Jan 2015 20:23:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Jan 2015 20:23:15 +0200 From: Konstantin Belousov To: Allan Jude Subject: Re: i915 crash Message-ID: <20150107182314.GO42409@kib.kiev.ua> References: <54ACCBB3.1080906@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ACCBB3.1080906@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "grembo@freebsd.org >> Michael Gmelin" , freebsd-current@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 18:23:22 -0000 On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote: > I grabbed the latest i915.8.patch from kib@'s website and compiled it > against r276774 (today) > > Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled. > > CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (2594.16-MHz K8-class CPU) > > It is an Ivy-bridge CPU/GPU > > I installed xorg and kde, and when I try to start KDE, it loads, and > gets so far as showing the FreeBSD wallpaper, then panics: > > > text dump: http://www.allanjude.com/bsd/i915_core.3.txt > Full dump: (26mb compressed, 740mb original) This is useless for anybody except you. > http://www.allanjude.com/bsd/i915_vmcore.3.xz > > Unread portion of the kernel message buffer: > panic: In GPU write domain > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe045e52e600 > vpanic() at vpanic+0x189/frame 0xfffffe045e52e680 > kassert_panic() at kassert_panic+0x132/frame 0xfffffe045e52e6f0 > i915_gem_pread_ioctl() at i915_gem_pread_ioctl+0x678/frame > 0xfffffe045e52e790 > drm_ioctl() at drm_ioctl+0x318/frame 0xfffffe045e52e800 > devfs_ioctl_f() at devfs_ioctl_f+0x122/frame 0xfffffe045e52e860 > kern_ioctl() at kern_ioctl+0x2c0/frame 0xfffffe045e52e8c0 > sys_ioctl() at sys_ioctl+0x153/frame 0xfffffe045e52e9a0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe045e52eab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe045e52eab0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022a56fa, rsp = > 0x7fffffffe718, rbp = 0x7fffffffe740 --- > KDB: enter: panic > Uptime: 9m19s > Dumping 739 out of 16176 > MB:..3%..11%..22%..31%..42%..52%..61%..72%..81%..91% > > Reading symbols from /boot/kernel/i915kms.ko.symbols...done. > Loaded symbols for /boot/kernel/i915kms.ko.symbols > Reading symbols from /boot/kernel/drm2.ko.symbols...done. > Loaded symbols for /boot/kernel/drm2.ko.symbols > Reading symbols from /boot/kernel/iicbus.ko.symbols...done. > Loaded symbols for /boot/kernel/iicbus.ko.symbols > Reading symbols from /boot/kernel/iic.ko.symbols...done. > Loaded symbols for /boot/kernel/iic.ko.symbols > Reading symbols from /boot/kernel/iicbb.ko.symbols...done. > Loaded symbols for /boot/kernel/iicbb.ko.symbols > #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > #1 0xffffffff80965d27 in kern_reboot (howto=Unhandled dwarf expression > opcode 0x93 > ) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff80966318 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff80966142 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:635 > #4 0xffffffff81e1de88 in i915_gem_pread_ioctl (dev=0xfffff8002ffd1000, > data=0xfffffe045e52e8f0, file=) > at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010 > #5 0xffffffff81e9a398 in drm_ioctl (kdev=, > cmd=2149606492, data=0xfffffe045e52e8f0 "y", flags=Unhandled dwarf > expression opcode 0x93 > ) > at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942 > #6 0xffffffff80849942 in devfs_ioctl_f (fp=0xfffff80009c15690, > com=2149606492, data=0xfffffe045e52e8f0, cred=0xfffffe045e52e8f0, > td=0xfffff80009c74000) at /usr/src/sys/fs/devfs/devfs_vnops.c:775 > #7 0xffffffff809c3ad0 in kern_ioctl (td=0xfffff80009c74000, > fd=, com=0, data=) at > file.h:318 > #8 0xffffffff809c3763 in sys_ioctl (td=0xfffff80009c74000, > uap=0xfffffe045e52ea40) at /usr/src/sys/kern/sys_generic.c:718 > #9 0xffffffff80d8590a in amd64_syscall (td=0xfffff80009c74000, traced=0) > at subr_syscall.c:133 > #10 0xffffffff80d632ab in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:395 > #11 0x00000008022a56fa in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > Is this reproducable ? Try the following patch on top of i915.8. commit 9af6c652745f551e2b6ce5218e350a5e47999feb Author: Konstantin Belousov Date: Wed Jan 7 20:21:46 2015 +0200 Properly move object into gtt domain when needed. diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c index 0f72d08..58cbb59 100644 --- a/sys/dev/drm2/i915/i915_gem.c +++ b/sys/dev/drm2/i915/i915_gem.c @@ -1251,7 +1251,7 @@ i915_gem_shmem_pread(struct drm_device *dev, * optimizes for the case when the gpu will dirty the data * anyway again before the next pread happens. */ needs_clflush = !cpu_cache_is_coherent(dev, obj->cache_level); - ret = i915_gem_object_wait_rendering(obj); + ret = i915_gem_object_set_to_gtt_domain(obj, false); if (ret) return ret; } @@ -1579,7 +1579,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev, * optimizes for the case when the gpu will use the data * right away and we therefore have to clflush anyway. */ needs_clflush_after = cpu_write_needs_clflush(obj); - ret = i915_gem_object_wait_rendering(obj); + ret = i915_gem_object_set_to_gtt_domain(obj, true); if (ret) return ret; } From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 20:08:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8EFE7DF; Wed, 7 Jan 2015 20:08:23 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7655415BF; Wed, 7 Jan 2015 20:08:23 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id t07K8Ltr059892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jan 2015 13:08:21 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id t07K8KdX059889; Wed, 7 Jan 2015 13:08:21 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 7 Jan 2015 13:08:20 -0700 (MST) From: Warren Block To: Matthias Apitz Subject: Re: Acer C720 Chromebook (was: Re: looking for new netbook) In-Reply-To: <20150107083329.GA2063@unixarea.DDR.dd> Message-ID: References: <20141127094342.GA1628@unixarea.DDR.dd> <20150107083329.GA2063@unixarea.DDR.dd> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 07 Jan 2015 13:08:21 -0700 (MST) Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 20:08:23 -0000 On Wed, 7 Jan 2015, Matthias Apitz wrote: > The keyboard of the C720, in principle a normal PC105, mine with German > layout QWERTZ, is a bit tricky: it has > > - only F-keys from F1 to F10 and they are labeled with symbols for the > ChromeOS applications; > - no hardware power-off (only by an ACPI key which is situated where F11 > would be, i.e. right above the Backspace key, you see the risk :-) ) > - no Windows key which could be used as Modifier-key in X11; > - no PageUP/DOWN keys Ouch. But the older Acer netbooks used Fn+up/down, so probably something similar can be done. Alt+up/down, maybe. When researching this machine a couple of weeks back, I saw somewhere that it was based on a similar existing PC-compatible Acer model, V3 or V5 maybe, or the ES1 series (can't find the reference again, of course). But all of those with 11.6" displays look to have older or less powerful processors, typically the Celeron N2840. The Celeron 2955 in the C720 is about 50% faster. The E3-111-P8DW has a faster CPU, but it is a third-generation N3530. Standard hard drive and socketed RAM, though. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 06:09:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28F8DB4C; Thu, 8 Jan 2015 06:09:54 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E27E5C7B; Thu, 8 Jan 2015 06:09:53 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id x19so7908873ier.6; Wed, 07 Jan 2015 22:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dD4roe+YyIotNLCpWhDyBysoQQCYI5VsDi4L1ZOat0w=; b=RIn/fOPsf5lZGkrURhW4l4oNtlgWU+WIUIOmNpRAyGa/FNweIWnXW4Ro8Kv4w5gxAO aNddi5Qdhy/jHjIKSuEWPvych5G6QEP968FusH1s5J9bjzK/oMSK8LJebG6eMhsh4cTg XfZ+sQ3AtyNepsgXHFslRHv1NF5rPQT3EaIyyeADHv1xUU3LccBrkGNcPLYEmnh5X4LA l9lR++ya1MGivGIrYAwcQPki++lR9tBG10rCqLEUycCcUhjGd545IG0xEUIvo6/4ncgc cqG6e6IhwGXIaTXEq/hlsiRnYlUReBg6ys2Tjgd7IdGjcakWqjh7LdZw1+SwvsvmopI4 TRuA== X-Received: by 10.107.131.133 with SMTP id n5mr7290421ioi.30.1420697393246; Wed, 07 Jan 2015 22:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.4 with HTTP; Wed, 7 Jan 2015 22:09:23 -0800 (PST) In-Reply-To: References: <20141127094342.GA1628@unixarea.DDR.dd> <20150107083329.GA2063@unixarea.DDR.dd> From: Jia-Shiun Li Date: Thu, 8 Jan 2015 14:09:23 +0800 Message-ID: Subject: Re: Acer C720 Chromebook (was: Re: looking for new netbook) To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Matthias Apitz , freebsd-mobile@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 06:09:54 -0000 On Thu, Jan 8, 2015 at 4:08 AM, Warren Block wrote: > > When researching this machine a couple of weeks back, I saw somewhere that > it was based on a similar existing PC-compatible Acer model, V3 or V5 > maybe, or the ES1 series (can't find the reference again, of course). But > all of those with 11.6" displays look to have older or less powerful > processors, typically the Celeron N2840. The Celeron 2955 in the C720 is > about 50% faster. > > The E3-111-P8DW has a faster CPU, but it is a third-generation N3530. > Standard hard drive and socketed RAM, though. > > No, N3530 is Baytrail too, a quad-core one. N2840 is dual-core. They are both architecturally successsor of 'Atom' core family despite being labelled Celeron or Pentium. The brands are good for Intel to differentiate prices but useless for technical purpose. The same happens to AMD too. Acer provides model variations in CPU, RAM, storage, display, etc. according to geo markets. For example ES1-111 is only available with N2940 (another quad-core) here in Taiwan. If you can find a quad-core Baytrail model and don't mind slower single-thread performance, the E3 or ES1 series are easier to install FreeBSD I guess. Total multi-thread performance are comparable. And now prices do not differ much either, since Microsoft tax is lifted from these new cheaper models to compete with Chromebooks. -Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 12:06:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA981275 for ; Thu, 8 Jan 2015 12:06:37 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F844793 for ; Thu, 8 Jan 2015 12:06:37 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ex7so2805610wid.3 for ; Thu, 08 Jan 2015 04:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I/7Kyqik9TXEyk2GIS6J/mAmJ7HjpC983NXXGMFSq1k=; b=ltLZBfvtLF7XBNfOgkzgT17sW0+ZzBee2LOib26wSaWgPWF+JDvkBMbQcBIM1g7W3V p3+5QHFDAC6nghzZKti46Nsvg1TLfnNlUhXo04TU/TMAGw4dwWN1HoI1W2vY0TL239nt cmKHivFJuOsNDMwHIgdjfL/lCnKtkYM2qtsCDoBw63F9KegTOGAZP1LdS/4NXYvuSfyv LldNtEICjeAq6B/pHcjucggOMGlO1lUdOLOQ7J1oaZUBSuvO/fZSmacw5Kj+fA13Wjpa u3M62HRFmaQAU1AIwtpdq8yukpTStUZbGBIslPZZreeslOGGIE4Gj3zV9PzkL9/lrycx IUfA== X-Received: by 10.180.126.99 with SMTP id mx3mr19128208wib.66.1420718795766; Thu, 08 Jan 2015 04:06:35 -0800 (PST) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id a14sm21574186wib.22.2015.01.08.04.06.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 04:06:34 -0800 (PST) Sender: Sulev-Madis Silber Message-ID: <54AE72BF.5040405@hot.ee> Date: Thu, 08 Jan 2015 14:06:23 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> In-Reply-To: <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> X-TagToolbar-Keys: D20150108140623474 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:06:38 -0000 Hello. I have this issue where it's impossible to get 9.x (9.3) into state where I can build clang 3.5.0 bootstrap of CURRENT. gcc works fine. I've already discussed this with some people in EFNet :: #bsdmips Currently I have this jail, built using: WITH_CLANG_IS_CC WITH_LIBCPLUSPLUS I get strange errors like: ---------------------------------------------------- In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:14: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:20: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/MathExtras.h:21:10: fatal error: 'type_traits' file not found #include ^ 1 error generated. ---------------------------------------------------- Or: ---------------------------------------------------- In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileOutputBuffer.cpp:14: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Errc.h:33:10: fatal error: 'system_error' file not found #include ^ 1 error generated. ---------------------------------------------------- There are files: ---------------------------------------------------- /usr/include/c++/4.2/tr1/type_traits /usr/include/c++/v1/type_traits /usr/include/c++/v1/system_error ---------------------------------------------------- Where files in v1/ directory seem to be indeed correct ones and part of clang. But include paths seem wrong? Or is it something else? Full log: http://ketas.si.pri.ee/bbb.build.1420677522.log I don't know... if 9.x can't be used to build 11.x / CURRENT anymore, maybe this should be put to UPDATING (that 9.x is not supported) and I just upgrade to 10.x... which would solve everything (hopefully). Thanks. From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 12:09:46 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5386C542; Thu, 8 Jan 2015 12:09:46 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 089437B0; Thu, 8 Jan 2015 12:09:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3BFE525D37C7; Thu, 8 Jan 2015 12:09:43 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A57A9C76FD9; Thu, 8 Jan 2015 12:09:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id M1ohDZDjOk4Z; Thu, 8 Jan 2015 12:09:41 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 505BDC76FD6; Thu, 8 Jan 2015 12:09:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: "*** [kernel.debug] Error code 139"? From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 8 Jan 2015 12:09:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> References: <20150107135756.GC14822@albert.catwhisker.org> To: Ed Maste X-Mailer: Apple Mail (2.1993) Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:09:46 -0000 > On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb = wrote: >=20 >=20 >> On 07 Jan 2015, at 14:13 , Ed Maste wrote: >>=20 >> On 7 January 2015 at 08:57, David Wolfskill = wrote: >>> --- kernel.debug --- >>> linking kernel.debug >>> ctfmerge -L VERSION -g -o kernel.debug ... >>> Segmentation fault (core dumped) >>> *** [kernel.debug] Error code 139 >> ... >>> I'm mostly wondering what "Error code 139" is intended to mean.... = :-} >>=20 >> It's the way termination due to a signal is reported. The exit status >> is 128 + the signal number and SIGSEGV =3D 11. >=20 > I did see it twice last night while doing HEAD builds, and = i386.GENERIC only. For later builds it was just gone again. Not sure = if anyone wants to figure out what was special about the two SVN = revisions. For me it was a cross-build from amd64 as part of make = universe. Ok, this continues; I have since seen it four more times. Still = i386.GENERIC only; none of the LINT kernels or other architectures. Can someone please investigate what triggers this? =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 12:40:30 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B1DD98; Thu, 8 Jan 2015 12:40:30 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8CD0B08; Thu, 8 Jan 2015 12:40:29 +0000 (UTC) Received: from [192.168.3.3] (unknown [77.243.161.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 21C99B80A; Thu, 8 Jan 2015 13:40:23 +0100 (CET) Subject: Re: "*** [kernel.debug] Error code 139"? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B943B119-C438-4949-85BB-9D3AAECA2963"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Dimitry Andric In-Reply-To: <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> Date: Thu, 8 Jan 2015 13:40:11 +0100 Message-Id: References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1993) Cc: Ed Maste , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:40:30 -0000 --Apple-Mail=_B943B119-C438-4949-85BB-9D3AAECA2963 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Jan 2015, at 13:09, Bjoern A. Zeeb = wrote: >=20 >> On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb = wrote: >>> On 07 Jan 2015, at 14:13 , Ed Maste wrote: >>> On 7 January 2015 at 08:57, David Wolfskill = wrote: >>>> --- kernel.debug --- >>>> linking kernel.debug >>>> ctfmerge -L VERSION -g -o kernel.debug ... >>>> Segmentation fault (core dumped) >>>> *** [kernel.debug] Error code 139 >>> ... >>>> I'm mostly wondering what "Error code 139" is intended to mean.... = :-} >>>=20 >>> It's the way termination due to a signal is reported. The exit = status >>> is 128 + the signal number and SIGSEGV =3D 11. >>=20 >> I did see it twice last night while doing HEAD builds, and = i386.GENERIC only. For later builds it was just gone again. Not sure = if anyone wants to figure out what was special about the two SVN = revisions. For me it was a cross-build from amd64 as part of make = universe. >=20 > Ok, this continues; I have since seen it four more times. Still = i386.GENERIC only; none of the LINT kernels or other architectures. >=20 > Can someone please investigate what triggers this? Looks like a stack overflow, cause unknown as of yet: Core was generated by `ctfmerge'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0804e7ac in hash_match (hash=3D0x2cd0e460, key=3D0xbb6f9048, = private=3D, fun=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:147 147 int bucket =3D hash->h_hashfn(hash->h_nbuckets, key); (gdb) bt #0 0x0804e7ac in hash_match (hash=3D0x2cd0e460, key=3D0xbb6f9048, = private=3D, fun=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:147 #1 hash_find (hash=3D0x804e80d , key=3D0xbb6f9088,= value=3D0x3e5) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:207 #2 0x08049e60 in alist_find (alist=3D0xbb6f9044, name=3D0x804e7f0 = , value=3D0x3e5) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/alist.c:130 #3 0x080508e6 in get_mapping (ta=3D0xbb6f9048, srcid=3D997) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:195 #4 equiv_node (ctdp=3D0x293f2730, mtdp=3D0x3207e2b0, ed=3D0xbb8faa58) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:366 #5 0x080504b5 in equiv_su (stdp=3D0x2ecb0970, ttdp=3D0x3207e2e0, = ed=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:292 #6 0x0805094f in equiv_node (ctdp=3D0x2ecb0970, mtdp=3D0x3207e2e0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #7 0x0805013b in equiv_plain (stdp=3D0x293f2730, ttdp=3D0x3207e2b0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:243 #8 0x0805094f in equiv_node (ctdp=3D0x293f2730, mtdp=3D0x3207e2b0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #9 0x080504b5 in equiv_su (stdp=3D0x2ecb0970, ttdp=3D0x3207e2e0, = ed=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:292 #10 0x0805094f in equiv_node (ctdp=3D0x2ecb0970, mtdp=3D0x3207e2e0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #11 0x0805013b in equiv_plain (stdp=3D0x293f2730, ttdp=3D0x3207e2b0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:243 #12 0x0805094f in equiv_node (ctdp=3D0x293f2730, mtdp=3D0x3207e2b0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #13 0x080504b5 in equiv_su (stdp=3D0x2ecb0970, ttdp=3D0x3207e2e0, = ed=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:292 #14 0x0805094f in equiv_node (ctdp=3D0x2ecb0970, mtdp=3D0x3207e2e0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 [...rougly 75000 instances of the same...] #75124 0x0805094f in equiv_node (ctdp=3D0x293f2730, mtdp=3D0x3207e2b0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #75125 0x080504b5 in equiv_su (stdp=3D0x293ab2e0, ttdp=3D0x32066c40, = ed=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:292 #75126 0x0805094f in equiv_node (ctdp=3D0x293ab2e0, mtdp=3D0x32066c40, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #75127 0x0805013b in equiv_plain (stdp=3D0x293ab2b0, ttdp=3D0x32066c10, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:243 #75128 0x0805094f in equiv_node (ctdp=3D0x293ab2b0, mtdp=3D0x32066c10, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #75129 0x080504b5 in equiv_su (stdp=3D0x2ecb0e20, ttdp=3D0x3208f9d0, = ed=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:292 #75130 0x0805094f in equiv_node (ctdp=3D0x2ecb0e20, mtdp=3D0x3208f9d0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #75131 0x0805013b in equiv_plain (stdp=3D0x2ecb0df0, ttdp=3D0x3208f9a0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:243 #75132 0x0805094f in equiv_node (ctdp=3D0x2ecb0df0, mtdp=3D0x3208f9a0, = ed=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:385 #75133 0x0805121d in equiv_cb (bucket=3D0x3208f9a0, arg=3D0xbb8faa58) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:412 #75134 0x0804e772 in hash_find_list_cb (node=3D0x3208f9a0, = arg=3D0xbb8faa10) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:160 #75135 0x0804fa31 in list_iter (list=3D0x3208bb18, func=3D0x804e740 = , private=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /common/list.c:127 #75136 0x0804e735 in hash_find_iter (hash=3D, = key=3D, fun=3D, private=3D) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:180 #75137 0x080510c1 in map_td_tree_post (ctdp=3D0x2ecb0df0, = ctdpp=3D, private=3D0xbb8faf08) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:450 #75138 0x08053603 in tdtraverse (this=3D0x2ecb0df0, thisp=3D0x29268f88, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:180 #75139 0x080538bb in tdtrav_func (this=3D0x2ecb0dc0, tdtd=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:70 #75140 0x080535e2 in tdtraverse (this=3D0x2ecb0dc0, thisp=3D0x2ecb0da8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75141 0x08053802 in tdtrav_plain (this=3D0x2ecb0d90, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75142 0x080535e2 in tdtraverse (this=3D0x2ecb0d90, thisp=3D0x2ecb0d78, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75143 0x08053802 in tdtrav_plain (this=3D0x2ecb0d60, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75144 0x080535e2 in tdtraverse (this=3D0x2ecb0d60, thisp=3D0x2912822c, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75145 0x08053916 in tdtrav_su (this=3D0x2ecb0970, tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:98 #75146 0x080535e2 in tdtraverse (this=3D0x2ecb0970, thisp=3D0x293f2748, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75147 0x08053802 in tdtrav_plain (this=3D0x293f2730, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75148 0x080535e2 in tdtraverse (this=3D0x293f2730, thisp=3D0x29098aec, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75149 0x08053916 in tdtrav_su (this=3D0x293ab2e0, tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:98 #75150 0x080535e2 in tdtraverse (this=3D0x293ab2e0, thisp=3D0x293ab2c8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75151 0x08053802 in tdtrav_plain (this=3D0x293ab2b0, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75152 0x080535e2 in tdtraverse (this=3D0x293ab2b0, thisp=3D0x2d44c298, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75153 0x08053802 in tdtrav_plain (this=3D0x2d44c280, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75154 0x080535e2 in tdtraverse (this=3D0x2d44c280, thisp=3D0x2d4b48d8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75155 0x080538bb in tdtrav_func (this=3D0x2937bd30, tdtd=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:70 #75156 0x080535e2 in tdtraverse (this=3D0x2937bd30, thisp=3D0x2937bd18, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75157 0x08053802 in tdtrav_plain (this=3D0x2937bd00, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75158 0x080535e2 in tdtraverse (this=3D0x2937bd00, thisp=3D0x2937bce8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75159 0x08053802 in tdtrav_plain (this=3D0x2937bcd0, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75160 0x080535e2 in tdtraverse (this=3D0x2937bcd0, thisp=3D0x2909874c, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75161 0x08053916 in tdtrav_su (this=3D0x29374250, tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:98 #75162 0x080535e2 in tdtraverse (this=3D0x29374250, thisp=3D0x29374238, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75163 0x08053802 in tdtrav_plain (this=3D0x29374220, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75164 0x080535e2 in tdtraverse (this=3D0x29374220, thisp=3D0x290982ac, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75165 0x08053916 in tdtrav_su (this=3D0x293741c0, tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:98 #75166 0x080535e2 in tdtraverse (this=3D0x293741c0, thisp=3D0x293741a8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75167 0x08053802 in tdtrav_plain (this=3D0x29374190, tdtd=3D0xbb8fae40) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:57 #75168 0x080535e2 in tdtraverse (this=3D0x29374190, thisp=3D0x2d61cd4c, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75169 0x08053916 in tdtrav_su (this=3D0x29374130, tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:98 #75170 0x080535e2 in tdtraverse (this=3D0x29374130, thisp=3D0x2ef762c8, = tdtd=3D0xbb8fae40) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:176 #75171 0x0805370f in iitraverse_td (arg1=3D, = arg2=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:194 #75172 iitraverse (ii=3D0x2ef762c0, vgenp=3D0x8050ed0 , = firstops=3D0x895, preops=3D0x805697c , postops=3D0x80563f0 = , private=3D0x80563b8 ) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/traverse.c:214 #75173 0x080509cf in merge_type_cb (data=3D0x2ef762c0, arg=3D0xbb8faf08) = at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:657 #75174 0x0804fa31 in list_iter (list=3D0x2926e8d0, func=3D0x8050980 = , private=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /common/list.c:127 #75175 0x0804e5e0 in hash_iter (hash=3D0x2b389f20, fun=3D, private=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/hash.c:223 #75176 0x0804fdf1 in merge_types (src=3D0x2b389f20, mcd=3D0x2dd522e0) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:1045 #75177 merge_into_master (cur=3D, mstr=3D0x2dd522e0, = tgt=3D, selfuniquify=3D) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/merge.c:1102 #75178 0x0804e0f7 in worker_runphase2 (wq=3D0x80568f0 ) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/ctfmerge.c:489 #75179 worker_thread (wq=3D0x80568f0 ) at = /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf= /cvt/ctfmerge.c:542 #75180 0x280e869c in ?? () from /lib/libthr.so.3 #75181 0x00000000 in ?? () -Dimitry --Apple-Mail=_B943B119-C438-4949-85BB-9D3AAECA2963 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSuerMACgkQsF6jCi4glqMBxgCgpQZNtHpmFW2EuDCdUeWUvbYA I74AnR7wMFUn5NyjL1VHNImzrCfb9TX8 =pdjp -----END PGP SIGNATURE----- --Apple-Mail=_B943B119-C438-4949-85BB-9D3AAECA2963-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 13:38:03 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D25ABAC9; Thu, 8 Jan 2015 13:38:03 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99FD4A; Thu, 8 Jan 2015 13:38:03 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id rd3so11819543pab.7; Thu, 08 Jan 2015 05:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0H3ru1oQLH/LA0uF8dbYK9qH7/4HNxXPD3bgb4uxKv4=; b=acW3v/UnzMEwWqyTZEO03rNMxgujnf3Sh519PUWsb5fAH+vpUev8BnQS7mqCaMNgm6 O66GyTu0apFdVH7kFZLuCnXfCA7hakgUj3ED/0dBfZYdrALGoY2zfShvRe3Wr9VNhm05 mkd4hRTD1IRoTe3qoHtr8nFmGzNBO5xw9QARFXxXPilrE18QpZ0NWr7hgYjfn5w9I/fA 8AD4jg1yj9LRj0furrTQP/HnQ53LGnuzG/3BAo1hNRCtUKGN1F1ggnvS1NvwnRZI952Z 9kSHdiGhQBIkE2ITKRyVWFXuKik6D9msEyt2P+vHOyimTJe0KPr2T1Hd1UjnW+Uowr9F 3Chg== X-Received: by 10.70.118.168 with SMTP id kn8mr14840510pdb.133.1420724283054; Thu, 08 Jan 2015 05:38:03 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id pd9sm4588388pdb.35.2015.01.08.05.38.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 05:38:01 -0800 (PST) Sender: Mark Johnston Date: Thu, 8 Jan 2015 05:37:56 -0800 From: markj@FreeBSD.org To: Dimitry Andric Subject: Re: "*** [kernel.debug] Error code 139"? Message-ID: <20150108133756.GA32884@raichu> References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Bjoern A. Zeeb" , Ed Maste , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 13:38:03 -0000 On Thu, Jan 08, 2015 at 01:40:11PM +0100, Dimitry Andric wrote: > On 08 Jan 2015, at 13:09, Bjoern A. Zeeb wrote: > > > >> On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb wrote: > >>> On 07 Jan 2015, at 14:13 , Ed Maste wrote: > >>> On 7 January 2015 at 08:57, David Wolfskill wrote: > >>>> --- kernel.debug --- > >>>> linking kernel.debug > >>>> ctfmerge -L VERSION -g -o kernel.debug ... > >>>> Segmentation fault (core dumped) > >>>> *** [kernel.debug] Error code 139 > >>> ... > >>>> I'm mostly wondering what "Error code 139" is intended to mean.... :-} > >>> > >>> It's the way termination due to a signal is reported. The exit status > >>> is 128 + the signal number and SIGSEGV = 11. > >> > >> I did see it twice last night while doing HEAD builds, and i386.GENERIC only. For later builds it was just gone again. Not sure if anyone wants to figure out what was special about the two SVN revisions. For me it was a cross-build from amd64 as part of make universe. > > > > Ok, this continues; I have since seen it four more times. Still i386.GENERIC only; none of the LINT kernels or other architectures. > > > > Can someone please investigate what triggers this? > > Looks like a stack overflow, cause unknown as of yet: I'll try to reproduce this, but perhaps try reverting r274569? r274565 and r274564 could also potentially be the cause of this, but r274569 would be my first guess. > > Core was generated by `ctfmerge'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0804e7ac in hash_match (hash=0x2cd0e460, key=0xbb6f9048, private=, fun=) > at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:147 > 147 int bucket = hash->h_hashfn(hash->h_nbuckets, key); > (gdb) bt > #0 0x0804e7ac in hash_match (hash=0x2cd0e460, key=0xbb6f9048, private=, fun=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:147 > #1 hash_find (hash=0x804e80d , key=0xbb6f9088, value=0x3e5) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:207 > #2 0x08049e60 in alist_find (alist=0xbb6f9044, name=0x804e7f0 , value=0x3e5) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/alist.c:130 > #3 0x080508e6 in get_mapping (ta=0xbb6f9048, srcid=997) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:195 > #4 equiv_node (ctdp=0x293f2730, mtdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:366 > #5 0x080504b5 in equiv_su (stdp=0x2ecb0970, ttdp=0x3207e2e0, ed=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:292 > #6 0x0805094f in equiv_node (ctdp=0x2ecb0970, mtdp=0x3207e2e0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #7 0x0805013b in equiv_plain (stdp=0x293f2730, ttdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:243 > #8 0x0805094f in equiv_node (ctdp=0x293f2730, mtdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #9 0x080504b5 in equiv_su (stdp=0x2ecb0970, ttdp=0x3207e2e0, ed=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:292 > #10 0x0805094f in equiv_node (ctdp=0x2ecb0970, mtdp=0x3207e2e0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #11 0x0805013b in equiv_plain (stdp=0x293f2730, ttdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:243 > #12 0x0805094f in equiv_node (ctdp=0x293f2730, mtdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #13 0x080504b5 in equiv_su (stdp=0x2ecb0970, ttdp=0x3207e2e0, ed=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:292 > #14 0x0805094f in equiv_node (ctdp=0x2ecb0970, mtdp=0x3207e2e0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > [...rougly 75000 instances of the same...] > #75124 0x0805094f in equiv_node (ctdp=0x293f2730, mtdp=0x3207e2b0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #75125 0x080504b5 in equiv_su (stdp=0x293ab2e0, ttdp=0x32066c40, ed=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:292 > #75126 0x0805094f in equiv_node (ctdp=0x293ab2e0, mtdp=0x32066c40, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #75127 0x0805013b in equiv_plain (stdp=0x293ab2b0, ttdp=0x32066c10, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:243 > #75128 0x0805094f in equiv_node (ctdp=0x293ab2b0, mtdp=0x32066c10, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #75129 0x080504b5 in equiv_su (stdp=0x2ecb0e20, ttdp=0x3208f9d0, ed=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:292 > #75130 0x0805094f in equiv_node (ctdp=0x2ecb0e20, mtdp=0x3208f9d0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #75131 0x0805013b in equiv_plain (stdp=0x2ecb0df0, ttdp=0x3208f9a0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:243 > #75132 0x0805094f in equiv_node (ctdp=0x2ecb0df0, mtdp=0x3208f9a0, ed=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:385 > #75133 0x0805121d in equiv_cb (bucket=0x3208f9a0, arg=0xbb8faa58) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:412 > #75134 0x0804e772 in hash_find_list_cb (node=0x3208f9a0, arg=0xbb8faa10) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:160 > #75135 0x0804fa31 in list_iter (list=0x3208bb18, func=0x804e740 , private=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common/list.c:127 > #75136 0x0804e735 in hash_find_iter (hash=, key=, fun=, private=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:180 > #75137 0x080510c1 in map_td_tree_post (ctdp=0x2ecb0df0, ctdpp=, private=0xbb8faf08) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:450 > #75138 0x08053603 in tdtraverse (this=0x2ecb0df0, thisp=0x29268f88, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:180 > #75139 0x080538bb in tdtrav_func (this=0x2ecb0dc0, tdtd=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:70 > #75140 0x080535e2 in tdtraverse (this=0x2ecb0dc0, thisp=0x2ecb0da8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75141 0x08053802 in tdtrav_plain (this=0x2ecb0d90, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75142 0x080535e2 in tdtraverse (this=0x2ecb0d90, thisp=0x2ecb0d78, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75143 0x08053802 in tdtrav_plain (this=0x2ecb0d60, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75144 0x080535e2 in tdtraverse (this=0x2ecb0d60, thisp=0x2912822c, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75145 0x08053916 in tdtrav_su (this=0x2ecb0970, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:98 > #75146 0x080535e2 in tdtraverse (this=0x2ecb0970, thisp=0x293f2748, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75147 0x08053802 in tdtrav_plain (this=0x293f2730, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75148 0x080535e2 in tdtraverse (this=0x293f2730, thisp=0x29098aec, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75149 0x08053916 in tdtrav_su (this=0x293ab2e0, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:98 > #75150 0x080535e2 in tdtraverse (this=0x293ab2e0, thisp=0x293ab2c8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75151 0x08053802 in tdtrav_plain (this=0x293ab2b0, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75152 0x080535e2 in tdtraverse (this=0x293ab2b0, thisp=0x2d44c298, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75153 0x08053802 in tdtrav_plain (this=0x2d44c280, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75154 0x080535e2 in tdtraverse (this=0x2d44c280, thisp=0x2d4b48d8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75155 0x080538bb in tdtrav_func (this=0x2937bd30, tdtd=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:70 > #75156 0x080535e2 in tdtraverse (this=0x2937bd30, thisp=0x2937bd18, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75157 0x08053802 in tdtrav_plain (this=0x2937bd00, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75158 0x080535e2 in tdtraverse (this=0x2937bd00, thisp=0x2937bce8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75159 0x08053802 in tdtrav_plain (this=0x2937bcd0, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75160 0x080535e2 in tdtraverse (this=0x2937bcd0, thisp=0x2909874c, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75161 0x08053916 in tdtrav_su (this=0x29374250, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:98 > #75162 0x080535e2 in tdtraverse (this=0x29374250, thisp=0x29374238, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75163 0x08053802 in tdtrav_plain (this=0x29374220, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75164 0x080535e2 in tdtraverse (this=0x29374220, thisp=0x290982ac, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75165 0x08053916 in tdtrav_su (this=0x293741c0, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:98 > #75166 0x080535e2 in tdtraverse (this=0x293741c0, thisp=0x293741a8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75167 0x08053802 in tdtrav_plain (this=0x29374190, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:57 > #75168 0x080535e2 in tdtraverse (this=0x29374190, thisp=0x2d61cd4c, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75169 0x08053916 in tdtrav_su (this=0x29374130, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:98 > #75170 0x080535e2 in tdtraverse (this=0x29374130, thisp=0x2ef762c8, tdtd=0xbb8fae40) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:176 > #75171 0x0805370f in iitraverse_td (arg1=, arg2=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:194 > #75172 iitraverse (ii=0x2ef762c0, vgenp=0x8050ed0 , firstops=0x895, preops=0x805697c , postops=0x80563f0 , private=0x80563b8 ) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/traverse.c:214 > #75173 0x080509cf in merge_type_cb (data=0x2ef762c0, arg=0xbb8faf08) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:657 > #75174 0x0804fa31 in list_iter (list=0x2926e8d0, func=0x8050980 , private=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/common/list.c:127 > #75175 0x0804e5e0 in hash_iter (hash=0x2b389f20, fun=, private=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/hash.c:223 > #75176 0x0804fdf1 in merge_types (src=0x2b389f20, mcd=0x2dd522e0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:1045 > #75177 merge_into_master (cur=, mstr=0x2dd522e0, tgt=, selfuniquify=) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:1102 > #75178 0x0804e0f7 in worker_runphase2 (wq=0x80568f0 ) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:489 > #75179 worker_thread (wq=0x80568f0 ) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:542 > #75180 0x280e869c in ?? () from /lib/libthr.so.3 > #75181 0x00000000 in ?? () > > -Dimitry > From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 14:06:25 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BC6D3F4; Thu, 8 Jan 2015 14:06:25 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC6263C6; Thu, 8 Jan 2015 14:06:24 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7EF4025D3815; Thu, 8 Jan 2015 14:06:21 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A57E1C76FD9; Thu, 8 Jan 2015 14:06:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id MdzFZFoUinKP; Thu, 8 Jan 2015 14:06:18 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DDDA6C76FD6; Thu, 8 Jan 2015 14:06:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: "*** [kernel.debug] Error code 139"? From: "Bjoern A. Zeeb" In-Reply-To: <20150108133756.GA32884@raichu> Date: Thu, 8 Jan 2015 14:06:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> To: markj@FreeBSD.org X-Mailer: Apple Mail (2.1993) Cc: Ed Maste , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:06:25 -0000 > On 08 Jan 2015, at 13:37 , markj@FreeBSD.org wrote: >=20 > On Thu, Jan 08, 2015 at 01:40:11PM +0100, Dimitry Andric wrote: >> On 08 Jan 2015, at 13:09, Bjoern A. Zeeb = wrote: >>>=20 >>>> On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb = wrote: >>>>> On 07 Jan 2015, at 14:13 , Ed Maste wrote: >>>>> On 7 January 2015 at 08:57, David Wolfskill = wrote: >>>>>> --- kernel.debug --- >>>>>> linking kernel.debug >>>>>> ctfmerge -L VERSION -g -o kernel.debug ... >>>>>> Segmentation fault (core dumped) >>>>>> *** [kernel.debug] Error code 139 >>>>> ... >>>>>> I'm mostly wondering what "Error code 139" is intended to = mean.... :-} >>>>>=20 >>>>> It's the way termination due to a signal is reported. The exit = status >>>>> is 128 + the signal number and SIGSEGV =3D 11. >>>>=20 >>>> I did see it twice last night while doing HEAD builds, and = i386.GENERIC only. For later builds it was just gone again. Not sure = if anyone wants to figure out what was special about the two SVN = revisions. For me it was a cross-build from amd64 as part of make = universe. >>>=20 >>> Ok, this continues; I have since seen it four more times. Still = i386.GENERIC only; none of the LINT kernels or other architectures. >>>=20 >>> Can someone please investigate what triggers this? >>=20 >> Looks like a stack overflow, cause unknown as of yet: >=20 > I'll try to reproduce this, but perhaps try reverting r274569? r274565 > and r274564 could also potentially be the cause of this, but r274569 > would be my first guess. It only started 2 nights ago and we are both doing daily builds. = Unlikely that stuff from November would do it oh so suddenly. It=E2=80=99s hard to exactly narrow it down as there was a lot of other = breakage in the tree but I know that r276729 finished a full universe = and I hadn=E2=80=99t noticed the problem before. So I would almost = assume it was something after that (but obviously it could be a = combination of things). /bz =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 14:13:38 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA8A978D; Thu, 8 Jan 2015 14:13:37 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1B9468B; Thu, 8 Jan 2015 14:13:37 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kq14so11970789pab.6; Thu, 08 Jan 2015 06:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=B0xWGcR2VL5sPj6pB2+N4e/ZkTPSfuJ05NBNKEw8H/o=; b=UYwXu1MlrFhkiAnQRsJl1jHSxvbG7ra8I0ewIr5Zu8ZZpLh6Ydtj6egOSe0j3ltw5j ZF6C6eYDL8C/hxAYc6DbysmOWCvMYlILOlC5UXJfQ/qYZg2XXvTiKCtJRw3AnAE2Nnl0 R5Yfkfo5XR4z9uz3D/pQM2oa/8hcXKnDwAFQ7NT3XnOp2RR1qkX10l4ycLLalZhb/scu opZK1dgylTGtu9igwqkEwGL3wElJmcLX3iIRKAELJCKwmZMj8vNQ1VbA3yMUmJGd58wT 6JHtw8AAlXK6GZLD0N6GF2WCMyaSKxfMFtNTxIEm7Kbmdc4tUd9yqiMq1UYlkn80A3fd 8ygg== X-Received: by 10.68.234.134 with SMTP id ue6mr15089902pbc.47.1420726417164; Thu, 08 Jan 2015 06:13:37 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id rv6sm4734581pab.9.2015.01.08.06.13.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 06:13:35 -0800 (PST) Sender: Mark Johnston Date: Thu, 8 Jan 2015 06:13:33 -0800 From: Mark Johnston To: "Bjoern A. Zeeb" Subject: Re: "*** [kernel.debug] Error code 139"? Message-ID: <20150108141333.GB32884@raichu> References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ed Maste , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:13:38 -0000 On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: > > > On 08 Jan 2015, at 13:37 , markj@FreeBSD.org wrote: > > > > On Thu, Jan 08, 2015 at 01:40:11PM +0100, Dimitry Andric wrote: > >> On 08 Jan 2015, at 13:09, Bjoern A. Zeeb wrote: > >>> > >>>> On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb wrote: > >>>>> On 07 Jan 2015, at 14:13 , Ed Maste wrote: > >>>>> On 7 January 2015 at 08:57, David Wolfskill wrote: > >>>>>> --- kernel.debug --- > >>>>>> linking kernel.debug > >>>>>> ctfmerge -L VERSION -g -o kernel.debug ... > >>>>>> Segmentation fault (core dumped) > >>>>>> *** [kernel.debug] Error code 139 > >>>>> ... > >>>>>> I'm mostly wondering what "Error code 139" is intended to mean.... :-} > >>>>> > >>>>> It's the way termination due to a signal is reported. The exit status > >>>>> is 128 + the signal number and SIGSEGV = 11. > >>>> > >>>> I did see it twice last night while doing HEAD builds, and i386.GENERIC only. For later builds it was just gone again. Not sure if anyone wants to figure out what was special about the two SVN revisions. For me it was a cross-build from amd64 as part of make universe. > >>> > >>> Ok, this continues; I have since seen it four more times. Still i386.GENERIC only; none of the LINT kernels or other architectures. > >>> > >>> Can someone please investigate what triggers this? > >> > >> Looks like a stack overflow, cause unknown as of yet: > > > > I'll try to reproduce this, but perhaps try reverting r274569? r274565 > > and r274564 could also potentially be the cause of this, but r274569 > > would be my first guess. > > It only started 2 nights ago and we are both doing daily builds. Unlikely that stuff from November would do it oh so suddenly. Unlikely, but possible. r274569 modified the termination conditions for the equiv_node() recursion that dim@ posted, so it's definitely relevant. > > It’s hard to exactly narrow it down as there was a lot of other breakage in the tree but I know that r276729 finished a full universe and I hadn’t noticed the problem before. So I would almost assume it was something after that (but obviously it could be a combination of things). > > /bz > > — > Bjoern A. Zeeb Charles Haddon Spurgeon: > "Friendship is one of the sweetest joys of life. Many might have failed > beneath the bitterness of their trial had they not found a friend." > From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 14:43:39 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B9CDA1B for ; Thu, 8 Jan 2015 14:43:39 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5421B9D4 for ; Thu, 8 Jan 2015 14:43:38 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t08EhbYJ038047 for ; Thu, 8 Jan 2015 06:43:37 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t08EhbJ1038046 for current@freebsd.org; Thu, 8 Jan 2015 06:43:37 -0800 (PST) (envelope-from david) Date: Thu, 8 Jan 2015 06:43:37 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: "*** [kernel.debug] Error code 139"? Message-ID: <20150108144337.GT14822@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iibEmBFpDzSsDyxm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:43:39 -0000 --iibEmBFpDzSsDyxm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: > ... > >>> Ok, this continues; I have since seen it four more times. Still i38= 6.GENERIC only; none of the LINT kernels or other architectures. > >>>=20 > >>> Can someone please investigate what triggers this? > >>=20 > >> Looks like a stack overflow, cause unknown as of yet: > >=20 > > I'll try to reproduce this, but perhaps try reverting r274569? r274565 > > and r274564 could also potentially be the cause of this, but r274569 > > would be my first guess. >=20 > It only started 2 nights ago and we are both doing daily builds. Unlikel= y that stuff from November would do it oh so suddenly. >=20 > It?s hard to exactly narrow it down as there was a lot of other breakage = in the tree but I know that r276729 finished a full universe and I hadn?t n= oticed the problem before. So I would almost assume it was something after= that (but obviously it could be a combination of things). > ... I'm only building world & kernel (vs. universe), and doing it natively on head/i386. You may see my history of (eventually, in a few cases) succssful builds for the machine & environment in question at . =20 While I did see an issue (that prevented a successful build) on 06 Jan and 01 Jan, the other daily builds in the last couple of weeks were fairly uneventful -- save for yesterday (07 Jan), where I encountered the SIGSEGV in ctfmerge (though, as I noted at the time, a re-build didn't experience it). Peace, david --=20 David H. Wolfskill david@catwhisker.org Actions have consequences ... as do inactions. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --iibEmBFpDzSsDyxm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUrpeZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7QeMP/jk0j4FbOp6qphP0x3VmaeUc cE1UUc7xDHDfzKe+w4UEMqZFAiEj0YbslJUJvRexSl4rW5k5ObI+tFLdvqR2JzQ9 MyOEY/H+pPPYCrKIAHkQZ82WmH+cyAQjlRVqvhOTncUgxHm9Cw6vrNd9nxTfgSg9 U3s945UqQseddOE6nupxM44TTpGl3NYNNtUY9F9M27BemCqm/gXKrWrcoaq4YBZD 8u3Uy11RkxeDNYxYIxBc/uSb4+TABv2RMXPCZBIZ494/hiuCO1O03mMSFfD/bDyx NIvV2En/aL9ktXN5Va5fXtZkvnWLQP0QzHrqfk2pKHuQt9Knd9iSbExqUJAwU8xG KuqwbMSetlXrBT7IPMpU5XQtNRBapTgmVahCpT7k4T0gbprdh2L17OqUm25Zv7LP e5GDcHYiyPlUeJDXY5CzxFzn0HvikZclAqPcvubVn4iH1i+JWwihkfglpdc6GC2v kTufteQsAJUwtCGB4Y4JNpTbNZJydnfrFygZb4WXTph/MldgNuo1Z2vZUEfBGibb YxwwGOF5GghdF4l0zZqA3uOWeogSoNK3VUOI8/wMH05VLyTktWqcJgqXtxGPi/31 WsAG/wHdAvTh4GZtYPZyTggkLqSC5IQkIH03huyTg74EM7OpcxHVNSrnWhnJBC7L Jx9sfv5umUxtwBlOnTkJ =oKnv -----END PGP SIGNATURE----- --iibEmBFpDzSsDyxm-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 15:24:43 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D4BABC5; Thu, 8 Jan 2015 15:24:43 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8FCADFF; Thu, 8 Jan 2015 15:24:42 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id v10so11773235pde.1; Thu, 08 Jan 2015 07:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ZeY1jLxxJkWyCzCOYs75HOauHu7IuP9wVLZrd9XmT5M=; b=a7vxtX4wnWPATRuJgNHAvYhe2sz7zkaLwaYTT6FG93oy2MBFnk5sIsUtWG4nVfGz0Y gZjLle2BmYrptmvuTdeHNRoxbqM6/0IQzA1QSXBiSbYoaTVpEt3tUPSwGh1655hJIXXh NRmtRMK30J/tdSizslAX7GpNsPfmstNpcSsfxSQCCuQof6iKHymD1D5DGMN6RrIplQU2 +uI1TyxMCjmyWmllPEUCAKkuvE74tsTbEWfQJEHoN3xecBgBNSkW9USfoxCuPQp0DGJx 2hA5nR/7EEtNaP9hBILXceCPGDL5mIGF6gNZTcXN9lJFR4cOUPZlgle1jXqOfCAR03b0 9WiQ== X-Received: by 10.66.121.132 with SMTP id lk4mr15999559pab.33.1420730682422; Thu, 08 Jan 2015 07:24:42 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id gk2sm4756132pbc.14.2015.01.08.07.24.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 07:24:41 -0800 (PST) Sender: Mark Johnston Date: Thu, 8 Jan 2015 07:24:39 -0800 From: Mark Johnston To: "Bjoern A. Zeeb" Subject: Re: "*** [kernel.debug] Error code 139"? Message-ID: <20150108152439.GC32884@raichu> References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ed Maste , Dimitry Andric , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:24:43 -0000 On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: > > > On 08 Jan 2015, at 13:37 , markj@FreeBSD.org wrote: > > > > On Thu, Jan 08, 2015 at 01:40:11PM +0100, Dimitry Andric wrote: > >> On 08 Jan 2015, at 13:09, Bjoern A. Zeeb wrote: > >>> > >>>> On 07 Jan 2015, at 15:02 , Bjoern A. Zeeb wrote: > >>>>> On 07 Jan 2015, at 14:13 , Ed Maste wrote: > >>>>> On 7 January 2015 at 08:57, David Wolfskill wrote: > >>>>>> --- kernel.debug --- > >>>>>> linking kernel.debug > >>>>>> ctfmerge -L VERSION -g -o kernel.debug ... > >>>>>> Segmentation fault (core dumped) > >>>>>> *** [kernel.debug] Error code 139 > >>>>> ... > >>>>>> I'm mostly wondering what "Error code 139" is intended to mean.... :-} > >>>>> > >>>>> It's the way termination due to a signal is reported. The exit status > >>>>> is 128 + the signal number and SIGSEGV = 11. > >>>> > >>>> I did see it twice last night while doing HEAD builds, and i386.GENERIC only. For later builds it was just gone again. Not sure if anyone wants to figure out what was special about the two SVN revisions. For me it was a cross-build from amd64 as part of make universe. > >>> > >>> Ok, this continues; I have since seen it four more times. Still i386.GENERIC only; none of the LINT kernels or other architectures. > >>> > >>> Can someone please investigate what triggers this? > >> > >> Looks like a stack overflow, cause unknown as of yet: > > > > I'll try to reproduce this, but perhaps try reverting r274569? r274565 > > and r274564 could also potentially be the cause of this, but r274569 > > would be my first guess. > > It only started 2 nights ago and we are both doing daily builds. Unlikely that stuff from November would do it oh so suddenly. > > It’s hard to exactly narrow it down as there was a lot of other breakage in the tree but I know that r276729 finished a full universe and I hadn’t noticed the problem before. So I would almost assume it was something after that (but obviously it could be a combination of things). Ok, I was able to reproduce the crash by cross-compiling i386 on amd64. Reverting r274569 made it go away for me. I'm going to try a few more times to see if it's consistent. -Mark From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:09:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B784687 for ; Thu, 8 Jan 2015 16:09:32 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1ECE6254 for ; Thu, 8 Jan 2015 16:09:32 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id q1so10024833lam.5 for ; Thu, 08 Jan 2015 08:09:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=lpBopkcDGRJdUc22by4jbqsea6mzmDyImPtdF1ZjkOY=; b=FOR/YKY98exDMtgUvFxjzoVsNISyJYpGlSG4LFV6Ny9j5OlgRDiV1luVPyRP83/isg ut++6r50k23O4W72XQii2EE+ZOSXDflKHZtHSUyHzn1LC05WRuXLeUu9asUwxKAvxkEt pPWmoWzXnM8s5Qu3cGYVXa9/rpXsFNV5idpyVR4XCW2KQyBUp+XShGySyxqfo5wvHbk3 +m9WfjI6C1lCAo7K9qUZg2WPkeF7bzDN9L3NFv9gf0Q5m4Ce900B+LzjVpogquf74R2Z FCYzfYFNwQn9sU4cMbTyuj8+moaoVp3s4ivE/fxIpGHxgNRxmkTk1NGsHsrupuVEC7Qf hxMw== X-Gm-Message-State: ALoCoQlRquL+Dh20ftVgF2REMj+mkCZ8TrOzawdFzFl3VjrrPXYUCyFX8kHtaz561B0GjihMugI/ MIME-Version: 1.0 X-Received: by 10.112.170.132 with SMTP id am4mr14666786lbc.74.1420733363671; Thu, 08 Jan 2015 08:09:23 -0800 (PST) Received: by 10.25.14.208 with HTTP; Thu, 8 Jan 2015 08:09:23 -0800 (PST) Date: Thu, 8 Jan 2015 17:09:23 +0100 Message-ID: Subject: [PATCH] Add support for 64-bit AHCI BAR. From: =?UTF-8?Q?Micha=C5=82_Stanek?= To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001a11c37818767c02050c264381 X-Mailman-Approved-At: Thu, 08 Jan 2015 16:29:36 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:09:32 -0000 --001a11c37818767c02050c264381 Content-Type: text/plain; charset=UTF-8 Hello all, I ran into an issue with AHCI BAR allocation on arm64. The AHCI PCI driver in sys/dev/ahci/ahci_pci.c assumes that ABAR (AHCI Base Address) register is located at offset 0x24 (BAR5) in the PCI header. Specification for AHCI confirms this is indeed the default address of the main BAR. However, if AHCI uses 64-bit base addresses, then this register consists of two dwords starting at offset 0x20 - BAR4 and BAR5. This is the case on our arm64 target and possibly other platforms using 64-bit BARs for AHCI. The following patch adds a check for the extended BAR in ahci_pci_attach() and sets the 'rid' in bus_alloc_resource_any accordingly. It fixes the allocation error on our platform. Please review and test this patch on other platforms. If there are no issues then it will be committed in a week. Thanks, Michal Stanek --001a11c37818767c02050c264381 Content-Type: text/x-patch; charset=US-ASCII; name="ahci_64bit_bar.patch" Content-Disposition: attachment; filename="ahci_64bit_bar.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4obv96a0 RnJvbSBjYWI2MGNkN2ZjNWE1MTdkZjRkOGM1NWRhNWU4NzI4OGM0MWE5ODVhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNaWNoYWwgU3RhbmVrIDxtc3RAc2VtaWhhbGYuY29tPgpEYXRl OiBXZWQsIDcgSmFuIDIwMTUgMTg6Mjg6MTggKzAxMDAKU3ViamVjdDogW1BBVENIXSBBZGQgc3Vw cG9ydCBmb3IgNjQtYml0IEFIQ0kgQkFSLgoKLS0tCiBzeXMvZGV2L2FoY2kvYWhjaV9wY2kuYyB8 IDExICsrKysrKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAyIGRlbGV0 aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvYWhjaS9haGNpX3BjaS5jIGIvc3lzL2Rldi9h aGNpL2FoY2lfcGNpLmMKaW5kZXggYWYyNjk1MS4uNDM3MjNhNiAxMDA2NDQKLS0tIGEvc3lzL2Rl di9haGNpL2FoY2lfcGNpLmMKKysrIGIvc3lzL2Rldi9haGNpL2FoY2lfcGNpLmMKQEAgLTM3Myw2 ICszNzMsNyBAQCBhaGNpX3BjaV9hdHRhY2goZGV2aWNlX3QgZGV2KQogCWludAllcnJvciwgaTsK IAl1aW50MzJfdCBkZXZpZCA9IHBjaV9nZXRfZGV2aWQoZGV2KTsKIAl1aW50OF90IHJldmlkID0g cGNpX2dldF9yZXZpZChkZXYpOworCXN0cnVjdCBwY2lfbWFwICptYXA7CiAKIAlpID0gMDsKIAl3 aGlsZSAoYWhjaV9pZHNbaV0uaWQgIT0gMCAmJgpAQCAtMzg2LDEyICszODcsMTggQEAgYWhjaV9w Y2lfYXR0YWNoKGRldmljZV90IGRldikKIAkgICAgcGNpX2dldF9zdWJ2ZW5kb3IoZGV2KSA9PSAw eDEwNDMgJiYKIAkgICAgcGNpX2dldF9zdWJkZXZpY2UoZGV2KSA9PSAweDgxZTQpCiAJCWN0bHIt PnF1aXJrcyB8PSBBSENJX1FfU0FUQTFfVU5JVDA7Ci0JLyogaWYgd2UgaGF2ZSBhIG1lbW9yeSBC QVIoNSkgd2UgYXJlIGxpa2VseSBvbiBhbiBBSENJIHBhcnQgKi8KIAljdGxyLT52ZW5kb3JpZCA9 IHBjaV9nZXRfdmVuZG9yKGRldik7CiAJY3Rsci0+ZGV2aWNlaWQgPSBwY2lfZ2V0X2RldmljZShk ZXYpOwogCWN0bHItPnN1YnZlbmRvcmlkID0gcGNpX2dldF9zdWJ2ZW5kb3IoZGV2KTsKIAljdGxy LT5zdWJkZXZpY2VpZCA9IHBjaV9nZXRfc3ViZGV2aWNlKGRldik7Ci0JY3Rsci0+cl9yaWQgPSBQ Q0lSX0JBUig1KTsKKworCS8qIEFIQ0kgQmFzZSBBZGRyZXNzIGlzIEJBUig1KSBieSBkZWZhdWx0 LCB1bmxlc3MgQkFScyBhcmUgNjQtYml0ICovCisJbWFwID0gcGNpX2ZpbmRfYmFyKGRldiwgUENJ Ul9CQVIoNCkpOworCWlmIChtYXAgIT0gTlVMTCAmJgorCSAgICAoKG1hcC0+cG1fdmFsdWUgJiBQ Q0lNX0JBUl9NRU1fVFlQRSkgPT0gUENJTV9CQVJfTUVNXzY0KSkKKwkJY3Rsci0+cl9yaWQgPSBQ Q0lSX0JBUig0KTsKKwllbHNlCisJCWN0bHItPnJfcmlkID0gUENJUl9CQVIoNSk7CiAJaWYgKCEo Y3Rsci0+cl9tZW0gPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwgU1lTX1JFU19NRU1PUlks CiAJICAgICZjdGxyLT5yX3JpZCwgUkZfQUNUSVZFKSkpCiAJCXJldHVybiBFTlhJTzsKLS0gCjIu Mi4xCgo= --001a11c37818767c02050c264381-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:36:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D2AD316 for ; Thu, 8 Jan 2015 16:36:28 +0000 (UTC) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45A1E7A9 for ; Thu, 8 Jan 2015 16:36:27 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id p6so2862331qcv.9 for ; Thu, 08 Jan 2015 08:36:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ZzaechhwzsQVRdnZh+sAdTqcPwviNDapHFOSENSMJhU=; b=FtR+bbfffm6ar0yjcN+GoruTSxVfldl1AXRwqdJoZZKx6JIpezW/eS2XTL+qnObf3O Er/Znz18aYjizku+a4XU2/fJJFimAig9RrIbVBGWoVh+wHtmvRR+QjOsxwO1fuaxC2qg Mp9x7UCEMRLxLEA87lHCu7KLyCR4NAawpR1kRjyTlWsGL2LuvnoOjjPS2x0TTndJsEyS rSlc4IPhLFt8ILWeqlB26zTUnmIPDe1SkgzIn55nEp7G2AcnFqlkOGeXK7imuMIvpcB4 FSXcTPOs8HezQm2qYpeTG1lmOdN3gCy95zHYstVofvH4zVs2PFASleY9iq+1nqAQKTYQ VXIQ== X-Gm-Message-State: ALoCoQlohXeU33+7hW6+X2S4JUPDYgaTTY1EXdh/RWv6hpKVn5hpLFLjEWkURIG1FSpgbJLWQ7z1 X-Received: by 10.224.30.74 with SMTP id t10mr17817944qac.8.1420734981621; Thu, 08 Jan 2015 08:36:21 -0800 (PST) Received: from [10.64.26.233] ([69.53.236.236]) by mx.google.com with ESMTPSA id p69sm4408559qga.27.2015.01.08.08.36.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 08:36:20 -0800 (PST) Sender: Warner Losh Subject: Re: [PATCH] Add support for 64-bit AHCI BAR. Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_61119F4E-BF62-4B0C-9CDA-1C08065117EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Thu, 8 Jan 2015 09:36:16 -0700 Message-Id: <83015CF1-7D55-4881-8CE9-BC42645A3763@bsdimp.com> References: To: =?utf-8?Q?Micha=C5=82_Stanek?= X-Mailer: Apple Mail (2.1993) Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:36:28 -0000 --Apple-Mail=_61119F4E-BF62-4B0C-9CDA-1C08065117EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 8, 2015, at 9:09 AM, Micha=C5=82 Stanek = wrote: >=20 > This looks good to my eyes=E2=80=A6 Given the ordering of the words in = the BAR, you won=E2=80=99t get false positives. It uses the PCI bus code to make = the determination, which eliminates duplication of code in drivers=E2=80=A6 = I like it. Warner --Apple-Mail=_61119F4E-BF62-4B0C-9CDA-1C08065117EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUrrIBAAoJEGwc0Sh9sBEA+DsQAJed3kQ+uiKDmKRgrKFGkhj+ HqvyJLds5YxM5vMKuhu/k9i8fKBwB/utLV9aYBfERs8UvWihLzpZe0Y72WCgDjZI U5cO7l3Sxww15xF4ohFXSTF9yjZl2OnwjwA/yszDICqCoDh6LZ/8KRKWWrc52hjb tl4kbCkGBtdwZgRDWdtvmi/qn4tGy1xfk7Vd6VqI//4G2eol0qM8cgMEIfqeRMsO aRlmutOktXnpQfj49zah0xi0bgvrD49B8ED6eL8hDuufNSwL8M1rBdV18mirq24a 5JllROD0SefN0nHJ7IKd+ZfWbMm6xZQEucvNhHfFhQ9jaqUruKDiYCcbP7io/2GW Z7b3546iInSEatuv6pdijz3aq08mcr00sZuQLxsysl0Vx12udDs9TV/8RTDs7iRW ROM0GpBQ/S5Lsv82hOdXxpfHjxbXRQUdeqkIJt1C9dNNEthKreYQdIIAWQb15nmE WdAiT/xvRaYg5PNIj2x3Swczq347HdIdVYo9rcdvtZeBIjHQO0pus+xusvpxD1eC MawNUTNFKfQAynGNp+NEnAC19CXCs4s1YRzAysf1FZpF4Gc6Il0un2wpN3y+HVPg nG3FwXlZy47udyB8c4/NT5Vo9S5uN8D36Grid17/Wj08mWyYGTZe//pFi77lyVp8 gUaNTnOeIGJ+JSnj4lrW =9pWr -----END PGP SIGNATURE----- --Apple-Mail=_61119F4E-BF62-4B0C-9CDA-1C08065117EA-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:51:24 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30CE07C2 for ; Thu, 8 Jan 2015 16:51:24 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A9A18F4 for ; Thu, 8 Jan 2015 16:51:23 +0000 (UTC) Received: from [10.12.76.76] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 792D8192A3B for ; Thu, 8 Jan 2015 16:51:22 +0000 (UTC) Message-ID: <54AEB588.7010109@ignoranthack.me> Date: Thu, 08 Jan 2015 09:51:20 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Haswell CPU Feature References: <54AB306F.2070509@ignoranthack.me> <54AB394E.5040601@ignoranthack.me> <54AB49C2.9020005@ignoranthack.me> <54ABF5A0.7020709@FreeBSD.org> In-Reply-To: <54ABF5A0.7020709@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:51:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/06/15 07:48, John Baldwin wrote: > On 1/6/15 12:44 AM, Jia-Shiun Li wrote: >> On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu >> wrote: >> >>> Hi Sean, >>> >>> On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno >>> wrote: >>>> I'm thinking something like this: >>>> >>>> Index: sys/x86/x86/identcpu.c >>>> =================================================================== >>>> >>>> - - --- sys/x86/x86/identcpu.c (revision 276729) >>>> +++ sys/x86/x86/identcpu.c (working copy) @@ -781,7 >>>> +781,7 @@ "\011TM2" /* Thermal Monitor 2 */ "\012SSSE3" >>>> /* SSSE3 */ "\013CNXT-ID" /* L1 context ID >>> available */ >>>> - - "\014" + >>>> "\014SDBG" /* IA32_DEBUG_INTERFACE >>> debug*/ >>>> "\015FMA" /* Fused Multiply Add */ "\016CX16" /* >>>> CMPXCHG16B >>> Instruction */ >>>> "\017xTPR" /* Send Task Priority >>> Messages*/ >>>> >>>> >>> >>> Looks good. >>> >> >> Maybe also this for completeness? >> >> # svnlite diff Index: sys/x86/include/specialreg.h >> =================================================================== >> >> - --- sys/x86/include/specialreg.h (revision 276737) >> +++ sys/x86/include/specialreg.h (working copy) @@ -154,6 >> +154,7 @@ #define CPUID2_TM2 0x00000100 #define >> CPUID2_SSSE3 0x00000200 #define CPUID2_CNXTID >> 0x00000400 +#define CPUID2_SDBG 0x00000800 #define >> CPUID2_FMA 0x00001000 #define CPUID2_CX16 >> 0x00002000 #define CPUID2_XTPR 0x00004000 > > Yes, please include both. SDBG matches the label in the Intel SDM, > so that's the preferred name. > Thanks folks, I've committed all of this to head after a quick download and read of the SDM. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUrrWGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kvBEH/0XgaqmdXENMYYnq18nBdSrt lEs8qJuZXwvJPJbKxYLXrL6UFp4Yprw+Z4I6aeJp0zXmQP3Kv6yT+yd/ATYt7E5t rf6ytd/qStLaq2FZu4rNQdePVWyMA4qXT0dINMChA0SishDef80WSY2J8LA7sExV EyuD+nBmpr8/oB3UImAbihK2/YGcdi7FEjJe1hWtzcBAp655A5I5fakxDwsQz4iE kqKaCMT50ib9D4G4JicWx1L72hcOAPWpvj9oOplHzp89ZtkuLSrWeKfKX4GriWEY gg6jcKSds6TYCs/3wuMM63YaimJ1wZbpGhvb09at1DPFT8CamqhMspAe70yr5a8= =KAfi -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 18:21:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 426CB4A4 for ; Thu, 8 Jan 2015 18:21:40 +0000 (UTC) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id E9DCF5FD for ; Thu, 8 Jan 2015 18:21:39 +0000 (UTC) X-AuditID: 12074422-f79476d000000d9e-bc-54aecaaded63 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E8.0E.03486.DAACEA45; Thu, 8 Jan 2015 13:21:33 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t08ILWoL007365; Thu, 8 Jan 2015 13:21:32 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t08ILUTu009182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jan 2015 13:21:31 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t08ILUpQ020423; Thu, 8 Jan 2015 13:21:30 -0500 (EST) Date: Thu, 8 Jan 2015 13:21:29 -0500 (EST) From: Benjamin Kaduk To: "Sulev-Madis Silber (ketas)" Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 In-Reply-To: <54AE72BF.5040405@hot.ee> Message-ID: References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> <54AE72BF.5040405@hot.ee> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IRYrdT1117al2IwYnJ3BZz3nxgsnjwZjqr A5PHjE/zWTwezNzGFMAUxWWTkpqTWZZapG+XwJXx8dlXxoLPrBWdzZcZGxjvs3QxcnJICJhI 3F84jw3CFpO4cG89kM3FISSwmEni0penrBDOBkaJE68XsEM4B5kkjpw8BNYiJFAv0Xa7hRnE ZhHQkpjzfjMjiM0moCIx881GsBoRASOJo/c+MYHYzAKGEi/X3WMHsYUFbCUaTt0C6+UUUJN4 vvM4WJxXwFHi2ZyPTBDL3jJK/JjxCywhKqAjsXr/FBaIIkGJkzOfsEAM1ZJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIDlYXpR2MPw8qHWIU 4GBU4uH9cH9tiBBrYllxZe4hRkkOJiVR3v8n1oUI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHV 8QTK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CyWpwcAj0rll9gVGKJS8/L1VJ gvc7yALBotT01Iq0zJwShFImDk6QRTwgi06CLCouSMwtzkyHyJ9i1OVY0L5/JpMQ2CApcV5F kCIBkKKM0jy4ObDk84pRHOhFYd4jIFU8wMQFN+kV0BImoCVZy1eDLClJREhJNTDyNX16/Tzg rt7b/akR7i5K1zWeMQvPcYrn807V65jB7RTtW6q3JcHe4NXKy5JlEuYqC1KlfHjuaLt82f7M R2q11GGb/39OnU9z4Fxz675f2VYzW8WKF1xJs1fq5nEmZoZbex9bbfHa4Xxp1dlVdzP+nfv5 9N/f8vvlTI57AuQLrjV3mBiFuiixFGckGmoxFxUnAgAR32ihGQMAAA== Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:21:40 -0000 On Thu, 8 Jan 2015, Sulev-Madis Silber (ketas) wrote: > I don't know... if 9.x can't be used to build 11.x / CURRENT anymore, > maybe this should be put to UPDATING (that 9.x is not supported) and I > just upgrade to 10.x... which would solve everything (hopefully). I have no specific data about this specific case, but the advertised procedure for upgrading between major branches is to update to the tip of the starting branch before attempting the major version jump, i.e., update to the tip of stable/9 before attempting to go to stable/10 or head. Given that 9.3 is the latest release from the 9.x series, it's not immediately clear (without doing some research) whether that will actually help in this specific case. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 18:27:34 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33E2164A; Thu, 8 Jan 2015 18:27:34 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDB0B663; Thu, 8 Jan 2015 18:27:33 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d124:5365:30b:631a] (unknown [IPv6:2001:7b8:3a7:0:d124:5365:30b:631a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1BE37B80A; Thu, 8 Jan 2015 19:27:28 +0100 (CET) Subject: Re: "*** [kernel.debug] Error code 139"? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CA2D62E7-9CB7-4D70-B6FA-B0B500C9907D"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Dimitry Andric In-Reply-To: <20150108152439.GC32884@raichu> Date: Thu, 8 Jan 2015 19:27:10 +0100 Message-Id: References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> <20150108152439.GC32884@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.1993) Cc: "Bjoern A. Zeeb" , Ed Maste , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:27:34 -0000 --Apple-Mail=_CA2D62E7-9CB7-4D70-B6FA-B0B500C9907D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 08 Jan 2015, at 16:24, Mark Johnston wrote: >=20 > On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: ... >> It only started 2 nights ago and we are both doing daily builds. = Unlikely that stuff from November would do it oh so suddenly. >>=20 >> It=E2=80=99s hard to exactly narrow it down as there was a lot of = other breakage in the tree but I know that r276729 finished a full = universe and I hadn=E2=80=99t noticed the problem before. So I would = almost assume it was something after that (but obviously it could be a = combination of things). >=20 > Ok, I was able to reproduce the crash by cross-compiling i386 on = amd64. > Reverting r274569 made it go away for me. I'm going to try a few more > times to see if it's consistent. Same here, reverting r274569 makes it work again. -Dimitry --Apple-Mail=_CA2D62E7-9CB7-4D70-B6FA-B0B500C9907D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSuzA0ACgkQsF6jCi4glqOvHQCg4cKeLonSvpHsxlAzMID49zEi RcYAoIiO9OBf7e5tzRU51kHUHrNAyEC5 =l/EH -----END PGP SIGNATURE----- --Apple-Mail=_CA2D62E7-9CB7-4D70-B6FA-B0B500C9907D-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 18:46:20 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CCB32A8; Thu, 8 Jan 2015 18:46:20 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8B328DD; Thu, 8 Jan 2015 18:46:19 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id lf10so13388995pab.5; Thu, 08 Jan 2015 10:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=fPX8CroLhsElFlc0hXozaTTQE8vKBVVISNHRsztiSJo=; b=g+HfSl4Feu9WFFLeZEaM3pva6/S51gV/uhf79XoEIVM9xlzlGHw85YNavRo1wIFWVk b+BOenX0oy5u6OwMsWrqS5EzYDhqCtB/zHAZl9ZaK7rB4hDoddoihB7FU4AFPEHNsrcA mhHmvarhU2oyynAjNesiC5nts9gQN5JnIY0ZtjaF64WcM9mR4GV6Cv+exLk+VNGeual+ OGz+83Jjkp2NtJSiHHkkZZHsVJSeUZK/1Vj/ZCYN4bNczhRGnOlzlhvlOs4HOZUDSU/2 KzPDXbQhMCIx5j5hs6c6eTae3aswF1/f6r3p6YA3dyXTh1UkIT2v3yCjEglMPYN4Kp9G OrFA== X-Received: by 10.68.130.103 with SMTP id od7mr16895638pbb.117.1420742779356; Thu, 08 Jan 2015 10:46:19 -0800 (PST) Received: from raichu ([198.244.104.6]) by mx.google.com with ESMTPSA id zr4sm5060091pbb.18.2015.01.08.10.46.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 10:46:18 -0800 (PST) Sender: Mark Johnston Date: Thu, 8 Jan 2015 10:46:16 -0800 From: Mark Johnston To: Dimitry Andric Subject: Re: "*** [kernel.debug] Error code 139"? Message-ID: <20150108184616.GD32884@raichu> References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> <20150108152439.GC32884@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Bjoern A. Zeeb" , Ed Maste , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:46:20 -0000 On Thu, Jan 08, 2015 at 07:27:10PM +0100, Dimitry Andric wrote: > On 08 Jan 2015, at 16:24, Mark Johnston wrote: > > > > On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: > ... > >> It only started 2 nights ago and we are both doing daily builds. Unlikely that stuff from November would do it oh so suddenly. > >> > >> It’s hard to exactly narrow it down as there was a lot of other breakage in the tree but I know that r276729 finished a full universe and I hadn’t noticed the problem before. So I would almost assume it was something after that (but obviously it could be a combination of things). > > > > Ok, I was able to reproduce the crash by cross-compiling i386 on amd64. > > Reverting r274569 made it go away for me. I'm going to try a few more > > times to see if it's consistent. > > Same here, reverting r274569 makes it work again. I've reverted it in r276848. Thanks, -Mark From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 19:42:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BF62BF for ; Thu, 8 Jan 2015 19:42:59 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3EE5EA3 for ; Thu, 8 Jan 2015 19:42:58 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t08Jgva1057302; Thu, 8 Jan 2015 14:42:57 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <54AEDD8B.1020306@sentex.net> Date: Thu, 08 Jan 2015 14:42:03 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> <54AE72BF.5040405@hot.ee> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 19:42:59 -0000 On 1/8/2015 1:21 PM, Benjamin Kaduk wrote: > I have no specific data about this specific case, but the advertised > procedure for upgrading between major branches is to update to the tip of > the starting branch before attempting the major version jump, i.e., update > to the tip of stable/9 before attempting to go to stable/10 or head. Actually, there seems to be a new caveat to this discussed in https://lists.freebsd.org/pipermail/freebsd-stable/2015-January/081521.html ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 20:40:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 823091B5; Thu, 8 Jan 2015 20:40:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA8406A8; Thu, 8 Jan 2015 20:40:07 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t08Ke1Yl051145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2015 22:40:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t08Ke1Yl051145 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t08Ke0Om051139; Thu, 8 Jan 2015 22:40:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 8 Jan 2015 22:40:00 +0200 From: Konstantin Belousov To: Micha?? Stanek Subject: Re: [PATCH] Add support for 64-bit AHCI BAR. Message-ID: <20150108203959.GR42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:40:08 -0000 On Thu, Jan 08, 2015 at 05:09:23PM +0100, Micha?? Stanek wrote: > Hello all, > > I ran into an issue with AHCI BAR allocation on arm64. The AHCI PCI driver > in sys/dev/ahci/ahci_pci.c assumes that ABAR (AHCI Base Address) register > is located at offset 0x24 (BAR5) in the PCI header. Specification for AHCI > confirms this is indeed the default address of the main BAR. Yes, at least rev. 1.3 of AHCI just states that ABAR must be at offset 0x24. > However, if > AHCI uses 64-bit base addresses, then this register consists of two dwords > starting at offset 0x20 - BAR4 and BAR5. This is the case on our arm64 > target and possibly other platforms using 64-bit BARs for AHCI. Is it specified anywhere, or just a quirk of the specific implementation ? If it is a quirk, would it make sense to also check the vendor or device id before applying the logic ? > > The following patch adds a check for the extended BAR in ahci_pci_attach() > and sets the 'rid' in bus_alloc_resource_any accordingly. It fixes the > allocation error on our platform. > > Please review and test this patch on other platforms. If there are no > issues then it will be committed in a week. > From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 00:54:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEC495A3; Fri, 9 Jan 2015 00:54:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BBEBB5F8; Fri, 9 Jan 2015 00:54:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EEA5EB2F; Fri, 9 Jan 2015 00:54:54 +0000 (UTC) Date: Fri, 9 Jan 2015 00:54:52 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, dim@FreeBSD.org, jhb@FreeBSD.org, jkim@FreeBSD.org Message-ID: <284693210.7.1420764893966.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2184 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 00:54:54 -0000 See Changes: [jkim] Merge OpenSSL 1.0.1k. [dim] Now compiler-rt has been updated in r276851, bring in the various sanitizer libraries that already work on FreeBSD: * asan: Address Sanitizer * ubsan: Undefined Behavior Sanitizer * profile: Profile Guided Optimization support Please note that these libraries are *experimental* at this stage, so the main Makefile is not yet connected to the build. Since I didn't want to needlessly edit BSD.usr.dist, you will also have to create the install directory /usr/lib/clang/3.5.0/lib/freebsd manually for now. [jhb] Change the default method for device_quiesce() to return 0 instead of EOPNOTSUPP. The current behavior can mask real quiesce errors since devclass_quiesce_driver() stops iterating over drivers as soon as it gets an error (incluiding EOPNOTSUPP), but the caller it returns the error to explicitly ignores EOPNOTSUPP. Reviewed by:=09imp ------------------------------------------ [...truncated 88745 lines...] --- e_sqrtl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- kerberos5/lib/libasn1__L --- --- asn1_rfc2459_asn1.o --- cc -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Q= unused-arguments -c asn1_rfc2459_asn1.c -o asn1_rfc2459_asn1.o --- lib/msun__L --- --- s_llrint.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_llrintf.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_llrintl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_logbl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_lrintl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_remquo.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_remquof.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_remquol.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_rintl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_scalbn.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_scalbnf.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- s_scalbnl.o --- cc -O2 -pipe -I -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/msun/src> -I -I -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknow= n-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-p= romoted-parameter -Wno-parentheses -Qunused-arguments -c --- Version.map --- cat = | cpp - - | awk -v vfile=3D -f > Version.map --- libm.a --- building static m library ranlib -D libm.a --- libm.so.5 --- building shared library libm.so.5 --- _libinstall --- sh -C -o= root -g wheel -m 444 libm.a /usr/obj sh -s -o= root -g wheel -m 444 libm.so.5 /usr/obj sh -l s = /usr/obj= /usr/obj --- _INCSINS --- sh -C -o= root -g wheel -m 444 /usr/obj --- kerberos5/lib/libwind__L --- =3D=3D=3D> kerberos5/lib/libwind (obj,depend,all,install) --- obj --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I. -DH= AVE_CONFIG_H -I -std=3Dgnu99 wind_err= .c --- kerberos5/lib/libasn1__L --- --- asn1_rfc2459_asn1.So --- cc -fpic -DPIC -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-pr= otector -Qunused-arguments -c asn1_rfc2459_asn1.c -o asn1_rfc2459_asn1.So --- kerberos5/lib/libwind__L --- echo libwind.so.11: /usr/obj /usr/obj >> .depend --- bidi_table.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o bidi_table.So --- combining_table.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o combining_table.So --- doxygen.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o doxygen.So --- normalize_table.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o normalize_table.So --- bidi_table.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o bidi_table.o --- combining_table.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o combining_table.o --- doxygen.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o doxygen.o --- normalize_table.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o normalize_table.o --- bidi.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o bidi.o --- bidi.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o bidi.So --- combining.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o combining.o --- combining.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o combining.So --- errorlist.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o errorlist.o --- errorlist.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o errorlist.So --- errorlist_table.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o errorlist_table.o --- errorlist_table.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o errorlist_table.So --- ldap.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o ldap.o --- ldap.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o ldap.So --- kerberos5/lib/libasn1__L --- --- asn1_cms_asn1.o --- cc -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Q= unused-arguments -c asn1_cms_asn1.c -o asn1_cms_asn1.o --- kerberos5/lib/libwind__L --- --- map.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o map.o --- map.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o map.So --- map_table.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o map_table.o --- map_table.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o map_table.So --- normalize.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o normalize.o --- normalize.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o normalize.So --- punycode.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o punycode.o --- punycode.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o punycode.So --- stringprep.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o stringprep.o --- stringprep.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o stringprep.So --- utf8.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o utf8.o --- kerberos5/lib/libasn1__L --- --- asn1_cms_asn1.So --- cc -fpic -DPIC -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-pr= otector -Qunused-arguments -c asn1_cms_asn1.c -o asn1_cms_asn1.So --- kerberos5/lib/libwind__L --- --- utf8.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o utf8.So --- wind_err.o --- cc -O2 -pipe -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c wind_err.c -= o wind_err.o --- wind_err.So --- cc -fpic -DPIC -O2 -pipe -I -I. -DHAVE_CO= NFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = wind_err.c -o wind_err.So --- libwind.a --- building static wind library ranlib -D libwind.a --- libwind.so.11 --- building shared library libwind.so.11 --- _libinstall --- sh -C -o= root -g wheel -m 444 libwind.a /usr/obj sh -s -o= root -g wheel -m 444 libwind.so.11 /usr/obj sh -l s = libwind.so.11 /usr/obj --- _INCSINS --- sh -C -o= root -g wheel -m 444 wind_err.h /usr= /obj --- kerberos5/lib/libheimipcc__L --- =3D=3D=3D> kerberos5/lib/libheimipcc (obj,depend,all,install) --- obj --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/kerberos5/lib/libheimipcc/.= ./../../crypto/heimdal/base> -I -DHAVE_CONF= IG_H -I -std=3Dgnu99 echo libheimipcc.so.11: /usr/obj /usr/obj /usr/obj >> .depend --- client.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAVE_CONFIG_H= -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o client.So --- common.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAVE_CONFIG_H= -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o common.So --- client.o --- cc -O2 -pipe -I -I -I -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o client.o --- common.o --- cc -O2 -pipe -I -I -I -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o common.o --- kerberos5/lib/libasn1__L --- --- asn1_krb5_asn1.o --- cc -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Q= unused-arguments -c asn1_krb5_asn1.c -o asn1_krb5_asn1.o --- kerberos5/lib/libheimipcc__L --- --- libheimipcc.so.11 --- building shared library libheimipcc.so.11 --- libheimipcc.a --- building static heimipcc library ranlib -D libheimipcc.a --- _libinstall --- sh -s -o= root -g wheel -m 444 libheimipcc.so.11 /usr/obj --- gnu/lib/libdialog__L --- =3D=3D=3D> gnu/lib/libdialog (obj,depend,all,install) --- obj --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I -D_XOPEN_SOURCE_EXTENDED -= DGCC_UNUSED=3D__unused -std=3Dgnu99 = echo libdialog.so.8: /usr/obj /usr/obj >> .depend --- argv.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o argv.So --- arrows.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o arrows.So --- buildlist.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o buildlist.So --- buttons.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o buttons.So --- calendar.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o calendar.So --- checklist.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o checklist.So --- columns.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o columns.So --- dlg_keys.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o dlg_keys.So --- editbox.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o editbox.So --- fselect.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o fselect.So --- secure/lib/libcrypto__L --- --- cpt_err.So --- cc -fpic -DPIC -O2 -pipe -DTERMIOS -DANSI_SOURCE -I = -I -I/usr/obj -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLF= CN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPE= NSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DG= HASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I -I -I -std=3Dgnu89 -fstack-protector -Wno-pointer-sign -Wno-empty-b= ody -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compa= re -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-en= um-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno= -parentheses -Qunused-arguments -c -o = cpt_err.So --- kerberos5/lib/libasn1__L --- --- asn1_krb5_asn1.So --- cc -fpic -DPIC -O2 -pipe -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-pr= otector -Qunused-arguments -c asn1_krb5_asn1.c -o asn1_krb5_asn1.So --- secure/lib/libcrypto__L --- --- cryptlib.So --- cc -fpic -DPIC -O2 -pipe -DTERMIOS -DANSI_SOURCE -I = -I -I/usr/obj -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLF= CN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPE= NSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DG= HASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I -I -I -std=3Dgnu89 -fstack-protector -Wno-pointer-sign -Wno-empty-b= ody -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compa= re -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-en= um-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno= -parentheses -Qunused-arguments -c -o= cryptlib.So --- gnu/lib/libdialog__L --- --- formbox.So --- cc -fpic -DPIC -O2 -pipe -I -I -D_XOPEN_SOURCE_EXTENDED -DGCC_U= NUSED=3D__unused -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o formbox.So --- secure/lib/libcrypto__L --- --- cversion.So --- cc -fpic -DPIC -O2 -pipe -DTERMIOS -DANSI_SOURCE -I = -I -I/usr/obj -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLF= CN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPE= NSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DG= HASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I -I -I -std=3Dgnu89 -fstack-protector -Wno-pointer-sign -Wno-empty-b= ody -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compa= re -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-en= um-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno= -parentheses -Qunused-arguments -c -o= cversion.So :80:10: error: use of undeclared ident= ifier 'cflags' return(cflags); ^ 1 error generated. *** [cversion.So] Error code 1 make[4]: stopped in 1 error make[4]: stopped in --- gnu/lib/libdialog__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- kerberos5/lib/libheimsqlite__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- kerberos5/lib/libasn1__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 01:42:45 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08990E62; Fri, 9 Jan 2015 01:42:45 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD3B7A78; Fri, 9 Jan 2015 01:42:44 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A3A8625D3A00; Fri, 9 Jan 2015 01:42:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B7B9CC76FD3; Fri, 9 Jan 2015 01:42:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id QZbxRkCZfmjo; Fri, 9 Jan 2015 01:42:37 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:6ded:a003:3324:7439] (unknown [IPv6:fde9:577b:c1a9:4410:6ded:a003:3324:7439]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 537B6C76FCD; Fri, 9 Jan 2015 01:42:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: "*** [kernel.debug] Error code 139"? From: "Bjoern A. Zeeb" In-Reply-To: <20150108184616.GD32884@raichu> Date: Fri, 9 Jan 2015 01:42:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> <20150108152439.GC32884@raichu> <20150108184616.GD32884@raichu> To: Mark Johnston X-Mailer: Apple Mail (2.1993) Cc: Ed Maste , Dimitry Andric , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 01:42:45 -0000 > On 08 Jan 2015, at 18:46 , Mark Johnston wrote: >=20 > On Thu, Jan 08, 2015 at 07:27:10PM +0100, Dimitry Andric wrote: >> On 08 Jan 2015, at 16:24, Mark Johnston wrote: >>>=20 >>> On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: >> ... >>>> It only started 2 nights ago and we are both doing daily builds. = Unlikely that stuff from November would do it oh so suddenly. >>>>=20 >>>> It=E2=80=99s hard to exactly narrow it down as there was a lot of = other breakage in the tree but I know that r276729 finished a full = universe and I hadn=E2=80=99t noticed the problem before. So I would = almost assume it was something after that (but obviously it could be a = combination of things). >>>=20 >>> Ok, I was able to reproduce the crash by cross-compiling i386 on = amd64. >>> Reverting r274569 made it go away for me. I'm going to try a few = more >>> times to see if it's consistent. >>=20 >> Same here, reverting r274569 makes it work again. >=20 > I've reverted it in r276848. So I may revert this reverted changed locally again and see, as the = universe before your =E2=80=9Cbackout=E2=80=9D went through smoothly; = I=E2=80=99d rather understand the root-cause that triggers this then = having something I don=E2=80=99t quite understand why it started to = happen 8 weeks after a change=E2=80=A6 =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 01:57:10 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7E72220; Fri, 9 Jan 2015 01:57:10 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55BF2B6E; Fri, 9 Jan 2015 01:57:10 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q59so5579672wes.10; Thu, 08 Jan 2015 17:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=v8F7cT3gFz/B725DVgQN7ByuZSvQNR54+f9MFaYI42M=; b=Lf1rE/hUE7pLKTJFKs8rBkhIqDY7Uauhl3fhsAfWcWblFSOEJgfNDKU+Fsy0aKLhzc tp17lpRXwdhV/Ou8y7w+wv0ziNDjVA36HosBBbPYmleFJobt1Ngkm8RwS/+elqx8WmFn 1o/vqwHJtR0ezC7EfoZRoNZrfgjF/y7vM+j3PiJqg0b8Ijg/DhrPrxmfo+VMDSH3wJbo F8cVLZfWKkqgbz8/2RaEDSkd+6lxR7v1mNQ3X+qg3fgDc0wSg7S2k+t5gRbd5dEuWIYi JkyaBbm0Hcb+zS8TnXFFqCvNPG5XBNuFOkNRbXi65ygkt6ILrHELU+RaVQh9Xyhv6RI5 oStQ== MIME-Version: 1.0 X-Received: by 10.195.13.104 with SMTP id ex8mr27480184wjd.12.1420768628821; Thu, 08 Jan 2015 17:57:08 -0800 (PST) Sender: markjdb@gmail.com Received: by 10.194.81.106 with HTTP; Thu, 8 Jan 2015 17:57:08 -0800 (PST) In-Reply-To: References: <20150107135756.GC14822@albert.catwhisker.org> <3C59182B-D747-4F33-9AED-6DED638596E7@lists.zabbadoz.net> <20150108133756.GA32884@raichu> <20150108152439.GC32884@raichu> <20150108184616.GD32884@raichu> Date: Thu, 8 Jan 2015 17:57:08 -0800 X-Google-Sender-Auth: DLSpPsemduwNXqn_b8w9w0-oo98 Message-ID: Subject: Re: "*** [kernel.debug] Error code 139"? From: Mark Johnston To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ed Maste , Mark Johnston , Dimitry Andric , FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 01:57:10 -0000 On Thu, Jan 8, 2015 at 5:42 PM, Bjoern A. Zeeb wrote: > >> On 08 Jan 2015, at 18:46 , Mark Johnston wrote: >> >> On Thu, Jan 08, 2015 at 07:27:10PM +0100, Dimitry Andric wrote: >>> On 08 Jan 2015, at 16:24, Mark Johnston wrote: >>>> >>>> On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote: >>> ... >>>>> It only started 2 nights ago and we are both doing daily builds. Unl= ikely that stuff from November would do it oh so suddenly. >>>>> >>>>> It=E2=80=99s hard to exactly narrow it down as there was a lot of oth= er breakage in the tree but I know that r276729 finished a full universe an= d I hadn=E2=80=99t noticed the problem before. So I would almost assume it= was something after that (but obviously it could be a combination of thing= s). >>>> >>>> Ok, I was able to reproduce the crash by cross-compiling i386 on amd64= . >>>> Reverting r274569 made it go away for me. I'm going to try a few more >>>> times to see if it's consistent. >>> >>> Same here, reverting r274569 makes it work again. >> >> I've reverted it in r276848. > > So I may revert this reverted changed locally again and see, as the unive= rse before your =E2=80=9Cbackout=E2=80=9D went through smoothly; I=E2=80= =99d rather understand the root-cause that triggers this then having someth= ing I don=E2=80=99t quite understand why it started to happen 8 weeks after= a change=E2=80=A6 Me too. Apparently my change was interacting badly with the type graph of recent i386 GENERIC kernels. I don't think that r274569 is fundamentally incorrect, but I clearly missed something, and didn't have the cycles to investigate right away (ctfmerge can be quite time-consuming to debug in my experience). Given that the change was breaking the build, I opted to revert it quickly. This weekend, I'll try to figure out what actually happened. From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 02:24:33 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E61C884 for ; Fri, 9 Jan 2015 02:24:33 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5D3DEE for ; Fri, 9 Jan 2015 02:24:32 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.9/8.14.9) with ESMTP id t092NtvV033673 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Jan 2015 18:24:02 -0800 (PST) (envelope-from null@pozo.com) Message-Id: <201501090224.t092NtvV033673@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Jan 2015 18:23:55 -0800 To: freebsd-current@freebsd.org From: Manfred Antar Subject: buildworld broken on current with WITHOUT_CAPSICUM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-102.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID,TW_SV,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0, No X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: t092NtvV033673 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 02:24:33 -0000 On amd64 current build world is broken if defined WITHOUT_CAPSICUM svn revision 276867 here is the error: /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:80:10: fatal error: 'libcapsicum.h' file not found #include ^ 1 error generated. make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump my src.conf: WITHOUT_CASPER=yes WITHOUT_CAPSICUM=yes WITHOUT_DMAGENT=yes WITHOUT_PROFILE=yes WITHOUT_KERNEL_SYMBOLS=yes WITH_IDEA=yes The last buildworld i completed was jan 6 2015 not sure the revision. I don't want casper or capsicum. Thanks for any help with this ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 03:13:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8589AA2B for ; Fri, 9 Jan 2015 03:13:44 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 108D23B7 for ; Fri, 9 Jan 2015 03:13:44 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so7132402wiw.4 for ; Thu, 08 Jan 2015 19:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wbLqqgEypEpSZiV+qkElmjza8F8H7vdeb6HedW1YPZM=; b=F9Z4Lu6pCTQ+j5SkeNPcogjYLm17qTA3F1PVG4TGtTaHphJ+ysyKam7OnfLY+7rJ7H mtVvLbCkSlvn/36ErbZwNsep0Ku1pJBlzEnc6raimhVzb/02zucVO5LW/GHAJKWUC0h0 /WdWct5MeWEBkXnpnOYVx4eqIMwvFY//EsJYwx/pKlvUqx0I1XOHhGHcgisCwEZ2r2T8 F2aHaMEyZRGBXDK+gc/+b2NCVxdR9ZQJBVsNVfjwKw52GrQXpKUgsfSIzrzqqMi2uPGs DgXbksFnFCAMvpgGbVDEKqTxbslD1uG2IRKAi9n4c7Eo7xjri3BEH73Ewej9+nOx0xGr Wxfw== X-Received: by 10.180.103.6 with SMTP id fs6mr511143wib.11.1420773222597; Thu, 08 Jan 2015 19:13:42 -0800 (PST) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id h13sm24089466wiw.4.2015.01.08.19.13.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 19:13:41 -0800 (PST) Sender: Sulev-Madis Silber Message-ID: <54AF4762.6010102@hot.ee> Date: Fri, 09 Jan 2015 05:13:38 +0200 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Tancsa Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> <12132B80-E31B-4782-B69E-C9B8F6E6F0B8@netapp.com> <54AE72BF.5040405@hot.ee> <54AEDD8B.1020306@sentex.net> In-Reply-To: <54AEDD8B.1020306@sentex.net> X-TagToolbar-Keys: D20150109051338123 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 03:13:44 -0000 Maybe I should add (if no-one noticed it yet) that this is cross-build for ARM. I wouldn't attempt to upgrade host itself over two major versions. I think it's totally insane how you can't build other major versions & arches. 9.x can't make 11.x (well, you can, if using gcc bootstrap), and I heard that 10.x can't make 9.x... I mean, build should start "clean", building all things that are needed to bootstrap. If needed, building some tools two times to get into right environment (host -> bootstrap -> bootstrap -> build). Of course, i realize how much work that would be... But this would make it possible to build things across all supported major versions and across arches where it's not too hard to support (for example, MIPS -> amd64 likely doesn't make sense, but i386/amd64 -> ARM/MIPS/... likely has uses). From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 08:52:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F455E1; Fri, 9 Jan 2015 08:52:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 75CFC6D9; Fri, 9 Jan 2015 08:52:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4A540201; Fri, 9 Jan 2015 08:51:05 +0000 (UTC) Date: Fri, 9 Jan 2015 08:50:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, emaste@FreeBSD.org, dim@FreeBSD.org, jhb@FreeBSD.org, jkim@FreeBSD.org, kib@FreeBSD.org Message-ID: <52438307.8.1420793462622.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <284693210.7.1420764893966.JavaMail.jenkins@jenkins-9.freebsd.org> References: <284693210.7.1420764893966.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2185 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 08:52:04 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 17:07:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A22C8E1 for ; Fri, 9 Jan 2015 17:07:43 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90BBBFC1 for ; Fri, 9 Jan 2015 17:07:42 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id gq15so15585906lab.4 for ; Fri, 09 Jan 2015 09:07:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tbW06j24Msk/hqcMjVgSIBtrUMnpecH0Uq5ubK2zwsw=; b=Dj6SHpOLlVWyPVUbiafvrDOfFWVxaSLAP69NZqHmdCfxHexx0ztg/y941MCDcE+5UT R7uJ2DbyENUbT1IFq/vpRAyHXgYqWTu93YkFdgld9HxtUJTX6q1EGnSelzAYZuOJ7fXQ sGU8J8xfqjJwQPKvZ/ZO2wdDtiYqGTXGqzUgql3BpvDdK+0ZCLbw4e440ijzF/VRfnCl MpfMEm/2HBZPRYNtDqtFhwVvNkFV9nWzA0iJecy+CQot1vMIgQEPDyzi1tcKzlZJVI6F 309z/4vMbayOdPDHTphJR2djkLmbctJZ6yhVGuh5dGngW6Kj8xONbmHvOeLL4b/w0aYK ZtQQ== X-Gm-Message-State: ALoCoQneLzlIitDTX7YQZqRDjIjNtMu6A9lzPOrWZGzZQELjoQmymsAKx33vr0F2EQNsq3FmXs0d MIME-Version: 1.0 X-Received: by 10.112.24.130 with SMTP id u2mr22471245lbf.57.1420823259891; Fri, 09 Jan 2015 09:07:39 -0800 (PST) Received: by 10.25.14.208 with HTTP; Fri, 9 Jan 2015 09:07:39 -0800 (PST) In-Reply-To: <20150108203959.GR42409@kib.kiev.ua> References: <20150108203959.GR42409@kib.kiev.ua> Date: Fri, 9 Jan 2015 18:07:39 +0100 Message-ID: Subject: Re: [PATCH] Add support for 64-bit AHCI BAR. From: =?UTF-8?Q?Micha=C5=82_Stanek?= To: Konstantin Belousov Content-Type: multipart/mixed; boundary=001a1134babcb1f795050c3b31f1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:07:43 -0000 --001a1134babcb1f795050c3b31f1 Content-Type: text/plain; charset=UTF-8 2015-01-08 21:40 GMT+01:00 Konstantin Belousov : > > However, if > > AHCI uses 64-bit base addresses, then this register consists of two > dwords > > starting at offset 0x20 - BAR4 and BAR5. This is the case on our arm64 > > target and possibly other platforms using 64-bit BARs for AHCI. > Is it specified anywhere, or just a quirk of the specific implementation ? > If it is a quirk, would it make sense to also check the vendor or device > id before applying the logic ? > > Yes, indeed it is a quirk as I just found out that our platform vendor actually uses BAR(0) as AHCI ABAR, while BAR(4) is used for something else. I found it implemented as a quirk in Linux AHCI code. The BAR is still 64-bit but in a different position than AHCI spec stated. I changed it as you suggested, the new patch is in the attachment. Please take a look. > > > The following patch adds a check for the extended BAR in > ahci_pci_attach() > > and sets the 'rid' in bus_alloc_resource_any accordingly. It fixes the > > allocation error on our platform. > > > > Please review and test this patch on other platforms. If there are no > > issues then it will be committed in a week. > > > --001a1134babcb1f795050c3b31f1 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Add-quirk-for-Cavium-AHCI-BAR-location.patch" Content-Disposition: attachment; filename="0001-Add-quirk-for-Cavium-AHCI-BAR-location.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4pt4emp0 RnJvbSBiNjIyMDg4NGQ5ZTcxZDdjNGZjMWMyYTIyYWRlMzc0ZmMwMjNjODMxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNaWNoYWwgU3RhbmVrIDxtc3RAc2VtaWhhbGYuY29tPgpEYXRl OiBGcmksIDkgSmFuIDIwMTUgMTc6MjA6MzggKzAxMDAKU3ViamVjdDogW1BBVENIXSBBZGQgcXVp cmsgZm9yIENhdml1bSBBSENJIEJBUiBsb2NhdGlvbgoKLS0tCiBzeXMvZGV2L2FoY2kvYWhjaV9w Y2kuYyB8IDkgKysrLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCA2IGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvYWhjaS9haGNpX3BjaS5jIGIvc3lzL2Rl di9haGNpL2FoY2lfcGNpLmMKaW5kZXggNDM3MjNhNi4uZGNlNGFjYiAxMDA2NDQKLS0tIGEvc3lz L2Rldi9haGNpL2FoY2lfcGNpLmMKKysrIGIvc3lzL2Rldi9haGNpL2FoY2lfcGNpLmMKQEAgLTM3 Myw3ICszNzMsNiBAQCBhaGNpX3BjaV9hdHRhY2goZGV2aWNlX3QgZGV2KQogCWludAllcnJvciwg aTsKIAl1aW50MzJfdCBkZXZpZCA9IHBjaV9nZXRfZGV2aWQoZGV2KTsKIAl1aW50OF90IHJldmlk ID0gcGNpX2dldF9yZXZpZChkZXYpOwotCXN0cnVjdCBwY2lfbWFwICptYXA7CiAKIAlpID0gMDsK IAl3aGlsZSAoYWhjaV9pZHNbaV0uaWQgIT0gMCAmJgpAQCAtMzkyLDExICszOTEsOSBAQCBhaGNp X3BjaV9hdHRhY2goZGV2aWNlX3QgZGV2KQogCWN0bHItPnN1YnZlbmRvcmlkID0gcGNpX2dldF9z dWJ2ZW5kb3IoZGV2KTsKIAljdGxyLT5zdWJkZXZpY2VpZCA9IHBjaV9nZXRfc3ViZGV2aWNlKGRl dik7CiAKLQkvKiBBSENJIEJhc2UgQWRkcmVzcyBpcyBCQVIoNSkgYnkgZGVmYXVsdCwgdW5sZXNz IEJBUnMgYXJlIDY0LWJpdCAqLwotCW1hcCA9IHBjaV9maW5kX2JhcihkZXYsIFBDSVJfQkFSKDQp KTsKLQlpZiAobWFwICE9IE5VTEwgJiYKLQkgICAgKChtYXAtPnBtX3ZhbHVlICYgUENJTV9CQVJf TUVNX1RZUEUpID09IFBDSU1fQkFSX01FTV82NCkpCi0JCWN0bHItPnJfcmlkID0gUENJUl9CQVIo NCk7CisJLyogRGVmYXVsdCBBSENJIEJhc2UgQWRkcmVzcyBpcyBCQVIoNSksIENhdml1bSB1c2Vz IEJBUigwKSAqLworCWlmIChjdGxyLT52ZW5kb3JpZCA9PSAweDE3N2QgJiYgY3Rsci0+ZGV2aWNl aWQgPT0gMHhhMDFjKQorCQljdGxyLT5yX3JpZCA9IFBDSVJfQkFSKDApOwogCWVsc2UKIAkJY3Rs ci0+cl9yaWQgPSBQQ0lSX0JBUig1KTsKIAlpZiAoIShjdGxyLT5yX21lbSA9IGJ1c19hbGxvY19y ZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX01FTU9SWSwKLS0gCjIuMi4xCgo= --001a1134babcb1f795050c3b31f1-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 17:27:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96763F25; Fri, 9 Jan 2015 17:27:22 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 392A724E; Fri, 9 Jan 2015 17:27:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t09HRGOp065236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2015 19:27:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t09HRGOp065236 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t09HRFLV065235; Fri, 9 Jan 2015 19:27:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 9 Jan 2015 19:27:15 +0200 From: Konstantin Belousov To: Micha?? Stanek Subject: Re: [PATCH] Add support for 64-bit AHCI BAR. Message-ID: <20150109172715.GU42409@kib.kiev.ua> References: <20150108203959.GR42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:27:22 -0000 On Fri, Jan 09, 2015 at 06:07:39PM +0100, Micha?? Stanek wrote: > 2015-01-08 21:40 GMT+01:00 Konstantin Belousov : > > > > However, if > > > AHCI uses 64-bit base addresses, then this register consists of two > > dwords > > > starting at offset 0x20 - BAR4 and BAR5. This is the case on our arm64 > > > target and possibly other platforms using 64-bit BARs for AHCI. > > Is it specified anywhere, or just a quirk of the specific implementation ? > > If it is a quirk, would it make sense to also check the vendor or device > > id before applying the logic ? > > > > > Yes, indeed it is a quirk as I just found out that our platform vendor > actually uses BAR(0) as AHCI ABAR, while BAR(4) is used for something else. > I found it implemented as a quirk in Linux AHCI code. > The BAR is still 64-bit but in a different position than AHCI spec stated. > I changed it as you suggested, the new patch is in the attachment. Please > take a look. This is probably technically correct (I am not AHCI code author), but note that we have more structured quirks mechanism than directly checking vendor and device id. Look at the ahci_ids table and the quirks member. Add a bit declaring the need of the quirk and test the bit, instead of the vendor/devid. > > > > > > The following patch adds a check for the extended BAR in > > ahci_pci_attach() > > > and sets the 'rid' in bus_alloc_resource_any accordingly. It fixes the > > > allocation error on our platform. > > > > > > Please review and test this patch on other platforms. If there are no > > > issues then it will be committed in a week. > > > > > > From b6220884d9e71d7c4fc1c2a22ade374fc023c831 Mon Sep 17 00:00:00 2001 > From: Michal Stanek > Date: Fri, 9 Jan 2015 17:20:38 +0100 > Subject: [PATCH] Add quirk for Cavium AHCI BAR location > > --- > sys/dev/ahci/ahci_pci.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/sys/dev/ahci/ahci_pci.c b/sys/dev/ahci/ahci_pci.c > index 43723a6..dce4acb 100644 > --- a/sys/dev/ahci/ahci_pci.c > +++ b/sys/dev/ahci/ahci_pci.c > @@ -373,7 +373,6 @@ ahci_pci_attach(device_t dev) > int error, i; > uint32_t devid = pci_get_devid(dev); > uint8_t revid = pci_get_revid(dev); > - struct pci_map *map; > > i = 0; > while (ahci_ids[i].id != 0 && > @@ -392,11 +391,9 @@ ahci_pci_attach(device_t dev) > ctlr->subvendorid = pci_get_subvendor(dev); > ctlr->subdeviceid = pci_get_subdevice(dev); > > - /* AHCI Base Address is BAR(5) by default, unless BARs are 64-bit */ > - map = pci_find_bar(dev, PCIR_BAR(4)); > - if (map != NULL && > - ((map->pm_value & PCIM_BAR_MEM_TYPE) == PCIM_BAR_MEM_64)) > - ctlr->r_rid = PCIR_BAR(4); > + /* Default AHCI Base Address is BAR(5), Cavium uses BAR(0) */ > + if (ctlr->vendorid == 0x177d && ctlr->deviceid == 0xa01c) > + ctlr->r_rid = PCIR_BAR(0); > else > ctlr->r_rid = PCIR_BAR(5); > if (!(ctlr->r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY, > -- > 2.2.1 > From owner-freebsd-current@FreeBSD.ORG Sat Jan 10 18:43:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C17566D for ; Sat, 10 Jan 2015 18:43:37 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5B063E7 for ; Sat, 10 Jan 2015 18:43:36 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id q1so19122628lam.5 for ; Sat, 10 Jan 2015 10:43:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iGeO1nxemStXBddFrI/GGAWyBlFhzKW/ggjA2EI8bo4=; b=KLANQ2JCQQxCawf7nniStEM5LZqkqD0p9wAcBISMLbP0Lmq10LtIjPDIsklTwx0Hp6 W6HHAyXqPx90xnnUw0daquIk4id1Uu0RI/R1TS04mOwhJblR3LuvWVoiI3dI8XPYq2X8 VX9RJGnvlfdkGHaVNP5WKaJCqiEE4kFrWzkVK+YGMktmPaol1rLQjRNIKWQpl47j6m8H vJzUwLEqzrktJwTac593n79/qe3cDd+ZnO0Tzqfz3EwMxCzJmpC2a7getmWuTdo2RUQX k4J0ctOEvvtWjl6l8ZYuFnzHgfmuXREqrzkHuQC5rsCgFGGPkU8nBdKw/WIy0/6Y/9hm Migg== X-Gm-Message-State: ALoCoQkdDeO24SC6GYcztOkFLsJbDPWl0dgPYOebIrtbeBgHdjXOY48d67b3nu5ESQYLVrTM4Qic X-Received: by 10.112.73.66 with SMTP id j2mr28437823lbv.44.1420915408661; Sat, 10 Jan 2015 10:43:28 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id m9sm2703540laa.28.2015.01.10.10.43.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Jan 2015 10:43:27 -0800 (PST) Message-ID: <54B172CE.8080603@freebsd.org> Date: Sat, 10 Jan 2015 21:43:26 +0300 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Manfred Antar , freebsd-current@freebsd.org Subject: Re: buildworld broken on current with WITHOUT_CAPSICUM References: <201501090224.t092NtvV033673@pozo.com> In-Reply-To: <201501090224.t092NtvV033673@pozo.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 18:43:37 -0000 It is broken exact at the same place even without WITHOUT_CAPSICUM. On 09.01.2015 5:23, Manfred Antar wrote: > On amd64 current build world is broken if defined WITHOUT_CAPSICUM svn revision 276867 > here is the error: > /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:80:10: fatal error: 'libcapsicum.h' file not found > #include > ^ > 1 error generated. > make[5]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump -- http://ache.vniz.net/