From owner-freebsd-current@freebsd.org Sun Mar 20 07:28:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A0F4AD6F74 for ; Sun, 20 Mar 2016 07:28:29 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD7501A47 for ; Sun, 20 Mar 2016 07:28:28 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id u2K7VkeH038369 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 20 Mar 2016 09:31:48 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id u2K7SEpd002193 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Mar 2016 09:28:14 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id u2K7SDOU002192; Sun, 20 Mar 2016 09:28:13 +0200 (EET) (envelope-from oleg@opentransfer.com) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@opentransfer.com using -f From: "Oleg V. Nauman" To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Date: Sun, 20 Mar 2016 09:28:13 +0200 Message-ID: <9991609.BzAFArhlj3@asus.theweb.org.ua> Organization: Ecommerce LLC User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160319194757.GE1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <5286161.5Mbx8epR8j@asus.theweb.org.ua> <20160319194757.GE1741@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 07:28:29 -0000 On Saturday 19 March 2016 21:47:57 Konstantin Belousov wrote: > On Sat, Mar 19, 2016 at 04:03:06PM +0200, Oleg V. Nauman wrote: > > Core was generated by `akonadi_baloo_index'. > > Program terminated with signal SIGABRT, Aborted. > > #0 0x0000000805630d6a in thr_kill () from /lib/libc.so.7 > > (gdb) bt > > #0 0x0000000805630d6a in thr_kill () from /lib/libc.so.7 > > #1 0x0000000805630d3b in __raise (s=6) at > > /usr/src/lib/libc/gen/raise.c:52 > > #2 0x0000000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > > #3 0x00000008053564b4 in _thread_exit ( > > > > fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c", > > lineno=139, > > msg=0x805357b97 "mutex is on list") at > > > > /usr/src/lib/libthr/thread/thr_exit.c:182 > > #4 0x000000080534cddc in mutex_assert_not_owned (m=0x80064d000) > > > > at /usr/src/lib/libthr/thread/thr_mutex.c:139 > > > > #5 0x000000080534cfb9 in enqueue_mutex (curthread=0x80e015000, > > m=0x80064d000)> > > at /usr/src/lib/libthr/thread/thr_mutex.c:383 > > > > #6 0x000000080534d213 in mutex_lock_common (m=0x80064d000, > > abstime=0x7fffffffd4e8, > > > > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533 > > > > #7 0x000000080534c6be in __pthread_mutex_timedlock (mutex=0x811c00008, > > > > abstime=0x7fffffffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566 > > > > (gdb) f 7 > > #7 0x000000080534c6be in __pthread_mutex_timedlock (mutex=0x811c00008, > > > > abstime=0x7fffffffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566 > > > > 566 ret = mutex_lock_common(m, abstime, 0); > > (gdb) p *mutex > > $1 = (pthread_mutex_t) 0x8000000000000001 > > (gdb) p m > > $2 = (struct pthread_mutex *) 0x80064d000 > > (gdb) p *m > > $3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0}, > > m_spare = {0, 0, 0, > > > > 0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0, > > > > m_yieldloops = 0, > > > > m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, > > tqe_prev => > > 0x0}} > > (gdb) p *curthread > > No symbol "curthread" in current context. > > (gdb) > > curthread is available e.q. in the frame 5. > > The content from the printout is reasonable, but now it contradicts to the > assertion fired, since both checked pointers are NULL, as reported by gdb. > > Please add the following debugging patch on top of the previous change > and reproduce the issue. I need the same info, but please also provide > exact gasp message from libthr, which is enchanced in the patch below. > > diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c > index 30a8be2..3342c9f 100644 > --- a/lib/libthr/thread/thr_mutex.c > +++ b/lib/libthr/thread/thr_mutex.c > @@ -124,8 +124,14 @@ mutex_assert_is_owned(struct pthread_mutex *m) > { > > #if defined(_PTHREADS_INVARIANTS) > - if (__predict_false(m->m_qe.tqe_prev == NULL)) > - PANIC("mutex is not on list"); > + if (__predict_false(m->m_qe.tqe_prev == NULL)) { > + char msg[128]; > + snprintf(msg, sizeof(msg), > + "mutex %p own %#x %#x is not on list %p %p", > + m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev, > + m->m_qe.tqe_next); > + PANIC(msg); > + } > #endif > } > > @@ -135,8 +141,14 @@ mutex_assert_not_owned(struct pthread_mutex *m) > > #if defined(_PTHREADS_INVARIANTS) > if (__predict_false(m->m_qe.tqe_prev != NULL || > - m->m_qe.tqe_next != NULL)) > - PANIC("mutex is on list"); > + m->m_qe.tqe_next != NULL)) { > + char msg[128]; > + snprintf(msg, sizeof(msg), > + "mutex %p own %#x %#x is on list %p %p", > + m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev, > + m->m_qe.tqe_next); > + PANIC(msg); > + } > #endif > } Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 0x80d46ebc0' at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 2 ) What I have got after applying this patch: #0 0x0000000805913d6a in thr_kill () from /lib/libc.so.7 #1 0x0000000805913d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000805913ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #3 0x0000000805639554 in _thread_exit ( fname=0x80563ac36 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=155, msg=0x7fffffffd1c0 "mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 0x80d46ebc0") at /usr/src/lib/libthr/thread/thr_exit.c:182 #4 0x000000080562fe36 in mutex_assert_not_owned (m=0x800632000) at /usr/src/lib/libthr/thread/thr_mutex.c:155 #5 0x0000000805630009 in enqueue_mutex (curthread=0x80cc15000, m=0x800632000) at /usr/src/lib/libthr/thread/thr_mutex.c:400 #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, m=0x800632000, abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 #7 0x0000000805630280 in mutex_lock_common (m=0x800632000, abstime=0x7fffffffd358, cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:553 #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 ... gdb) f 6 #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, m=0x800632000, abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 535 enqueue_mutex(curthread, m); (gdb) p *curthread $1 = {tid = 100444, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, m_spare = {0, 0, 0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle = { tqe_next = 0x0, tqe_prev = 0x805841000 <_thread_list>}, gcle = {tqe_next = 0x0, tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80584b3c0}, wle = {tqe_next = 0x0, tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = {sched_policy = 2, sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = 0x7ffffdfff000, stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize = 0}, cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, cancel_async = 0, cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0, in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = { _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = { __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, deferred_sigmask = {__bits = { 0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}, deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = 0x0, flags = 0, tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80cc151a0}, {tqh_first = 0x0, tqh_last = 0x80cc151b0}, {tqh_first = 0x0, tqh_last = 0x80cc151c0}, {tqh_first = 0x0, tqh_last = 0x80cc151d0}}, ret = 0x0, specific = 0x800631000, specific_data_count = 5, rdlock_count = 0, rtld_bits = 0, tcb = 0x8006df108, cleanup = 0x0, ex = { exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 0}, unwind_stackend = 0x7ffffffff000, unwind_disabled = 0, magic = 3499860245, report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p = 0, data = 0}, wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, defer_waiters = { 0x0 }, wake_addr = 0x80584b0c8, sleepqueue = 0x80cc14040} (gdb) f 8 #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 583 ret = mutex_lock_common(m, abstime, 0); (gdb) p *mutex $2 = (pthread_mutex_t) 0x8000000000000001 (gdb) p m $3 = (struct pthread_mutex *) 0x800632000 (gdb) p *m $4 = {m_lock = {m_owner = 100444, m_flags = 1, m_ceilings = {0, 0}, m_spare = {0, 0, 0, 0}}, m_flags = 1, m_owner = 100444, m_count = 0, m_spinloops = 0, m_yieldloops = 0, m_qe = { tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = 0x0}} Thank you From owner-freebsd-current@freebsd.org Sun Mar 20 08:14:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8403ACEFE8 for ; Sun, 20 Mar 2016 08:14:01 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A7176B23 for ; Sun, 20 Mar 2016 08:14:01 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id A2B7CACEFE7; Sun, 20 Mar 2016 08:14:01 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2629ACEFE6 for ; Sun, 20 Mar 2016 08:14:01 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0A3B22; Sun, 20 Mar 2016 08:14:01 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6CC984FAE6; Sun, 20 Mar 2016 08:13:59 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2K8DwcN004657; Sun, 20 Mar 2016 08:13:58 GMT (envelope-from phk@phk.freebsd.dk) To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= cc: Ian Lepore , current@freebsd.org Subject: Re: USB disks attach after rootfs prompt In-reply-to: <20160319215624.GA1325@brick.home> From: "Poul-Henning Kamp" References: <1346.1458392679@critter.freebsd.dk> <1458397972.68920.69.camel@freebsd.org> <1998.1458400175@critter.freebsd.dk> <20160319215624.GA1325@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4655.1458461638.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Mar 2016 08:13:58 +0000 Message-ID: <4656.1458461638@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 08:14:01 -0000 -------- In message <20160319215624.GA1325@brick.home>, Edward Tomasz =3D?utf-8?Q?N= apiera=3D C5=3D82a?=3D writes: >> I am somewhat certain that this used to work... > >That might be my fault. I built this kernel overnight: FreeBSD 11.0-CURRENT #2 r297053: Sun Mar 20 02:47:38 UTC 2016 Now it doesn't find _any_ devices at the -a prompt. Your suggested patch did not change that. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sun Mar 20 10:36:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5CDDAD668B for ; Sun, 20 Mar 2016 10:36:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 84EAAF01 for ; Sun, 20 Mar 2016 10:36:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 84388AD668A; Sun, 20 Mar 2016 10:36:30 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83DC5AD6689 for ; Sun, 20 Mar 2016 10:36:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A959F00; Sun, 20 Mar 2016 10:36:30 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id i75so7769115lfb.1; Sun, 20 Mar 2016 03:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vSyU0GF9yVsV+/bRcH8DKuAnNDgFua2w7hghyx/WaTg=; b=bPCx5fBIMBEw7XcCA5s93TK8bsibMasWsfXdxPsUINVlOqASpst74bsEGh622/QqOP fUDWP5fNcxJ16ryKhZXGdFfsmwyxNIcbQm2fKnv4kKe+8re60ImPYkSLs2Q8rZm1mc4P hYUVCb/ewaQnuWQi9oDJ9/GF9luqwEsR14nbjbpfFx6e0WIACSoGRR/dbOkYcMCyy3L8 s9xAijaqdhMqTaEbwHEdAtzCnQ96EKpMuCvXAa3JkXmij+asuNMHJHznS/n/CR0QrwVQ KDI5JxjLhA9kOd0qbGRGuuhU31SpDWCLTDANBavOBbJfhkjN5rHbwqxzPMTWiBV1Q/5c l7Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=vSyU0GF9yVsV+/bRcH8DKuAnNDgFua2w7hghyx/WaTg=; b=kiZkCGZ8MhOTmZzFvoU/6OAht+9KoqENQBdcgE/BTgLGK23xbm0qmj0m9jpBQdG5Gs gWwA6RQ3Xqp3rDFCOBh+cBueJUOvCAGQHAauVuWe+lN7nUo4W29pZUMGe2eKAYJ1qHcy s7ohxyOoy5cqsOISeGgPmips0XPdhRFXLNHGws5E5mqP6A8IKHnlA8IQaN8SfKszItr+ ELFZJYiVPD3TYz+IXWNzQKcG8iVQEcTmxgnS9Mpuwdo24CccCuXTVMRiWpAVp5QXTMOb B6cCtGYcZUR7ksDUP5u2dYvIr8S0uL1XAObGSNYZ84Orj0cyTJxapo5tLniYmdsH5kCi llPQ== X-Gm-Message-State: AD7BkJJ9viv02n8ZX1sWE4Oac9512FoKHz/KtoU60xJv/+Xd0pob6G1iJ+AN6ea8i94txg== X-Received: by 10.25.44.18 with SMTP id s18mr9069337lfs.66.1458470187252; Sun, 20 Mar 2016 03:36:27 -0700 (PDT) Received: from [10.112.45.215] ([5.172.252.215]) by smtp.gmail.com with ESMTPSA id i9sm3669949lfe.31.2016.03.20.03.36.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2016 03:36:26 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: USB disks attach after rootfs prompt From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: iPhone Mail (13D15) In-Reply-To: <4656.1458461638@critter.freebsd.dk> Date: Sun, 20 Mar 2016 11:36:22 +0100 Cc: Ian Lepore , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9901A1B3-1629-4BC7-9F2C-D5B0F1F2BA13@FreeBSD.org> References: <1346.1458392679@critter.freebsd.dk> <1458397972.68920.69.camel@freebsd.org> <1998.1458400175@critter.freebsd.dk> <20160319215624.GA1325@brick.home> <4656.1458461638@critter.freebsd.dk> To: Poul-Henning Kamp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 10:36:30 -0000 Dnia 20.03.2016 o godz. 09:13 Poul-Henning Kamp napisa=C5= =82(a): > -------- > In message <20160319215624.GA1325@brick.home>, Edward Tomasz =3D?utf-8?Q?N= apiera=3D > C5=3D82a?=3D writes: >=20 >>> I am somewhat certain that this used to work... >>=20 >> That might be my fault. >=20 > I built this kernel overnight: >=20 > FreeBSD 11.0-CURRENT #2 r297053: Sun Mar 20 02:47:38 UTC 2016 >=20 > Now it doesn't find _any_ devices at the -a prompt. >=20 > Your suggested patch did not change that. That's seriously weird. Did you see the messages about root mount waiting f= or usbusX, with the patch applied? What's the hardware? From owner-freebsd-current@freebsd.org Sun Mar 20 12:03:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1454AAD6DBF for ; Sun, 20 Mar 2016 12:03:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 021621F24 for ; Sun, 20 Mar 2016 12:03:31 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 01642AD6DBE; Sun, 20 Mar 2016 12:03:31 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F08B6AD6DBD for ; Sun, 20 Mar 2016 12:03:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B98631F23; Sun, 20 Mar 2016 12:03:30 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 075334F57A; Sun, 20 Mar 2016 12:03:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2KC3R0F005433; Sun, 20 Mar 2016 12:03:27 GMT (envelope-from phk@phk.freebsd.dk) To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= cc: Ian Lepore , current@freebsd.org Subject: Re: USB disks attach after rootfs prompt In-reply-to: <9901A1B3-1629-4BC7-9F2C-D5B0F1F2BA13@FreeBSD.org> From: "Poul-Henning Kamp" References: <1346.1458392679@critter.freebsd.dk> <1458397972.68920.69.camel@freebsd.org> <1998.1458400175@critter.freebsd.dk> <20160319215624.GA1325@brick.home> <4656.1458461638@critter.freebsd.dk> <9901A1B3-1629-4BC7-9F2C-D5B0F1F2BA13@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5431.1458475407.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Mar 2016 12:03:27 +0000 Message-ID: <5432.1458475407@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 12:03:31 -0000 -------- In message <9901A1B3-1629-4BC7-9F2C-D5B0F1F2BA13@FreeBSD.org>, =3D?utf-8?Q= ?Edward _Tomasz_Napiera=3DC5=3D82a?=3D writes: >That's seriously weird. Did you see the messages about root mount waitin= g >for usbusX, with the patch applied? What's the hardware? The hardware is BHYVE. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sun Mar 20 18:51:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3829AD7565 for ; Sun, 20 Mar 2016 18:51:40 +0000 (UTC) (envelope-from graywolfe@mac.com) Received: from pv33p04im-asmtp001.me.com (pv33p04im-asmtp001.me.com [17.143.181.10]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B1D51E32 for ; Sun, 20 Mar 2016 18:51:40 +0000 (UTC) (envelope-from graywolfe@mac.com) Received: from no-dns-yet.demon.co.uk (no-dns-yet.demon.co.uk [62.49.153.27]) by pv33p04im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O4C001D7MXV7050@pv33p04im-asmtp001.me.com> for freebsd-current@freebsd.org; Sun, 20 Mar 2016 17:51:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-20_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603200286 From: Tim Preston Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Subject: Possible problem with the ${name}_chdir variable behaviour in /etc/c.subr Message-id: Date: Sun, 20 Mar 2016 17:51:30 +0000 To: freebsd-current@freebsd.org MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 18:51:40 -0000 I was having a problem making the audio/teamspeak3-server port start fro = the rc.d scripts on a -current box that I=E2=80=99ve just built. I = eventually traced this down to it not starting in the correct directory. Looking at the rc.d script I could see that it was attempting to chdir = to the correct directory by setting the teamspeak_chdir variable. So it = looked like this feature was misbehaving in some way. To test this I put together an rc.d script for pwd that used = ${name}_chdir based on how the teamspeak rc.d script was setup. Running = this on a 10.3 box showed that it was changing to the specified = directory as expected, but on -current it was not. I=E2=80=99ve taken a quick look at rc.subr on both boxes but I can=E2=80=99= t immediately see what=E2=80=99s breaking this, and I can=E2=80=99t see = anything in the setup or behaviour of the -current box that would point = to it being something that I=E2=80=99ve broken somehow there. I was wondering if anyone else could reproduce this? Simple rc.d script for pwd ----- #!/bin/sh # PROVIDE: pwd # REQUIRE: LOGIN # KEYWORD: shutdown . /etc/rc.subr name=3D"pwd" rcvar=3Dpwd_enable db_dir=3D/var/db/teamspeak command=3D/bin/pwd pwd_chdir=3D$db_dir required_dirs=3D"$db_dir" load_rc_config $name : ${pwd_enable=3D"NO"} run_rc_command "$1" ----- Running on 10.3 shows the expected result ----- root@amy:~# uname -a FreeBSD amy.flibble.org 10.3-BETA3 FreeBSD 10.3-BETA3 #3 r296346: Thu = Mar 3 15:09:55 GMT 2016 root@amy:/usr/obj/usr/src/sys/GENERIC = amd64 root@amy:~# grep FreeBSD /etc/rc.subr =20 # $FreeBSD: stable/10/etc/rc.subr 292450 2015-12-18 19:58:34Z rilles $ root@amy:~# ls -ld /var/db/teamspeak=20 drwxr-xr-x 3 teamspeak teamspeak 512 Mar 20 00:23 /var/db/teamspeak root@amy:~# sum /usr/local/etc/rc.d/pwd=20 33073 1 /usr/local/etc/rc.d/pwd root@amy:~# service pwd onestart Starting pwd. /var/db/teamspeak ----- On -current we see that were still in / ----- root@emily:~# uname -a FreeBSD emily.flibble.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r297022: = Fri Mar 18 15:18:44 UTC 2016 = root@emily.flibble.org:/usr/obj/usr/src/sys/GENERIC amd64 root@emily:~# grep FreeBSD /etc/rc.subr # $FreeBSD: head/etc/rc.subr 295949 2016-02-24 01:32:12Z araujo $ root@amy:~# ls -ld /var/db/teamspeak=20 drwxr-xr-x 3 teamspeak teamspeak 512 Mar 20 00:23 /var/db/teamspeak root@emily:~# sum /usr/local/etc/rc.d/pwd 33073 1 /usr/local/etc/rc.d/pwd root@emily:~# service pwd onestart Starting pwd. / ----- --=20 Tim Preston graywolfe@mac.com From owner-freebsd-current@freebsd.org Sun Mar 20 21:14:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D19EAD7966 for ; Sun, 20 Mar 2016 21:14:53 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 1E9D71257 for ; Sun, 20 Mar 2016 21:14:52 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3qSsD340SXzZs9 for ; Sun, 20 Mar 2016 22:14:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from :received:received; s=mail; t=1458508482; x=1460322883; bh=N6HB8 kiB2XQ1iXV3GGV7+yzAFtGYNTITFhR+k/Ih/PY=; b=c/oGMbXNrzr+S5C7RHT+b TDk60Zcnb2ZnpnzwFD/jb9AZRHP4TRh4G/sX7txvtdibEjijzlFZa+0mpncn0BUS LuuT6KFkQqd0ZZVJ/W9wrr7U+Zfjxu0Vl+hUS6BdksCFxf1J14n1D2Hz4dvdYyfZ Z93B/J9vrGEDCiy/xKY1bU= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id aclkGBpQUFqI for ; Sun, 20 Mar 2016 22:14:42 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA for ; Sun, 20 Mar 2016 22:14:42 +0100 (CET) To: freebsd-current@freebsd.org From: Guido Falsi Subject: sdhci_pci.ko fails to load Message-ID: <56EF12C1.1020202@madpilot.net> Date: Sun, 20 Mar 2016 22:14:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 21:14:53 -0000 Hi, I've just noticed a regression. I have been using mmc.ko, mmcsd.ko and sdhci.ko to use the integrated SSD card reader on my laptop. I have actively used it during a trip at the start of December, so I'm sure it did work as expected then with a kernel from the end of November. Today with rr296993 I noticed it was not working, the device was not being attached by the kernel. doing "kldload sdhci_pci" retirns this error: link_elf_obj: symbol mmc_driver undefined linker_load_file: Unsupported file type I tried with the modules mentioned above already loaded. Compiling a kernel with the devices statically linked in works as expected. Is this some kind of regression? -- Guido Falsi From owner-freebsd-current@freebsd.org Sun Mar 20 21:21:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21C80AD7B36 for ; Sun, 20 Mar 2016 21:21:08 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 D8CE915D4; Sun, 20 Mar 2016 21:21:07 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3qSsMQ0BZczb2C; Sun, 20 Mar 2016 22:21:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1458508864; x=1460323265; bh=zX3QbqQfnClaV5cCJTZyWJBv/zfiKCDN0dD pgd6ha6w=; b=dfJFhxR9osWzC5HhOOuuvy4KDrFsTgpf4fiVXrQGZ3GFnbB/uzV eXcEOZ1KqDB7PTRIDwdl9mK+nbfNS1uZAV6lEzKY7pk70D1++4CYRwqrBqpkfSY5 ObwjbD9+cFvYH6G7SMKYLNUia9+k/sjeV6Swzx2gi+J9TNVGXl7JktHM= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id WBAyrFYWeFvV; Sun, 20 Mar 2016 22:21:04 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sun, 20 Mar 2016 22:21:04 +0100 (CET) Subject: Re: sdhci_pci.ko fails to load To: cem@FreeBSD.org References: <56EF12C1.1020202@madpilot.net> Cc: freebsd-current From: Guido Falsi Message-ID: <56EF143F.9030308@madpilot.net> Date: Sun, 20 Mar 2016 22:21:03 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 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.21 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, 20 Mar 2016 21:21:08 -0000 On 03/20/16 22:18, Conrad Meyer wrote: > Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND on mmc. > As I said, when loading sdhci_pci I had already loaded module mmc. Anyway I'll try that again just to make sure, maybe I missed it and thought I had it loaded. I'll followup shortly. -- Guido Falsi From owner-freebsd-current@freebsd.org Sun Mar 20 21:34:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1A50AD7D1C for ; Sun, 20 Mar 2016 21:34:01 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 7F0F51D11; Sun, 20 Mar 2016 21:34:00 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3qSsfG3T0Gzb4F; Sun, 20 Mar 2016 22:33:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1458509636; x=1460324037; bh=SISFPRBK+2kpaWR+mizGuUFNZstyIdJo2Wf zf7GM5NI=; b=HSIe2fFgxVxcdYDUpY/CJ+maLfSefpU/yfbCeNI+Zj5LKNO6xXo 9fojX6hwiyYl4YmMjuhgxSU+uL++atIR+ttKorL5clqKgHucyrXp4TYbnhaZGPBP ZJotOODQgukXExUyZZ570gIHeD/6IUmEd2n5CAoS+mUTFrqld2rImiPU= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id ep7Jf1N7F4k6; Sun, 20 Mar 2016 22:33:56 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Sun, 20 Mar 2016 22:33:56 +0100 (CET) Subject: Re: sdhci_pci.ko fails to load To: cem@FreeBSD.org References: <56EF12C1.1020202@madpilot.net> <56EF143F.9030308@madpilot.net> Cc: freebsd-current From: Guido Falsi Message-ID: <56EF1744.4030607@madpilot.net> Date: Sun, 20 Mar 2016 22:33:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56EF143F.9030308@madpilot.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 21:34:02 -0000 On 03/20/16 22:21, Guido Falsi wrote: > On 03/20/16 22:18, Conrad Meyer wrote: >> Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND on mmc. >> > > As I said, when loading sdhci_pci I had already loaded module mmc. > > Anyway I'll try that again just to make sure, maybe I missed it and > thought I had it loaded. > > I'll followup shortly. > I confirm that I had already loaded mmc.ko. Here's a session log: Script started on Sun Mar 20 22:24:37 2016 root@tommy:~ [0]# kldstat Id Refs Address Size Name 1 94 0xffffffff80200000 d3b488 kernel 2 1 0xffffffff80f3d000 2d1ee8 zfs.ko 3 2 0xffffffff8120f000 a3c8 opensolaris.ko 4 1 0xffffffff81421000 635a tmpfs.ko 5 1 0xffffffff81428000 781b if_lagg.ko 6 1 0xffffffff81430000 241b if_tun.ko 7 1 0xffffffff81433000 2266 if_gif.ko 8 1 0xffffffff81436000 24a3 if_tap.ko 9 1 0xffffffff81439000 be11 msdosfs.ko 10 2 0xffffffff81445000 5f59 cd9660.ko 11 1 0xffffffff8144b000 249 cd9660_iconv.ko 12 1 0xffffffff8144c000 3140 libiconv.ko 13 1 0xffffffff81450000 32fd procfs.ko 14 1 0xffffffff81454000 3ccd pseudofs.ko 15 1 0xffffffff81458000 53b2 mmc.ko 16 1 0xffffffff8145e000 4274 sdhci.ko 17 1 0xffffffff81463000 1b10 mmcsd.ko 18 1 0xffffffff81465000 23ca sysvmsg.ko 19 1 0xffffffff81468000 302b sysvsem.ko 20 1 0xffffffff8146c000 2136 sysvshm.ko 21 1 0xffffffff8146f000 cfa coretemp.ko 22 2 0xffffffff81470000 3ac49 sound.ko 23 1 0xffffffff814ab000 2282f snd_hda.ko 24 1 0xffffffff814ce000 39fc autofs.ko 25 3 0xffffffff814d2000 aafd agp.ko 26 1 0xffffffff814dd000 8e60 fuse.ko 27 3 0xffffffff814e6000 45ee8 vboxdrv.ko 28 2 0xffffffff8152c000 2a0f vboxnetflt.ko 29 2 0xffffffff8152f000 9506 netgraph.ko 30 1 0xffffffff81539000 150b ng_ether.ko 31 1 0xffffffff8153b000 3f86 vboxnetadp.ko 32 1 0xffffffff8153f000 8b936 i915kms.ko 33 1 0xffffffff815cb000 4c8e1 drm2.ko 34 4 0xffffffff81618000 1ca0 iicbus.ko 35 1 0xffffffff8161a000 ecb iic.ko 36 1 0xffffffff8161b000 1663 iicbb.ko root@tommy:~ [0]# kldload sdhci_pci kldload: an error occurred while loading the module. Please check dmesg(8) for more details. root@tommy:~ [1]# exit Script done on Sun Mar 20 22:25:01 2016 the full error in dmesg is the same as stated before: link_elf_obj: symbol mmc_driver undefined linker_load_file: Unsupported file type Meybe the symbol is optimized out by the compiler in the module? -- Guido Falsi From owner-freebsd-current@freebsd.org Sun Mar 20 22:04:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A785ACE77F; Sun, 20 Mar 2016 22:04:57 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 33FBAE94; Sun, 20 Mar 2016 22:04:57 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mx1.stack.nl (Postfix) with ESMTP id 2B753B805D; Sun, 20 Mar 2016 23:04:54 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 854AA892B9; Sun, 20 Mar 2016 23:04:54 +0100 (CET) Date: Sun, 20 Mar 2016 23:04:54 +0100 From: Jilles Tjoelker To: Tim Preston , freebsd-rc@freebsd.org Cc: freebsd-current@freebsd.org, adrian@freebsd.org Subject: Re: Possible problem with the ${name}_chdir variable behaviour in /etc/c.subr Message-ID: <20160320220454.GA78464@stack.nl> References: 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) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 22:04:57 -0000 On Sun, Mar 20, 2016 at 05:51:30PM +0000, Tim Preston wrote: > I was having a problem making the audio/teamspeak3-server port start > fro the rc.d scripts on a -current box that I’ve just built. I > eventually traced this down to it not starting in the correct > directory. > Looking at the rc.d script I could see that it was attempting to chdir > to the correct directory by setting the teamspeak_chdir variable. So > it looked like this feature was misbehaving in some way. > To test this I put together an rc.d script for pwd that used > ${name}_chdir based on how the teamspeak rc.d script was setup. > Running this on a 10.3 box showed that it was changing to the > specified directory as expected, but on -current it was not. > I’ve taken a quick look at rc.subr on both boxes but I can’t > immediately see what’s breaking this, and I can’t see anything in the > setup or behaviour of the -current box that would point to it being > something that I’ve broken somehow there. > I was wondering if anyone else could reproduce this? The NAME_chdir variable prepends 'cd $NAME_chdir && ' to the command at a certain point. Prepending further commands like limits (as added by SVN r288291) will not work properly. The older $NAME_prepend feature is broken in the same way. The cd command is having the limits or similar applied to it while the real command is running without proper limits and current directory. The NAME_user and NAME_nice variables use sh -c to avoid this problem but it introduces double-quoting issues (i.e. using arguments containing certain special characters requires an additional unexpected level of quoting). Prepending cd at a later time would avoid the problem with limits and NAME_prepend and allow getting rid of sh -c, but would change the directory as root so permission problems with NAME_user would be detected later. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Sun Mar 20 22:05:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CC8DACE800 for ; Sun, 20 Mar 2016 22:05:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 53472FCA for ; Sun, 20 Mar 2016 22:05:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e551b80f-eee7-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 20 Mar 2016 22:05:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2KM5Ydd007001; Sun, 20 Mar 2016 16:05:34 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458511534.68920.84.camel@freebsd.org> Subject: Re: sdhci_pci.ko fails to load From: Ian Lepore To: Guido Falsi , cem@FreeBSD.org Cc: freebsd-current Date: Sun, 20 Mar 2016 16:05:34 -0600 In-Reply-To: <56EF1744.4030607@madpilot.net> References: <56EF12C1.1020202@madpilot.net> <56EF143F.9030308@madpilot.net> <56EF1744.4030607@madpilot.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 22:05:37 -0000 On Sun, 2016-03-20 at 22:33 +0100, Guido Falsi wrote: > On 03/20/16 22:21, Guido Falsi wrote: > > On 03/20/16 22:18, Conrad Meyer wrote: > > > Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND > > > on mmc. > > > > > > > As I said, when loading sdhci_pci I had already loaded module mmc. > > > > Anyway I'll try that again just to make sure, maybe I missed it and > > thought I had it loaded. > > > > I'll followup shortly. > > > > I confirm that I had already loaded mmc.ko. > > Here's a session log: > > Script started on Sun Mar 20 22:24:37 2016 > root@tommy:~ [0]# kldstat > > Id Refs Address Size Name > 1 94 0xffffffff80200000 d3b488 kernel > 2 1 0xffffffff80f3d000 2d1ee8 zfs.ko > 3 2 0xffffffff8120f000 a3c8 opensolaris.ko > 4 1 0xffffffff81421000 635a tmpfs.ko > 5 1 0xffffffff81428000 781b if_lagg.ko > 6 1 0xffffffff81430000 241b if_tun.ko > 7 1 0xffffffff81433000 2266 if_gif.ko > 8 1 0xffffffff81436000 24a3 if_tap.ko > 9 1 0xffffffff81439000 be11 msdosfs.ko > 10 2 0xffffffff81445000 5f59 cd9660.ko > 11 1 0xffffffff8144b000 249 cd9660_iconv.ko > 12 1 0xffffffff8144c000 3140 libiconv.ko > 13 1 0xffffffff81450000 32fd procfs.ko > 14 1 0xffffffff81454000 3ccd pseudofs.ko > 15 1 0xffffffff81458000 53b2 mmc.ko > 16 1 0xffffffff8145e000 4274 sdhci.ko > 17 1 0xffffffff81463000 1b10 mmcsd.ko > 18 1 0xffffffff81465000 23ca sysvmsg.ko > 19 1 0xffffffff81468000 302b sysvsem.ko > 20 1 0xffffffff8146c000 2136 sysvshm.ko > 21 1 0xffffffff8146f000 cfa coretemp.ko > 22 2 0xffffffff81470000 3ac49 sound.ko > 23 1 0xffffffff814ab000 2282f snd_hda.ko > 24 1 0xffffffff814ce000 39fc autofs.ko > 25 3 0xffffffff814d2000 aafd agp.ko > 26 1 0xffffffff814dd000 8e60 fuse.ko > 27 3 0xffffffff814e6000 45ee8 vboxdrv.ko > 28 2 0xffffffff8152c000 2a0f vboxnetflt.ko > 29 2 0xffffffff8152f000 9506 netgraph.ko > 30 1 0xffffffff81539000 150b ng_ether.ko > 31 1 0xffffffff8153b000 3f86 vboxnetadp.ko > 32 1 0xffffffff8153f000 8b936 i915kms.ko > 33 1 0xffffffff815cb000 4c8e1 drm2.ko > 34 4 0xffffffff81618000 1ca0 iicbus.ko > 35 1 0xffffffff8161a000 ecb iic.ko > 36 1 0xffffffff8161b000 1663 iicbb.ko > root@tommy:~ [0]# kldload sdhci_pci > > kldload: an error occurred while loading the module. Please check > dmesg(8) for more details. > root@tommy:~ [1]# exit > > Script done on Sun Mar 20 22:25:01 2016 > > the full error in dmesg is the same as stated before: > > link_elf_obj: symbol mmc_driver undefined > linker_load_file: Unsupported file type > > Meybe the symbol is optimized out by the compiler in the module? > I suspect this is caused by my r292180 back in December. I'm trying to figure out if that's the case and if so, how to fix it. -- Ian From owner-freebsd-current@freebsd.org Sun Mar 20 22:40:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36F6DACEDC6 for ; Sun, 20 Mar 2016 22:40:36 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E83D91BE5; Sun, 20 Mar 2016 22:40:35 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mx1.stack.nl (Postfix) with ESMTP id 3B4A1B8060; Sun, 20 Mar 2016 23:40:34 +0100 (CET) Received: by toad2.stack.nl (Postfix, from userid 1677) id 9647B892B9; Sun, 20 Mar 2016 23:40:34 +0100 (CET) Date: Sun, 20 Mar 2016 23:40:34 +0100 From: Jilles Tjoelker To: Ian Lepore Cc: Guido Falsi , cem@FreeBSD.org, freebsd-current Subject: Re: sdhci_pci.ko fails to load Message-ID: <20160320224034.GB78464@stack.nl> References: <56EF12C1.1020202@madpilot.net> <56EF143F.9030308@madpilot.net> <56EF1744.4030607@madpilot.net> <1458511534.68920.84.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458511534.68920.84.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Mar 2016 22:40:36 -0000 On Sun, Mar 20, 2016 at 04:05:34PM -0600, Ian Lepore wrote: > On Sun, 2016-03-20 at 22:33 +0100, Guido Falsi wrote: > > On 03/20/16 22:21, Guido Falsi wrote: > > > On 03/20/16 22:18, Conrad Meyer wrote: > > > > Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND > > > > on mmc. > > > As I said, when loading sdhci_pci I had already loaded module mmc. > > > Anyway I'll try that again just to make sure, maybe I missed it and > > > thought I had it loaded. > > > I'll followup shortly. > > I confirm that I had already loaded mmc.ko. > [snip] > > the full error in dmesg is the same as stated before: > > link_elf_obj: symbol mmc_driver undefined > > linker_load_file: Unsupported file type > > Meybe the symbol is optimized out by the compiler in the module? > I suspect this is caused by my r292180 back in December. I'm trying to > figure out if that's the case and if so, how to fix it. I think this is caused by the missing MODULE_DEPEND. The kernel linker only looks for symbols in the ELF objects containing the module itself and its declared dependencies. If mmc is compiled into the main kernel image, this is always satisfied. -- Jilles Tjoelker From owner-freebsd-current@freebsd.org Mon Mar 21 00:56:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E702AD6DC4 for ; Mon, 21 Mar 2016 00:56:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 35F8693C for ; Mon, 21 Mar 2016 00:56:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8da571a8-eeff-11e5-b278-7d22021d92d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 21 Mar 2016 00:55:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2L0stNu007335; Sun, 20 Mar 2016 18:54:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458521695.68920.86.camel@freebsd.org> Subject: Re: sdhci_pci.ko fails to load From: Ian Lepore To: Jilles Tjoelker Cc: Guido Falsi , cem@FreeBSD.org, freebsd-current Date: Sun, 20 Mar 2016 18:54:55 -0600 In-Reply-To: <20160320224034.GB78464@stack.nl> References: <56EF12C1.1020202@madpilot.net> <56EF143F.9030308@madpilot.net> <56EF1744.4030607@madpilot.net> <1458511534.68920.84.camel@freebsd.org> <20160320224034.GB78464@stack.nl> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 00:56:05 -0000 On Sun, 2016-03-20 at 23:40 +0100, Jilles Tjoelker wrote: > On Sun, Mar 20, 2016 at 04:05:34PM -0600, Ian Lepore wrote: > > On Sun, 2016-03-20 at 22:33 +0100, Guido Falsi wrote: > > > On 03/20/16 22:21, Guido Falsi wrote: > > > > On 03/20/16 22:18, Conrad Meyer wrote: > > > > > Try 'kldload mmc' first. 'sdhci_pci' is missing a > > > > > MODULE_DEPEND > > > > > on mmc. > > > > > As I said, when loading sdhci_pci I had already loaded module > > > > mmc. > > > > > Anyway I'll try that again just to make sure, maybe I missed it > > > > and > > > > thought I had it loaded. > > > > > I'll followup shortly. > > > > I confirm that I had already loaded mmc.ko. > > > [snip] > > > the full error in dmesg is the same as stated before: > > > > link_elf_obj: symbol mmc_driver undefined > > > linker_load_file: Unsupported file type > > > > Meybe the symbol is optimized out by the compiler in the module? > > > I suspect this is caused by my r292180 back in December. I'm > > trying to > > figure out if that's the case and if so, how to fix it. > > I think this is caused by the missing MODULE_DEPEND. The kernel > linker > only looks for symbols in the ELF objects containing the module > itself > and its declared dependencies. > > If mmc is compiled into the main kernel image, this is always > satisfied. > Thanks for the clue about the linker, it would have taken me forever to figure that out by flailing around like I was doing. Hopefully this is all fixed now with r297127, but I was only able to test it on arm systems (I have no x86 with sdhci). -- Ian From owner-freebsd-current@freebsd.org Mon Mar 21 03:01:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71284AD66BA for ; Mon, 21 Mar 2016 03:01:05 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31CFF31A for ; Mon, 21 Mar 2016 03:01:04 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ob0-f181.google.com with SMTP id ts10so164772030obc.1 for ; Sun, 20 Mar 2016 20:01:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=wlREQcd0Et/DRQNjZABBWHvuOn4pDxjzqxdnAefY41M=; b=kGSYMBRWqGnATGiOXGrvEFOTBPDX+Tzl1hkwH83aVzqqqY+cgs3KiK54H2q3Ab296E K82hYtDFwUwGgHLVd2lS4RzOOjLumKKfgqzZPbOTgFtZ7Dkjd+/qbcEW4Inj7LpvuVNC ILFHvfZk7CLPZQSxwee3I8p7uoDVbVTolKwmAdSTMsGddOq3+DWei3W995J16UsW4INI TVNDWb6Kx9R/GBC+MCjrbN+I8p64U3HiptFJ+FDJ/6W0LeOR+en4U8GqYspujDrhQu9f RrEuswq/TnRmZiUUbBO5cX9LPmkuZNjdkOxdSpXdDJVtZ6Uiu0l9B93JFJjz5DJtekvz nzGA== X-Gm-Message-State: AD7BkJLWBt+skfyFiZL7GsqRsNp33fdXy5oEXOsXz37eNpfizuMWv3dQHeaXAPgLMgDbNw== X-Received: by 10.182.105.131 with SMTP id gm3mr17179698obb.23.1458508727933; Sun, 20 Mar 2016 14:18:47 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com. [209.85.214.180]) by smtp.gmail.com with ESMTPSA id 8sm10890003obo.12.2016.03.20.14.18.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Mar 2016 14:18:47 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id ts10so160819012obc.1 for ; Sun, 20 Mar 2016 14:18:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.83.237 with SMTP id t13mr15171795oey.8.1458508727360; Sun, 20 Mar 2016 14:18:47 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.157.36.202 with HTTP; Sun, 20 Mar 2016 14:18:47 -0700 (PDT) In-Reply-To: <56EF12C1.1020202@madpilot.net> References: <56EF12C1.1020202@madpilot.net> Date: Sun, 20 Mar 2016 14:18:47 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: sdhci_pci.ko fails to load From: Conrad Meyer To: Guido Falsi Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 03:01:05 -0000 Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND on mmc. Best, Conrad On Sun, Mar 20, 2016 at 2:14 PM, Guido Falsi wrote: > Hi, > > I've just noticed a regression. > > I have been using mmc.ko, mmcsd.ko and sdhci.ko to use the integrated > SSD card reader on my laptop. > > I have actively used it during a trip at the start of December, so I'm > sure it did work as expected then with a kernel from the end of November. > > Today with rr296993 I noticed it was not working, the device was not > being attached by the kernel. > > doing "kldload sdhci_pci" retirns this error: > > link_elf_obj: symbol mmc_driver undefined > linker_load_file: Unsupported file type > > I tried with the modules mentioned above already loaded. > > Compiling a kernel with the devices statically linked in works as expected. > > Is this some kind of regression? > > -- > Guido Falsi > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Mar 21 03:38:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8474AD6F1D for ; Mon, 21 Mar 2016 03:38:03 +0000 (UTC) (envelope-from rizzo@i805.com.br) Received: from server.i805.com.br (mailhost.i805.com.br [50.7.9.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fbsd10.amd64", Issuer "fbsd10.amd64" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93C061807 for ; Mon, 21 Mar 2016 03:38:02 +0000 (UTC) (envelope-from rizzo@i805.com.br) Received: from www.i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.15.2/8.15.2) with ESMTP id u2L3CeSm066572 for ; Mon, 21 Mar 2016 00:13:01 -0300 (BRT) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: freebsd-current@freebsd.org Subject: nic ral0 not created Date: Mon, 21 Mar 2016 00:12:40 -0300 Message-Id: <20160321030843.M55986@i805.com.br> X-Mailer: OpenWebMail 3.00_beta4 20140806 79bb7cc X-OriginatingIP: 186.221.218.162 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on server.i805.com.br X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 03:38:04 -0000 Hi all, I'm download a least memstick image (20160308) and my notebook create a ral0 interface. look at this photo http://ibin.co/2XJ6CoBE6t2a The sistem reconise as a RT2790 Ralink but when I run the ifconfig command it's not showed. Have someone any idea? TIZ --- /************************************************* **Nilton José Rizzo UFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **************************************************/ From owner-freebsd-current@freebsd.org Mon Mar 21 05:21:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 596F2AD629D for ; Mon, 21 Mar 2016 05:21:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 D6541669 for ; Mon, 21 Mar 2016 05:21:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2L5L3mb094992 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 07:21:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2L5L3mb094992 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2L5L2b0094990; Mon, 21 Mar 2016 07:21:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Mar 2016 07:21:02 +0200 From: Konstantin Belousov To: "Oleg V. Nauman" Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Message-ID: <20160321052102.GJ1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <5286161.5Mbx8epR8j@asus.theweb.org.ua> <20160319194757.GE1741@kib.kiev.ua> <9991609.BzAFArhlj3@asus.theweb.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9991609.BzAFArhlj3@asus.theweb.org.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 05:21:10 -0000 On Sun, Mar 20, 2016 at 09:28:13AM +0200, Oleg V. Nauman wrote: > Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 0x80d46ebc0' > at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 2 ) > > What I have got after applying this patch: > > #0 0x0000000805913d6a in thr_kill () from /lib/libc.so.7 > #1 0x0000000805913d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x0000000805913ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > #3 0x0000000805639554 in _thread_exit ( > fname=0x80563ac36 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=155, > msg=0x7fffffffd1c0 "mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 > 0x80d46ebc0") > at /usr/src/lib/libthr/thread/thr_exit.c:182 > #4 0x000000080562fe36 in mutex_assert_not_owned (m=0x800632000) > at /usr/src/lib/libthr/thread/thr_mutex.c:155 > #5 0x0000000805630009 in enqueue_mutex (curthread=0x80cc15000, m=0x800632000) > at /usr/src/lib/libthr/thread/thr_mutex.c:400 > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > m=0x800632000, > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 > #7 0x0000000805630280 in mutex_lock_common (m=0x800632000, > abstime=0x7fffffffd358, > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:553 > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 > ... > gdb) f 6 > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > m=0x800632000, > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 > 535 enqueue_mutex(curthread, m); > (gdb) p *curthread > $1 = {tid = 100444, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, > m_spare = {0, 0, > 0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle > = { > tqe_next = 0x0, tqe_prev = 0x805841000 <_thread_list>}, gcle = {tqe_next = > 0x0, > tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80584b3c0}, wle = > {tqe_next = 0x0, > tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = > {sched_policy = 2, > sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = > 0x7ffffdfff000, > stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize > = 0}, > cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, > cancel_async = 0, > cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0, > in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = > 0, si_pid = 0, > si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, > sival_ptr = 0x0, > sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, > _timer = { > _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, > __spare__ = { > __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, > deferred_sigmask = {__bits = { > 0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0, > __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}, > deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = > 0x0, flags = 0, > tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80cc151a0}, {tqh_first = > 0x0, > tqh_last = 0x80cc151b0}, {tqh_first = 0x0, tqh_last = 0x80cc151c0}, > {tqh_first = 0x0, > tqh_last = 0x80cc151d0}}, ret = 0x0, specific = 0x800631000, > specific_data_count = 5, > rdlock_count = 0, rtld_bits = 0, tcb = 0x8006df108, cleanup = 0x0, ex = { > exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = > 0}, > unwind_stackend = 0x7ffffffff000, unwind_disabled = 0, magic = 3499860245, > report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p > = 0, data = 0}, > wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, > defer_waiters = { > 0x0 }, wake_addr = 0x80584b0c8, sleepqueue = > 0x80cc14040} > > (gdb) f 8 > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 > 583 ret = mutex_lock_common(m, abstime, 0); > (gdb) p *mutex > $2 = (pthread_mutex_t) 0x8000000000000001 > (gdb) p m > $3 = (struct pthread_mutex *) 0x800632000 > (gdb) p *m > $4 = {m_lock = {m_owner = 100444, m_flags = 1, m_ceilings = {0, 0}, m_spare = > {0, 0, 0, 0}}, > m_flags = 1, m_owner = 100444, m_count = 0, m_spinloops = 0, m_yieldloops = > 0, m_qe = { > tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = 0x0}} > Thank you, this is useful, but misterious. Below is my current (mis-)understanding of the problem based on your debugging data. I wrote this mostly to myself, and continue looking at it, but might be somebody else is curious. Note that there is inconsistency in the debugging output from libthr, which reports that m->m_qe.tqe_next is not NULL (and it looks like a reasonable pointer), while gdb reports that both pointers from m_qe are correctly NULLs. The m_lock.m_owner and m_owner values are fine both from libthr output and from gdb output. Additional interesting detail is that m_qe.tqe_prev is NULL, which agrees with the order of zeroing in mutex_init_link(). So it sounds as if dequeue_mutex() is executed after the m_lock.m_owner relinguished ownership of the mutex. Visual code inspection does not reveal such pathes, it would be huge bug anyway. I currently do not see how it is possible at all. Either some additional code is somewhere, or memory ordering is broken, or memory is corrupted. That said, I will flush my patch queue for the libthr shortly, which includes the fork/pshared fix you already tested. Ideally, I need the minimal stand-alone binary or source which demostrates the problem. I understand that it is hard to get with KDE. As an aside question, what hardware is used to reproduce the assert ? From owner-freebsd-current@freebsd.org Mon Mar 21 07:07:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ED23AD7CD4 for ; Mon, 21 Mar 2016 07:07:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 1E1BCDA for ; Mon, 21 Mar 2016 07:07:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2L77Cqj079378 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 09:07:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2L77Cqj079378 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2L77AWw079233; Mon, 21 Mar 2016 09:07:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Mar 2016 09:07:10 +0200 From: Konstantin Belousov To: "Oleg V. Nauman" Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Message-ID: <20160321070710.GK1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <5286161.5Mbx8epR8j@asus.theweb.org.ua> <20160319194757.GE1741@kib.kiev.ua> <9991609.BzAFArhlj3@asus.theweb.org.ua> <20160321052102.GJ1741@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160321052102.GJ1741@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 07:07:19 -0000 On Mon, Mar 21, 2016 at 07:21:02AM +0200, Konstantin Belousov wrote: > On Sun, Mar 20, 2016 at 09:28:13AM +0200, Oleg V. Nauman wrote: > > Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 0x80d46ebc0' > > at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 2 ) > > > > What I have got after applying this patch: > > > > #0 0x0000000805913d6a in thr_kill () from /lib/libc.so.7 > > #1 0x0000000805913d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 > > #2 0x0000000805913ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 > > #3 0x0000000805639554 in _thread_exit ( > > fname=0x80563ac36 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=155, > > msg=0x7fffffffd1c0 "mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 > > 0x80d46ebc0") > > at /usr/src/lib/libthr/thread/thr_exit.c:182 > > #4 0x000000080562fe36 in mutex_assert_not_owned (m=0x800632000) > > at /usr/src/lib/libthr/thread/thr_mutex.c:155 > > #5 0x0000000805630009 in enqueue_mutex (curthread=0x80cc15000, m=0x800632000) > > at /usr/src/lib/libthr/thread/thr_mutex.c:400 > > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > > m=0x800632000, > > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 > > #7 0x0000000805630280 in mutex_lock_common (m=0x800632000, > > abstime=0x7fffffffd358, > > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:553 > > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 > > ... > > gdb) f 6 > > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > > m=0x800632000, > > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:535 > > 535 enqueue_mutex(curthread, m); > > (gdb) p *curthread > > $1 = {tid = 100444, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, > > m_spare = {0, 0, > > 0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle > > = { > > tqe_next = 0x0, tqe_prev = 0x805841000 <_thread_list>}, gcle = {tqe_next = > > 0x0, > > tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80584b3c0}, wle = > > {tqe_next = 0x0, > > tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = > > {sched_policy = 2, > > sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = > > 0x7ffffdfff000, > > stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize > > = 0}, > > cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, > > cancel_async = 0, > > cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0, > > in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = > > 0, si_pid = 0, > > si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, > > sival_ptr = 0x0, > > sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, > > _timer = { > > _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, > > __spare__ = { > > __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, > > deferred_sigmask = {__bits = { > > 0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0, > > __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}, > > deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = > > 0x0, flags = 0, > > tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80cc151a0}, {tqh_first = > > 0x0, > > tqh_last = 0x80cc151b0}, {tqh_first = 0x0, tqh_last = 0x80cc151c0}, > > {tqh_first = 0x0, > > tqh_last = 0x80cc151d0}}, ret = 0x0, specific = 0x800631000, > > specific_data_count = 5, > > rdlock_count = 0, rtld_bits = 0, tcb = 0x8006df108, cleanup = 0x0, ex = { > > exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = > > 0}, > > unwind_stackend = 0x7ffffffff000, unwind_disabled = 0, magic = 3499860245, > > report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p > > = 0, data = 0}, > > wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, > > defer_waiters = { > > 0x0 }, wake_addr = 0x80584b0c8, sleepqueue = > > 0x80cc14040} > > > > (gdb) f 8 > > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > > abstime=0x7fffffffd358) at /usr/src/lib/libthr/thread/thr_mutex.c:583 > > 583 ret = mutex_lock_common(m, abstime, 0); > > (gdb) p *mutex > > $2 = (pthread_mutex_t) 0x8000000000000001 > > (gdb) p m > > $3 = (struct pthread_mutex *) 0x800632000 > > (gdb) p *m > > $4 = {m_lock = {m_owner = 100444, m_flags = 1, m_ceilings = {0, 0}, m_spare = > > {0, 0, 0, 0}}, > > m_flags = 1, m_owner = 100444, m_count = 0, m_spinloops = 0, m_yieldloops = > > 0, m_qe = { > > tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = 0x0}} > > > > Thank you, this is useful, but misterious. Below is my current > (mis-)understanding of the problem based on your debugging data. I wrote > this mostly to myself, and continue looking at it, but might be somebody > else is curious. > > Note that there is inconsistency in the debugging output from libthr, > which reports that m->m_qe.tqe_next is not NULL (and it looks like a > reasonable pointer), while gdb reports that both pointers from m_qe are > correctly NULLs. The m_lock.m_owner and m_owner values are fine both > from libthr output and from gdb output. Additional interesting detail is > that m_qe.tqe_prev is NULL, which agrees with the order of zeroing in > mutex_init_link(). > > So it sounds as if dequeue_mutex() is executed after the m_lock.m_owner > relinguished ownership of the mutex. Visual code inspection does not > reveal such pathes, it would be huge bug anyway. I currently do not see > how it is possible at all. Either some additional code is somewhere, or > memory ordering is broken, or memory is corrupted. > > That said, I will flush my patch queue for the libthr shortly, which > includes the fork/pshared fix you already tested. Ideally, I need the > minimal stand-alone binary or source which demostrates the problem. I > understand that it is hard to get with KDE. > > As an aside question, what hardware is used to reproduce the assert ? Please, use the stock libthr from r297141, and apply the following debugging kernel patch. I am interested whether the messages appear in dmesg/console for your load. diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c index 9474b0b..7718870 100644 --- a/sys/kern/kern_umtx.c +++ b/sys/kern/kern_umtx.c @@ -3629,6 +3629,7 @@ umtx_shm_create_reg(struct thread *td, const struct umtx_key *key, reg = umtx_shm_find_reg(key); if (reg != NULL) { +printf("pid %d creating existing key 1\n", td->td_proc->p_pid); *res = reg; return (0); } @@ -3650,6 +3651,7 @@ umtx_shm_create_reg(struct thread *td, const struct umtx_key *key, if (reg1 != NULL) { mtx_unlock(&umtx_shm_lock); umtx_shm_free_reg(reg); +printf("pid %d creating existing key 2\n", td->td_proc->p_pid); *res = reg1; return (0); } From owner-freebsd-current@freebsd.org Mon Mar 21 08:29:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADECBAD736D for ; Mon, 21 Mar 2016 08:29:07 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7463BBD0 for ; Mon, 21 Mar 2016 08:29:07 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 852EE6DF91B; Mon, 21 Mar 2016 09:29:04 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u2L8T4kH067625; Mon, 21 Mar 2016 09:29:04 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u2L8T065065228; Mon, 21 Mar 2016 09:29:00 +0100 (CET) (envelope-from lars) Date: Mon, 21 Mar 2016 09:29:00 +0100 From: Lars Engels To: Nilton Jose Rizzo Cc: freebsd-current@freebsd.org Subject: Re: nic ral0 not created Message-ID: <20160321082900.GK31139@e-new.0x20.net> Mail-Followup-To: Lars Engels , Nilton Jose Rizzo , freebsd-current@freebsd.org References: <20160321030843.M55986@i805.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cN0A5YokcrYPGsSB" Content-Disposition: inline In-Reply-To: <20160321030843.M55986@i805.com.br> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 08:29:07 -0000 --cN0A5YokcrYPGsSB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 21, 2016 at 12:12:40AM -0300, Nilton Jose Rizzo wrote: >=20 >=20 >=20 > Hi all, >=20 > I'm download a least memstick image (20160308) and=20 > my notebook create a ral0 interface. >=20 > look at this photo > http://ibin.co/2XJ6CoBE6t2a >=20 > The sistem reconise as a RT2790 Ralink but when I run > the ifconfig command it's not showed. >=20 > Have someone any idea? Wireless devices no longer show up in ifconfig's output. You should see the device when you run sysctl net.wlan.devices Then you can create a wlan0 device: ifconfig wlan0 create wlandev ral0 and use the wlan0 device. --cN0A5YokcrYPGsSB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJW77DMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1thWUH/1tmNiRYgCJphTQGhjyMMEMe JE90kFWVWy0tvAxlrM0S0GAR24cUdNpL/9imwZGGLBQC+Xr77lBQ0CpW/gLvE/cy PNgqVD6okvzcIH9isbeASzzg8qteNOZkZL3PVnJWtM3VSoN507tNfMGjN2+aMPzo fMv8AvRdWKI6lOoWruvzKmZ2bq8XmmQkUEZQetfJJOjys3UC6SOlMTEYc+V/lVvO d/ctDZrxSpXNBehDv3QG+iq+XOxMU5Si55r92hsaLzrFgEdUPjtSr/XfUl/C39Fr VCbS5rydozDkbar6kmAJahYSZeroghzWFpbXfmxhf0D2FJHAIhGGiKH64+b+KYc= =O/T1 -----END PGP SIGNATURE----- --cN0A5YokcrYPGsSB-- From owner-freebsd-current@freebsd.org Mon Mar 21 10:15:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37E65AD700F for ; Mon, 21 Mar 2016 10:15:32 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8AD6C9 for ; Mon, 21 Mar 2016 10:15:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id u2LAIo4L035578 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 21 Mar 2016 12:18:53 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id u2LAFGtD028182 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Mar 2016 12:15:16 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id u2LAFG2o028181; Mon, 21 Mar 2016 12:15:16 +0200 (EET) (envelope-from oleg@opentransfer.com) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@opentransfer.com using -f From: "Oleg V. Nauman" To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Date: Mon, 21 Mar 2016 12:15:15 +0200 Message-ID: <1541955.eeyoXZYkvP@asus.theweb.org.ua> Organization: Ecommerce LLC User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160321070710.GK1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <20160321052102.GJ1741@kib.kiev.ua> <20160321070710.GK1741@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 10:15:32 -0000 On Monday 21 March 2016 09:07:10 you wrote: > On Mon, Mar 21, 2016 at 07:21:02AM +0200, Konstantin Belousov wrote: > > On Sun, Mar 20, 2016 at 09:28:13AM +0200, Oleg V. Nauman wrote: > > > Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 > > > 0x80d46ebc0' at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c > > > (errno = 2 )> > > > > What I have got after applying this patch: > > > #0 0x0000000805913d6a in thr_kill () from /lib/libc.so.7 > > > #1 0x0000000805913d3b in __raise (s=6) at > > > /usr/src/lib/libc/gen/raise.c:52 > > > #2 0x0000000805913ca9 in abort () at > > > /usr/src/lib/libc/stdlib/abort.c:65 > > > #3 0x0000000805639554 in _thread_exit ( > > > > > > fname=0x80563ac36 "/usr/src/lib/libthr/thread/thr_mutex.c", > > > lineno=155, > > > msg=0x7fffffffd1c0 "mutex 0x800632000 own 0x1885c 0x1885c is on list > > > 0x0 > > > > > > 0x80d46ebc0") > > > > > > at /usr/src/lib/libthr/thread/thr_exit.c:182 > > > > > > #4 0x000000080562fe36 in mutex_assert_not_owned (m=0x800632000) > > > > > > at /usr/src/lib/libthr/thread/thr_mutex.c:155 > > > > > > #5 0x0000000805630009 in enqueue_mutex (curthread=0x80cc15000, > > > m=0x800632000)> > > > > at /usr/src/lib/libthr/thread/thr_mutex.c:400 > > > > > > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > > > m=0x800632000, > > > > > > abstime=0x7fffffffd358) at > > > /usr/src/lib/libthr/thread/thr_mutex.c:535 > > > > > > #7 0x0000000805630280 in mutex_lock_common (m=0x800632000, > > > abstime=0x7fffffffd358, > > > > > > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:553 > > > > > > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > > > > > > abstime=0x7fffffffd358) at > > > /usr/src/lib/libthr/thread/thr_mutex.c:583 > > > > > > ... > > > gdb) f 6 > > > #6 0x0000000805631665 in mutex_lock_sleep (curthread=0x80cc15000, > > > m=0x800632000, > > > > > > abstime=0x7fffffffd358) at > > > /usr/src/lib/libthr/thread/thr_mutex.c:535 > > > > > > 535 enqueue_mutex(curthread, m); > > > (gdb) p *curthread > > > $1 = {tid = 100444, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, > > > 0}, > > > m_spare = {0, 0, > > > > > > 0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = > > > 0, tle > > > > > > = { > > > > > > tqe_next = 0x0, tqe_prev = 0x805841000 <_thread_list>}, gcle = > > > {tqe_next = > > > > > > 0x0, > > > > > > tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80584b3c0}, wle = > > > > > > {tqe_next = 0x0, > > > > > > tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr > > > = > > > > > > {sched_policy = 2, > > > > > > sched_inherit = 4, prio = 0, suspend = 0, flags = 258, > > > stackaddr_attr = > > > > > > 0x7ffffdfff000, > > > > > > stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, > > > cpusetsize > > > > > > = 0}, > > > > > > cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = > > > 0, > > > > > > cancel_async = 0, > > > > > > cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = > > > 0, > > > in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, > > > si_code => > > > > 0, si_pid = 0, > > > > > > si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, > > > > > > sival_ptr = 0x0, > > > > > > sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = > > > 0}, > > > > > > _timer = { > > > > > > _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band > > > = 0}, > > > > > > __spare__ = { > > > > > > __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, > > > > > > deferred_sigmask = {__bits = { > > > > > > 0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = > > > 0x0, > > > __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, > > > 0}}}, > > > > > > deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, > > > joiner = > > > > > > 0x0, flags = 0, > > > > > > tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80cc151a0}, > > > {tqh_first = > > > > > > 0x0, > > > > > > tqh_last = 0x80cc151b0}, {tqh_first = 0x0, tqh_last = > > > 0x80cc151c0}, > > > > > > {tqh_first = 0x0, > > > > > > tqh_last = 0x80cc151d0}}, ret = 0x0, specific = 0x800631000, > > > > > > specific_data_count = 5, > > > > > > rdlock_count = 0, rtld_bits = 0, tcb = 0x8006df108, cleanup = 0x0, ex > > > = { > > > > > > exception_class = 0, exception_cleanup = 0x0, private_1 = 0, > > > private_2 = > > > > > > 0}, > > > > > > unwind_stackend = 0x7ffffffff000, unwind_disabled = 0, magic = > > > 3499860245, > > > report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, > > > th_p > > > > > > = 0, data = 0}, > > > > > > wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, > > > > > > defer_waiters = { > > > > > > 0x0 }, wake_addr = 0x80584b0c8, sleepqueue = > > > > > > 0x80cc14040} > > > > > > (gdb) f 8 > > > #8 0x000000080562f6be in __pthread_mutex_timedlock (mutex=0x810a00008, > > > > > > abstime=0x7fffffffd358) at > > > /usr/src/lib/libthr/thread/thr_mutex.c:583 > > > > > > 583 ret = mutex_lock_common(m, abstime, 0); > > > (gdb) p *mutex > > > $2 = (pthread_mutex_t) 0x8000000000000001 > > > (gdb) p m > > > $3 = (struct pthread_mutex *) 0x800632000 > > > (gdb) p *m > > > $4 = {m_lock = {m_owner = 100444, m_flags = 1, m_ceilings = {0, 0}, > > > m_spare = {0, 0, 0, 0}}, > > > > > > m_flags = 1, m_owner = 100444, m_count = 0, m_spinloops = 0, > > > m_yieldloops = > > > > > > 0, m_qe = { > > > > > > tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = > > > 0x0}} > > > > Thank you, this is useful, but misterious. Below is my current > > (mis-)understanding of the problem based on your debugging data. I wrote > > this mostly to myself, and continue looking at it, but might be somebody > > else is curious. > > > > Note that there is inconsistency in the debugging output from libthr, > > which reports that m->m_qe.tqe_next is not NULL (and it looks like a > > reasonable pointer), while gdb reports that both pointers from m_qe are > > correctly NULLs. The m_lock.m_owner and m_owner values are fine both > > from libthr output and from gdb output. Additional interesting detail is > > that m_qe.tqe_prev is NULL, which agrees with the order of zeroing in > > mutex_init_link(). > > > > So it sounds as if dequeue_mutex() is executed after the m_lock.m_owner > > relinguished ownership of the mutex. Visual code inspection does not > > reveal such pathes, it would be huge bug anyway. I currently do not see > > how it is possible at all. Either some additional code is somewhere, or > > memory ordering is broken, or memory is corrupted. > > > > That said, I will flush my patch queue for the libthr shortly, which > > includes the fork/pshared fix you already tested. Ideally, I need the > > minimal stand-alone binary or source which demostrates the problem. I > > understand that it is hard to get with KDE. > > > > As an aside question, what hardware is used to reproduce the assert ? > > Please, use the stock libthr from r297141, and apply the following > debugging kernel patch. I am interested whether the messages appear > in dmesg/console for your load. > > diff --git a/sys/kern/kern_umtx.c b/sys/kern/kern_umtx.c > index 9474b0b..7718870 100644 > --- a/sys/kern/kern_umtx.c > +++ b/sys/kern/kern_umtx.c > @@ -3629,6 +3629,7 @@ umtx_shm_create_reg(struct thread *td, const struct > umtx_key *key, > > reg = umtx_shm_find_reg(key); > if (reg != NULL) { > +printf("pid %d creating existing key 1\n", td->td_proc->p_pid); > *res = reg; > return (0); > } > @@ -3650,6 +3651,7 @@ umtx_shm_create_reg(struct thread *td, const struct > umtx_key *key, if (reg1 != NULL) { > mtx_unlock(&umtx_shm_lock); > umtx_shm_free_reg(reg); > +printf("pid %d creating existing key 2\n", td->td_proc->p_pid); > *res = reg1; > return (0); > } OK, but please take a look what I have found ( it makes me thinking that problem is within the compiled KDE code ): The failure point within the KDE code is the same ( at least it is true for coredumps generated today ): #7 0x0000000805a2f6be in __pthread_mutex_timedlock (mutex=0x81b200008, abstime=0x7fffffffd458) at /usr/src/lib/libthr/thread/thr_mutex.c:583 #8 0x000000080443c4b0 in pthreadTimedLock::lock (this=0x81777b680) at /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252 .... (gdb) f 8 #8 0x000000080443c4b0 in pthreadTimedLock::lock (this=0x81777b680) at /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252 252 return pthread_mutex_timedlock(&m_mutex, &timeout) == 0; (gdb) p &m_mutex $1 = (pthread_mutex_t *) 0x81b200008 (gdb) p m_mutex $2 = (pthread_mutex_t &) @0x81b200008: 0x8000000000000001 (gdb) p &timeout $3 = (timespec *) 0x6 (gdb) p timeout Cannot access memory at address 0x6 (gdb) It seems that both m_mutex and timeout are wrong The class which generates coredumps looks like: #if defined(KSDC_THREAD_PROCESS_SHARED_SUPPORTED) && defined(KSDC_TIMEOUTS_SUPPORTED) class pthreadTimedLock : public pthreadLock { public: pthreadTimedLock(pthread_mutex_t &mutex) : pthreadLock(mutex) { } virtual bool lock() { struct timespec timeout; // Long timeout, but if we fail to meet this timeout it's probably a cache // corruption (and if we take 8 seconds then it should be much much quicker // the next time anyways since we'd be paged back in from disk) timeout.tv_sec = 10 + ::time(NULL); // Absolute time, so 10 seconds from now timeout.tv_nsec = 0; return pthread_mutex_timedlock(&m_mutex, &timeout) == 0; } }; #endif It is called by: (gdb) f 9 #9 0x000000080443c8a8 in KSharedDataCache::Private::CacheLocker::cautiousLock ( this=0x7fffffffd5f0) at /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache.cpp:1259 1259 while (!d->lock() && !isLockedCacheSafe()) { gdb) p *d $4 = {m_cacheName = {static null = {}, static shared_null = {ref = { _q_value = 2731}, alloc = 0, size = 0, data = 0x6192ca , clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0, capacity = 0, reserved = 0, array = {0}}, static shared_empty = {ref = {_q_value = 50}, alloc = 0, size = 0, data = 0x805105c3a , clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0, capacity = 0, reserved = 0, array = {0}}, d = 0x8176e8180, static codecForCStrings = 0x0}, shm = 0x81b200000, m_lock = {> = {> = {value = 0x81777b680}, d = 0x81777b6c0}, }, m_mapSize = 10547304, m_defaultCacheSize = 10485760, m_expectedItemSize = 0, m_expectedType = LOCKTYPE_MUTEX} (gdb) p d $5 = (KSharedDataCache::Private *) 0x8176d2030 Well I understand that unwinding the KDE code it is a task not for humans.. The hardware is ASUS X552C notebook, Ivybridge, amd64 I noticed massive coredumps after x11/kdelibs4 recompilation with clang 3.8.0 so it is possible that it is a problem with code generation. It is does not depend on optimization level ( at least it exhibits the same behavior for both -O2 and -O0 ) The only CPU/optimization/code generation specific setting is CPUTYPE?=nehalem in make.conf Thank you From owner-freebsd-current@freebsd.org Mon Mar 21 11:23:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8834AD87CF for ; Mon, 21 Mar 2016 11:23:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 533CBCC8 for ; Mon, 21 Mar 2016 11:23:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2LBMxUn061278 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 13:22:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2LBMxUn061278 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2LBMwX0061277; Mon, 21 Mar 2016 13:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Mar 2016 13:22:58 +0200 From: Konstantin Belousov To: "Oleg V. Nauman" Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Message-ID: <20160321112258.GM1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <20160321052102.GJ1741@kib.kiev.ua> <20160321070710.GK1741@kib.kiev.ua> <1541955.eeyoXZYkvP@asus.theweb.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1541955.eeyoXZYkvP@asus.theweb.org.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 11:23:04 -0000 On Mon, Mar 21, 2016 at 12:15:15PM +0200, Oleg V. Nauman wrote: > OK, but please take a look what I have found ( it makes me thinking that > problem is within the compiled KDE code ): > The failure point within the KDE code is the same ( at least it is true for > coredumps generated today ): > > #7 0x0000000805a2f6be in __pthread_mutex_timedlock (mutex=0x81b200008, > abstime=0x7fffffffd458) at /usr/src/lib/libthr/thread/thr_mutex.c:583 > #8 0x000000080443c4b0 in pthreadTimedLock::lock (this=0x81777b680) > at > /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252 > .... > (gdb) f 8 > #8 0x000000080443c4b0 in pthreadTimedLock::lock (this=0x81777b680) > at > /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252 > 252 return pthread_mutex_timedlock(&m_mutex, &timeout) == 0; > (gdb) p &m_mutex > $1 = (pthread_mutex_t *) 0x81b200008 > (gdb) p m_mutex > $2 = (pthread_mutex_t &) @0x81b200008: 0x8000000000000001 This is correct. The value is the special cookie set for the process-shared locks, the actual lock exists elsewere. > (gdb) p &timeout > $3 = (timespec *) 0x6 This might be some gdb issue. Anyway, the timeout value is not the problem. > (gdb) p timeout > Cannot access memory at address 0x6 > (gdb) > > It seems that both m_mutex and timeout are wrong m_mutex is fine, as I noted above. > > The class which generates coredumps looks like: > > #if defined(KSDC_THREAD_PROCESS_SHARED_SUPPORTED) && > defined(KSDC_TIMEOUTS_SUPPORTED) > class pthreadTimedLock : public pthreadLock > { > public: > pthreadTimedLock(pthread_mutex_t &mutex) > : pthreadLock(mutex) > { > } > > virtual bool lock() > { > struct timespec timeout; > > // Long timeout, but if we fail to meet this timeout it's probably a > cache > // corruption (and if we take 8 seconds then it should be much much > quicker > // the next time anyways since we'd be paged back in from disk) > timeout.tv_sec = 10 + ::time(NULL); // Absolute time, so 10 seconds > from now > timeout.tv_nsec = 0; > > return pthread_mutex_timedlock(&m_mutex, &timeout) == 0; > } > }; > #endif > > It is called by: > > (gdb) f 9 > #9 0x000000080443c8a8 in KSharedDataCache::Private::CacheLocker::cautiousLock > ( > this=0x7fffffffd5f0) > at > /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache.cpp:1259 > 1259 while (!d->lock() && !isLockedCacheSafe()) { > gdb) p *d > $4 = {m_cacheName = {static null = {}, static shared_null = > {ref = { > _q_value = 2731}, alloc = 0, size = 0, data = 0x6192ca > , > clean = 0, simpletext = 0, righttoleft = 0, asciiCache = 0, capacity = > 0, reserved = 0, > array = {0}}, static shared_empty = {ref = {_q_value = 50}, alloc = 0, > size = 0, > data = 0x805105c3a , clean = 0, simpletext = > 0, > righttoleft = 0, asciiCache = 0, capacity = 0, reserved = 0, array = > {0}}, > d = 0x8176e8180, static codecForCStrings = 0x0}, shm = 0x81b200000, > m_lock = {> = > {> = {value = 0x81777b680}, d = 0x81777b6c0}, > }, m_mapSize = 10547304, > m_defaultCacheSize = 10485760, m_expectedItemSize = 0, m_expectedType = > LOCKTYPE_MUTEX} > (gdb) p d > $5 = (KSharedDataCache::Private *) 0x8176d2030 > > Well I understand that unwinding the KDE code it is a task not for humans.. > > The hardware is ASUS X552C notebook, Ivybridge, amd64 > I noticed massive coredumps after x11/kdelibs4 recompilation with clang 3.8.0 > so it is possible that it is a problem with code generation. > It is does not depend on optimization level ( at least it exhibits the same > behavior for both -O2 and -O0 ) > The only CPU/optimization/code generation specific setting is > CPUTYPE?=nehalem > in make.conf In other words, there is no virtualization involved. I think that the problem at hands is not related to clang update. You recently rebuilt kde libs, which probably triggered detection of the new feature, process-shared locks in our libthr. Before that, older HEAD does not exposed p/shared as implemented option. Somehow the implementation and KDE expectations do not match, and asserts in libthr catch that. Anyway, please apply the debugging patch I posted in the previous mail. From owner-freebsd-current@freebsd.org Mon Mar 21 12:02:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6285AAD79F4 for ; Mon, 21 Mar 2016 12:02:51 +0000 (UTC) (envelope-from rizzo@i805.com.br) Received: from server.i805.com.br (mailhost.i805.com.br [50.7.9.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fbsd10.amd64", Issuer "fbsd10.amd64" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A9E378A for ; Mon, 21 Mar 2016 12:02:50 +0000 (UTC) (envelope-from rizzo@i805.com.br) Received: from www.i805.com.br (localhost [127.0.0.1]) by server.i805.com.br (8.15.2/8.15.2) with ESMTP id u2LC2NbE071534; Mon, 21 Mar 2016 09:02:43 -0300 (BRT) (envelope-from rizzo@i805.com.br) From: "Nilton Jose Rizzo" To: Lars Engels Cc: freebsd-current@freebsd.org Subject: Re: nic ral0 not created Date: Mon, 21 Mar 2016 09:02:23 -0300 Message-Id: <20160321120208.M99877@i805.com.br> In-Reply-To: <20160321082900.GK31139@e-new.0x20.net> References: <20160321030843.M55986@i805.com.br> <20160321082900.GK31139@e-new.0x20.net> X-Mailer: OpenWebMail 3.00_beta4 20140806 79bb7cc X-OriginatingIP: 186.221.218.162 (rizzo) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on server.i805.com.br X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 12:02:51 -0000 Em Mon, 21 Mar 2016 09:29:00 +0100, Lars Engels escreveu > On Mon, Mar 21, 2016 at 12:12:40AM -0300, Nilton Jose Rizzo wrote: > > > > > > > > Hi all, > > > > I'm download a least memstick image (20160308) and > > my notebook create a ral0 interface. > > > > look at this photo > > http://ibin.co/2XJ6CoBE6t2a > > > > The sistem reconise as a RT2790 Ralink but when I run > > the ifconfig command it's not showed. > > > > Have someone any idea? > > Wireless devices no longer show up in ifconfig's output. You should see > the device when you run > > sysctl net.wlan.devices > > Then you can create a wlan0 device: > > ifconfig wlan0 create wlandev ral0 > > and use the wlan0 device. Thanx --- /************************************************* **Nilton José Rizzo UFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **************************************************/ From owner-freebsd-current@freebsd.org Mon Mar 21 16:11:57 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AEE1AD8890 for ; Mon, 21 Mar 2016 16:11:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EFEB19F4; Mon, 21 Mar 2016 16:11:56 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (localhost.auburn.protected-networks.net [127.0.0.1]) by mail.auburn.protected-networks.net (Postfix) with ESMTP id C97BC80; Mon, 21 Mar 2016 12:11:48 -0400 (EDT) Received: from mail.auburn.protected-networks.net ([127.0.0.1]) by mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cft5DG0ZwxGN; Mon, 21 Mar 2016 12:11:46 -0400 (EDT) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id B31E35; Mon, 21 Mar 2016 12:11:46 -0400 (EDT) To: freebsd-current , jhibbits@freebsd.org From: Michael Butler Subject: SVN r296987 -> r297000 breaks Sil 3124 channel attach Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56F01D41.9000607@protected-networks.net> Date: Mon, 21 Mar 2016 12:11:45 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 16:11:57 -0000 Something between SVN r296987 and r297000 causes the following errors in dmesg .. and the loss of the attached disks: siisch0: at channel 0 on siis0 device attach: siisch0 attach returned 6 siisch1: at channel 1 on siis0 device attach: siisch0 attach returned 6 siisch2: at channel 2 on siis0 device attach: siisch0 attach returned 6 siisch3: at channel 3 on siis0 device attach: siisch0 attach returned 6 I can't see anything but r297000 causing this :-( Michael From owner-freebsd-current@freebsd.org Mon Mar 21 16:14:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1325AD89F5 for ; Mon, 21 Mar 2016 16:14:47 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 688B7D7B for ; Mon, 21 Mar 2016 16:14:47 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id d205so144387442oia.0 for ; Mon, 21 Mar 2016 09:14:47 -0700 (PDT) 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; bh=Yf0NBkJeylYOWbF7liJQLnTidnXIcOQbPjO2njanu04=; b=gWlTm9BEnIKqgt+rO4bVmoRVJsaRg/0DegIJO5J6Nojwq2bExDS+Tbjp0hI955Loxn lvO3cRow97M6QyDKJoUr0Ixft/YXUMOC54sUUWZpnhues5bDlrLCiDv0zClbVSGsSJA3 hC0B88ui2s3QPWWe5tLDUrSfW9UcUy6JBJqggNa94x0ibHa99RSJWQMFPyxvIlWtF580 U5NtcrjKfmLwMQXkKil9CDPGPwBz6WGWJBWJ+xW7yZZX91UDXOkNWi86A1321DzIqQDh VfocnAK8yQDbqpEm4k8JhEHISNlvftlh3E0G0HdQ/kMxOVC/Zq5TmGoR5o6LsDiOPelT 0wsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Yf0NBkJeylYOWbF7liJQLnTidnXIcOQbPjO2njanu04=; b=DTZDxibOJv4xJ29KX5pC17VWSqt5OVhIhvxsMnUP5W1dH0gGg0QSSM3BllHGg2GBme Zwd8v/KH76DFOnOSkTakSd55hR7Mo1gdzYNRvmw+BajM4mb8+rN4kmF702MvWz8uj24e 6vGo0KpLJWD0Ham+6GppUKKzk+luQq8eAwcdPaKokl4S3ZDgcwIFmvQFVMZC7mQJBoC0 DlE6RPZJZHMwEUJUY2GCy4nIpKIAKO5ubc2Q8vMLkHwAk8afvOZvnIPuGOMTfDpPVIOJ 8ztovLbCaSlXXc+CMPSmot4NN5XXWp/5rS6OGEyDRugFlDf6p8iFYkjHAlpCdlOHuAg2 yA0w== X-Gm-Message-State: AD7BkJIFdSIru82igNuIbgS/fU5EvdkXyJBDjUnZM72HR6cacjzY3NHtDfOyhHMSy90wvx4EinR432sCRCZJFg== MIME-Version: 1.0 X-Received: by 10.157.63.53 with SMTP id m50mr1196733otc.54.1458576886755; Mon, 21 Mar 2016 09:14:46 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Mon, 21 Mar 2016 09:14:46 -0700 (PDT) In-Reply-To: <56F01D41.9000607@protected-networks.net> References: <56F01D41.9000607@protected-networks.net> Date: Mon, 21 Mar 2016 11:14:46 -0500 X-Google-Sender-Auth: EZBnNx-AFJLj_vZrQPJurcy3EHE Message-ID: Subject: Re: SVN r296987 -> r297000 breaks Sil 3124 channel attach From: Justin Hibbits To: Michael Butler Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 16:14:47 -0000 You're right. On line 323 of sys/dev/siis/siis.c, try replacing 'long' with 'rman_res_t', as I did for ahci.c. If this works, tonight I'll commit the fix. I envision there may be others using 'long' instead of 'u_long' for rman (u_long was the correct form until rman_res_t, so signed long was already a bug). - Justin On Mon, Mar 21, 2016 at 11:11 AM, Michael Butler wrote: > Something between SVN r296987 and r297000 causes the following errors in > dmesg .. and the loss of the attached disks: > > siisch0: at channel 0 on siis0 > device attach: siisch0 attach returned 6 > siisch1: at channel 1 on siis0 > device attach: siisch0 attach returned 6 > siisch2: at channel 2 on siis0 > device attach: siisch0 attach returned 6 > siisch3: at channel 3 on siis0 > device attach: siisch0 attach returned 6 > > I can't see anything but r297000 causing this :-( > > Michael > From owner-freebsd-current@freebsd.org Mon Mar 21 16:23:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25920AD8C2D for ; Mon, 21 Mar 2016 16:23:42 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [202.12.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5CB32BD; Mon, 21 Mar 2016 16:23:41 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (localhost.auburn.protected-networks.net [127.0.0.1]) by mail.auburn.protected-networks.net (Postfix) with ESMTP id ED3EA7F; Mon, 21 Mar 2016 12:23:39 -0400 (EDT) Received: from mail.auburn.protected-networks.net ([127.0.0.1]) by mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIcbvcsInjsw; Mon, 21 Mar 2016 12:23:37 -0400 (EDT) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 90767E; Mon, 21 Mar 2016 12:23:36 -0400 (EDT) Subject: Re: SVN r296987 -> r297000 breaks Sil 3124 channel attach To: Justin Hibbits References: <56F01D41.9000607@protected-networks.net> Cc: freebsd-current From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56F02007.1010603@protected-networks.net> Date: Mon, 21 Mar 2016 12:23:35 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 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.21 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, 21 Mar 2016 16:23:42 -0000 On 03/21/16 12:14, Justin Hibbits wrote: > You're right. On line 323 of sys/dev/siis/siis.c, try replacing > 'long' with 'rman_res_t', as I did for ahci.c. If this works, tonight > I'll commit the fix. I envision there may be others using 'long' > instead of 'u_long' for rman (u_long was the correct form until > rman_res_t, so signed long was already a bug). > > - Justin > > On Mon, Mar 21, 2016 at 11:11 AM, Michael Butler > wrote: >> Something between SVN r296987 and r297000 causes the following errors in >> dmesg .. and the loss of the attached disks: >> >> siisch0: at channel 0 on siis0 >> device attach: siisch0 attach returned 6 >> siisch1: at channel 1 on siis0 >> device attach: siisch0 attach returned 6 >> siisch2: at channel 2 on siis0 >> device attach: siisch0 attach returned 6 >> siisch3: at channel 3 on siis0 >> device attach: siisch0 attach returned 6 >> >> I can't see anything but r297000 causing this :-( That was it - perfect! Thanks :-) pcib2: at device 30.0 on pci0 pci2: on pcib2 siis0: port 0xecf0-0xecff mem 0xfe1ffc00-0xfe1ffc7f,0xfe1f0000-0xfe1f7fff irq 22 at device 1.0 on pci2 siisch0: at channel 0 on siis0 siisch1: at channel 1 on siis0 siisch2: at channel 2 on siis0 siisch3: at channel 3 on siis0 Michael From owner-freebsd-current@freebsd.org Mon Mar 21 17:42:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18389AD8169 for ; Mon, 21 Mar 2016 17:42:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 035E965A for ; Mon, 21 Mar 2016 17:42:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 02B24AD8168; Mon, 21 Mar 2016 17:42:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02521AD8167 for ; Mon, 21 Mar 2016 17:42:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 E7248659 for ; Mon, 21 Mar 2016 17:42:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2LHgYVl058912 for ; Mon, 21 Mar 2016 17:42:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 194744] [PATCH] allow to specify custom keymap when kbdmux used Date: Mon, 21 Mar 2016 17:42:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emaste@freebsd.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 21 Mar 2016 18:41:11 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 17:42:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194744 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #5 from Ed Maste --- > Yes, sorry, I looked the wrong PR. This PR is a dup of 153459. Thanks for confirming, I will make it a dup. I expect to resolve this soon, after finishing off use of the new -P option added to kbdcontrol. *** This bug has been marked as a duplicate of bug 153459 *** --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-current@freebsd.org Mon Mar 21 22:33:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09162AD8372 for ; Mon, 21 Mar 2016 22:33:14 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D31B477C for ; Mon, 21 Mar 2016 22:33:13 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id x3so281369952pfb.1 for ; Mon, 21 Mar 2016 15:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=OhugpAjeXDXdMZoWWTJXQ+iTX+MZUQOOE6y6ujlkd9U=; b=Xa58x7hRaopxwkb/jZuktUWnbCk97EaJUNFQe4jOgTFPfh/pYy1wB5dr92sqa4J7Ae hxfKc9OqNxkjhJXr9FRun0QXmc9/GqVQhZXms6cjaHjAVuiEya0XDiT/XKqaG+V8zl59 FiAzaaFHMTeLVbGiYKloXAwsgDsm6KMePcshSfWpYnh4O2/yGjPuGYh7L+VxwjGgS0eI Aj+IWH4fPLvJjk8YTvCuZo9UJalgZlCLTJClyPosvAY5qSFozZHH8T1RN5VhhhaWl/fZ XXW+hSHQ+7su0W4+mekFsByxiozBr+G3G5vKQjCH48NnZaWMYAWrlj+6w1ef0qZR3KzT JDdQ== 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; bh=OhugpAjeXDXdMZoWWTJXQ+iTX+MZUQOOE6y6ujlkd9U=; b=AFjQTFqVNFq8HoUz2VF/uuKVnWLWlW7EDeAg6Txck0AF3CwmAhFq9aL25u0Nb1coDc e4xADB969wAu/5g1APGu5a2UY4HARQpBZR1p+ShUBHZoLw+IvLrRcjnww4ZdYuxIxvDF QCnqqXNuuvR04KDzocojBbylIcymLVAM5sZWi+Z3ysjhH7QIFY34EkDJhuyzQnP/Py0P GsLo0DzJmKuZ/7KgtnHsWwwjhyEiU2HzkV5sXm2/pStgaeWGcqZeXJP4fKYqAkKPnQaI WDX3fUOLU6otL4X3lJrDcorT/VZXnu7DfURhpXsEakwEMfcl8jJWRz7Tk4rpOyIUDj0M JZ5A== X-Gm-Message-State: AD7BkJKOdn5f66DurIdH5jFt7BicpochHs675t+iM41imLCTLx2hbM4WeqlcwI/u944yvcUfMyeW2VDPXa5k4w== X-Received: by 10.98.67.67 with SMTP id q64mr49308738pfa.44.1458599593410; Mon, 21 Mar 2016 15:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.89.6 with HTTP; Mon, 21 Mar 2016 15:32:53 -0700 (PDT) From: Arseny Nasokin Date: Tue, 22 Mar 2016 01:32:53 +0300 Message-ID: Subject: sysctl: OID number(131) is already in use for 'me' To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 21 Mar 2016 22:33:14 -0000 I've recently upgrade my machine to FreeBSD-Current revision 297059 and got strange result on first boot lines: sysctl: OID number(131) is already in use for 'me' I build system in two stages: first with 'native'/crosstools clang, second in bhyve. This message appears in both times. I've tried to boot latest FreeBSD-10 and I've seen no such message. My kernel config is here: https://bitbucket.org/eirnym/bsd/src/7f7e4a234b5bba4b346fd76e5f8b35d58d2bec29/eroese/EirZen.amd64 -- Eir Nym From owner-freebsd-current@freebsd.org Tue Mar 22 06:06:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D50E3AD8B09 for ; Tue, 22 Mar 2016 06:06:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DC7DC41 for ; Tue, 22 Mar 2016 06:06:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id u2M69vdi009122 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 22 Mar 2016 08:09:59 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id u2M66NJZ002431 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 08:06:23 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id u2M66IuH002430; Tue, 22 Mar 2016 08:06:18 +0200 (EET) (envelope-from oleg@opentransfer.com) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@opentransfer.com using -f From: "Oleg V. Nauman" To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Date: Tue, 22 Mar 2016 08:06:17 +0200 Message-ID: <1850738.9W54HNFmp1@asus.theweb.org.ua> Organization: Ecommerce LLC User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160321112258.GM1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <1541955.eeyoXZYkvP@asus.theweb.org.ua> <20160321112258.GM1741@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 06:06:31 -0000 On Monday 21 March 2016 13:22:58 you wrote: > On Mon, Mar 21, 2016 at 12:15:15PM +0200, Oleg V. Nauman wrote: [skip] > > In other words, there is no virtualization involved. > > I think that the problem at hands is not related to clang update. You > recently rebuilt kde libs, which probably triggered detection of the new > feature, process-shared locks in our libthr. Before that, older HEAD > does not exposed p/shared as implemented option. Somehow the implementation > and KDE expectations do not match, and asserts in libthr catch that. > > Anyway, please apply the debugging patch I posted in the previous mail. After applying the patch: Mar 22 07:34:37 asus kernel: pid 1928 creating existing key 1 Mar 22 07:34:58 asus kernel: pid 1928 (akonadi_baloo_index), uid 1001: exited on signal 6 (core dumped) > /usr/local/bin/gdb /usr/local/bin/akonadi_baloo_indexer akonadi_baloo_index.core GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD] Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd11.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/bin/akonadi_baloo_indexer...(no debugging symbols found)...done. warning: core file may not match specified executable file. [New LWP 100294] Core was generated by `akonadi_baloo_index'. Program terminated with signal SIGABRT, Aborted. #0 0x0000000805617d6a in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x0000000805617d6a in thr_kill () from /lib/libc.so.7 #1 0x0000000805617d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000805617ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #3 0x000000080533d484 in _thread_exit ( fname=0x80533eb66 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=150, msg=0x7fffffffd300 "mutex 0x80064d000 own 0x187c6 0x187c6 is on list 0x0 0x80933ca80") at /usr/src/lib/libthr/thread/thr_exit.c:182 #4 0x0000000805333e76 in mutex_assert_not_owned (m=0x80064d000) at /usr/src/lib/libthr/thread/thr_mutex.c:150 #5 0x0000000805334049 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000) at /usr/src/lib/libthr/thread/thr_mutex.c:395 #6 0x00000008053342a3 in mutex_lock_common (m=0x80064d000, abstime=0x7fffffffd448, cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:545 #7 0x00000008053336fe in __pthread_mutex_timedlock (mutex=0x811c00008, abstime=0x7fffffffd448) at /usr/src/lib/libthr/thread/thr_mutex.c:578 #8 0x000000080443c4b0 in pthreadTimedLock::lock (this=0x80e164910) at /usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252 #9 0x000000080443c8a8 in KSharedDataCache::Private::CacheLocker::cautiousLock ( this=0x7fffffffd5e0) .... (gdb) f 5 #5 0x0000000805334049 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000) at /usr/src/lib/libthr/thread/thr_mutex.c:395 395 mutex_assert_not_owned(m); (gdb) p *curthread $1 = {tid = 100294, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, m_spare = {0, 0, 0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle = { tqe_next = 0x0, tqe_prev = 0x805544e90 <_thread_list>}, gcle = {tqe_next = 0x0, tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80554f240}, wle = {tqe_next = 0x0, tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = {sched_policy = 2, sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = 0x7ffffdfff000, stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize = 0}, cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, cancel_async = 0, cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0, in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = { _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = { __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, deferred_sigmask = {__bits = { 0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}, deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = 0x0, flags = 0, tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80e0151a0}, {tqh_first = 0x0, tqh_last = 0x80e0151b0}, {tqh_first = 0x0, tqh_last = 0x80e0151c0}, {tqh_first = 0x0, tqh_last = 0x80e0151d0}}, ret = 0x0, specific = 0x80064c000, specific_data_count = 4, rdlock_count = 0, rtld_bits = 0, tcb = 0x8006fd158, cleanup = 0x0, ex = { exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 0}, unwind_stackend = 0x7ffffffff000, unwind_disabled = 0, magic = 3499860245, report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p = 0, data = 0}, wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, defer_waiters = { 0x0 }, wake_addr = 0x80554ef48, sleepqueue = 0x80e014040} (gdb) f 7 #7 0x00000008053336fe in __pthread_mutex_timedlock (mutex=0x811c00008, abstime=0x7fffffffd448) at /usr/src/lib/libthr/thread/thr_mutex.c:578 578 ret = mutex_lock_common(m, abstime, 0); (gdb) p *mutex $2 = (pthread_mutex_t) 0x8000000000000001 (gdb) p m $3 = (struct pthread_mutex *) 0x80064d000 (gdb) p *m $4 = {m_lock = {m_owner = -2147383354, m_flags = 1, m_ceilings = {0, 0}, m_spare = {0, 0, 0, 0}}, m_flags = 1, m_owner = 100294, m_count = 0, m_spinloops = 0, m_yieldloops = 0, m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = 0x0}} Thank you From owner-freebsd-current@freebsd.org Tue Mar 22 07:53:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F088AD83AA for ; Tue, 22 Mar 2016 07:53:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 19C213F0 for ; Tue, 22 Mar 2016 07:53:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2M7rN0H072089 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 09:53:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2M7rN0H072089 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2M7rNBR072088; Tue, 22 Mar 2016 09:53:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Mar 2016 09:53:23 +0200 From: Konstantin Belousov To: "Oleg V. Nauman" Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Message-ID: <20160322075323.GR1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <1541955.eeyoXZYkvP@asus.theweb.org.ua> <20160321112258.GM1741@kib.kiev.ua> <1850738.9W54HNFmp1@asus.theweb.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1850738.9W54HNFmp1@asus.theweb.org.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 07:53:29 -0000 On Tue, Mar 22, 2016 at 08:06:17AM +0200, Oleg V. Nauman wrote: > After applying the patch: > > Mar 22 07:34:37 asus kernel: pid 1928 creating existing key 1 > Mar 22 07:34:58 asus kernel: pid 1928 (akonadi_baloo_index), uid 1001: exited > on signal 6 (core dumped) Good, thank you. Please try this one. diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c index 3342c9f..865e4cf 100644 --- a/lib/libthr/thread/thr_mutex.c +++ b/lib/libthr/thread/thr_mutex.c @@ -38,6 +38,7 @@ * $FreeBSD$ */ +#include #include "namespace.h" #include #include @@ -264,6 +265,51 @@ set_inherited_priority(struct pthread *curthread, struct pthread_mutex *m) m->m_lock.m_ceilings[1] = -1; } +static void +shared_mutex_init(struct pthread_mutex *pmtx, const struct + pthread_mutex_attr *mutex_attr) +{ + static const struct pthread_mutex_attr foobar_mutex_attr = { + .m_type = PTHREAD_MUTEX_DEFAULT, + .m_protocol = PTHREAD_PRIO_NONE, + .m_ceiling = 0, + .m_pshared = PTHREAD_PROCESS_SHARED + }; + bool done; + + /* + * Hack to allow multiple pthread_mutex_init() calls on the + * same process-shared mutex. We rely on kernel allocating + * zeroed offpage for the mutex, i.e. the + * PMUTEX_INITSTAGE_ALLOC value must be zero. + */ + for (done = false; !done;) { + switch (pmtx->m_ps) { + case PMUTEX_INITSTAGE_DONE: + atomic_thread_fence_acq(); + done = true; + break; + case PMUTEX_INITSTAGE_ALLOC: + if (atomic_cmpset_int(&pmtx->m_ps, + PMUTEX_INITSTAGE_ALLOC, PMUTEX_INITSTAGE_BUSY)) { + if (mutex_attr == NULL) + mutex_attr = &foobar_mutex_attr; + mutex_init_body(pmtx, mutex_attr); + atomic_store_rel_int(&pmtx->m_ps, + PMUTEX_INITSTAGE_DONE); + done = true; + } + break; + case PMUTEX_INITSTAGE_BUSY: + _pthread_yield(); + break; + default: + PANIC("corrupted offpage"); + break; + } + } +} + int __pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutex_attr) @@ -285,7 +331,7 @@ __pthread_mutex_init(pthread_mutex_t *mutex, if (pmtx == NULL) return (EFAULT); *mutex = THR_PSHARED_PTR; - mutex_init_body(pmtx, *mutex_attr); + shared_mutex_init(pmtx, *mutex_attr); return (0); } @@ -426,6 +472,7 @@ check_and_init_mutex(pthread_mutex_t *mutex, struct pthread_mutex **m) *m = __thr_pshared_offpage(mutex, 0); if (*m == NULL) ret = EINVAL; + shared_mutex_init(*m, NULL); } else if (__predict_false(*m <= THR_MUTEX_DESTROYED)) { if (*m == THR_MUTEX_DESTROYED) { ret = EINVAL; @@ -588,6 +635,7 @@ _pthread_mutex_unlock(pthread_mutex_t *mutex) mp = __thr_pshared_offpage(mutex, 0); if (mp == NULL) return (EINVAL); + shared_mutex_init(mp, NULL); } else { mp = *mutex; } @@ -815,6 +863,7 @@ _pthread_mutex_getprioceiling(pthread_mutex_t *mutex, m = __thr_pshared_offpage(mutex, 0); if (m == NULL) return (EINVAL); + shared_mutex_init(m, NULL); } else { m = *mutex; if (m <= THR_MUTEX_DESTROYED) @@ -839,6 +888,7 @@ _pthread_mutex_setprioceiling(pthread_mutex_t *mutex, m = __thr_pshared_offpage(mutex, 0); if (m == NULL) return (EINVAL); + shared_mutex_init(m, NULL); } else { m = *mutex; if (m <= THR_MUTEX_DESTROYED) @@ -942,12 +992,13 @@ __pthread_mutex_setyieldloops_np(pthread_mutex_t *mutex, int count) int _pthread_mutex_isowned_np(pthread_mutex_t *mutex) { - struct pthread_mutex *m; + struct pthread_mutex *m; if (*mutex == THR_PSHARED_PTR) { m = __thr_pshared_offpage(mutex, 0); if (m == NULL) return (0); + shared_mutex_init(m, NULL); } else { m = *mutex; if (m <= THR_MUTEX_DESTROYED) diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h index 7ee1fbf..0db2dad 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -146,6 +146,13 @@ TAILQ_HEAD(mutex_queue, pthread_mutex); #define MAX_DEFER_WAITERS 50 +/* + * Values for pthread_mutex m_ps indicator. + */ +#define PMUTEX_INITSTAGE_ALLOC 0 +#define PMUTEX_INITSTAGE_BUSY 1 +#define PMUTEX_INITSTAGE_DONE 2 + struct pthread_mutex { /* * Lock for accesses to this structure. @@ -156,6 +163,7 @@ struct pthread_mutex { int m_count; int m_spinloops; int m_yieldloops; + int m_ps; /* pshared init stage */ /* * Link for all mutexes a thread currently owns, of the same * prio type. From owner-freebsd-current@freebsd.org Tue Mar 22 10:01:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A949AD7820 for ; Tue, 22 Mar 2016 10:01:47 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from oleg.opentransfer.com (oleg.opentransfer.com [91.217.144.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oleg-10.opentransfer.com", Issuer "oleg-10.opentransfer.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB65485F for ; Tue, 22 Mar 2016 10:01:46 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua ([10.0.8.4]) by oleg.opentransfer.com (8.15.2/8.15.2) with ESMTPS id u2MA5CtR011813 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 22 Mar 2016 12:05:15 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: from asus.theweb.org.ua (localhost [127.0.0.1]) by asus.theweb.org.ua (8.15.2/8.15.2) with ESMTPS id u2MA1c8h002018 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 12:01:39 +0200 (EET) (envelope-from oleg@opentransfer.com) Received: (from oleg@localhost) by asus.theweb.org.ua (8.15.2/8.15.2/Submit) id u2MA1cKp002017; Tue, 22 Mar 2016 12:01:38 +0200 (EET) (envelope-from oleg@opentransfer.com) X-Authentication-Warning: asus.theweb.org.ua: oleg set sender to oleg@opentransfer.com using -f From: "Oleg V. Nauman" To: Konstantin Belousov Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Date: Tue, 22 Mar 2016 12:01:38 +0200 Message-ID: <24312565.qdfGvr8xZt@asus.theweb.org.ua> Organization: Ecommerce LLC User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160322075323.GR1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <1850738.9W54HNFmp1@asus.theweb.org.ua> <20160322075323.GR1741@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 10:01:47 -0000 On Tuesday 22 March 2016 09:53:23 Konstantin Belousov wrote: > On Tue, Mar 22, 2016 at 08:06:17AM +0200, Oleg V. Nauman wrote: > > After applying the patch: > > Mar 22 07:34:37 asus kernel: pid 1928 creating existing key 1 > > Mar 22 07:34:58 asus kernel: pid 1928 (akonadi_baloo_index), uid 1001: > > exited on signal 6 (core dumped) > > Good, thank you. Please try this one. > > diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c > index 3342c9f..865e4cf 100644 > --- a/lib/libthr/thread/thr_mutex.c > +++ b/lib/libthr/thread/thr_mutex.c > @@ -38,6 +38,7 @@ > * $FreeBSD$ > */ > > +#include > #include "namespace.h" > #include > #include > @@ -264,6 +265,51 @@ set_inherited_priority(struct pthread *curthread, > struct pthread_mutex *m) m->m_lock.m_ceilings[1] = -1; > } > > +static void > +shared_mutex_init(struct pthread_mutex *pmtx, const struct > + pthread_mutex_attr *mutex_attr) > +{ > + static const struct pthread_mutex_attr foobar_mutex_attr = { > + .m_type = PTHREAD_MUTEX_DEFAULT, > + .m_protocol = PTHREAD_PRIO_NONE, > + .m_ceiling = 0, > + .m_pshared = PTHREAD_PROCESS_SHARED > + }; > + bool done; > + > + /* > + * Hack to allow multiple pthread_mutex_init() calls on the > + * same process-shared mutex. We rely on kernel allocating > + * zeroed offpage for the mutex, i.e. the > + * PMUTEX_INITSTAGE_ALLOC value must be zero. > + */ > + for (done = false; !done;) { > + switch (pmtx->m_ps) { > + case PMUTEX_INITSTAGE_DONE: > + atomic_thread_fence_acq(); > + done = true; > + break; > + case PMUTEX_INITSTAGE_ALLOC: > + if (atomic_cmpset_int(&pmtx->m_ps, > + PMUTEX_INITSTAGE_ALLOC, PMUTEX_INITSTAGE_BUSY)) { > + if (mutex_attr == NULL) > + mutex_attr = &foobar_mutex_attr; > + mutex_init_body(pmtx, mutex_attr); > + atomic_store_rel_int(&pmtx->m_ps, > + PMUTEX_INITSTAGE_DONE); > + done = true; > + } > + break; > + case PMUTEX_INITSTAGE_BUSY: > + _pthread_yield(); > + break; > + default: > + PANIC("corrupted offpage"); > + break; > + } > + } > +} > + > int > __pthread_mutex_init(pthread_mutex_t *mutex, > const pthread_mutexattr_t *mutex_attr) > @@ -285,7 +331,7 @@ __pthread_mutex_init(pthread_mutex_t *mutex, > if (pmtx == NULL) > return (EFAULT); > *mutex = THR_PSHARED_PTR; > - mutex_init_body(pmtx, *mutex_attr); > + shared_mutex_init(pmtx, *mutex_attr); > return (0); > } > > @@ -426,6 +472,7 @@ check_and_init_mutex(pthread_mutex_t *mutex, struct > pthread_mutex **m) *m = __thr_pshared_offpage(mutex, 0); > if (*m == NULL) > ret = EINVAL; > + shared_mutex_init(*m, NULL); > } else if (__predict_false(*m <= THR_MUTEX_DESTROYED)) { > if (*m == THR_MUTEX_DESTROYED) { > ret = EINVAL; > @@ -588,6 +635,7 @@ _pthread_mutex_unlock(pthread_mutex_t *mutex) > mp = __thr_pshared_offpage(mutex, 0); > if (mp == NULL) > return (EINVAL); > + shared_mutex_init(mp, NULL); > } else { > mp = *mutex; > } > @@ -815,6 +863,7 @@ _pthread_mutex_getprioceiling(pthread_mutex_t *mutex, > m = __thr_pshared_offpage(mutex, 0); > if (m == NULL) > return (EINVAL); > + shared_mutex_init(m, NULL); > } else { > m = *mutex; > if (m <= THR_MUTEX_DESTROYED) > @@ -839,6 +888,7 @@ _pthread_mutex_setprioceiling(pthread_mutex_t *mutex, > m = __thr_pshared_offpage(mutex, 0); > if (m == NULL) > return (EINVAL); > + shared_mutex_init(m, NULL); > } else { > m = *mutex; > if (m <= THR_MUTEX_DESTROYED) > @@ -942,12 +992,13 @@ __pthread_mutex_setyieldloops_np(pthread_mutex_t > *mutex, int count) int > _pthread_mutex_isowned_np(pthread_mutex_t *mutex) > { > - struct pthread_mutex *m; > + struct pthread_mutex *m; > > if (*mutex == THR_PSHARED_PTR) { > m = __thr_pshared_offpage(mutex, 0); > if (m == NULL) > return (0); > + shared_mutex_init(m, NULL); > } else { > m = *mutex; > if (m <= THR_MUTEX_DESTROYED) > diff --git a/lib/libthr/thread/thr_private.h > b/lib/libthr/thread/thr_private.h index 7ee1fbf..0db2dad 100644 > --- a/lib/libthr/thread/thr_private.h > +++ b/lib/libthr/thread/thr_private.h > @@ -146,6 +146,13 @@ TAILQ_HEAD(mutex_queue, pthread_mutex); > > #define MAX_DEFER_WAITERS 50 > > +/* > + * Values for pthread_mutex m_ps indicator. > + */ > +#define PMUTEX_INITSTAGE_ALLOC 0 > +#define PMUTEX_INITSTAGE_BUSY 1 > +#define PMUTEX_INITSTAGE_DONE 2 > + > struct pthread_mutex { > /* > * Lock for accesses to this structure. > @@ -156,6 +163,7 @@ struct pthread_mutex { > int m_count; > int m_spinloops; > int m_yieldloops; > + int m_ps; /* pshared init stage */ > /* > * Link for all mutexes a thread currently owns, of the same > * prio type. After applying this patch: No coredumps produced after three subsequent KDE session restarts. Thank you! From owner-freebsd-current@freebsd.org Tue Mar 22 10:52:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEFEDAD94E0 for ; Tue, 22 Mar 2016 10:52:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 8A3A563C for ; Tue, 22 Mar 2016 10:52:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2MApx8S044951 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 12:51:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2MApx8S044951 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2MApxdJ044950; Tue, 22 Mar 2016 12:51:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Mar 2016 12:51:59 +0200 From: Konstantin Belousov To: "Oleg V. Nauman" Cc: freebsd-current@freebsd.org Subject: Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35) Message-ID: <20160322105159.GS1741@kib.kiev.ua> References: <5093647.qxI0C33PyG@asus.theweb.org.ua> <1850738.9W54HNFmp1@asus.theweb.org.ua> <20160322075323.GR1741@kib.kiev.ua> <24312565.qdfGvr8xZt@asus.theweb.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24312565.qdfGvr8xZt@asus.theweb.org.ua> User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 10:52:06 -0000 On Tue, Mar 22, 2016 at 12:01:38PM +0200, Oleg V. Nauman wrote: > After applying this patch: > > No coredumps produced after three subsequent KDE session restarts. Thank you for patience and testing. The issue is apparent bug in KDE which can do several calls to pthread_mutex_init() for process-shared mutex, from different processes. This situation is declared as undefined by Posix and really is quite severe bug for unchecked implementations. I committed the workaround as r297185. From owner-freebsd-current@freebsd.org Tue Mar 22 13:23:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B470AD9B58 for ; Tue, 22 Mar 2016 13:23:43 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 EFDB9EB8; Tue, 22 Mar 2016 13:23:42 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3qTtgT41q0zZvS; Tue, 22 Mar 2016 14:23:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mail; t= 1458653011; x=1460467412; bh=8veZr3Ni7i53962RCbF/VDwuu1qn2UnWgmh gfw7LGKM=; b=fv9n2ZLfiuYg1zQoodLUrtMgzaWJaxjIFsP6zjCylLRGRsdiflA xep0fYuVPk9BPPJAGtVC10O3ydZ6Fo5p0IhfsBMj+BgF1zfn7As8lvz7glw2kHw7 dzISX0/sG/xtowjQ7Sx39fzhzR53LdOPKpL7ErwTgNrSJZcvfnuKQkJw= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id eFrt6_Dl12QO; Tue, 22 Mar 2016 14:23:31 +0100 (CET) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 22 Mar 2016 14:23:31 +0100 (CET) Subject: Re: sdhci_pci.ko fails to load To: Ian Lepore , Jilles Tjoelker References: <56EF12C1.1020202@madpilot.net> <56EF143F.9030308@madpilot.net> <56EF1744.4030607@madpilot.net> <1458511534.68920.84.camel@freebsd.org> <20160320224034.GB78464@stack.nl> <1458521695.68920.86.camel@freebsd.org> Cc: cem@FreeBSD.org, freebsd-current From: Guido Falsi Message-ID: <56F14753.4010408@madpilot.net> Date: Tue, 22 Mar 2016 14:23:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458521695.68920.86.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 13:23:43 -0000 On 03/21/16 01:54, Ian Lepore wrote: > On Sun, 2016-03-20 at 23:40 +0100, Jilles Tjoelker wrote: >> On Sun, Mar 20, 2016 at 04:05:34PM -0600, Ian Lepore wrote: >>> On Sun, 2016-03-20 at 22:33 +0100, Guido Falsi wrote: >>>> the full error in dmesg is the same as stated before: >> >>>> link_elf_obj: symbol mmc_driver undefined >>>> linker_load_file: Unsupported file type >> >>>> Meybe the symbol is optimized out by the compiler in the module? >> >>> I suspect this is caused by my r292180 back in December. I'm >>> trying to >>> figure out if that's the case and if so, how to fix it. >> >> I think this is caused by the missing MODULE_DEPEND. The kernel >> linker >> only looks for symbols in the ELF objects containing the module >> itself >> and its declared dependencies. >> >> If mmc is compiled into the main kernel image, this is always >> satisfied. >> > > Thanks for the clue about the linker, it would have taken me forever to > figure that out by flailing around like I was doing. > > Hopefully this is all fixed now with r297127, but I was only able to > test it on arm systems (I have no x86 with sdhci). > Sorry for the delay, I updated the machine to r297146 and can confirm the problem is gone. Thanks you a lot for the quick fix! -- Guido Falsi From owner-freebsd-current@freebsd.org Tue Mar 22 15:43:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BCE5AD8E2C for ; Tue, 22 Mar 2016 15:43:10 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3E27AF; Tue, 22 Mar 2016 15:43:09 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 385711792D; Tue, 22 Mar 2016 08:43:09 -0700 (PDT) Date: Tue, 22 Mar 2016 08:43:09 -0700 From: hiren panchasara To: John Wehle Cc: freebsd-current@freebsd.org, melifaro@FreeBSD.org Subject: Re: trivial freebsd 9 (and later) route patch reminder / question Message-ID: <20160322154309.GL74217@strugglingcoder.info> References: <201603182306.u2IN6U5t024373@jwlab.FEITH.COM> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FnOKg9Ah4tDwTfQS" Content-Disposition: inline In-Reply-To: <201603182306.u2IN6U5t024373@jwlab.FEITH.COM> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 15:43:10 -0000 --FnOKg9Ah4tDwTfQS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable + Alexander V. Chernikov (melifaro@) On 03/18/16 at 07:06P, John Wehle wrote: > Noticed in 2013 a problem with FreeBSD 9 due to a MFC which > broke my VPN. There's a bug report with a trivial patch at: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D179829 >=20 > The problem is still present in FreeBSD 10 and the code in > HEAD also looks unchanged (meaning the problem likely still > exists). >=20 > It would nice to fix the problem before FreeBSD 11 is branched. >=20 > Does the current bug report suffice, or is it buried since it > was originally discovered on FreeBSD 9? >=20 > Basically I wasn't sure if I needed to open a new report against > HEAD. >=20 > -- John > ------------------------------------------------------------------------- > | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | > | John Wehle | Fax: 1-215-540-5495 | | > ------------------------------------------------------------------------- Cheers, Hiren --FnOKg9Ah4tDwTfQS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJW8WgJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l7X4H/RoNtKVBjasBXV3cKXNS0WDO uZ1Hn1hz95xB+wFU9aYhW5nwUmpRRlHRJwoeLeu1h+rxGFThgolUX+vq+y2fPQcs AK06Tu/3VrXARoRUwApxNyreiZX6Iw6z/FCh1m2xC9wbh9Bjekwp2HoKR05y6TDy /te3ynjjnN6VQMuZVN9ul2ZGzXVJD39P4grEB/g7vFPtgMPw0/4JlPcSUs8n1wpb wIIgWhylGO1pckenwXh21G2w62EZo30znA7rXhXwKW/LRDgXS6VkTDSRRibpxMsF s0gQT1s7e1XR6tXJGQmMKpKMHWR/UAmSSl+V6etD+X0dmjnMphZEKayNSoDEqSI= =YK0C -----END PGP SIGNATURE----- --FnOKg9Ah4tDwTfQS-- From owner-freebsd-current@freebsd.org Tue Mar 22 16:26:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C009AD9D37 for ; Tue, 22 Mar 2016 16:26:41 +0000 (UTC) (envelope-from hps@selasky.org) 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 69E8EB7E for ; Tue, 22 Mar 2016 16:26:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 267CF1FE023; Tue, 22 Mar 2016 17:26:34 +0100 (CET) Subject: Re: sysctl: OID number(131) is already in use for 'me' To: Arseny Nasokin , freebsd-current References: From: Hans Petter Selasky Message-ID: <56F172E2.8040302@selasky.org> Date: Tue, 22 Mar 2016 17:29:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 22 Mar 2016 16:26:41 -0000 Hi, Were all kernel modules in /boot/modules rebuilt? --HPS On 03/21/16 23:32, Arseny Nasokin wrote: > I've recently upgrade my machine to FreeBSD-Current revision 297059 and got > strange result on first boot lines: > > sysctl: OID number(131) is already in use for 'me' > > I build system in two stages: first with 'native'/crosstools clang, second > in bhyve. This message appears in both times. > > I've tried to boot latest FreeBSD-10 and I've seen no such message. > > My kernel config is here: > https://bitbucket.org/eirnym/bsd/src/7f7e4a234b5bba4b346fd76e5f8b35d58d2bec29/eroese/EirZen.amd64 > > -- Eir Nym From owner-freebsd-current@freebsd.org Wed Mar 23 10:55:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 433D1ADA376 for ; Wed, 23 Mar 2016 10:55:33 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE1651EDB for ; Wed, 23 Mar 2016 10:55:32 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: by mail-lb0-x22b.google.com with SMTP id k12so7273195lbb.1 for ; Wed, 23 Mar 2016 03:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ULlHeMiG4MWqNzk7o60a2RUY4okZFIcZRDIpCZgvCvE=; b=BQsNoMYlMBF8wJ9U6q6qnqW97CKU96bU56zHFhzdWJHvOCksNBIwJOjw45/SY5J1A4 zyWFIlIeJhQfICEUOgQJ9jnWgOS9HX8au1Ioti0lK5kuQFbYRiPgqXE6LQOHG6Gr6sdt IL3SAQm6YpnzDr+0LTnlnILK3TJBjJJesa2i8mKs3dN7VJLGXbFButXZRj8JltdMkXwx KYswYC0fUJ5O9NIHFQ1r3lwJXrAxiq7qxwI+SiHqFh7vVude/67KNuHLam8rKNN1YbII 7Dgds4rzw64NnwoW0ms/isoLyxEeQwG5OVDE4ZvjOdksXBV5TegqWpI+65b5FI2Nahif fkBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ULlHeMiG4MWqNzk7o60a2RUY4okZFIcZRDIpCZgvCvE=; b=d0kDtsKukuT5LYYa6PdWr9SCWvxdzs3kGAU8n7EAdA2Ig/UiUVh8DfKfyINSiBu9Xl WPKa1fR1WBZKIR0IIODEqvcIfdAzW+vGipM3hgcgIggVojB3hY79K8RYzQnTm3UgPZwY ww1wB7i+JtZwohdqjYTHzgLfTncSb9UHtFi+N5WvvI/79QSviTxAj0ayfe07xkrsT75W 6XMOP3mQtHA7dfzhTM4JjIFYQD6iyLhzJkltN86oFaBPPBRsWjMH83XlPxutQ6ebWmXe jlzYP8QGgdx/FnBCvRVa2XIPRp0jpDcLJB/7nOXHnJWZawdcsFjb20AZsB0ETwFDp3Mt XRdw== X-Gm-Message-State: AD7BkJKEpeCA+IElspNUGRXnyM2TLhOhQ1ATDhfWs6n6jn3LKmlaVRF10R9yRJlQkHObiA== X-Received: by 10.112.210.200 with SMTP id mw8mr887292lbc.16.1458730531066; Wed, 23 Mar 2016 03:55:31 -0700 (PDT) Received: from [172.16.24.200] (eroese.org. [213.251.194.80]) by smtp.gmail.com with ESMTPSA id d131sm330266lfg.27.2016.03.23.03.55.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Mar 2016 03:55:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: sysctl: OID number(131) is already in use for 'me' From: Eir Nym In-Reply-To: <56F172E2.8040302@selasky.org> Date: Wed, 23 Mar 2016 13:55:29 +0300 Cc: FreeBSD Mail Lists Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F172E2.8040302@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 23 Mar 2016 10:55:33 -0000 Hi, Is there method to check this with compiled binaries? I never update world on live system since it is -CURRENT branch and I = keep possible incompatibility in mind. You can also look into my build script I=E2=80=99ve published in same = repository. =E2=80=94 Arseny Nasokin =E2=9C=AA > On 22 Mar 2016, at 19:29, Hans Petter Selasky wrote: >=20 > Hi, >=20 > Were all kernel modules in /boot/modules rebuilt? >=20 > --HPS >=20 > On 03/21/16 23:32, Arseny Nasokin wrote: >> I've recently upgrade my machine to FreeBSD-Current revision 297059 = and got >> strange result on first boot lines: >>=20 >> sysctl: OID number(131) is already in use for 'me' >>=20 >> I build system in two stages: first with 'native'/crosstools clang, = second >> in bhyve. This message appears in both times. >>=20 >> I've tried to boot latest FreeBSD-10 and I've seen no such message. >>=20 >> My kernel config is here: >> = https://bitbucket.org/eirnym/bsd/src/7f7e4a234b5bba4b346fd76e5f8b35d58d2be= c29/eroese/EirZen.amd64 >>=20 >> -- Eir Nym >=20 >=20 From owner-freebsd-current@freebsd.org Wed Mar 23 18:11:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B39AADB015 for ; Wed, 23 Mar 2016 18:11:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1653B173A for ; Wed, 23 Mar 2016 18:11:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 15596ADB014; Wed, 23 Mar 2016 18:11:39 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14F94ADB013 for ; Wed, 23 Mar 2016 18:11:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6DB41738 for ; Wed, 23 Mar 2016 18:11:38 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u2NIBV50011642 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Mar 2016 11:11:31 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u2NIBV96011641; Wed, 23 Mar 2016 11:11:31 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Mar 2016 11:11:31 -0700 From: Gleb Smirnoff To: Vitalij Satanivskij Cc: current@freebsd.org Subject: Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833) Message-ID: <20160323181131.GN2616@FreeBSD.org> References: <20160304124053.GA25071@hell.ukr.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20160304124053.GA25071@hell.ukr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 23 Mar 2016 18:11:39 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Vitalij, can you please try with this patch? On Fri, Mar 04, 2016 at 02:40:54PM +0200, Vitalij Satanivskij wrote: V> Hello. V> V> I get kernel panic on high loaded server with messages V> V> savecore: reboot after panic: V> vn_sendfile: mlen 326 space -20 hdrlen 326 V> V> V> # kgdb kernel.debug /var/crash/vmcore.0 V> V> Unread portion of the kernel message buffer: V> panic: vn_sendfile: mlen 326 space -20 hdrlen 326 V> cpuid = 5 V> KDB: stack backtrace: V> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe20206314f0 V> vpanic() at vpanic+0x182/frame 0xfffffe2020631570 V> kassert_panic() at kassert_panic+0x126/frame 0xfffffe20206315e0 V> vn_sendfile() at vn_sendfile+0x14ca/frame 0xfffffe2020631900 V> sys_sendfile() at sys_sendfile+0x11e/frame 0xfffffe20206319a0 V> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe2020631ab0 V> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe2020631ab0 V> --- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x801ef062a, rsp = 0x7fffffffd8d8, rbp = 0x7fffffffe1d0 --- V> KDB: enter: panic V> V> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/zfs.ko.debug...done. V> done. V> Loaded symbols for /boot/kernel/zfs.ko V> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. V> done. V> Loaded symbols for /boot/kernel/opensolaris.ko V> Reading symbols from /boot/kernel/carp.ko...Reading symbols from /usr/lib/debug//boot/kernel/carp.ko.debug...done. V> done. V> Loaded symbols for /boot/kernel/carp.ko V> Reading symbols from /boot/kernel/ums.ko...Reading symbols from /usr/lib/debug//boot/kernel/ums.ko.debug...done. V> done. V> Loaded symbols for /boot/kernel/ums.ko V> Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done. V> done. V> Loaded symbols for /boot/kernel/tmpfs.ko V> #0 doadump (textdump=0) at pcpu.h:221 V> 221 __asm("movq %%gs:%1,%0" : "=r" (td) V> (kgdb) bt V> #0 doadump (textdump=0) at pcpu.h:221 V> #1 0xffffffff80384a0b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 V> #2 0xffffffff803847fe in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 V> #3 0xffffffff80384594 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 V> #4 0xffffffff8038702b in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:251 V> #5 0xffffffff80a656e3 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 V> #6 0xffffffff80ea1298 in trap (frame=0xfffffe2020631420) at /usr/src/sys/amd64/amd64/trap.c:556 V> #7 0xffffffff80e81a77 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:234 V> #8 0xffffffff80a64dcb in kdb_enter (why=0xffffffff813b6c2f "panic", msg=0x80
) at cpufunc.h:63 V> #9 0xffffffff80a27b5f in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:750 V> #10 0xffffffff80a279b6 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:647 V> #11 0xffffffff80a25efa in vn_sendfile (fp=, sockfd=1619, hdr_uio=, trl_uio=0x0, offset=0, V> nbytes=, sent=, flags=, kflags=, td=0xa8) V> at /usr/src/sys/kern/kern_sendfile.c:833 V> #12 0xffffffff80a2641e in sys_sendfile (td=0xfffff80253593000, uap=0xfffffe2020631a40) at file.h:382 V> #13 0xffffffff80ea214b in amd64_syscall (td=0xfffff80253593000, traced=0) at subr_syscall.c:135 V> #14 0xffffffff80e81d5b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:394 V> #15 0x0000000801ef062a in ?? () V> Previous frame inner to this frame (corrupt stack?) V> Current language: auto; currently minimal V> (kgdb) list *0xffffffff80a25efa V> 0xffffffff80a25efa is in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833). V> 828 free(sfio, M_TEMP); V> 829 goto done; V> 830 } V> 831 V> 832 /* Add the buffer chain to the socket buffer. */ V> 833 KASSERT(m_length(m, NULL) == space + hdrlen, V> 834 ("%s: mlen %u space %d hdrlen %d", V> 835 __func__, m_length(m, NULL), space, hdrlen)); V> 836 V> 837 CURVNET_SET(so->so_vnet); V> V> V> System have 128Gb memory V> zfs as FS V> DB's worked on it and web pages served by this server. V> V> core saved. V> panic periodicaly repeted (few hours -- up to few days) V> V> Before this, old current (about two year old CURRENT ) work on this server without crashes. V> V> Can anybody point me to way of more complex problem diagnostic or any other useful things V> V> Thank you. V> V> V> V> V> V> _______________________________________________ V> freebsd-current@freebsd.org mailing list V> https://lists.freebsd.org/mailman/listinfo/freebsd-current V> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Totus tuus, Glebius. --YZ5djTAD1cGYuMQK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sendfile.diff" Index: kern_sendfile.c =================================================================== --- kern_sendfile.c (revision 297210) +++ kern_sendfile.c (working copy) @@ -673,6 +673,8 @@ retry_space: * hdrlen is set to 0 after the first loop. */ space -= hdrlen; + if (space < 0) + space = 0; if (vp != NULL) { error = vn_lock(vp, LK_SHARED); --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@freebsd.org Wed Mar 23 19:00:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F97AADB792 for ; Wed, 23 Mar 2016 19:00:41 +0000 (UTC) (envelope-from hps@selasky.org) 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 6CA3E1E25 for ; Wed, 23 Mar 2016 19:00:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (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 7B3961FE023; Wed, 23 Mar 2016 20:00:38 +0100 (CET) Subject: Re: sysctl: OID number(131) is already in use for 'me' To: Eir Nym References: <56F172E2.8040302@selasky.org> Cc: FreeBSD Mail Lists From: Hans Petter Selasky Message-ID: <56F2E887.30801@selasky.org> Date: Wed, 23 Mar 2016 20:03:35 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 23 Mar 2016 19:00:41 -0000 On 03/23/16 11:55, Eir Nym wrote: > Hi, > > Is there method to check this with compiled binaries? > Hi, You might try: strings /boot/modules/*.ko | grep me But you need to analyze the output. Possibly you could add a kdb_backtrace() call around the printf in question in the kernel. That would give you the answer which module is causing the error. --HPS From owner-freebsd-current@freebsd.org Wed Mar 23 22:27:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC73DADBDE4 for ; Wed, 23 Mar 2016 22:27:37 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from turad.lysandor.de (turad.lysandor.de [136.243.10.60]) (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 B426B151E for ; Wed, 23 Mar 2016 22:27:37 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from localhost (localhost [127.0.0.1]) by turad.lysandor.de (Postfix) with ESMTP id 159E3AAC7C0 for ; Wed, 23 Mar 2016 23:27:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at turad.lysandor.de Received: from turad.lysandor.de ([127.0.0.1]) by localhost (turad.lysandor.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5TrZI-wtW6h for ; Wed, 23 Mar 2016 23:27:28 +0100 (CET) Received: from nachtschatten.purplekraken.com (x5f723e46.dyn.telefonica.de [95.114.62.70]) (Authenticated sender: flo@snakeoilproductions.net) by turad.lysandor.de (Postfix) with ESMTPSA id 88CCCAAC760 for ; Wed, 23 Mar 2016 23:27:28 +0100 (CET) Subject: Re: Panic on r297039 with nvidia-driver-340.93 and KDE5 To: freebsd-current@freebsd.org References: <56EDBD7F.4020108@snakeoilproductions.net> From: Florian Limberger Message-ID: <56F31850.8040801@snakeoilproductions.net> Date: Wed, 23 Mar 2016 23:27:28 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56EDBD7F.4020108@snakeoilproductions.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 23 Mar 2016 22:27:38 -0000 Hi, On 19.03.16 21:58, Florian Limberger wrote: > I omitted the later frame adresses, I typed this off a photo, I missed > to create a crash dump, but I can provide one if it is needed: > > panic: ufs_dirbad: /usr/home: bad dir ino 6742590 at offset 512: I resolved my issue, the fs was in an inconsistent state and fsck missed it because I used the journal on recovery. After another fsck without the journal the panic went away. Regards florian From owner-freebsd-current@freebsd.org Wed Mar 23 23:59:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B435CADB13C for ; Wed, 23 Mar 2016 23:59:27 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECD015CA for ; Wed, 23 Mar 2016 23:59:27 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9A702ADB13B; Wed, 23 Mar 2016 23:59:27 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A0EFADB13A for ; Wed, 23 Mar 2016 23:59:27 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7871A15C9 for ; Wed, 23 Mar 2016 23:59:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u2NNxPsW013121 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Mar 2016 16:59:25 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u2NNxPsa013120; Wed, 23 Mar 2016 16:59:25 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Mar 2016 16:59:25 -0700 From: Gleb Smirnoff To: Vitalij Satanivskij Cc: current@freebsd.org Subject: Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833) Message-ID: <20160323235925.GT2616@FreeBSD.org> References: <20160304124053.GA25071@hell.ukr.net> <20160323181131.GN2616@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <20160323181131.GN2616@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 23 Mar 2016 23:59:27 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Vitalij, although the first patch should fixup the panic, can you please instead run this one. And if it is possible, can you please monitor this sysctl: sysctl kern.ipc.sf_long_headers -- Totus tuus, Glebius. --O5XBE6gyVG5Rl6Rj Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sendfile.diff" Index: sys/kern/kern_descrip.c =================================================================== --- sys/kern/kern_descrip.c (revision 297217) +++ sys/kern/kern_descrip.c (working copy) @@ -3958,7 +3958,7 @@ badfo_chown(struct file *fp, uid_t uid, gid_t gid, static int badfo_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio, struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int flags, - int kflags, struct thread *td) + struct thread *td) { return (EBADF); @@ -4044,7 +4044,7 @@ invfo_chown(struct file *fp, uid_t uid, gid_t gid, int invfo_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio, struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int flags, - int kflags, struct thread *td) + struct thread *td) { return (EINVAL); Index: sys/kern/kern_sendfile.c =================================================================== --- sys/kern/kern_sendfile.c (revision 297217) +++ sys/kern/kern_sendfile.c (working copy) @@ -95,6 +95,7 @@ struct sendfile_sync { }; counter_u64_t sfstat[sizeof(struct sfstat) / sizeof(uint64_t)]; +static counter_u64_t sf_long_headers; /* QQQGL */ static void sfstat_init(const void *unused) @@ -102,6 +103,7 @@ sfstat_init(const void *unused) COUNTER_ARRAY_ALLOC(sfstat, sizeof(struct sfstat) / sizeof(uint64_t), M_WAITOK); + sf_long_headers = counter_u64_alloc(M_WAITOK); /* QQQGL */ } SYSINIT(sfstat, SI_SUB_MBUF, SI_ORDER_FIRST, sfstat_init, NULL); @@ -117,6 +119,8 @@ sfstat_sysctl(SYSCTL_HANDLER_ARGS) } SYSCTL_PROC(_kern_ipc, OID_AUTO, sfstat, CTLTYPE_OPAQUE | CTLFLAG_RW, NULL, 0, sfstat_sysctl, "I", "sendfile statistics"); +SYSCTL_COUNTER_U64(_kern_ipc, OID_AUTO, sf_long_headers, CTLFLAG_RW, + &sf_long_headers, "times headers did not fit into socket buffer"); /* * Detach mapped page and release resources back to the system. Called @@ -516,7 +520,7 @@ sendfile_getsock(struct thread *td, int s, struct int vn_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio, struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int flags, - int kflags, struct thread *td) + struct thread *td) { struct file *sock_fp; struct vnode *vp; @@ -534,7 +538,7 @@ vn_sendfile(struct file *fp, int sockfd, struct ui so = NULL; m = mh = NULL; sfs = NULL; - sbytes = 0; + hdrlen = sbytes = 0; softerr = 0; error = sendfile_getobj(td, fp, &obj, &vp, &shmfd, &obj_size, &bsize); @@ -560,26 +564,6 @@ vn_sendfile(struct file *fp, int sockfd, struct ui cv_init(&sfs->cv, "sendfile"); } - /* If headers are specified copy them into mbufs. */ - if (hdr_uio != NULL && hdr_uio->uio_resid > 0) { - hdr_uio->uio_td = td; - hdr_uio->uio_rw = UIO_WRITE; - /* - * In FBSD < 5.0 the nbytes to send also included - * the header. If compat is specified subtract the - * header size from nbytes. - */ - if (kflags & SFK_COMPAT) { - if (nbytes > hdr_uio->uio_resid) - nbytes -= hdr_uio->uio_resid; - else - nbytes = 0; - } - mh = m_uiotombuf(hdr_uio, M_WAITOK, 0, 0, 0); - hdrlen = m_length(mh, &mhtail); - } else - hdrlen = 0; - rem = nbytes ? omin(nbytes, obj_size - offset) : obj_size - offset; /* @@ -668,11 +652,23 @@ retry_space: SOCKBUF_UNLOCK(&so->so_snd); /* - * Reduce space in the socket buffer by the size of - * the header mbuf chain. - * hdrlen is set to 0 after the first loop. + * At the beginning of the first loop check if any headers + * are specified and copy them into mbufs. Reduce space in + * the socket buffer by the size of the header mbuf chain. + * Clear hdr_uio here and hdrlen at the end of the first loop. */ - space -= hdrlen; + if (hdr_uio != NULL) { + hdr_uio->uio_td = td; + hdr_uio->uio_rw = UIO_WRITE; + /* QQQGL remove counter */ + if (space < hdr_uio->uio_resid) + counter_u64_add(sf_long_headers, 1); + hdr_uio->uio_resid = min(hdr_uio->uio_resid, space); + mh = m_uiotombuf(hdr_uio, M_WAITOK, 0, 0, 0); + hdrlen = m_length(mh, &mhtail); + space -= hdrlen; + hdr_uio = NULL; + } if (vp != NULL) { error = vn_lock(vp, LK_SHARED); @@ -944,6 +940,17 @@ sendfile(struct thread *td, struct sendfile_args * &hdr_uio); if (error != 0) goto out; + /* + * In FBSD < 5.0 the nbytes to send also included + * the header. If compat is specified subtract the + * header size from nbytes. + */ + if (compat) { + if (uap->nbytes > hdr_uio->uio_resid) + uap->nbytes -= hdr_uio->uio_resid; + else + uap->nbytes = 0; + } } if (hdtr.trailers != NULL) { error = copyinuio(hdtr.trailers, hdtr.trl_cnt, @@ -965,7 +972,7 @@ sendfile(struct thread *td, struct sendfile_args * } error = fo_sendfile(fp, uap->s, hdr_uio, trl_uio, uap->offset, - uap->nbytes, &sbytes, uap->flags, compat ? SFK_COMPAT : 0, td); + uap->nbytes, &sbytes, uap->flags, td); fdrop(fp, td); if (uap->sbytes != NULL) Index: sys/sys/file.h =================================================================== --- sys/sys/file.h (revision 297217) +++ sys/sys/file.h (working copy) @@ -112,7 +112,7 @@ typedef int fo_chown_t(struct file *fp, uid_t uid, struct ucred *active_cred, struct thread *td); typedef int fo_sendfile_t(struct file *fp, int sockfd, struct uio *hdr_uio, struct uio *trl_uio, off_t offset, size_t nbytes, - off_t *sent, int flags, int kflags, struct thread *td); + off_t *sent, int flags, struct thread *td); typedef int fo_seek_t(struct file *fp, off_t offset, int whence, struct thread *td); typedef int fo_fill_kinfo_t(struct file *fp, struct kinfo_file *kif, @@ -376,11 +376,11 @@ fo_chown(struct file *fp, uid_t uid, gid_t gid, st static __inline int fo_sendfile(struct file *fp, int sockfd, struct uio *hdr_uio, struct uio *trl_uio, off_t offset, size_t nbytes, off_t *sent, int flags, - int kflags, struct thread *td) + struct thread *td) { return ((*fp->f_ops->fo_sendfile)(fp, sockfd, hdr_uio, trl_uio, offset, - nbytes, sent, flags, kflags, td)); + nbytes, sent, flags, td)); } static __inline int Index: sys/sys/socket.h =================================================================== --- sys/sys/socket.h (revision 297217) +++ sys/sys/socket.h (working copy) @@ -594,7 +594,6 @@ struct sf_hdtr { #define SF_FLAGS(rh, flags) (((rh) << 16) | (flags)) #ifdef _KERNEL -#define SFK_COMPAT 0x00000001 #define SF_READAHEAD(flags) ((flags) >> 16) #endif /* _KERNEL */ --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-current@freebsd.org Thu Mar 24 03:10:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F513ADBC8A for ; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 66E1C17D6 for ; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 62006ADBC85; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 617DDADBC83; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9FD17D3; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 4924B123A; Thu, 24 Mar 2016 03:10:00 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D94551AFF5; Thu, 24 Mar 2016 03:09:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id OOCUC_5crhxK; Thu, 24 Mar 2016 03:09:57 +0000 (UTC) Subject: Re: leaky M_RTABLE r295632 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 3A5EC1AFF0 To: current@FreeBSD.org, net@FreeBSD.org References: <56CB8538.1050003@FreeBSD.org> <56E5D122.5080501@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <56F35A84.1070605@FreeBSD.org> Date: Wed, 23 Mar 2016 20:09:56 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56E5D122.5080501@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MhXpDSpXpexxtomTWTnjS8SW1knkV6Hob" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 03:10:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MhXpDSpXpexxtomTWTnjS8SW1knkV6Hob Content-Type: multipart/mixed; boundary="dS7GpSTrdDhFvoc13sHsKAxStMM3fDEUw" From: Bryan Drewery To: current@FreeBSD.org, net@FreeBSD.org Message-ID: <56F35A84.1070605@FreeBSD.org> Subject: Re: leaky M_RTABLE r295632 References: <56CB8538.1050003@FreeBSD.org> <56E5D122.5080501@FreeBSD.org> In-Reply-To: <56E5D122.5080501@FreeBSD.org> --dS7GpSTrdDhFvoc13sHsKAxStMM3fDEUw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/13/16 1:44 PM, Bryan Drewery wrote: > On 2/22/2016 2:01 PM, Bryan Drewery wrote: >> Running CURRENT r295632. >> >> # vmstat -m|grep routetbl >> routetbl 103952 51995K - 155861 512,1024 >> >> This seems quite large for my dev build system. >> >=20 > Now on r296480: >=20 > # vmstat -m|grep routetbl > routetbl 8928 4484K - 13324 512,1024 >=20 > Still seems too high. >=20 Fixed in r297222, from 11/2014 r274118. Happened when reloading NFS exports, which happens often when building with Poudriere where the mounts used are exported over NFS. --=20 Regards, Bryan Drewery --dS7GpSTrdDhFvoc13sHsKAxStMM3fDEUw-- --MhXpDSpXpexxtomTWTnjS8SW1knkV6Hob Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW81qEAAoJEDXXcbtuRpfPAs8H/ja5OzSFLSzpL8cr69mMuCgn aA5B2MkHsV1OrNAIlGglTZtJ21CtfO49Vx45H9Is/16t4fXBnkldyx46Veo8lASX zD2gCS7IwyNd+DOOiLqkxc4xjqURLl6Zt8HKHnkmnklZ/0vZHniL6Hh6tiwS3psB a9gNZE5cVBIsJYiAMKq4KYs7ix5t1ZaPcIqQZCuwObqE3a2blNkKT34cOK/fFDG0 SOPBfjgCI1r4JvjS0ZH53/o9B0Og5Z1ivjDurgBM7BTocI0nRk63lZEl3IWOL3qu hM7vJNHy4+QSM58AFiJ4rLfpi9Dpct2NuDPab6uEj0oG0UAjtevpWoXHIauhdiU= =3pWF -----END PGP SIGNATURE----- --MhXpDSpXpexxtomTWTnjS8SW1knkV6Hob-- From owner-freebsd-current@freebsd.org Thu Mar 24 09:13:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95440ADAFE6 for ; Thu, 24 Mar 2016 09:13:11 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7B21F1C7E for ; Thu, 24 Mar 2016 09:13:11 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 72F42ADAFE4; Thu, 24 Mar 2016 09:13:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72440ADAFE2; Thu, 24 Mar 2016 09:13:11 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F314C1C7B; Thu, 24 Mar 2016 09:13:10 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id q73so27165416lfe.2; Thu, 24 Mar 2016 02:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=+8UgkckhN4nOz8pEDZmO1iOKlvwSY89Ce4BxooT/q5k=; b=w388It2Gw30JPCwC8qeozRQ07skxmM1knCeezpPHAXNKeF5Syo7Tw6aTGTpCmQhSO/ 7aP4nVH2xQK+qxXMj9YTk2QS8wqKJna3cIo74uj0Lw5K6eUvpFdSXZaVp51JqR1o0q2B sNeXfnaXZpCOWKpmYX/mikdLOWb65Hk/tFwFU7j5aXReY4qTYYBpbpkCPHOdwUzoCRmw 1oKLeHaayGTqV5xvuGyW0gfFlWCYFcp0imGwlfcUTbJEGNiXEDbp+Enuih96SFZ9KHJ3 S/IktEvNFoutg9k+vd9tqCE4ql+DdovZkXiD8wz8tjLpe2Kyv2oNeCVN2VNCB7fQ7ZgD nfmg== 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; bh=+8UgkckhN4nOz8pEDZmO1iOKlvwSY89Ce4BxooT/q5k=; b=A6vZ7Slhv2Uex2u3RuENeYva4UlpsvP6554vrYI3v7Pt20nNNZ8uOBt3GsPbP8pEd4 PNGXeEVZIWO1lFoVUnKsTjDllJWG+vhmDgqEnf336WpsncO2gjb/DcOjftkAQqAFG1E5 erksQSAJ+8FkNiOhK0Wf5oVc2Tgd68CwUdy6DMQkYlVfmma7ikZnwtwhoPXvvx+RKGHA Bfs9xR9PRI8b1XPsIlew/u0ynAKgB/a1tCDbA4GMY3b/k9xSbYX/VpoODNJbfNWjMdpP 3gN4e4SSgQAlo4cncLeY4hq26t14X9paQShaADl3tykUIX//rgjAdxjiJD2UF5wfi5bq ehjg== X-Gm-Message-State: AD7BkJIl3K9Wp5AlfCb0QwQ8ovcX0E9DKAfsjTJ4l92H5FBUaYDFKYJthA/nOtJO2RkzPUgLnvbNUPZbq8WTSA== MIME-Version: 1.0 X-Received: by 10.25.206.132 with SMTP id e126mr3073259lfg.20.1458810789189; Thu, 24 Mar 2016 02:13:09 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 02:13:09 -0700 (PDT) Date: Thu, 24 Mar 2016 13:43:09 +0430 Message-ID: Subject: FreeBSD MachO File format, your comments on it. From: mokhi To: emulation@freebsd.org Cc: current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 09:13:11 -0000 Hi guys. I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). I am working on adding Mach-O binary format to supported formats for FreeBSD. Not for emulations on first step, but as a native supported format just like a.out [or Elf] (though it can go in both ways too). There are good reasons to have Mach-O format support IMO. It's well/clear designed file format. Can supports multiple Arch by default (It's Fat Format). Because of its Fat Format support, it can even help porting/packaging easier for projects such as Freebsd-arm or others IMO :D. At end (even not among its interesting parts, maybe :D) point, it leads and helps to have OSX emulation support on FreeBSD. BTW, i've coded[1] Mach-O support for FreeBSD with helps of FreeBSD-ppl on IRC about various aspects of this works (from fundamental points of VM-MAP, to SysEntVec for Mach-O format) and with help of Elf and a.out format codes and mach-o references. It's in Alpha state (or before it) IMO, as I'm not sure about some of its parts, but I've tested a mach-o formatted binary with it and it at least loads and maps it segments correctly :D. (it was actually a simple "return 0" C Code, compiled in a OSX, if you know how can I force my FreeBSD clang to produce mach-o files instead of ELF I'd be happy to know it, and I appreciate :D) I'd like to have your helps and comments on it, in hope to make it better and make it ready for review. Thanks and thousands of regards, Mokhi. ============================== [1] https://github.com/m0khi/FreeBSD_MachO From owner-freebsd-current@freebsd.org Thu Mar 24 09:24:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89D6EAD85D6 for ; Thu, 24 Mar 2016 09:24:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 4F02A14EC for ; Thu, 24 Mar 2016 09:24:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aj1VR-001DFD-C7>; Thu, 24 Mar 2016 10:24:41 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1aj1VQ-001uCd-Gp>; Thu, 24 Mar 2016 10:24:41 +0100 Date: Thu, 24 Mar 2016 10:24:34 +0100 From: "O. Hartmann" To: freebsd-current Subject: r297227: buildkernel fail: ERROR: ctfconvert: ipsec_output.o doesn't have type data to convert Message-ID: <20160324102434.7b4212fe@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 09:24:49 -0000 CURRENT fails building a kernel: [...] --- modules-all --- --- all_subdir_acl_posix1e --- ===> acl_posix1e (all) --- all_subdir_acpi --- ===> acpi (all) --- tcp_subr.o --- /usr/src/sys/netinet/tcp_subr.c:1935:20: error: use of undeclared identifier 'tcbinfo' in_pcbnotifyall(&tcbinfo, faddr, EHOSTDOWN, notify); ^ 1 error generated. *** [tcp_subr.o] Error code 1 bmake[2]: stopped in /usr/obj/usr/src/sys/FREYJA --- ipsec_output.o --- ctfconvert -L VERSION ipsec_output.o ERROR: ctfconvert: ipsec_output.o doesn't have type data to convert --- modules-all --- A failure has been detected in another branch of the parallel make From owner-freebsd-current@freebsd.org Thu Mar 24 09:38:05 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3449AD8AF3 for ; Thu, 24 Mar 2016 09:38:05 +0000 (UTC) (envelope-from ap@bnc.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9BB1F7D for ; Thu, 24 Mar 2016 09:38:05 +0000 (UTC) (envelope-from ap@bnc.net) Received: by mailman.ysv.freebsd.org (Postfix) id 899E2AD8AF1; Thu, 24 Mar 2016 09:38:05 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 893DEAD8AF0 for ; Thu, 24 Mar 2016 09:38:05 +0000 (UTC) (envelope-from ap@bnc.net) Received: from mailomat.net (mailomat.net [81.20.89.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailomat.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E35201F7C for ; Thu, 24 Mar 2016 09:38:04 +0000 (UTC) (envelope-from ap@bnc.net) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Cloudmark-Analysis: v=2.1 cv=QMdRGG7L c=1 sm=1 tr=0 a=/nRDZZJyYxTE/j0HnTmKXw==:117 a=/nRDZZJyYxTE/j0HnTmKXw==:17 a=ZDwDCB9QlRsA:10 a=QX6QvZ3GsOUA:10 a=7OsogOcEt9IA:10 a=pGLkceISAAAA:8 a=sWie0twZxNM9jsNxa5wA:9 a=QEXdDO2ut3YA:10 a=dwwisWO2WLCgvboBJakA:9 a=ZVk8-NSrHBgA:10 Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 6.1.8) with ESMTPSA id 76035086 for current@freebsd.org; Thu, 24 Mar 2016 10:37:57 +0100 X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] Received: from [192.168.200.188] (account ap@bnc.net HELO corwin.cable-net.bnc.net) by bnc.net (CommuniGate Pro SMTP 6.1.8) with ESMTPSA id 7408586 for current@freebsd.org; Thu, 24 Mar 2016 10:37:57 +0100 From: Achim Patzner Content-Type: multipart/signed; boundary="Apple-Mail=_69F79742-783D-4138-A4B0-8CBF2391CE2A"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <40D5D502-FCA9-4405-A18B-FAB2E4478F02@bnc.net> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD MachO File format, your comments on it. Date: Thu, 24 Mar 2016 10:37:56 +0100 References: To: current@freebsd.org In-Reply-To: X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 09:38:05 -0000 --Apple-Mail=_69F79742-783D-4138-A4B0-8CBF2391CE2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 24.03.2016 um 10:13 schrieb mokhi : >=20 > Hi guys. > I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). >=20 > I am working on adding Mach-O binary format to supported formats for = FreeBSD. Would that project end in having an intelligent loader that will only = map the relevant architecture to memory (i. e. I=E2=80=99ll have = extremely fat executables supporting any known architecture in the = universe on /usr/local or even for all files that can be shared between = machines) and keep the load on memory and network as low as possible? Cool. I=E2=80=99ll buy immediately. Now if someone would add completely = hassle-free automatic cross-compilation to building I feel like = Christmas came early. (Just imagine an =E2=80=9Cone stick fits them all=E2=80=9D-installer=E2=80= =A6) Achim --Apple-Mail=_69F79742-783D-4138-A4B0-8CBF2391CE2A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCCBWUw ggNNoAMCAQICAxADCTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNDEyMjkxNDIyNTRaFw0x NjEyMjgxNDIyNTRaMDMxFjAUBgNVBAMTDUFjaGltIFBhdHpuZXIxGTAXBgkqhkiG9w0BCQEWCmFw QGJuYy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCemZ2gCwrtE8FYdD42ApLp AyRBcfTJHRaU5R/rTbpBTIbDQn4ESOg0697sOlMjiNlzgvuTJeGDSd6DLREb5pJqqNyzW5kTu1yN dzI8442GxyZAYImcXpQNvvA5OxH4GRwzcjlIie5TDZll1pA+OQwDfPWeosfUugHaDU6KuX6QhrJx JYdweO7ZOb9jL2iJGco3QCQKPoqbLt+NmIyV48DsB12H7oW7NI9E5CfiRQqMioVVUvkRWL2w+1MQ +ymaXl0KOqRZOzhKYJpoRmLxO/hKgBTn2MsEqtqMp5gemM3hRKF14MSo85nNqMv25AYJapkENazR hUmISG+1y6/goSJNAgMBAAGjggE6MIIBNjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdU byBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93 d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUF BwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6 Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMBUGA1UdEQQOMAyBCmFwQGJuYy5uZXQwDQYJKoZI hvcNAQENBQADggIBAA8WwhAMglEXZ/flLiaO0wpdPQrMb4Vm296wYTTQEul2XRshzcXdgnlDitAL 1osyWUME+X6sCIiGkf+Ykbfm49VctlGNeZ7BIQ2R7XMCzcE5MjEjX9VjjF7pTG4kgTs+aTgVrOPo kC/Gv1HCRy0g8dGb6O06DcRWy3Y2BYkzPYGsnr2fYGLrK5chMgHKYk+KR48yO1VyeYKo2EkIKblN oLveAf+tFzzJOAN6t/oauEsyFK23KWNqNkWePJaoXLhhNtyYVGqH6CWPJe3DgHI+Nsg1i9IOCHl1 vBqinySXdPYfEJpI6NeyAV1my4bQwrJSKdFbwGZUgACkGM11BQcOxOB1FBCrxHCV1WCgdtZ0sCIC ec/YlUAzSOkIko3CouFN3ilt+P5qQSZj96rNiFXnb3mxFcJ7cZJhxNkelLbzSlqD9LRNdZ6HuigA 5BcjWRNeWPm3Dj/PFeQxRT5dqV1Q2IkS2T6lmNJTv0Z4mjihpFPL62lZna58i7Axm4oTCR4amWNS s1C3V0kozBu0b4FhxqpCJdfNw+XT53gbhAGqbs5YIcvEOSjMuhKsVcXkl8fNR70oHf3k3k5o+hD1 o4xP/cF0PEeLaxinl+rMZWyRayT6h+ODVGoGpU9oiirYgUjNnxoqUprXPAyLcNDk0wDIEXkFBr9f ZcJ8itP95jda2JdPMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxADCTAJBgUrDgMCGgUAoIIBhzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQwOTM3NTdaMCMG CSqGSIb3DQEJBDEWBBQGPD24mWQk5a4Dbcx9GVGNIrCAWjCBkQYJKwYBBAGCNxAEMYGDMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMQAwkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMQAwkwDQYJKoZIhvcN AQEBBQAEggEAQ/7lV4XmPhHWytrlNRznbaOBDm5Xig4ac110YGzRHgjV/IAv6t6cX3cV9nM6yBvY QLzCzUQFFrlmKoSdWJJJTFR6UhSl2r/DJwSvuoDvMOyPQX/luCjJr9YddjfzmKCzv65XFVulPMKZ LhiU6QNRiyIOqErAI8shWakHjjfdji1eQY4i9cBljjfgc8lphpIKPEcZanEAhyy+5IMJWFufq4FA EP+EL+S8g9QS1C49TbiCROrMXv7mfK92d8vqrlskI1pAIKg8Ls0ECrLtMTd9RY56sMIZEb/7WQsx r0oVJmzZ/T7pwMe40KYNWZMHUwc1/tK/qAcaoPIM2zz0S6U5hwAAAAAAAA== --Apple-Mail=_69F79742-783D-4138-A4B0-8CBF2391CE2A-- From owner-freebsd-current@freebsd.org Thu Mar 24 10:51:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36247ADB067 for ; Thu, 24 Mar 2016 10:51:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 225C218BE for ; Thu, 24 Mar 2016 10:51:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 21B48ADB065; Thu, 24 Mar 2016 10:51:31 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1ED98ADB063; Thu, 24 Mar 2016 10:51:31 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF32B18BD; Thu, 24 Mar 2016 10:51:29 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u2OApK1Y016713 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2016 10:51:23 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: FreeBSD MachO File format, your comments on it. From: David Chisnall In-Reply-To: Date: Thu, 24 Mar 2016 10:51:15 +0000 Cc: emulation@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> References: To: mokhi X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 10:51:31 -0000 Hi, I=E2=80=99d slightly question the assertion that Mach-O is a = well-designed format. For example, it has a hard limit of 16 section = types, doesn=E2=80=99t support COMDATs and so on. OS X uses a load of = magic section names to work around these limitations. Note that a Mach-O image activator is relatively easy, but a Mach-O rtld = is far more complex. It might be possible to port dyld from OS X, but = as I recall it depends quite heavily on the Mach kernel interfaces. On fat binaries, note that the support in the file format is pretty = trivial. Far more support is needed in the image activator and rtld to = determine the correct parts and map only them. If you=E2=80=99re = interested in doing this work, then I=E2=80=99d recommend looking at = this proposed specification for fat ELF binaries: https://icculus.org/fatelf/ That said, I=E2=80=99m not totally convinced that fat binaries are = actually a good solution (unless you=E2=80=99re willing to go a step = further than Apple did and merge data sections) - NeXT managed very well = shipping fat bundles without using fat binaries and even had a special = mode in ditto to strip out the foreign architectures when copying a = bundle from a network share to a local filesystem. Persuading clang to emit FreeBSD Mach-O binaries is probably harder than = you think. It=E2=80=99s quite easy to persuade it that Mach is a valid = file format for FreeBSD, but there are a *lot* of places where people = conflate =E2=80=98is Mach=E2=80=99 with =E2=80=98is Darwin=E2=80=99 in = the Clang and LLVM sources. Finding all of these and making sure that = they=E2=80=99re really checking the correct one is difficult. Emulating OS X binaries may be interesting. NetBSD had a Mach / XNU = compat layer for a while. The problem here is that the graphics stack = interfaces on OS X are completely different from any other *NIX system = (as are the kernel interfaces for sound), so the most that they could do = was run command-line and X11 Mac apps - not especially useful. Actually = emulating OS X apps will need far more than that - OS X ships with about = 500MB of frameworks, many of which are used by most applications. The = GNUstep project is undermanned and hasn=E2=80=99t been able to keep up = with the changes to the core Foundation and AppKit frameworks, let alone = the rest. David > On 24 Mar 2016, at 09:13, mokhi wrote: >=20 > Hi guys. > I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). >=20 > I am working on adding Mach-O binary format to supported formats for = FreeBSD. > Not for emulations on first step, but as a native supported format > just like a.out [or Elf] > (though it can go in both ways too). >=20 > There are good reasons to have Mach-O format support IMO. > It's well/clear designed file format. > Can supports multiple Arch by default (It's Fat Format). > Because of its Fat Format support, it can even help porting/packaging = easier for > projects such as Freebsd-arm or others IMO :D. > At end (even not among its interesting parts, maybe :D) point, it > leads and helps to have > OSX emulation support on FreeBSD. >=20 > BTW, i've coded[1] Mach-O support for FreeBSD with helps of > FreeBSD-ppl on IRC about various aspects of this works (from > fundamental points of VM-MAP, to SysEntVec for Mach-O format) and > with help of Elf and a.out format codes and mach-o references. > It's in Alpha state (or before it) IMO, as I'm not sure about some of > its parts, but I've tested a mach-o formatted binary with it and it at > least loads and maps it segments correctly :D. (it was actually a > simple "return 0" C Code, compiled in a OSX, if you know how can I > force my FreeBSD clang to produce mach-o files instead of ELF I'd be > happy to know it, and I appreciate :D) >=20 > I'd like to have your helps and comments on it, in hope to make it = better > and make it ready for review. >=20 > Thanks and thousands of regards, Mokhi. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > [1] https://github.com/m0khi/FreeBSD_MachO > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 24 12:05:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A63F0ADCFC0 for ; Thu, 24 Mar 2016 12:05:41 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 894E716E0 for ; Thu, 24 Mar 2016 12:05:41 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 888E4ADCFBE; Thu, 24 Mar 2016 12:05:41 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88180ADCFBD; Thu, 24 Mar 2016 12:05:41 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA6B16DF; Thu, 24 Mar 2016 12:05:41 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lb0-x234.google.com with SMTP id qe11so28455723lbc.3; Thu, 24 Mar 2016 05:05:41 -0700 (PDT) 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; bh=fcTalCEsxnGm4MY+ZS25r3ASiSBWtexJIif/AtgrLkk=; b=mhopUkYm3wtCUfgsALhU5NS1CmMdIM2ilzhTiVd0pirIOgmdBLmmEjGTNRqPbu5t5U vnUWoDYpcM1OcDyVFzfMaW20KS5Y25MfoaovW+uxusKzQcL58dIXnwrsLNUiUrKWojYl MbuwA1I/ml+Wi+DoP2CNXGQLGqQrQNZwFQaVlb9Yn0NjQO6CuWVQsEG3mz+BvRdsxAJS nmSY6lCzfrlbdHocvbWWIhDvuBGFqmHVJ0QNsdVo+LcZeQB/xFO2xvl7AdnGHyhUHwH1 ILpLRkHTpR5QnsmRmdIrrqjKWnbCj7nBTaNFvCC+5g2rIO1weyn3XkF7/6ZvD36O3eiE UaLg== 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; bh=fcTalCEsxnGm4MY+ZS25r3ASiSBWtexJIif/AtgrLkk=; b=Mf6/vywopaXFtNZ1SjEXOKeoUbRk6dC/+eN7h/y9mrza+u6e2VKoMQPnTyV8N3XOPF pvY4MK6h/ZKc/cXC1K6cQu601BvWDfhaQUUTWy9Qla+zaZn3SUqXxNuRnPbiRVSDdq+t v7uU3OoSfLodpOx1nuR2JfNim4CxvdMJE9kPAw9IMgeBdTTfFyxpzQR6FoR6EoLDEim9 mymL7Q32pcVtA4iwkyU3UOjdbIy/gvYg5J++mwyYdbdOwD5HkhfzDxyDEM1czRt1XOQd CfjZUbFqET2JkzR3IDCROxOQw3J8QD7r4BrwUERGwzOejFlaZO3mayXEgP4e003CNMMe lkCw== X-Gm-Message-State: AD7BkJIcGesNKMc0BzGqi7ckstsq3NSSd89We0Q7I/Sd8Ys9h1E32OY3K33RdSHJxgaRRuvO/9AIv5wT2UMwbA== MIME-Version: 1.0 X-Received: by 10.112.124.137 with SMTP id mi9mr3258685lbb.112.1458821139002; Thu, 24 Mar 2016 05:05:39 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 05:05:38 -0700 (PDT) In-Reply-To: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> Date: Thu, 24 Mar 2016 16:35:38 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: David Chisnall Cc: emulation@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 12:05:41 -0000 Hi. I'm agreed with point you told about improvements we can do for fat format (or more). And I'm ready to do them (with your helps, sure :D). But we need short steps and more of them (a local proverb :D) IMO. If we completely do this image activator, then we can have 2 sub plans for OSX emulation and/or fat data segment redesign. I saw netbsd's way of mach-kernel/darwin emulation. They have been stopped in porting/simulating quartz (the reason described lack of developers' interest IIRC), and that relates to OSX emulating. If we wanna complete/continue that way, first we need this image activator, what's your opinion about it? BTW, in brief I believe we can have strategies to do (sub plans) and it worth (at least for me, because I'll learn good things). What's your opinion? Best wishes, Mokhi. From owner-freebsd-current@freebsd.org Thu Mar 24 12:21:36 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 212A9ADB2A2 for ; Thu, 24 Mar 2016 12:21:36 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5261E66 for ; Thu, 24 Mar 2016 12:21:36 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 084ADADB2A0; Thu, 24 Mar 2016 12:21:36 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 057DAADB29F; Thu, 24 Mar 2016 12:21:36 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6BDA1E65; Thu, 24 Mar 2016 12:21:35 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u2OCLS6g017173 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2016 12:21:33 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: FreeBSD MachO File format, your comments on it. From: David Chisnall In-Reply-To: Date: Thu, 24 Mar 2016 12:21:23 +0000 Cc: emulation@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> To: mokhi X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 12:21:36 -0000 On 24 Mar 2016, at 12:05, mokhi wrote: >=20 > Hi. >=20 > I'm agreed with point you told about improvements we can do for fat > format (or more). > And I'm ready to do them (with your helps, sure :D). >=20 > But we need short steps and more of them (a local proverb :D) IMO. > If we completely do this image activator, then we can have 2 sub plans > for OSX emulation and/or fat data segment redesign. FatELF binaries do not depend on this work. Fat Mach-O binaries do, but = the pain of working with Mach-O is not worth it (talk to some of the = Apple toolchain team some time about how much effort Mach-O is - I=E2=80=99= m glad it=E2=80=99s their problem and not mine). I don=E2=80=99t believe that the work to support FatELF would be = particularly large. The format is pretty simple (basically a small = header that tells you where within the binaries to find the real ELF for = your architecture). Teaching all of the associated bits of the = toolchain (especially debuggers) about it is a lot of tedious work, but = not particularly hard if someone is motivated to do it. Teaching clang = and lld to produce fat binaries as part of normal ELF compilation would = be a bit more work. > I saw netbsd's way of mach-kernel/darwin emulation. > They have been stopped in porting/simulating quartz (the reason > described lack of developers' interest IIRC), and that relates to OSX > emulating. That wasn=E2=80=99t the only reason. The XNU kernel interfaces for = graphics and sound are large and mostly undocumented (at least, = publicly) and change between OS X revisions. Even if you implement = *all* of this, then you=E2=80=99d still need most of an OS X userland to = be able to run OS X applications. This would involve violating the OS X = EULA unless you ran it on a Mac and the only thing that you=E2=80=99d = then be able to do that you couldn=E2=80=99t with OS X is run FreeBSD = binaries in the background or in XQuartz (which you can already do = pretty well with xhyve on OS X). If you are willing to violate the OS X = EULA then you should probably just run OS X in a VM. > If we wanna complete/continue that way, first we need this image > activator, what's your opinion about it? >=20 > BTW, in brief I believe we can have strategies to do (sub plans) and > it worth (at least for me, because I'll learn good things). What's > your opinion? As a learning exercise, I definitely encourage you to continue. Writing = a new image activator will teach you a lot. If you want to do some of = the rtld work to make a partial Mach-O rtld then you=E2=80=99ll learn = even more. I just don=E2=80=99t think that the end result will be = something that=E2=80=99s particularly useful to anyone. David From owner-freebsd-current@freebsd.org Thu Mar 24 12:29:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0784FADB43F for ; Thu, 24 Mar 2016 12:29:47 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id DDB5011E9 for ; Thu, 24 Mar 2016 12:29:46 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D9498ADB43D; Thu, 24 Mar 2016 12:29:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6AF9ADB43C for ; Thu, 24 Mar 2016 12:29:46 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DD1711E8 for ; Thu, 24 Mar 2016 12:29:46 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id c62so29847717lfc.1 for ; Thu, 24 Mar 2016 05:29:46 -0700 (PDT) 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-transfer-encoding; bh=8UAzdEumaIb61LfKDQ02Vfgdu/aC5Bka0Kylh9/gTzE=; b=Jn0vcNtNtbfpyccrdSYGXF7Q2V5WI3PGuSTvMHAptBJaIj66ppLWxYqMc3e5vYGLw0 JamhlXOzPmrjgMJ4wVSuEQ+topycr0sJalJLoMbMxALj4t87TMNaIWVYN3RjtNExsuLR CMRyAR5JQN4qtuIPVjjbd578DtILREBrTXxeW3C5zezeQbyRngBgEboT3WR7l7ggW3D8 OqMZSOF2WjUSaGFEpfQTob1zyBquWoiRqSKWttay1WU8oS0wW0r/DHy78UiI4tab/is3 +ZXFDcFACkSgOwRPdL8YwbiW4oDPOr6JFZTinHlOi0ho+v0dUJiY0OpdyHPWCkqMKO5U xbYg== 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-transfer-encoding; bh=8UAzdEumaIb61LfKDQ02Vfgdu/aC5Bka0Kylh9/gTzE=; b=d8WDrigj/c1+ZjXtS4IA4SjOKe16HIXuD31yRZxHMy4vJFmdcWGiOx+J06WRkNgPjb /DMwHte2vRrz8dIuxVAedDfpwgjvIFFRdxkJj4gST+d+qL/pW1kcrdzQqJf8fC7Jjfl1 SRGNcrrr0ns/6CjrftJE2l8vonuEgvH2lUFq2bsSnbfo1gUEsFkPH21GtDKL8Z/kFOOg zMEDIJu4EW2edYY/nkVj053OiCxW1gtNP0DLEAHmhOFFb+qod/jzMTsvCts02o0ZGtpY i21ujRxYxQz376iDnxaqekT7q0qDTYJLIhl9oZVLovffAuWP/tNBO6KAo8AN4Yt4Q9AK qNAw== X-Gm-Message-State: AD7BkJJeJYp6HuQz3ys4PXzCfboNYA142VzMQhC2NtH1cGDHOE13vOfCd2SKvQTa6jFK4UJsMP/e4VtULnpN/w== MIME-Version: 1.0 X-Received: by 10.25.206.132 with SMTP id e126mr3444308lfg.20.1458822584497; Thu, 24 Mar 2016 05:29:44 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 05:29:44 -0700 (PDT) In-Reply-To: <40D5D502-FCA9-4405-A18B-FAB2E4478F02@bnc.net> References: <40D5D502-FCA9-4405-A18B-FAB2E4478F02@bnc.net> Date: Thu, 24 Mar 2016 16:59:44 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: Achim Patzner Cc: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 12:29:47 -0000 On 3/24/16, Achim Patzner wrote: > Would that project end in having an intelligent loader that will only map > the relevant architecture to memory (i. e. I=E2=80=99ll have extremely fa= t > executables supporting any known architecture in the universe on /usr/loc= al > or even for all files that can be shared between machines) and keep the l= oad > on memory and network as low as possible? It'll be one of its results, (at least) I expect :D though I'm not sure how it will have effect on network. > automatic cross-compilation to building I feel like Christmas came early. Then happy vacation ;) Thanks and thousands of regards, Mokhi. From owner-freebsd-current@freebsd.org Thu Mar 24 12:34:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6A47ADB59C for ; Thu, 24 Mar 2016 12:34:47 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B92711608 for ; Thu, 24 Mar 2016 12:34:47 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B523AADB599; Thu, 24 Mar 2016 12:34:47 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B27FCADB597; Thu, 24 Mar 2016 12:34:47 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DD601606; Thu, 24 Mar 2016 12:34:47 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lb0-x236.google.com with SMTP id qe11so28919058lbc.3; Thu, 24 Mar 2016 05:34:47 -0700 (PDT) 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; bh=gwsNT1Gf9XJUG60CS8KcFAEMHmEs7MLfvE5JcR6LOTs=; b=yWw4+ZOzFnTJauoJHboHi8Fw0q48Bx7k5Fs3VOSYM5YDQgVO33sazd6NIcehByN4ZT ZaQ+9GeMwABZaW03FrgcbzStfofUTrNZ4RJ2oQiSd11CIA7s/wcbIPPVA5c2B9gZwbVT 8sDrg2N7T9bhulW1p/sWUudF+r7TdWnTaAPB+nPKsyQQFoxNLxCaOZ3gA6/a6FgDYibR tYsxi9mfCYvC48f7Sa1mQA8cIHrRWTCj81oV8hfmy59nAH+kAEuozdBVNMpBrK8KKU3g LXxjiwlKLGG9JYhbZYYrgyitkGxY//eE7lR1HUWTauFKC2zGCzRvUGRCY4reT7yVLByi r+lg== 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; bh=gwsNT1Gf9XJUG60CS8KcFAEMHmEs7MLfvE5JcR6LOTs=; b=MlaX/ljuCLqPng0AQHLCsGbxjbMH98U3FUvSpiAubBrCs2jf8vG65Ovn4fzbnomqOu Zj/MT/Be+/ZGHNE5YwwOtWtQLn0v5gTbDoIhyFup+/9t/+Q0c2SqSfPWfAP+OZClSRP3 Cn2oE7HenYERjdnetODxh46DULcGrjmbKVMdtMmdsA8Ygh86TIh/u7lizQF8CpPzftta IOXnj4YQLz+25I2Gzpnt010pD4yhweT3abX4eB80i+dcLe7no4bS0UqV9BRQvskULV61 82MvcPQV5bizr/2iDpuxZgbI5ri+21mq2ew24JLcGrPMFDR1GNjXuZ5lhttLvC0xZE3c shPA== X-Gm-Message-State: AD7BkJI65goysap5/0ZCXXxi3QjNFQ27HeRoE0Z1BhTyurs3ZoyK/6d4nlFuV3tRj2nA4XzkQp5e/AXh32Tjgg== MIME-Version: 1.0 X-Received: by 10.112.124.137 with SMTP id mi9mr3313004lbb.112.1458822885315; Thu, 24 Mar 2016 05:34:45 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 05:34:45 -0700 (PDT) In-Reply-To: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> Date: Thu, 24 Mar 2016 17:04:45 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: David Chisnall Cc: emulation@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 12:34:47 -0000 Then you think the better idea is porting FatELF to FreeBSD, rather than working on MachO? From owner-freebsd-current@freebsd.org Thu Mar 24 12:45:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A3CBADB8D4 for ; Thu, 24 Mar 2016 12:45:13 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C18A1C31 for ; Thu, 24 Mar 2016 12:45:13 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1818EADB8D2; Thu, 24 Mar 2016 12:45:13 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15473ADB8D1; Thu, 24 Mar 2016 12:45:13 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2D91C2F; Thu, 24 Mar 2016 12:45:12 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lb0-x22d.google.com with SMTP id qe11so29093945lbc.3; Thu, 24 Mar 2016 05:45:12 -0700 (PDT) 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; bh=tTwTAyqkPSRxnkdlccfrdd2fn2tn0UGwi0cAr6b/Gj4=; b=qQr20Vr7gbQD6xVAFZF/nY5QIiZ2ufkhvxVfbkcBX7x6qlnPXFXoR3L747uTXHXq+e QZErKBzSCPSsbaMgwBg3TNla6hPxdeefRBagrIbXksn1HWYw2mYQCnt2g/CijUms8VxZ /tNm9kUZOX7JelgE2Gd05PD2rSKx0FLiXYmOibF8svjek68SwDccxiJPFeAqgs2fMJDl 0Aab2zM7zAIwhltpqplQzMLjoKPnJnPFIhPKKQzGYDhp8EB6x+HNzZ5nVTFEsMikoGRI lD0bojAm8114MdPi851mZyo0M1sxvDtCEvrkAEPM1vzjLZsesljvxXq+shGYF+h5DyMA JjMw== 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; bh=tTwTAyqkPSRxnkdlccfrdd2fn2tn0UGwi0cAr6b/Gj4=; b=JKA242SGlNhY5bgwjqjNiAjmA3/MZExg4W0GRWGNHD+xx6q87DeerkJwycRzTJMD7F Sm4Wb1ByeLE/l827AVe6xlnLXCTIUk1n4FVeuU58XIg1apj+Bh2XCYe/ZXpfktYDPiQ6 +stBBZhTx6FcC9/s30+RJVPyJ2Y7HW8+s6V2mTjr3YDL5lcNvb3IerW3JcCUTL87yKun RSE6GeI5q5L0hl3KADXxbkr2l55Ng60DA7eUAZpOiRiACBIcLOBJhjq0U2LsjNiaPMZX 6Q5K4WtnCH3wavpszpnbC1h1yO3QeggxzcPm7k4sUK82cZ9FpLiI66o+IweSbcVTQPni xkcw== X-Gm-Message-State: AD7BkJL+D3vVsKXDJfZr45S6/MEuSEQdzCZeHO0WntIWsJDaeAbQGIjij/lYsIG7+YRM/xJGgzKOkvwvJVInaQ== MIME-Version: 1.0 X-Received: by 10.112.172.68 with SMTP id ba4mr3274890lbc.86.1458823510885; Thu, 24 Mar 2016 05:45:10 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 05:45:10 -0700 (PDT) In-Reply-To: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> Date: Thu, 24 Mar 2016 17:15:10 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: David Chisnall Cc: emulation@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 12:45:13 -0000 On 3/24/16, mokhi wrote: > Then you think the better idea is porting FatELF to FreeBSD, rather > than working on MachO? > If yes, I am ready to put dedicated time on it :) [as I did for MachO] But before that, you think, is there any changes we can/should make on it? * I read something about FatELF when I was doing research for macho :) From owner-freebsd-current@freebsd.org Thu Mar 24 13:14:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 268AFADB2C9 for ; Thu, 24 Mar 2016 13:14:11 +0000 (UTC) (envelope-from pldrouin@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0A45E1BBB for ; Thu, 24 Mar 2016 13:14:11 +0000 (UTC) (envelope-from pldrouin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 06125ADB2C8; Thu, 24 Mar 2016 13:14:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 035D1ADB2C7 for ; Thu, 24 Mar 2016 13:14:10 +0000 (UTC) (envelope-from pldrouin@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA9B21BBA for ; Thu, 24 Mar 2016 13:14:10 +0000 (UTC) (envelope-from pldrouin@gmail.com) Received: by mail-ig0-x230.google.com with SMTP id nk17so111814455igb.1 for ; Thu, 24 Mar 2016 06:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=0MWa5vmj/15atgl+Ful4FjFMrNrJKpJ/i4vuuJf7zig=; b=L2sf/AEM1WPUBTN0LKvp0YvopBoz7Q8LjxGMuyqs1wDNPe7gfGxc7KIqqNKvZTSiWh +On6SkiitycUr7SxtWXe+mCoT6YA5bcNBWzFER1DyGrFA/zNg4+Ar6q8c0YHXXHPqLB3 jCLcyqfhWozQd/7/KTu2m6Tv8mG0GHtdKKOblojefeQQIIN7rAGMDiYSDSc7z5DJWZQA CtfoUvKt2A+OYspKChcddIEWfyZfLS29PL9d3DCQwOoAFoyPaefOZ6MhqESYcRoQPIBb hvm68HfG7IL9FahBIXiWlScCLOJe52PS1K8YiX5ZadRU4yw0nH6ex8kMgTtaj71klC4N CntQ== 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; bh=0MWa5vmj/15atgl+Ful4FjFMrNrJKpJ/i4vuuJf7zig=; b=YU1t7xpH+ZxjKiClhc48ruA6EOKNjUsGNlnrMqTAcL2rR1ux9yeJyfnckRBaJneZFp ua8H2SnkiacyT90m66bee+oh+8f77uzMpZk5KSKaumDDMNVRUVHQiqi4SAGYcXdjyoOo zZR/uaQX6wMpJs8Qv0kkR9FoX7rX3q6gU18t0CsLaVJOyptjHPJqFMcKNCT2MWU+JCvL 7tZ/oB3pXikHAJlLk9Xqneak2J+Oy65tDqpxQYpxXqL6kiJpLe28ATBnNHvs+CywSto3 08qKtrsWEQBTqOLOv9RGWNAWeYClXz90JyCsJjDaTQvV/E6mTXNI/yuBkP96ijhQpsbO Wspw== X-Gm-Message-State: AD7BkJIKcZ2TCUiadMGFSLzYIOzhfHNBZOewNIMUA/Ej3OSym8n9pDQhsFJJwerzrKJVa+D/dUwcJAXh11L9dA== MIME-Version: 1.0 X-Received: by 10.50.87.7 with SMTP id t7mr30248346igz.65.1458825249893; Thu, 24 Mar 2016 06:14:09 -0700 (PDT) Received: by 10.79.34.29 with HTTP; Thu, 24 Mar 2016 06:14:09 -0700 (PDT) Date: Thu, 24 Mar 2016 09:14:09 -0400 Message-ID: Subject: Running arm64 current on ODROID C2 From: Pierre-Luc Drouin To: current@freebsd.org X-Mailman-Approved-At: Thu, 24 Mar 2016 13:20:18 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 13:14:11 -0000 Hi, I would like to run arm64 current on an ODROID C2 (Amlogic S905 A53 64bit ARMv8). I was going to try configuring u-boot to either use an ELF kernel and boot it with bootelf or a kernel.bin produced with objcopy. and boot it with the go command. I was looking at the wiki instruction page for the ODROID C1 and the one for arm64. Is there any known issue that will prevent me for successfully run arm64 current on this type of device? Note that I don't care about video for now. Thanks! From owner-freebsd-current@freebsd.org Thu Mar 24 13:43:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEDC1ADBFF9 for ; Thu, 24 Mar 2016 13:43:07 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A075315A0 for ; Thu, 24 Mar 2016 13:43:07 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9BFA7ADBFF6; Thu, 24 Mar 2016 13:43:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B788ADBFF5; Thu, 24 Mar 2016 13:43:07 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F578159C; Thu, 24 Mar 2016 13:43:07 +0000 (UTC) (envelope-from damjan.jov@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id r187so61458497oih.3; Thu, 24 Mar 2016 06:43:07 -0700 (PDT) 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-transfer-encoding; bh=fhbl+eNyCKGKIR5xBHUORGC+QeR2PY92Oq9G+q5nXV0=; b=MCbN7/Ntv9crj1TxWD3RmqdJpfU860oTfsV039zdo9a0EYN2BkvuAdb1johbXLz3ht RfOrFaUiv7Q3elvOK1mrOEMLvYCIyjIxvywlECH09b4Tn2lh2zwU5hik+7HzPtKVdgLr /5SlQcNdhckoyGHBajaUfPBMhKSyd89Im2xgItryzoYpGpapUbCeBjD7UhFz0qZbBkbV 1QWVo38DZrfHZtX2a7S//8+ydM1dIaYIfGgzgcWupsiO9ZonjEmmjXakIPKfMh9ktql0 8QZkSrFFuPUBhNm7sEfFadR9bourK0ae7/crJq//TsqNyOSsZJcLpmVmugCtgI+7nqFk n8Tw== 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-transfer-encoding; bh=fhbl+eNyCKGKIR5xBHUORGC+QeR2PY92Oq9G+q5nXV0=; b=gUuX6jALXRCN9jKDKdg4LsrqmNlAdRcgM3NiU4wgsMDG3fUfW5UQRgyhS3TSnTEvoU EpYeCKQ2FQEehMLDY06Pq3NYKb0p5zZ6gKdNi0DE16rCWxcadHLm6XMUv6bgGnfYZB8u iimgQi3eRKto0vhjF/OLSFiqIFY+MM8APIOhlMw7zjCbCPQTDxFuasc1AL0sdqfTPc8K 0l5uJlz1RKzo2fA6afPiN1nbuPbwfWLIJJZuksiWG9EuFF/I24KVeXPvdB7CzkilkxXy JPB8Tulz/MR2Ysq/4eb4W56TVvW8zjd8/pxT22t3dchnn4GeDbyXn8CM2AZ4zrZ4+Y0s iuyQ== X-Gm-Message-State: AD7BkJLMlQYmwFLRGKFGTwKIWsuukq4SFAC1ZLnYAsSB3tIIYJedUnN+m7lEHKEOVPjUaWldWC5uiZhAfQXYeA== X-Received: by 10.202.57.133 with SMTP id g127mr4142000oia.120.1458826986439; Thu, 24 Mar 2016 06:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.38.168 with HTTP; Thu, 24 Mar 2016 06:42:46 -0700 (PDT) In-Reply-To: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> From: Damjan Jovanovic Date: Thu, 24 Mar 2016 15:42:46 +0200 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. To: David Chisnall Cc: mokhi , emulation@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 13:43:07 -0000 ELF itself is a disaster. Symbol lookup in ELF is process scoped, not library scoped like Windows's PE and Mac's Mach-O, so same named symbols from different libraries in the same process (loaded through any number of levels of indirection) can and do clash, resulting in memory corruption. This is why hacks like symbol versioning, RTLD_DEEPBIND on GNU's libc and -Bdirect on Solaris were invented. We suffer from this problem badly on FreeBSD, as Clang's C++ standard library and GCC's standard library don't have fully compatible ABIs, so when both are loaded into the same process and the incompatible C++ features are used -> memory corruption -> crash. Eg. compile Apache OpenOffice with GCC on a system built with Clang, and you'll see even the unit tests crash. This is why I am personally interested in alternatives like Mach-O. Damjan On Thu, Mar 24, 2016 at 12:51 PM, David Chisnall wro= te: > Hi, > > I=E2=80=99d slightly question the assertion that Mach-O is a well-designe= d format. For example, it has a hard limit of 16 section types, doesn=E2= =80=99t support COMDATs and so on. OS X uses a load of magic section names= to work around these limitations. > > Note that a Mach-O image activator is relatively easy, but a Mach-O rtld = is far more complex. It might be possible to port dyld from OS X, but as I= recall it depends quite heavily on the Mach kernel interfaces. > > On fat binaries, note that the support in the file format is pretty trivi= al. Far more support is needed in the image activator and rtld to determin= e the correct parts and map only them. If you=E2=80=99re interested in doi= ng this work, then I=E2=80=99d recommend looking at this proposed specifica= tion for fat ELF binaries: > > https://icculus.org/fatelf/ > > That said, I=E2=80=99m not totally convinced that fat binaries are actual= ly a good solution (unless you=E2=80=99re willing to go a step further than= Apple did and merge data sections) - NeXT managed very well shipping fat b= undles without using fat binaries and even had a special mode in ditto to s= trip out the foreign architectures when copying a bundle from a network sha= re to a local filesystem. > > Persuading clang to emit FreeBSD Mach-O binaries is probably harder than = you think. It=E2=80=99s quite easy to persuade it that Mach is a valid fil= e format for FreeBSD, but there are a *lot* of places where people conflate= =E2=80=98is Mach=E2=80=99 with =E2=80=98is Darwin=E2=80=99 in the Clang an= d LLVM sources. Finding all of these and making sure that they=E2=80=99re = really checking the correct one is difficult. > > Emulating OS X binaries may be interesting. NetBSD had a Mach / XNU comp= at layer for a while. The problem here is that the graphics stack interfac= es on OS X are completely different from any other *NIX system (as are the = kernel interfaces for sound), so the most that they could do was run comman= d-line and X11 Mac apps - not especially useful. Actually emulating OS X a= pps will need far more than that - OS X ships with about 500MB of framework= s, many of which are used by most applications. The GNUstep project is und= ermanned and hasn=E2=80=99t been able to keep up with the changes to the co= re Foundation and AppKit frameworks, let alone the rest. > > David > >> On 24 Mar 2016, at 09:13, mokhi wrote: >> >> Hi guys. >> I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends). >> >> I am working on adding Mach-O binary format to supported formats for Fre= eBSD. >> Not for emulations on first step, but as a native supported format >> just like a.out [or Elf] >> (though it can go in both ways too). >> >> There are good reasons to have Mach-O format support IMO. >> It's well/clear designed file format. >> Can supports multiple Arch by default (It's Fat Format). >> Because of its Fat Format support, it can even help porting/packaging ea= sier for >> projects such as Freebsd-arm or others IMO :D. >> At end (even not among its interesting parts, maybe :D) point, it >> leads and helps to have >> OSX emulation support on FreeBSD. >> >> BTW, i've coded[1] Mach-O support for FreeBSD with helps of >> FreeBSD-ppl on IRC about various aspects of this works (from >> fundamental points of VM-MAP, to SysEntVec for Mach-O format) and >> with help of Elf and a.out format codes and mach-o references. >> It's in Alpha state (or before it) IMO, as I'm not sure about some of >> its parts, but I've tested a mach-o formatted binary with it and it at >> least loads and maps it segments correctly :D. (it was actually a >> simple "return 0" C Code, compiled in a OSX, if you know how can I >> force my FreeBSD clang to produce mach-o files instead of ELF I'd be >> happy to know it, and I appreciate :D) >> >> I'd like to have your helps and comments on it, in hope to make it bette= r >> and make it ready for review. >> >> Thanks and thousands of regards, Mokhi. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> [1] https://github.com/m0khi/FreeBSD_MachO >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.o= rg" From owner-freebsd-current@freebsd.org Thu Mar 24 13:56:07 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC96CADC29A for ; Thu, 24 Mar 2016 13:56:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B79811D39 for ; Thu, 24 Mar 2016 13:56:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id B3686ADC298; Thu, 24 Mar 2016 13:56:07 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2ECBADC297; Thu, 24 Mar 2016 13:56:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 888541D37; Thu, 24 Mar 2016 13:56:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.0.7] (cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id u2ODu4NK017717 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2016 13:56:05 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc91230-cmbg18-2-0-cust661.5-4.cable.virginm.net [82.1.230.150] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: FreeBSD MachO File format, your comments on it. From: David Chisnall In-Reply-To: Date: Thu, 24 Mar 2016 13:55:58 +0000 Cc: mokhi , emulation@freebsd.org, current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> To: Damjan Jovanovic X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 13:56:07 -0000 On 24 Mar 2016, at 13:42, Damjan Jovanovic wrote: >=20 > ELF itself is a disaster. Symbol lookup in ELF is process scoped, not > library scoped like Windows's PE and Mac's Mach-O, so same named > symbols from different libraries in the same process (loaded through > any number of levels of indirection) can and do clash, resulting in > memory corruption. This is why hacks like symbol versioning, > RTLD_DEEPBIND on GNU's libc and -Bdirect on Solaris were invented. This problem is addressed by some of the work that Sony has done = recently that they are about to upstream to Clang/LLVM. > We suffer from this problem badly on FreeBSD, as Clang's C++ standard > library and GCC's standard library don't have fully compatible ABIs, > so when both are loaded into the same process and the incompatible C++ > features are used -> memory corruption -> crash. Eg. compile Apache > OpenOffice with GCC on a system built with Clang, and you'll see even > the unit tests crash. That shouldn=E2=80=99t happen, as libstd++ and libc++ have different = symbols (libc++ puts its symbols in the __v1 namespace). The problem = can come from mixing libsupc++ and libcxxrt, but that=E2=80=99s only an = issue if you have not built libstdc++ against libcxxrt. David From owner-freebsd-current@freebsd.org Thu Mar 24 14:26:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D365ADCBF8 for ; Thu, 24 Mar 2016 14:26:28 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3F71413C7 for ; Thu, 24 Mar 2016 14:26:28 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3A912ADCBF6; Thu, 24 Mar 2016 14:26:28 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A01DADCBF3; Thu, 24 Mar 2016 14:26:28 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B383613C3; Thu, 24 Mar 2016 14:26:27 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id q73so33365061lfe.2; Thu, 24 Mar 2016 07:26:27 -0700 (PDT) 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; bh=x6ghGwrsxNHhnE9Cjns1LN1JjlIvQ8QFnpGDc+FGIVU=; b=ef1L3xOTCLXnkgzCrhB/bE6wMJF2cBuZuiSc41md9oBr5Nt6wR/H4nyy7HgGWbl13/ sOWG77/xjFQu12ZcusMmK7G4hNLxp0D5LL+jTs1n3zjUaFSJ/XMFTsvvp+wgj1XJA415 5VoSoQCxDQd1EBNpxZQUWOtu12ay3c2dGN0Ctu8EYZy9xanG2bZlDYXokosnfb8O8lWb YuSY0dgSCfu7FPTSOte3lGnRF72sP7VC56d3JP0z8fxNErTsOSFbQf/D8boHCmyT8nc7 WE1O0YWlA41FKzJWpEzEVRxA9iQOe8xjQfZED8MZGxZX28NDoaJaDeIDXHlhC6lwSaX3 JL6A== 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; bh=x6ghGwrsxNHhnE9Cjns1LN1JjlIvQ8QFnpGDc+FGIVU=; b=cqgGHVDRpF1KHwmoPi3YCrz5c2gPYRX4+ZoLBNPP3oDJBWAb6RahBSnWo2/4iTjZhE xBi6OkaCYTZOGXZxSAuQ2zxbLOdxfRTBe9Z2Q1dbGgKjwCng64gDM/gfgMM2WxyLCe13 kZnh0SMzqlDA5p5z15mqxUdfsuwMdEySmBpdu7yHGt0AlhpDc/8tqxM2ZPfkSDo+1M25 XnXH7FV5asoK5J3RJOaAAh0c9wnyF/0HHjNmn3/GJ4bTluidBzgLPuo+RBJkGKUqnJpq 3pnR7YeTzactsFZ9sUgN3B8QybNWQfR5+SBMy35EdVmcmMW/kGoilYOVyPmAMH1Pbmnv DuPg== X-Gm-Message-State: AD7BkJITB9+2YDqciDfdIE15ibZKoO4QJbHeqYJ0Ylmkd+xWivURVT1F97B/rqd6rSRBXl3XRiEDl0hIheKTUQ== MIME-Version: 1.0 X-Received: by 10.25.206.132 with SMTP id e126mr3733173lfg.20.1458829586035; Thu, 24 Mar 2016 07:26:26 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Thu, 24 Mar 2016 07:26:25 -0700 (PDT) In-Reply-To: <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> Date: Thu, 24 Mar 2016 18:56:25 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: David Chisnall Cc: Damjan Jovanovic , emulation@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 14:26:28 -0000 So, I'll try to port FatELF as well as MachO. Choosing the better one is up to you ;) All opinions/idea are welcome and I appreciate. Best wishes, Mokhi. From owner-freebsd-current@freebsd.org Thu Mar 24 19:00:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0765ADB382 for ; Thu, 24 Mar 2016 19:00:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C0D301DC0 for ; Thu, 24 Mar 2016 19:00:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BC8F9ADB380; Thu, 24 Mar 2016 19:00:04 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9DE1ADB37E; Thu, 24 Mar 2016 19:00:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79CBE1DBE; Thu, 24 Mar 2016 19:00:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id ig19so18365407igb.1; Thu, 24 Mar 2016 12:00:04 -0700 (PDT) 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; bh=/oo5NqmxELG0K3OZRERn2YHd3FFnDw1dy6ubphx2vGY=; b=dfciuIycu+wo0wfKDNCsTiE3fIVUb4bx/K8aSWo2Tif0Cj/G1/hh/XbX/TbwBfafJ6 ncxO7Z87rS+olie8QTRTcGwCw4HO71m2EVCJ4P95c977iBMeJWfKxMQMBGl7FD81OSIp 2ZKFpEiNiwlX3eHQ3jz15UfrXzADWDEFUjh3ykNe4p9vhsLl+RJusEKUdFqCyczRJDWG TndSBPbQEZ2ugl0wMKqZ59gFuxKL/EA8CTOXWrwCXiR4K+ygrkk+2hkddrlbWa+ft5mf AUdgkkVSvWqU/ysht551V1JtsHH0X01y0Ru5KtavjRECczIzD8uPoRECCtw3fTxoGqbq SHWQ== 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; bh=/oo5NqmxELG0K3OZRERn2YHd3FFnDw1dy6ubphx2vGY=; b=Cm8bf2Jx6S3Eya441BsdVo/oypypQklRTxKKUWgW6ty232XfSONNdc/Pk2fE/xXTqf npIb7K/Q0trlplrV3p0Pxj5Pu+9wmXZD69bt7nWK4XZCgVrBCFlsyg3YlVFbFFSKQU+F gyQD3SEDEEC2mmhrt+8M2KbuilLH1OC39vXAzTvg7LRvjuGRx8szGleVAS+l5xhKeDBo lIMqmXoHITFolKgX5p6RheFJsCmxD6ihmSZM61H1Pgh1LOzzcKC3YOkekFRvntXHQmHx 5D8OdmWLgzJyRX6yeI/tE8ZAZYvKbm/wkJLqo8RKaxnNdth/WdV9L7n547vo8vnb5V1H 7ubg== X-Gm-Message-State: AD7BkJLHqcgS0egrSrDtJpyPC+pgeLXmf/CEu1jA/atxMoolFsseY7QOO9H86rUG/8sWByZdYH6/FhCJgVgZBg== MIME-Version: 1.0 X-Received: by 10.50.157.39 with SMTP id wj7mr30109358igb.61.1458846003797; Thu, 24 Mar 2016 12:00:03 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Thu, 24 Mar 2016 12:00:03 -0700 (PDT) In-Reply-To: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> Date: Thu, 24 Mar 2016 12:00:03 -0700 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: Adrian Chadd To: mokhi Cc: David Chisnall , Damjan Jovanovic , emulation@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 19:00:05 -0000 +1, get mach-o up, see if we can twist other people to work on the other missing bits to run apple stuff on freebsd. :P -a On 24 March 2016 at 07:26, mokhi wrote: > So, I'll try to port FatELF as well as MachO. > Choosing the better one is up to you ;) > > All opinions/idea are welcome and I appreciate. > > Best wishes, Mokhi. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Mar 24 19:46:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10855ADC100; Thu, 24 Mar 2016 19:46:55 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA38F1439; Thu, 24 Mar 2016 19:46:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EEBBFF48; Thu, 24 Mar 2016 22:46:50 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: question on support processor Intel Atom Z3735F References: <1458846365.574939838@f173.i.mail.ru> To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <56F44422.6050107@FreeBSD.org> Date: Thu, 24 Mar 2016 22:46:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458846365.574939838@f173.i.mail.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VsglVVQiJDluXDFjul55pI78WllaStjHE" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 19:46:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VsglVVQiJDluXDFjul55pI78WllaStjHE Content-Type: multipart/mixed; boundary="0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <56F44422.6050107@FreeBSD.org> Subject: Re: question on support processor Intel Atom Z3735F References: <1458846365.574939838@f173.i.mail.ru> In-Reply-To: <1458846365.574939838@f173.i.mail.ru> --0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24.03.2016 22:06, =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80 wro= te: > Intel Atom Z3735F Both x86 (32 bit) and amd64 (64 bit) will do. It depends on available memory. If you have 4GB or more installed, try amd64. --=20 // Lev Serebryakov --0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0-- --VsglVVQiJDluXDFjul55pI78WllaStjHE 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 iQJ8BAEBCgBmBQJW9EQoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePo+wP/0AOjwXT2CTdDLzc9IqK8phs QXkImc/jbP05oDClzORbK3sM1F3bQ7QY2Zs+7YNS6skC6u702dLDNQKtE1rtlujJ Ozkb/tLA7xmZNJ/Id41qp/f39CyD3Sfj77l07zuZxFWVePbYEWlNZT2GxyYeaZ5j AMAr4hr/Wg/MlFUMDd5EvrQSGs84v/EHkn7tlv53wnM+aJsizJEdDQaNgkD9WBdN SFmRXu7kFpCb3v0vskl7A0XLP6kg5WNBcgs4tRkJwSnNfIBzkKR8har8cDl9GJof uTKfMUZDg7sp0jtJCsRuCo0DO7GAFdWOOfo6jkioP+rrB62Jjhxwh79WwJ7iOkxh 9CLohrmWP75PezxAq4gpImlx12msgsQvTzQwYd2GWFd0pZrwRLdQS86owAGXeAC6 BkCOkkl05ljsMMygzXAt3UXXkteqifGduaAtJDBcPnbcvv5VKwOAOyvx26wwB5x/ 83nEc9Hqrimb5O8NJVJ/IZR2gBhNQQ2J6/WSenGHx0oe22ggNVgf5B8haDx/Ak2J NicxV6uykpgVnSc8UBZEJsWiMc4MRgONXefCoPJ3SgwEnvEM49WfE1Vml+tFxXq4 DKm/gyUzHngYgCDeYDkeEWvPtlrXdO3N2tyyp1cb/net4w1NHGHmS4FDMUgW2CxF 8ZHIItrzGRnGaZajKW76 =YGny -----END PGP SIGNATURE----- --VsglVVQiJDluXDFjul55pI78WllaStjHE-- From owner-freebsd-current@freebsd.org Thu Mar 24 23:11:15 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFF34ADD808 for ; Thu, 24 Mar 2016 23:11:15 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2B4196A for ; Thu, 24 Mar 2016 23:11:15 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id l68so4984947wml.1 for ; Thu, 24 Mar 2016 16:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=/h8MvnBc6PvRPOqmc/zmdPgTzajoe4MZ+4+KIFKLI/c=; b=WQr0otDn4NSEAuBRHkPmwLvn72QKidmiIkIDi0r8YmHTvH+88fpaSQciddXSN/N/9s yxKNP+icQjrnxP3/4IOZawByvAwyPbGlIHHp5iz9MOFAdDs+q5VKQcmTN8UWwov7RpKW q6PmRcNS2Exo7YRq/+yBwVC1KFFhQYjymPcEX73hjmVqrn+uJVYmn7xKvFG8goCvXxU/ lusOFtNywknlpBUfrTEK0XMr4yyEKJd5qbGZW+y6Yl4Uc0p0fqJ4cglT/PcicVKqxkyc xUDK+xCMzGhhBOxgrwPyK2FL2PrfYooCcP7itRxnECgTF2sd1WH54pauG72F/GfpH5fW RkAQ== 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; bh=/h8MvnBc6PvRPOqmc/zmdPgTzajoe4MZ+4+KIFKLI/c=; b=T9WZdGwpl2hae5SeIaTcOIa94l9jOFrFzXQg+ZKzg64R62msE6aAfr3zpuOHruqGVq zYDchTxxZZDn0JBvYANQv72exkmQFEF3TggC93ZU6geffkn09Q/ZXae84WK6xBM5oITk W2UPJDVV366AI1vkbn9zYvdPIATepcbko4X1Ni14z2BG3GbAKLVtciMgybAm1Hp7tby4 uJ6QBlsfjKDK6VzEpM4GZDWr4dlu5iDTSxLwTgeGWbaou/WRL5wjvrbCPvQm6lss5O5n ZRmoQjAj3NTaImza4IXBVoTLMS7cgOCAYLK9gqVfrKe8FqHp7tMsrkPHpPvibb5ApczY jJfg== X-Gm-Message-State: AD7BkJJsOlcROFj2m7rH/f+TVLxnSmNERHDZPuMqvVOq//i7xUL5AyXuB1lCunP67arjMyvedokGKSGT226piQ== MIME-Version: 1.0 X-Received: by 10.28.225.198 with SMTP id y189mr37622176wmg.94.1458861073450; Thu, 24 Mar 2016 16:11:13 -0700 (PDT) Received: by 10.28.224.84 with HTTP; Thu, 24 Mar 2016 16:11:13 -0700 (PDT) Date: Fri, 25 Mar 2016 01:11:13 +0200 Message-ID: Subject: panic "wlock already held" when changing ipv6 default route From: Guy Yur To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 23:11:15 -0000 Hi, When changing the ipv6 default route I get a panic on wlock already held. Could be related to r293424 lock changes, haven't checked an older version yet. route add -inet6 default fe80::7 route change -inet6 default fe80::7 panic: rw_rlock: wlock already held for rib head lock @ /usr/src/sys/net/route.c:445 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0050ee01d0 vpanic() at vpanic+0x182/frame 0xfffffe0050ee0250 kassert_panic() at kassert_panic+0x126/frame 0xfffffe0050ee02c0 __rw_rlock() at __rw_rlock+0xe7/frame 0xfffffe0050ee0360 rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfffffe0050ee0420 ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfffffe0050ee0460 rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfffffe0050ee0480 rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfffffe0050ee0570 route_output() at route_output+0x653/frame 0xfffffe0050ee07c0 sosend_generic() at sosend_generic+0x436/frame 0xfffffe0050ee0880 soo_write() at soo_write+0x42/frame 0xfffffe0050ee08b0 dofilewrite() at dofilewrite+0x87/frame 0xfffffe0050ee0900 kern_writev() at kern_writev+0x68/frame 0xfffffe0050ee0950 sys_write() at sys_write+0x60/frame 0xfffffe0050ee09a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0050ee0ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0050ee0ab0 --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp = 0x7fffffffe2d8, rbp = 0x7fffffffeb90 --- KDB: enter: panic [ thread pid 644 tid 100054 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why Booted into livecd with snapshot iso in a VirtualBox VM and ran the commands above. FreeBSD-11.0-CURRENT-amd64-20160308-r296485-bootonly.iso -- Guy From owner-freebsd-current@freebsd.org Fri Mar 25 04:22:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73D19ADDBC6 for ; Fri, 25 Mar 2016 04:22:18 +0000 (UTC) (envelope-from eric.camachat@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11A0F1A81 for ; Fri, 25 Mar 2016 04:22:18 +0000 (UTC) (envelope-from eric.camachat@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id p65so10462486wmp.0 for ; Thu, 24 Mar 2016 21:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=rToWZkSxJYIzu9tMAGyQDKy3g/UOgXnEYqp+sTXC7RU=; b=ZACsy6zvCzkpK586mssuiimBn9PBdqtjX00XRnNjGrzJhOFrSwRSCZzvEqmOmLC166 Rg0bauniqI2ROqinazjHUzOlYrFKipY6SUtm9tWEZXttTUFlTiU5XYAF7/NdBiKXRIpm eYg8Y5bH4pN48Ei2oqTUzUsf4FrX/LzMZOU/j0G6ZDiRweEBZ4XsK5Tn79EbsdIEjY7q q/VSBsqfm8gaUuhzf1yY1Hpdl2FAI+aHZXAbkclY2+FcnyQ/xWID8zdo0OIlvv9TJmyv NNrt6U7aMOUqZAu66Xn9WI365WdDvrlWzwrx9JQ5UYdv0GLJcMQgDCeEJQIOG9EqArUp zkxQ== 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 :content-transfer-encoding; bh=rToWZkSxJYIzu9tMAGyQDKy3g/UOgXnEYqp+sTXC7RU=; b=dBny254smA9vkh0b3qudLJNNJGogupO6DfwS+odmIBzYsYR8I5imAu84zzTElwb6qZ VnWBXjlWP0XuuFJyqsByNeSObsMUnheweheqVwBp00BTVCio1fGsajgJxaHBCCloYNUb kHrr2/I6aVEWbCRthqcItkbZ6NF1NndRQlZy0ujH97XvJkt3sF9ygQMJ06bQ65yt0VDU SjCfQDa1kg8VRQr04xmqSkxMMcBUFvslilIW94JVDhbeFVuFU/+YTMuw5t6SSLkFCnBQ 9vGmV0kQXLzqVLfP0AA4/q/cWoX4Jjp7d0dd7t8kPQsOg8KvCSzfyU8EiqxuU550T/H7 cgbw== X-Gm-Message-State: AD7BkJKx2JiKBKB2gb0IEGqnZG1wPhwEoUncTAMgIawsmWNZp8ktEQpS8XeTxi0i/W7GXAUW7mAvepuoAWzDlg== X-Received: by 10.28.170.137 with SMTP id t131mr35853412wme.74.1458879735722; Thu, 24 Mar 2016 21:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.226.11 with HTTP; Thu, 24 Mar 2016 21:21:56 -0700 (PDT) From: Eric Camachat Date: Thu, 24 Mar 2016 21:21:56 -0700 Message-ID: Subject: failed to compile base, buldworld, with -Os CFLAGS To: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 04:22:18 -0000 I tried to buildworld with -Os CFLAGS, but it failed. Here is the compiling log: --- getcap.So --- cc -m32 -DCOMPAT_32BIT -march=3Dhaswell -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -fpic -DPIC -g -Os -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/world32/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD -MF.depend.getcap.So -MTgetcap.So -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -I/usr/src/lib/libutil -I/usr/src/lib/msun/i387 -I/usr/src/lib/msun/x86 -I/usr/src/lib/msun/src -c /usr/src/lib/libc/gen/getcap.c -o getcap.So --- getcwd.So --- --- fnmatch.So --- cc: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/fnmatch-87dc57.c (http://slexy.org/view/s2ddVhTTyQ) cc: note: diagnostic msg: /tmp/fnmatch-87dc57.sh (http://slexy.org/view/s21zeFmDPU) cc: note: diagnostic msg: ******************** *** [fnmatch.So] Error code 254 make[4]: stopped in /usr/src/lib/libc --=20 =F0=9F=8C=9EEric From owner-freebsd-current@freebsd.org Thu Mar 24 19:37:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B12E1ADBD08; Thu, 24 Mar 2016 19:37:19 +0000 (UTC) (envelope-from foxii@bk.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.181.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2F71DED; Thu, 24 Mar 2016 19:37:18 +0000 (UTC) (envelope-from foxii@bk.ru) Received: from f173.i.mail.ru (f173.i.mail.ru [94.100.178.91]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id 0C9D06C2F738; Thu, 24 Mar 2016 22:06:16 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=3UzJU63EH+uaP1oDo7acTLbcz8H/qVao2MDF7qm4jak=; b=XopBwU96ahHiQ2GHlj/9SRpzFEbTvLXsmfJ3u5C2W+aeNbiLTcySkpExi9U63JsR/95EZsZv5MmefFzF59hd3h9XQXYvEol7aRYHD9YelfITK28tMsmd64bA60ugaG5jSkmQxO72aRoGOQPMH9mC8god7E0MeMjFkFLYFLlncyc=; Received: from [31.44.58.133] (ident=mail) by f173.i.mail.ru with local (envelope-from ) id 1ajAa5-0007U5-Qo; Thu, 24 Mar 2016 22:06:06 +0300 Received: from [31.44.58.133] by e.mail.ru with HTTP; Thu, 24 Mar 2016 22:06:05 +0300 From: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: =?UTF-8?B?cXVlc3Rpb24gb24gc3VwcG9ydCBwcm9jZXNzb3IgSW50ZWwgQXRvbSBaMzcz?= =?UTF-8?B?NUY=?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [31.44.58.133] Date: Thu, 24 Mar 2016 22:06:05 +0300 Reply-To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= X-Priority: 3 (Normal) Message-ID: <1458846365.574939838@f173.i.mail.ru> X-Mras: Ok X-Spam: undefined X-Mailman-Approved-At: Fri, 25 Mar 2016 04:23:43 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 19:37:19 -0000 IEhlbGxvLCBwbGVhc2UgdGVsbCBtZSB3aGV0aGVyIHRoZSBGcmVlQlNEIG9wZXJhdGluZyBzeXN0 ZW0gSW50ZWwgQXRvbSBaMzczNUY/wqBXaGljaCBkaXN0cmlidXRpb24gSSBuZWVkIHRvIGRvd25s b2FkPwoKCgE= From owner-freebsd-current@freebsd.org Thu Mar 24 19:39:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF9C2ADBE30 for ; Thu, 24 Mar 2016 19:39:31 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B96791F39 for ; Thu, 24 Mar 2016 19:39:31 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-io0-x234.google.com with SMTP id m184so94667681iof.1 for ; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PxNb59yuuJJyNKGn0p/AojQ1579fwx4OQzbT14Ac3KQ=; b=RCbeaFth4MkX2ySwjMkkd+Z7MXtrMwvJTc0e51GjPTgrYghqGSjecU9Bg0oex7Xl0y o3dyEdtjLTn77S0coLjoYqm87LhRq1NrOYYKSagnjMmgsVX8VG854RCs/JLL7q4fFw2a oDAqXiuGrfbifRK3w2Axo1rRH/qu2+dhL0KyTNLlhXoLLSCYFrAFf0MvGBQYStdeLyC0 42yuEroVDjLafTUAjNh1mx72AGPJD8wrRomFFERfyJnQ0WjZSneR89OO5/4L+Ftt7gUv tF4QOi2DmRDboLsH4h0DwKUCf5blt69IrRGQ36Ot/dCKGhZG8rLdzOMBAgxlruqruhnF eBgg== 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; bh=PxNb59yuuJJyNKGn0p/AojQ1579fwx4OQzbT14Ac3KQ=; b=Adk96kXIwxiXrVhjOH87nyREgAuPeIniAQoD55PESc1EzjpFoSeUFuhXFyzG+Xludi yjbWTQAx6WCd3LfeSObiGPLrG6V1I7vTlwH4nHpx2H7HOshgFwJvh5UPMkP4DXmCdPPZ bTune7YOXeqvxvhPLe5vYH+GFoCPcItAtHs1GeAOf8GQPTurjXqGUZzpDwLSCbCsN1qD ezg2MtFbjYDQddLFvOFZYDYrLZtFGdsu/YvfmfxfL7oW6KoQIxPJmLNDfNiQL83av0b7 YiLnRgeVXE5SVbm/y7MNAaOqp1/iVkyFZzFLgKgR8EsScjJWzpbB4JonTQIiqiNms7TQ f1Ag== X-Gm-Message-State: AD7BkJIRose04iPSB7ECLpjR3TpfXeR+4k4RZYgUEvzNpD1NEf6zCn/gxYgnFINfTFFeUJGqDFgUAy3QNaECtQ== MIME-Version: 1.0 X-Received: by 10.107.14.142 with SMTP id 136mr10155270ioo.94.1458848371145; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) Received: by 10.79.11.71 with HTTP; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) X-Originating-IP: [207.96.192.66] Received: by 10.79.11.71 with HTTP; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) In-Reply-To: <1458846365.574939838@f173.i.mail.ru> References: <1458846365.574939838@f173.i.mail.ru> Date: Thu, 24 Mar 2016 15:39:31 -0400 Message-ID: Subject: Re: question on support processor Intel Atom Z3735F From: peter garshtja To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= Cc: freebsd-arch@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-Mailman-Approved-At: Fri, 25 Mar 2016 04:24:02 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 24 Mar 2016 19:39:32 -0000 Hi Vladimir, I believe you need x86 arch. Regards On Mar 24, 2016 3:37 PM, "=D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80"= wrote: > Hello, please tell me whether the FreeBSD operating system Intel Atom > Z3735F? Which distribution I need to download? > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Mar 25 05:14:54 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A5CFADC5EF for ; Fri, 25 Mar 2016 05:14:54 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward11p.cmail.yandex.net (forward11p.cmail.yandex.net [87.250.241.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2951BF2 for ; Fri, 25 Mar 2016 05:14:53 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from web18g.yandex.ru (web18g.yandex.ru [95.108.252.118]) by forward11p.cmail.yandex.net (Yandex) with ESMTP id 3783520E44; Fri, 25 Mar 2016 08:14:36 +0300 (MSK) Received: from web18g.yandex.ru (localhost [127.0.0.1]) by web18g.yandex.ru (Yandex) with ESMTP id 91A8F42A12A0; Fri, 25 Mar 2016 08:14:35 +0300 (MSK) Received: by web18g.yandex.ru with HTTP; Fri, 25 Mar 2016 08:14:33 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: Guy Yur , freebsd-current In-Reply-To: References: null Subject: Re: panic "wlock already held" when changing ipv6 default route MIME-Version: 1.0 Message-Id: <1317681458882873@web18g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 25 Mar 2016 08:14:33 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 05:14:54 -0000 25.03.2016, 02:11, "Guy Yur" : > Hi, > > When changing the ipv6 default route I get a panic on wlock already held. > Could be related to r293424 lock changes, haven't checked an older version yet. Hi, Yes, there is a problem when the default route next hop is filled in incorrectly, so lookup fails (e.g. matches previous one). Will be fixed soon. Thanks for the report. > > route add -inet6 default fe80::7 > route change -inet6 default fe80::7 > > panic: rw_rlock: wlock already held for rib head lock @ > /usr/src/sys/net/route.c:445 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0050ee01d0 > vpanic() at vpanic+0x182/frame 0xfffffe0050ee0250 > kassert_panic() at kassert_panic+0x126/frame 0xfffffe0050ee02c0 > __rw_rlock() at __rw_rlock+0xe7/frame 0xfffffe0050ee0360 > rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfffffe0050ee0420 > ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfffffe0050ee0460 > rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfffffe0050ee0480 > rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfffffe0050ee0570 > route_output() at route_output+0x653/frame 0xfffffe0050ee07c0 > sosend_generic() at sosend_generic+0x436/frame 0xfffffe0050ee0880 > soo_write() at soo_write+0x42/frame 0xfffffe0050ee08b0 > dofilewrite() at dofilewrite+0x87/frame 0xfffffe0050ee0900 > kern_writev() at kern_writev+0x68/frame 0xfffffe0050ee0950 > sys_write() at sys_write+0x60/frame 0xfffffe0050ee09a0 > amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0050ee0ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0050ee0ab0 > --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp = > 0x7fffffffe2d8, rbp = 0x7fffffffeb90 --- > KDB: enter: panic > [ thread pid 644 tid 100054 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > > Booted into livecd with snapshot iso in a VirtualBox VM and ran the > commands above. > FreeBSD-11.0-CURRENT-amd64-20160308-r296485-bootonly.iso > > -- Guy > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Mar 25 11:05:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A97AAADD20B for ; Fri, 25 Mar 2016 11:05:06 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E694172E for ; Fri, 25 Mar 2016 11:05:05 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id DB7766E005D; Fri, 25 Mar 2016 12:05:02 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u2PB52ne005726; Fri, 25 Mar 2016 12:05:02 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u2PB52nu004930; Fri, 25 Mar 2016 12:05:02 +0100 (CET) (envelope-from lars) Date: Fri, 25 Mar 2016 12:05:02 +0100 From: Lars Engels To: =?utf-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= Cc: freebsd-current@FreeBSD.org Subject: Re: question on support processor Intel Atom Z3735F Message-ID: <20160325110501.GN24170@e-new.0x20.net> Mail-Followup-To: Lars Engels , =?utf-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , freebsd-current@FreeBSD.org References: <1458846365.574939838@f173.i.mail.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s8J8qjRpxLkp1Gun" Content-Disposition: inline In-Reply-To: <1458846365.574939838@f173.i.mail.ru> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 11:05:06 -0000 --s8J8qjRpxLkp1Gun Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 24, 2016 at 10:06:05PM +0300, =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0= =BC=D0=B8=D1=80 wrote: > Hello, please tell me whether the FreeBSD operating system Intel Atom > Z3735F?=C2=A0Which distribution I need to download? The CPU supports amd64 but AFAIK the Baytrail architecture only supports a 32-bit UEFI. So you need to create your own boot medium. --s8J8qjRpxLkp1Gun Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF7BAEBCgBmBQJW9RtdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tZFEH9i/o7Lc9F/GzqmI0t4tQhGv+ 5aQTtrcJml23+GprtnJEmXZRXA7mb32aUEoYcYDP95ipkkvwAI5A3ILS4QN6ltTH /9lLL5IRngZQNMM/27qNoIxmnDy/lmOKQlTwroKnqN/fE7VesIg2zy8qNrTvMtJi L7q5coiuPRGI3eOp92Zc57SVqoOqTajRtYOTRWlrStNrFBjfXC+WjzKG73rwCYdZ 9o51PmfjtBCDqCA6r1Mls6KXq6QbAY0izb2+voIj7wrCHsf2OQpwp6y4D5+XSVd9 Qn0+7bk883KiZnPzOUHLMIXE6PL5cqMmzcx2Ao3XSE8kHOcsMUvLeDgTPjkdNw== =97XU -----END PGP SIGNATURE----- --s8J8qjRpxLkp1Gun-- From owner-freebsd-current@freebsd.org Fri Mar 25 15:43:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48707ADD46E for ; Fri, 25 Mar 2016 15:43:29 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 285871F3C for ; Fri, 25 Mar 2016 15:43:29 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 236BDADD46C; Fri, 25 Mar 2016 15:43:29 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22FE2ADD46B; Fri, 25 Mar 2016 15:43:29 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DFCF1F3B; Fri, 25 Mar 2016 15:43:28 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id d82so57163671lfe.3; Fri, 25 Mar 2016 08:43:28 -0700 (PDT) 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; bh=LZEMj49FWO8HoMJy4cghaH7ao5kJeQPnaGIAaI2DG/E=; b=lMTnJRJf+b5Abbn7HQJ+rmoa+frO+Np+8v3DFsopPyRDtc66jv+9zd+Jzh5sEL6D4n eQj50I4LPNPDVVcito93mLqlsh7UcPHPJRVk2KhltPD/YjU8WwaCQpYR+6nVrF6RESCB SSibwYGrFfJKsunWkH9ZXPEyzXJj1hPxJILcHTKxSrjtikNzXZWM3wc0xpubeYfEmJbZ +aJIySDXqGDX5Yb/UJAvq9vnql15EAsT0mK0KmSz4RgdyxS5gqLPFcaLL5b4fnAeckWs y23j37wfcgQAzuUAcmdEHMN8Q9RWuwyc6EhO/LSDXfjiqC4Gw7HXZlUtfqPK7GqBOyyE gb5w== 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; bh=LZEMj49FWO8HoMJy4cghaH7ao5kJeQPnaGIAaI2DG/E=; b=jBrNHcCmlCZdKdESxQC9RcyLwfyA4V8NGcyUV/VdHOA2vTWTI8IiHLXnb0QqeptMuh GoyIoG8m1WcjI5MHsgMK/8aict++vHChC8jGtyRiFSf+M49+PWGyrg+X04ioSmeVK7BA 9K2rwDcAnmKpL8iRIcxMBvhNSJPwdJc80T8igBP6lfG9Ec7L7s8o0Qalgr2qtaRfVS89 NotoMpbf8559U9vxlzkU02wCJTR1RrjxUjGvkb3ofTl9FRRZtPFXpJIbRry+DLjOc2T6 msEnv7viEEQb0ARGdkM77+Il1ia75i4TLGc7p8ovQ5TkN8E8485oIXgjOzDjq1RiMWzb 2i0w== X-Gm-Message-State: AD7BkJJOnV9SATKkYPRwpHVk1RGZ7GvIZKV3IFDbu34NamU3w0hP3/e+/zaRurQLkFQBCYMZQ9Ph8+n877SCGw== MIME-Version: 1.0 X-Received: by 10.25.138.7 with SMTP id m7mr6118202lfd.109.1458920607016; Fri, 25 Mar 2016 08:43:27 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Fri, 25 Mar 2016 08:43:26 -0700 (PDT) In-Reply-To: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> Date: Fri, 25 Mar 2016 20:13:26 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: Adrian Chadd Cc: David Chisnall , Damjan Jovanovic , emulation@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 15:43:29 -0000 Adrian, thanks for your +1 :P So, what about EULA related things that 'David' pointed to? If this isn't really a big problem, I have no problem to continue on working on it, an FatELF both ;) From owner-freebsd-current@freebsd.org Fri Mar 25 17:33:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2389AADDBE0 for ; Fri, 25 Mar 2016 17:33:03 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D99941AC3 for ; Fri, 25 Mar 2016 17:33:02 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: by mail-vk0-x232.google.com with SMTP id e185so97417897vkb.1 for ; Fri, 25 Mar 2016 10:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brilliantservice-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=X4SK8Js1Wxni4t9xonU355X1YTz3GOQjfmfPq+V1H3g=; b=LLasppZVlXjINF9fNanzp6gFeVN38wAv339btzTdCGR0UJW3CgQrNnhCOmkQRMlSAz XK7ZI41vbT/lfiiGQjXJ8rqxdnVh2ygFTI4/jhFDyB7LUa7FmPC10nHjd7X4yHJXvCe4 uQGFMa4WdiXlYIWirbvuE1FxQrQZDrlphn4y4MswuCOL2XHWjMb5kHwsxbWhOXoxqQFF pKpCt2I3u5ASW5CmFrO6wUHlu/l2tU+WnAZ2DW4taGHQxIL7xXYU1dzpDU2gMnyvYN4p Gu1ZDdaXj/FaOW+rUZiU021fPRfDKmn8o+GNRlhc9iM4dY1ExHi6V7s7efDb5G/Pln7Y 3keQ== 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; bh=X4SK8Js1Wxni4t9xonU355X1YTz3GOQjfmfPq+V1H3g=; b=R89IrJE3SzXsaTCq6KAHd7w8IhLNaqVRMesqRlhWdaEQqEmQAUyYFL2J7OKMFNST8A oebdLSgHbQ4lr3+Uo6YLr8C4yploiRWYDXEkZ5rD/4rWj90Fy3h81kgirJjrVskuVTvB QavAw3aV8uH7jt7boUVnIJJn4jF0XzPk0/P/nIf9dWLk4qck+FOxNCAUq5kZV/xO3SNL MH4mOqGrMszowHQdl2CImXWMK62das/rzdZcgiBMMQGYQUoH1f1rSmNwpyHhHkVPu/2h 1gchBVJIGxd8siCLlYD8uNvcvndnv0PkTOEKRHK/COqRUBzMPlqlOPdH/hw7VuuB6cZN c7pw== X-Gm-Message-State: AD7BkJKmt90k242XvKZpuJRSI1ZO4D37+jfJk7q3nBO2teSr2xaIN+e5voeUXm7SxHz0SUOhrLxRC42YWwu0S4DE+cct51OJX3Q3lOPsN1kCwf18qoIcp7fNvz66uM0dz2hW+afHD+mRDybzN3T60sXaBOo= X-Received: by 10.31.16.38 with SMTP id g38mr7824874vki.105.1458927181798; Fri, 25 Mar 2016 10:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.197 with HTTP; Fri, 25 Mar 2016 10:32:47 -0700 (PDT) In-Reply-To: <20160325110501.GN24170@e-new.0x20.net> References: <1458846365.574939838@f173.i.mail.ru> <20160325110501.GN24170@e-new.0x20.net> From: "Lundberg, Johannes" Date: Fri, 25 Mar 2016 10:32:47 -0700 Message-ID: Subject: Re: question on support processor Intel Atom Z3735F To: Lars Engels , =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 17:33:03 -0000 T25lIHByb2JsZW0gaXMgdGhhdCBtb3N0IG9mIHRoZXNlIGRldmljZXMgaGF2ZSBvbmx5IDMyIGJp dCBVRUZJIHdoaWNoDQpGcmVlQlNEIGRvZXMgbm90IHN1cHBvcnQgKGV4Y2VwdCBJbnRlbCBDb21w dXRlIFN0aWNrIHdoaWNoIGhhcyA2NCBiaXQgVUVGSSkuDQpJIHVzZSBzcGVjaWFsIGJ1aWx0IEdy dWIgdG8gYm9vdCBhIDY0IGJpdCBBcmNoIExpbnV4IG9uIHRoaXMgY2hpcCwgbWF5YmUNCnNhbWUg YXBwcm9hY2ggY291bGQgYmUgdXNlZCB0byBib290IGEgNjQgYml0IEZyZWVCU0QuIEhvd2V2ZXIs IHlvdSBwcm9iYWJseQ0Kd29uJ3QgYmUgYWJsZSB0byB1c2UgdGhlIGludGVybmFsIGVNTUMgKGlm IHlvdXIgZGV2aWNlIGdvdCBpdCkgc2luY2UgdGhlDQpjb250cm9sbGVyIGNhbiBub3QgaW5pdGlh dGUgbW1jIG1lbW9yeSBjb3JyZWN0bHkuIFdvcmsgaW4gcHJvZ3Jlc3MgaGVyZQ0KdGhvdWdoIGJ5 IG1lIGFuZCBJbHlhLg0KDQpPbiBhIHNpZGUgbm90ZSwNCml0IHdvdWxkIHRob3VnaCBiZSBuaWNl IHRvIGhhdmUgMzIgYml0IFVFRkkgc3VwcG9ydCBvbiBGcmVlQlNEIGJlY2F1c2UgdGhhdA0Kd291 bGQgaW5jbHVkZSBzdXBwb3J0IGZvciBJbnRlbCBJb1QgYm9hcmRzIGxpa2UgR2FsaWxlbyBldGMg d2hpY2ggYXJlIGFsbA0KMzIgYml0LiBNaWdodCBiZSBhIGxvdCBvZiB3b3JrIHRob3VnaC4uDQoN Cg0KLS0NCk5hbWU6ICAgICBKb2hhbm5lcyBMdW5kYmVyZw0KUG9zaXRpb246IE1pcmFtYSBwcm9q ZWN0IGxlYWRlcg0KUGhvbmU6ICAgICsxLTQwOC02MzYtMjE2MQ0KU2t5cGU6ICAgIGJyaWxsaWFu dGpvaGFubmVzDQpPbmxpbmU6ICAgTGlua2VkSW4gPGh0dHA6Ly9qcC5saW5rZWRpbi5jb20vaW4v bHVuZGJlcmdqb2hhbm5lcz4gRmFjZWJvb2sNCjxodHRwczovL3d3dy5mYWNlYm9vay5jb20vbWly YW1hb25lPiBSZWRkaXQNCjxodHRwczovL3d3dy5yZWRkaXQuY29tL3VzZXIveW9oYW5lc3U3NS8+ IFR3aXR0ZXINCjxodHRwczovL3R3aXR0ZXIuY29tL1lvaGFuZXN1NzVUd2VldD4gR2l0SHViIDxo dHRwczovL2dpdGh1Yi5jb20veW9oYW5lc3U3NT4NCkdpdExhYiA8aHR0cHM6Ly9naXRsYWIuY29t L3Uvam9oYW5uZXNfbHVuZGJlcmc+DQpDb21wYW55OiAgTWlyYW1hIDxodHRwOi8vbWlyYS5tYT4g QnJpbGxpYW50c2VydmljZSBVUw0KPGh0dHA6Ly93d3cuYnJpbGxpYW50c2VydmljZXVzYS5jb20+ IEJyaWxsaWFudHNlcnZpY2UgSlANCjxodHRwOi8vd3d3LmJyaWxsaWFudHNlcnZpY2UuY28uanA+ DQoNCk9uIEZyaSwgTWFyIDI1LCAyMDE2IGF0IDQ6MDUgQU0sIExhcnMgRW5nZWxzIDxsYXJzLmVu Z2Vsc0AweDIwLm5ldD4gd3JvdGU6DQoNCj4gT24gVGh1LCBNYXIgMjQsIDIwMTYgYXQgMTA6MDY6 MDVQTSArMDMwMCwg0JLQu9Cw0LTQuNC80LjRgCB3cm90ZToNCj4gPiAgSGVsbG8sIHBsZWFzZSB0 ZWxsIG1lIHdoZXRoZXIgdGhlIEZyZWVCU0Qgb3BlcmF0aW5nIHN5c3RlbSBJbnRlbCBBdG9tDQo+ ID4gIFozNzM1Rj8gV2hpY2ggZGlzdHJpYnV0aW9uIEkgbmVlZCB0byBkb3dubG9hZD8NCj4NCj4N Cj4gVGhlIENQVSBzdXBwb3J0cyBhbWQ2NCBidXQgQUZBSUsgdGhlIEJheXRyYWlsIGFyY2hpdGVj dHVyZSBvbmx5IHN1cHBvcnRzIGENCj4gMzItYml0IFVFRkkuIFNvIHlvdSBuZWVkIHRvIGNyZWF0 ZSB5b3VyIG93biBib290IG1lZGl1bS4NCj4NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8 muOBk+OBrumbu+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOB ruOBp+OBguOCiuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OC k+OBp+OBhOOBvuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6Hj gZXjgozjgZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPj ga7jg6Hjg7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD 44CB44Gd44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP 44GE44GL44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK 44GS44G+44GZ44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGlu IHRoaXMgZW1haWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWUuCkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIg YWN0aW9uIG9mIHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVk IHJlY2lwaWVudCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBhbmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVz dHJveSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4K From owner-freebsd-current@freebsd.org Fri Mar 25 18:31:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A740ADDB15 for ; Fri, 25 Mar 2016 18:31:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (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 41C681A2E for ; Fri, 25 Mar 2016 18:31:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ec75:112a:3512:fd5] (unknown [IPv6:2001:7b8:3a7:0:ec75:112a:3512:fd5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B2527239AF; Fri, 25 Mar 2016 19:31:03 +0100 (CET) Subject: Re: failed to compile base, buldworld, with -Os CFLAGS Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_820F6747-B99A-4F4B-B591-913DBF59F6B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: Date: Fri, 25 Mar 2016 19:30:55 +0100 Cc: freebsd-current Message-Id: References: To: Eric Camachat X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 18:31:06 -0000 --Apple-Mail=_820F6747-B99A-4F4B-B591-913DBF59F6B6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 25 Mar 2016, at 05:21, Eric Camachat wrote: > > I tried to buildworld with -Os CFLAGS, but it failed. ... > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > cc: note: diagnostic msg: /tmp/fnmatch-87dc57.c > (http://slexy.org/view/s2ddVhTTyQ) > cc: note: diagnostic msg: /tmp/fnmatch-87dc57.sh > (http://slexy.org/view/s21zeFmDPU) Thanks for the report. This also happens with llvm trunk, so I have submitted a bug with a reduced test case upstream: https://llvm.org/bugs/show_bug.cgi?id=27071 In the mean time, please use -O1 or -O2 to build world, as a workaround. -Dimitry --Apple-Mail=_820F6747-B99A-4F4B-B591-913DBF59F6B6 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.29 iEYEARECAAYFAlb1g+cACgkQsF6jCi4glqMmPwCff5Y2IK/uQFn7sB+bRA7EBzkm OdMAoPA12Uk2kDj/KrRgBG4+cnOI1PQZ =3vqi -----END PGP SIGNATURE----- --Apple-Mail=_820F6747-B99A-4F4B-B591-913DBF59F6B6-- From owner-freebsd-current@freebsd.org Fri Mar 25 18:33:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06953ADDC91 for ; Fri, 25 Mar 2016 18:33:23 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DA2D61D56 for ; Fri, 25 Mar 2016 18:33:22 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D5830ADDC8F; Fri, 25 Mar 2016 18:33:22 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4D60ADDC8B; Fri, 25 Mar 2016 18:33:22 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A4A11D53; Fri, 25 Mar 2016 18:33:22 +0000 (UTC) (envelope-from mokhi64@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id q73so56987274lfe.2; Fri, 25 Mar 2016 11:33:22 -0700 (PDT) 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; bh=jDBDi71HXpO8Gb35sV/EhmrcCaHAqeO+CZdApqPG9Pc=; b=yR06jO6l/+6vDG0gxgICtq0Qt/82gH4BaBWPMDYtBKnXLd9HLHfw4MTJYBmgfFtvSz QHR0zNz2HXylZph7BpTqxjkTeMt5P4SjUGW0pBQKVRbFoLJC2jG0CtdhbTbqbYClypDj I4Y1rm+oIyTBmcI0fFe39aH6OFkvNy023hbVLR2TvFRHdR7xSGN2mZXpsm1KJbekbppS lrq37ukigIcCimBxZQ/I5eR8fzogbxJ3HHhj8J2KSva0cteb3nDejug8zCeS5B/2C/U0 JoyaD60TqRlcFrADYK4myfC6XIBazP+tG0Hkhg97Cr79iq43jcyKu/z12PnAa6CHv1zB 2/kg== 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; bh=jDBDi71HXpO8Gb35sV/EhmrcCaHAqeO+CZdApqPG9Pc=; b=Bh3J1mnh3bUaVjHEwsncMI9v4MigZfkMj/tgkUlAga94yg2p+jAWNrX02lHCeqIyj+ TyVs0Tjl+9pVGAYQN3uHsmYmuvC0i1BWcofe+Cub5TCmrP9YB+ircNH5Z1b8B+Cx+pYo LloJ6EKvjETgzdmyW2nCLKqa5JbeIT8SUUCWi3VA1Ic8oVQs3IGEB7jfXdb40fqo9fNJ DNNSDCBTBOI8w3LoySJ/5q+ftVfWr89gitsFts+BYoX72Tnq4D/CJix/n9wr70xENpOh gGKmvu5TYUpci4QU675//DuSenq++tw/9u5CxZHV4kkNSSthovz12dq7bBO/v5YqwvCS c4jQ== X-Gm-Message-State: AD7BkJJ0t2Xgj3HDAcvp+imUxFdZYeOnXmwZPVrLY+jYN0exKrsQRtPHzj4c3mmKnLyx5/Of17WOIpiqEEpw3w== MIME-Version: 1.0 X-Received: by 10.25.138.7 with SMTP id m7mr6360542lfd.109.1458930800737; Fri, 25 Mar 2016 11:33:20 -0700 (PDT) Received: by 10.25.139.68 with HTTP; Fri, 25 Mar 2016 11:33:20 -0700 (PDT) In-Reply-To: References: <7554521E-81AB-43DE-A7FC-A9F334F660B7@FreeBSD.org> <097363D7-DB74-4C48-90A7-BFACB1E0C0E1@FreeBSD.org> Date: Fri, 25 Mar 2016 23:03:20 +0430 Message-ID: Subject: Re: FreeBSD MachO File format, your comments on it. From: mokhi To: Adrian Chadd Cc: David Chisnall , Damjan Jovanovic , emulation@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 18:33:23 -0000 errr, typo ... s/an FatELF both/and FatELF both/g :) On 3/25/16, mokhi wrote: > Adrian, thanks for your +1 :P > > So, what about EULA related things that 'David' pointed to? > If this isn't really a big problem, I have no problem to continue on > working on it, an FatELF both ;) > From owner-freebsd-current@freebsd.org Fri Mar 25 18:47:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2969DADDEE5 for ; Fri, 25 Mar 2016 18:47:24 +0000 (UTC) (envelope-from wblock@wonkity.com) 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 DC70E129A for ; Fri, 25 Mar 2016 18:47:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u2PIl9FM039045 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Mar 2016 12:47:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u2PIl9Ni039042; Fri, 25 Mar 2016 12:47:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 Mar 2016 12:47:09 -0600 (MDT) From: Warren Block To: "Lundberg, Johannes" cc: Lars Engels , =?KOI8-R?B?98zBxMnNydI=?= , FreeBSD Current Subject: Re: question on support processor Intel Atom Z3735F In-Reply-To: Message-ID: References: <1458846365.574939838@f173.i.mail.ru> <20160325110501.GN24170@e-new.0x20.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 25 Mar 2016 12:47:09 -0600 (MDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 18:47:24 -0000 On Fri, 25 Mar 2016, Lundberg, Johannes wrote: > One problem is that most of these devices have only 32 bit UEFI which > FreeBSD does not support (except Intel Compute Stick which has 64 bit UEFI). The MinnowBoard has both 32-bit and 64-bit UEFI. My Turbot came with 64-bit UEFI, and the FreeBSD amd64 UEFI install image works fine with it. This is an Atom E3826 board. > I use special built Grub to boot a 64 bit Arch Linux on this chip, maybe > same approach could be used to boot a 64 bit FreeBSD. However, you probably > won't be able to use the internal eMMC (if your device got it) since the > controller can not initiate mmc memory correctly. Work in progress here > though by me and Ilya. > > On a side note, > it would though be nice to have 32 bit UEFI support on FreeBSD because that > would include support for Intel IoT boards like Galileo etc which are all > 32 bit. Might be a lot of work though.. If any existing 32-bit Linux UEFI loader could be made to work with FreeBSD (possibly chainloading?), that would be better than nothing. I would like to have the opposite method also, having a 64-bit UEFI boot a 32-bit FreeBSD. (Why? So my run-on-anything 32-bit FreeBSD image could still work on any UEFI system.) From owner-freebsd-current@freebsd.org Fri Mar 25 20:30:03 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98D9ADDA4F for ; Fri, 25 Mar 2016 20:30:03 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 B1772180B for ; Fri, 25 Mar 2016 20:30:02 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ajYMq-000P4C-TJ>; Fri, 25 Mar 2016 21:30:00 +0100 Received: from x5ce12f54.dyn.telefonica.de ([92.225.47.84] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1ajYMq-000CwX-KL>; Fri, 25 Mar 2016 21:30:00 +0100 Date: Fri, 25 Mar 2016 21:30:25 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT slow and shaky network stability Message-ID: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 92.225.47.84 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 20:30:04 -0000 Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD 11.0-CURRENT #9 r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and like "glue": it is slow with X11, sometimes ssh connections even nearby hosts on the same net not under load have some time to respond to keys in xterm or on console (vt()) ~ 1 - 3 seconds and I receive very often "broken pipe" to ssh connections to a host nearby. I realized this strange behaviour on a couple of systems a maintain running most recent CURRENT. I also realize a high usage of swap on a 8GB RAM, 2 core box having two ZFS volumes (one 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia 364.12/355.11 driver, I checked on both) and running desktop only (windowmaker) brings the system toward using 12 or sometimes several hundreds of megabytes of swap - and I do not see what is using so much space. Does anyone also realize this phenomenon? Regards, oh From owner-freebsd-current@freebsd.org Fri Mar 25 20:31:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14668ADDABF for ; Fri, 25 Mar 2016 20:31:32 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2EDA1ADD for ; Fri, 25 Mar 2016 20:31:31 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ig0-x233.google.com with SMTP id cl4so18603349igb.0 for ; Fri, 25 Mar 2016 13:31:31 -0700 (PDT) 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; bh=LPwV9kHcGfuO0WH8EX8/SRXIHSNHh2cd+R0awcbaVlQ=; b=S6tJv3kZ8Eqtnja8lsv+faELWPLK7SwGrprwd3g86EZNa+czSr0injOZvoTM1bq5zd OuiujA9xGXF3d8EsMS0cJzK5PXGrZXSivpHwS99Nap7O5OpOyyciBBbBCTmh9VMkey50 1C42E3cxvTX62diob9NqT2FKZVnMOMurxPre7GBfmF7hlKJhvsTOdRxtK1bnPGgf+M6a m7hR4I5munr7JR3lgglg6kf+3PlLDwPNGDnFVas5SQwbTjAa5cptfk2VrDhxuKoKr7b/ AZd+hogdJXWtgoKL89FBTLdyR2s3MeXB9qBqPU8oQ2yM8ukOrt6dlSW7qh5xqiNtioyn Rvfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LPwV9kHcGfuO0WH8EX8/SRXIHSNHh2cd+R0awcbaVlQ=; b=W6T2fZyuFPADFsj4j8YYQ5YQJG7El35zcZeAAgr/bj1Vkshviiiifz41/NAOfwYxZT hrOZJNYEcpCkW55B6vmLTaPmPTjBb4y0J8r1NlWFyC4GceU1lf3BfhIS6Iey+CeT85z/ V+02vHPxeugY1OCmCDld5is1vmRrLihAZuc17fM6tEZcQbmomRMT6ehGEaLAV8WLLgqu VhzuXSrEu3EqsoJL6BOiiuruHKdyKBjLYZvHLkd6GyfJeBJTRdDBEPvPuzk79ma/q0uz 2b+GXEZ6yv/FofIaAY/qjtwiph6x8GIKz3H9WlXlKMW3WSJcAKplgwqixXqbAN+3T1uE GD6Q== X-Gm-Message-State: AD7BkJJs7j52JRdx0gOIARvSkiXTP04FjvUHqxWo+Rnp7Vt5qRKNeI+OeUtfLW6Xib+aqrBGBlwjFQx99XxMzw== MIME-Version: 1.0 X-Received: by 10.50.67.39 with SMTP id k7mr384617igt.76.1458937891212; Fri, 25 Mar 2016 13:31:31 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.143.75 with HTTP; Fri, 25 Mar 2016 13:31:31 -0700 (PDT) In-Reply-To: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> Date: Fri, 25 Mar 2016 13:31:31 -0700 X-Google-Sender-Auth: pTZ9u4Dpd8SJ1nos3jtAkmselW0 Message-ID: Subject: Re: CURRENT slow and shaky network stability From: "K. Macy" To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 20:31:32 -0000 Does this pre or postage input changes? On Friday, March 25, 2016, O. Hartmann wrote: > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD > 11.0-CURRENT #9 > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and > like "glue": it > is slow with X11, sometimes ssh connections even nearby hosts on the same > net not under > load have some time to respond to keys in xterm or on console (vt()) ~ 1 - > 3 seconds and > I receive very often "broken pipe" to ssh connections to a host nearby. I > realized this > strange behaviour on a couple of systems a maintain running most recent > CURRENT. > > I also realize a high usage of swap on a 8GB RAM, 2 core box having two > ZFS volumes (one > 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia > 364.12/355.11 driver, I > checked on both) and running desktop only (windowmaker) brings the system > toward using 12 > or sometimes several hundreds of megabytes of swap - and I do not see what > is using so > much space. > > Does anyone also realize this phenomenon? > > Regards, > > oh > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > From owner-freebsd-current@freebsd.org Fri Mar 25 20:34:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34929ADDC28 for ; Fri, 25 Mar 2016 20:34:14 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5CC1CCF for ; Fri, 25 Mar 2016 20:34:14 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B0E5411C4 for ; Fri, 25 Mar 2016 20:34:13 +0000 (UTC) (envelope-from rm@FreeBSD.org) To: FreeBSD Current From: Ruslan Makhmatkhanov Subject: SD card adapter doesn't working anymore Message-ID: <56F5A0A9.8030207@FreeBSD.org> Date: Fri, 25 Mar 2016 23:33:45 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 20:34:14 -0000 Hello, I have this in pciconf output: ====================================================================== none1@pci0:36:0:0: class=0x088000 card=0x167e103c chip=0x2392197b rev=0x30 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'SD/MMC Host Controller' class = base peripheral none2@pci0:36:0:3: class=0x088000 card=0x167e103c chip=0x2393197b rev=0x30 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'MS Host Controller' class = base peripheral ====================================================================== And my SD-card controller is not working anymore (it worked on -current on the same laptop year or two ago). Do I need to load some kld to make it working, or support for this controllers was dropped altogether for some reason? I have mostly vanilla GENERIC at r296772, but it actually stopped to work much earlier. Thanks. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 25 20:58:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BA3EADE1B1 for ; Fri, 25 Mar 2016 20:58:35 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 2DDA118A6 for ; Fri, 25 Mar 2016 20:58:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5fa0a161-f2cc-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 25 Mar 2016 20:58:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2PKwX49019780; Fri, 25 Mar 2016 14:58:33 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458939512.1091.79.camel@freebsd.org> Subject: Re: SD card adapter doesn't working anymore From: Ian Lepore To: Ruslan Makhmatkhanov , FreeBSD Current Date: Fri, 25 Mar 2016 14:58:32 -0600 In-Reply-To: <56F5A0A9.8030207@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 20:58:35 -0000 On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: > Hello, > > I have this in pciconf output: > > ===================================================================== > = > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > chip=0x2392197b > rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'SD/MMC Host Controller' > class = base peripheral > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > chip=0x2393197b > rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'MS Host Controller' > class = base peripheral > ===================================================================== > = > > And my SD-card controller is not working anymore (it worked on > -current > on the same laptop year or two ago). Do I need to load some kld to > make > it working, or support for this controllers was dropped altogether > for > some reason? I have mostly vanilla GENERIC at r296772, but it > actually > stopped to work much earlier. > > Thanks. > This is probably my fault, introduced with r292180 in December, and fixed a few days ago with r297127; sorry about that. Updating should get you running again. Unfortunately you can't fix it just by pre-loading the right modules, because part of the problem was a missing MODULE_DEPENDS() that helps the kernel linker resolve symbols between different modules. -- Ian From owner-freebsd-current@freebsd.org Fri Mar 25 21:00:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1ADAADE248 for ; Fri, 25 Mar 2016 21:00:30 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv25.fwdcdn.com (frv25.fwdcdn.com [212.42.77.25]) by mx1.freebsd.org (Postfix) with ESMTP id 87E981AE0; Fri, 25 Mar 2016 21:00:30 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from [10.10.14.26] (helo=frv157.fwdcdn.com) by frv25.fwdcdn.com QID:1ajYYL-000J4E-VH/RC:2; Fri, 25 Mar 2016 22:41:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=kmWQHTZEob6giG+6J9V3G1M5Zl8mP0RGK89AVDoZpoI=; b=RxfqlncS7MGT1p5J3vOxqIWOoJVub/CMJjh97BnZPAdwIQCWxNdQgC5F4YNLRP5Rb7clKB8GndqJb7bfzN7Gy3Lz6yTQA9vsSa2AWmyD5p+RpDVTujJSddb6314kGzw9ht8R5iJyJrDxYZCsFSfWtbIQ4GG7BeF1W00bEFE1tI0=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1ajYYE-0002kp-2l ; Fri, 25 Mar 2016 22:41:46 +0200 Date: Fri, 25 Mar 2016 22:41:45 +0200 From: Ivan Klymenko To: Ruslan Makhmatkhanov Cc: FreeBSD Current Subject: Re: SD card adapter doesn't working anymore Message-ID: <20160325224145.2f319ead@nonamehost.local> In-Reply-To: <56F5A0A9.8030207@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:00:30 -0000 On Fri, 25 Mar 2016 23:33:45 +0300 Ruslan Makhmatkhanov wrote: > Hello, > > I have this in pciconf output: > > ====================================================================== > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > chip=0x2392197b rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'SD/MMC Host Controller' > class = base peripheral > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > chip=0x2393197b rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'MS Host Controller' > class = base peripheral > ====================================================================== > > And my SD-card controller is not working anymore (it worked on > -current on the same laptop year or two ago). Do I need to load some > kld to make it working, or support for this controllers was dropped > altogether for some reason? I have mostly vanilla GENERIC at r296772, > but it actually stopped to work much earlier. > > Thanks. > +1 I would also like to clarify about this problem was drawn up a bug report. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 Thanks. From owner-freebsd-current@freebsd.org Fri Mar 25 21:01:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99595ADE34C for ; Fri, 25 Mar 2016 21:01:09 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7651C8D; Fri, 25 Mar 2016 21:01:09 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id DD21119DE; Fri, 25 Mar 2016 21:01:08 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458939512.1091.79.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F5A6F8.3040904@FreeBSD.org> Date: Sat, 26 Mar 2016 00:00:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458939512.1091.79.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:01:09 -0000 Ian Lepore wrote on 03/25/16 11:58 PM: > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >> Hello, >> >> I have this in pciconf output: >> >> ===================================================================== >> = >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ===================================================================== >> = >> >> And my SD-card controller is not working anymore (it worked on >> -current >> on the same laptop year or two ago). Do I need to load some kld to >> make >> it working, or support for this controllers was dropped altogether >> for >> some reason? I have mostly vanilla GENERIC at r296772, but it >> actually >> stopped to work much earlier. >> >> Thanks. >> > > This is probably my fault, introduced with r292180 in December, and > fixed a few days ago with r297127; sorry about that. Updating should > get you running again. > > Unfortunately you can't fix it just by pre-loading the right modules, > because part of the problem was a missing MODULE_DEPENDS() that helps > the kernel linker resolve symbols between different modules. > > -- Ian Thank you! Will try. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 25 21:05:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F369CADE401 for ; Fri, 25 Mar 2016 21:05:42 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E8F131F94; Fri, 25 Mar 2016 21:05:42 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 0DDFE1AC7; Fri, 25 Mar 2016 21:05:41 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ivan Klymenko References: <56F5A0A9.8030207@FreeBSD.org> <20160325224145.2f319ead@nonamehost.local> Cc: FreeBSD Current , Ian Lepore From: Ruslan Makhmatkhanov Message-ID: <56F5A809.2020505@FreeBSD.org> Date: Sat, 26 Mar 2016 00:05:13 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160325224145.2f319ead@nonamehost.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:05:43 -0000 Ivan Klymenko wrote on 03/25/16 11:41 PM: > On Fri, 25 Mar 2016 23:33:45 +0300 > Ruslan Makhmatkhanov wrote: > >> Hello, >> >> I have this in pciconf output: >> >> ====================================================================== >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ====================================================================== >> >> And my SD-card controller is not working anymore (it worked on >> -current on the same laptop year or two ago). Do I need to load some >> kld to make it working, or support for this controllers was dropped >> altogether for some reason? I have mostly vanilla GENERIC at r296772, >> but it actually stopped to work much earlier. >> >> Thanks. >> > > +1 > I would also like to clarify about this problem was drawn up a bug > report. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 > > Thanks. Hah, I even see my comment from 2014 in this PR. So looks like it was broken not in r292180 as Ian pointed, but much-much earlier. Anyway, I'll try to update to fresh -current first. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 25 21:11:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65055ADE6E2 for ; Fri, 25 Mar 2016 21:11:19 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 C7BDA1308; Fri, 25 Mar 2016 21:11:18 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Lxkmz5pMCYRMl1rzVKGwEvhXeynks6yK4xrKL/x+734=; b=NBWDfFxhZ6z4PCrrTPFYjmta2Dpev1L+XklqK66l0D2DoMMOhaaJ7i6Dx5iNuOxvKbaGa/v27GEQEeJm82uGaMj2gpoAtqHR2SQIbe8gZuQCiUyKXs9ftggL0ZRlnku+f8L9+VOJXOCnJDk2IKVk4quKycqUNCIeQVcBT3Um7Pk=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1ajZ0m-000Btt-4W ; Fri, 25 Mar 2016 23:11:16 +0200 Date: Fri, 25 Mar 2016 23:11:15 +0200 From: Ivan Klymenko To: Ruslan Makhmatkhanov Cc: FreeBSD Current , Ian Lepore Subject: Re: SD card adapter doesn't working anymore Message-ID: <20160325231115.3752fe53@nonamehost.local> In-Reply-To: <56F5A809.2020505@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> <20160325224145.2f319ead@nonamehost.local> <56F5A809.2020505@FreeBSD.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:11:19 -0000 On Sat, 26 Mar 2016 00:05:13 +0300 Ruslan Makhmatkhanov wrote: > Ivan Klymenko wrote on 03/25/16 11:41 PM: > > On Fri, 25 Mar 2016 23:33:45 +0300 > > Ruslan Makhmatkhanov wrote: > > > >> Hello, > >> > >> I have this in pciconf output: > >> > >> ====================================================================== > >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c > >> chip=0x2392197b rev=0x30 hdr=0x00 > >> vendor = 'JMicron Technology Corp.' > >> device = 'SD/MMC Host Controller' > >> class = base peripheral > >> > >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c > >> chip=0x2393197b rev=0x30 hdr=0x00 > >> vendor = 'JMicron Technology Corp.' > >> device = 'MS Host Controller' > >> class = base peripheral > >> ====================================================================== > >> > >> And my SD-card controller is not working anymore (it worked on > >> -current on the same laptop year or two ago). Do I need to load > >> some kld to make it working, or support for this controllers was > >> dropped altogether for some reason? I have mostly vanilla GENERIC > >> at r296772, but it actually stopped to work much earlier. > >> > >> Thanks. > >> > > > > +1 > > I would also like to clarify about this problem was drawn up a bug > > report. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 > > > > Thanks. > > Hah, I even see my comment from 2014 in this PR. I have it broken just from that moment to this day. uname -a FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r297234: Thu Mar 24 15:15:39 EET 2016 ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11 amd64 > So looks like it was > broken not in r292180 as Ian pointed, but much-much earlier. Anyway, > I'll try to update to fresh -current first. > From owner-freebsd-current@freebsd.org Fri Mar 25 21:34:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B02F0ADEA53 for ; Fri, 25 Mar 2016 21:34:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 966AE1E36 for ; Fri, 25 Mar 2016 21:34:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 3c5cb1a8-f2d1-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 25 Mar 2016 21:33:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2PLXw3E019897; Fri, 25 Mar 2016 15:33:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458941638.1091.82.camel@freebsd.org> Subject: Re: SD card adapter doesn't working anymore From: Ian Lepore To: Ivan Klymenko , Ruslan Makhmatkhanov Cc: FreeBSD Current Date: Fri, 25 Mar 2016 15:33:58 -0600 In-Reply-To: <20160325231115.3752fe53@nonamehost.local> References: <56F5A0A9.8030207@FreeBSD.org> <20160325224145.2f319ead@nonamehost.local> <56F5A809.2020505@FreeBSD.org> <20160325231115.3752fe53@nonamehost.local> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:34:06 -0000 On Fri, 2016-03-25 at 23:11 +0200, Ivan Klymenko wrote: > On Sat, 26 Mar 2016 00:05:13 +0300 > Ruslan Makhmatkhanov wrote: > > > Ivan Klymenko wrote on 03/25/16 11:41 PM: > > > On Fri, 25 Mar 2016 23:33:45 +0300 > > > Ruslan Makhmatkhanov wrote: > > > > > > > Hello, > > > > > > > > I have this in pciconf output: > > > > > > > > =============================================================== > > > > ======= > > > > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > > > > chip=0x2392197b rev=0x30 hdr=0x00 > > > > vendor = 'JMicron Technology Corp.' > > > > device = 'SD/MMC Host Controller' > > > > class = base peripheral > > > > > > > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > > > > chip=0x2393197b rev=0x30 hdr=0x00 > > > > vendor = 'JMicron Technology Corp.' > > > > device = 'MS Host Controller' > > > > class = base peripheral > > > > =============================================================== > > > > ======= > > > > > > > > And my SD-card controller is not working anymore (it worked on > > > > -current on the same laptop year or two ago). Do I need to load > > > > some kld to make it working, or support for this controllers > > > > was > > > > dropped altogether for some reason? I have mostly vanilla > > > > GENERIC > > > > at r296772, but it actually stopped to work much earlier. > > > > > > > > Thanks. > > > > > > > > > > +1 > > > I would also like to clarify about this problem was drawn up a > > > bug > > > report. > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 > > > > > > Thanks. > > > > Hah, I even see my comment from 2014 in this PR. > > I have it broken just from that moment to this day. > uname -a > FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > r297234: > Thu Mar 24 15:15:39 EET 2016 > ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11 amd64 > > > > So looks like it was > > broken not in r292180 as Ian pointed, but much-much earlier. > > Anyway, > > I'll try to update to fresh -current first. > > That PR has a very small range, r271081-138, but I don't any changes in that range related to sdhci, or to pci. The PR doesn't say anything about how the device "doesn't work". Does the sdhci device show up in dmesg, but the sd card is never detected, or does sdhci not even attach? -- Ian From owner-freebsd-current@freebsd.org Fri Mar 25 21:49:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AB0BADECDF for ; Fri, 25 Mar 2016 21:49:42 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (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 0C34613F0 for ; Fri, 25 Mar 2016 21:49:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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 E55CF25D386D; Fri, 25 Mar 2016 21:49:38 +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 05C75C79D4D; Fri, 25 Mar 2016 21:49: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 VReII0cJydtW; Fri, 25 Mar 2016 21:49:36 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8A936C79D2F; Fri, 25 Mar 2016 21:49:36 +0000 (UTC) Date: Fri, 25 Mar 2016 21:49:36 +0000 (UTC) From: "Bjoern A. Zeeb" To: Guy Yur cc: freebsd-current Subject: Re: panic "wlock already held" when changing ipv6 default route In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 21:49:42 -0000 On Fri, 25 Mar 2016, Guy Yur wrote: > Hi, > > When changing the ipv6 default route I get a panic on wlock already held. > Could be related to r293424 lock changes, haven't checked an older version yet. > > route add -inet6 default fe80::7 > route change -inet6 default fe80::7 Hmm undependent of the bug these are link-local addresses and should have a % at the end, right? /bz From owner-freebsd-current@freebsd.org Fri Mar 25 22:04:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9415ADD135 for ; Fri, 25 Mar 2016 22:04:29 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv157.fwdcdn.com (frv157.fwdcdn.com [212.42.77.157]) (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 7DB1F1057; Fri, 25 Mar 2016 22:04:28 +0000 (UTC) (envelope-from fidaj@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=rA3lEufhe1XCewynU8RMbk5M+0CYkiRBLsBQB/SAfFs=; b=pxfWdzCk1bfML4PBpPgf3HuZECNiKnFTiAwz1b7xOCUL+TChYdQPEcB8KZH3ytRpkVJiRbdnOMHh0+fjo7+sytkGy4n3V1KcFATUYkCArvygPI/Ho/jYcdwz7087c426umpEW2IyIhbO0X5aJZSfjapb+qkDvCCtEX9mr6guYU8=; Received: from [37.229.193.176] (helo=nonamehost.local) by frv157.fwdcdn.com with esmtpsa ID 1ajZqE-0000qU-3g ; Sat, 26 Mar 2016 00:04:26 +0200 Date: Sat, 26 Mar 2016 00:04:25 +0200 From: Ivan Klymenko To: Ian Lepore Cc: Ruslan Makhmatkhanov , FreeBSD Current Subject: Re: SD card adapter doesn't working anymore Message-ID: <20160326000425.2013a74f@nonamehost.local> In-Reply-To: <1458941638.1091.82.camel@freebsd.org> References: <56F5A0A9.8030207@FreeBSD.org> <20160325224145.2f319ead@nonamehost.local> <56F5A809.2020505@FreeBSD.org> <20160325231115.3752fe53@nonamehost.local> <1458941638.1091.82.camel@freebsd.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.229.193.176; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 22:04:29 -0000 On Fri, 25 Mar 2016 15:33:58 -0600 Ian Lepore wrote: > On Fri, 2016-03-25 at 23:11 +0200, Ivan Klymenko wrote: > > On Sat, 26 Mar 2016 00:05:13 +0300 > > Ruslan Makhmatkhanov wrote: > > > > > Ivan Klymenko wrote on 03/25/16 11:41 PM: > > > > On Fri, 25 Mar 2016 23:33:45 +0300 > > > > Ruslan Makhmatkhanov wrote: > > > > > > > > > Hello, > > > > > > > > > > I have this in pciconf output: > > > > > > > > > > =============================================================== > > > > > ======= > > > > > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > > > > > chip=0x2392197b rev=0x30 hdr=0x00 > > > > > vendor = 'JMicron Technology Corp.' > > > > > device = 'SD/MMC Host Controller' > > > > > class = base peripheral > > > > > > > > > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > > > > > chip=0x2393197b rev=0x30 hdr=0x00 > > > > > vendor = 'JMicron Technology Corp.' > > > > > device = 'MS Host Controller' > > > > > class = base peripheral > > > > > =============================================================== > > > > > ======= > > > > > > > > > > And my SD-card controller is not working anymore (it worked on > > > > > -current on the same laptop year or two ago). Do I need to > > > > > load some kld to make it working, or support for this > > > > > controllers was > > > > > dropped altogether for some reason? I have mostly vanilla > > > > > GENERIC > > > > > at r296772, but it actually stopped to work much earlier. > > > > > > > > > > Thanks. > > > > > > > > > > > > > +1 > > > > I would also like to clarify about this problem was drawn up a > > > > bug > > > > report. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 > > > > > > > > Thanks. > > > > > > Hah, I even see my comment from 2014 in this PR. > > > > I have it broken just from that moment to this day. > > uname -a > > FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > > r297234: > > Thu Mar 24 15:15:39 EET 2016 > > ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11 amd64 > > > > > > > So looks like it was > > > broken not in r292180 as Ian pointed, but much-much earlier. > > > Anyway, > > > I'll try to update to fresh -current first. > > > > > That PR has a very small range, r271081-138, but I don't any changes > in that range related to sdhci, or to pci. The PR doesn't say > anything about how the device "doesn't work". Does the sdhci device > show up in dmesg, but the sd card is never detected, or does sdhci > not even attach? > > -- Ian "doesn't work" - this means that the necessary modules loaded either nothing happens by dmesg and does not appear in the device /dev/ in any case - it is a message about the problem and some strange reason, unless specified more detailed report. From owner-freebsd-current@freebsd.org Fri Mar 25 23:11:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BCCAADD1CB for ; Fri, 25 Mar 2016 23:11:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 DD5D52DE5 for ; Fri, 25 Mar 2016 23:11:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fe9be697-f2de-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 25 Mar 2016 23:12:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2PNBoLd020068; Fri, 25 Mar 2016 17:11:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458947510.1091.91.camel@freebsd.org> Subject: Re: SD card adapter doesn't working anymore From: Ian Lepore To: Ruslan Makhmatkhanov , FreeBSD Current Date: Fri, 25 Mar 2016 17:11:50 -0600 In-Reply-To: <56F5A0A9.8030207@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 23:11:53 -0000 On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: > Hello, > > I have this in pciconf output: > > ===================================================================== > = > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > chip=0x2392197b > rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'SD/MMC Host Controller' > class = base peripheral > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > chip=0x2393197b > rev=0x30 hdr=0x00 > vendor = 'JMicron Technology Corp.' > device = 'MS Host Controller' > class = base peripheral > ===================================================================== > = > > And my SD-card controller is not working anymore (it worked on > -current > on the same laptop year or two ago). Do I need to load some kld to > make > it working, or support for this controllers was dropped altogether > for > some reason? I have mostly vanilla GENERIC at r296772, but it > actually > stopped to work much earlier. > > Thanks. > Do you have a pciconf entry for class=080501 chip=0x2391197b, device would probably be "SD Host Controller", and if so, is it none@pci or sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output for it, and I'm curious whether any irq-related error showed up when it attached. The only change I can find that might have some effect is a switch to MSI-based interrupts some time ago. That was MFC'd to 10-stable in r271051, and that's very close to range cited in that PR. It might be worth trying to set hw.sdhci.enable_msi=0 in loader.conf and see if it makes a difference. -- Ian From owner-freebsd-current@freebsd.org Fri Mar 25 23:13:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF70DADD23E for ; Fri, 25 Mar 2016 23:13:24 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D594D2F75; Fri, 25 Mar 2016 23:13:24 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id ED9722A20; Fri, 25 Mar 2016 23:13:23 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , Ivan Klymenko References: <56F5A0A9.8030207@FreeBSD.org> <20160325224145.2f319ead@nonamehost.local> <56F5A809.2020505@FreeBSD.org> <20160325231115.3752fe53@nonamehost.local> <1458941638.1091.82.camel@freebsd.org> Cc: FreeBSD Current From: Ruslan Makhmatkhanov Message-ID: <56F5C5F6.5060600@FreeBSD.org> Date: Sat, 26 Mar 2016 02:12:54 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458941638.1091.82.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 23:13:25 -0000 Ian Lepore wrote on 03/26/16 12:33 AM: > On Fri, 2016-03-25 at 23:11 +0200, Ivan Klymenko wrote: >> On Sat, 26 Mar 2016 00:05:13 +0300 >> Ruslan Makhmatkhanov wrote: >> >>> Ivan Klymenko wrote on 03/25/16 11:41 PM: >>>> On Fri, 25 Mar 2016 23:33:45 +0300 >>>> Ruslan Makhmatkhanov wrote: >>>> >>>>> Hello, >>>>> >>>>> I have this in pciconf output: >>>>> >>>>> =============================================================== >>>>> ======= >>>>> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >>>>> chip=0x2392197b rev=0x30 hdr=0x00 >>>>> vendor = 'JMicron Technology Corp.' >>>>> device = 'SD/MMC Host Controller' >>>>> class = base peripheral >>>>> >>>>> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >>>>> chip=0x2393197b rev=0x30 hdr=0x00 >>>>> vendor = 'JMicron Technology Corp.' >>>>> device = 'MS Host Controller' >>>>> class = base peripheral >>>>> =============================================================== >>>>> ======= >>>>> >>>>> And my SD-card controller is not working anymore (it worked on >>>>> -current on the same laptop year or two ago). Do I need to load >>>>> some kld to make it working, or support for this controllers >>>>> was >>>>> dropped altogether for some reason? I have mostly vanilla >>>>> GENERIC >>>>> at r296772, but it actually stopped to work much earlier. >>>>> >>>>> Thanks. >>>>> >>>> >>>> +1 >>>> I would also like to clarify about this problem was drawn up a >>>> bug >>>> report. >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193341 >>>> >>>> Thanks. >>> >>> Hah, I even see my comment from 2014 in this PR. >> >> I have it broken just from that moment to this day. >> uname -a >> FreeBSD nonamehost.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 >> r297234: >> Thu Mar 24 15:15:39 EET 2016 >> ivan@nonamehost.local:/media/da0s1/obj/usr/src/sys/mk11 amd64 >> >> >>> So looks like it was >>> broken not in r292180 as Ian pointed, but much-much earlier. >>> Anyway, >>> I'll try to update to fresh -current first. >>> > > That PR has a very small range, r271081-138, but I don't any changes in > that range related to sdhci, or to pci. The PR doesn't say anything > about how the device "doesn't work". Does the sdhci device show up in > dmesg, but the sd card is never detected, or does sdhci not even > attach? > > -- Ian If memory serves me right, I first run into this problem about 2-6 months before I added a comment to the PR, that it doesn't works for me on r271687. Doesn't work means driver doesn't attaching to the hardware, so plugging memory card doesn't trigger any changes in system - still no driver attached to hardware and no device, that I can mount, appeared. But I sure that it worked without any intervention before - I just plugged an SD-card and it auto-mounted with my DE. But after that there is just nothing to mount. The reason why I missed particular revision it stopped working is because I'm using SD not too often (once a year or something) to update car music playlist. I can try to boot earlier releases like 10.0 etc, to find out revision on what it works. Anyway, Ian, if you may suggest something, I'm open to any tests and providing all the infos that is needed to debug the issue. Especially, because there is at least three person that are facing the same issue. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 25 23:23:58 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81DA1ADD457 for ; Fri, 25 Mar 2016 23:23:58 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 77A671357; Fri, 25 Mar 2016 23:23:58 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id C762C2B3F; Fri, 25 Mar 2016 23:23:57 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F5C870.7090906@FreeBSD.org> Date: Sat, 26 Mar 2016 02:23:28 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458947510.1091.91.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 23:23:58 -0000 Ian Lepore wrote on 03/26/16 02:11 AM: > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >> Hello, >> >> I have this in pciconf output: >> >> ===================================================================== >> = >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ===================================================================== >> = >> >> And my SD-card controller is not working anymore (it worked on >> -current >> on the same laptop year or two ago). Do I need to load some kld to >> make >> it working, or support for this controllers was dropped altogether >> for >> some reason? I have mostly vanilla GENERIC at r296772, but it >> actually >> stopped to work much earlier. >> >> Thanks. >> > > Do you have a pciconf entry for class=080501 chip=0x2391197b, device > would probably be "SD Host Controller", and if so, is it none@pci or > sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output for > it, and I'm curious whether any irq-related error showed up when it > attached. > > The only change I can find that might have some effect is a switch to > MSI-based interrupts some time ago. That was MFC'd to 10-stable in > r271051, and that's very close to range cited in that PR. > > It might be worth trying to set hw.sdhci.enable_msi=0 in loader.conf > and see if it makes a difference. > > -- Ian rm@smsh-zfs:/usr/src/sys/dev/ath/ath_hal> pciconf -vl | grep 0x2391197b sdhci_pci0@pci0:36:0:2: class=0x080501 card=0x167e103c chip=0x2391197b rev=0x30 hdr=0x00 rm@smsh-zfs:/usr/src/sys/dev/ath/ath_hal> dmesg | grep sdhci sdhci_pci0: mem 0xd4802000-0xd48020ff irq 18 at device 0.2 on pci4 sdhci_pci0: 1 slot(s) allocated Here is the full dmesg of mine: https://dpaste.de/Xq1H/raw -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Fri Mar 25 23:42:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC82FADD99A for ; Fri, 25 Mar 2016 23:42:47 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C267F1CD0; Fri, 25 Mar 2016 23:42:47 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 1C8822DF8; Fri, 25 Mar 2016 23:42:46 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F5CCDA.2060808@FreeBSD.org> Date: Sat, 26 Mar 2016 02:42:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458947510.1091.91.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 23:42:47 -0000 Ian Lepore wrote on 03/26/16 02:11 AM: > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >> Hello, >> >> I have this in pciconf output: >> >> ===================================================================== >> = >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ===================================================================== >> = >> >> And my SD-card controller is not working anymore (it worked on >> -current >> on the same laptop year or two ago). Do I need to load some kld to >> make >> it working, or support for this controllers was dropped altogether >> for >> some reason? I have mostly vanilla GENERIC at r296772, but it >> actually >> stopped to work much earlier. >> >> Thanks. >> > > Do you have a pciconf entry for class=080501 chip=0x2391197b, device > would probably be "SD Host Controller", and if so, is it none@pci or > sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output for > it, and I'm curious whether any irq-related error showed up when it > attached. > > The only change I can find that might have some effect is a switch to > MSI-based interrupts some time ago. That was MFC'd to 10-stable in > r271051, and that's very close to range cited in that PR. > > It might be worth trying to set hw.sdhci.enable_msi=0 in loader.conf > and see if it makes a difference. > > -- Ian Sorry, but nothing has changed in pciconf/dmesg with this option at boot. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Sat Mar 26 00:00:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EEDFADE163 for ; Sat, 26 Mar 2016 00:00:49 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2470113D5; Sat, 26 Mar 2016 00:00:49 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 724441023; Sat, 26 Mar 2016 00:00:48 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F5D114.2050706@FreeBSD.org> Date: Sat, 26 Mar 2016 03:00:20 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458947510.1091.91.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 00:00:49 -0000 Ian Lepore wrote on 03/26/16 02:11 AM: > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >> Hello, >> >> I have this in pciconf output: >> >> ===================================================================== >> = >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ===================================================================== >> = >> >> And my SD-card controller is not working anymore (it worked on >> -current >> on the same laptop year or two ago). Do I need to load some kld to >> make >> it working, or support for this controllers was dropped altogether >> for >> some reason? I have mostly vanilla GENERIC at r296772, but it >> actually >> stopped to work much earlier. >> >> Thanks. >> > > Do you have a pciconf entry for class=080501 chip=0x2391197b, device > would probably be "SD Host Controller", and if so, is it none@pci or > sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output for > it, and I'm curious whether any irq-related error showed up when it > attached. > > The only change I can find that might have some effect is a switch to > MSI-based interrupts some time ago. That was MFC'd to 10-stable in > r271051, and that's very close to range cited in that PR. > > It might be worth trying to set hw.sdhci.enable_msi=0 in loader.conf > and see if it makes a difference. > > -- Ian For what it worth, I also boot with hw.sdhci.debug=1 and got this: sdhci_pci0: mem 0xd4802000-0xd48020ff irq 18 at device 0.2 on pci4 sdhci_pci0-slot0: 50MHz 8bits 3.3V 1.8V DMA sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x00000000 | Version: 0x0000ad01 sdhci_pci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_pci0-slot0: Present: 0x00080000 | Host ctl: 0x00000000 sdhci_pci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci_pci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci_pci0-slot0: Caps: 0x054032b2 | Max curr: 0x00000000 sdhci_pci0-slot0: =========================================== sdhci_pci0: 1 slot(s) allocated -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Sat Mar 26 01:09:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 052B6ADEEE3 for ; Sat, 26 Mar 2016 01:09:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 CF48212DC for ; Sat, 26 Mar 2016 01:09:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 4fa8d9cc-f2ef-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Mar 2016 01:08:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2Q19FOk020284; Fri, 25 Mar 2016 19:09:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458954555.1091.94.camel@freebsd.org> Subject: Re: SD card adapter doesn't working anymore From: Ian Lepore To: Ruslan Makhmatkhanov , FreeBSD Current Date: Fri, 25 Mar 2016 19:09:15 -0600 In-Reply-To: <56F5CCDA.2060808@FreeBSD.org> References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> <56F5CCDA.2060808@FreeBSD.org> Content-Type: multipart/mixed; boundary="=-jUbba7m6ihm6c3IP7ZyY" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 01:09:19 -0000 --=-jUbba7m6ihm6c3IP7ZyY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2016-03-26 at 02:42 +0300, Ruslan Makhmatkhanov wrote: > Ian Lepore wrote on 03/26/16 02:11 AM: > > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: > > > Hello, > > > > > > I have this in pciconf output: > > > > > > ================================================================= > > > ==== > > > = > > > none1@pci0:36:0:0: class=0x088000 card=0x167e103c > > > chip=0x2392197b > > > rev=0x30 hdr=0x00 > > > vendor = 'JMicron Technology Corp.' > > > device = 'SD/MMC Host Controller' > > > class = base peripheral > > > > > > none2@pci0:36:0:3: class=0x088000 card=0x167e103c > > > chip=0x2393197b > > > rev=0x30 hdr=0x00 > > > vendor = 'JMicron Technology Corp.' > > > device = 'MS Host Controller' > > > class = base peripheral > > > ================================================================= > > > ==== > > > = > > > > > > And my SD-card controller is not working anymore (it worked on > > > -current > > > on the same laptop year or two ago). Do I need to load some kld > > > to > > > make > > > it working, or support for this controllers was dropped > > > altogether > > > for > > > some reason? I have mostly vanilla GENERIC at r296772, but it > > > actually > > > stopped to work much earlier. > > > > > > Thanks. > > > > > > > Do you have a pciconf entry for class=080501 chip=0x2391197b, > > device > > would probably be "SD Host Controller", and if so, is it none@pci o > > r > > sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output > > for > > it, and I'm curious whether any irq-related error showed up when it > > attached. > > > > The only change I can find that might have some effect is a switch > > to > > MSI-based interrupts some time ago. That was MFC'd to 10-stable in > > r271051, and that's very close to range cited in that PR. > > > > It might be worth trying to set hw.sdhci.enable_msi=0 in > > loader.conf > > and see if it makes a difference. > > > > -- Ian > > Sorry, but nothing has changed in pciconf/dmesg with this option at > boot. > Hmm, well so much for logic ("what changed around the time reported in that PR?"). Now for intuition... Maybe this JMicro device id needs the same quirks as the 2381 ID that's already in the driver. The attached patch would add that. If this fixes it, that's good, but it doesn't explain why it worked then stopped working at some point. -- Ian --=-jUbba7m6ihm6c3IP7ZyY Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: dev/sdhci/sdhci_pci.c =================================================================== --- dev/sdhci/sdhci_pci.c (revision 297146) +++ dev/sdhci/sdhci_pci.c (working copy) @@ -105,6 +105,9 @@ static const struct sdhci_device { { 0x2381197B, 0xffff, "JMicron JMB38X SD", SDHCI_QUIRK_32BIT_DMA_SIZE | SDHCI_QUIRK_RESET_AFTER_REQUEST }, + { 0x2391197B, 0xffff, "JMicron JMB38X SD", + SDHCI_QUIRK_32BIT_DMA_SIZE | + SDHCI_QUIRK_RESET_AFTER_REQUEST }, { 0x16bc14e4, 0xffff, "Broadcom BCM577xx SDXC/MMC Card Reader", SDHCI_QUIRK_BCM577XX_400KHZ_CLKSRC }, { 0, 0xffff, NULL, --=-jUbba7m6ihm6c3IP7ZyY-- From owner-freebsd-current@freebsd.org Fri Mar 25 23:42:19 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 588DBADD975 for ; Fri, 25 Mar 2016 23:42:19 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward15m.cmail.yandex.net (forward15m.cmail.yandex.net [IPv6:2a02:6b8:b030::9c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 169811C9E; Fri, 25 Mar 2016 23:42:18 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [IPv6:2a02:6b8:0:2519::121]) by forward15m.cmail.yandex.net (Yandex) with ESMTP id 8EDFF21928; Sat, 26 Mar 2016 02:42:15 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id 2E88D67403D9; Sat, 26 Mar 2016 02:42:15 +0300 (MSK) Received: by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id nbXmVQ9VEX-gESm4DbE; Sat, 26 Mar 2016 02:42:14 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1458949334; bh=zFbFXBpCLdkxbXQRkhIBgIYAFMuiydyzSWwFFLtkw0g=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pj1xRm8ZQH7urrtlA8lcIddgYVQqjKAWples2Rd1FvJ7nmcaf43vQQFtm/Tgj5X9n 9QuyLvLgshixJeDa6B2R1GDoAYAPuCRnpA3mB3wvRD9MacpI+0M0loDiKIPSrViSyp B0jSwZr3+4MKW8NmcsMYT1C7gl1XaUa4qilG3ypk= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-ForeignMX: US X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F5CCBA.3020009@yandex.ru> Date: Sat, 26 Mar 2016 02:41:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458947510.1091.91.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 26 Mar 2016 05:23:43 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 25 Mar 2016 23:42:19 -0000 Ian Lepore wrote on 03/26/16 02:11 AM: > On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >> Hello, >> >> I have this in pciconf output: >> >> ===================================================================== >> = >> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >> chip=0x2392197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'SD/MMC Host Controller' >> class = base peripheral >> >> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >> chip=0x2393197b >> rev=0x30 hdr=0x00 >> vendor = 'JMicron Technology Corp.' >> device = 'MS Host Controller' >> class = base peripheral >> ===================================================================== >> = >> >> And my SD-card controller is not working anymore (it worked on >> -current >> on the same laptop year or two ago). Do I need to load some kld to >> make >> it working, or support for this controllers was dropped altogether >> for >> some reason? I have mostly vanilla GENERIC at r296772, but it >> actually >> stopped to work much earlier. >> >> Thanks. >> > > Do you have a pciconf entry for class=080501 chip=0x2391197b, device > would probably be "SD Host Controller", and if so, is it none@pci or > sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output for > it, and I'm curious whether any irq-related error showed up when it > attached. > > The only change I can find that might have some effect is a switch to > MSI-based interrupts some time ago. That was MFC'd to 10-stable in > r271051, and that's very close to range cited in that PR. > > It might be worth trying to set hw.sdhci.enable_msi=0 in loader.conf > and see if it makes a difference. > > -- Ian Sorry, but nothing has changed in pciconf/dmesg with this option at boot. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Sat Mar 26 09:24:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A70BADB024 for ; Sat, 26 Mar 2016 09:24:12 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EF9471600; Sat, 26 Mar 2016 09:24:11 +0000 (UTC) (envelope-from rm@FreeBSD.org) Received: from [127.0.0.1] (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 46BB51C1F; Sat, 26 Mar 2016 09:24:11 +0000 (UTC) (envelope-from rm@FreeBSD.org) Subject: Re: SD card adapter doesn't working anymore To: Ian Lepore , FreeBSD Current References: <56F5A0A9.8030207@FreeBSD.org> <1458947510.1091.91.camel@freebsd.org> <56F5CCDA.2060808@FreeBSD.org> <1458954555.1091.94.camel@freebsd.org> From: Ruslan Makhmatkhanov Message-ID: <56F6551D.1010308@FreeBSD.org> Date: Sat, 26 Mar 2016 12:23:41 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458954555.1091.94.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 09:24:12 -0000 Ian Lepore wrote on 03/26/16 04:09 AM: > On Sat, 2016-03-26 at 02:42 +0300, Ruslan Makhmatkhanov wrote: >> Ian Lepore wrote on 03/26/16 02:11 AM: >>> On Fri, 2016-03-25 at 23:33 +0300, Ruslan Makhmatkhanov wrote: >>>> Hello, >>>> >>>> I have this in pciconf output: >>>> >>>> ================================================================= >>>> ==== >>>> = >>>> none1@pci0:36:0:0: class=0x088000 card=0x167e103c >>>> chip=0x2392197b >>>> rev=0x30 hdr=0x00 >>>> vendor = 'JMicron Technology Corp.' >>>> device = 'SD/MMC Host Controller' >>>> class = base peripheral >>>> >>>> none2@pci0:36:0:3: class=0x088000 card=0x167e103c >>>> chip=0x2393197b >>>> rev=0x30 hdr=0x00 >>>> vendor = 'JMicron Technology Corp.' >>>> device = 'MS Host Controller' >>>> class = base peripheral >>>> ================================================================= >>>> ==== >>>> = >>>> >>>> And my SD-card controller is not working anymore (it worked on >>>> -current >>>> on the same laptop year or two ago). Do I need to load some kld >>>> to >>>> make >>>> it working, or support for this controllers was dropped >>>> altogether >>>> for >>>> some reason? I have mostly vanilla GENERIC at r296772, but it >>>> actually >>>> stopped to work much earlier. >>>> >>>> Thanks. >>>> >>> >>> Do you have a pciconf entry for class=080501 chip=0x2391197b, >>> device >>> would probably be "SD Host Controller", and if so, is it none@pci o >>> r >>> sdhci_pci@pci ? If sdhci_pci attached, there would be dmesg output >>> for >>> it, and I'm curious whether any irq-related error showed up when it >>> attached. >>> >>> The only change I can find that might have some effect is a switch >>> to >>> MSI-based interrupts some time ago. That was MFC'd to 10-stable in >>> r271051, and that's very close to range cited in that PR. >>> >>> It might be worth trying to set hw.sdhci.enable_msi=0 in >>> loader.conf >>> and see if it makes a difference. >>> >>> -- Ian >> >> Sorry, but nothing has changed in pciconf/dmesg with this option at >> boot. >> > > Hmm, well so much for logic ("what changed around the time reported in > that PR?"). Now for intuition... > > Maybe this JMicro device id needs the same quirks as the 2381 ID that's > already in the driver. The attached patch would add that. If this > fixes it, that's good, but it doesn't explain why it worked then > stopped working at some point. > > -- Ian I updated to r297281 with this quirk applied. Sadly, it doesn't change anything - controllers still not recognized. I also tried to boot this revision with disabled hw.sdhci.enable_msi=0, that I applied earlier. -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@freebsd.org Sat Mar 26 10:23:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 244AEADD20D for ; Sat, 26 Mar 2016 10:23:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 10F5318AA; Sat, 26 Mar 2016 10:23:39 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 05EFD1282; Sat, 26 Mar 2016 10:23:38 +0000 (UTC) Date: Sat, 26 Mar 2016 10:23:34 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jkim@FreeBSD.org, trasz@FreeBSD.org, mmel@FreeBSD.org, bdrewery@FreeBSD.org, cem@FreeBSD.org, avos@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <1731249001.134.1458987817994.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_amd64_gcc4.9 - Build #1137 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_amd64_gcc4.9 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 10:23:39 -0000 FreeBSD_HEAD_amd64_gcc4.9 - Build #1137 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.= 9/1137/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/= 1137/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1= 137/console Change summaries: 297287 by avos: net80211: fix panic for DWDS vaps Since r248069, TX IC lock must obtained before calling ieee80211_encap() and/or ieee80211_parent_xmitpkt(). Tested with: Intel 3945BG. 297286 by mmel: ARM: Parse command line delivered by U-Boot: - in atags - in DT blob (by using 'fdt chosen' U-Boot command) The command line must start with guard's string 'FreeBSD:' and can contain list of comma separated kenv strings. Also, boot modifier strings from boot.h are recognised and parsed into boothowto. The command line must be passed from U-Boot by setting of bootargs variable= : 'setenv bootargs FreeBSD:boot_single=3D1,vfs.root.mountfrom=3Dufs:/dev/ada0= s1a' followed by 'fdt chosen' (only for DT based boot) 297285 by mmel: ARM: Fix ATAG handling in LINUX_BOOT_API: - Don't convert atags address passed from U-Boot. It's real physical address (and we have 1:1 mapping). - Size of tags is encoded in words, not in bytes 297284 by mmel: ARM: Teach LINUX_BOOT_ABI to recognize DT blob. This allow us to boot FreeBSD kernel (using uImage encapsulation) directly from U-boot using 'bootm' command or by Android fastboot loader. For now, kernel uImage must be marked as Linux, but we can add support for FreeBSD into U-Boot later. 297283 by bdrewery: Implement (ACFLAGS|CFLAGS|CXXFLAGS).SRC globally. Sponsored by:=09EMC / Isilon Storage Division 297282 by bdrewery: We don't have a CPPFLAGS, COPTS or CPUFLAGS. Sponsored by:=09EMC / Isilon Storage Division 297281 by bdrewery: WITHOUT_TOOLCHAIN: Fix includes not being staged in WORLDTMP. This has been the case since r264930 and r274662. Sponsored by:=09EMC / Isilon Storage Division 297280 by bdrewery: WITHOUT_TOOLCHAIN: Also exclude LLDB. Sponsored by:=09EMC / Isilon Storage Division 297279 by bdrewery: CROSS_BINUTILS_PREFIX: Reduce redundant logic. Sponsored by:=09EMC / Isilon Storage Division 297278 by bdrewery: External compiler: Remove redundant flags from CXXFLAGS. The use of XCXXFLAGS is to assign it to CXX in CROSSENV. XCFLAGS is also assigned here so there is no need to have --syroot and -B flags again. Sponsored by:=09EMC / Isilon Storage Division 297277 by bdrewery: WITHOUT_CROSS_COMPILER: Fix this to use external compiler logic. Without this the default toolchain in /usr/bin/ would not use WORLDTMP via --sysroot, and would lack --target if cross-building. PR:=09=09196193 Related:=09D3970 Sponsored by:=09EMC / Isilon Storage Division 297276 by jkim: Merge byacc 20160324. 297273 by cem: Add td_swinvoltick to track last involuntary context switch Expose in DDB via "show thread." Reviewed by:=09markj Sponsored by:=09EMC / Isilon Storage Division 297272 by bdrewery: Fix libcompat not handling some external toolchain flags. - Use libc++ with GCC. - Use CROSS_BINUTILS_PREFIX with -B (r280980 addressed this mostly already) Sponsored by:=09EMC / Isilon Storage Division 297271 by bdrewery: Update flags for external GCC. - The -L WORLDTMP/usr/lib is not needed as GCC is already adding in -L =3D/usr/lib internally with --sysroot. It does not do this for header include paths though, thus passing -isystem =3D/usr/include is still needed. For the forced libc++ usage: - Use -isystem rather than -I for libc++ headers. - Use -std=3Dc++11 rather than gnu++11. - Use -nostdinc++ to ensure GCC's headers don't leak in. Sponsored by:=09EMC / Isilon Storage Division 297270 by bdrewery: Build libcompat (lib32) with a --sysroot pointing into its stage directory. This overrides the cross-compiler's default sysroot to use the WORLD32's sysroot for building the lib32 libraries. Previously the cross-compiler would default the sysroot to the 64bit WORLDTMP and -B/-L/-isystem flags were used to build using the lib32 files. This leads to multiple issues discussed later. Some extra headers are now needed to be staged since the 64bit WORLDTMP is not referenced at all for headers. The 64bit WORLDTMP is still used via PATH for build tools. Overriding the default target/arch is retained in the CC/CXX overrides. This allows reverting the LDSCRIPT rewriting in installworld from r296921 a= nd r235122, thus allowing read-only objdirs to work for installing again. This removes the need for _LDSCRIPTROOT. This allows progressing the change to always use --sysroot for the build rather than only relying on the cross-compiler's default sysroot. The work for that is in D3970 and needed to resolve WITHOUT_CROSS_COMPILER not using a --sysroot [1]. PR:=09=09196193 [1] Sponsored by:=09EMC / Isilon Storage Division 297269 by bdrewery: LIBRARIES_ONLY should only be defined during install32. r245561 added it to prevent extra files from being installed during the install32 phase (to prevent duplicates in the meta log with -DNO_ROOT). The flag should not be passed during build32 though since it may prevent staging of includes during the 'make includes' phase on library directories. Sponsored by:=09EMC / Isilon Storage Division 297268 by trasz: Fix iSCSI initiator crash that could happen with out-of-memory conditions with in-flight IO and subsequent reconnection. PR:=09=09199117 MFC after:=091 month Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D5673 The end of the build log: [...truncated 111125 lines...] /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.show.o -MTshow.o -std=3Dgnu= 99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uni= nitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum= -compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wn= o-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -W= no-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD= _amd64_gcc4.9/bin/sh/show.c -o show.o --- test.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.test.o -MTtest.o -std=3Dgnu= 99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uni= nitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum= -compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wn= o-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -W= no-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD= _amd64_gcc4.9/bin/sh/../test/test.c -o test.o --- all_subdir_libexec --- --- getif.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/bootpgw/.. -g -MD -MF.depend.getif.o -MTgetif.o -= std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-pointer-sign -Wn= o-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error=3Dlogical-no= t-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitialized -Wno-err= or=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error= =3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-bu= t-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing -Wno-= error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/boo= tpgw/../getif.c -o getif.o --- all_subdir_cddl --- --- libzfs_dataset.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -DZFS_NO_ACL -I/builds/= FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../sbin/mount -I/builds/Fre= eBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/lib/libumem -I/builds/= FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../sys/cddl/compat/opensola= ris -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/compa= t/opensolaris/include -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/.= ./../../cddl/compat/opensolaris/lib/libumem -I/builds/FreeBSD_HEAD_amd64_gc= c4.9/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common = -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../sys/cddl/contr= ib/opensolaris/common/zfs -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libz= fs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/builds/FreeBS= D_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/u= ts/common/sys -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../= cddl/contrib/opensolaris/head -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/= libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/builds/FreeBSD_H= EAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libn= vpair -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/con= trib/opensolaris/lib/libuutil/common -I/builds/FreeBSD_HEAD_amd64_gcc4.9/cd= dl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/builds= /FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/contrib/opensolari= s/lib/libzfs_core/common -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.libzfs_da= taset.po -MTlibzfs_dataset.po -std=3Diso9899:1999 -fstack-protector-strong = -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare -W= no-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Du= ninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3D= cast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -= Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-error=3D= strict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /builds/Fr= eeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/l= ib/libzfs/common/libzfs_dataset.c -o libzfs_dataset.po --- all_subdir_lib --- --- s_ccosh.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _ccosh.po -MTs_ccosh.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_ccosh.c -o s_ccosh.po --- all_subdir_libexec --- --- hwaddr.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/bootpgw/.. -g -MD -MF.depend.hwaddr.o -MThwaddr.o= -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-pointer-sign -= Wno-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error=3Dlogical-= not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitialized -Wno-e= rror=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-err= or=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-= but-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing -Wn= o-error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/b= ootpgw/../hwaddr.c -o hwaddr.o --- all_subdir_lib --- --- s_ccoshf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _ccoshf.po -MTs_ccoshf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_ccoshf.c -o s_ccoshf.po --- all_subdir_libexec --- --- report.o --- --- all_subdir_lib --- --- s_cexp.po --- --- all_subdir_libexec --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/bootpgw/.. -g -MD -MF.depend.report.o -MTreport.o= -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-pointer-sign -= Wno-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error=3Dlogical-= not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitialized -Wno-e= rror=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-err= or=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-= but-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing -Wn= o-error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/b= ootpgw/../report.c -o report.o --- all_subdir_lib --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cexp.po -MTs_cexp.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-header= s -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cexp.c -o s_cexp.po --- all_subdir_libexec --- --- rtmsg.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/bootpgw/.. -g -MD -MF.depend.rtmsg.o -MTrtmsg.o -= std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-pointer-sign -Wn= o-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error=3Dlogical-no= t-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitialized -Wno-err= or=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error= =3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-bu= t-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing -Wno-= error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/boo= tpgw/../rtmsg.c -o rtmsg.o --- all_subdir_lib --- --- s_cexpf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cexpf.po -MTs_cexpf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cexpf.c -o s_cexpf.po --- s_cimag.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cimag.po -MTs_cimag.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cimag.c -o s_cimag.po --- all_subdir_bin --- --- trap.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.trap.o -MTtrap.o -std=3Dgnu= 99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uni= nitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum= -compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wn= o-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -W= no-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD= _amd64_gcc4.9/bin/sh/trap.c -o trap.o --- all_subdir_lib --- --- s_cimagf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cimagf.po -MTs_cimagf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cimagf.c -o s_cimagf.po --- all_subdir_libexec --- --- bootpgw.full --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/bootpgw/.. -g -std=3Dgnu99 -fstack-protector-strong = -Wsystem-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error= =3Denum-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-comp= are -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobb= ered -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wn= o-error=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-v= alue -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -o bootpgw.full boo= tpgw.o getif.o hwaddr.o report.o rtmsg.o =20 --- all_subdir_lib --- --- s_cimagl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cimagl.po -MTs_cimagl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cimagl.c -o s_cimagl.po --- all_subdir_libexec --- --- bootpgw.debug --- /usr/local/x86_64-freebsd/bin/objcopy --only-keep-debug bootpgw.full bootpg= w.debug --- bootpgw --- /usr/local/x86_64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3Db= ootpgw.debug bootpgw.full bootpgw =3D=3D=3D> libexec/bootpd/tools (all) --- all_subdir_lib --- --- s_conj.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _conj.po -MTs_conj.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-header= s -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_conj.c -o s_conj.po --- all_subdir_libexec --- --- all --- =3D=3D=3D> libexec/bootpd/tools/bootpef (all) --- .depend --- echo bootpef.full: /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEA= D_amd64_gcc4.9/tmp/usr/lib/libc.a >> .depend --- bootpef.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/tools/bootpef/../.. -g -MD -MF.depend.bootpef.o -= MTbootpef.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-poi= nter-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error= =3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitial= ized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-ali= gn -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-erro= r=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-a= liasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libex= ec/bootpd/tools/bootpef/bootpef.c -o bootpef.o --- all_subdir_lib --- --- s_conjf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _conjf.po -MTs_conjf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_conjf.c -o s_conjf.po --- s_conjl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _conjl.po -MTs_conjl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_conjl.c -o s_conjl.po --- s_cproj.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cproj.po -MTs_cproj.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cproj.c -o s_cproj.po --- all_subdir_bin --- --- var.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.var.o -MTvar.o -std=3Dgnu99= -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-unini= tialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-c= ompare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-= error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno= -error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD= _amd64_gcc4.9/bin/sh/var.c -o var.o --- all_subdir_lib --- --- s_cprojf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _cprojf.po -MTs_cprojf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3D--- all_subdir_libexec --- --- dovend.o --- --- all_subdir_lib --- strict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /builds/Fr= eeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_cprojf.c -o s_cprojf.po --- all_subdir_libexec --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/tools/bootpef/../.. -g -MD -MF.depend.dovend.o -M= Tdovend.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-point= er-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare -Wno-error= =3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitial= ized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-ali= gn -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-erro= r=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-a= liasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/libex= ec/bootpd/tools/bootpef/../../dovend.c -o dovend.o --- all_subdir_lib --- --- s_creal.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _creal.po -MTs_creal.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_creal.c -o s_creal.po --- s_crealf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _crealf.po -MTs_crealf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_crealf.c -o s_crealf.po --- s_creall.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _creall.po -MTs_creall.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_creall.c -o s_creall.po --- s_csinh.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _csinh.po -MTs_csinh.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_csinh.c -o s_csinh.po --- all_subdir_libexec --- --- readfile.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -I/builds/FreeBSD_HEAD_amd64= _gcc4.9/libexec/bootpd/tools/bootpef/../.. -g -MD -MF.depend.readfile.o = -MTreadfile.o -std=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wno-p= ointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compare -Wno-err= or=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error=3Duniniti= alized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-a= lign -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-er= ror=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict= -aliasing -Wno-error=3Daddress -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib= exec/bootpd/tools/bootpef/../../readfile.c -o readfile.o --- all_subdir_lib --- --- s_csinhf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _csinhf.po -MTs_csinhf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_csinhf.c -o s_csinhf.po --- s_ctanh.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _ctanh.po -MTs_ctanh.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /build= s/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_ctanh.c -o s_ctanh.po --- s_ctanhf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -pg -O2 -pipe -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld80= -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEAD_= amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/incl= ude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend.s= _ctanhf.po -MTs_ctanhf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/src/s_ctanhf.c -o s_ctanhf.po --- e_remainder.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_remainder.po -MTe_remainder.po -std=3Dgnu99 -fstack-protector-strong -Ws= ystem-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3De= num-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered= -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-er= ror=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value= -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_remainder.S -o e_= remainder.po --- all_subdir_bin --- --- builtins.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.builtins.o -MTbuiltins.o -s= td=3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-erro= r=3Denum-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-com= pare -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclob= bered -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -W= no-error=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-= value -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -c builtins.c -= o builtins.o --- all_subdir_lib --- --- e_remainderf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_remainderf.po -MTe_remainderf.po -std=3Dgnu99 -fstack-protector-strong -= Wsystem-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error= =3Denum-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-comp= are -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobb= ered -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wn= o-error=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-v= alue -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas= -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_remainderf.S = -o e_remainderf.po --- e_remainderl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_remainderl.po -MTe_remainderl.po -std=3Dgnu99 -fstack-protector-strong -= Wsystem-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error= =3Denum-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-comp= are -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobb= ered -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wn= o-error=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-v= alue -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas= -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_remainderl.S = -o e_remainderl.po --- all_subdir_bin --- --- nodes.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.nodes.o -MTnodes.o -std=3Dg= nu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-u= ninitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Den= um-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -= Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered = -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-err= or=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -c nodes.c -o nodes.o --- all_subdir_lib --- --- e_sqrt.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_sqrt.po -MTe_sqrt.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-head= ers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-compar= e -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-error= =3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-erro= r=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Dinli= ne -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-erro= r=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /bui= lds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_sqrt.S -o e_sqrt.po --- e_sqrtf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_sqrtf.po -MTe_sqrtf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /b= uilds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_sqrtf.S -o e_sqrtf.po --- e_sqrtl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .e_sqrtl.po -MTe_sqrtl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /b= uilds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/e_sqrtl.S -o e_sqrtl.po --- s_llrint.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_llrint.po -MTs_llrint.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-co= mpare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-e= rror=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-= error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3D= inline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-= error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c = /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_llrint.S -o s_llrint.po --- s_llrintf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_llrintf.po -MTs_llrintf.po -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-= compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno= -error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wn= o-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_llrintf.S -o s_llrin= tf.po --- s_llrintl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_llrintl.po -MTs_llrintl.po -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-= compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno= -error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wn= o-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_llrintl.S -o s_llrin= tl.po --- s_logbl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_logbl.po -MTs_logbl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /b= uilds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_logbl.S -o s_logbl.po --- s_lrint.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_lrint.po -MTs_lrint.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /b= uilds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_lrint.S -o s_lrint.po --- all_subdir_bin --- --- syntax.o --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/Free= BSD_HEAD_amd64_gcc4.9/bin/sh -g -MD -MF.depend.syntax.o -MTsyntax.o -std= =3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W= no-uninitialized -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error= =3Denum-compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-comp= are -Wno-error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobb= ered -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wn= o-error=3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-v= alue -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -c syntax.c -o s= yntax.o --- all_subdir_lib --- --- s_lrintf.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_lrintf.po -MTs_lrintf.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-co= mpare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-e= rror=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-= error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3D= inline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-= error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c = /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_lrintf.S -o s_lrintf.po --- all_subdir_bin --- --- sh.full --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/builds/FreeBS= D_HEAD_amd64_gcc4.9/bin/sh -g -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-e= rror=3Dunused-function -Wno-error=3Denum-compare -Wno-error=3Dlogical-not-p= arentheses -Wno-error=3Dbool-compare -Wno-error=3Duninitialized -Wno-error= =3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error= =3Dextra -Wno-error=3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-bu= t-set-variable -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing -Wno-= error=3Daddress -o sh.full alias.o arith_yacc.o arith_yylex.o cd.o echo.o = error.o eval.o exec.o expand.o histedit.o input.o jobs.o kill.o mail.o main= .o memalloc.o miscbltin.o mystring.o options.o output.o parser.o printf.o r= edir.o show.o test.o trap.o var.o builtins.o nodes.o syntax.o -ledit --- all_subdir_lib --- --- s_lrintl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_lrintl.po -MTs_lrintl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-co= mpare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-e= rror=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-= error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3D= inline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-= error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c = /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_lrintl.S -o s_lrintl.po --- s_remquo.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_remquo.po -MTs_remquo.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-co= mpare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-e= rror=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-= error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3D= inline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-= error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c = /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_remquo.S -o s_remquo.po --- s_remquof.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_remquof.po -MTs_remquof.po -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-= compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno= -error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wn= o-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_remquof.S -o s_remqu= of.po --- s_remquol.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_remquol.po -MTs_remquol.po -std=3Dgnu99 -fstack-protector-strong -Wsyste= m-headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-= compare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno= -error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wn= o-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error= =3Dinline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -W= no-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -c /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_remquol.S -o s_remqu= ol.po --- s_rintl.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_rintl.po -MTs_rintl.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-he= aders -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-comp= are -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-err= or=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-er= ror=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3Din= line -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-er= ror=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c /b= uilds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_rintl.S -o s_rintl.po --- s_scalbn.po --- /usr/local/bin/x86_64-portbld-freebsd10.1-gcc -isystem /builds/FreeBSD_HEAD= _amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include --sysroo= t=3D/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/= tmp -B/usr/local/x86_64-freebsd/bin/ -DPROF -O2 -pipe -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/x86 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/ld= 80 -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64 -I/builds/FreeBSD_HEA= D_amd64_gcc4.9/lib/msun/src -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/in= clude -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/libc/amd64 -MD -MF.depend= .s_scalbn.po -MTs_scalbn.po -std=3Dgnu99 -fstack-protector-strong -Wsystem-= headers -Wno-pointer-sign -Wno-error=3Dunused-function -Wno-error=3Denum-co= mpare -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno-e= rror=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-= error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes -Wno-error=3D= inline -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value -Wno-= error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas -c = /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun/amd64/s_scalbn.S -o s_scalbn.po --- all_subdir_bin --- histedit.o: In function `histedit': /builds/FreeBSD_HEAD_amd64_gcc4.9/bin/sh/histedit.c:125: undefined referenc= e to `_el_fn_sh_complete' collect2: error: ld returned 1 exit status *** [sh.full] Error code 1 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/bin/sh 1 error bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/bin/sh --- all_subdir_lib --- A failure has been detected in another branch of the parallel make bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/msun --- all_subdir_bin --- *** [all_subdir_bin/sh] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/bin 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/bin *** [all_subdir_bin] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 --- all_subdir_lib --- *** [all_subdir_lib/msun] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/lib 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/lib *** [all_subdir_lib] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 --- all_subdir_cddl --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib/libzfs *** [all_subdir_cddl/lib/libzfs] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib 1 error bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/cddl/lib *** [all_subdir_cddl/lib] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/cddl 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/cddl *** [all_subdir_cddl] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 --- all_subdir_libexec --- A failure has been detected in another branch of the parallel make bmake[6]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/tools= /bootpef *** [all] Error code 2 bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/tools 1 error bmake[5]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd/tools *** [all] Error code 2 bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd 1 error bmake[4]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec/bootpd *** [all] Error code 2 bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec 1 error bmake[3]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9/libexec *** [all_subdir_libexec] Error code 2 bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 4 errors bmake[2]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 *** [everything] Error code 2 bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 1 error bmake[1]: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 *** [buildworld] Error code 2 make: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 1 error make: stopped in /builds/FreeBSD_HEAD_amd64_gcc4.9 Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE IRC notifier plugin: Sending notification to: #freebsd-commits Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-current@freebsd.org Sat Mar 26 17:00:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76547ADEA07 for ; Sat, 26 Mar 2016 17:00:27 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 3A489129A; Sat, 26 Mar 2016 17:00:26 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ajrZX-000GQm-P2>; Sat, 26 Mar 2016 18:00:23 +0100 Received: from x5ce13412.dyn.telefonica.de ([92.225.52.18] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1ajrZX-001Wjv-E7>; Sat, 26 Mar 2016 18:00:23 +0100 Date: Sat, 26 Mar 2016 18:00:45 +0100 From: "O. Hartmann" To: "K. Macy" Cc: FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability Message-ID: <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/2MdzBa/DDc2YgqXOAyIXM=m"; protocol="application/pgp-signature" X-Originating-IP: 92.225.52.18 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 17:00:27 -0000 --Sig_/2MdzBa/DDc2YgqXOAyIXM=m Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 25 Mar 2016 13:31:31 -0700 "K. Macy" schrieb: > Does this pre or postage input changes? ??? First of all, and the most visible fact is, that the ssh connection with hi= gh terminal i/o (compiling world, poudriere bulk ...) receives very often broken pipe. = The "native" console of the systems (non UEFI, but drm2/i915kms loaded, iGPU of IvyBridg= e XEON) in question is like "glue" - responding time shifted. This is on all CURRENT s= ystems. =20 >=20 > On Friday, March 25, 2016, O. Hartmann wrot= e: >=20 > > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD > > 11.0-CURRENT #9 > > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and > > like "glue": it > > is slow with X11, sometimes ssh connections even nearby hosts on the sa= me > > net not under > > load have some time to respond to keys in xterm or on console (vt()) ~ = 1 - > > 3 seconds and > > I receive very often "broken pipe" to ssh connections to a host nearby.= I > > realized this > > strange behaviour on a couple of systems a maintain running most recent > > CURRENT. > > > > I also realize a high usage of swap on a 8GB RAM, 2 core box having two > > ZFS volumes (one > > 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia > > 364.12/355.11 driver, I > > checked on both) and running desktop only (windowmaker) brings the syst= em > > toward using 12 > > or sometimes several hundreds of megabytes of swap - and I do not see w= hat > > is using so > > much space. > > > > Does anyone also realize this phenomenon? > > > > Regards, > > > > oh > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg > > " > > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Sig_/2MdzBa/DDc2YgqXOAyIXM=m Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW9sA9AAoJEOgBcD7A/5N8IpAH/iYSv8BPk2Ni/TPDUh2DQon+ T9OSzyShOYqsTf5Jmo1IUVJdw84sTT2kqg/TIUCHVM0x08GTS867mlolRWE3JmGE 96ZaV2pZ5BLqs4wLCTGUd1GsFFeducUkI+33IAxM6CxNKtqOI7VNUh9qclKtL03v rrH/f2foQTQLGh68P3Y6Aasw/mmYljnLOWxzB4KTpQZmCwoHr3bvc5kjRL8MiiwO Em37Dejc+ij67PUF7SW63A88QIqovme46I8FPCk7+JNlltkhgRJP1lpAKlEWZwwE u2qgnqCpqLVtkCxhC/FcyTo4cMQkrHAVHescJyRe6kL2JGVdcvnMi4PfGbv6r58= =NDJV -----END PGP SIGNATURE----- --Sig_/2MdzBa/DDc2YgqXOAyIXM=m-- From owner-freebsd-current@freebsd.org Sat Mar 26 17:28:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68B2CADE2AC for ; Sat, 26 Mar 2016 17:28:25 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 665231B3C; Sat, 26 Mar 2016 17:28:24 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.auburn.protected-networks.net (localhost.auburn.protected-networks.net [127.0.0.1]) by mail.auburn.protected-networks.net (Postfix) with ESMTP id 116D966; Sat, 26 Mar 2016 13:28:20 -0400 (EDT) Received: from mail.auburn.protected-networks.net ([127.0.0.1]) by mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j73cy7_k8xA; Sat, 26 Mar 2016 13:28:18 -0400 (EDT) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks CA" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 1835C8; Sat, 26 Mar 2016 13:28:18 -0400 (EDT) Subject: Re: CURRENT slow and shaky network stability To: "O. Hartmann" , "K. Macy" References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> Cc: FreeBSD CURRENT From: Michael Butler Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <56F6C6B0.6010103@protected-networks.net> Date: Sat, 26 Mar 2016 13:28:16 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 17:28:25 -0000 -current is not great for interactive use at all. The strategy of pre-emptively dropping idle processes to swap is hurting .. big time. Compare inactive memory to swap in this example .. 110 processes: 1 running, 108 sleeping, 1 zombie CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1819 imb 1 28 0 213M 11284K select 1 147:44 5.97% gkrellm 59238 imb 43 20 0 980M 424M select 0 10:07 1.92% firefox .. it shouldn't start randomly swapping out processes because they're used infrequently when there's more than enough RAM to spare .. It also shows up when trying to reboot .. on all of my gear, 90 seconds of "fail-safe" time-out is no longer enough when a good proportion of daemons have been dropped onto swap and must be brought back in to flush their data segments :-( Michael From owner-freebsd-current@freebsd.org Sat Mar 26 17:40:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26213ADE5EF for ; Sat, 26 Mar 2016 17:40:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (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 DFDEF164F for ; Sat, 26 Mar 2016 17:40:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::d9a:d4e2:d8a5:bfbb] (unknown [IPv6:2001:7b8:3a7:0:d9a:d4e2:d8a5:bfbb]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5648225AE3; Sat, 26 Mar 2016 18:40:28 +0100 (CET) Subject: Re: failed to compile base, buldworld, with -Os CFLAGS Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_966F1FF8-ACBB-4D2B-B6D1-5D338C2F6FE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: Date: Sat, 26 Mar 2016 18:40:21 +0100 Cc: freebsd-current Message-Id: <0E0CBB40-E962-40F9-9F8C-57108169BE40@FreeBSD.org> References: To: Eric Camachat X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 17:40:32 -0000 --Apple-Mail=_966F1FF8-ACBB-4D2B-B6D1-5D338C2F6FE1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 25 Mar 2016, at 19:30, Dimitry Andric wrote: > > On 25 Mar 2016, at 05:21, Eric Camachat wrote: >> >> I tried to buildworld with -Os CFLAGS, but it failed. > ... >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> cc: note: diagnostic msg: /tmp/fnmatch-87dc57.c >> (http://slexy.org/view/s2ddVhTTyQ) >> cc: note: diagnostic msg: /tmp/fnmatch-87dc57.sh >> (http://slexy.org/view/s21zeFmDPU) > > Thanks for the report. This also happens with llvm trunk, so I have > submitted a bug with a reduced test case upstream: > > https://llvm.org/bugs/show_bug.cgi?id=27071 > > In the mean time, please use -O1 or -O2 to build world, as a workaround. This should now be fixed as of r297294, where I merged the upstream fix: http://reviews.llvm.org/rL264465 -Dimitry --Apple-Mail=_966F1FF8-ACBB-4D2B-B6D1-5D338C2F6FE1 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.29 iEYEARECAAYFAlb2yYsACgkQsF6jCi4glqOF0wCg4MZLv1w/WV726BwYhoMIcEzq nJMAn0Gyhi1mHwyerxm7tfGoGjyOFuV5 =OYkO -----END PGP SIGNATURE----- --Apple-Mail=_966F1FF8-ACBB-4D2B-B6D1-5D338C2F6FE1-- From owner-freebsd-current@freebsd.org Sat Mar 26 17:56:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFFF5ADE93A for ; Sat, 26 Mar 2016 17:56:26 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B9BF14E0 for ; Sat, 26 Mar 2016 17:56:26 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id v187so110152263ioe.2 for ; Sat, 26 Mar 2016 10:56:26 -0700 (PDT) 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; bh=1aQjuyPa707e/SBlMljvjJ6EAkEIMkWZMb0BVAq+c+g=; b=iXCoXljGvj+nAMD94i9DbzFli504j6SPTWa0EMOSW+VVjjLqrgLV10VJDuF6cUHNhv YYmgM1UFFVzN+yXXj78kFnzL3P6prqHKYREqR5oAiGN7xLWxrRckTzVnK3XZ2RXwqb7C s+Hf2zKEbAn5Cr/kmx25iCzS9E6Zwv4JYsPDf6GtWPGrR4wCjtA8Pr8ES2pg6cXOt/7l 1NJ6QEQO8jYM8ywjSEntA12uPdRXDsV3NVjAJHmMTCIWj/T8oTYpZ0dlhdBS25TiHOP7 XLWoRVh1SAlFOQE17hav6Cq5q5xoCkG8ukp/hzjHhd9QJob3dl7OIHypoFbfVie8hJtf /koQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1aQjuyPa707e/SBlMljvjJ6EAkEIMkWZMb0BVAq+c+g=; b=NL+Xq1MjjznfUTaLMz+ZRnDIJhpq8jnBzv8fsJ5/a8CLOTEjbL/yJzu+MtBzM0pdvm bMp6d0UWCnZ8NAqNyGJnnLoBz26m/2QrVhP8+l4uZ5YtZb0OYoe/6UpM357vwEc53iIf 2VxAt5jOYXHzd3D2qXWfNh69480W2NnFRzzMWf/djtQodp0zsOiOkU8jc01YfeUdArux AlDl+nbg3o4gakFa1etleIdbcPj/QVNkVZqoUquTcAG+F7wAM1GnF3rPijuIdCy8lmms bDx1XsG76pHGk4G4l/lU8KB3awu/pulGtaC26U0DS5CqSh/huhBd966s8oKzxKtL3iUX sQ0A== X-Gm-Message-State: AD7BkJI7fUDypM/uSf6a8EKwnGygPu7gXdsG7jwfeKU6aGDYDQFzfgOIB2GL+9TdEXe12A2kBVVMNvmbGa3Lng== MIME-Version: 1.0 X-Received: by 10.107.162.17 with SMTP id l17mr19360613ioe.42.1459014985862; Sat, 26 Mar 2016 10:56:25 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.107.143.75 with HTTP; Sat, 26 Mar 2016 10:56:25 -0700 (PDT) In-Reply-To: <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> Date: Sat, 26 Mar 2016 10:56:25 -0700 X-Google-Sender-Auth: 38R3XWwrHu2t1s-k1y8Unk8-F6I Message-ID: Subject: Re: CURRENT slow and shaky network stability From: "K. Macy" To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 17:56:26 -0000 Sorry meant inpcb and autocorrect "fixed" it. On Saturday, March 26, 2016, O. Hartmann wrote: > Am Fri, 25 Mar 2016 13:31:31 -0700 > "K. Macy" > schrieb: > > > Does this pre or postage input changes? > > ??? > > First of all, and the most visible fact is, that the ssh connection with > high terminal > i/o (compiling world, poudriere bulk ...) receives very often broken pipe. > The "native" > console of the systems (non UEFI, but drm2/i915kms loaded, iGPU of > IvyBridge XEON) in > question is like "glue" - responding time shifted. This is on all CURRENT > systems. > > > > > On Friday, March 25, 2016, O. Hartmann > wrote: > > > > > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD > > > 11.0-CURRENT #9 > > > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky > and > > > like "glue": it > > > is slow with X11, sometimes ssh connections even nearby hosts on the > same > > > net not under > > > load have some time to respond to keys in xterm or on console (vt()) ~ > 1 - > > > 3 seconds and > > > I receive very often "broken pipe" to ssh connections to a host > nearby. I > > > realized this > > > strange behaviour on a couple of systems a maintain running most recent > > > CURRENT. > > > > > > I also realize a high usage of swap on a 8GB RAM, 2 core box having two > > > ZFS volumes (one > > > 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia > > > 364.12/355.11 driver, I > > > checked on both) and running desktop only (windowmaker) brings the > system > > > toward using 12 > > > or sometimes several hundreds of megabytes of swap - and I do not see > what > > > is using so > > > much space. > > > > > > Does anyone also realize this phenomenon? > > > > > > Regards, > > > > > > oh > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org > > > " > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org " > > From owner-freebsd-current@freebsd.org Sat Mar 26 19:01:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E70EBADE74B for ; Sat, 26 Mar 2016 19:01:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A4E1E1692; Sat, 26 Mar 2016 19:01:31 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ajtSj-000b1T-8w>; Sat, 26 Mar 2016 20:01:29 +0100 Received: from f052164093.adsl.alicedsl.de ([78.52.164.93] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (envelope-from ) id <1ajtSi-001f3I-UV>; Sat, 26 Mar 2016 20:01:29 +0100 Date: Sat, 26 Mar 2016 20:01:55 +0100 From: "O. Hartmann" To: Michael Butler Cc: "K. Macy" , FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability Message-ID: <20160326200155.4df77b12.ohartman@zedat.fu-berlin.de> In-Reply-To: <56F6C6B0.6010103@protected-networks.net> References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> <20160326180045.790621bb.ohartman@zedat.fu-berlin.de> <56F6C6B0.6010103@protected-networks.net> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/S+Ep0qy.hqg3cs_QHNY+Yfs"; protocol="application/pgp-signature" X-Originating-IP: 78.52.164.93 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 19:01:32 -0000 --Sig_/S+Ep0qy.hqg3cs_QHNY+Yfs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 26 Mar 2016 13:28:16 -0400 Michael Butler schrieb: > -current is not great for interactive use at all. The strategy of > pre-emptively dropping idle processes to swap is hurting .. big time. What is the gain then? If this "feature" results in corrupted ssh sessions, slow console sessions = or even worse: prolongued compilation times, then it is a big fail! >=20 > Compare inactive memory to swap in this example .. >=20 > 110 processes: 1 running, 108 sleeping, 1 zombie > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1819 imb 1 28 0 213M 11284K select 1 147:44 5.97% > gkrellm > 59238 imb 43 20 0 980M 424M select 0 10:07 1.92% > firefox >=20 > .. it shouldn't start randomly swapping out processes because they're > used infrequently when there's more than enough RAM to spare .. >=20 > It also shows up when trying to reboot .. on all of my gear, 90 seconds > of "fail-safe" time-out is no longer enough when a good proportion of > daemons have been dropped onto swap and must be brought back in to flush > their data segments :-( >=20 > Michael --Sig_/S+Ep0qy.hqg3cs_QHNY+Yfs Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW9tyjAAoJEOgBcD7A/5N80fcH/25TOoJ5sWM8tIHkQC4Rg1sN U1Wxw0rcFIBtnmSd9GipjiIDTwe4PRVN76CNdPygn3L3Go2RS52V2bWXs26TsSX+ mbaQ03LeGbXLioL3+gQIitfLARU4iIRNWl/VyGr4Z5IAVtkfAFQ7kBjaBFIkeHC/ Cz7QVR76sNwEfsn8fdpVO6UWAODBYQ7glu+F81QOcLD+8Ewf4jrCS1J+oaFM0C9g akOERFgpIQSQPmrGV0mL+2+KGpvNuRSoqiHTslhXrWzGDJ64VYTh/LB742Z8kAhR USG+sAXeD82H2MenS/jwXN7Zg3Flk0zz9MQviVonLKPw7j9MIc0fWpve7kR/Fx8= =6cI4 -----END PGP SIGNATURE----- --Sig_/S+Ep0qy.hqg3cs_QHNY+Yfs-- From owner-freebsd-current@freebsd.org Sat Mar 26 19:08:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33CF7ADE83D for ; Sat, 26 Mar 2016 19:08:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6FD91C82 for ; Sat, 26 Mar 2016 19:08:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x232.google.com with SMTP id av4so30347019igc.1 for ; Sat, 26 Mar 2016 12:08:15 -0700 (PDT) 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; bh=4JvkNm42klkbtELk7eHwG88ySRFzYzrT7rAAl/fdIv8=; b=CpGKjlpDtbQTMTkaTS32zlgcIo9J3ZVZvQc5KmNAfE0VKP1LJr8dp804cfxsdAAsLU ksS+d7A/m4OtqK+LmJmgHsWlikSUs3oSgbOjpvEd67L5phktIC1HjaOurUxRS5yzd/Hj MBaKrVVZNDyMDKxQLcPUlQQWo7ewrvppwLt0ToGhuX85Yg6jzYz+XwHpdxGqIVCy2+hw 729re0Sm4RlfBIHC5AXccKlQO0Njbj7Mr+Y+U5gBGxD0vFpAfdz6TbEdU/C7d1bRRmFB uWVkqfDzsngjh7vWchjIYm5Ld7y0Dx6F7Z2dqGOUp9Plz2Wc22JeuuarLcy8swu7g66l p6pQ== 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; bh=4JvkNm42klkbtELk7eHwG88ySRFzYzrT7rAAl/fdIv8=; b=kOr0X5gAnmvMzs/e7cpJMFaxMXx9620nt42VTMaHzgWlYogg4cqVRYnzpe8jmpGUen m/fPfcpIssXGrBTO6R8FtnArWs8pXqMvhHoiBuYK0pKHbqCAzVMZYKKNBNsqGD+nUs33 RsPMd/QLoicgW/z209vsop9dJLW9z9M+2JWhEiiHHs7gH5cE6g+yg83FtnonRCrte+8I 5jZn4fXT4V2C18zLPm8ZRgu3s9T3Y7Wbwh0/UiP5Ureb/FujrmJxzPTvTpXruaegdKsC NzC3VvB0uzEAoGak4UeZzTiDmKoecCQDk2A4f+h3J6wbPqvOJUyqteMPTJsHN4z0CK76 8YPg== X-Gm-Message-State: AD7BkJIwZaSB0csTyZfYLmaN02+sGbNx7FY8kT/nOTItep4aFaAgMfbc9cgv/4C90SHo2pT6GAKTXHxEG67PeA== MIME-Version: 1.0 X-Received: by 10.50.8.101 with SMTP id q5mr2514771iga.22.1459019295381; Sat, 26 Mar 2016 12:08:15 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Sat, 26 Mar 2016 12:08:15 -0700 (PDT) In-Reply-To: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> Date: Sat, 26 Mar 2016 12:08:15 -0700 Message-ID: Subject: Re: CURRENT slow and shaky network stability From: Adrian Chadd To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 19:08:16 -0000 hiya, can you identify a revision where it /doesn't/ do broken pipe? That'd be the best way to start debugging this and figure out which revision broke things. I haven't updated to the latest -HEAD on anything just yet; everything's a few weeks old. Thanks, -a On 25 March 2016 at 13:30, O. Hartmann wrote: > Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD 11.0-CURRENT #9 > r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and like "glue": it > is slow with X11, sometimes ssh connections even nearby hosts on the same net not under > load have some time to respond to keys in xterm or on console (vt()) ~ 1 - 3 seconds and > I receive very often "broken pipe" to ssh connections to a host nearby. I realized this > strange behaviour on a couple of systems a maintain running most recent CURRENT. > > I also realize a high usage of swap on a 8GB RAM, 2 core box having two ZFS volumes (one > 3TB HD and one 4 TB HAD with ZFS). Using Firefox on X11 (nVidia 364.12/355.11 driver, I > checked on both) and running desktop only (windowmaker) brings the system toward using 12 > or sometimes several hundreds of megabytes of swap - and I do not see what is using so > much space. > > Does anyone also realize this phenomenon? > > Regards, > > oh > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Mar 26 20:15:32 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A77B9ADE6D0 for ; Sat, 26 Mar 2016 20:15:32 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 72D4B17ED for ; Sat, 26 Mar 2016 20:15:32 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 891D84FAE8; Sat, 26 Mar 2016 20:15:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2QKFN4L067645; Sat, 26 Mar 2016 20:15:23 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT slow and shaky network stability In-reply-to: From: "Poul-Henning Kamp" References: <20160325213025.61c41f2c.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67643.1459023323.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2016 20:15:23 +0000 Message-ID: <67644.1459023323@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 20:15:32 -0000 -------- In message , Adrian Chadd writes: I can second that -current isn't too great right now, and I also see the breaking SSH sessions. I'm running: FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 I repartitioned my disk I don't have the previous version around any more but it was 4-6 weeks old, and I'm quite sure it didn't have the breaking ssh connections. On another machine running: FreeBSD 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 I'm seeing weirdness with a 2TB and a 3TB external USB disk, in particular I/O aborts with this message: usb_pc_common_mem_cb: Page offset was not preserved -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sat Mar 26 21:09:22 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3530FADD346 for ; Sat, 26 Mar 2016 21:09:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1757D103E for ; Sat, 26 Mar 2016 21:09:22 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2QL9Aoa079919; Sat, 26 Mar 2016 14:09:15 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201603262109.u2QL9Aoa079919@gw.catspoiler.org> Date: Sat, 26 Mar 2016 14:09:10 -0700 (PDT) From: Don Lewis Subject: Re: CURRENT slow and shaky network stability To: phk@phk.freebsd.dk cc: adrian.chadd@gmail.com, ohartman@zedat.fu-berlin.de, freebsd-current@freebsd.org In-Reply-To: <67644.1459023323@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 21:09:22 -0000 On 26 Mar, Poul-Henning Kamp wrote: > -------- > In message > , Adrian Chadd writes: > > I can second that -current isn't too great right now, and I also see > the breaking SSH sessions. > > I'm running: > > FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 > > I repartitioned my disk I don't have the previous version around any more > but it was 4-6 weeks old, and I'm quite sure it didn't have the breaking > ssh connections. > > On another machine running: > > FreeBSD 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016 > > I'm seeing weirdness with a 2TB and a 3TB external USB disk, in > particular I/O aborts with this message: > > usb_pc_common_mem_cb: Page offset was not preserved > No problems here with: FreeBSD 11.0-CURRENT #37 r297204M: Tue Mar 22 23:29:06 PDT 2016 From owner-freebsd-current@freebsd.org Sat Mar 26 21:26:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46CADADD8D1 for ; Sat, 26 Mar 2016 21:26:55 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 25EEE1966; Sat, 26 Mar 2016 21:26:55 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2QLQjT0079960; Sat, 26 Mar 2016 14:26:49 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201603262126.u2QLQjT0079960@gw.catspoiler.org> Date: Sat, 26 Mar 2016 14:26:45 -0700 (PDT) From: Don Lewis Subject: Re: CURRENT slow and shaky network stability To: imb@protected-networks.net cc: ohartman@zedat.fu-berlin.de, kmacy@freebsd.org, freebsd-current@freebsd.org In-Reply-To: <56F6C6B0.6010103@protected-networks.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 21:26:55 -0000 On 26 Mar, Michael Butler wrote: > -current is not great for interactive use at all. The strategy of > pre-emptively dropping idle processes to swap is hurting .. big time. > > Compare inactive memory to swap in this example .. > > 110 processes: 1 running, 108 sleeping, 1 zombie > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1819 imb 1 28 0 213M 11284K select 1 147:44 5.97% > gkrellm > 59238 imb 43 20 0 980M 424M select 0 10:07 1.92% > firefox > > .. it shouldn't start randomly swapping out processes because they're > used infrequently when there's more than enough RAM to spare .. I don't know what changed, and probably something can use some tweaking, but paging out idle processes isn't always the wrong thing to do. For instance if I'm using poudriere to build a bunch of packages and its heavy use of tmpfs is pushing the machine into many GB of swap usage, I don't want interactive use like: vi foo.c cc foo.c vi foo.c to suffer because vi and cc have to be read in from a busy hard drive each time while unused console getty and idle sshd processes in a bunch of jails are still hanging on to memory even though they haven't executed any instructions since shortly after the machine was booted weeks ago. > It also shows up when trying to reboot .. on all of my gear, 90 seconds > of "fail-safe" time-out is no longer enough when a good proportion of > daemons have been dropped onto swap and must be brought back in to flush > their data segments :-( That's a different and known problem. See: From owner-freebsd-current@freebsd.org Sat Mar 26 22:51:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 515EAADEA0B for ; Sat, 26 Mar 2016 22:51:13 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2AB01AD5 for ; Sat, 26 Mar 2016 22:51:12 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id e185so121785818vkb.1 for ; Sat, 26 Mar 2016 15:51:12 -0700 (PDT) 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:cc; bh=lefXkU4L8SX6rlDSpU5c6QATosGCSazztTHGPdTnefY=; b=oRNt9ICOZJT05vLQ//CV71rb/uu6wrWbJe9eOY6r2VRXAFiobwRqyRU7Ne0xwXe+Cc EVlRBvt71Gk0vc79n9BTeYOVoeapI6lu+d8NowTP/5Vwi3M/+/RLTVkZsXX0+USvoR4A XqjbsyLlLmuzN0YCVKpwAlXheOCLeNwakAzMBKPdjxb/IGaq66v6/Y6NODQW6PGGFxNx mqICEtjr9Md+cRh2fxbrWe1HCYmgiSGCizMlEuGjvVgihjTs7Qe3/MvZ+aztIf8H4vfm Dp9c7shNiOXa+I53INZBxbghbZ5cjELaL5Fu9pdYx78UIIuhpnD4bk8rO+SQFG9gy87y Qj0A== 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:cc; bh=lefXkU4L8SX6rlDSpU5c6QATosGCSazztTHGPdTnefY=; b=H69tnUeG1JccswQ6bL2aWZrUxqbxB2maORi5FPKzz2t6uqVPd2tsr0GjLqo/W2O+LR vgmmk6UfStd4Ju2uyH7QlRTRdAWbqRlCs9BmbV/tzObyuSXE/pHFukKjo4YMO7E2l1+o 8sBtKbkzpZFlX1MeO0+U8qfXU3c3yabFreIk5Xiecz3tajQSwJ2ptjWRApCvC59+VVWV BkwNwtVYSJ/FMEOZmEZwP+OnAchosa9Mjc7sspdIlEU7Zib/UvTJHF48Bk+pP+tvZOf1 0MtcGHaLF49H+u3R8+1XDC0U0CdnDi1BFP/oYmhqal9hxRpCKb4ipvEl/6tzW6Zbb/MF 4Ewg== X-Gm-Message-State: AD7BkJLAo7TbB4JM0BzIJaiKbPirlB1J5q+jN6UrF2CBk0PGfr1zYaAeEBMGAuI4OZKFHwGWmKxTfpDqk6JRpw== MIME-Version: 1.0 X-Received: by 10.159.37.150 with SMTP id 22mr7190857uaf.36.1459032672015; Sat, 26 Mar 2016 15:51:12 -0700 (PDT) Received: by 10.31.194.194 with HTTP; Sat, 26 Mar 2016 15:51:11 -0700 (PDT) In-Reply-To: <201603262126.u2QLQjT0079960@gw.catspoiler.org> References: <56F6C6B0.6010103@protected-networks.net> <201603262126.u2QLQjT0079960@gw.catspoiler.org> Date: Sat, 26 Mar 2016 18:51:11 -0400 Message-ID: Subject: Re: CURRENT slow and shaky network stability From: Ultima Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 22:51:13 -0000 Having this long timeout issue occur many times during the day. Normally not this bad, currently on r297060 amd64. A few hours ago had a system hang that lasted for about 1-2 hours.(not sure how long exactly, gave up waiting) It occured after a zfs destroy operation and affected sshd. (could no longer login via ssh) The system was in a seemingly unusable state during this time. A large zfs send was underway during the outage. This operation was not in the same state as the system receiving was still growing. Not sure if its related, sounds like it is. Any more information that maybe helpful? On Sat, Mar 26, 2016 at 5:26 PM, Don Lewis wrote: > On 26 Mar, Michael Butler wrote: > > -current is not great for interactive use at all. The strategy of > > pre-emptively dropping idle processes to swap is hurting .. big time. > > > > Compare inactive memory to swap in this example .. > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% idle > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > > COMMAND > > 1819 imb 1 28 0 213M 11284K select 1 147:44 5.97% > > gkrellm > > 59238 imb 43 20 0 980M 424M select 0 10:07 1.92% > > firefox > > > > .. it shouldn't start randomly swapping out processes because they're > > used infrequently when there's more than enough RAM to spare .. > > I don't know what changed, and probably something can use some tweaking, > but paging out idle processes isn't always the wrong thing to do. For > instance if I'm using poudriere to build a bunch of packages and its > heavy use of tmpfs is pushing the machine into many GB of swap usage, I > don't want interactive use like: > vi foo.c > cc foo.c > vi foo.c > to suffer because vi and cc have to be read in from a busy hard drive > each time while unused console getty and idle sshd processes in a bunch > of jails are still hanging on to memory even though they haven't > executed any instructions since shortly after the machine was booted > weeks ago. > > > It also shows up when trying to reboot .. on all of my gear, 90 seconds > > of "fail-safe" time-out is no longer enough when a good proportion of > > daemons have been dropped onto swap and must be brought back in to flush > > their data segments :-( > > That's a different and known problem. See: > < > https://svnweb.freebsd.org/base/releng/10.3/bin/csh/config_p.h?revision=297204&view=markup > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Sat Mar 26 22:58:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD092ADEBE4 for ; Sat, 26 Mar 2016 22:58:26 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 99D291E2B for ; Sat, 26 Mar 2016 22:58:25 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1B79B4FAE8; Sat, 26 Mar 2016 22:58:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2QMwMu7084491; Sat, 26 Mar 2016 22:58:22 GMT (envelope-from phk@phk.freebsd.dk) To: Ultima cc: freebsd-current@freebsd.org Subject: Re: CURRENT slow and shaky network stability In-reply-to: From: "Poul-Henning Kamp" References: <56F6C6B0.6010103@protected-networks.net> <201603262126.u2QLQjT0079960@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84489.1459033102.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2016 22:58:22 +0000 Message-ID: <84490.1459033102@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 22:58:26 -0000 -------- In message , Ultima writes: > A large zfs send [...] I am not running zfs. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Sat Mar 26 23:31:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68E7BADE3C5 for ; Sat, 26 Mar 2016 23:31:44 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48D9019E1 for ; Sat, 26 Mar 2016 23:31:44 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2QNVXVm080178; Sat, 26 Mar 2016 16:31:38 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201603262331.u2QNVXVm080178@gw.catspoiler.org> Date: Sat, 26 Mar 2016 16:31:33 -0700 (PDT) From: Don Lewis Subject: Re: CURRENT slow and shaky network stability To: phk@phk.freebsd.dk cc: ultima1252@gmail.com, freebsd-current@freebsd.org In-Reply-To: <84490.1459033102@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 23:31:44 -0000 On 26 Mar, Poul-Henning Kamp wrote: > -------- > In message > , Ultima writes: > >> A large zfs send [...] > > I am not running zfs. I am. I'm not seeing any unexpected problems. I haven't really loaded this system up with a big poudriere run since it's been booted. It's mostly just been singled-threaded compiles since then. A bit of swap is used and free memory is kind of low. In my case the culprit seems to be ARC. last pid: 28589; load averages: 1.06, 1.09, 1.08 up 3+15:55:10 16:12:51 71 processes: 2 running, 63 sleeping, 6 stopped CPU: 7.0% user, 0.0% nice, 0.9% system, 0.0% interrupt, 92.1% idle Mem: 564M Active, 6787M Inact, 23G Wired, 277M Buf, 656M Free ARC: 16G Total, 5494M MFU, 2062M MRU, 499K Anon, 573M Header, 8434M Other Swap: 40G Total, 4108K Used, 40G Free When I'm making heavy use of poudriere, swap usage goes up a lot and the pressure on free memory decreases the ARC size significantly. It's a headless machine accessed via ssh, so I won't see any issues with Xorgs and its clients getting paged out. Remote shell access seems to perform ok for me. Before r297203 I was running r296416 and really pushed it hard. I didn't observe any unexpected interactivity issues even with more than 10G of swap used and a load average over 50. I'd love to add more RAM, but the motherboard is at max capacity. The problems that some are describing sound a lot like lost interrupts or lost wakeups. The former could easily be hardware dependant. My FreeBSD 10.3-PRERELEASE desktop is worse under load. It also uses zfs, but only has 8 GB of RAM. The main culprit is firefox, which gets very bloated after a while. I've got some other hoggish processes on it, which doesn't help. From owner-freebsd-current@freebsd.org Sat Mar 26 23:36:48 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDA18ADE463 for ; Sat, 26 Mar 2016 23:36:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AB9D81BB2; Sat, 26 Mar 2016 23:36:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 26D784FAE8; Sat, 26 Mar 2016 23:36:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u2QNakK5084651; Sat, 26 Mar 2016 23:36:46 GMT (envelope-from phk@phk.freebsd.dk) To: Don Lewis cc: ultima1252@gmail.com, freebsd-current@freebsd.org Subject: Re: CURRENT slow and shaky network stability In-reply-to: <201603262331.u2QNVXVm080178@gw.catspoiler.org> From: "Poul-Henning Kamp" References: <201603262331.u2QNVXVm080178@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84649.1459035406.1@critter.freebsd.dk> Date: Sat, 26 Mar 2016 23:36:46 +0000 Message-ID: <84650.1459035406@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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, 26 Mar 2016 23:36:49 -0000 -------- In message <201603262331.u2QNVXVm080178@gw.catspoiler.org>, Don Lewis writes: >> I am not running zfs. Ohh, and I should probably add: I don't have a swap-space configured. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.