From owner-freebsd-current@FreeBSD.ORG Sat Apr 13 23:01:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7EB0C189 for ; Sat, 13 Apr 2013 23:01:31 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm19.bullet.mail.bf1.yahoo.com (nm19.bullet.mail.bf1.yahoo.com [98.139.212.178]) by mx1.freebsd.org (Postfix) with SMTP id 30D7D1704 for ; Sat, 13 Apr 2013 23:01:30 +0000 (UTC) Received: from [98.139.215.143] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 Received: from [76.13.13.228] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 Received: from [127.0.0.1] by smtp107-mob.biz.mail.ac4.yahoo.com with NNFMP; 13 Apr 2013 23:01:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365894090; bh=MB77me6FnuoXHyzsbc1NiiiUuXBdLnyjmV9Rp3CiesM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=LWrQLzEuSIBO1WBLNUYzWTxkW7FjY4lmOFfNUw3ys1/9qwhJ1VSragX1EgtD6ealPYCm2PL8dbbeYgm5cmIS/YHplj/NFAKEY2rbgsHeLPQ7e3qKGsjKUkdQxAm91gIR7V2EBJblxeknQq7KZezzOKnFdVY9Un/w5+kQ8kNRmEc= X-Yahoo-Newman-Id: 345441.26413.bm@smtp107-mob.biz.mail.ac4.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Mu3qXagVM1mdY3BXwVvJdbJUVa2H2gL41i2RNLg05aCBpnd 3_UdCuRRAFR5VgIuehgNHl.rdN0vFOY7ygp9uM0YgupuxizNPg0cYFigZdSn r8lOmR6gjD13wsZQZK.wNa9kou.4NUQG0OrfkpEUXTJGPXSl6d5Vog4sLbdH tBp4EasnWpXtXL28G203PjEJj914NfbJGIA00noKyVSK1SxDpOHr4RJ1YquV dYkWXedF7SWDTXGsnjhmMp_FpBhInLAxR61ZXfuGU3hTYIY3.pdn_yXDxl_o tgsKnvt6c1iZNfF0wosKZJ0MzhRfKCdXkV6O6maHoAJSxB4ihw9qdGVYd066 5Aikl.exTa5vltaKpjzoewWYYaV5Cc8hWTyrkRep9Z7hpcJhwd_ZPnb0sDSI 3P9h12k52cyfsmetbYSn3WdYPIbVdh_E_ZMzwODRFhAJhylq5eECmNDkWlT3 EfR5rlYkd0kjRy.0USck1dK0_ZSlMeydb X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.184.10.106] (scott4long@70.196.197.242 with xymcookie) by smtp107-mob.biz.mail.ac4.yahoo.com with SMTP; 13 Apr 2013 16:01:30 -0700 PDT References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> X-Mailer: iPhone Mail (10B329) From: Scott Long Subject: Re: ipfilter(4) needs maintainer Date: Sat, 13 Apr 2013 17:01:29 -0600 To: Rui Paulo X-Mailman-Approved-At: Sun, 14 Apr 2013 00:36:08 +0000 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Apr 2013 23:01:31 -0000 On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote: > On 2013/04/13, at 5:03, Scott Long wrote: >> You target audience for this isn't people who track CURRENT, it's people w= ho are on 7, 8, or 9 and looking to update to 10.x sometime in the future. >=20 > Yes, I'm aware of that, but the problem remains. If ipfilter is broken or g= ets broken because of the networking stack changes, we'll have to fix it to k= eep the deprecation path going... >=20 Welcome to the challenges of maintaining a whole OS :-) >>>> So with that said, would it be possible to write some tutorials on how t= o migrate an ipfilter installation to pf? Maybe some mechanical syntax docs= accompanied by a few case studies? Is it possible for a script to automate= some of the common mechanical changes? Also essential is a clear document o= n what goes away with ipfilter and what is gained with pf. Once those tools= are written, I suggest announcing that ipfilter is available but deprecated= /unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain pe= ople will still pitch a fit about it departing, but if the tools are there t= o help the common users, you'll be successful in winning mindshare and gener= al support. >>>=20 >>>=20 >>> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, b= ut I'm not sure automated tools exist. I'm also not convinced we need to wri= te them and I think the issue can be deal with by writing a bunch of example= s on how to do it manually. Then we can give people 1y to switch. >>=20 >> Please believe me that no matter how trivial you think the switch is, a m= igration guide still needs to be written. >=20 >=20 > A migration *guide*, yes. Tools to convert one syntax to another: no. >=20 Ok, so in response to this and to Glebs email, lets rephrase the call for he= lp into a call for someone with ipfilter experience to help write a migratio= n guide. Like I said, this isn't about migrating from 10-current to 10-curr= ent prime, it about migrating from 7/8/9 where up ipfilter does work. Maybe= look for old openbsd docs and mailing list items from when they did their f= orced migration. Maybe fish for help by announcing the deprecation and remo= val schedule and hook whomever complains into helping instead. Maybe someth= ing else, but whatever it is, it should be done. If you and Gleb don't want= to do this, I will. Scott From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 00:41:39 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0927FE46; Sun, 14 Apr 2013 00:41:39 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id E260A1A9B; Sun, 14 Apr 2013 00:41:38 +0000 (UTC) Received: from [10.249.237.150] (mobile-166-137-186-177.mycingular.net [166.137.186.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id AACEE3981E; Sat, 13 Apr 2013 17:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1365900098; bh=dsZ+/nqmoTgXE5nDl3DmzzTldHUxbn6A8eFlPszgJbw=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=jzodYpsG0p2kVReRg59fWF3+koMiX2Ki3swgyaDDAiIgjql1gKwN1I3B1suSIPSf+ QX7L3Ph05M0uXbhxd8euqj/cVzCAKC0ywoiR+ZvY2j1CrfHpUhEE7TDrlUsVh+Mxj2 bH2TKsBOBO3t686PYYuetMsPboF2R4A1YAh3LjWE= References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> Message-Id: X-Mailer: iPhone Mail (10B329) From: Rui Paulo Subject: Re: ipfilter(4) needs maintainer Date: Sat, 13 Apr 2013 17:41:35 -0700 To: Scott Long X-Mailman-Approved-At: Sun, 14 Apr 2013 01:48:11 +0000 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 00:41:39 -0000 2013/04/13 16:01=1B$B!"=1B(BScott Long =1B$B$N%a%C%;!= <%8=1B(B: > Maybe something else, but whatever it is, it should be done. If you and G= leb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html= From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 04:43:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6C2AEDC2; Sun, 14 Apr 2013 04:43:13 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BFF1FA; Sun, 14 Apr 2013 04:43:12 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id 3so1986250pdj.41 for ; Sat, 13 Apr 2013 21:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ebm1EF4GfpJVSi0UttD5hl7ZY4dVarY3dFYt4itymgE=; b=Md5PeNsX+dLy6bzfHSrC+8lIYPF4nzRDxRK95+hTtpp9r/6sG7Z08o/nC+zvw7+5kW iQvpgJv6oC8ZoKVrNz30n8nEIhfHHdpq1+OpbXF1kKR51em9QQTJng9xw3AN6ATwFgRu 72sW37AVYF5jvoG+Nn9QpyyBM4R5fRKFKDARt4GpuP3IDDkNNaapOoPLmfL3gLQ33E+7 mXn/GzHcesN95q6KVJgucX6NMuVj887kiDrZvc8TOqCzmcUnfqBAxByiEi05hEwtV7Ji SzhOVCnxfacpeMYAhZws6evKB3UsFUHOANZu+JIP5+6TzmSp/kLLbFw3V8RBLSuAem2B Wg/Q== X-Received: by 10.68.112.1 with SMTP id im1mr23026220pbb.169.1365914592443; Sat, 13 Apr 2013 21:43:12 -0700 (PDT) Received: from localhost (c-67-160-248-74.hsd1.ca.comcast.net. [67.160.248.74]) by mx.google.com with ESMTPS id n6sm67124pbn.6.2013.04.13.21.43.09 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 21:43:10 -0700 (PDT) Sender: Gleb Kurtsou Date: Sat, 13 Apr 2013 21:43:14 -0700 From: Gleb Kurtsou To: Shawn Webb , pjd@freebsd.org Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 Message-ID: <20130414044314.GA1115@reks> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 04:43:13 -0000 On (22/03/2013 11:51), Shawn Webb wrote: > Hey All, > > I'm not sure if this is a result of r248583 or a different commit, but I > hit a kernel panic when closing Chrome. I've linked to the info and > core.txt files below. If you need me to ship you the vmcore file, let me > know. It's 1.1GB in size. > > Other than the pasted files, I'm not too sure where to go from here. If > there's any other info you need, please let me know. I'm a newb at > submitting this kind of stuff. > > Paste of info file: http://ix.io/4Qo > Paste of core.txt file: http://ix.io/4Qp Shawn, did you find workaround for the problem? I've just upgraded to recent HEAD and see the same panic on closing chrome. Switching back to r247601 just before "Merge Capsicum overhaul" commit makes panic disappear. ~ # kgdb -n 1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: VNASSERT failed 0xfffffe0196700760: tag none, type VBAD usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VV_NOSYNC|VI_DOOMED) lock type zfs: UNLOCKED panic: No vop_advlock(0xfffffe0196700760, 0xffffff823adb9908) cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff823adb9740 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff823adb97f0 vpanic() at vpanic+0x127/frame 0xffffff823adb9830 kassert_panic() at kassert_panic+0x136/frame 0xffffff823adb98a0 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x92/frame 0xffffff823adb98d0 closef() at closef+0x9a/frame 0xffffff823adb9960 closefp() at closefp+0xa0/frame 0xffffff823adb99b0 amd64_syscall() at amd64_syscall+0x1f9/frame 0xffffff823adb9ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff823adb9ab0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80aeaaa8a, rsp = 0x7ffffebf3f38, rbp = 0x7ffffebf3f50 --- [...] (kgdb) fr 0 #0 doadump (textdump=1) at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) up #1 0xffffffff804f5827 in kern_reboot (howto=260) at /freebsd-src/local/sys/kern/kern_shutdown.c:447 447 doadump(TRUE); (kgdb) #2 0xffffffff804f5d36 in vpanic (fmt=, ap=) at /freebsd-src/local/sys/kern/kern_shutdown.c:754 754 kern_reboot(bootopt); (kgdb) #3 0xffffffff804f5bc6 in kassert_panic (fmt=) at /freebsd-src/local/sys/kern/kern_shutdown.c:642 642 vpanic(fmt, ap); (kgdb) #4 0xffffffff80747aa2 in VOP_ADVLOCK_APV (vop=, a=0xffffff823adb9908) at vnode_if.c:2522 2522 VNASSERT(vop != NULL, a->a_vp, ("No vop_advlock(%p, %p)", a->a_vp, a)); (kgdb) #5 0xffffffff804b8eaa in closef (fp=0xfffffe014da8ccd0, td=0xfffffe0014aea920) at vnode_if.h:1041 1041 vnode_if.h: No such file or directory. in vnode_if.h (kgdb) #6 0xffffffff804b7030 in closefp (fdp=0xfffffe001c8c4800, fd=, fp=0xfffffe014da8ccd0, td=0xfffffe0014aea920, holdleaders=) at /freebsd-src/local/sys/kern/kern_descrip.c:1136 1136 error = closef(fp, td); (kgdb) p *fp $5 = {f_data = 0xfffffe0196700760, f_ops = 0xffffffff80a477b8, f_cred = 0xfffffe0067907600, f_vnode = 0xfffffe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3, f_count = 0, f_seqcount = 0, f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset = 16388, f_label = 0x0} (kgdb) p *fp $6 = {f_data = 0xfffffe0196700760, f_ops = 0xffffffff80a477b8, f_cred = 0xfffffe0067907600, f_vnode = 0xfffffe0196700760, f_type = 1, f_vnread_flags = 0, f_flag = 3, f_count = 0, f_seqcount = 0, f_nextoff = 16388, f_vnun = {fvn_cdevpriv = 0x0, fvn_advice = 0x0}, f_offset = 16388, f_label = 0x0} (kgdb) p fp->f_vnode $7 = (struct vnode *) 0xfffffe0196700760 (kgdb) p *fp->f_vnode $8 = {v_tag = 0xffffffff807a3e35 "none", v_op = 0x0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = { tqe_next = 0xfffffe014fd95760, tqe_prev = 0xfffffe011d500958}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = { lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe01967007b0}, v_cache_dd = 0x0, v_lock = {lock_object = {lo_name = 0xffffffff80dddbb1 "zfs", lo_flags = 91881472, lo_data = 0, lo_witness = 0x0}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = { lock_object = {lo_name = 0xffffffff807bfbb9 "vnode interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0x0}, mtx_lock = 6}, v_vnlock = 0xfffffe01967007c8, v_actfreelist = { tqe_next = 0xfffffe0031985b10, tqe_prev = 0xfffffe014fd95820}, v_bufobj = {bo_mtx = {lock_object = { lo_name = 0xffffffff807bfbc9 "bufobj interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0x0}, mtx_lock = 6}, bo_ops = 0xffffffff80a5af10, bo_object = 0x0, bo_synclist = { le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffffe0196700760, __bo_vnode = 0xfffffe0196700760, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe0196700880}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe01967008a0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe01967008e8}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 0, v_usecount = 0, v_iflag = 128, v_vflag = 4, v_writecount = 0, v_hash = 26636295, v_type = VBAD} # kgdb -n 0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: negative refcount 0xfffffe0059a400c8 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff823aff8770 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff823aff8820 vpanic() at vpanic+0x127/frame 0xffffff823aff8860 kassert_panic() at kassert_panic+0x136/frame 0xffffff823aff88d0 closef() at closef+0x1ff/frame 0xffffff823aff8960 closefp() at closefp+0xa0/frame 0xffffff823aff89b0 amd64_syscall() at amd64_syscall+0x1f9/frame 0xffffff823aff8ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff823aff8ab0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80aeaaa8a, rsp = 0x7fffffffbd28, rbp = 0x7fffffffbd40 --- Uptime: 21m3s [...] (kgdb) bt #0 doadump (textdump=1) at pcpu.h:231 #1 0xffffffff804f5827 in kern_reboot (howto=260) at /freebsd-src/local/sys/kern/kern_shutdown.c:447 #2 0xffffffff804f5d36 in vpanic (fmt=, ap=) at /freebsd-src/local/sys/kern/kern_shutdown.c:754 #3 0xffffffff804f5bc6 in kassert_panic (fmt=) at /freebsd-src/local/sys/kern/kern_shutdown.c:642 #4 0xffffffff804b900f in closef (fp=, td=) at refcount.h:66 #5 0xffffffff804b7030 in closefp (fdp=0xfffffe018dc79800, fd=, fp=0xfffffe0059a400a0, td=0xfffffe016dfca920, holdleaders=) at /freebsd-src/local/sys/kern/kern_descrip.c:1136 #6 0xffffffff806e26c9 in amd64_syscall (td=0xfffffe016dfca920, traced=0) at subr_syscall.c:134 #7 0xffffffff806cb13b in Xfast_syscall () at exception.S:387 #8 0x000000080aeaaa8a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) > > Thanks, > > Shawn Webb > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 08:40:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1333D0F; Sun, 14 Apr 2013 08:40:36 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF4C74B; Sun, 14 Apr 2013 08:40:36 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so4740453ieb.17 for ; Sun, 14 Apr 2013 01:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=j6CYPWbmUIJ9tIyfIuVujfLw+s4CdoYucG5iMRLWAkU=; b=xEyI/CSe7QCYcOOlpXLUJMF+mVQmOxZqxJ4GHkENPonmrr7ylt0F2AW4N6DynUmPTE rLrJExSbZ/3Iq97MDTyLeYvm3FGKEAPaNoGdLI6Mo4wQj3wH72OWiBK3SqCSwnNK3Bdx dbVgMka00FhSZu1gT2Sw5roJa+Q64OCNyaREzpGsh7dpPjx76Iu3DeWFJpu36EqfUi/y z4yAGePF99HwGkZOjuO2FopiHUngxtdDpFXc6c5gIYUqPAA/Bz8XQBXCxEGGGuBKWQUQ wgAttrf/sOvtpM+2L6IQJSMe2sf0mpk7LUjsyE9FDzSlunMJ8zSUOETvBYpWlqpPUWCp Rmyw== X-Received: by 10.50.13.175 with SMTP id i15mr2922926igc.75.1365928836044; Sun, 14 Apr 2013 01:40:36 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Sun, 14 Apr 2013 01:40:04 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Chris Rees Date: Sun, 14 Apr 2013 09:40:04 +0100 X-Google-Sender-Auth: ihKLwSBt2G9ZOR1EEAWe6oNhbzg Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Rui Paulo Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Scott Long , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 08:40:36 -0000 On 14 April 2013 01:41, Rui Paulo wrote: > 2013/04/13 16:01$B!"(BScott Long $B$N%a%C%;!<%8(B: > >> Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. > > I already started writing a guide. See here for a very incomplete version: > > http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff Chris From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 09:54:48 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C03AC01; Sun, 14 Apr 2013 09:54:48 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D07748DB; Sun, 14 Apr 2013 09:54:47 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C14A728423; Sun, 14 Apr 2013 11:54:39 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id AC2EC28429; Sun, 14 Apr 2013 11:54:38 +0200 (CEST) Message-ID: <516A7CDD.7080201@quip.cz> Date: Sun, 14 Apr 2013 11:54:37 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 09:54:48 -0000 Rui Paulo wrote: > 2013/04/13 16:01$B!"(BScott Long $B$N%a%C%;!<%8(B: > >> Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. > > I already started writing a guide. See here for a very incomplete version: > > http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html 1.1 ipftest PF rules can be checked with pfctl -n: -n Do not actually load rules, just parse them For example: pfctl -nvf /etc/pf.conf.tmp 3 Examples 3.1 Filtering ipf.conf and pf.conf has the same syntax for basic filtering rules, so you can use it on the right side to: block in on le0 proto tcp from 10.1.1.1/32 to any pass in proto tcp from 10.1.0.0/16 port = 23 to 10.2.0.0/16 flags A/A Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 13:20:06 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD8FC21F; Sun, 14 Apr 2013 13:20:06 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 62878F20; Sun, 14 Apr 2013 13:20:04 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Apr 2013 06:20:05 -0700 Message-ID: <516AAD01.1090201@a1poweruser.com> Date: Sun, 14 Apr 2013 09:20:01 -0400 From: Joe User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> In-Reply-To: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2013 13:20:05.0164 (UTC) FILETIME=[C706F6C0:01CE3912] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: Gleb Smirnoff , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 13:20:06 -0000 Rui Paulo wrote: > On 2013/04/12, at 22:31, Scott Long wrote: > >> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >> >>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>> >>>> Lack of maintainer in a near future would lead to bitrot due to changes >>>> in other areas of network stack, kernel APIs, etc. This already happens, >>>> many changes during 10.0-CURRENT cycle were only compile tested wrt >>>> ipfilter. If we fail to find maintainer, then a correct decision would be >>>> to remove ipfilter(4) from the base system before 10.0-RELEASE. >>> This has been discussed in the past. Every time someone came up and said "I'm still using ipfilter!" and the idea to remove it dies with it. >>> I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. >>> >> One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing "ipfilter is going away. EOM" is inadequate and leads to completely justified complaints from users. > > I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. > >> So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. > > > It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. > > Regards, > -- > Rui Paulo > Wow boys, This conversation has gotten way off track. Looking for a maintainer for ipfilter is totally different than opening the dead subject of removing ipfilter from the system. Look at openbsd's pf, its been forked and is now freebsd maintained. New upstream versions of Ipfilter have always needed tweaking before it can be included in the base system. If your unsatisfied with the lack of bug fixes, then ask the author for special permission to create a fork if his license don't allow it now. The point is: ipfilter is part of FreeBSD and you are never going to remove it. Accept that fact. So look for alternate ways to address your concerns about ipfilter bug fixs getting applied and/or updating ipfilter to function with vimage or changes to the Freebsd network stack and kernel APIs. Finding a maintainer is the purpose of this post, and the solution to your concerns, so lets stay on subject, OK. From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 13:26:00 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AA583E4; Sun, 14 Apr 2013 13:26:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C0F23F5E; Sun, 14 Apr 2013 13:25:59 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r3EDPn9K002035; Sun, 14 Apr 2013 07:25:49 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <516AAD01.1090201@a1poweruser.com> Date: Sun, 14 Apr 2013 07:25:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> To: Joe X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Gleb Smirnoff , Rui Paulo , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 13:26:00 -0000 On Apr 14, 2013, at 7:20 AM, Joe wrote: > Rui Paulo wrote: >> On 2013/04/12, at 22:31, Scott Long wrote: >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>>=20 >>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>>>=20 >>>>> Lack of maintainer in a near future would lead to bitrot due to = changes >>>>> in other areas of network stack, kernel APIs, etc. This already = happens, >>>>> many changes during 10.0-CURRENT cycle were only compile tested = wrt >>>>> ipfilter. If we fail to find maintainer, then a correct decision = would be >>>>> to remove ipfilter(4) from the base system before 10.0-RELEASE. >>>> This has been discussed in the past. Every time someone came up and = said "I'm still using ipfilter!" and the idea to remove it dies with it. = I've been saying we should remove it for 4 years now. Not only it's = outdated but it also doesn't not fit well in the FreeBSD roadmap. Then = there's the question of maintainability. We gave the author a commit bit = so that he could maintain it. That doesn't happen anymore and it sounds = like he has since moved away from FreeBSD. I cannot find any reason to = burden another FreeBSD developer with maintaining ipfilter. >>>>=20 >>> One thing that FreeBSD is bad about (and this really applies to many = open source projects) when deprecating something is that the developer = and release engineering groups rarely provide adequate, if any, tools to = help users transition and cope with the deprecation. The fear of = deprecation can be largely overcome by giving these users a clear and = comprehensive path forward. Just announcing "ipfilter is going away. = EOM" is inadequate and leads to completely justified complaints from = users. >> I agree with the deprecation path, but given the amount of changes = that happened in the last 6 months, I'm not even sure ipfilter is = working fine in FreeBSD CURRENT, but I haven't tested it. >>> So with that said, would it be possible to write some tutorials on = how to migrate an ipfilter installation to pf? Maybe some mechanical = syntax docs accompanied by a few case studies? Is it possible for a = script to automate some of the common mechanical changes? Also = essential is a clear document on what goes away with ipfilter and what = is gained with pf. Once those tools are written, I suggest announcing = that ipfilter is available but deprecated/unsupported in FreeBSD 10, and = will be removed from FreeBSD 11. Certain people will still pitch a fit = about it departing, but if the tools are there to help the common users, = you'll be successful in winning mindshare and general support. >> It's not very difficult to switch an ipf.conf/ipnat.conf to a = pf.conf, but I'm not sure automated tools exist. I'm also not convinced = we need to write them and I think the issue can be deal with by writing = a bunch of examples on how to do it manually. Then we can give people 1y = to switch. >> Regards, >> -- >> Rui Paulo >=20 > Wow boys, This conversation has gotten way off track. Looking for a = maintainer for ipfilter is totally different than opening the dead = subject of removing ipfilter from the system. >=20 The project has been in search of a maintainer for ipfilter for many = years. Gleb's most recent plea is just the latest round in this loose = battle. > Look at openbsd's pf, its been forked and is now freebsd maintained. = New upstream versions of Ipfilter have always needed tweaking before it = can be included in the base system. If your unsatisfied with the lack of = bug fixes, then ask the author for special permission to create a fork = if his license don't allow it now. >=20 > The point is: ipfilter is part of FreeBSD and you are never going to = remove it. Accept that fact. >=20 Negative, amigo. Without passionate interest in developing ipfilter, = it's just a roadblock and an eyesore. Abandonware needs to be culled. Scott From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 13:49:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C26C639; Sun, 14 Apr 2013 13:49:20 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 200D4FCD; Sun, 14 Apr 2013 13:49:18 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id eh20so2591374lab.6 for ; Sun, 14 Apr 2013 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=yGHs6ot0jCTDCIITcy6xcXi3uFPB7IiAlnkfkUHOXRw=; b=CoYySB/ziHTaPj8aJogTg5CguUZjO/gqbnCpQv9MNniz6NQaH2GkjFrSnGDz+5DNhV 5MQOLZbf1p17tKduly7YT3NnXSG9i8u67ceYipLdTrke1lk/3mG2+OEqDo7860RXo3kZ PhyRyfUuZPLJ8ySrdnEWpI+C5Sesen7+nvwYgO3DxeRKR6tzAECamQwfJqI+xwwd+uzc GMlrUjdYgMdG41zcjoZDGQunILmypn9eqPUuhJxQPXoHs3cTVaBVWcgtO93upVVG4Wkb vsW1hXZ4h35zdTZbUcLDriDglJJ1sbp8TtBheST1N8F+pQuGAFNXQTphLCf7xNVSWnqr ldlA== X-Received: by 10.152.135.205 with SMTP id pu13mr4693876lab.48.1365947357996; Sun, 14 Apr 2013 06:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.60.196 with HTTP; Sun, 14 Apr 2013 06:48:36 -0700 (PDT) In-Reply-To: <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> From: Odhiambo Washington Date: Sun, 14 Apr 2013 16:48:36 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org, Joe , Rui Paulo , Gleb Smirnoff , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 13:49:20 -0000 I do not stand in any good stead to comment on this, but I have used IPFilter more extensively than PF when it comes to FreeBSD and packet manipulations. As a user, what I can say is this: 1. The only firewall that seems 'native' to FreeBSD is ipfw and I believe it works very well for some users who are able to adapt to it's syntax. 2. PF is being felt to be part of FreeBSD, but it too lags far behind OpenBSD implementation - almost like it's unmaintained. There has been debates about this which were never concluded. Most of you will agree with me on this. IPFilter is obviously NOT going to make it in 10.x and never releases because of those changes which have led to this thread/debate. So my take is there is a very simple answer/solution to this debate, which conforms to the K.I.S.S principle: 3. There is NO need to look for a maintainer. Simply DEPRECATE IPFilter from 10.x and put out a BIG Notice/Billboard somewhere where whoever needs to run FreeBSD because of IPFilter will find it. I doubt there is such a person anywhere because there are firewall implementations out there that can address this. Just put it out somewhere that IPFilter is NOT AVAILABLE on FreeBSD 10.x upwards and go ahead and remove it from the system. Nobody will complain. If anyone does, tell them that IPFilter is supported on FreeBSD upto 8.x (or is it 9.x? On my 9.x systems I use PF). 4. It's pretty easy for a newcomer to adopt and adapt to a firewall that is properly supported. Newcomers don't have much choice anyway. They decide to go with a system after finding out that it "meets their requirements". Let's remember that there are other Unix variants out there with Firewall implementations too. I hope this helps you big boys settle this debate. On 14 April 2013 16:25, Scott Long wrote: > > On Apr 14, 2013, at 7:20 AM, Joe wrote: > > > Rui Paulo wrote: > >> On 2013/04/12, at 22:31, Scott Long wrote: > >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > >>> > >>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > >>>> > >>>>> Lack of maintainer in a near future would lead to bitrot due to > changes > >>>>> in other areas of network stack, kernel APIs, etc. This already > happens, > >>>>> many changes during 10.0-CURRENT cycle were only compile tested wrt > >>>>> ipfilter. If we fail to find maintainer, then a correct decision > would be > >>>>> to remove ipfilter(4) from the base system before 10.0-RELEASE. > >>>> This has been discussed in the past. Every time someone came up and > said "I'm still using ipfilter!" and the idea to remove it dies with it. > I've been saying we should remove it for 4 years now. Not only it's > outdated but it also doesn't not fit well in the FreeBSD roadmap. Then > there's the question of maintainability. We gave the author a commit bit so > that he could maintain it. That doesn't happen anymore and it sounds like > he has since moved away from FreeBSD. I cannot find any reason to burden > another FreeBSD developer with maintaining ipfilter. > >>>> > >>> One thing that FreeBSD is bad about (and this really applies to many > open source projects) when deprecating something is that the developer and > release engineering groups rarely provide adequate, if any, tools to help > users transition and cope with the deprecation. The fear of deprecation > can be largely overcome by giving these users a clear and comprehensive > path forward. Just announcing "ipfilter is going away. EOM" is inadequate > and leads to completely justified complaints from users. > >> I agree with the deprecation path, but given the amount of changes that > happened in the last 6 months, I'm not even sure ipfilter is working fine > in FreeBSD CURRENT, but I haven't tested it. > >>> So with that said, would it be possible to write some tutorials on how > to migrate an ipfilter installation to pf? Maybe some mechanical syntax > docs accompanied by a few case studies? Is it possible for a script to > automate some of the common mechanical changes? Also essential is a clear > document on what goes away with ipfilter and what is gained with pf. Once > those tools are written, I suggest announcing that ipfilter is available > but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD > 11. Certain people will still pitch a fit about it departing, but if the > tools are there to help the common users, you'll be successful in winning > mindshare and general support. > >> It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, > but I'm not sure automated tools exist. I'm also not convinced we need to > write them and I think the issue can be deal with by writing a bunch of > examples on how to do it manually. Then we can give people 1y to switch. > >> Regards, > >> -- > >> Rui Paulo > > > > Wow boys, This conversation has gotten way off track. Looking for a > maintainer for ipfilter is totally different than opening the dead subject > of removing ipfilter from the system. > > > > The project has been in search of a maintainer for ipfilter for many > years. Gleb's most recent plea is just the latest round in this loose > battle. > > > Look at openbsd's pf, its been forked and is now freebsd maintained. New > upstream versions of Ipfilter have always needed tweaking before it can be > included in the base system. If your unsatisfied with the lack of bug > fixes, then ask the author for special permission to create a fork if his > license don't allow it now. > > > > The point is: ipfilter is part of FreeBSD and you are never going to > remove it. Accept that fact. > > > > Negative, amigo. Without passionate interest in developing ipfilter, it's > just a roadblock and an eyesore. Abandonware needs to be culled. > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 15:18:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB9524B1 for ; Sun, 14 Apr 2013 15:18:41 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id AF823281 for ; Sun, 14 Apr 2013 15:18:41 +0000 (UTC) Received: from pool-141-154-241-44.bos.east.verizon.net ([141.154.241.44] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UROhP-000LdF-G7; Sun, 14 Apr 2013 15:18:35 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r3EFIVea055092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 14 Apr 2013 11:18:32 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 141.154.241.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Oodk0tgdJLrM55p69c7// Date: Sun, 14 Apr 2013 11:18:23 -0400 From: "J.R. Oldroyd" To: Alexander Leidinger Subject: Re: DTrace of radeonkms on 9.1 Message-ID: <20130414111823.19e30e63@shibato> In-Reply-To: <20130401143652.00001870@unknown> References: <20130327180714.5beae7d6@shibato> <20130401143652.00001870@unknown> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/cfxMsEF0P/4pgVqjEC0kB6K"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Sun, 14 Apr 2013 11:18:32 -0400 (EDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD shortcircuit=no autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 15:18:41 -0000 --Sig_/cfxMsEF0P/4pgVqjEC0kB6K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 1 Apr 2013 14:36:52 +0200 Alexander Leidinger wrote: > > On Wed, 27 Mar 2013 18:07:14 -0400 > "J.R. Oldroyd" wrote: >=20 > > Is there any known magic involved in getting DTrace to do its thing on > > 9.1-release? > >=20 > > I am trying to use it to debug a memory leak problem with the > > radeonkms driver under 9.x. >=20 > Can you check if you have the same dtrace-problem with -current? I > would expect that 9.1 already has some dtrace-fixes regarding new > probes in run-time loaded modules, this is just to verify this > assumption. >=20 > Assuming there is some kind of dead-lock in this module-load interaction > with dtrace, you could modify the radeonkms module to do it's > initialization magic once a sysctl is set to 1, instead of doing this > magic at module-load time. This way you could load the module, start > the dtrace script and then issue the magic sysctl. >=20 > Bye, > Alexander. >=20 Thanks for the suggestion. The problem I was hoping to use DTrace to debug turned out to be an incompletely back-ported vm_alloc_page_contig() function. This was discovered using careful code analysis. Having improved the back-port of this function, the radeonkms driver is now running fine on 9.1-release. The need for DTtrace has therefore gone away for the time being. That said, the back-port of the VM function is not 100%, yet. I've had to put this on hold due to other commitments, but when I get back to this, I probably need to talk to our VM experts to get a list of commits that will be needed to properly merge that function into 9-stable. -jr --Sig_/cfxMsEF0P/4pgVqjEC0kB6K Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFqyMcACgkQls33urr0k4lWgQCeJYAVlvXKHB32kaj02hIg/gKE HRgAnj0uLakPdTIq8oqcb7e9/lbK46QI =U+9J -----END PGP SIGNATURE----- --Sig_/cfxMsEF0P/4pgVqjEC0kB6K-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 15:48:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E456BAAB; Sun, 14 Apr 2013 15:48:41 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7562C364; Sun, 14 Apr 2013 15:48:41 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r3EFmXTe010600; Sun, 14 Apr 2013 09:48:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r3EFmXn2010597; Sun, 14 Apr 2013 09:48:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 14 Apr 2013 09:48:33 -0600 (MDT) From: Warren Block To: Chris Rees Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message-ID: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) 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]); Sun, 14 Apr 2013 09:48:33 -0600 (MDT) Cc: "net@freebsd.org" , Scott Long , Rui Paulo , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 15:48:42 -0000 On Sun, 14 Apr 2013, Chris Rees wrote: > On 14 April 2013 01:41, Rui Paulo wrote: >> 2013/04/13 16:01?Scott Long ??????: >> >>> Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. >> >> I already started writing a guide. See here for a very incomplete version: >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html > > If you're really serious about deprecating ipf, we absolutely have to > remove instructions for it from the Handbook as soon as possible; > every time a new user comes across instructions you're going to have > yet another annoyed party. > > http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Is it possible to move ipfilter into a port? From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 15:52:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25BF7CC1; Sun, 14 Apr 2013 15:52:30 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 40773397; Sun, 14 Apr 2013 15:52:29 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id er20so3730908lab.28 for ; Sun, 14 Apr 2013 08:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xm7wVX3Jbkg0iGoCFAfLmc0uDn94rPvxjXPXNJMdqKM=; b=WecU7kMSxnX+lrUOIJ50t6OnUMg4UhLhMPy9W/jF3ZQReOA8lJj5sQR0KlXoUQmmwW rDgmGwWf/wysfHiOc5uwteiQPYJqyQvCoUUlkK82GjAHiXhLjJXoBeUGnU5cQogLu3q/ XXoBO2dB4TammDUYrlfIcDD0hnaY6Jjmnk1k5sIsPRCRiCIKVs3DRX/Wod1UbnOpAi8p npt+sbR2kInvRsXOseNLpYY7W1H3RBFYLuXtHtuDRVo8zn6ZYQLtOkMFhEA17y4vQKR8 eR5AB4CZnUAbIGFgTYjJHh65GlM9K6OrXDJOoS4FcVgJGpvxvRtI696ok6u2WzXQpbwZ 48xA== X-Received: by 10.112.168.5 with SMTP id zs5mr4649761lbb.66.1365954748052; Sun, 14 Apr 2013 08:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.60.196 with HTTP; Sun, 14 Apr 2013 08:51:47 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Odhiambo Washington Date: Sun, 14 Apr 2013 18:51:47 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 15:52:30 -0000 It's NOT possible, because someone has to handle the kernel hooks, which is the contention. Mark as deprecated, remove the HandBook section, but only for 10.x On 14 April 2013 18:48, Warren Block wrote: > On Sun, 14 Apr 2013, Chris Rees wrote: > > On 14 April 2013 01:41, Rui Paulo wrote: >> >>> 2013/04/13 16:01?Scott Long ??????: >>> >>> >>> Maybe something else, but whatever it is, it should be done. If you >>>> and Gleb don't want to do this, I will. >>>> >>> >>> I already started writing a guide. See here for a very incomplete >>> version: >>> >>> http://people.freebsd.org/~**rpaulo/ipf-deprecation/**article.html >>> >> >> If you're really serious about deprecating ipf, we absolutely have to >> remove instructions for it from the Handbook as soon as possible; >> every time a new user comes across instructions you're going to have >> yet another annoyed party. >> >> http://www.bayofrum.net/~**crees/patches/remove-ipf.diff >> > > This should probably be done like we did for CVS for ports. Mark it as > deprecated, then remove the Handbook section once the code is removed. > > Is it possible to move ipfilter into a port? > > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 15:53:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96984E64; Sun, 14 Apr 2013 15:53:05 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB7E3DB; Sun, 14 Apr 2013 15:53:05 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id e14so4963060iej.2 for ; Sun, 14 Apr 2013 08:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QVz0sLjFxVr5CRAkLAvgVSpFsn7WfVIkm1lqrVKRjyQ=; b=p4qoapX3FlDQhtQEB6/pKURj4O/u0svwtyLzp/Bf+OmSNYiiabVRmeM/i3UUUL+EzN PzS10xaeMXrtOgtSrgBjk9UobXMx8EGoe1cLai8Xh+qAY5oXaNP079hkH/UFejvfDTrx 4AfEbz0CUX9kyCr9ZXzh6xVmt02VCFzOWeIXMw479wRd7UmLvb3Zom2/PFDtTrcnhgaV ENzeJfwCk3Bd5QwzI/0o6wqIcK+L3Asn//flLHF12oUP5pSLaErL4Rd2+p8vi6rGamwu TdBLohoPKglup8mOPpeHcgW2bVTIvhF4uLk8JvieGajtFZpLhTXXIN2gbJmA+LOTBDCq tinw== X-Received: by 10.50.197.170 with SMTP id iv10mr3254220igc.62.1365954785041; Sun, 14 Apr 2013 08:53:05 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Sun, 14 Apr 2013 08:52:34 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Chris Rees Date: Sun, 14 Apr 2013 16:52:34 +0100 X-Google-Sender-Auth: VrhDYlCmWDVtZ2W7G8E7ed42Ibw Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Cc: "net@freebsd.org" , Scott Long , Rui Paulo , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 15:53:05 -0000 On 14 April 2013 16:48, Warren Block wrote: > On Sun, 14 Apr 2013, Chris Rees wrote: > >> On 14 April 2013 01:41, Rui Paulo wrote: >>> >>> 2013/04/13 16:01?Scott Long ??????: >>> >>> >>>> Maybe something else, but whatever it is, it should be done. If you and >>>> Gleb don't want to do this, I will. >>> >>> >>> I already started writing a guide. See here for a very incomplete >>> version: >>> >>> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html >> >> >> If you're really serious about deprecating ipf, we absolutely have to >> remove instructions for it from the Handbook as soon as possible; >> every time a new user comes across instructions you're going to have >> yet another annoyed party. >> >> http://www.bayofrum.net/~crees/patches/remove-ipf.diff > > > This should probably be done like we did for CVS for ports. Mark it as > deprecated, then remove the Handbook section once the code is removed. > > Is it possible to move ipfilter into a port? There isn't really a point in moving it to a port, because it still needs the same level of commitment to make it work; many kernel/net changes cause it to break, and Rui has already pointed out that no-one knows if it even works at all on HEAD. Moving kernel stuff like this to ports isn't really an option :/ Chris From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 16:06:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4ECB439A; Sun, 14 Apr 2013 16:06:51 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 13B1765B; Sun, 14 Apr 2013 16:06:51 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1URPS5-000DUI-0E; Sun, 14 Apr 2013 12:06:49 -0400 Date: Sun, 14 Apr 2013 12:06:48 -0400 From: Gary Palmer To: Warren Block Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 16:06:51 -0000 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: > Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Regards, Gary From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 16:51:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 13FCF670 for ; Sun, 14 Apr 2013 16:51:46 +0000 (UTC) (envelope-from feld@feld.me) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mx1.freebsd.org (Postfix) with ESMTP id D48A990A for ; Sun, 14 Apr 2013 16:51:45 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 83E0B1CB5 for ; Sun, 14 Apr 2013 12:51:39 -0400 (EDT) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute2.internal (MEProxy); Sun, 14 Apr 2013 12:51:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= nvSeBgXoyOMg+5wzcsQw8KLsnus=; b=ikhAvGS5eeKdWRnKBoABpp72Z/oWwtw+ zgcCkc3eKHgv5peDZECJ7MLfgpRG2mhiKPjIE1tHSGkYpsEzuIXyWzLDEsTFUria SZ7JMbuz/I19YzEy5odAAEDC7AyMWydpCyx6jXeFnvU+XjSg0f3n9ykcx6bp/q3K N50CoVnTXHE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=nvSeBgXoyOMg+5wzcsQw8KLsnus=; b=Oza KvtlyQB07awKXXqKLevlUDBp9e3wgifgBrZbF6jG4U6hvCgUh0hflyRcQAIhfxGl emRpFtCPJewF6zgDCzsQjlHeotCyakN8+Yza0i125VZT7A8g1KwHDdn7c3j/pKa4 WCYyg1UiIMw0GvUtyvGRuewaNGa+BPxxA4wHzDZQ= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 3D410B207FD; Sun, 14 Apr 2013 12:51:39 -0400 (EDT) Message-Id: <1365958299.18685.140661217615946.27F44A9B@webmail.messagingengine.com> X-Sasl-Enc: Qc8wS4XqojZcqOKd49W3WdZcDdY6Qu0Jr3ij6KP5NZPM 1365958299 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cd2b3500 In-Reply-To: <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) Date: Sun, 14 Apr 2013 11:51:39 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 16:51:46 -0000 I would also like to see this committed. I started on my own patch about 4 months ago but got sidetracked. This would be very, very valuable to the sysadmins at my workplace. From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 17:17:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AFD8B29; Sun, 14 Apr 2013 17:17:04 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 01A899A8; Sun, 14 Apr 2013 17:17:03 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX1+j9OdE9eP/0PwTB2geKrkRat3E00vTR8g@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3EGPNkq013418; Sun, 14 Apr 2013 16:25:23 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Sun, 14 Apr 2013 16:25:23 -0000 Message-ID: In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Sun, 14 Apr 2013 16:25:23 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Gary Palmer" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 17:17:04 -0000 Hi, I will see what I can do when I come back from work. PF is based on ipfilter so having 3 is indeed a bit much. Chris > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: >> Is it possible to move ipfilter into a port? > > That may work short term, but the ENOMAINTAINER problem will quickly creep > up again as kernel APIs change. If the author has lost interest in > maintaining the FreeBSD port of ipfilter then unless someone steps forward > to carry on the work, I don't see much of a future for ipfilter in > FreeBSD > > Do we honestly need three packet filters? > > Regards, > > Gary > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 17:53:43 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C05C0184; Sun, 14 Apr 2013 17:53:43 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe10.ukr.net (ffe10.ukr.net [195.214.192.60]) by mx1.freebsd.org (Postfix) with ESMTP id 42A63AC0; Sun, 14 Apr 2013 17:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=etrq1yVHCoBkAEn3prd7kSDf+mQ6qMXLk8XtLM480Dw=; b=MVwLCqEeGyhChkDjRopy0PLNHqvTZeT+3VCAfBpciS3RM3Xi6J5JVnFpHuvh4oqoT38z4xaKN2ux3R9KK4epj532o5fAJRjDu7HGNVqnX7sS31wVqTU589gEYGwZo+/MQ2aWQ+pEp71kJIMctnEd9VelhxyGQ9dzoTXvoCB34Ik=; Received: from mail by ffe10.ukr.net with local ID 1URQkw-000DrL-J1 ; Sun, 14 Apr 2013 20:30:22 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re[2]: ipfilter(4) needs maintainer In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> To: "Gary Palmer" From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Date: Sun, 14 Apr 2013 20:30:22 +0300 X-Mailman-Approved-At: Sun, 14 Apr 2013 18:12:54 +0000 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 17:53:43 -0000 --- Original message --- From: "Gary Palmer" Date: 14 April 2013, 19:06:59 > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: > > Is it possible to move ipfilter into a port? > > That may work short term, but the ENOMAINTAINER problem will quickly creep > up again as kernel APIs change. If the author has lost interest in > maintaining the FreeBSD port of ipfilter then unless someone steps forward > to carry on the work, I don't see much of a future for ipfilter in > FreeBSD > > Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 18:31:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A457999; Sun, 14 Apr 2013 18:31:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F091CCBB; Sun, 14 Apr 2013 18:31:00 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D03578D7A; Sun, 14 Apr 2013 18:30:59 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 82E939260; Sun, 14 Apr 2013 20:30:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Odhiambo Washington Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> Date: Sun, 14 Apr 2013 20:30:59 +0200 In-Reply-To: (Odhiambo Washington's message of "Sun, 14 Apr 2013 16:48:36 +0300") Message-ID: <861uadc6cc.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Gleb Smirnoff , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 18:31:01 -0000 Odhiambo Washington writes: > 2. PF is being felt to be part of FreeBSD, but it too lags far behind > OpenBSD implementation - almost like it's unmaintained. There has been > debates about this which were never concluded. Most of you will agree with > me on this. FreeBSD's version of pf is actively maintained by Gleb. IIUC, the reason why it lags behind OpenBSD is partly that OpenBSD keep making changes to the filter syntax which break existing rulesets, and partly that FreeBSD's and OpenBSD's network stacks and locking primitives are so different that we can't easily plug OpenBSD's code into our kernel without significant performance issues. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 18:55:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF6D3F1D; Sun, 14 Apr 2013 18:55:50 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 83136D88; Sun, 14 Apr 2013 18:55:49 +0000 (UTC) Received: from [IPv6:2001:b70:201:300::397] (unknown [IPv6:2001:b70:201:300::397]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3Zphqx5yNPz1Q2; Sun, 14 Apr 2013 19:55:41 +0100 (BST) Message-ID: <516AFB99.2040007@rewt.org.uk> Date: Sun, 14 Apr 2013 19:55:21 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: wishmaster Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gary Palmer , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 18:55:50 -0000 wishmaster wrote: > --- Original message --- > From: "Gary Palmer" > Date: 14 April 2013, 19:06:59 > > >> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: >>> Is it possible to move ipfilter into a port? >> That may work short term, but the ENOMAINTAINER problem will quickly creep >> up again as kernel APIs change. If the author has lost interest in >> maintaining the FreeBSD port of ipfilter then unless someone steps forward >> to carry on the work, I don't see much of a future for ipfilter in >> FreeBSD >> >> Do we honestly need three packet filters? > > Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. > We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. > May be the next step will be discussion about one packet filter in the system?.. > > Cheers, For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... Does anyone even use ipf? it doesn't even work on Linux anymore, junk it and keep pf+ipfw, job done. From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 19:11:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4849335 for ; Sun, 14 Apr 2013 19:11:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) by mx1.freebsd.org (Postfix) with ESMTP id 44EB7E1B for ; Sun, 14 Apr 2013 19:11:53 +0000 (UTC) Received: from mail-wi0-f197.google.com ([209.85.212.197]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKUWr/X/qUDt/cQ/fb047qdC5KkqjOk7bR@postini.com; Sun, 14 Apr 2013 19:11:54 UTC Received: by mail-wi0-f197.google.com with SMTP id hn17so1697101wib.0 for ; Sun, 14 Apr 2013 12:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to:x-gm-message-state; bh=gP3s534UcnNLFCAU1rw7n2xAY+Xzw4+Jr3rxUJJMpjw=; b=XsBLd/PizQmf9JW2sXg6RPabsRtubrWox1ldLjr8B58QpO68T0IlK6HWYrZZw0MI5A ASAA1X9LIwzbTk52v+NegtOH204YbpDpOb4sJBrnE3nUbbKgKLZV6XTZno+lBeuL8s8A MA5O1hQnK4Cwo+vNKFGBRQS9Rfkxj/YL5Wa1fQ2fEGROhja7vWfB5kYSc0MEI/1noOO+ QozQxcZmC/mrgu5C9c/e7F24vgooyqMpRLlDYzID2drWFbASSDPFXYCWPbqrFEBQ5WoB 3mTslMm0d35qa/nh+AHr6x6r/a957t1nmTEGTecCdQ3UJn8RFubVe4ZYpEho2NfEwdSs 80Pw== X-Received: by 10.180.109.197 with SMTP id hu5mr7844910wib.22.1365966687152; Sun, 14 Apr 2013 12:11:27 -0700 (PDT) X-Received: by 10.180.109.197 with SMTP id hu5mr7844897wib.22.1365966686983; Sun, 14 Apr 2013 12:11:26 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPS id bo1sm10645332wib.0.2013.04.14.12.11.24 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 12:11:25 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r3EJBMkr084883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Apr 2013 20:11:23 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r3EJBMOb084882; Sun, 14 Apr 2013 20:11:22 +0100 (BST) (envelope-from mexas) Date: Sun, 14 Apr 2013 20:11:22 +0100 (BST) From: Anton Shterenlikht Message-Id: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> To: rpaulo@FreeBSD.org, scottl@samsco.org Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> X-Gm-Message-State: ALoCoQlJr+1uO035z0W/ZXfWLHzOiQ4KE2tppC6A1T66jLnlWuy81PLWYMfnha4vfa3b7cSu5M9euYfU5IZLDgHKWL/k8fWwcFhc9bNmAQUBl5e+u2t6tUfiEOEf0amWtNh38EGgPDZ12mmkOUUvq66nKufLDbwoVw== Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 19:11:55 -0000 A migration *guide*, yes. Tools to convert one syntax to another: no. ok, so what is the brief migraiton advice? The Handbook mentions PF and IPFW. I gather from your mails that PF is the recommended choice. Is that so? If I choose PF, can I just follow the Handbook PF section, and once it's working, remove all IPF related kernel options and config files? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 19:58:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6A72C5D; Sun, 14 Apr 2013 19:58:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8073BF77; Sun, 14 Apr 2013 19:58:55 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ib11so3344407vcb.6 for ; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ze/1KuWFhUcRIDSdz4w6Y6tPgTgz6W8Rb6qLUAKmYhY=; b=HXvzZdDIkn50hyJnoJyfFKcoBIeeHg5wed14UQ47pgxRECT+dzd0zTBjCtdGDsV2Dn byR3ckpuPsEswt3pwI0IBa9QpATm67OKSe4yEJ0gUNEIfQNFCl3C8Z9lXMmQPLAbyofg k4OPZNivAF9lJt8xJqM05rGGS5L9BxANKsJgzK8BxkATnVEAvlLWU6/tsuFGXn+7gGr7 exZNSIUrbwmqlJzwZcW1JKaHWACB98UI/tLMPN+CrJRqa5AKDgtWHiKlS6N0zoRbbEh0 DC07+XTe8NM6xzFPkU07MTQgd+EPtwSt/EdgZwTaB3vpoTrSkqTPoLSuKc2IQGvccEAI Sg7Q== MIME-Version: 1.0 X-Received: by 10.58.146.195 with SMTP id te3mr103487veb.33.1365969534359; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> Date: Sun, 14 Apr 2013 15:58:54 -0400 Message-ID: Subject: Re: Re[2]: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: wishmaster Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gary Palmer , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 19:58:56 -0000 I agree with this, we dont need 3 packet filters, it seems like we should focus the people interested in working on packet filters,toward the packet filter most actively maintained, the fact that there is 3 in base is overkill, Just depreciate it and be done with it.... a new email, asking for help to bring pf closer to OpenBSD, is more of a productive conversation. On Sun, Apr 14, 2013 at 1:30 PM, wishmaster wrote: > > > --- Original message --- > From: "Gary Palmer" > Date: 14 April 2013, 19:06:59 > > > > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: > > > Is it possible to move ipfilter into a port? > > > > That may work short term, but the ENOMAINTAINER problem will quickly > creep > > up again as kernel APIs change. If the author has lost interest in > > maintaining the FreeBSD port of ipfilter then unless someone steps > forward > > to carry on the work, I don't see much of a future for ipfilter in > > FreeBSD > > > > Do we honestly need three packet filters? > > Yes! This is the most clever thought in this thread. Why we need 3 > firewalls? Two packet filters it's excess too. > We have two packet filters: one with excellent syntax and > functionality but with outdated bandwidth control mechanism (aka ALTQ); > another - with nice traffic shaper/prioritization (dummynet)/classification > (diffused) but with complicated implementation in not trivial tasks. > May be the next step will be discussion about one packet filter in the > system?.. > > Cheers, > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 20:33:23 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E00EB5AC; Sun, 14 Apr 2013 20:33:23 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id CE42FFA; Sun, 14 Apr 2013 20:33:23 +0000 (UTC) Received: from [IPv6:2601:9:4d00:3c:3169:d5a4:db0a:888b] (unknown [IPv6:2601:9:4d00:3c:3169:d5a4:db0a:888b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id CC1533981E; Sun, 14 Apr 2013 13:33:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Rui Paulo In-Reply-To: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> Date: Sun, 14 Apr 2013 13:33:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED46F7A-8A5A-4668-8B00-D58278C9A0DA@FreeBSD.org> References: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1503) Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 20:33:23 -0000 On 2013/04/14, at 12:11, Anton Shterenlikht wrote: > A migration *guide*, yes. Tools to convert one syntax to = another: no. >=20 > ok, so what is the brief migraiton advice? It's still being written. > The Handbook mentions PF and IPFW. > I gather from your mails that PF is the recommended choice. > Is that so? Yes, because of how much easier it is to convert from ipf to pf version = ipf to ipfw. > If I choose PF, can I just follow the > Handbook PF section, and once it's working, > remove all IPF related kernel options and config > files? Yes, that will be the plan. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 22:25:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 118044DA; Sun, 14 Apr 2013 22:25:14 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id BF7A35FE; Sun, 14 Apr 2013 22:25:13 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3ZpnTf6GNLzGMf1; Mon, 15 Apr 2013 00:25:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:organization:in-reply-to:references:user-agent :date:date:subject:subject:from:from:received:received:received :vbr-info; s=jakla2; t=1365978308; x=1368570309; bh=ERuCSN/R29Tv d448E63be+NM6qgx9Uc4v8XSyOdm/qk=; b=ALgzQDf1ua27wVCUM9K5U1kFCYJ6 iACaHQpqSuajJF77bAEp6JJ5N5xRX6A1uxXP5l4DFd4dYXq90vyqQRN5UHccTpQq lzvw0PiigJsjbsg/0QNw+MVZS3AmeqpaBmzB7uaoN4qxmNBz8+JM3COuYg6FlDvY zt/eHrr8nsAStZE= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 2df5AFYu6xoJ; Mon, 15 Apr 2013 00:25:08 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Mon, 15 Apr 2013 00:25:07 +0200 (CEST) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id CC42C330; Mon, 15 Apr 2013 00:25:07 +0200 (CEST) From: Mark Martinec To: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 00:25:07 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Organization: J. Stefan Institute MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 22:25:14 -0000 On Sunday April 14 2013 19:30:22 wishmaster wrote: > > Do we honestly need three packet filters? > Yes! This is the most clever thought in this thread. Why we need 3 > firewalls? Two packet filters it's excess too. We have two packet filters: > one with excellent syntax and functionality but with outdated bandwidth > control mechanism (aka ALTQ); another - with nice traffic > shaper/prioritization (dummynet)/classification (diffused) but with > complicated implementation in not trivial tasks. May be the next step > will be discussion about one packet filter in the system?.. ... and as far as I can tell none of them is currently usable on an IPv6-only FreeBSD (like protecting a host with sshguard), none of them supports stateful NAT64, nor IPv6 prefix translation :( Mark From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 23:48:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F154FC53 for ; Sun, 14 Apr 2013 23:48:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id C9752822 for ; Sun, 14 Apr 2013 23:48:09 +0000 (UTC) Received: by mail-da0-f48.google.com with SMTP id p8so1807718dan.7 for ; Sun, 14 Apr 2013 16:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=CmW5XMsULlUrVgXgh2tqdoN4/HNv568AssdC6k3Z4hc=; b=JvEEueMg7vVPLyg6k/iOQdMm45/dQ4IgydR7cRe/7M0noJA9GDDJsKlTn/TYVrRfp+ Xq4t5lJJrHbdL8XYvXbCVX9+xJ70wLI3hFz4acLCk37WY7kpCbWANhn0W+v9GvEdbvbm HNn/Zmh98yyBvSWJQE2jbVcwT+ods9ga/rkMFn2a+98lJemJi+LhgycJVOKGcTXyojdz wK+shvr3V/wXYRIKH/VcuykBbMNLzTNmeYdtQRz0J4YBmjqCmpqty1BIuUvVxEoHdpTY Ro2hJcb6EwhLV3tQV3Ji96tEU8ELGKB39C/9lO8Y6zBUQR9f5xdAbRVV+gJVdXcMLulH 0Qjw== X-Received: by 10.68.200.10 with SMTP id jo10mr13717281pbc.53.1365983289542; Sun, 14 Apr 2013 16:48:09 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id lf12sm19433370pab.13.2013.04.14.16.48.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 14 Apr 2013 16:48:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 15 Apr 2013 08:48:01 +0900 From: YongHyeon PYUN Date: Mon, 15 Apr 2013 08:48:01 +0900 To: Spil Oss Subject: Re: Problems with axe(4) and checksum offloading Message-ID: <20130414234801.GA3820@michelle.cdnetworks.com> References: <20130408063548.GB1526@michelle.cdnetworks.com> <20130410021455.GB3086@michelle.cdnetworks.com> <20130411011130.GA2985@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 23:48:10 -0000 On Sat, Apr 13, 2013 at 03:25:11PM +0200, Spil Oss wrote: > Hi YongHyeon, > > Will post on freebsd-ipfw@ as well... > > Does your engineering sample function normally with rxcsum/txcsum disabled? Yes. > > Kind regards, > > Spil. > > > On Thu, Apr 11, 2013 at 3:11 AM, YongHyeon PYUN wrote: > > > On Wed, Apr 10, 2013 at 07:48:00PM +0200, Spil Oss wrote: > > > Hi YongHyeon, > > > > > > With the original unmodified .ko... > > > > > > ifconfig output as requested at bottom > > > > > > Static IP-configuration does not make a difference with the ipfw > > behaviour. > > > > > > ipfw ruleset (based on /etc/rc.firewall simple ruleset) > > > 00010 allow ip from any to me dst-port 22 recv ue0 > > > 00010 allow tcp from me 22 to any xmit ue0 > > > 00100 allow ip from any to any via lo0 > > > 00200 deny ip from any to 127.0.0.0/8 > > > 00300 deny ip from 127.0.0.0/8 to any > > > 00400 deny ip from any to ::1 > > > 00500 deny ip from ::1 to any > > > 00600 allow ipv6-icmp from :: to ff02::/16 > > > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > > > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > > > 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 > > > 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > > > 01100 deny ip from 10.16.2.1 to any in via ue0 > > > 01200 deny ip from 172.17.2.111 to any in via re0 > > > 01300 deny ip from any to 10.0.0.0/8 via ue0 > > > 01500 deny ip from any to 192.168.0.0/16 via ue0 > > > 01600 deny ip from any to 0.0.0.0/8 via ue0 > > > 01700 deny ip from any to 169.254.0.0/16 via ue0 > > > 01800 deny ip from any to 192.0.2.0/24 via ue0 > > > 01900 deny ip from any to 224.0.0.0/4 via ue0 > > > 02000 deny ip from any to 240.0.0.0/4 via ue0 > > > 02100 divert 8668 ip4 from any to any via ue0 > > > 02200 deny ip from 10.0.0.0/8 to any via ue0 > > > 02400 deny ip from 192.168.0.0/16 to any via ue0 > > > 02500 deny ip from 0.0.0.0/8 to any via ue0 > > > 02600 deny ip from 169.254.0.0/16 to any via ue0 > > > 02700 deny ip from 192.0.2.0/24 to any via ue0 > > > 02800 deny ip from 224.0.0.0/4 to any via ue0 > > > 02900 deny ip from 240.0.0.0/4 to any via ue0 > > > 03000 allow tcp from any to any established > > > 03100 allow ip from any to any frag > > > 03200 allow tcp from any to me dst-port 22 setup > > > 03300 allow tcp from any to me dst-port 25 setup > > > 03400 allow tcp from any to me dst-port 465 setup > > > 03500 allow tcp from any to me dst-port 587 setup > > > 03600 allow tcp from any to me dst-port 80 setup > > > 03700 allow tcp from any to me dst-port 443 setup > > > 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto tcp > > > 03900 allow tcp from any to any setup > > > 04000 allow udp from me to any dst-port 53 keep-state > > > 04100 allow udp from me to any dst-port 123 keep-state > > > 04200 allow ip from any to any dst-port 22 recv ue0 > > > 65535 deny ip from any to any > > > > > > If I remove rule 10 it will NOT work with ue0, the ruleset without rule > > 10 > > > DOES work with re0. > > > > > > Found an older PR about em or fxp having trouble with natd when > > > rxcsum/txcsum was enabled, that is why I started fiddling with > > > rxcsum/txcsum and found that the NIC would be unusable without > > > rxcsum/txcsum enabled. If only I could find that PR now > > (kern/170081???)... > > > Was fixed in base... > > > > If you don't use ipfw/natd, checksum offloading of axe(4) work? > > If yes, you'd get better answer from ipfw mailing list. > > > > > > > > Some other post reported fake AX88772A chips (32-pin packaging vs 64 in > > the > > > original) on cheap USB NICs so I checked the hardware as well and could > > not > > > > AX88772A does not support TX/RX checksum offloading. > > > > > see an issue (64-pin packaging). > > > > > > # ifconfig ue0 > > > ue0: flags=8802 metric 0 mtu 1500 > > > options=8000b > > > ether 00:60:6e:42:5b:53 > > > nd6 options=21 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > > > # dhclient ue0 > > > DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 > > > DHCPOFFER from 172.17.2.1 > > > DHCPREQUEST on ue0 to 255.255.255.255 port 67 > > > DHCPACK from 172.17.2.1 > > > bound to 172.17.2.111 -- renewal in 43200 seconds. > > > > > > # ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu 1500 > > > options=8000b > > > ether 00:60:6e:42:5b:53 > > > inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 > > > inet 172.17.2.111 netmask 0xffffff00 broadcast 172.17.2.255 > > > nd6 options=21 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > I can see TX/RX checksum offloading is active and it successfully > > got a IP address via DHCP. > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN > > wrote: > > > > > > > On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: > > > > > Hi YongHyeon, > > > > > > > > > > output from verbose boot > > > > > > > > > > ugen3.2: at usbus3 > > > > > axe0: on usbus3 > > > > > axe0: PHYADDR 0xe0:0x10 > > > > > miibus1: on axe0 > > > > > ukphy0: PHY 16 on miibus1 > > > > > ukphy0: OUI 0x007063, model 0x0008, rev. 1 > > > > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > > > > > auto-flow > > > > > ue0: on axe0 > > > > > ue0: bpf attached > > > > > ue0: Ethernet address: 00:60:6e:42:5b:53 > > > > > ue0: link state changed to UP > > > > > ue0: link state changed to DOWN > > > > > ue0: link state changed to UP > > > > > > > > AX88772B engineering sample I have still worked on latest current. > > > > Could you use a static IP rather than using DHCP and see whether > > > > that makes any difference?(Note, you have to revert your changes > > > > made to axe(4) before trying that). > > > > > > > > Also show me the output of 'ifconfig ue0' before/after running > > > > dhclient(8). > > > > > > > > > > > > > > Apart from what I originally described... > > > > > Networking does work, but not when packets pass through ipfw and > > nat. If > > > > I > > > > > add my ipfw rules before the divert natd rule networking works as > > > > expected, > > > > > without the SYN,ACK response packets are not accepted if I e.g. > > connect > > > > to > > > > > something on the axe interface. I have validated the ipfw ruleset > > with > > > > the > > > > > onboard realtek NIC and it then works as expected. > > > > > > > > > > # usbconfig -u 3 -a 2 dump_info > > > > > ugen3.2: at usbus3, cfg=0 md=HOST > > spd=HIGH > > > > > (480Mbps) pwr=ON (200mA) > > > > > > > > > > Kind regards, > > > > > > > > > > Spil. > > > > > > > > > > > > > > > On Mon, Apr 8, 2013 at 8:35 AM, YongHyeon PYUN > > wrote: > > > > > > > > > > > On Sun, Apr 07, 2013 at 09:14:16PM +0200, Spil Oss wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > With checksum offloading enabled I cannot use my axe NIC (ASIX > > > > AX88772B). > > > > > > > > > > > > > > ifconfig ue0 -txcsum -rxcsum > > > > > > > will make dhclient ue0 return > > > > > > > > > > > > > > if I re-enable txcsum and rxcsum I get an immediate response > > from the > > > > > > dhcp > > > > > > > server. > > > > > > > > > > > > > > Tried to remove the csum features by commenting out > > > > > > > ifp->if_capabilities |= IFCAP_TXCSUM | IFCAP_RXCSUM; > > > > > > > ifp->if_hwassist = AXE_CSUM_FEATURES; > > > > > > > (lines 855 and 856 in /usr/src/sys/dev/usb/net/if_axe.c) > > > > > > > and rebuild the module. This does remove RXCSUM and TXCSUM from > > > > options > > > > > > and > > > > > > > behaves the same as disabling the features with ifconfig (i.e. > > does > > > > not > > > > > > > work) > > > > > > > > > > > > > > 10.0-CURRENT r248351 > > > > > > > > > > > > > > Hope someone can help me... Spil. > > > > > > > > > > > > Last time I tried, checksum offloading worked as expected. > > > > > > Would you show me the verbose dmesg output after attaching the > > > > > > axe(4) NIC? > > > > > > > > > > > > From owner-freebsd-current@FreeBSD.ORG Sun Apr 14 23:10:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2609CA1C for ; Sun, 14 Apr 2013 23:10:46 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id E666F780 for ; Sun, 14 Apr 2013 23:10:45 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k18so1977698oag.25 for ; Sun, 14 Apr 2013 16:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=VLd5GuH6Bexi+xL7oBouEgRxls8tF3SOi/ABxA7rquA=; b=RoorVbZFEsJV2XTAxpR99TA2LRqNeTAs1IYKv3EllM4M8qLt0z3y9OgRQozMb2eZNh b7PE11LphxbmjfcQuiB0GWSTae7ruDX+o5PPtAXSGu0OWXHr1kFq0aRjrP6/VoeVnTod ZZP4skK0D0hLE1Tt8axQkAXG2mCx8yrA3mu3rM1s9I1jP7A9yKjt2lFKuIjcrz2G2+ZI VNHBrj7k5GTmxRx+X8wITDl8D9Iku38SBQauqmqGKNnVYG1XjV3ZPcIzxKMnBhJrLlQa zLlYi1N2U/EVtz5/gv9R9fdtvcMW5GMCdVnkEdM5AssYdi3ggpR60Vd9gq+pAHk0pYO/ 8xUQ== X-Received: by 10.60.102.73 with SMTP id fm9mr7005287oeb.110.1365981044967; Sun, 14 Apr 2013 16:10:44 -0700 (PDT) Received: from jims-mini.office.pfmechanics.net ([192.207.126.228]) by mx.google.com with ESMTPS id do4sm3814137oeb.0.2013.04.14.16.10.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 16:10:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Jim Thompson In-Reply-To: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> Date: Sun, 14 Apr 2013 18:10:39 -0500 Message-Id: <35D4CCA3-1981-4825-B83F-70217B11672D@netgate.com> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> To: Mark Martinec X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm/gpH83Tte1apR+rxiQlVM26bn5I4pzjcXfwv8qsHs6ymO+kA+2cNaNGXrpT9u6ywspL3G X-Mailman-Approved-At: Mon, 15 Apr 2013 02:33:00 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 23:10:46 -0000 On Apr 14, 2013, at 5:25 PM, Mark Martinec = wrote: > ... and as far as I can tell none of them is currently usable > on an IPv6-only FreeBSD (like protecting a host with sshguard), > none of them supports stateful NAT64, nor IPv6 prefix translation :( pfSense 2.1 has a lot of work to make this happen for pf, so it should = be possible for pf with some attention. Jim From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 03:32:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B846345A; Mon, 15 Apr 2013 03:32:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD36EBE; Mon, 15 Apr 2013 03:32:15 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3F3WAmK013173 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Apr 2013 20:32:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <516B74BC.3070903@freebsd.org> Date: Mon, 15 Apr 2013 11:32:12 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 References: <51667FDC.7050807@freebsd.org> In-Reply-To: <51667FDC.7050807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 03:32:15 -0000 On 4/11/13 5:18 PM, Andre Oppermann wrote: > Excuse me for being slightly spammy but I've received feedback that we > haven't spread this information widely enough outside the inner circles > and interested people missed the announcement. > > EuroBSDcon 2013: September 28-29 in Malta > ========================================= > > EuroBSDcon is the European technical conference for users and > developers > of BSD-based systems. The conference will take place Saturday and > Sunday > 28-29 September at the Hilton Conference Centre in St. Julian's, Malta > (tutorials and FreeBSD Developer Summit on preceding Thursday and > Friday, > talks on Saturday and Sunday). [Yes, very nice weather at that time of > year, about 26/19C sunny no rain, Social event on Saturday evening > is going > to be a sunset beach BBQ] The web page suggest I bring my wife AND my spouse.. what if they don't know about each other? From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 08:33:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26FD7B3C; Mon, 15 Apr 2013 08:33:17 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 78638CF4; Mon, 15 Apr 2013 08:33:16 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E57F7FAA; Mon, 15 Apr 2013 10:29:30 +0200 (CEST) Date: Mon, 15 Apr 2013 10:35:17 +0200 From: Pawel Jakub Dawidek To: Gleb Kurtsou Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 Message-ID: <20130415083517.GB1410@garage.freebsd.pl> References: <20130414044314.GA1115@reks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline In-Reply-To: <20130414044314.GA1115@reks> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 08:33:17 -0000 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 13, 2013 at 09:43:14PM -0700, Gleb Kurtsou wrote: > On (22/03/2013 11:51), Shawn Webb wrote: > > Hey All, > >=20 > > I'm not sure if this is a result of r248583 or a different commit, but I > > hit a kernel panic when closing Chrome. I've linked to the info and > > core.txt files below. If you need me to ship you the vmcore file, let me > > know. It's 1.1GB in size. > >=20 > > Other than the pasted files, I'm not too sure where to go from here. If > > there's any other info you need, please let me know. I'm a newb at > > submitting this kind of stuff. > >=20 > > Paste of info file: http://ix.io/4Qo > > Paste of core.txt file: http://ix.io/4Qp >=20 > Shawn, did you find workaround for the problem? >=20 > I've just upgraded to recent HEAD and see the same panic on closing > chrome. Switching back to r247601 just before "Merge Capsicum overhaul" > commit makes panic disappear. I did receive Shawn's report some time ago, I even installed Chromium to try to reproduce it, but it didn't crash for me yet. If there are some easy, but reliable steps to reproduce it, like "open this webpage in tab 1, then this webpage in tab 2, then close tab 1" that would be great. This kernel coredump is not really useful, as we this is legitimate case of decrementing reference counter. The problem is that something decremented it earlier when it shouldn't or it wasn't incremented somewhere. DTrace might be useful tool here if we could instrument it to log backtrace of all increments and decrements done by the Chromium processes. > ~ # kgdb -n 1 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > VNASSERT failed > 0xfffffe0196700760: tag none, type VBAD > usecount 0, writecount 0, refcount 0 mountedhere 0 > flags (VV_NOSYNC|VI_DOOMED) > lock type zfs: UNLOCKED > panic: No vop_advlock(0xfffffe0196700760, 0xffffff823adb9908) > cpuid =3D 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff823ad= b9740 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff823adb97f0 > vpanic() at vpanic+0x127/frame 0xffffff823adb9830 > kassert_panic() at kassert_panic+0x136/frame 0xffffff823adb98a0 > VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x92/frame 0xffffff823adb98d0 > closef() at closef+0x9a/frame 0xffffff823adb9960 > closefp() at closefp+0xa0/frame 0xffffff823adb99b0 > amd64_syscall() at amd64_syscall+0x1f9/frame 0xffffff823adb9ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff823adb9ab0 > --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x80aeaaa8a, rsp =3D 0= x7ffffebf3f38, rbp =3D 0x7ffffebf3f50 --- > [...] > (kgdb) fr 0 > #0 doadump (textdump=3D1) at pcpu.h:231 > 231 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) up > #1 0xffffffff804f5827 in kern_reboot (howto=3D260) at /freebsd-src/local= /sys/kern/kern_shutdown.c:447 > 447 doadump(TRUE); > (kgdb)=20 > #2 0xffffffff804f5d36 in vpanic (fmt=3D, ap=3D) > at /freebsd-src/local/sys/kern/kern_shutdown.c:754 > 754 kern_reboot(bootopt); > (kgdb)=20 > #3 0xffffffff804f5bc6 in kassert_panic (fmt=3D) > at /freebsd-src/local/sys/kern/kern_shutdown.c:642 > 642 vpanic(fmt, ap); > (kgdb)=20 > #4 0xffffffff80747aa2 in VOP_ADVLOCK_APV (vop=3D, a= =3D0xffffff823adb9908) > at vnode_if.c:2522 > 2522 VNASSERT(vop !=3D NULL, a->a_vp, ("No vop_advlock(%p, %p)", a->a_vp= , a)); > (kgdb)=20 > #5 0xffffffff804b8eaa in closef (fp=3D0xfffffe014da8ccd0, td=3D0xfffffe0= 014aea920) at vnode_if.h:1041 > 1041 vnode_if.h: No such file or directory. > in vnode_if.h > (kgdb)=20 > #6 0xffffffff804b7030 in closefp (fdp=3D0xfffffe001c8c4800, fd=3D, fp=3D0xfffffe014da8ccd0,=20 > td=3D0xfffffe0014aea920, holdleaders=3D) > at /freebsd-src/local/sys/kern/kern_descrip.c:1136 > 1136 error =3D closef(fp, td); > (kgdb) p *fp > $5 =3D {f_data =3D 0xfffffe0196700760, f_ops =3D 0xffffffff80a477b8, f_cr= ed =3D 0xfffffe0067907600,=20 > f_vnode =3D 0xfffffe0196700760, f_type =3D 1, f_vnread_flags =3D 0, f_f= lag =3D 3, f_count =3D 0, f_seqcount =3D 0,=20 > f_nextoff =3D 16388, f_vnun =3D {fvn_cdevpriv =3D 0x0, fvn_advice =3D 0= x0}, f_offset =3D 16388, f_label =3D 0x0} > (kgdb) p *fp > $6 =3D {f_data =3D 0xfffffe0196700760, f_ops =3D 0xffffffff80a477b8, f_cr= ed =3D 0xfffffe0067907600,=20 > f_vnode =3D 0xfffffe0196700760, f_type =3D 1, f_vnread_flags =3D 0, f_f= lag =3D 3, f_count =3D 0, f_seqcount =3D 0,=20 > f_nextoff =3D 16388, f_vnun =3D {fvn_cdevpriv =3D 0x0, fvn_advice =3D 0= x0}, f_offset =3D 16388, f_label =3D 0x0} > (kgdb) p fp->f_vnode > $7 =3D (struct vnode *) 0xfffffe0196700760 > (kgdb) p *fp->f_vnode > $8 =3D {v_tag =3D 0xffffffff807a3e35 "none", v_op =3D 0x0, v_data =3D 0x0= , v_mount =3D 0x0, v_nmntvnodes =3D { > tqe_next =3D 0xfffffe014fd95760, tqe_prev =3D 0xfffffe011d500958}, v_= un =3D {vu_mount =3D 0x0, vu_socket =3D 0x0,=20 > vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next =3D 0x= 0, le_prev =3D 0x0}, v_cache_src =3D { > lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, tqh_last =3D 0= xfffffe01967007b0}, v_cache_dd =3D 0x0,=20 > v_lock =3D {lock_object =3D {lo_name =3D 0xffffffff80dddbb1 "zfs", lo_f= lags =3D 91881472, lo_data =3D 0,=20 > lo_witness =3D 0x0}, lk_lock =3D 1, lk_exslpfail =3D 0, lk_timo =3D= 51, lk_pri =3D 96}, v_interlock =3D { > lock_object =3D {lo_name =3D 0xffffffff807bfbb9 "vnode interlock", lo= _flags =3D 16908288, lo_data =3D 0,=20 > lo_witness =3D 0x0}, mtx_lock =3D 6}, v_vnlock =3D 0xfffffe01967007= c8, v_actfreelist =3D { > tqe_next =3D 0xfffffe0031985b10, tqe_prev =3D 0xfffffe014fd95820}, v_= bufobj =3D {bo_mtx =3D {lock_object =3D { > lo_name =3D 0xffffffff807bfbc9 "bufobj interlock", lo_flags =3D 1= 6908288, lo_data =3D 0,=20 > lo_witness =3D 0x0}, mtx_lock =3D 6}, bo_ops =3D 0xffffffff80a5af= 10, bo_object =3D 0x0, bo_synclist =3D { > le_next =3D 0x0, le_prev =3D 0x0}, bo_private =3D 0xfffffe019670076= 0, __bo_vnode =3D 0xfffffe0196700760,=20 > bo_clean =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe0196= 700880}, bv_root =3D 0x0, bv_cnt =3D 0},=20 > bo_dirty =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe0196= 7008a0}, bv_root =3D 0x0, bv_cnt =3D 0},=20 > bo_numoutput =3D 0, bo_flag =3D 0, bo_bsize =3D 131072}, v_pollinfo = =3D 0x0, v_label =3D 0x0, v_lockf =3D 0x0,=20 > v_rl =3D {rl_waiters =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe01967= 008e8}, rl_currdep =3D 0x0}, v_cstart =3D 0,=20 > v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_holdcnt =3D 0, v_usecount= =3D 0, v_iflag =3D 128, v_vflag =3D 4,=20 > v_writecount =3D 0, v_hash =3D 26636295, v_type =3D VBAD} >=20 >=20 > # kgdb -n 0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > panic: negative refcount 0xfffffe0059a400c8 > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff823af= f8770 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff823aff8820 > vpanic() at vpanic+0x127/frame 0xffffff823aff8860 > kassert_panic() at kassert_panic+0x136/frame 0xffffff823aff88d0 > closef() at closef+0x1ff/frame 0xffffff823aff8960 > closefp() at closefp+0xa0/frame 0xffffff823aff89b0 > amd64_syscall() at amd64_syscall+0x1f9/frame 0xffffff823aff8ab0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff823aff8ab0 > --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x80aeaaa8a, rsp =3D 0= x7fffffffbd28, rbp =3D 0x7fffffffbd40 --- > Uptime: 21m3s > [...] > (kgdb) bt > #0 doadump (textdump=3D1) at pcpu.h:231 > #1 0xffffffff804f5827 in kern_reboot (howto=3D260) at /freebsd-src/local= /sys/kern/kern_shutdown.c:447 > #2 0xffffffff804f5d36 in vpanic (fmt=3D, ap=3D) > at /freebsd-src/local/sys/kern/kern_shutdown.c:754 > #3 0xffffffff804f5bc6 in kassert_panic (fmt=3D) > at /freebsd-src/local/sys/kern/kern_shutdown.c:642 > #4 0xffffffff804b900f in closef (fp=3D, td=3D) at refcount.h:66 > #5 0xffffffff804b7030 in closefp (fdp=3D0xfffffe018dc79800, fd=3D, fp=3D0xfffffe0059a400a0,=20 > td=3D0xfffffe016dfca920, holdleaders=3D) > at /freebsd-src/local/sys/kern/kern_descrip.c:1136 > #6 0xffffffff806e26c9 in amd64_syscall (td=3D0xfffffe016dfca920, traced= =3D0) at subr_syscall.c:134 > #7 0xffffffff806cb13b in Xfast_syscall () at exception.S:387 > #8 0x000000080aeaaa8a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb)=20 >=20 > >=20 > > Thanks, > >=20 > > Shawn Webb > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEUEARECAAYFAlFru8UACgkQForvXbEpPzT1LQCfX5BrnYJNEM7nfOfibDA4pZem xsMAlRV9Kmu16YNpa6qwiFF2AUddN6g= =YE/8 -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 09:21:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 134DC12C for ; Mon, 15 Apr 2013 09:21:25 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id C9C40EAC for ; Mon, 15 Apr 2013 09:21:24 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1URfb6-0004TA-5S for freebsd-current@freebsd.org; Mon, 15 Apr 2013 13:21:12 +0400 Date: Mon, 15 Apr 2013 13:21:12 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415092112.GA15866@zxy.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 09:21:25 -0000 On Fri, Apr 12, 2013 at 11:33:30PM -0700, Rui Paulo wrote: > It's not very difficult to switch an ipf.conf/ipnat.conf to a > pf.conf, but I'm not sure automated tools exist. I'm also not > convinced we need to write them and I think the issue can be deal > with by writing a bunch of examples on how to do it manually. Then > we can give people 1y to switch. Realy? pf do FTP nat translation w/o contexst switching? Multiple GRE nat translation? I am use from ipfilter only ipnat. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 09:37:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECAA03BB for ; Mon, 15 Apr 2013 09:37:53 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 88CDBF3A for ; Mon, 15 Apr 2013 09:37:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 0EA482B43022 for ; Mon, 15 Apr 2013 11:28:08 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkvaBLqRYmQP for ; Mon, 15 Apr 2013 11:28:07 +0200 (SAST) Received: from clue.co.za (unknown [197.87.27.46]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 702802B43021 for ; Mon, 15 Apr 2013 11:28:07 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen.clue.co.za) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1URfc1-0000Qp-LR for current@freebsd.org; Mon, 15 Apr 2013 11:22:09 +0200 To: current@freebsd.org Subject: mirror site ftp3.za.freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Mon, 15 Apr 2013 11:22:08 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 09:37:54 -0000 Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:15:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36DDE82B; Mon, 15 Apr 2013 10:15:29 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id E8B83F2; Mon, 15 Apr 2013 10:15:28 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 036B86A6002; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id r3FAFQh7078878; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id r3FAFQ0C077927; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) (envelope-from lars) Date: Mon, 15 Apr 2013 12:15:26 +0200 From: Lars Engels To: Joe Holden Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415101526.GA65341@e-new.0x20.net> References: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <516AFB99.2040007@rewt.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <516AFB99.2040007@rewt.org.uk> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p5 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Gary Palmer , "net@freebsd.org" , "current@freebsd.org" , wishmaster X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:15:29 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote: > wishmaster wrote: >=20 > > --- Original message --- > > From: "Gary Palmer" > > Date: 14 April 2013, 19:06:59 > >=20 > > =20 > >> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: > >>> Is it possible to move ipfilter into a port? > >> That may work short term, but the ENOMAINTAINER problem will quickly c= reep > >> up again as kernel APIs change. If the author has lost interest in > >> maintaining the FreeBSD port of ipfilter then unless someone steps for= ward > >> to carry on the work, I don't see much of a future for ipfilter in > >> FreeBSD > >> > >> Do we honestly need three packet filters? > > =20 > > Yes! This is the most clever thought in this thread. Why we need > > 3 firewalls? Two packet filters it's excess too. > > We have two packet filters: one with excellent syntax and > > functionality but with outdated bandwidth control mechanism > > (aka ALTQ); another - with nice traffic shaper/prioritization > > (dummynet)/classification (diffused) but with complicated > > implementation in not trivial tasks. > > May be the next step will be discussion about one packet filter in = the system?.. > >=20 > > Cheers, > For non-nat ipfw is still superior in every way, numbered rules (think:= =20 > scripts), dummynet, much faster than pf, syntax is a lot nicer and=20 > predictable... >=20 > Does anyone even use ipf? it doesn't even work on Linux anymore, junk it= =20 > and keep pf+ipfw, job done. m0n0wall uses ipfilter: http://m0n0.ch/wall/facts.php --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFr0z4ACgkQKc512sD3afigkgCgklyPLcaWJH3qt5S0U8iXp6xR j1EAn1zbodljf60/M7bXSjT2C1rFF0bz =faym -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:15:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B40C09AD; Mon, 15 Apr 2013 10:15:41 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D36CF7; Mon, 15 Apr 2013 10:15:41 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 38D2D4AC57; Mon, 15 Apr 2013 14:15:38 +0400 (MSK) Date: Mon, 15 Apr 2013 14:15:36 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <951943801.20130415141536@serebryakov.spb.ru> To: Mark Martinec Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:15:41 -0000 Hello, Mark. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 2:25:07: >> Yes! This is the most clever thought in this thread. Why we need 3 >> firewalls? Two packet filters it's excess too. We have two packet filter= s: >> one with excellent syntax and functionality but with outdated bandwidth >> control mechanism (aka ALTQ); another - with nice traffic >> shaper/prioritization (dummynet)/classification (diffused) but with >> complicated implementation in not trivial tasks. May be the next step >> will be discussion about one packet filter in the system?.. MM> ... and as far as I can tell none of them is currently usable MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:26:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 926E0C23; Mon, 15 Apr 2013 10:26:42 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D406B18F; Mon, 15 Apr 2013 10:26:41 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so3493357wey.11 for ; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=vXjvTQOwUK2MIjRVTZ9U7h2i+i0KDEYnsDYC/R0Z1AU=; b=e3TWytJ2sWkCROK1i0WXC2Zup8J7nRH9oB1ACv0BnrDNBvJkw/hH5r6a9L4el2mrR+ K/SI15iNUS0AjSays/q3dLZmPIG365mHNTP1rDRYQPQqTTYUolgrSs0nPLDBHpITfA2O l2ieqsQXf3lugFiYkjobfFp1XrteNFbhxZ3Z1fyMnI8RKYVI+y7oWonCLOciQudbrK4E DDpP5mN56TH7ulCDoZwb4xnnxMLDA/2x9FXAAM5ExcEelSjNLzLliN8S51pFogdOg0wC ukhQ1kESy/QEh9vbhpeid87MYoF34xyUQbG09usKJeX9L6JlS4aXdw/0V3mgUu5c4wJP CfAA== MIME-Version: 1.0 X-Received: by 10.180.38.105 with SMTP id f9mr10989707wik.15.1366021600468; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) In-Reply-To: <951943801.20130415141536@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:26:40 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:26:42 -0000 On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov wrote: > Hello, Mark. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 2:25:07: > >>> Yes! This is the most clever thought in this thread. Why we need 3 >>> firewalls? Two packet filters it's excess too. We have two packet filte= rs: >>> one with excellent syntax and functionality but with outdated bandwidth >>> control mechanism (aka ALTQ); another - with nice traffic >>> shaper/prioritization (dummynet)/classification (diffused) but with >>> complicated implementation in not trivial tasks. May be the next step >>> will be discussion about one packet filter in the system?.. > > MM> ... and as far as I can tell none of them is currently usable > MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), > MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( > IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will > render all that NAT nightmare to void. I hope, IPv6 prefix translation > will not be possible never ever! > > -- > // Black Lion AKA Lev Serebryakov > Things like ftp-proxy(8) will need address translation even with IPv6. Also certain scrub options require a NAT like functionalities. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:32:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 149E3EE1; Mon, 15 Apr 2013 10:32:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id CB88120A; Mon, 15 Apr 2013 10:32:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C821F4AC57; Mon, 15 Apr 2013 14:32:38 +0400 (MSK) Date: Mon, 15 Apr 2013 14:32:37 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <195468703.20130415143237@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:32:47 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:26:40: >> MM> ... and as far as I can tell none of them is currently usable >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will >> render all that NAT nightmare to void. I hope, IPv6 prefix translation >> will not be possible never ever! KP> Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some "proxy". And, yes, NAT64 will be useful for sure, but it is another story, not IPv6<->IPv6 translation. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:36:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C4B916F; Mon, 15 Apr 2013 10:36:30 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4C490252; Mon, 15 Apr 2013 10:36:29 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k13so4392088wgh.17 for ; Mon, 15 Apr 2013 03:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lWIihVDyaEQidvIpRrySs0QzOajjsdOFteimd9vq8f4=; b=v5br8GHqduhbC/hZpRw1jTkMvC7LHXmKewmUqnm1JZHy/0zTonxK6M97HwmXGR//nx jurps8341cKITV8qx/KUZfkk0Y6bTR5c4iT/QKcNgdh2iszdYYx3pkpQwWuSPJL5tzn1 AtUQMf7N5IKd/XBFydcVu8w2sXnXzfGtQTKSinuvNg44VCcrbnZ4l6LdP5GEop1gK8EW Mq1FNKnrlxBPc6nyc8nWqMBb/KBP6lBM12qoqrvfVuJNYQpwEvWYaDhfBvpNDj0QnmNV rAbS484EpsqA480HCqo4BtchVSsY9AZmKPkRHEgrgAyW57obnDmY1QxCiIuEGO635HwL pTcQ== MIME-Version: 1.0 X-Received: by 10.180.19.39 with SMTP id b7mr11064061wie.15.1366022187931; Mon, 15 Apr 2013 03:36:27 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:36:27 -0700 (PDT) In-Reply-To: <195468703.20130415143237@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:36:27 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:36:30 -0000 On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:26:40: > >>> MM> ... and as far as I can tell none of them is currently usable >>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), >>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation := ( >>> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will >>> render all that NAT nightmare to void. I hope, IPv6 prefix translation >>> will not be possible never ever! > > KP> Things like ftp-proxy(8) will need address translation even with IPv6= . > ftp-proxy is solution to help IPv4 NAT. Why do we need it when every > device could have routable IPv6? Of course, _every_ device should be > protected by border firewall (stateful and IPv6-enabled), but FTP > server should have special rules for it to allow traffic pass, not > some "proxy". > > And, yes, NAT64 will be useful for sure, but it is another story, > not IPv6<->IPv6 translation. > You're forgetting set ups where outgoing traffic is controlled by filter rules, outgoing passive mode ftp needs help from the proxy to open holes for arbitrary ports. This is not limited to IPv4 and NAT. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:38:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F097E321 for ; Mon, 15 Apr 2013 10:38:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id B30A2276 for ; Mon, 15 Apr 2013 10:38:13 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1URgnR-0005Xw-2P for freebsd-current@freebsd.org; Mon, 15 Apr 2013 14:38:01 +0400 Date: Mon, 15 Apr 2013 14:38:01 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415103801.GA21132@zxy.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <951943801.20130415141536@serebryakov.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:38:14 -0000 On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: > >> Yes! This is the most clever thought in this thread. Why we need 3 > >> firewalls? Two packet filters it's excess too. We have two packet filters: > >> one with excellent syntax and functionality but with outdated bandwidth > >> control mechanism (aka ALTQ); another - with nice traffic > >> shaper/prioritization (dummynet)/classification (diffused) but with > >> complicated implementation in not trivial tasks. May be the next step > >> will be discussion about one packet filter in the system?.. > > MM> ... and as far as I can tell none of them is currently usable > MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), > MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( > IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will > render all that NAT nightmare to void. I hope, IPv6 prefix translation > will not be possible never ever! You disallow anonymization? NAT do anonymisation also. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:41:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 92ECF55A for ; Mon, 15 Apr 2013 10:41:28 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFBB2C7 for ; Mon, 15 Apr 2013 10:41:28 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so1382666wib.16 for ; Mon, 15 Apr 2013 03:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wN9saBo9L0yjdLjr5QZ8q61h4csgu7wLxkrN8AZVvbU=; b=koukZD7Ji96EJwPHG3sjMqMClWZzKO6y31fTigoIeuTBWMysePiwiYCMAVMuds1IGX z4I799Z6K7c+epyXBHIalJsOk2jRiGoGtfSjxJ8NuijfQHXl6hRbx6T836c5EoWY/TMK L95Vegln1YECno/dMX0rAgyZM6mPNvGMxzdboE8vTweVpWhv3+x2TIeBKczAuoV3gNJU DZ9owkMU4ADrMEYoTXDBeJS1XGujSku9gcxHpB6iVfyOEwHXkD22/jX3dSYZ8fxRHloY LAikVrsBdBNAAGte9rFgVfyBTWz+wDlO6VnCb7gm67Jtk68TviUNEExHvLPqG6e12uby nl5Q== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr10841255wib.32.1366022487283; Mon, 15 Apr 2013 03:41:27 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:41:27 -0700 (PDT) In-Reply-To: <20130415103801.GA21132@zxy.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <20130415103801.GA21132@zxy.spb.ru> Date: Mon, 15 Apr 2013 13:41:27 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: Slawa Olhovchenkov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:41:28 -0000 On Mon, Apr 15, 2013 at 1:38 PM, Slawa Olhovchenkov wrote: > On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: > >> >> Yes! This is the most clever thought in this thread. Why we need 3 >> >> firewalls? Two packet filters it's excess too. We have two packet filters: >> >> one with excellent syntax and functionality but with outdated bandwidth >> >> control mechanism (aka ALTQ); another - with nice traffic >> >> shaper/prioritization (dummynet)/classification (diffused) but with >> >> complicated implementation in not trivial tasks. May be the next step >> >> will be discussion about one packet filter in the system?.. >> >> MM> ... and as far as I can tell none of them is currently usable >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will >> render all that NAT nightmare to void. I hope, IPv6 prefix translation >> will not be possible never ever! > > You disallow anonymization? NAT do anonymisation also. > _______________________________________________ Please stop it already, NAT has never done any real anonymisation. it's just one of the myths that just refuse to die. Use a real anonymiser like Tor if you want to keep your identity hidden. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:44:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5AD16AD; Mon, 15 Apr 2013 10:44:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC7B2FC; Mon, 15 Apr 2013 10:44:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0A63A4AC57; Mon, 15 Apr 2013 14:44:29 +0400 (MSK) Date: Mon, 15 Apr 2013 14:44:28 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <621849003.20130415144428@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:44:31 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:36:27: >> And, yes, NAT64 will be useful for sure, but it is another story, >> not IPv6<->IPv6 translation. KP> You're forgetting set ups where outgoing traffic is controlled by KP> filter rules, outgoing passive mode ftp needs help from the proxy to KP> open holes for arbitrary ports. This is not limited to IPv4 and NAT. It could be done without IPv6 prefix mapping. Yes, firewall should have ability to expect some connections fro FTP commands (some flag on rule, for sure), but it is not prefix rewriting (there are some other protocols, which need similar treatment, like SIP)! I was shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own problems and complications, but one REALLY GOOD side of it, that we don't need NAT for it anymore! Some special tricks in firewall -- yes, maybe, for bad-designed, but widely-deployed application level protocols, but not address translations! I, personally, don't see any problems to enable all outbound connections for dedicated FTP server, though. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:47:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED04A97E; Mon, 15 Apr 2013 10:47:25 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id 384F0349; Mon, 15 Apr 2013 10:47:25 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id c10so1382245wiw.13 for ; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=P1ZKwYwb92Sbj62ZjZpl4ffRTg7lVPe6GykMxQTfN5I=; b=klasYIv8EfrQ91mYeWpsmoPtt/R3gpycHmcO+8ralOKI6llbBm2x8VPmMFHVTdp0I9 bujt82gd56vVwx1RGvWZ+Cc2fVOCvz7vIYoW55pD9aD2pSV9VjkkiVMzYF3GyWPzOt/2 iPPvI43gKprmtA/ltdmH1gVxyyq/HpcBeuBx5rGVgUioTyQC4uBFmhU62fHYVOg2G0aR YOHcYTAXtuF2nVBhtyeangTjsJHNaAmaIIOrPvCTz9mvcgopx9UfnMaF/eMyzak63AY7 2HgWyUXMB6sZ5KXQk/sAoMXLIwUhgyFtYAbCohyVQnTJKk1XH5kxI/smwZE9brcIpYIc rZqA== MIME-Version: 1.0 X-Received: by 10.194.157.138 with SMTP id wm10mr10133324wjb.28.1366022844442; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) In-Reply-To: <621849003.20130415144428@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:47:24 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:47:26 -0000 On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:36:27: > >>> And, yes, NAT64 will be useful for sure, but it is another story, >>> not IPv6<->IPv6 translation. > KP> You're forgetting set ups where outgoing traffic is controlled by > KP> filter rules, outgoing passive mode ftp needs help from the proxy to > KP> open holes for arbitrary ports. This is not limited to IPv4 and NAT. > It could be done without IPv6 prefix mapping. Yes, firewall should > have ability to expect some connections fro FTP commands (some flag > on rule, for sure), but it is not prefix rewriting (there are some > other protocols, which need similar treatment, like SIP)! I was > shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own > problems and complications, but one REALLY GOOD side of it, that we > don't need NAT for it anymore! Some special tricks in firewall -- yes, > maybe, for bad-designed, but widely-deployed application level > protocols, but not address translations! > > I, personally, don't see any problems to enable all outbound > connections for dedicated FTP server, though. > Server side is the easy part, no need for proxy because you know the passive mode data ports and you can open holes in your firewall using the known port numbers. I'm however talking about an ftp client behind a very restrictive firewall making an IPv6 connection an ftp server that uses passive mode data ports that can't be known in advance. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:50:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E33A1BED; Mon, 15 Apr 2013 10:50:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A777138F; Mon, 15 Apr 2013 10:50:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 57FF24AC57; Mon, 15 Apr 2013 14:50:24 +0400 (MSK) Date: Mon, 15 Apr 2013 14:50:23 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <66408799.20130415145023@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:50:26 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:47:24: KP> I'm however talking about an ftp client behind a very restrictive KP> firewall making an IPv6 connection an ftp server that uses passive KP> mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:54:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D845DE2; Mon, 15 Apr 2013 10:54:50 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id BA2743FD; Mon, 15 Apr 2013 10:54:49 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hj19so334837wib.8 for ; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zA9LvDmKcJZOtlFnL79gdLDn0H3qjNSSSzgHsuaKF28=; b=mUpuHrBM+/K6/KGLlZUkRK/zdlb7aFjo9Cc7Ys3+JCpOmEDpWGPDLxv5xCy91wQwTB sQMQeB7l2HbfEcjRuyX8JMkVOg+j/rDa2xwbXiDgsM7/+DB7gJ+Z2A+bkjM7UknZWeuT ut+VSEdzQ3VVhSXCipPfaoU8jPUiqTWheRxh3vPNXaHSa4emHI0BJYYEG738n/LLU1PN l1oj6KVFyU37YxicQnZoxV7Gb/lX6m/CfTpPi89aLqxlpIew1gf0v7PYHOJdAi/jQxOM XEtzGddpIs2we09Nc8aRWRgQpEpTkevmhLy26Y8RQGKAR8cXKuNmFA5yZ9HcXtCT4oQ9 ETIw== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr31172222wjr.33.1366023288898; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) In-Reply-To: <66408799.20130415145023@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:54:48 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:54:50 -0000 On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:47:24: > > KP> I'm however talking about an ftp client behind a very restrictive > KP> firewall making an IPv6 connection an ftp server that uses passive > KP> mode data ports that can't be known in advance. > Same solution -- inspection of connections to 21 port, without any > address translation. And if FTP server uses non-standard control > port, yes, here is a problem, but it cannot be solved with NAT too > (or your NAT/firewall should expect each and every connection for FTP > commands, which is heavy and error-prone task). > Mmm, are you thinking of the way Linux iptables handles this scenario with a kernel mode helper? I don't think any of the three packet filters in FreeBSD has a functionality like that yet. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:57:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72ECAFC6 for ; Mon, 15 Apr 2013 10:57:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F01E611 for ; Mon, 15 Apr 2013 10:57:18 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1URh5u-0005tb-RW for freebsd-current@freebsd.org; Mon, 15 Apr 2013 14:57:06 +0400 Date: Mon, 15 Apr 2013 14:57:06 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415105706.GB21132@zxy.spb.ru> References: <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66408799.20130415145023@serebryakov.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:57:18 -0000 On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote: > KP> I'm however talking about an ftp client behind a very restrictive > KP> firewall making an IPv6 connection an ftp server that uses passive > KP> mode data ports that can't be known in advance. > Same solution -- inspection of connections to 21 port, without any > address translation. And if FTP server uses non-standard control > port, yes, here is a problem, but it cannot be solved with NAT too > (or your NAT/firewall should expect each and every connection for FTP > commands, which is heavy and error-prone task). Not heavy. But error-prone, yes. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:57:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 735DD171 for ; Mon, 15 Apr 2013 10:57:44 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B3C94627 for ; Mon, 15 Apr 2013 10:57:43 +0000 (UTC) Received: (qmail 91373 invoked from network); 15 Apr 2013 10:51:00 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Apr 2013 10:51:00 -0000 Date: Mon, 15 Apr 2013 12:51:00 +0200 (CEST) Message-Id: <20130415.125100.74672975.sthaug@nethelp.no> To: lev@FreeBSD.org Subject: Re: ipfilter(4) needs maintainer From: sthaug@nethelp.no In-Reply-To: <195468703.20130415143237@serebryakov.spb.ru> References: <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Mark.Martinec+freebsd@ijs.si, kpaasial@gmail.com, current@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:57:44 -0000 > >> MM> ... and as far as I can tell none of them is currently usable > >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard), > >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :( > >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will > >> render all that NAT nightmare to void. I hope, IPv6 prefix translation > >> will not be possible never ever! > > KP> Things like ftp-proxy(8) will need address translation even with IPv6. > ftp-proxy is solution to help IPv4 NAT. Why do we need it when every > device could have routable IPv6? Of course, _every_ device should be > protected by border firewall (stateful and IPv6-enabled), but FTP > server should have special rules for it to allow traffic pass, not > some "proxy". > > And, yes, NAT64 will be useful for sure, but it is another story, > not IPv6<->IPv6 translation. We are *way* too late in the game to completely avoid IPv6 NAT. Various flavors already exist in the form of RFCs, e.g. NPTv6: http://tools.ietf.org/html/rfc6296 Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 11:00:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6FFD94FD for ; Mon, 15 Apr 2013 11:00:51 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) by mx1.freebsd.org (Postfix) with ESMTP id E73A3676 for ; Mon, 15 Apr 2013 11:00:50 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r3FAib6O069698 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 15 Apr 2013 13:44:37 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <516BDA15.6000605@digsys.bg> Date: Mon, 15 Apr 2013 13:44:37 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130318 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <516AFB99.2040007@rewt.org.uk> In-Reply-To: <516AFB99.2040007@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 11:00:51 -0000 On 14.04.13 21:55, Joe Holden wrote: > For non-nat ipfw is still superior in every way, numbered rules > (think: scripts), dummynet, much faster than pf, syntax is a lot nicer > and predictable... And, best of all, it still is buggy. At lest, it's tables handling is unusable. I have been very stubborn IPFW user for very long time, but finally gave up in favor of PF. Nothing like that ever since. I am also not convinced IPFW is any faster than PF. Daniel From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 11:01:59 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A07C9629; Mon, 15 Apr 2013 11:01:59 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id DEF5C693; Mon, 15 Apr 2013 11:01:58 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so1395721wib.16 for ; Mon, 15 Apr 2013 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=LMuPrt462S9z9AkXH3kvHdYSkGOhjzIYZGD51/6lLnU=; b=GFyZycfgLGW4imyNjNF/9bO4uSfdE/wvAtuP+rimb1KXC7DW3DDJIpVpkdSUG0ayan VbJ1Y8w5p8ZbYTUQQwy316d+nJxGX1fTVdipeScpic/7lg+CmVLXlf3BAuF19Abfp4e7 Ic7+pRQ+2rXhELr7nmEM4+yls7t//wnsTahx7deMEibTa9/PzZeWOkYXehl6IAF7NlR4 NvwakhCv2nS1yPWkLWsF+saFHDJKEuq07/Z9fweU/O/dNdhOEMROeA1hyYQyhZY5NTt/ cur9O4xbUfUqv+RuSuYf1qS0a9Vz2tNVljKWDyR9iWKa6AuU15Ypj8cWuSEPTiMDlK+P b6FQ== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr10955574wib.32.1366023718020; Mon, 15 Apr 2013 04:01:58 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 04:01:57 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 14:01:57 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 11:01:59 -0000 On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala wrote: > On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote: >> Hello, Kimmo. >> You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 14:47:24= : >> >> KP> I'm however talking about an ftp client behind a very restrictive >> KP> firewall making an IPv6 connection an ftp server that uses passive >> KP> mode data ports that can't be known in advance. >> Same solution -- inspection of connections to 21 port, without any >> address translation. And if FTP server uses non-standard control >> port, yes, here is a problem, but it cannot be solved with NAT too >> (or your NAT/firewall should expect each and every connection for FTP >> commands, which is heavy and error-prone task). >> > > Mmm, are you thinking of the way Linux iptables handles this scenario > with a kernel mode helper? I don't think any of the three packet > filters in FreeBSD has a functionality like that yet. > > -Kimmo To elaborate on this, Linux iptables has a "related" qualifier for rules and the "related" traffic is identified by kernel mode helpers, ftp is one example for their use. -Kimmo From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 11:15:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6853D441; Mon, 15 Apr 2013 11:15:45 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 0763D994; Mon, 15 Apr 2013 11:15:44 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id w15so3663507vbb.37 for ; Mon, 15 Apr 2013 04:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QDDO3p3C2LJLA3EMAgrUTYFfR63JlEKDYbKmHl31WdM=; b=mE6j1Mb/Lt/Fz5EMMWQBtV3K8IeAm2AvAPBaz/j5hp1MJpgwnfqAoaTLVMRWTae0rz CfM7XFTYHzou4FduroHYoy8APHWHBe1Nb9IwEtQ29ujSZ6MBKYrVfCp2ba3C+Kst2Ehx YLvMM6Dk0YH02+42se1My4dUhz7i+i2CRMRE2uv44K2hQC0mb28IPb4y2Wlqqd1+VztH HX/D4L64DX2YAVvjSj11kJXumyBAEO2K6HjWtIFG8dEOx9v71jOZHIZVZOOWaFHyGq0m 7n+Aci/BkWESBGcUptN4iYNXnPe0bdYV7AzHFflYZdXQWUCzFeGtjaWxLP8x/qPe2g/D ML1w== MIME-Version: 1.0 X-Received: by 10.220.115.135 with SMTP id i7mr15454812vcq.30.1366024544615; Mon, 15 Apr 2013 04:15:44 -0700 (PDT) Received: by 10.59.2.170 with HTTP; Mon, 15 Apr 2013 04:15:44 -0700 (PDT) In-Reply-To: <20130415083517.GB1410@garage.freebsd.pl> References: <20130414044314.GA1115@reks> <20130415083517.GB1410@garage.freebsd.pl> Date: Mon, 15 Apr 2013 07:15:44 -0400 Message-ID: Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 From: Shawn Webb To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Gleb Kurtsou , FreeBSD-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 11:15:45 -0000 On Mon, Apr 15, 2013 at 4:35 AM, Pawel Jakub Dawidek wrote: > > I did receive Shawn's report some time ago, I even installed Chromium to > try to reproduce it, but it didn't crash for me yet. > > If there are some easy, but reliable steps to reproduce it, like "open > this webpage in tab 1, then this webpage in tab 2, then close tab 1" > that would be great. This kernel coredump is not really useful, as we > this is legitimate case of decrementing reference counter. The problem > is that something decremented it earlier when it shouldn't or it wasn't > incremented somewhere. DTrace might be useful tool here if we could > instrument it to log backtrace of all increments and decrements done by > the Chromium processes. Opening and closing tabs seems to be what does it for me. Try opening/closing tabs that have sites open that use Flash (like YouTube). It seems that I can go longer without a kernel panic these days, but it still does happen. I've pretty much switched to using Firefox. I was able to pinpoint the commit, but I wasn't able to pinpoint the actual code that causes the panic. For what it's worth, I'm also running ZFS on root. I'm not sure if that makes any difference. Pawel, can you give me some DTrace scripts to run? I have DTrace enabled on the machine. Thanks, Shawn From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 12:12:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D289EF9; Mon, 15 Apr 2013 12:12:24 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 477AACC4; Mon, 15 Apr 2013 12:12:24 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3Zq7r60C8ZzGN2P; Mon, 15 Apr 2013 14:12:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1366027936; x=1368619937; bh=CDS SV0jzTciporXtxv/xcn/uck9EX9P4mogmf/LFhDk=; b=CjJTrAGAls+g7exQjQW IRp+Zb2lkAiaQbHmYPEE9pdxCMqcRwSiuzu0Dov3bsm88Glki3O07C71kLO/xHMg +y6jLgtyvog/tFG78A3CVGVNTH+kyYH0i8AmUnTKeihyPTXZ3TWZupa22l5oH0TT dIKmeB8cb8VaDe4p7ucrJk8c= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id Dal7cfbi-S8Y; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 9AB15B68; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-net@freebsd.org Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 14:12:16 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <20130415.125100.74672975.sthaug@nethelp.no> In-Reply-To: <20130415.125100.74672975.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304151412.16246.Mark.Martinec+freebsd@ijs.si> Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 12:12:24 -0000 On Monday April 15 2013 12:32:37 Lev Serebryakov wrote: > And, yes, NAT64 will be useful for sure, but it is another story, > not IPv6<->IPv6 translation. Fear not, NPT66 prefix translation is stateless, this is nothing like NAT44 / NAPT. On Monday April 15 2013 12:51:00 sthaug@nethelp.no wrote: > We are *way* too late in the game to completely avoid IPv6 NAT. > Various flavors already exist in the form of RFCs, e.g. NPTv6: > http://tools.ietf.org/html/rfc6296 Prefix translation is useful for SOHO or branch offices with more than one uplink, unless one wants to invest into AS and BGP or start building tunnels: http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html Mark From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 12:44:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C933D97B for ; Mon, 15 Apr 2013 12:44:15 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id 88473E21 for ; Mon, 15 Apr 2013 12:44:15 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id jz10so4073530veb.19 for ; Mon, 15 Apr 2013 05:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZMDVR6SoDYpintoLbf5xsgRoyROqC3wtlWJV63GP9Zk=; b=PENYyRsQ4ysFCw/Lyla5UarZcb4TwzSujsvgrAziSpyINHqG2k7KtFC9gaKhk8YTJN Eas3MirmqAG9r3Jz6NcNmXxS2NgxrCuZwnoW2auHuPO8wRYMG+ax0VQGm7AM/z4QrerY WyVMmB6PvWWKjSlIXLa9hFVhyDd8q6X8pLNL93XloZZJMuEPMRD0YniCBySvJG1sSbX6 PCDiEjfGBMRfcQDSfBNvmL2avpmKTQNs3u0x0UaLhyrt+7AAUOalUPHl6GV8Tu8d1Iiq DncwtN0l3Kip7+CZlJ5xhcSBgbmwXg1mVBYKO7wS2J2LnlnMDjZMlkJfM6sFahd2Yx1o 80iw== X-Received: by 10.220.68.202 with SMTP id w10mr5003177vci.5.1366029854641; Mon, 15 Apr 2013 05:44:14 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.59.9.103 with HTTP; Mon, 15 Apr 2013 05:43:54 -0700 (PDT) In-Reply-To: <516BDA15.6000605@digsys.bg> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <516AFB99.2040007@rewt.org.uk> <516BDA15.6000605@digsys.bg> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 15 Apr 2013 14:43:54 +0200 X-Google-Sender-Auth: qD3pcTRG57zyR0q3YeOnZXbq0L0 Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 12:44:15 -0000 > > I have been very stubborn IPFW user for very long time, but finally gave up > in favor of PF. Nothing like that ever since. I am also not convinced IPFW > is any faster than PF. Hi Daniel, I know that measuring PPS for a firewall is not enought for comparing firewall performance (rfc3511 details lot's of the parameters, but on my small&dirty bench lab with an old server (one core Intel Pentium4 3.00GHz with a dual NIC 82546GB connected to the PCI-X Bus) I've got theses differences (value are in Kpps, small packet size) on FreeBSD 9.1: - forwarding-only: 405 Kpps - IPFW enabled: 320 Kpps - PF enabled: 274 Kpps IPFW was configured with only one line: add 3000 allow ip from any to any And PF with one line too: pass => On this simple test, IPFW is "faster" than PF regarding the forwarding rate. But without "ipfwsync" feature, IPFW is useless for our use case... Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 14:33:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA5DB7B; Mon, 15 Apr 2013 14:33:11 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-04.shaw.ca (smtp-out-04.shaw.ca [64.59.134.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C554362; Mon, 15 Apr 2013 14:33:11 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=HUoWN8sqH4wajA0WKpKyUV7G7o/UpN4YSPso/+twBIs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=s1O25tkdAAAA:8 a=MyE6jBz-AAAA:8 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=ZB5LerlCAAAA:8 a=BWvPGDcYAAAA:8 a=d8jxi4gjFzhM9obhgiUA:9 a=CjuIK1q_8ugA:10 a=6oEG72nUbxYA:10 a=OyOq_G8mXAEA:10 a=aLekXsIfG0IA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-04.shaw.ca with ESMTP; 15 Apr 2013 08:33:33 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A782C192; Mon, 15 Apr 2013 07:33:04 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FEX3c3005916; Mon, 15 Apr 2013 07:33:04 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151433.r3FEX3c3005916@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Warren Block Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Warren Block of "Sun, 14 Apr 2013 09:48:33 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 07:33:03 -0700 Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:33:11 -0000 In message , Warren Block writ es: > On Sun, 14 Apr 2013, Chris Rees wrote: > > > On 14 April 2013 01:41, Rui Paulo wrote: > >> 2013/04/13 16:01?Scott Long ??????: > >> > >>> Maybe something else, but whatever it is, it should be done. If you and > Gleb don't want to do this, I will. > >> > >> I already started writing a guide. See here for a very incomplete version: > >> > >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html > > > > If you're really serious about deprecating ipf, we absolutely have to > > remove instructions for it from the Handbook as soon as possible; > > every time a new user comes across instructions you're going to have > > yet another annoyed party. > > > > http://www.bayofrum.net/~crees/patches/remove-ipf.diff > > This should probably be done like we did for CVS for ports. Mark it as > deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 13:35:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14435430; Mon, 15 Apr 2013 13:35:04 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id E071DE5; Mon, 15 Apr 2013 13:35:03 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id p12so2521568pdj.19 for ; Mon, 15 Apr 2013 06:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=6w1a/ilfxqYxh9YsEcBZe+QNkQTxdeDjJEE4ClqIYK0=; b=oKE+L0MX1/YQeM9rew3SJEVmgli/26IE/PMtbHQcjsALfvUyHDIKrbhQA2B4Bvu2Cu wZW0iWQQ3h5eTU+JdwYSxIjN75npB2LyZEdzGEQncmbhSv8WAFWWZDKP33GaeXkI7uDh z7xcKMpdjVFZJFxC086jMwwPxy9uYuybtvPsFarRxj2qi+K2MCgdvxCZkaoFiEZQeL0t gkwAs6b6Lv0ZsWAJkixjALW5zUxkhmMg2QZh8ihBuAA9APfgW7sEcUkke/qQx/swCWmn iXZKAP5YBUHMAsgQqM8uYQQz4sQlQsHStnDNdwEvaUUkOJuoXbUjNTnplcrOGG+ufkfU l/fg== X-Received: by 10.68.233.2 with SMTP id ts2mr7602996pbc.133.1366032903145; Mon, 15 Apr 2013 06:35:03 -0700 (PDT) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id qr7sm20385879pbc.16.2013.04.15.06.35.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 15 Apr 2013 06:35:01 -0700 (PDT) Subject: Re: mirror site ftp3.za.freebsd.org From: Sean Bruno To: Ian FREISLICH In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-yZ+6gQ+IZmmrYTciyUoM" Date: Mon, 15 Apr 2013 06:34:59 -0700 Message-ID: <1366032899.7836.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Mon, 15 Apr 2013 16:21:37 +0000 Cc: "clusteradm@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:35:04 -0000 --=-yZ+6gQ+IZmmrYTciyUoM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-04-15 at 11:22 +0200, Ian FREISLICH wrote: > Hi >=20 > For quite some time this mirror site has been unreachable. AFAICT, > my ex colleagues who used to maintain it have moved on and it's now > been left unmaintained. I left there in 2004 and Mark Murray who > set it up left shortly thereafter. Perhaps it should be dropped > from the mirror list. >=20 > Ian >=20 Moving to clusteradm@ to poke at it. Sean --=-yZ+6gQ+IZmmrYTciyUoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRbAIDAAoJEBkJRdwI6BaH2dgH/A+y6+m5dfWORYAG0qUFch5N VpF8p0gVlXSt/+B6uvRLAdYI6oZQAGz68BmUx78FfFOEu/qqW+VayZu2P6Em5Mpt jecJF5HjtwxndiTQ0uSplvWEvuHGByEKfwLpg8Y0m1Sf2+lm7lPidE9D7asGViHM 2a+6FrfRHu+ww0sOzww7HgbRnHowqCaZFauzsyBbO41nt4QIhlDA2aY474tdDIny NH6wDygFjC6v8ra6ZYBNxJ7bP18WJp3SiYI0E1t1xrb43TwVWZq8ZuArXXNlwqs+ 8eQ6owOx4YmhqnCE0Yi22Pn5aKW/9uZeUUTw12vy7/z/uKvnZFmoSTWKW7CHUV0= =6QpA -----END PGP SIGNATURE----- --=-yZ+6gQ+IZmmrYTciyUoM-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 16:37:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1BA677B9; Mon, 15 Apr 2013 16:37:53 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id F22F8C1C; Mon, 15 Apr 2013 16:37:52 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX19ZCZpLg3X25ygaCjqzq9Mlk8Alxk7jxeo@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3FGbh7R017217; Mon, 15 Apr 2013 16:37:43 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Mon, 15 Apr 2013 16:37:43 -0000 Message-ID: <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> In-Reply-To: <201304151433.r3FEX3c3005916@slippy.cwsent.com> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> Date: Mon, 15 Apr 2013 16:37:43 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Cy Schubert" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 16:37:53 -0000 Ok, seems someone has taken the job. > In message , Warren Block > writ > es: >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >>> Maybe something else, but whatever it is, it should be done. If you >> and >> Gleb don't want to do this, I will. >> >> >> >> I already started writing a guide. See here for a very incomplete >> version: >> >> >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html >> > >> > If you're really serious about deprecating ipf, we absolutely have to >> > remove instructions for it from the Handbook as soon as possible; >> > every time a new user comes across instructions you're going to have >> > yet another annoyed party. >> > >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff >> >> This should probably be done like we did for CVS for ports. Mark it as >> deprecated, then remove the Handbook section once the code is removed. > > Sorry, I'm coming in late on this discussion. I'm willing to take it on as > I've been planning on updating it for a while. Would a src committer like > to take me on for mentorship? > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 16:47:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24BBBA31; Mon, 15 Apr 2013 16:47:36 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 07F85D0A; Mon, 15 Apr 2013 16:47:35 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX18HA453t2DQ4GHFc0QTQWZlzFPaXd1WQos@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3FGlX98018902; Mon, 15 Apr 2013 16:47:33 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Mon, 15 Apr 2013 16:47:33 -0000 Message-ID: <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> In-Reply-To: <201304151433.r3FEX3c3005916@slippy.cwsent.com> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> Date: Mon, 15 Apr 2013 16:47:33 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Cy Schubert" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 16:47:36 -0000 However it would of been better if said person asked me as I already offered to take it on but whatever. > In message , Warren Block > writ > es: >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >>> Maybe something else, but whatever it is, it should be done. If you >> and >> Gleb don't want to do this, I will. >> >> >> >> I already started writing a guide. See here for a very incomplete >> version: >> >> >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html >> > >> > If you're really serious about deprecating ipf, we absolutely have to >> > remove instructions for it from the Handbook as soon as possible; >> > every time a new user comes across instructions you're going to have >> > yet another annoyed party. >> > >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff >> >> This should probably be done like we did for CVS for ports. Mark it as >> deprecated, then remove the Handbook section once the code is removed. > > Sorry, I'm coming in late on this discussion. I'm willing to take it on as > I've been planning on updating it for a while. Would a src committer like > to take me on for mentorship? > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 16:55:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EC53EEF; Mon, 15 Apr 2013 16:55:22 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id CBA44DFF; Mon, 15 Apr 2013 16:55:21 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=oX08kPI8AAAA:8 a=s1O25tkdAAAA:8 a=MyE6jBz-AAAA:8 a=CjxXgO3LAAAA:8 a=ZB5LerlCAAAA:8 a=No9LUIqVyjyxOwiwL1sA:9 a=CjuIK1q_8ugA:10 a=6oEG72nUbxYA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=4wfsiePOASQA:10 a=OyOq_G8mXAEA:10 a=aLekXsIfG0IA:10 a=rC2wZJ5BpNYA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 10:56:17 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 31050D1; Mon, 15 Apr 2013 09:55:20 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FGtJqI003143; Mon, 15 Apr 2013 09:55:19 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151655.r3FGtJqI003143@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: cpet@sdf.org Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from cpet@sdf.org of "Mon, 15 Apr 2013 16:37:43 -0000." <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 09:55:19 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:55:22 -0000 I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org In message <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org>, cpet@sdf.org writes: > Ok, seems someone has taken the job. > > > > In message , Warren Block > > writ > > es: > >> On Sun, 14 Apr 2013, Chris Rees wrote: > >> > >> > On 14 April 2013 01:41, Rui Paulo wrote: > >> >> 2013/04/13 16:01?Scott Long ??????: > >> >> > >> >>> Maybe something else, but whatever it is, it should be done. If you > >> and > >> Gleb don't want to do this, I will. > >> >> > >> >> I already started writing a guide. See here for a very incomplete > >> version: > >> >> > >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html > >> > > >> > If you're really serious about deprecating ipf, we absolutely have to > >> > remove instructions for it from the Handbook as soon as possible; > >> > every time a new user comes across instructions you're going to have > >> > yet another annoyed party. > >> > > >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff > >> > >> This should probably be done like we did for CVS for ports. Mark it as > >> deprecated, then remove the Handbook section once the code is removed. > > > > Sorry, I'm coming in late on this discussion. I'm willing to take it on as > > I've been planning on updating it for a while. Would a src committer like > > to take me on for mentorship? > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 17:10:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC59B783; Mon, 15 Apr 2013 17:10:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id EDFF6EEE; Mon, 15 Apr 2013 17:10:43 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id o7so1692107wea.36 for ; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=APEofcB5mBL0ZyW0fk7N3C0sGPVmTsHwLEli09CrBBg=; b=OISbCgmXYsI6OH0fdshyDLlOvGSoK3zlbiTl1AiRnOSqLglvVWICeAdYn/R0eWYXBo vu1yRels+XWY9bZCfU1hmoRLSgA7gNwm6QF/+vk0Rp3Q+zXPjTxT3V40oOyhSemYxWxy mLnGDm5iXp6uPtFZB7dwvoGUtMzf26I1aRId8Y/Dd2/lgax1WppXsfuAc+HKXwEYTSMC SnyB7HxAHjb3c/rZ7I47v95vrY45sQsIH/acfMx4EGWftuTn3wJcnq1NnsqvGV6MlGxC briUSVV6qY8U6Xc7PrjIdBL8FeffckEHmUtH5fwtyjCUWrKvgpBAaenhzVAKZkIIYL9w 9PQg== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr13670725wid.29.1366045842552; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.121.136 with HTTP; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) In-Reply-To: <201304151655.r3FGtJqI003143@slippy.cwsent.com> References: <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> <201304151655.r3FGtJqI003143@slippy.cwsent.com> Date: Mon, 15 Apr 2013 10:10:42 -0700 X-Google-Sender-Auth: 9_w36DVJwWKnPcKSQPG7065O28Y Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Adrian Chadd To: Cy Schubert Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , cpet@sdf.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 17:10:44 -0000 ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_. Adrian On 15 April 2013 09:55, Cy Schubert wrote: > I've been planning on taking on IP Filter for quite some time. > Unfortunately I've left my src commit bit lapse (my ports commit bit is > alive and well though) thus I'm looking for a mentor. In addition I'm > working on an ACER WMI/ACPI kld. One mentor would be preferred but two > would be fine too. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > In message <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org>, > cpet@sdf.org > writes: >> Ok, seems someone has taken the job. >> >> >> > In message , Warren Block >> > writ >> > es: >> >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >> >> >>> Maybe something else, but whatever it is, it should be done. If you >> >> and >> >> Gleb don't want to do this, I will. >> >> >> >> >> >> I already started writing a guide. See here for a very incomplete >> >> version: >> >> >> >> >> >> http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html >> >> > >> >> > If you're really serious about deprecating ipf, we absolutely have to >> >> > remove instructions for it from the Handbook as soon as possible; >> >> > every time a new user comes across instructions you're going to have >> >> > yet another annoyed party. >> >> > >> >> > http://www.bayofrum.net/~crees/patches/remove-ipf.diff >> >> >> >> This should probably be done like we did for CVS for ports. Mark it as >> >> deprecated, then remove the Handbook section once the code is removed. >> > >> > Sorry, I'm coming in late on this discussion. I'm willing to take it on as >> > I've been planning on updating it for a while. Would a src committer like >> > to take me on for mentorship? >> > >> > >> > -- >> > Cheers, >> > Cy Schubert >> > FreeBSD UNIX: Web: http://www.FreeBSD.org >> > >> > >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > >> >> > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 17:09:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AF4E579; Mon, 15 Apr 2013 17:09:22 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id EC413EC5; Mon, 15 Apr 2013 17:09:21 +0000 (UTC) Received: from [IPv6:2620:149:f01:247:50e9:8e57:ccae:d65f] (unknown [IPv6:2620:149:f01:247:50e9:8e57:ccae:d65f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 03A013981E; Mon, 15 Apr 2013 10:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1366045755; bh=pqDCn48SpNxdoy5ftWA+lZSZ4FANDTy8S34LqKgkueE=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=GxsrFfQgZnqVkU30u94OTwKGEq1JvHE/bvhwhjjaxS4AK6tJ9AtYPktITZVQCa3CP +P8f0ej7vk5c3kp59Qk41jjBJh7kLMpJd1GtLidMuf4GalxW1Q15k0LQZ4ZY3ZDRwO yU8j1lBPYXVbOJW83IpSj2fZEsXYZXrsDfKcouzo= References: <201304151655.r3FGtJqI003143@slippy.cwsent.com> Mime-Version: 1.0 (1.0) In-Reply-To: <201304151655.r3FGtJqI003143@slippy.cwsent.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Message-Id: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> X-Mailer: iPhone Mail (10B329) From: Rui Paulo Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 10:09:17 -0700 To: Cy Schubert X-Mailman-Approved-At: Mon, 15 Apr 2013 17:23:31 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 17:09:22 -0000 2013/04/15 9:55=1B$B!"=1B(BCy Schubert =1B$B$N%a%= C%;!<%8=1B(B: > I've been planning on taking on IP Filter for quite some time.=20 > Unfortunately I've left my src commit bit lapse (my ports commit bit is=20= > alive and well though) thus I'm looking for a mentor. In addition I'm=20 > working on an ACER WMI/ACPI kld. One mentor would be preferred but two=20 > would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b= e in the base system. Perhaps you can work on it as a port? Why do you want to work on something that people have been trying to remove s= ince 2005? From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 17:48:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E33F7EB; Mon, 15 Apr 2013 17:48:56 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA3B10C3; Mon, 15 Apr 2013 17:48:55 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=MyE6jBz-AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=WboiWaibMC_ph7dsMDUA:9 a=CjuIK1q_8ugA:10 a=aLekXsIfG0IA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 11:49:12 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 8D5B480; Mon, 15 Apr 2013 10:48:44 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FHmhC3002734; Mon, 15 Apr 2013 10:48:43 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151748.r3FHmhC3002734@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Rui Paulo of "Mon, 15 Apr 2013 10:09:17 -0700." <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 10:48:43 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:48:56 -0000 In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo writes: > 2013/04/15 9:55$B!"(BCy Schubert $B$N%a%C%;!<%8(B: > > > I've been planning on taking on IP Filter for quite some time. > > Unfortunately I've left my src commit bit lapse (my ports commit bit is > > alive and well though) thus I'm looking for a mentor. In addition I'm > > working on an ACER WMI/ACPI kld. One mentor would be preferred but two > > would be fine too. > > What are your plans regarding ipfilter? I remain unconvinced that it should b > e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. > > Why do you want to work on something that people have been trying to remove s > ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 17:49:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9712C988 for ; Mon, 15 Apr 2013 17:49:21 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF8410DE for ; Mon, 15 Apr 2013 17:49:21 +0000 (UTC) Received: from [38.105.238.108] (port=49477 helo=[10.16.241.159]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1URnWq-0002ZI-7n for current@freebsd.org; Mon, 15 Apr 2013 13:49:20 -0400 From: George Neville-Neil Content-Type: multipart/signed; boundary="Apple-Mail=_6E7C0653-A82C-488C-87E2-1228802866C6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Folks using Apache 2 ought to be interested in this DTrace module... Message-Id: <02C9F54B-860C-4D5E-84CC-551BC494D041@neville-neil.com> Date: Mon, 15 Apr 2013 13:49:28 -0400 To: current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 17:49:21 -0000 --Apple-Mail=_6E7C0653-A82C-488C-87E2-1228802866C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://github.com/davepacheco/mod_usdt I've no time to port this but it ought to be straight forward and would = be interesting to those serving up=20 lots of Apache on FreeBSD. If someone wants to hack on it and have me review it, I can do that. Best, George --Apple-Mail=_6E7C0653-A82C-488C-87E2-1228802866C6 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.19 (Darwin) iEYEARECAAYFAlFsPagACgkQYdh2wUQKM9K7gQCfQZ7q8Ig8fF3UI3/6Es1EIGWT OP0AoL+cEQnmxDUuF8Qn+UKU8BLkW+fP =L+o1 -----END PGP SIGNATURE----- --Apple-Mail=_6E7C0653-A82C-488C-87E2-1228802866C6-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 18:49:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFAA3C2D; Mon, 15 Apr 2013 18:49:20 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 8D146132D; Mon, 15 Apr 2013 18:49:20 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so3982107vbh.26 for ; Mon, 15 Apr 2013 11:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FjVV7VOsNjGtJCWgVclbNWEX2Wdf0BAhoFTKy4HyTY8=; b=skhejkY0dHHPB8NDe2rA5bEdCZ14UeAliEEw/63/8B1DwqsmdBhsf0ua7I1//WsHw4 nr12fcmz2ErB1zsxRRMsAAyV//dwA0jGSEdpTbb1NJZ3P/f7CnNU9vn21f5niqXB2otB UjRdyjzhYhuMOPfrKXFhu+bvjVP4ZLBfiLqxbxObZg1TcxlBBgZlsp23i2rt0srByvqz wWFOvvrgnSdRZwaKZCNFRu8bestG9Yoi8URsot7LW0jDGaKaVKanZkLmx7j2GsC/iYG9 z6VrEw63Eq5EKBeNlm2FTRjlabHdlXSxH8opeJAo0CtYtw0ve4mnkn1nLfOkAckESekx Wd0A== MIME-Version: 1.0 X-Received: by 10.220.106.14 with SMTP id v14mr17014585vco.2.1366051760054; Mon, 15 Apr 2013 11:49:20 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Mon, 15 Apr 2013 11:49:19 -0700 (PDT) In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 14:49:19 -0400 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: Cy Schubert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 18:49:21 -0000 Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrot= e: > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo > writes: > > 2013/04/15 9:55=E3=80=81Cy Schubert =E3=81= =AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > > > > I've been planning on taking on IP Filter for quite some time. > > > Unfortunately I've left my src commit bit lapse (my ports commit bit = is > > > alive and well though) thus I'm looking for a mentor. In addition I'm > > > working on an ACER WMI/ACPI kld. One mentor would be preferred but tw= o > > > would be fine too. > > > > What are your plans regarding ipfilter? I remain unconvinced that it > should b > > e in the base system. Perhaps you can work on it as a port? > > The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't > done much with IPF while employed with Sun. Since then there has been som= e > development that is long overdue for HEAD. > > I'm not sure if I'd MFC it into 9 or not. > > I did consider a port but given it would has to touch bits and pieces of > the source tree (/usr/src), a port would be messy and the decision was ma= de > to work on importing it into base. > > > > > Why do you want to work on something that people have been trying to > remove s > > ince 2005? > > I and others have been using it in FreeBSD for over decade. For the longe= st > of time we'd use a common set of rules across a FreeBSD and Solaris farm > (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). > Interoperability with other systems which use IP Filter is a plus. If > there's a maintainer, it only makes FreeBSD richer. Losing IP Filter woul= d > be a loss. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 18:54:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BC83E86; Mon, 15 Apr 2013 18:54:44 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id ADB16136D; Mon, 15 Apr 2013 18:54:43 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id hf12so4124080vcb.7 for ; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b11ecb/K+a8WPRlSgj3UFo4QpM0Qg2eo3TCnuKuc8Yo=; b=qfWHoNlTBke+WuD+BkrpzETt2gu1Dp+pHKNRVyI/dByGuDJkND+7CaFtOMBfN6t+Ei AoOe/Pegj21UK4YXJZimOjsBW3bfYC/atXbs6U1OHS0Oz5XTToOLBS++uiqSK6QKXWoY 0uY9z9hAlNo1ArWx4ci1CThCNm88nSFjnLgs9xhGNAxyLb4ohjYO+nUrZvXTutnzjfjF 9DNt83bc5hEKNbhGqcqjNcpO2pPhXU3AGfvYRHU7B5gd4hUgkL7U0468KsIYTL92gxTF xwO57LdK5BkxbgnhRK3ESGU1FJzE9aUerKempvdr7GjTzycMWbA62/kjKzJia+uYmwmr 23pw== MIME-Version: 1.0 X-Received: by 10.52.89.229 with SMTP id br5mr7580751vdb.24.1366052077614; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) In-Reply-To: References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 14:54:37 -0400 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: Cy Schubert Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 18:54:44 -0000 To my knowledge it is already off by default and you need these options to enable it options IPFILTER options IPFILTER_LOG so to those that wish to have it removed from base, if it has a maintainer whats the trouble? On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr. wrote: > > Thank you to those that have expressed interest in maintaining IP Filter.. > > My thoughts are, could we consider putting a option in the kernel config, > and leaving it off by default for GENERIC? > I think this is a acceptable compromise, considering some people wish for > it to be removed. > > Sam Fourman Jr. > > > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrote: > >> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo >> writes: >> > 2013/04/15 9:55$B!"(BCy Schubert $B$N%a%C%;!<%8(B: >> > >> > > I've been planning on taking on IP Filter for quite some time. >> > > Unfortunately I've left my src commit bit lapse (my ports commit bit >> is >> > > alive and well though) thus I'm looking for a mentor. In addition I'm >> > > working on an ACER WMI/ACPI kld. One mentor would be preferred but two >> > > would be fine too. >> > >> > What are your plans regarding ipfilter? I remain unconvinced that it >> should b >> > e in the base system. Perhaps you can work on it as a port? >> >> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't >> done much with IPF while employed with Sun. Since then there has been some >> development that is long overdue for HEAD. >> >> I'm not sure if I'd MFC it into 9 or not. >> >> I did consider a port but given it would has to touch bits and pieces of >> the source tree (/usr/src), a port would be messy and the decision was >> made >> to work on importing it into base. >> >> > >> > Why do you want to work on something that people have been trying to >> remove s >> > ince 2005? >> >> I and others have been using it in FreeBSD for over decade. For the >> longest >> of time we'd use a common set of rules across a FreeBSD and Solaris farm >> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). >> Interoperability with other systems which use IP Filter is a plus. If >> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would >> be a loss. >> >> >> -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: http://www.FreeBSD.org >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > > > -- > > Sam Fourman Jr. > -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:27:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5625692E; Mon, 15 Apr 2013 19:27:57 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id C6E3315CE; Mon, 15 Apr 2013 19:27:56 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=CjxXgO3LAAAA:8 a=BWvPGDcYAAAA:8 a=MyE6jBz-AAAA:8 a=6I5d2MoRAAAA:8 a=VjTKFRfQl6pNXV81uPAA:9 a=CjuIK1q_8ugA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=aLekXsIfG0IA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 13:28:23 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id B1CE180; Mon, 15 Apr 2013 12:27:55 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJRtq9002799; Mon, 15 Apr 2013 12:27:55 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151927.r3FJRtq9002799@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Scott Long Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Scott Long of "Mon, 15 Apr 2013 12:56:04 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 12:27:55 -0700 Cc: Warren Block , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:27:57 -0000 In message , Scott Long writes: > > On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote: > > > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo > > writes: > >> 2013/04/15 9:55$B!"(BCy Schubert $B$N%a%C%;!<%8 > (B: > >> > >>> I've been planning on taking on IP Filter for quite some time. > >>> Unfortunately I've left my src commit bit lapse (my ports commit bit is > >>> alive and well though) thus I'm looking for a mentor. In addition I'm > >>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two > >>> would be fine too. > >> > >> What are your plans regarding ipfilter? I remain unconvinced that it shoul > d b > >> e in the base system. Perhaps you can work on it as a port? > > > > The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't > > done much with IPF while employed with Sun. Since then there has been some > > development that is long overdue for HEAD. > > > > I'm not sure if I'd MFC it into 9 or not. > > > > I did consider a port but given it would has to touch bits and pieces of > > the source tree (/usr/src), a port would be messy and the decision was made > > > to work on importing it into base. > > > >> > >> Why do you want to work on something that people have been trying to remov > e s > >> ince 2005? > > > > I and others have been using it in FreeBSD for over decade. For the longest > > > of time we'd use a common set of rules across a FreeBSD and Solaris farm > > (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). > > Interoperability with other systems which use IP Filter is a plus. If > > there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would > > be a loss. > > > > > If you're committed to maintaining IPFilter, that's great. However, it can't > be > left to stagger along in a zombie state with nothing more than good intentio > ns > from well meaning people. What is your timeline for getting it back into sha > pe > and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:48:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8036B2D4; Mon, 15 Apr 2013 19:48:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A5FD816A8; Mon, 15 Apr 2013 19:48:37 +0000 (UTC) Message-ID: <516C58ED.40505@FreeBSD.org> Date: Mon, 15 Apr 2013 15:45:49 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130408 Thunderbird/17.0.5 MIME-Version: 1.0 To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> In-Reply-To: <201304151927.r3FJRtq9002799@slippy.cwsent.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 19:48:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: > In message , Scott > Long writes: >> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert >> wrote: >> >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, >>> Rui Paulo writes: >>>> 2013/04/15 9:55$B!"(BCy Schubert >>>> $B$N%a%C%;!<%8 >> (B: >>>> >>>>> I've been planning on taking on IP Filter for quite some >>>>> time. Unfortunately I've left my src commit bit lapse (my >>>>> ports commit bit is alive and well though) thus I'm looking >>>>> for a mentor. In addition I'm working on an ACER WMI/ACPI >>>>> kld. One mentor would be preferred but two would be fine >>>>> too. >>>> >>>> What are your plans regarding ipfilter? I remain unconvinced >>>> that it shoul >> d b >>>> e in the base system. Perhaps you can work on it as a port? >>> >>> The initial plan was to import IP Filter 5.1.2 into HEAD. >>> darrenr@ hadn't done much with IPF while employed with Sun. >>> Since then there has been some development that is long overdue >>> for HEAD. >>> >>> I'm not sure if I'd MFC it into 9 or not. >>> >>> I did consider a port but given it would has to touch bits and >>> pieces of the source tree (/usr/src), a port would be messy and >>> the decision was made >> >>> to work on importing it into base. >>> >>>> >>>> Why do you want to work on something that people have been >>>> trying to remov >> e s >>>> ince 2005? >>> >>> I and others have been using it in FreeBSD for over decade. For >>> the longest >> >>> of time we'd use a common set of rules across a FreeBSD and >>> Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a >>> local CVS repo). Interoperability with other systems which use >>> IP Filter is a plus. If there's a maintainer, it only makes >>> FreeBSD richer. Losing IP Filter would be a loss. >>> >> >> >> If you're committed to maintaining IPFilter, that's great. >> However, it can't be left to stagger along in a zombie state >> with nothing more than good intentio ns from well meaning people. >> What is your timeline for getting it back into sha pe and >> re-integrating yourself into the committer community? > > I would think this would be my top priority right now. I'd like to > see it at the latest level in HEAD. I would like to MFC to 9-STABLE > at some point. > > Given that IPF already lives in src/contrib and src/sys/contrib, > would the change in License from Darren Reed's own not so BSD > friendly IPF license to GPLv2 be of concern. I recall there was a > lot of concern over IPF's license change at the time. (FreeBSD > moved it to contrib while OpenBSD removed it completely and wrote > PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_with_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbFjtAAoJECXpabHZMqHOSFkIAK72iLtzb1py01/A+SbX8ejn hi5eh8ri6QQ2Kh4K96b/R5oHk5PoGNpc7xX7Kbp1wyJ2OrdNvAPnElwMDpPCjnRC rKPXiS25Km9D1e18E2pLB4iTweb/AOf87bGRz6skm3Rq0D4XOX9dwRndj1vqRxmH V/Rrdlzprx4EvDmgmfAfSZwGTGit6fVXqHHj5LtONURNKe4qAliVIdxB1vQFQBqB BnHF1gN7tIJVCrn+4yKSVsv6vqRSXp5LOIRBw2ooURKEkkKqVIapboEU+pGitN4g dbVZkoBol7V+LfqBBpsG7JH+OboUvdvWJ7hqeNtAV4YerBBBbePvx9D5iehmRUk= =/mAG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:55:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 905EC520; Mon, 15 Apr 2013 19:55:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF1616F3; Mon, 15 Apr 2013 19:55:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FJtiRO001999; Mon, 15 Apr 2013 23:55:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FJtiq6001998; Mon, 15 Apr 2013 23:55:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 15 Apr 2013 23:55:44 +0400 From: Gleb Smirnoff To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415195544.GY76816@FreeBSD.org> References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 19:55:55 -0000 Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C> done much with IPF while employed with Sun. Since then there has been some C> development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. C> I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C> I did consider a port but given it would has to touch bits and pieces of C> the source tree (/usr/src), a port would be messy and the decision was made C> to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:58:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 825A478F for ; Mon, 15 Apr 2013 19:58:32 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB0E172E for ; Mon, 15 Apr 2013 19:58:32 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r3FJwQn5009704 for ; Mon, 15 Apr 2013 15:58:31 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <516C5BE2.50005@m5p.com> Date: Mon, 15 Apr 2013 15:58:26 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 15 Apr 2013 15:58:31 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 19:58:32 -0000 It was pretty successful. All my 8.3 packages are still running very happily, though at some point I imagine I will have to update and recompile them. But ... When I press ENTER in the boot0 screen, I get the hyphen that will start spinning after a timeout and begin loading boot1 (which, as far as I know, I have not updated). boot1 (I think) presents me with a prompt that does not respond to key presses on the keyboard. It times out and continues loading anyway. At this stage, I am always presented with a manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get any further. Does this just mean I should update the boot code? Presumably "fdisk -B" won't change anything. Should I just do "bsdlabel -B"? (It's an MBR disk.) Aside from this glitch, I'm very happy with how smoothly the update went. And I wouldn't be complaining, except that I'm tired of having to type "ufs:/dev/ada0s1a" every time I boot. -- George Mitchell From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 20:12:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94120AD9; Mon, 15 Apr 2013 20:12:47 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 20D1817AC; Mon, 15 Apr 2013 20:12:47 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=N9rBXh7b3HRsED3skiAA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 14:11:33 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 872BE80; Mon, 15 Apr 2013 13:12:40 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FKCdI3085567; Mon, 15 Apr 2013 13:12:39 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304152012.r3FKCdI3085567@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Gleb Smirnoff of "Mon, 15 Apr 2013 23:55:44 +0400." <20130415195544.GY76816@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 13:12:39 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:12:47 -0000 In message <20130415195544.GY76816@FreeBSD.org>, Gleb Smirnoff writes: > Cy, > > good news that you volunteered to work on this! > > On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: > C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't > C> done much with IPF while employed with Sun. Since then there has been some > > C> development that is long overdue for HEAD. > > The problem is that v5.1.2 is under GPL. I'm afraid we should update > to v4.1.34 only, and then stick to it. So the nearest TODO list > is smth like: > > - update to v4.1.34 > - cleanse old kernel APIs (timeout(9) at least) > - fix VIMAGE > - review open PRs (some might should be closed) > - since we do not expect more imports, may be cleanse non-FreeBSD stuff > from there? > - maybe move it into sys/netpfil? Need to consult imp@ on that. License > is very closed to BSD, but has some additions. A small step in the right direction is a good thing. I'll run the patches by you first. The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. > > C> I'm not sure if I'd MFC it into 9 or not. > > This is up to you, but be adviced that head already differs from stable/9, > for example network stack is entirely in network byte order. So merging > would require a lot of attention and testing. > > C> I did consider a port but given it would has to touch bits and pieces of > C> the source tree (/usr/src), a port would be messy and the decision was mad > e > C> to work on importing it into base. > > Port isn't an option. IPFilter is too close to many kernel APIs, that > can change quickly. Agreed. I looked at it a few months ago and determined that src is where it should be. (I put it aside, getting ACER WMI/ACPI working on my new Acer laptop was my priority at the time.) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 18:54:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 307ACDEF for ; Mon, 15 Apr 2013 18:54:21 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm11-vm3.bullet.mail.ne1.yahoo.com (nm11-vm3.bullet.mail.ne1.yahoo.com [98.138.91.141]) by mx1.freebsd.org (Postfix) with ESMTP id E683E1361 for ; Mon, 15 Apr 2013 18:54:20 +0000 (UTC) Received: from [98.138.90.49] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 Received: from [98.138.226.125] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 Received: from [127.0.0.1] by smtp204.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366052053; bh=V/xNCL3BbI6r2ZxwodymFOu0kCpQSC5l15IWEoXIFuY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=yi8RhwxL3JQK9oCGh7IytdVXfuFbUZGL2EZvauipAU3wLC3qIvbbXK9CGgzN7XrOICiKA5uC8o4oWP2NHNj37ZilhtRFVXBChGKQ0z3D7VeVw0ytI5gjuzBHWvbCerTOXjS2sOiIqt4wLZtC+Ine6z/vecLx7otht69QnKmDQLY= X-Yahoo-Newman-Id: 804993.13129.bm@smtp204.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WHZN.SwVM1kdI99PkbAVnxVr4v78xA4Xst1WwRVWlnXYzFa fFQ7iAMZ.UO514xAUrqi2hMg4JpihDswZopfd6SkiJSt5aau7BWuO4tHzDJb ly8Ra0939r0uL40lezOFSY0O_itQTqYtvuN6DL6A0INy6x32vhSsvIPZ2TX8 6WYPB7wdC7PQoK.BRAlpRw9fQklMknXKmkOYV8PpjJYrM7uD80hmtm2mCF3h .k9hpZrb.xxgaPMQiFoXwjcFyoS8KfyjbHWgjrEwMInucKoPFbdtgcT34dHW 48ExickgcGfDMlhm7BLwUMjj.0ztsSKovW2BIkYY.AoaO5oqyr16uVokvTqq clbWezqNHjWX6cTTRiMKzgiqY7Vn7qLUrA0L1VdkxUWsLSBhbExcJ0hV7iBV N.x07rdnVGOLEf1lvydEW4Wl4LQauVHkcm2iq2Aelc6QIcQeNOav8vJv9U8p hJFobkO8UJZOi X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with plain) by smtp204.mail.ne1.yahoo.com with SMTP; 15 Apr 2013 11:54:13 -0700 PDT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: Date: Mon, 15 Apr 2013 12:54:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 15 Apr 2013 20:20:53 +0000 Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 18:54:21 -0000 The desire to remove it stems from the inability to give it adequate = engineering=20 service as the network stack evolves. Simply taking it out of a kernel = config file doesn't address that problem at all. If it's going to stay in FreeBSD = at all, it needs to be maintained. This could be set about a fair amount of stuff = in FreeBSD, but IPFilter stands out since there's a high rate of needed change = happening in the network stack, and it shouldn't be left to rot nor to be a stumbling = block for those changes. Scott On Apr 15, 2013, at 12:49 PM, "Sam Fourman Jr." = wrote: > Thank you to those that have expressed interest in maintaining IP = Filter.. >=20 > My thoughts are, could we consider putting a option in the kernel = config, > and leaving it off by default for GENERIC? > I think this is a acceptable compromise, considering some people wish = for > it to be removed. >=20 > Sam Fourman Jr. >=20 >=20 > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert = wrote: >=20 >> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo >> writes: >>> 2013/04/15 9:55=E3=80=81Cy Schubert = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>>=20 >>>> I've been planning on taking on IP Filter for quite some time. >>>> Unfortunately I've left my src commit bit lapse (my ports commit = bit is >>>> alive and well though) thus I'm looking for a mentor. In addition = I'm >>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but = two >>>> would be fine too. >>>=20 >>> What are your plans regarding ipfilter? I remain unconvinced that it >> should b >>> e in the base system. Perhaps you can work on it as a port? >>=20 >> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ = hadn't >> done much with IPF while employed with Sun. Since then there has been = some >> development that is long overdue for HEAD. >>=20 >> I'm not sure if I'd MFC it into 9 or not. >>=20 >> I did consider a port but given it would has to touch bits and pieces = of >> the source tree (/usr/src), a port would be messy and the decision = was made >> to work on importing it into base. >>=20 >>>=20 >>> Why do you want to work on something that people have been trying to >> remove s >>> ince 2005? >>=20 >> I and others have been using it in FreeBSD for over decade. For the = longest >> of time we'd use a common set of rules across a FreeBSD and Solaris = farm >> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). >> Interoperability with other systems which use IP Filter is a plus. If >> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter = would >> be a loss. >>=20 >>=20 >> -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: http://www.FreeBSD.org >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 >=20 >=20 > --=20 >=20 > Sam Fourman Jr. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 18:56:14 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1807B319 for ; Mon, 15 Apr 2013 18:56:14 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by mx1.freebsd.org (Postfix) with SMTP id 24CE013A9 for ; Mon, 15 Apr 2013 18:56:12 +0000 (UTC) Received: from [98.139.215.142] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 Received: from [98.139.213.2] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 Received: from [127.0.0.1] by smtp102.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366052166; bh=w7UvLY2kbxUpjeDCeAOpS2Mt4voXIkP6UxbCCukEFFE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=NpA30B7wvZWKXKqIyKd24QAHUkcPbrIk3Xw42T+bvGOXGav6nz39pJ+i+ZwHP1xpXIy1DcgsP4FSIKzGlTyAekexMcOkh30pTiZOpjLaB3oJzV5I1AVSEY3GpTD59TuXIYlwGUq7MF4tjSk7/pov+A1TZ7fpQkZH0HoWTONa09M= X-Yahoo-Newman-Id: 463229.98655.bm@smtp102.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ewwQPWAVM1kM2PPbK8Bs92HNlKp8xz.ZqWqDaOIW5QdeI_q gH_52h3rleY_0F94nkeyyP_7l9VCKEhk0nlvleojJTLRVN4EcUr9lF9sQLnl JZXSkBBysXdnrygWVDWKEbt8lzkDB6yYu2fY_dTa4n_Y2eqbxB7w1ETCIfig kf5rWdz5TyfeaehI0VgbOcNofORHiyDHk6M77OElsQendKrTNlJAS7sftFDC qafVDlNhWq3JxbcpCovay8HeCb25LWoWmsAlb8CRdWMDrwyuYlRvCtJL4dkz ruMrsl54D5BJK7WY55bmMP.beEG5yHiXhcewd3Fzxt4cRXbEzRLmVB5__VtR Iq07YA28tzL4aKiNehnbkR.slVyJD4Bb9zmFpYP6G3elOuuZeJ4s0gbgxHv8 98o8KfdnaIXlSFjCAH1MBbVSRVIbtYNSPWyoHkc_qNeInlp03ehNUPDLjaEV nS2teePsck9tt X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with ) by smtp102.mail.bf1.yahoo.com with SMTP; 15 Apr 2013 11:56:06 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 12:56:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201304151748.r3FHmhC3002734@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 15 Apr 2013 20:36:59 +0000 Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 18:56:14 -0000 On Apr 15, 2013, at 11:48 AM, Cy Schubert = wrote: > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo=20 > writes: >> 2013/04/15 9:55=1B$B!"=1B(BCy Schubert = =1B$B$N%a%C%;!<%8=1B(B: >>=20 >>> I've been planning on taking on IP Filter for quite some time.=20 >>> Unfortunately I've left my src commit bit lapse (my ports commit bit = is=20 >>> alive and well though) thus I'm looking for a mentor. In addition = I'm=20 >>> working on an ACER WMI/ACPI kld. One mentor would be preferred but = two=20 >>> would be fine too. >>=20 >> What are your plans regarding ipfilter? I remain unconvinced that it = should b >> e in the base system. Perhaps you can work on it as a port? >=20 > The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ = hadn't=20 > done much with IPF while employed with Sun. Since then there has been = some=20 > development that is long overdue for HEAD. >=20 > I'm not sure if I'd MFC it into 9 or not. >=20 > I did consider a port but given it would has to touch bits and pieces = of=20 > the source tree (/usr/src), a port would be messy and the decision was = made=20 > to work on importing it into base. >=20 >>=20 >> Why do you want to work on something that people have been trying to = remove s >> ince 2005? >=20 > I and others have been using it in FreeBSD for over decade. For the = longest=20 > of time we'd use a common set of rules across a FreeBSD and Solaris = farm=20 > (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).=20 > Interoperability with other systems which use IP Filter is a plus. If=20= > there's a maintainer, it only makes FreeBSD richer. Losing IP Filter = would=20 > be a loss. >=20 If you're committed to maintaining IPFilter, that's great. However, it = can't be left to stagger along in a zombie state with nothing more than good = intentions from well meaning people. What is your timeline for getting it back = into shape and re-integrating yourself into the committer community? Scott= From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:15:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D147B730; Mon, 15 Apr 2013 19:15:53 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7C71569; Mon, 15 Apr 2013 19:15:53 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=MyE6jBz-AAAA:8 a=1CH5QDEJChWIyTtZLrIA:9 a=wPNLvfGTeEIA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=aLekXsIfG0IA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 13:16:19 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id CAC5E80; Mon, 15 Apr 2013 12:15:50 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJFnM1002686; Mon, 15 Apr 2013 12:15:49 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151915.r3FJFnM1002686@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Scott Long Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Scott Long of "Mon, 15 Apr 2013 12:54:12 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Apr 2013 12:15:49 -0700 X-Mailman-Approved-At: Mon, 15 Apr 2013 20:37:15 +0000 Cc: Warren Block , "current@freebsd.org" , darrenr@freebsd.org, Chris Rees , Rui Paulo , "net@freebsd.org" , "Sam Fourman Jr." , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:15:53 -0000 It was pointed out to me that Darren Reed has changed licenses from his I= P=20 Filter license that's been in IPF since 2005 or so, when he joined Sun, t= o=20 GPLv2 (probably when Darren left when Oracle took over Sun). Given that I= PF=20 already lives in src/contrib and src/sys/contrib due to the 2005 license = change, would that be a problem? If it's OK then I'll maintain it in src.= =20 If not then a port is in order. Having said that, a port would be messy a= s=20 IPF's own install scripts update src/sys/netinet, among other locations. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org In message , Scott Long= =20 writes: > The desire to remove it stems from the inability to give it adequate en= gineer > ing=20 > service as the network stack evolves. Simply taking it out of a kernel= confi > g file > doesn't address that problem at all. If it's going to stay in FreeBSD = at all > , it > needs to be maintained. This could be set about a fair amount of stuff= in Fr > eeBSD, > but IPFilter stands out since there's a high rate of needed change happ= ening=20 > in > the network stack, and it shouldn't be left to rot nor to be a stumblin= g bloc > k for > those changes. >=20 > Scott >=20 > On Apr 15, 2013, at 12:49 PM, =22Sam Fourman Jr.=22 wrote: >=20 > > Thank you to those that have expressed interest in maintaining IP Fil= ter.. > >=20 > > My thoughts are, could we consider putting a option in the kernel con= fig, > > and leaving it off by default for GENERIC? > > I think this is a acceptable compromise, considering some people wish= for > > it to be removed. > >=20 > > Sam Fourman Jr. > >=20 > >=20 > > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrot > e: > >=20 > >> In message <18DF99B0-6E66-4906-A233-7778451B8A92=40felyko.com>, Rui = Paulo > >> writes: > >>> 2013/04/15 9:55=E3=80=81Cy Schubert = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > >>>=20 > >>>> I've been planning on taking on IP Filter for quite some time. > >>>> Unfortunately I've left my src commit bit lapse (my ports commit b= it is > >>>> alive and well though) thus I'm looking for a mentor. In addition = I'm > >>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but= two > >>>> would be fine too. > >>>=20 > >>> What are your plans regarding ipfilter? I remain unconvinced that i= t > >> should b > >>> e in the base system. Perhaps you can work on it as a port? > >>=20 > >> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr=40= hadn't > >> done much with IPF while employed with Sun. Since then there has bee= n some > >> development that is long overdue for HEAD. > >>=20 > >> I'm not sure if I'd MFC it into 9 or not. > >>=20 > >> I did consider a port but given it would has to touch bits and piece= s of > >> the source tree (/usr/src), a port would be messy and the decision w= as mad > e > >> to work on importing it into base. > >>=20 > >>>=20 > >>> Why do you want to work on something that people have been trying t= o > >> remove s > >>> ince 2005? > >>=20 > >> I and others have been using it in FreeBSD for over decade. For the = longes > t > >> of time we'd use a common set of rules across a FreeBSD and Solaris = farm > >> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). > >> Interoperability with other systems which use IP Filter is a plus. I= f > >> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter= would > >> be a loss. > >>=20 > >>=20 > >> -- > >> Cheers, > >> Cy Schubert > >> FreeBSD UNIX: Web: http://www.FreeBSD.org > >>=20 > >>=20 > >> _______________________________________________ > >> freebsd-current=40freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to =22freebsd-current-unsubscribe=40fr= eebsd.org=22 > >>=20 > >=20 > >=20 > >=20 > > --=20 > >=20 > > Sam Fourman Jr. > > _______________________________________________ > > freebsd-net=40freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to =22freebsd-net-unsubscribe=40freebsd= .org=22 >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:39:21 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2E0FECF for ; Mon, 15 Apr 2013 19:39:21 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm15-vm1.bullet.mail.gq1.yahoo.com (nm15-vm1.bullet.mail.gq1.yahoo.com [98.137.176.73]) by mx1.freebsd.org (Postfix) with SMTP id C30981652 for ; Mon, 15 Apr 2013 19:39:21 +0000 (UTC) Received: from [98.137.12.59] by nm15.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 Received: from [208.71.42.192] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366054369; bh=Kk7m3nLVDM0MkNiUhi/dfXMTZv2Mi0EAIB4MzrrfzDw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=h4aw3r9Y8bYtF908foPPVPjEicfLpH5gvdA0P9nNvoY5oglKpWZl0eNEJEpfOZqmuWojOiSu0FZGPQm443E2yplS3BiehpdCrmPn6WGs8POUdgSXm9hUbpul45aQ/Ad3daObiDMwvGPP3K8JXnNfSHXutGhWkqqwMviebgarbbA= X-Yahoo-Newman-Id: 407737.54732.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MMg.9N0VM1ntHCRxlyk7F7vdB4eTuNecSUnPLzijZCHmTka 0jYwo2NdLiNDzYIcEuz.1fdpGSCCBxxshQxphmCfSinXlwnYhWH0P0qFZiXp 7rBspGhPAclGENhKw05yDOsNGK9WPCztv1UWaGo_YvGRZnufnV.nm3mZ2bIH o5eHkAvkNFXhrZXCDICIB2sGh57_ZT_m2BdSm82yy9Ba8OpWiCq.AMlX3Fp_ iCRsXOdLIy0UZDQgjeO0cu9PgyyCXuPQTT1ULvJo2yy5gEbd_yOc6x7tWm1T vs0tYlxjtP0FQI_3cPMatE4HOz1kqozzxh_yPsACiMeQMz4dwMCajoDv7w9F J4OFaDsKPAz_cYPq0qnQMCFQBhc8sXuwQ8NIX3c9lSHnHf7MxbO3uQmWJuNX A5Lo4vaC31baO_SpfultBqqXNLGf67TMHMzvtIl53Z8BdEfPq1aWgqegHnTD cCtW9klYqf0lQMpMw6TOc3swanRmAM.u2pL8QOGvemC3R7tzvxQY- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with plain) by smtp203.mail.gq1.yahoo.com with SMTP; 15 Apr 2013 12:32:49 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <201304151927.r3FJRtq9002799@slippy.cwsent.com> Date: Mon, 15 Apr 2013 13:32:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 15 Apr 2013 20:37:37 +0000 Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 19:39:22 -0000 On Apr 15, 2013, at 1:27 PM, Cy Schubert = wrote: > In message , Scott = Long=20 > writes: >>=20 >> On Apr 15, 2013, at 11:48 AM, Cy Schubert = wrote: >>=20 >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo=20 >>> writes: >>>> 2013/04/15 9:55=1B$B!"=1B(BCy Schubert = =1B$B$N%a%C%;!<%8=1B >> (B: >>>>=20 >>>>> I've been planning on taking on IP Filter for quite some time.=20 >>>>> Unfortunately I've left my src commit bit lapse (my ports commit = bit is=20 >>>>> alive and well though) thus I'm looking for a mentor. In addition = I'm=20 >>>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but = two=20 >>>>> would be fine too. >>>>=20 >>>> What are your plans regarding ipfilter? I remain unconvinced that = it shoul >> d b >>>> e in the base system. Perhaps you can work on it as a port? >>>=20 >>> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ = hadn't=20 >>> done much with IPF while employed with Sun. Since then there has = been some=20 >>> development that is long overdue for HEAD. >>>=20 >>> I'm not sure if I'd MFC it into 9 or not. >>>=20 >>> I did consider a port but given it would has to touch bits and = pieces of=20 >>> the source tree (/usr/src), a port would be messy and the decision = was made >>=20 >>> to work on importing it into base. >>>=20 >>>>=20 >>>> Why do you want to work on something that people have been trying = to remov >> e s >>>> ince 2005? >>>=20 >>> I and others have been using it in FreeBSD for over decade. For the = longest >>=20 >>> of time we'd use a common set of rules across a FreeBSD and Solaris = farm=20 >>> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).=20 >>> Interoperability with other systems which use IP Filter is a plus. = If=20 >>> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter = would=20 >>> be a loss. >>>=20 >>=20 >>=20 >> If you're committed to maintaining IPFilter, that's great. However, = it can't >> be >> left to stagger along in a zombie state with nothing more than good = intentio >> ns >> from well meaning people. What is your timeline for getting it back = into sha >> pe >> and re-integrating yourself into the committer community? >=20 > I would think this would be my top priority right now. I'd like to see = it=20 > at the latest level in HEAD. I would like to MFC to 9-STABLE at some = point. >=20 > Given that IPF already lives in src/contrib and src/sys/contrib, would = the=20 > change in License from Darren Reed's own not so BSD friendly IPF = license to=20 > GPLv2 be of concern. I recall there was a lot of concern over IPF's = license=20 > change at the time. (FreeBSD moved it to contrib while OpenBSD removed = it=20 > completely and wrote PF -- I'm not sure what NetBSD did). >=20 I would assume that the license change would be OK, especially since the = other option is to remove it (or let it continue to rot and be an eyesore) but = I'll defer to those like Gleb and Rui with a more vested interest in it. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 19:52:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C62104EA; Mon, 15 Apr 2013 19:52:46 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 323E016DE; Mon, 15 Apr 2013 19:52:46 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=BWvPGDcYAAAA:8 a=MyE6jBz-AAAA:8 a=_ctWjzdLAAAA:8 a=j8UoxrQNBuIlFuJTPtQA:9 a=CjuIK1q_8ugA:10 a=FvmvQ9K01c4A:10 a=fzi2j93kHG4A:10 a=SV7veod9ZcQA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=aLekXsIfG0IA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 13:51:37 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 2CE3880; Mon, 15 Apr 2013 12:52:44 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJqhh5003278; Mon, 15 Apr 2013 12:52:43 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151952.r3FJqhh5003278@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Jung-uk Kim Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Jung-uk Kim of "Mon, 15 Apr 2013 15:45:49 -0400." <516C58ED.40505@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 12:52:43 -0700 X-Mailman-Approved-At: Mon, 15 Apr 2013 20:37:51 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:52:46 -0000 In message <516C58ED.40505@FreeBSD.org>, Jung-uk Kim writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: > > In message , Scott > > Long writes: > >> > >> On Apr 15, 2013, at 11:48 AM, Cy Schubert > >> wrote: > >> > >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, > >>> Rui Paulo writes: > >>>> 2013/04/15 9:55$B!"(BCy Schubert > >>>> $B$N%a%C%;!<%8 > >> (B: > >>>> > >>>>> I've been planning on taking on IP Filter for quite some > >>>>> time. Unfortunately I've left my src commit bit lapse (my > >>>>> ports commit bit is alive and well though) thus I'm looking > >>>>> for a mentor. In addition I'm working on an ACER WMI/ACPI > >>>>> kld. One mentor would be preferred but two would be fine > >>>>> too. > >>>> > >>>> What are your plans regarding ipfilter? I remain unconvinced > >>>> that it shoul > >> d b > >>>> e in the base system. Perhaps you can work on it as a port? > >>> > >>> The initial plan was to import IP Filter 5.1.2 into HEAD. > >>> darrenr@ hadn't done much with IPF while employed with Sun. > >>> Since then there has been some development that is long overdue > >>> for HEAD. > >>> > >>> I'm not sure if I'd MFC it into 9 or not. > >>> > >>> I did consider a port but given it would has to touch bits and > >>> pieces of the source tree (/usr/src), a port would be messy and > >>> the decision was made > >> > >>> to work on importing it into base. > >>> > >>>> > >>>> Why do you want to work on something that people have been > >>>> trying to remov > >> e s > >>>> ince 2005? > >>> > >>> I and others have been using it in FreeBSD for over decade. For > >>> the longest > >> > >>> of time we'd use a common set of rules across a FreeBSD and > >>> Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a > >>> local CVS repo). Interoperability with other systems which use > >>> IP Filter is a plus. If there's a maintainer, it only makes > >>> FreeBSD richer. Losing IP Filter would be a loss. > >>> > >> > >> > >> If you're committed to maintaining IPFilter, that's great. > >> However, it can't be left to stagger along in a zombie state > >> with nothing more than good intentio ns from well meaning people. > >> What is your timeline for getting it back into sha pe and > >> re-integrating yourself into the committer community? > > > > I would think this would be my top priority right now. I'd like to > > see it at the latest level in HEAD. I would like to MFC to 9-STABLE > > at some point. > > > > Given that IPF already lives in src/contrib and src/sys/contrib, > > would the change in License from Darren Reed's own not so BSD > > friendly IPF license to GPLv2 be of concern. I recall there was a > > lot of concern over IPF's license change at the time. (FreeBSD > > moved it to contrib while OpenBSD removed it completely and wrote > > PF -- I'm not sure what NetBSD did). > > FYI, NetBSD has PF from OpenBSD: > > http://www.netbsd.org/docs/network/pf.html > > Also, they upgraded it to the latest GPL'ed sources recently (and > moved to a different directory): > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_wi > th_tag=MAIN > > Now they have their own packet filter, called NPF: > > http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html > > They have more choices now. :-) I'm always (or usually) one for more than fewer choices. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 21:28:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5C52547; Mon, 15 Apr 2013 21:28:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 42DFB1C09; Mon, 15 Apr 2013 21:28:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FLSRUZ002620; Tue, 16 Apr 2013 01:28:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FLSQRL002619; Tue, 16 Apr 2013 01:28:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 16 Apr 2013 01:28:26 +0400 From: Gleb Smirnoff To: cpet@sdf.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415212826.GA76816@FreeBSD.org> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 21:28:42 -0000 On Mon, Apr 15, 2013 at 04:47:33PM -0000, cpet@sdf.org wrote: c> However it would of been better if said person asked me as I already c> offered to take it on but whatever. More manpower - the better. Why can't you work together? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 21:34:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B53D84B; Mon, 15 Apr 2013 21:34:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 919EB1C55; Mon, 15 Apr 2013 21:34:33 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FLYVNp002671; Tue, 16 Apr 2013 01:34:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FLYVS7002670; Tue, 16 Apr 2013 01:34:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 16 Apr 2013 01:34:31 +0400 From: Gleb Smirnoff To: Scott Long Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415213431.GB76816@FreeBSD.org> References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 21:34:35 -0000 On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote: S> > Given that IPF already lives in src/contrib and src/sys/contrib, would the S> > change in License from Darren Reed's own not so BSD friendly IPF license to S> > GPLv2 be of concern. I recall there was a lot of concern over IPF's license S> > change at the time. (FreeBSD moved it to contrib while OpenBSD removed it S> > completely and wrote PF -- I'm not sure what NetBSD did). S> S> I would assume that the license change would be OK, especially since the other S> option is to remove it (or let it continue to rot and be an eyesore) but I'll defer to those like S> Gleb and Rui with a more vested interest in it. I'm not a licensing guru, so I can't tell whether GPL ipfilter can live in src/ and if it can, where should it be. So I expect someone else to comment on licensing. My personal, biased towards BSD, wish, is to import only the last BSD-licensed version, move it out of contrib to netpfil, remove zillions of compatibility (towards other OSes) code and just maintain it. Maintaining means fixing bugs and catching up on kernel changes. We can ask Darren whether we can switch the license to pure BSD. Since he himself switched the entire license to GPL, the insisting on the following clause seems strange, and expect he won't insist on it. > The licence and distribution terms for any publically available version or > derivative of this code cannot be changed. i.e. this code cannot simply be > copied, in part or in whole, and put under another distribution licence > [including the GNU Public Licence.] -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 22:09:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C16FCEDB for ; Mon, 15 Apr 2013 22:09:52 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7521D95 for ; Mon, 15 Apr 2013 22:09:52 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id jt11so2732197pbb.9 for ; Mon, 15 Apr 2013 15:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer; bh=BlxiZHrXOdDbI93cGR7XMMwLRpFnLp2tEUMoqdoz3ws=; b=faWNYfrwZXBCJiZs6ygtmpTsIF0qwM/98FhiCZT5TlNmtyaOAUNPtbxVt4HRWnUNO6 2qBg5TyIoLqmUDRw8FIzUl6B8t0qiwMKuKp/tmjT/cvwhWmicM9+4005SVjs/GFeIlKZ gC8L5qtUmirZ+7xyrP2bhPGgwD4RVY1GOwwpoGMktrdxrg0T8qWYgDrckIv/zyeWzZli Ga4mILDDYqdRDMUPpqNPxA3EqbzSlpWJA69Sv9gXrrf5Qlb6DGS4NP1cOlMaPuZNzSvZ oTgwW+R6BeM7zmKmKF2mQuk1NtTPAwTC35FNxJxPfw+GrLDx2Xvhh7L4Mkw+U8VFGx0u rFDg== X-Received: by 10.68.164.163 with SMTP id yr3mr19445988pbb.27.1366063792022; Mon, 15 Apr 2013 15:09:52 -0700 (PDT) Received: from [10.11.14.166] ([69.38.217.10]) by mx.google.com with ESMTPS id rt13sm23557497pac.14.2013.04.15.15.09.49 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 15 Apr 2013 15:09:50 -0700 (PDT) Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) From: Sean Bruno To: George Mitchell In-Reply-To: <516C5BE2.50005@m5p.com> References: <516C5BE2.50005@m5p.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EMR63iZyPVcnkC8mv9C3" Date: Mon, 15 Apr 2013 15:09:48 -0700 Message-ID: <1366063788.1350.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 22:09:52 -0000 --=-EMR63iZyPVcnkC8mv9C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: > that does not respond to key presses on the keyboard. It times out > and > continues loading anyway. At this stage, I am always presented with a > manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get > any further. >=20 >=20 Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? Sean --=-EMR63iZyPVcnkC8mv9C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRbHqsAAoJEBkJRdwI6BaH9W8H/3Sb7SjlDgSD4JSspqgE68/0 bfsGvCf+IOgSAqhHK3xxsPS97dhSQcdTLcPDhulNxOJwRwbbUZG2wPtI1XSUgdYE gvY8qL8jUaIYA8NWcBO3NmItH0kO1j+1qVxX1lBKcZih58moujxFrkADo40uF0vf PbRBZKErd7BqJCnymtOxksE/Ozw4qQicmwR91zpSieoQ6JDhnQhK8O07DLFl8kan sYBpbHNXtUNy8g+jwKE/wS3MZPzAFiFFHl1EeJ7+Ro+ifOeshFblZjcaB5m/fq6U hHxr4Fzq2S1Q7YoosNjJcruTUVkFk1NvypLDCMmVG6mEOR3LvrXK1CaNB6TR/Ng= =X+yl -----END PGP SIGNATURE----- --=-EMR63iZyPVcnkC8mv9C3-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 22:44:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB2162B8; Mon, 15 Apr 2013 22:44:18 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9A87D1E61; Mon, 15 Apr 2013 22:44:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1URs8F-0001Nq-Oc; Tue, 16 Apr 2013 02:44:16 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=9GtT+lAXeMMXFyFUxJs+DKLvw1RoBhsiBG3WSgO5ScA=; b=I3VpdTFTUhE0XUmPfHLqiIlAaw0+NT1qohTnSnyski+lR8S2JUbdx6pzR69Hxc7M1wVvPaoFt0b/DhICNG0OSal1+8yNXHOLXxxqC10YV+kTD5nZyLmYu3WrLwc0OnDEg3CL6GKcjmepOfAvXRhKGnzUPw2WSr0ADhDt5JXK9t4=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1URs5b-000B9U-A2; Mon, 15 Apr 2013 22:41:32 +0000 From: Jan Beich To: "O. Hartmann" Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ In-Reply-To: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> (O. Hartmann's message of "Sat, 13 Apr 2013 20:20:46 +0200") Date: Mon, 15 Apr 2013 16:42:50 -0600 References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1URs5b-000B9U-A2@internal.tormail.org> Cc: FreeBSD Current , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 22:44:18 -0000 "O. Hartmann" writes: > Trying to recompile converters/libiconv on FreeBSD 10.0-CUR/r49438 (with > bran new CLANG 3.3) results with the errors below. This error shows up > on boxes having FBSD 10 and X11. It doesn't show up on those boxes > running without a full X11 (that is the only difference I can figure out > at the moment since the different systems share a lot of configuration > stuff, having different CPU types (C2D, Sandy-Bridge, Ivy-Bridge) but > nothing I can figure out as the source of the strange behaviour and > error). [...] > converters/libiconv: > cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -I../lib -I../intl > -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -O2 -pipe -O3 > -march=native -fno-strict-aliasing -c areadlink.c > In file included from areadlink.c:27: > In file included from ./careadlinkat.h:23: > In file included from ./fcntl.h:62: > ./unistd.h:694:5: error: invalid token at start of a preprocessor > expression > #if @GNULIB_EUIDACCESS@ > ^ > 1 error generated. Maybe -O3 overoptimizes regex in libc e.g., $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' #if @GNULIB_EUIDACCESS@ $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' aaaaaaaaaaaaaaaaxxxaaaa From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 22:44:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD31844D for ; Mon, 15 Apr 2013 22:44:40 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF5D1E77 for ; Mon, 15 Apr 2013 22:44:40 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r3FMiYNL011318 for ; Mon, 15 Apr 2013 18:44:39 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <516C82D2.5040109@m5p.com> Date: Mon, 15 Apr 2013 18:44:34 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) References: <516C5BE2.50005@m5p.com> <1366063788.1350.3.camel@localhost> In-Reply-To: <1366063788.1350.3.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 15 Apr 2013 18:44:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 22:44:40 -0000 On 04/15/13 18:09, Sean Bruno wrote: > On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: >> that does not respond to key presses on the keyboard. It times out >> and >> continues loading anyway. At this stage, I am always presented with a >> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get >> any further. >> >> > > Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? > > Sean > Yes: # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1b none swap sw 0 0 /dev/ada0s1a / ufs rw 1 1 [...] From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 22:52:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81659632 for ; Mon, 15 Apr 2013 22:52:28 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5C31ED1 for ; Mon, 15 Apr 2013 22:52:27 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id p43so4172313wea.10 for ; Mon, 15 Apr 2013 15:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1MWAkEQu8WsdLFTwzixh/ldp1A2OAXMBg8t4DZ2EyT4=; b=BgqE2IReuuNklQwlmyFWl2qfafW67m3w4ohHRXqcGGYN4TxuXwN/cDQm+lqSNw6gaA 5TfD+676G3/gLyVZB0e0fnuiOwRbrFSolmzyi1dT4KnkIjUcsT/LtnbCjyo0YbJt0rCI L0ixk0BSZJXZZOYYfYWRRW+D/nv88tXS/G2YAQh7bUqidLK+ScOICB5ANPK2yDIljMJP +AUq3q1PnOLvaGGpdJ1f3Ad8zGX0hml3C5aPihzs2V7wGu4jLxoSQLM3ra8oxzcfv6nD no4eZFyIFP3VEZHI5XAl4tEmGJtPJg2lRszBawQAAcYfTVa71m1MF+c2lB4bFcnZZke2 mqLA== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr6577256wiv.27.1366066347308; Mon, 15 Apr 2013 15:52:27 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 15:52:27 -0700 (PDT) In-Reply-To: <516C82D2.5040109@m5p.com> References: <516C5BE2.50005@m5p.com> <1366063788.1350.3.camel@localhost> <516C82D2.5040109@m5p.com> Date: Tue, 16 Apr 2013 01:52:27 +0300 Message-ID: Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) From: Kimmo Paasiala To: George Mitchell Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 22:52:28 -0000 On Tue, Apr 16, 2013 at 1:44 AM, George Mitchell wrote: > On 04/15/13 18:09, Sean Bruno wrote: >> >> On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: >>> >>> that does not respond to key presses on the keyboard. It times out >>> and >>> continues loading anyway. At this stage, I am always presented with a >>> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get >>> any further. >>> >>> >> >> Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? >> >> Sean >> > Yes: > > # Device Mountpoint FStype Options Dump Pass# > /dev/ada0s1b none swap sw 0 0 > /dev/ada0s1a / ufs rw 1 1 > [...] > > > Change the order so that the root device is the first in /etc/fstab. -Kimmo From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 00:41:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDDBF1F6; Tue, 16 Apr 2013 00:41:48 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9EF207; Tue, 16 Apr 2013 00:41:48 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=3f4U5fHrZLLPCzJ96ldNbjtja1zQ0ih230F6vdsLr5s= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=oX08kPI8AAAA:8 a=BWvPGDcYAAAA:8 a=CYQVMFuZM2fOKkw8t2cA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=4wfsiePOASQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 15 Apr 2013 18:42:38 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 4236580; Mon, 15 Apr 2013 17:41:41 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3G0fdWM005771; Mon, 15 Apr 2013 17:41:39 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304160041.r3G0fdWM005771@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Gleb Smirnoff of "Tue, 16 Apr 2013 01:28:26 +0400." <20130415212826.GA76816@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 17:41:39 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , cpet@sdf.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 00:41:48 -0000 In message <20130415212826.GA76816@FreeBSD.org>, Gleb Smirnoff writes: > On Mon, Apr 15, 2013 at 04:47:33PM -0000, cpet@sdf.org wrote: > c> However it would of been better if said person asked me as I already > c> offered to take it on but whatever. Sorry, I didn't see your posting. I had a permissions issue on my gateway which caused the loss of a few emails (still sorting through the list of bounces). > > More manpower - the better. Why can't you work together? I don't mind working with others. I know there's more than enough to keep everyone busy. My main goal is to make sure IPF doesn't disappear nor go into disrepair and to make sure it's well maintained. Let's work together. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 00:50:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63CA954B for ; Tue, 16 Apr 2013 00:50:34 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 0546525F for ; Tue, 16 Apr 2013 00:50:33 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r3G0oRmT012350; Mon, 15 Apr 2013 20:50:32 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <516CA053.5080704@m5p.com> Date: Mon, 15 Apr 2013 20:50:27 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Kimmo Paasiala , freebsd-current@freebsd.org Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) References: <516C5BE2.50005@m5p.com> <1366063788.1350.3.camel@localhost> <516C82D2.5040109@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 15 Apr 2013 20:50:32 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 00:50:34 -0000 On 04/15/13 18:52, Kimmo Paasiala wrote: > On Tue, Apr 16, 2013 at 1:44 AM, George Mitchell wrote: >> On 04/15/13 18:09, Sean Bruno wrote: >>> >>> On Mon, 2013-04-15 at 15:58 -0400, George Mitchell wrote: >>>> >>>> that does not respond to key presses on the keyboard. It times out >>>> and >>>> continues loading anyway. At this stage, I am always presented with a >>>> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get >>>> any further. >>>> >>>> >>> >>> Hrm ... is /dev/ada0s1a the default root disk in your /etc/fstab ? >>> >>> Sean >>> >> Yes: >> >> # Device Mountpoint FStype Options Dump Pass# >> /dev/ada0s1b none swap sw 0 0 >> /dev/ada0s1a / ufs rw 1 1 >> [...] >> >> >> > Change the order so that the root device is the first in /etc/fstab. > > -Kimmo > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I tried that and there was no change. I still get the "mountroot:" prompt and have to type ufs:/dev/ada0s1a. -- George From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 00:57:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 914B77AD for ; Tue, 16 Apr 2013 00:57:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 65C66297 for ; Tue, 16 Apr 2013 00:57:12 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i9so2563187iad.35 for ; Mon, 15 Apr 2013 17:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=YTj1A8jJS+tjXQicGZe86WX3GEXh4RywUJZhFOtoCUM=; b=cis/iKoYXe+yKjznzgZXjdJKcsPxRhMIiCXfnv6A1zMUkw+vRxj0w/Jlj4HwU7nmO2 UNDEs+hFhzeFHAOXu4HmH4SX5nPjNGv93QfFLHPzh+F7Yp5z2Od8SakGyjxRDvmCtBEW nMc7xNZ1EU5QJ6LCdjwI1Kxi91xIpbK8k59q3l/4mCByfeaOiYGpHyqHmvjTPGWgbGb/ 0sI/ghh5MRltIruzqfyPqXs4SoPdC2bEbbltknFDMsZjCHWmD0CcMXVsuJGrUWzhQqgi Leg0f37UsWkyysBfQHRsG2ed+2ddQXF7OJEghcKBo92Xwi4YcKrbI7GdFf2/autg6BQe 6ycQ== X-Received: by 10.50.49.66 with SMTP id s2mr6461299ign.13.1366073831987; Mon, 15 Apr 2013 17:57:11 -0700 (PDT) Received: from gloom.uwaterloo.ca (cn-nat3-uw-129-97-125-50.net.uwaterloo.ca. [129.97.125.50]) by mx.google.com with ESMTPS id qs4sm14877613igb.10.2013.04.15.17.57.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 17:57:11 -0700 (PDT) Date: Mon, 15 Apr 2013 20:57:02 -0400 From: Mark Johnston To: George Mitchell Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) Message-ID: <20130416005702.GA5006@gloom.uwaterloo.ca> References: <516C5BE2.50005@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516C5BE2.50005@m5p.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 00:57:12 -0000 On Mon, Apr 15, 2013 at 03:58:26PM -0400, George Mitchell wrote: > > It was pretty successful. All my 8.3 packages are still running very > happily, though at some point I imagine I will have to update and > recompile them. > > But ... > > When I press ENTER in the boot0 screen, I get the hyphen that will start > spinning after a timeout and begin loading boot1 (which, as far as I > know, I have not updated). boot1 (I think) presents me with a prompt > that does not respond to key presses on the keyboard. It times out and > continues loading anyway. At this stage, I am always presented with a > manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get > any further. I ran into this too. It was caused by a problem in r249408 and is fixed as of r249436. Updating your kernel to something beyond r249435 should make this go away. -Mark From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 01:01:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11AB48D9 for ; Tue, 16 Apr 2013 01:01:14 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id DA51D2BF for ; Tue, 16 Apr 2013 01:01:13 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id e16so4912466iaa.34 for ; Mon, 15 Apr 2013 18:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OIPF/LuIK2UBAoGMjgtsuo8vY4b7gKCwott2Jbvo9k0=; b=0HntuRsmKnv7jcZhMTspm3yKQSVMqpDskFIxpbheCj9OSzwLt0fdkRJS5NfGNFReBy loJypO9dF6m0bOIheTP8b+9WOVwhI+UJ75tH6QIIZ3XGXLd5t9JCo6QT/jKpouEw8nMA mckNTizYcsmYxEZW6VVVlPePpAdBE2Q6ofiNPOb+5qKbJTan7XQPkmTmaWdVgsZxNyyf wl96/2zQ+BwcGZMqTh+QKIj/wFsifd92GlnNerscnmtjuCm/xXhdpVf87rK133OI2MKf 9pax8PviCUCItO2C5jaBPBr28lRtdID9eLRWD5Hke5U0fbftA9L/8KQ6Fkgwamcezwb6 I3cA== X-Received: by 10.50.180.197 with SMTP id dq5mr6477305igc.22.1366074073598; Mon, 15 Apr 2013 18:01:13 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id qn10sm13494773igc.6.2013.04.15.18.01.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 18:01:13 -0700 (PDT) Message-ID: <516CA2D4.9020503@gmail.com> Date: Mon, 15 Apr 2013 20:01:08 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) References: <516C5BE2.50005@m5p.com> <1366063788.1350.3.camel@localhost> <516C82D2.5040109@m5p.com> <516CA053.5080704@m5p.com> In-Reply-To: <516CA053.5080704@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 01:01:14 -0000 On 4/15/2013 7:50 PM, George Mitchell wrote: > > I tried that and there was no change. I still get the "mountroot:" > prompt and have to type ufs:/dev/ada0s1a. -- George > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" What if you change it to ad0 instead of ada0? I wonder if the legacy aliases isn't being set properly, or something related to that. From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 01:48:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BFC35E2D for ; Tue, 16 Apr 2013 01:48:26 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9244D5E9 for ; Tue, 16 Apr 2013 01:48:26 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id h1so5077830oag.3 for ; Mon, 15 Apr 2013 18:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=OO1mAR8x01SjHJrKGl08W9LDZF3TXLdDu62xW3Forww=; b=xhc8kkgFAUX9RdS+T2/g8k9Sq4g7sId2DxXP/lpWJEX8DOUWzunZcIa1Ukm6IGZ0HD KWRWwXS8VSOz+E5q1CGZ0RfsiorELBhjvBjo6h99L4vRjGpaJ1d4DkoIReihX8fFc6uo 6vGghpJkwPg+djnzDVFzYtE5pcnApNag1qiKOe7g7cESFdEAV+/qoZPrgMIoarbXnJoE mdrBOKtJNVtp8SAggPh9NgPWR992Z/gQzMu3yb6FEbelYmJyg4lioCLwOHfB5+gKmj7V 4dvBjApyxbaAM+OKz7ep5gpjohghNK2DD+MYd8loSzGepW3JCCflyu6EBp/m16dVA/za VveQ== MIME-Version: 1.0 X-Received: by 10.60.92.201 with SMTP id co9mr69393oeb.113.1366076900520; Mon, 15 Apr 2013 18:48:20 -0700 (PDT) Received: by 10.76.135.194 with HTTP; Mon, 15 Apr 2013 18:48:20 -0700 (PDT) Date: Mon, 15 Apr 2013 21:48:20 -0400 Message-ID: Subject: Last commit to HEAD From: Outback Dingo To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 01:48:26 -0000 Okay I must be loosing it since the change over to svn, and loosing cvsup where can i find the last commit to HEAD ? and is it correct to use svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs making the last commit rev 249529 and as for 9.x i thought releng was what brought updates to the 9 tree so why stable look like theres more current work, or is that going to become the life of 9.2 .... trying to refresh my memory here! From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 02:17:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D55421D1 for ; Tue, 16 Apr 2013 02:17:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 953416AE for ; Tue, 16 Apr 2013 02:17:04 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r3G2H4Ch011192; Mon, 15 Apr 2013 19:17:04 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r3G2H4AW011191; Mon, 15 Apr 2013 19:17:04 -0700 (PDT) (envelope-from david) Date: Mon, 15 Apr 2013 19:17:04 -0700 From: David Wolfskill To: Outback Dingo Subject: Re: Last commit to HEAD Message-ID: <20130416021704.GK1404@albert.catwhisker.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DesjdUuHQDwS2t4N" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 02:17:05 -0000 --DesjdUuHQDwS2t4N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 09:48:20PM -0400, Outback Dingo wrote: > Okay I must be loosing it since the change over to svn, and loosing cvsup >=20 > where can i find the last commit to HEAD ? A couple of Web-oriented sources of information: * , which (as of this writing) refers to "Apr 15 Andrey V. Elsukov svn commit: r249528 - head/sys/netinet6". * , which (again, as of this writing) mentions "Directory revision: 249528 (of 249529)". > and is it correct to use >=20 > svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs Mostly, though we now have some official mirrors, as well; you might want to consider using one of those. And per , https is recommended for "anonymous checkout", e.g.: "svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src" > making the last commit rev 249529 As of this writing, that was the last commit to the src repository. However, that commit was to the "user" part of the repo, not to head. (Ref. .) > and as for 9.x i thought releng was what brought updates to the 9 tree releng/* is equivalent to the old RELENG_* CVS branches -- that is, RELEASE_* + patches/commits to address security advisories. This is *not* what you want for "new features" (such as support for a device that wasn't supported in RELEASE). > so why stable look like theres more current work, or is that going to > become > the life of 9.2 .... That's exactly the same as it was under CVS: "stable/*" is a development branch, and that *does* get "new features" (ideally, all MFCed from head), and (as of this writing) stable/9 is where code is committed that will eventually become release/9.2.0, then releng/9.2. > trying to refresh my memory here! I hope that helps a bit. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --DesjdUuHQDwS2t4N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFstJ8ACgkQmprOCmdXAD1hXACeMMxCDXoHFoixyoBW0m3Hi6x2 qhsAn1PZoAIud9qET+3zlvzdlTGVyPrE =G/Pz -----END PGP SIGNATURE----- --DesjdUuHQDwS2t4N-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 02:28:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DBD8C3C4 for ; Tue, 16 Apr 2013 02:28:50 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx1.freebsd.org (Postfix) with ESMTP id AA700753 for ; Tue, 16 Apr 2013 02:28:50 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id n9so20835oag.20 for ; Mon, 15 Apr 2013 19:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A9fy5cb9kSwwSF8Ouex1EtbvhhKq2wK7QQX5eyrxtUg=; b=Lb7IOupTnUOFFyE6gQEWBy2eY+DBeYohqyZCVKNKr4+YRhWAe7SxuLHMS/fuMFQuYl oP4vfbrJYAQP2lzFG6yK6JQMLNI7iNDXwMoXBQZTDkymkGVcsrBxb7fyZ9CD6HHM6NYu XbrL6uge9gKYRF/vg7HJqTd+2vwK4PZk4cEYXks3hpKpgbPDN171PTFgz9SSnKN46YkR ZKgRZQ+PrRaoCMnUZe3ALBz0MJEKTifPzWq/M2f+39nbD7oG7fwtUehJ+8cWQumUIZPW /jlqpx3/VCZPmMm/oy9Z61b3vUKIScrYiEXUWEtOnXuJQwa4h4ypPtJbUOf1hIvNER7f EyFA== MIME-Version: 1.0 X-Received: by 10.60.135.103 with SMTP id pr7mr95640oeb.142.1366079329626; Mon, 15 Apr 2013 19:28:49 -0700 (PDT) Received: by 10.76.135.194 with HTTP; Mon, 15 Apr 2013 19:28:49 -0700 (PDT) In-Reply-To: <20130416021704.GK1404@albert.catwhisker.org> References: <20130416021704.GK1404@albert.catwhisker.org> Date: Mon, 15 Apr 2013 22:28:49 -0400 Message-ID: Subject: Re: Last commit to HEAD From: Outback Dingo To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 02:28:50 -0000 On Mon, Apr 15, 2013 at 10:17 PM, David Wolfskill wrote: > On Mon, Apr 15, 2013 at 09:48:20PM -0400, Outback Dingo wrote: > > Okay I must be loosing it since the change over to svn, and loosing cvsup > > > > where can i find the last commit to HEAD ? > > A couple of Web-oriented sources of information: > > * , which (as of > this writing) refers to "Apr 15 Andrey V. Elsukov svn commit: > r249528 - head/sys/netinet6". > > * , which (again, as of this > writing) mentions "Directory revision: 249528 (of 249529)". > > > and is it correct to use > > > > svn co http://svn.freebsd.org/base/head/ for 10.0-CURRENT srcs > > Mostly, though we now have some official mirrors, as well; you might want > to consider using one of those. And per > < > http://www.freebsd.org/doc/en/articles/committers-guide/article.html#subversion-primer > >, > https is recommended for "anonymous checkout", e.g.: > "svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src" > > > making the last commit rev 249529 > > As of this writing, that was the last commit to the src repository. > However, that commit was to the "user" part of the repo, not to head. > (Ref. .) > > > and as for 9.x i thought releng was what brought updates to the 9 tree > > releng/* is equivalent to the old RELENG_* CVS branches -- that is, > RELEASE_* + patches/commits to address security advisories. > > This is *not* what you want for "new features" (such as support for a > device that wasn't supported in RELEASE). > > > so why stable look like theres more current work, or is that going to > > become > > the life of 9.2 .... > > That's exactly the same as it was under CVS: "stable/*" is a development > branch, and that *does* get "new features" (ideally, all MFCed from > head), and (as of this writing) stable/9 is where code is committed that > will eventually become release/9.2.0, then releng/9.2. > > > trying to refresh my memory here! > > I hope that helps a bit. > > Peace, > david > Yupp Thanks for the refresher, im good now! > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 03:05:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96C66814; Tue, 16 Apr 2013 03:05:27 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by mx1.freebsd.org (Postfix) with ESMTP id 6F41C91C; Tue, 16 Apr 2013 03:05:27 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id rr4so31553pbb.10 for ; Mon, 15 Apr 2013 20:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Vr3C2Hxlv9TNfIBnLav/ssqz8Go3sVoLNBBJ+LVk3sY=; b=GmQBy4e9B2HGDqFyvBZnL0ya5tfd8e5RjUxobMa8cbdWn/+r5AXOeLlT/c8y4cv142 r70uJH+PXNRaKX5BHAg6rCd9HWBiAYBBgA3EtI/vvI1sF8WsftPCzv05nknsDs/SAlOU R9j4FVnMJSDWQeBBHM5bGbycxDOJtD+1TSSHgfYu4N5hPQXnjceOj/I0ORf/LRTP3ANW R5kiO72tfjkZUgsRq6Y+4KHKJaQd/mwkxqGUmUlBxvIGNmlduKh8EU7G9s0LCqkp3/7j 8lBm8r8ERyNXxhSCM74ZvYfdpf3dP4JcYDPfj+ak1kwfy8e/YKAJqkIy4ZvALCeQF+V0 icmA== X-Received: by 10.66.11.7 with SMTP id m7mr1121302pab.68.1366081526744; Mon, 15 Apr 2013 20:05:26 -0700 (PDT) Received: from localhost (c-67-160-248-74.hsd1.ca.comcast.net. [67.160.248.74]) by mx.google.com with ESMTPS id ra9sm595509pab.16.2013.04.15.20.05.25 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 20:05:25 -0700 (PDT) Sender: Gleb Kurtsou Date: Mon, 15 Apr 2013 20:05:30 -0700 From: Gleb Kurtsou To: Pawel Jakub Dawidek Subject: Re: r248583 Kernel panic: negative refcount 0xfffffe0031b59168 Message-ID: <20130416030530.GA1274@reks> References: <20130414044314.GA1115@reks> <20130415083517.GB1410@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130415083517.GB1410@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-current , Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 03:05:27 -0000 On (15/04/2013 10:35), Pawel Jakub Dawidek wrote: > On Sat, Apr 13, 2013 at 09:43:14PM -0700, Gleb Kurtsou wrote: > > On (22/03/2013 11:51), Shawn Webb wrote: > > > Hey All, > > > > > > I'm not sure if this is a result of r248583 or a different commit, but I > > > hit a kernel panic when closing Chrome. I've linked to the info and > > > core.txt files below. If you need me to ship you the vmcore file, let me > > > know. It's 1.1GB in size. > > > > > > Other than the pasted files, I'm not too sure where to go from here. If > > > there's any other info you need, please let me know. I'm a newb at > > > submitting this kind of stuff. > > > > > > Paste of info file: http://ix.io/4Qo > > > Paste of core.txt file: http://ix.io/4Qp > > > > Shawn, did you find workaround for the problem? > > > > I've just upgraded to recent HEAD and see the same panic on closing > > chrome. Switching back to r247601 just before "Merge Capsicum overhaul" > > commit makes panic disappear. > > I did receive Shawn's report some time ago, I even installed Chromium to > try to reproduce it, but it didn't crash for me yet. I could send you chrome binary I'm using. It's a outdated chromium-22.0.1229.92. > If there are some easy, but reliable steps to reproduce it, like "open > this webpage in tab 1, then this webpage in tab 2, then close tab 1" > that would be great. This kernel coredump is not really useful, as we > this is legitimate case of decrementing reference counter. The problem > is that something decremented it earlier when it shouldn't or it wasn't > incremented somewhere. DTrace might be useful tool here if we could > instrument it to log backtrace of all increments and decrements done by > the Chromium processes. I'll try to reproduce it in vm.. which is not that easy because virtualbox kmod needs patching to work on month old CURRENT and there is no binary packages to install vm in the first place. From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 09:13:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD8A736E for ; Tue, 16 Apr 2013 09:13:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 36201D84 for ; Tue, 16 Apr 2013 09:13:17 +0000 (UTC) Received: (qmail 17057 invoked from network); 16 Apr 2013 10:19:25 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Apr 2013 10:19:25 -0000 Message-ID: <516D161E.9010701@freebsd.org> Date: Tue, 16 Apr 2013 11:13:02 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer References: <201304151748.r3FHmhC3002734@slippy.cwsent.com> In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 09:13:18 -0000 On 15.04.2013 19:48, Cy Schubert wrote: > I did consider a port but given it would has to touch bits and pieces of > the source tree (/usr/src), a port would be messy and the decision was made > to work on importing it into base. Actually it shouldn't touch many if any pieces of src/sys. Everything should happen via sorta published API's the other firewall packages use as well. Most important pfil hooks. The hardest part probably is to get the locking right. Please run changes to src/sys/net* through glebius@ and me (andre@) first before committing. In most, if not all cases, it is possible to find a generic way of doing things or to standardize on a common one for all of our packet filters. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 11:16:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93A13C85 for ; Tue, 16 Apr 2013 11:16:39 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 54940276 for ; Tue, 16 Apr 2013 11:16:39 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r3GBGWSl017526; Tue, 16 Apr 2013 07:16:37 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <516D3310.50808@m5p.com> Date: Tue, 16 Apr 2013 07:16:32 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Johnston Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) References: <516C5BE2.50005@m5p.com> <20130416005702.GA5006@gloom.uwaterloo.ca> In-Reply-To: <20130416005702.GA5006@gloom.uwaterloo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 16 Apr 2013 07:16:38 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 11:16:39 -0000 On 04/15/13 20:57, Mark Johnston wrote: > On Mon, Apr 15, 2013 at 03:58:26PM -0400, George Mitchell wrote: >> >> It was pretty successful. All my 8.3 packages are still running very >> happily, though at some point I imagine I will have to update and >> recompile them. >> >> But ... >> >> When I press ENTER in the boot0 screen, I get the hyphen that will start >> spinning after a timeout and begin loading boot1 (which, as far as I >> know, I have not updated). boot1 (I think) presents me with a prompt >> that does not respond to key presses on the keyboard. It times out and >> continues loading anyway. At this stage, I am always presented with a >> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get >> any further. > > I ran into this too. It was caused by a problem in r249408 and is fixed > as of r249436. Updating your kernel to something beyond r249435 should > make this go away. > > -Mark > Thanks! I have a compile going and I'll check the result later today. -- George From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 06:43:29 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09BD5824; Tue, 16 Apr 2013 06:43:29 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from tux-cave.hellug.gr (tux-cave.hellug.gr [195.134.99.74]) by mx1.freebsd.org (Postfix) with ESMTP id 687CEFB9; Tue, 16 Apr 2013 06:43:27 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: r3G6hCUj022455 Received: from saturn.laptop (217-162-217-29.dynamic.hispeed.ch [217.162.217.29]) (authenticated bits=0) by tux-cave.hellug.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id r3G6hCUj022455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 09:43:19 +0300 Received: from saturn.laptop (localhost [127.0.0.1]) by saturn.laptop (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r3G6h6qr025909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 08:43:06 +0200 Received: (from keramida@localhost) by saturn.laptop (8.14.4/8.14.4/Submit) id r3G6h3nY025896; Tue, 16 Apr 2013 08:43:03 +0200 X-Authentication-Warning: saturn.laptop: keramida set sender to keramida@ceid.upatras.gr using -f From: keramida@ceid.upatras.gr (Giorgos Keramidas) To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <201304151915.r3FJFnM1002686@slippy.cwsent.com> (Cy Schubert's message of "Mon, 15 Apr 2013 12:15:49 -0700") Date: Tue, 16 Apr 2013 07:58:48 +0200 Message-ID: <87sj2rc8yv.fsf@saturn.laptop> References: <201304151915.r3FJFnM1002686@slippy.cwsent.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 16 Apr 2013 11:20:28 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "Sam Fourman Jr." , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 06:43:29 -0000 On Mon, 15 Apr 2013 12:15:49 -0700, Cy Schubert wrote: > It was pointed out to me that Darren Reed has changed licenses from > his IP Filter license that's been in IPF since 2005 or so, when he > joined Sun, to GPLv2 (probably when Darren left when Oracle took over > Sun). Given that IPF already lives in src/contrib and src/sys/contrib > due to the 2005 license change, would that be a problem? If it's OK > then I'll maintain it in src. If not then a port is in order. Having > said that, a port would be messy as IPF's own install scripts update > src/sys/netinet, among other locations. That would be a big 'no', right there. Ports should never update kernel headers. If not for any other reason, because "which kernel?". I regularly keep 2-3 different source trees of the kernel around, and build them from non-standard locations. Having to remember to run ipfilter_hack.sh on each of them before doing a successful build and ending up with kernel sources which are always 'unclean svn checkouts' would suck -- and I suspect I'm not the only one doing builds of kernels outside of /usr/src. From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 13:24:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E20BFE2; Tue, 16 Apr 2013 13:24:02 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id A3DCCA65; Tue, 16 Apr 2013 13:24:02 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id er7so421632obc.2 for ; Tue, 16 Apr 2013 06:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=+g1bMpfaZYg7yDy1FQz5II7n3IBOQb2II20dvVo4/Io=; b=IeOPqHCiRj4qgkmSQWelAH0MaRbi8j/X88zmigAODRQtgklyhIdppOTm2/Y5iR+RVq tVjxvMgDGh3WiXOiXLmrPLNTCv72MXbEcKnCAIM4ILqJURd6IvvGd5qqHNkQ6ZpegqeF rPZo/VmIrSUqDtw8LwRDMyYYGyyitbBJT3pSclN6Wwc0QrYGlj0vqY7PSAZeM4okyFfd 1NekW3Q9mZK6/pzKzShGN2HLO0H1qHiv+boiZwCvIXQVQR0prjDAfftHFyo68cf0C0eJ aYYb/maIu40PXI2+jotRS5W2OvvUyIpK9mpa95W6Ki5IsS7+6z6aLYGbs7Oq9Invdd5/ DVyw== MIME-Version: 1.0 X-Received: by 10.182.231.197 with SMTP id ti5mr803969obc.64.1366118642239; Tue, 16 Apr 2013 06:24:02 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Tue, 16 Apr 2013 06:24:02 -0700 (PDT) Date: Tue, 16 Apr 2013 15:24:02 +0200 Message-ID: Subject: swapcontext rewrite broke some software From: Oliver Pinter To: davidxu Content-Type: text/plain; charset=ISO-8859-1 Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 13:24:02 -0000 Hi! After this commit: commit ac0cfc7fcb1b51ee6aeacfd676fa6dfbe11eefb5 Author: davidxu Date: Wed Apr 10 02:40:03 2013 +0000 swapcontext wrapper can not be implemented in C, the stack pointer saved in the context becomes invalid when the function returns, same as setjmp, it must be implemented in assemble language, see discussions in PR misc/177624. Some* software not found the swapcontext functions after this commit. Please add a sentence to UPDATING file and/or bump the __FreeBSD_version to reflect this change. * qemu From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 13:57:41 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30D79DC8; Tue, 16 Apr 2013 13:57:41 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 98179D9C; Tue, 16 Apr 2013 13:57:34 +0000 (UTC) Received: from cpsps-ews11.kpnxchange.com ([10.94.84.178]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 16 Apr 2013 15:56:23 +0200 Received: from CPSMTPM-CMT101.kpnxchange.com ([195.121.3.17]) by cpsps-ews11.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 16 Apr 2013 15:56:23 +0200 Received: from sun.offermans.rompen.nl ([77.170.60.162]) by CPSMTPM-CMT101.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Tue, 16 Apr 2013 15:56:22 +0200 Received: from squid (squid.vpn.offrom.nl [10.168.0.72]) by sun.offermans.rompen.nl (8.14.5/8.14.4) with ESMTP id r3GDuMPg025682; Tue, 16 Apr 2013 15:56:22 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid with local (Exim 4.72) (envelope-from ) id 1US6Mv-0007Bb-N6; Tue, 16 Apr 2013 15:56:21 +0200 Date: Tue, 16 Apr 2013 15:56:21 +0200 From: Willy Offermans To: freebsd-hardware@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: control of order of inet devices Message-ID: <20130416135621.GE3286@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 16 Apr 2013 13:56:22.0655 (UTC) FILETIME=[2DBD38F0:01CE3AAA] X-RcptDomain: FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 13:57:41 -0000 Dear FreeBSD friends, How can I control the order of the network devices in FreeBSD. For example, the command ifconfig lists the network devices: pcn0: flags=8802 metric 0 mtu 1500 options=80000 ether 00:0c:46:ea:2b:32 nd6 options=29 media: Ethernet 100baseFX status: no carrier rl0: flags=8843 metric 0 mtu 1500 options=2008 ether 00:11:6b:99:7c:5a inet XXX.XXX.24.4 netmask 0xffffff80 broadcast 137.226.24.127 inet6 fe80::211:6bff:fe99:7c5a%rl0 prefixlen 64 scopeid 0x4 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active nfe0: flags=8802 metric 0 mtu 1500 options=82008 ether 00:1b:fc:df:a1:33 nd6 options=29 media: Ethernet autoselect (none) status: no carrier plip0: flags=8810 metric 0 mtu 1500 nd6 options=29 lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:22:19:10:8d:bb inet XXX.XXX.24.19 netmask 0xffffffff broadcast 137.226.24.19 inet6 fe80::2bd:83ff:fe68:7200%tap0 prefixlen 64 scopeid 0x8 nd6 options=21 media: Ethernet autoselect status: no carrier pcn0 being first. However, I would like tap0 being first and of course without any output ordering trick. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 15:00:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7925FA7F for ; Tue, 16 Apr 2013 15:00:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E5BB2FDA for ; Tue, 16 Apr 2013 14:59:59 +0000 (UTC) Received: (qmail 23539 invoked from network); 16 Apr 2013 16:06:10 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Apr 2013 16:06:10 -0000 Message-ID: <516D676D.6020706@freebsd.org> Date: Tue, 16 Apr 2013 16:59:57 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Julian Elischer Subject: Re: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 References: <51667FDC.7050807@freebsd.org> <516B74BC.3070903@freebsd.org> In-Reply-To: <516B74BC.3070903@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 15:00:00 -0000 On 15.04.2013 05:32, Julian Elischer wrote: > On 4/11/13 5:18 PM, Andre Oppermann wrote: >> Excuse me for being slightly spammy but I've received feedback that we >> haven't spread this information widely enough outside the inner circles >> and interested people missed the announcement. >> >> EuroBSDcon 2013: September 28-29 in Malta >> ========================================= >> >> EuroBSDcon is the European technical conference for users and developers >> of BSD-based systems. The conference will take place Saturday and Sunday >> 28-29 September at the Hilton Conference Centre in St. Julian's, Malta >> (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, >> talks on Saturday and Sunday). [Yes, very nice weather at that time of >> year, about 26/19C sunny no rain, Social event on Saturday evening is going >> to be a sunset beach BBQ] > > The web page suggest I bring my wife AND my spouse.. what if they don't > know about each other? Well, you have poorly managed your relationships then. ;) This web page is a place holder and will be updated with the all important details on venue/travel/hotels/schedule really soon now. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 15:44:20 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DDF59EC0; Tue, 16 Apr 2013 15:44:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8767126E; Tue, 16 Apr 2013 15:44:19 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3GFiNL6014246; Tue, 16 Apr 2013 10:44:24 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3GFiNaa014245; Tue, 16 Apr 2013 10:44:23 -0500 (CDT) (envelope-from brooks) Date: Tue, 16 Apr 2013 10:44:23 -0500 From: Brooks Davis To: Willy Offermans Subject: Re: control of order of inet devices Message-ID: <20130416154423.GD98205@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJcv+A0YCCLh2VIg" Content-Disposition: inline In-Reply-To: <20130416135621.GE3286@vpn.offrom.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 15:44:20 -0000 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2013 at 03:56:21PM +0200, Willy Offermans wrote: > Dear FreeBSD friends, >=20 > How can I control the order of the network devices in FreeBSD. >=20 > For example, the command ifconfig lists the network devices: >=20 > pcn0: flags=3D8802 metric 0 mtu 1500 > options=3D80000 > ether 00:0c:46:ea:2b:32 > nd6 options=3D29 > media: Ethernet 100baseFX > status: no carrier > rl0: flags=3D8843 metric 0 mtu 15= 00 > options=3D2008 > ether 00:11:6b:99:7c:5a > inet XXX.XXX.24.4 netmask 0xffffff80 broadcast 137.226.24.127 > inet6 fe80::211:6bff:fe99:7c5a%rl0 prefixlen 64 scopeid 0x4=20 > nd6 options=3D29 > media: Ethernet autoselect (100baseTX ) > status: active > nfe0: flags=3D8802 metric 0 mtu 1500 > options=3D82008 > ether 00:1b:fc:df:a1:33 > nd6 options=3D29 > media: Ethernet autoselect (none) > status: no carrier > plip0: flags=3D8810 metric 0 mtu 1500 > nd6 options=3D29 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7=20 > inet 127.0.0.1 netmask 0xff000000=20 > nd6 options=3D21 > tap0: flags=3D8843 metric 0 mtu 1= 500 > options=3D80000 > ether 00:22:19:10:8d:bb > inet XXX.XXX.24.19 netmask 0xffffffff broadcast 137.226.24.19 > inet6 fe80::2bd:83ff:fe68:7200%tap0 prefixlen 64 scopeid 0x8=20 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier >=20 > pcn0 being first. However, I would like tap0 being first and of course > without any output ordering trick. The order is dictated by the order the drivers are probed by the kernel. When the devices are created they are added to a linked list. There is no practical way to control the order and it has little or no effect. -- Brooks --ZJcv+A0YCCLh2VIg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRbXHWXY6L6fI4GtQRAnu9AKCAx1z0Ns3LdGZb+OEthXHUXoubAQCgr0YG ba2xOdoX8hi1TH33bqevAFE= =vPsr -----END PGP SIGNATURE----- --ZJcv+A0YCCLh2VIg-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 16:08:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C5B59ED for ; Tue, 16 Apr 2013 16:08:40 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1AFF55E0 for ; Tue, 16 Apr 2013 16:08:39 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D855E25D3A00 for ; Tue, 16 Apr 2013 16:08:32 +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 147E5BE85D1 for ; Tue, 16 Apr 2013 16:08:32 +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 usO5PHgjQOfK for ; Tue, 16 Apr 2013 16:08:30 +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 AE0ACBE85C8 for ; Tue, 16 Apr 2013 16:08:30 +0000 (UTC) Date: Tue, 16 Apr 2013 16:08:29 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-current@freebsd.org Subject: My incremental buildworlds started failing Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 16:08:40 -0000 Hi, I have been seeing this on incremental buildworlds for a day or two now? ANyone can throw the cluebat at me? ===> rescue/rescue/routed/rtquery (depend) {standard input}: Assembler messages: {standard input}:2: Warning: unterminated string; newline inserted {standard input}:3: Warning: unterminated string; newline inserted ===> kerberos5/usr.bin/kcc (all) In file included from /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c:51: /storage/head/obj//sparc64.sparc64/scratch/tmp/bz/head.svn/tmp/usr/include/netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (not in a function) *** [rtsol.o] Error code 1 1 error *** [rtsol_make] Error code 2 1 error ===> kerberos5/usr.sbin/ktutil (all) ===> rescue (all) ===> rescue/librescue (all) ===> rescue/rescue (all) Run "/storage/head/obj//scratch/tmp/bz/head.svn/make.amd64/make -f rescue.mk" to build crunched binary. ===> rescue/rescue/routed/rtquery (depend) {standard input}: Assembler messages: {standard input}:2: Warning: unterminated string; newline inserted {standard input}:3: Warning: unterminated string; newline inserted In file included from /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c:51: /storage/head/obj//arm.armeb/scratch/tmp/bz/head.svn/tmp/usr/include/netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (not in a function) *** [rtsol.o] Error code 1 1 error *** [rtsol_make] Error code 2 1 error *** [objs] Error code 2 1 error *** [all] Error code 2 1 error *** [rescue.all__D] Error code 2 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error -- Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 16:39:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7457F6C for ; Tue, 16 Apr 2013 16:39:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2137E8 for ; Tue, 16 Apr 2013 16:39:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b037:d3c5:d0df:2e6b] (unknown [IPv6:2001:7b8:3a7:0:b037:d3c5:d0df:2e6b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D41FF5C44; Tue, 16 Apr 2013 18:39:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: My incremental buildworlds started failing From: Dimitry Andric In-Reply-To: Date: Tue, 16 Apr 2013 18:39:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> References: To: Bjoern A. Zeeb X-Mailer: Apple Mail (2.1503) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 16:39:14 -0000 On Apr 16, 2013, at 18:08, Bjoern A. Zeeb = wrote: > I have been seeing this on incremental buildworlds for a day or two = now? ANyone can throw the cluebat at me? >=20 > =3D=3D=3D> rescue/rescue/routed/rtquery (depend) > {standard input}: Assembler messages: > {standard input}:2: Warning: unterminated string; newline inserted > {standard input}:3: Warning: unterminated string; newline inserted > =3D=3D=3D> kerberos5/usr.bin/kcc (all) > In file included from = /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c:51: > = /storage/head/obj//sparc64.sparc64/scratch/tmp/bz/head.svn/tmp/usr/include= /netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (not in = a function) > *** [rtsol.o] Error code 1 > 1 error > *** [rtsol_make] Error code 2 > 1 error Probably http://svnweb.freebsd.org/changeset/base/249543 From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 17:08:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 006DB6AC; Tue, 16 Apr 2013 17:08:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 4E20A952; Tue, 16 Apr 2013 17:08:01 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id l13so154924wie.3 for ; Tue, 16 Apr 2013 10:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=o6mYr4omhYanS6EhxL4GeiP9cOrlM4fyYQNUejFl46k=; b=qIZODIbRn81DPtrLbHUYEXGqy46fCr/ODex1Ug0zryP7By1qKUlI/V8ZbCbOwjuIdy SA1wgbgdmhUNXcIx+NSrAwzdBB1ndMbUJGv9sn+FKcybav6gy7WhlabKe/FPNTt5D7Ua o8CNaNhWWVoMvGQbbMOoUETipFjdxtfYFp7d+IEb/xQsyDQGo9eW+nhByHQl+9rhYL1s o2BdBASPmgu+ct79L2lbrCKFy2785DKX8H3Df7+uSmTXVdGp2fdvXpPcvQcltjJ2K7qD 9Z5Y8bvBdE3v68gQRJ1OW9j2VEl1WBYIeQBltivsXs6b3SjcUgFoMX7jFBPG2B5M+Wkx yElA== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr5325477wiv.27.1366132080448; Tue, 16 Apr 2013 10:08:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.88.129 with HTTP; Tue, 16 Apr 2013 10:08:00 -0700 (PDT) In-Reply-To: <20130416154423.GD98205@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> Date: Tue, 16 Apr 2013 10:08:00 -0700 X-Google-Sender-Auth: YqQwRzw8aKlSYfyNIx9mbO0IPSE Message-ID: Subject: Re: control of order of inet devices From: Adrian Chadd To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: Willy Offermans , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 17:08:02 -0000 Since people keep asking about this; maybe it's time we added a hint to the bus code that allows for the unit to be set based on the pci bus / slot / etc. Adrian From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 17:08:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E4B96B0; Tue, 16 Apr 2013 17:08:16 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id B56E9954; Tue, 16 Apr 2013 17:08:15 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUGACmEbVFR8ZLu/2dsb2JhbABQgwY2wQaBCBd0gh8BAQUnLyIBEAsOCgkWDwkDAgECASceBg0BBwEBiBQIrE2QT41jgSwHg0IDj1SBKYcrj3GDDTqBLw Received: from 238.146-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.146.238]) by relay.skynet.be with ESMTP; 16 Apr 2013 19:07:04 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.6/8.14.6) with ESMTP id r3GH73ZP075672; Tue, 16 Apr 2013 19:07:03 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <516D8531.1090006@coosemans.org> Date: Tue, 16 Apr 2013 19:06:57 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130408 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: My incremental buildworlds started failing References: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> In-Reply-To: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2BODLLRLDLPCSARUXHUFJ" Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 17:08:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BODLLRLDLPCSARUXHUFJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-04-16 18:39, Dimitry Andric wrote: > On Apr 16, 2013, at 18:08, Bjoern A. Zeeb wrote: >> I have been seeing this on incremental buildworlds for a day or two no= w? >> ANyone can throw the cluebat at me? If that means building with NO_CLEAN=3Dyes then the problem is r249484. It creates a symlink: ln -fs ../include ${DESTDIR}/usr/lib/include But if ${DESTDIR}/usr/lib/include already exists it creates ${DESTDIR}/usr/include/include -> ../include. I'm thinking of reverting that commit. >> =3D=3D=3D> rescue/rescue/routed/rtquery (depend) >> {standard input}: Assembler messages: >> {standard input}:2: Warning: unterminated string; newline inserted >> {standard input}:3: Warning: unterminated string; newline inserted >> =3D=3D=3D> kerberos5/usr.bin/kcc (all) >> In file included from /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.sb= in/rtsold/rtsol.c:51: >> /storage/head/obj//sparc64.sparc64/scratch/tmp/bz/head.svn/tmp/usr/inc= lude/netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (not = in a function) >> *** [rtsol.o] Error code 1 >> 1 error >> *** [rtsol_make] Error code 2 >> 1 error >=20 >=20 > Probably http://svnweb.freebsd.org/changeset/base/249543 This has been fixed in r249552 now. ------enig2BODLLRLDLPCSARUXHUFJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlFthTcACgkQfoCS2CCgtiv6fQD+OySAs7Z6AzInAsm7YQ0l3D5l /SNn25cR9C1pFgUhBZQA/0OdbfI/J9MSd447rgazTFWC46V/RyjVC1TvySqX2rgq =LLCP -----END PGP SIGNATURE----- ------enig2BODLLRLDLPCSARUXHUFJ-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 17:56:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF8E6C5B for ; Tue, 16 Apr 2013 17:56:39 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-03.shaw.ca (smtp-out-03.shaw.ca [64.59.136.139]) by mx1.freebsd.org (Postfix) with ESMTP id A91BDC2E for ; Tue, 16 Apr 2013 17:56:39 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=qT60hWcJq2tKMlwzTlfV91MSQCJjCwg5oP07qu3o0oU= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=BAd17sX70kMIhsp1rSkA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-03.shaw.ca with ESMTP; 16 Apr 2013 11:57:31 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 25F9880; Tue, 16 Apr 2013 10:56:32 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3GHuVmu003474; Tue, 16 Apr 2013 10:56:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304161756.r3GHuVmu003474@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: current@freebsd.org Subject: Stack Overflow in GEOM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2013 10:56:31 -0700 Cc: cschuber@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:56:39 -0000 Has anyone see this before? Just updated my CURRENT partitions on my testbed and laptop. The laptop just boots but I've managed to capture this on my testbed (attached to a serial port on another system). This is HEAD from yesterday (Apr 15) morning (PDT). The partition being booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is there a way to quickly display that kern.kstack_pages from DDB? ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: ATA-7 device ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ata2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad4 ada3 at ata3 bus 0 scbus3 target 0 lun 0 ada3: ATA-7 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad6 SMP: AP CPU #1 Launched! panic: stack overflow detected; backtrace may be corrupted cpuid = 1 KDB: enter: panic [ thread pid 13 tid 100009 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 13 tid 100009 td 0x872d6000 kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at kdb_enter+0x3d/frame 0x86edca98 panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at panic+0x141/frame 0x86edcad4 __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at __stack_chk_init/frame 0x86edcae0 g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at g_label_disk_ident_taste+0x102/frame 0x86edcb70 g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at g_label_taste+0x3ca/frame 0x86edcc6c g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at g_new_provider_event+0xb1/frame 0x86edcc88 g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at g_run_events+0x19f/frame 0x86edccc4 fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 --- trap 0, eip = 0, esp = 0x86edcd40, ebp = 0 --- db> I've been poking at this off and on last night. Any ideas? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 18:13:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BCD6408 for ; Tue, 16 Apr 2013 18:13:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0F98FD68 for ; Tue, 16 Apr 2013 18:13:54 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r3GIDmUu017144 for ; Tue, 16 Apr 2013 11:13:48 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r3GIDmxp017143 for current@freebsd.org; Tue, 16 Apr 2013 11:13:48 -0700 (PDT) (envelope-from david) Date: Tue, 16 Apr 2013 11:13:48 -0700 From: David Wolfskill To: current@freebsd.org Subject: Re: Stack Overflow in GEOM Message-ID: <20130416181348.GR1404@albert.catwhisker.org> References: <201304161756.r3GHuVmu003474@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ItYuPQ2o89VkWXjV" Content-Disposition: inline In-Reply-To: <201304161756.r3GHuVmu003474@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 18:13:55 -0000 --ItYuPQ2o89VkWXjV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2013 at 10:56:31AM -0700, Cy Schubert wrote: > Has anyone see this before? Just updated my CURRENT partitions on my=20 > testbed and laptop. The laptop just boots but I've managed to capture thi= s=20 > on my testbed (attached to a serial port on another system). >=20 > This is HEAD from yesterday (Apr 15) morning (PDT). The partition being= =20 > booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is there= a=20 > way to quickly display that kern.kstack_pages from DDB? > ...=20 > panic: stack overflow detected; backtrace may be corrupted > cpuid =3D 1 > KDB: enter: panic > [ thread pid 13 tid 100009 ] > .... I'm seeing this, but my situation is ... reversed: my build machine came up OK: FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1134 r2= 49538M/249542:1000030: Tue Apr 16 09:15:49 PDT 2013 root@freebeast.catw= hisker.org:/usr/obj/usr/src/sys/GENERIC i386 but my laptop exhibits symptoms that I *believe* resemble those you cited. (I was unable to get a crash dump, and the machine rebooted too quickly after I typed "panic" at the ddb prompt. I don't have a serial console on the laptop.) I had thought that it might be nvidia-driver-related (again), but I also note that the laptop has a single SATA drive, while the build machine has SCSI (possibly SAS -- machine is powered off for the day, since its work is done) drives. Laptop also has 2x the memory the build machine does. (They are each i386.) My last successful smoke-test for head on the laptop was yesterday: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #869 r2495= 02M/249503:1000030: Mon Apr 15 05:23:38 PDT 2013 root@g1-227.catwhisker= =2Eorg:/usr/obj/usr/src/sys/CANARY i386 I had built head @r249538 this morning, and that's the build where my smoke-test failed. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ItYuPQ2o89VkWXjV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFtlNsACgkQmprOCmdXAD0TwgCeMpsc3HcX/sSoOLFcmPt0W5Fh gFgAnjMyyAnqY0LJ5aBlIIm5a7lEdkiu =0346 -----END PGP SIGNATURE----- --ItYuPQ2o89VkWXjV-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 18:36:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7943CFB; Tue, 16 Apr 2013 18:36:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1020AE69; Tue, 16 Apr 2013 18:36:14 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3GIaJGc015834; Tue, 16 Apr 2013 13:36:19 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3GIaIP2015833; Tue, 16 Apr 2013 13:36:18 -0500 (CDT) (envelope-from brooks) Date: Tue, 16 Apr 2013 13:36:18 -0500 From: Brooks Davis To: Adrian Chadd Subject: Re: control of order of inet devices Message-ID: <20130416183618.GG98205@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L1c6L/cjZjI9d0Eq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Willy Offermans , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 18:36:15 -0000 --L1c6L/cjZjI9d0Eq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 16, 2013 at 10:08:00AM -0700, Adrian Chadd wrote: > Since people keep asking about this; maybe it's time we added a hint > to the bus code that allows for the unit to be set based on the pci > bus / slot / etc. I don't see how that would address Willy's request. Neither the unit number or the if_index of an interface effects its order in getifaddrs() output. With modern bus hierarchies, you probably don't want to use the unit anyway as it loses too much information. Some along the lines of Fedora's Consistent Network Device Naming would likely be more useful. That would be fairly easy to implement. -- Brooks --L1c6L/cjZjI9d0Eq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRbZoiXY6L6fI4GtQRAnuJAJ9AU4LWOJ9Fx2XcFfXr3O6VznsC3ACdHU8N z43Dv00XJBwtbzvt8wohuyQ= =hIjv -----END PGP SIGNATURE----- --L1c6L/cjZjI9d0Eq-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 18:58:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C09F383F; Tue, 16 Apr 2013 18:58:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4A7FA8; Tue, 16 Apr 2013 18:58:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b037:d3c5:d0df:2e6b] (unknown [IPv6:2001:7b8:3a7:0:b037:d3c5:d0df:2e6b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EBDC65C44; Tue, 16 Apr 2013 20:58:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ From: Dimitry Andric In-Reply-To: <1URs5b-000B9U-A2@internal.tormail.org> Date: Tue, 16 Apr 2013 20:58:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> To: Jan Beich X-Mailer: Apple Mail (2.1503) Cc: FreeBSD Current , "O. Hartmann" , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 18:58:58 -0000 On Apr 16, 2013, at 00:42, Jan Beich wrote: > "O. Hartmann" writes: >> ./unistd.h:694:5: error: invalid token at start of a preprocessor >> expression >> #if @GNULIB_EUIDACCESS@ >> ^ >> 1 error generated. > > Maybe -O3 overoptimizes regex in libc e.g., > > $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' > #if @GNULIB_EUIDACCESS@ > > $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' > aaaaaaaaaaaaaaaaxxxaaaa How did you arrive at this result? I have recompiled both libc and sed with -O3, but it works just fine here. Maybe -march=native is the clue, so which kind of CPU do you have? To see what CPU llvm detects, try: tblgen -version | grep CPU Note that -O3 turns on clang's vectorizer, so you might have run into an optimizer bug, or some kind of undefined behavior which now falls over. -Dimitry From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 19:03:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6161B8E; Tue, 16 Apr 2013 19:03:21 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id 59222100F; Tue, 16 Apr 2013 19:03:21 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id gf12so697024vcb.32 for ; Tue, 16 Apr 2013 12:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wmmhsbq4zCPOEQHAmFllhh8bDk6Js4Md8hhhw5uG+bc=; b=zwteLh/xJtZjLMrZb2qtQcdgxGxhjkAeARlmySjVEDztVI67tVYt4HKetRCmt4PTU3 o+ig//DMV8MTdVtRXMX7BPcPWArPbJqGXp1ndXO4p2sPVUQW+aATAlsMMbSKmC4GwVDR kSdqBwire5y4d/MvBqX8Eplk1cRZoLrrWBazOnUWpB9lE0VJ/CWwjvji3oXXdzbJR+TL XQuefbWhNwF5QLFy9xj0zspvf67I0+QNuy6awiFC4BiiwqZPgU02KyEI0ApP+nj9lLVN pw72oEYsk2zfWxXdD/jePMzFlD4VdETNiQG3Q4t8dQWkOFZPaF+ONXUX2L/Nek0LcyAg l1sg== MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr2134726vdc.86.1366138994830; Tue, 16 Apr 2013 12:03:14 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Tue, 16 Apr 2013 12:03:14 -0700 (PDT) In-Reply-To: <20130416183618.GG98205@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130416183618.GG98205@lor.one-eyed-alien.net> Date: Tue, 16 Apr 2013 12:03:14 -0700 Message-ID: Subject: Re: control of order of inet devices From: Mehmet Erol Sanliturk To: Brooks Davis Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , freebsd-current , Willy Offermans , "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 19:03:21 -0000 On Tue, Apr 16, 2013 at 11:36 AM, Brooks Davis wrote: > On Tue, Apr 16, 2013 at 10:08:00AM -0700, Adrian Chadd wrote: > > Since people keep asking about this; maybe it's time we added a hint > > to the bus code that allows for the unit to be set based on the pci > > bus / slot / etc. > > I don't see how that would address Willy's request. Neither the unit > number or the if_index of an interface effects its order in > getifaddrs() output. > > With modern bus hierarchies, you probably don't want to use the unit > anyway as it loses too much information. Some along the lines of > Fedora's Consistent Network Device Naming would likely be more useful. > That would be fairly easy to implement. > > -- Brooks > Fedora is using eth0 , ... , eth9 , but FreeBSD is using em* , re* , .. names which is much better than Fedora ( or similar distributions ) approach . In eth0 , ... , usage , it is necessary to record MAC addresses of the NIC units ( because any name is not displayed like FreeBSD ) BEFORE starting an installation to isolate which one is referenced : Even this is not very useful sometimes because I am seeing they ( different Linux distributions ) are reporting MAC addresses differently for some NIC units , and no one of them is identical to others to number eth with existing NIC units ( for example , eth0 is not used for the same NIC by all the distributions , i.e. , there is no any standard numbering scheme ) . FreeBSD is using names ( Realtek , Intel , etc with other information also ) which is very easy to understand which NIC unit is referenced . I think , in FreeBSD , the problem may occur when all of the NIC units are the same model . For such cases , there is a necessity to display also slot / port information ( in that case MAC address is not showing slot / port information ) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 19:06:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AD26D29; Tue, 16 Apr 2013 19:06:30 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id BECBE1045; Tue, 16 Apr 2013 19:06:29 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3GJ6YiH016047; Tue, 16 Apr 2013 14:06:34 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3GJ6YUk016046; Tue, 16 Apr 2013 14:06:34 -0500 (CDT) (envelope-from brooks) Date: Tue, 16 Apr 2013 14:06:34 -0500 From: Brooks Davis To: Mehmet Erol Sanliturk Subject: Re: control of order of inet devices Message-ID: <20130416190634.GH98205@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130416183618.GG98205@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzX0AQGjRQPusK/O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-current , Willy Offermans , "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 19:06:30 -0000 --NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2013 at 12:03:14PM -0700, Mehmet Erol Sanliturk wrote: > On Tue, Apr 16, 2013 at 11:36 AM, Brooks Davis wrote: >=20 > > On Tue, Apr 16, 2013 at 10:08:00AM -0700, Adrian Chadd wrote: > > > Since people keep asking about this; maybe it's time we added a hint > > > to the bus code that allows for the unit to be set based on the pci > > > bus / slot / etc. > > > > I don't see how that would address Willy's request. Neither the unit > > number or the if_index of an interface effects its order in > > getifaddrs() output. > > > > With modern bus hierarchies, you probably don't want to use the unit > > anyway as it loses too much information. Some along the lines of > > Fedora's Consistent Network Device Naming would likely be more useful. > > That would be fairly easy to implement. > > > > -- Brooks > > >=20 >=20 > Fedora is using eth0 , ... , eth9 , but FreeBSD is using em* , re* , .. > names which is much better than Fedora ( or similar distributions ) > approach . As of Fedora 16 the default was changed: http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Gu= ide/appe-Consistent_Network_Device_Naming.html -- Brooks --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD4DBQFRbaE5XY6L6fI4GtQRAibVAJdYxjwSha0r7Iwb/y3DVD40VCN1AKCd94Gs NRQ0i9nK9GPVz6PAQoAwEw== =e7T4 -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 19:22:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16972488; Tue, 16 Apr 2013 19:22:53 +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]) by mx1.freebsd.org (Postfix) with ESMTP id C8DC9114F; Tue, 16 Apr 2013 19:22:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) with esmtp (envelope-from ) id <1USBSn-001Ey3-6N>; Tue, 16 Apr 2013 21:22:45 +0200 Received: from f052018160.adsl.alicedsl.de ([78.52.18.160] helo=[192.168.0.128]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) with esmtpsa (envelope-from ) id <1USBSn-000UXA-1W>; Tue, 16 Apr 2013 21:22:45 +0200 Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ From: "O. Hartmann" To: Dimitry Andric In-Reply-To: References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+JNEwKYMXXQyvXjb8Vxe" Date: Tue, 16 Apr 2013 21:22:44 +0200 Message-ID: <1366140164.1505.2.camel@thor.walstatt.dyndns.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Originating-IP: 78.52.18.160 Cc: FreeBSD Current , FreeBSD ports , Jan Beich X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 19:22:53 -0000 --=-+JNEwKYMXXQyvXjb8Vxe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, 2013-04-16 at 20:58 +0200, Dimitry Andric wrote: > On Apr 16, 2013, at 00:42, Jan Beich wrote: > > "O. Hartmann" writes: > >> ./unistd.h:694:5: error: invalid token at start of a preprocessor > >> expression > >> #if @GNULIB_EUIDACCESS@ > >> ^ > >> 1 error generated. > >=20 > > Maybe -O3 overoptimizes regex in libc e.g., > >=20 > > $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' > > #if @GNULIB_EUIDACCESS@ > >=20 > > $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' > > aaaaaaaaaaaaaaaaxxxaaaa >=20 > How did you arrive at this result? I have recompiled both libc and sed > with -O3, but it works just fine here. Maybe -march=3Dnative is the clue= , > so which kind of CPU do you have? To see what CPU llvm detects, try: >=20 > tblgen -version | grep CPU >=20 > Note that -O3 turns on clang's vectorizer, so you might have run into an > optimizer bug, or some kind of undefined behavior which now falls over. >=20 > -Dimitry >=20 tblgen -version | grep CPU: Host CPU: penryn (host A) Host CPU: core-avx-i (host B) Host CPU: corei7-avx (host C) and the problem occurs on all of those boxes running most recent FreeBSD 10.0-CURRENT with CLANG 3.3 --=-+JNEwKYMXXQyvXjb8Vxe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRbaUEAAoJEOgBcD7A/5N80zoIANwvx2NHWhqz7ElKbxTqolpU dJatrIJxdlBgYosrV6oFmN4z4SdViNuKUS1rDD7/SkvBnrdNlETBLJlVnG84+VsY ydrXZ2CvZRj3jk7LfvT7M/K741ZEQtN7JyZj81Lk5jnGycUmr9AIwyt3GRciTTWk pySq9fkcmT3kk3atihoT6C4ko+CZxoyaOSEPOzSKOOxwO9aGKjfSH7offTi22vj5 dTaVhhEE5LVvB4NsJVIIkI17o1EllKMUQNh2F63FITXpdgnNXN6FV2/rXNBwLV97 SVvbc+6RPVF4pXCtKir/a4km4ZKLpwaN16wJ6wlt2M80M+ssr0WemdYhXcg6AaQ= =euec -----END PGP SIGNATURE----- --=-+JNEwKYMXXQyvXjb8Vxe-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 19:57:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA5D0F08 for ; Tue, 16 Apr 2013 19:57:18 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx1.freebsd.org (Postfix) with ESMTP id 8948B1381 for ; Tue, 16 Apr 2013 19:57:18 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id lj1so517677pab.35 for ; Tue, 16 Apr 2013 12:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gjlWU9dlfNbWLYx4afk2rQjLMMpCMHyTEmO8SUDjMfY=; b=td7h7ojU6aGgEn6zd2LbU+QadRO+q4CvcrEZIBwS6vPQY0b25P8gAit3hgHx52fJjx ViD9mFHI1kpvD4iqXV9ceCSwEpeUjhNHdMlNvX9apZp3Q5tOLDQciX8SecfTyOlazPj6 bOnVJQFlTrxH6GspZ2JoUS2wTbhDNJG5RTnrj6MV0GgLitgB9R7u3Q8zklT52jy9kRIp rnhj1DouUAu2JJmNhjG4bfoK9biD9L6r+Zdb2hsq1lt3K26vedO/N1Zsui/EoHGgE6dd QgB+tqqRrGn5bm6TuzOtpdbZpcfAd6oaDPTklKStJp6vgNRTcivEd1wYrc5j5OHrKmGH HMtQ== X-Received: by 10.66.119.202 with SMTP id kw10mr4951918pab.181.1366142232008; Tue, 16 Apr 2013 12:57:12 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id j13sm3849698pat.17.2013.04.16.12.57.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 12:57:10 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <516DAD14.9020307@FreeBSD.org> Date: Tue, 16 Apr 2013 12:57:08 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: FreeBSD Current Subject: DTrace gone quiet? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 19:57:18 -0000 I just upgraded my kernel and userspace to head (r249552) and I notice that DTrace doesn't output anything until I hit ctrl-c. All previous "hits" on the probe appear lost. For example: # dtrace -n 'fbt::ether_output:entry' dtrace: description 'fbt::ether_output:entry' matched 1 probe (No output here. I waited a long time before the ctrl-c and I know the system is actively transmitting and receiving Ethernet traffic). ^C CPU ID FUNCTION:NAME 9 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry Can anyone confirm or contradict this on a recent HEAD (around r249552 in my case)? Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:01:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3156A579 for ; Tue, 16 Apr 2013 20:01:56 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C0A5113D2 for ; Tue, 16 Apr 2013 20:01:55 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e51so430471eek.13 for ; Tue, 16 Apr 2013 13:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fnPhKO3KC0S2rg2QF6f/RYC/vQuIo2x8AtXKd6ETm4I=; b=CMWT+gX1Uq1Tgm+SAIU0CVfR3TRt5hPQHNPvF+XmnOuFFcP/Nj4pjEkgLTtofSb2w9 fs5mIgFC9fLeH8IwwjZl0M9tQP2YPtrlxja6wFiQa/L5BMatdTd7NqQ0ixLozyQsOrxr 8LwNtvgVyO713ZqpjivOwGPF1MEOQ+Qt48nOJkt3Zje/gHfw0vIkiPJBR/WG+Ze84iuT mZuqCsqElaE1phDKFiUJ34lIk2H8nzAr4LXiBOEGJ3iL18wfZqpEGcb4Jc9VnIzmgtn7 U5jkjBYud8sH4QUwbRseAXZmRv7sfXOpn0wI5CPRMWIVIZQpIYOCT2aVK64u3pvuYvlH FESA== MIME-Version: 1.0 X-Received: by 10.15.99.201 with SMTP id bl49mr9661070eeb.43.1366142509603; Tue, 16 Apr 2013 13:01:49 -0700 (PDT) Received: by 10.14.111.2 with HTTP; Tue, 16 Apr 2013 13:01:49 -0700 (PDT) In-Reply-To: <20130416181348.GR1404@albert.catwhisker.org> References: <201304161756.r3GHuVmu003474@slippy.cwsent.com> <20130416181348.GR1404@albert.catwhisker.org> Date: Tue, 16 Apr 2013 13:01:49 -0700 Message-ID: Subject: Re: Stack Overflow in GEOM From: Jim Harris To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:01:56 -0000 On Tue, Apr 16, 2013 at 11:13 AM, David Wolfskill wrote: > On Tue, Apr 16, 2013 at 10:56:31AM -0700, Cy Schubert wrote: > > Has anyone see this before? Just updated my CURRENT partitions on my > > testbed and laptop. The laptop just boots but I've managed to capture > this > > on my testbed (attached to a serial port on another system). > > > > This is HEAD from yesterday (Apr 15) morning (PDT). The partition being > > booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is > there a > > way to quickly display that kern.kstack_pages from DDB? > > ... > > panic: stack overflow detected; backtrace may be corrupted > > cpuid = 1 > > KDB: enter: panic > > [ thread pid 13 tid 100009 ] > > .... > > I'm seeing this, but my situation is ... reversed: my build machine came > up OK: > > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1134 > r249538M/249542:1000030: Tue Apr 16 09:15:49 PDT 2013 > root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > > but my laptop exhibits symptoms that I *believe* resemble those you > cited. (I was unable to get a crash dump, and the machine rebooted too > quickly after I typed "panic" at the ddb prompt. I don't have a serial > console on the laptop.) > > I had thought that it might be nvidia-driver-related (again), but I also > note that the laptop has a single SATA drive, while the build machine > has SCSI (possibly SAS -- machine is powered off for the day, since its > work is done) drives. Laptop also has 2x the memory the build machine > does. (They are each i386.) > > My last successful smoke-test for head on the laptop was yesterday: > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #869 > r249502M/249503:1000030: Mon Apr 15 05:23:38 PDT 2013 > root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > I had built head @r249538 this morning, and that's the build where > my smoke-test failed. > > This stack trace corruption was noted on svn-src-head@ as well, and appears to be fixed with r249564. -Jim From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:03:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 74DD66A1; Tue, 16 Apr 2013 20:03:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 35FA61438; Tue, 16 Apr 2013 20:03:07 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k18so888722oag.39 for ; Tue, 16 Apr 2013 13:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vUGSwXRi2dug0e6ufpVkA6LHXluyQU7ewHT1aLD1mks=; b=H8qG4Z3i6XNBgyNokdArKTms2lAD8NtYOeoXFqGMgaw8SH2P23cUL+4WAPKpTADlY/ zJxwrfAQix79NwGOYmCX58CR75L7Y+1qrjB4Spvzac88Ygneyz5/STuwe5KgiBDIIeD8 4ERKdmPEtLfC5+d0ldiyU5+hHKK5cgjYkfYZwcAoLfSne/Y5T0j8+6VN2RDsofOXhv9Q lVGQHhtuAX961JN7kZO91LDV5VCG1zIBAdTSQTrgtow+TenNd+C2kwkQLKiGVJ6FVEVk U7i9i+28cLo3GL0ukybcRWpGqbr8gop3I8sS3CUUqNy7GRiGW6kArFw6+a3ojSGGojr/ TiSA== MIME-Version: 1.0 X-Received: by 10.60.132.196 with SMTP id ow4mr1421064oeb.75.1366142586458; Tue, 16 Apr 2013 13:03:06 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Tue, 16 Apr 2013 13:03:06 -0700 (PDT) In-Reply-To: <516DAD14.9020307@FreeBSD.org> References: <516DAD14.9020307@FreeBSD.org> Date: Tue, 16 Apr 2013 16:03:06 -0400 Message-ID: Subject: Re: DTrace gone quiet? From: Ryan Stone To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:03:07 -0000 On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar wrote: > I just upgraded my kernel and userspace to head (r249552) and I notice > that DTrace doesn't output anything until I hit ctrl-c. All previous > "hits" on the probe appear lost. For example: > > # dtrace -n 'fbt::ether_output:entry' > dtrace: description 'fbt::ether_output:entry' matched 1 probe > > (No output here. I waited a long time before the ctrl-c and I know the > system is actively transmitting and receiving Ethernet traffic). > > ^C > CPU ID FUNCTION:NAME > 9 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > > > Can anyone confirm or contradict this on a recent HEAD (around r249552 > in my case)? > > Regards, > Navdeep > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Hm, if you run with "-x bufpolicy=switch" does it work? It sounds as through the ring buffer policy is being set by default for you. I'm not sure how that could happen. From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:04:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C3777CC; Tue, 16 Apr 2013 20:04:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 18C0E1459; Tue, 16 Apr 2013 20:04:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b037:d3c5:d0df:2e6b] (unknown [IPv6:2001:7b8:3a7:0:b037:d3c5:d0df:2e6b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8E5BF5C44; Tue, 16 Apr 2013 22:04:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: control of order of inet devices From: Dimitry Andric In-Reply-To: <20130416183618.GG98205@lor.one-eyed-alien.net> Date: Tue, 16 Apr 2013 22:04:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130416183618.GG98205@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1503) Cc: Adrian Chadd , freebsd-current@freebsd.org, Willy Offermans , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:04:47 -0000 On Apr 16, 2013, at 20:36, Brooks Davis wrote: > On Tue, Apr 16, 2013 at 10:08:00AM -0700, Adrian Chadd wrote: >> Since people keep asking about this; maybe it's time we added a hint >> to the bus code that allows for the unit to be set based on the pci >> bus / slot / etc. > > I don't see how that would address Willy's request. Neither the unit > number or the if_index of an interface effects its order in > getifaddrs() output. > > With modern bus hierarchies, you probably don't want to use the unit > anyway as it loses too much information. Some along the lines of > Fedora's Consistent Network Device Naming would likely be more useful. > That would be fairly easy to implement. I've been using the ifconfig_XXX_name setting in rc.conf for years now, which at works fine, at least for me. E.g.: ifconfig_em0_name="if_ext" ifconfig_em1_name="if_lan" ifconfig_ral0_name="if_wifi" However, if bus enumeration would randomly swap em0 and em1, for example, this would break down. Linux usually just fixes a specific interface name to a hardware address, e.g. /etc/sysconfig/network-scripts/ifcfg-eth0 on a CentOS box has: DEVICE="eth0" BOOTPROTO="dhcp" HWADDR="00:0C:29:65:E4:E3" ... From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:06:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9357E92D; Tue, 16 Apr 2013 20:06:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 511AA147F; Tue, 16 Apr 2013 20:06:03 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id h23so780040iae.14 for ; Tue, 16 Apr 2013 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qyG5TvFSkCAtHRybUaWDjsVjw54BsbNz0OgqoEztwx8=; b=N5wFGQiNG7nAzzfypeRz2OTg0IhcjJ7Y7jk5RZ3rZoHPGBnrW5m0HC7vx0m5Aq+7MQ 1J4KgImIrqyfLkHSknBh9PlioepGTIyA936UkhpLl7vziabbihBYrZP0mRusAxEZGtmM ou+2dRclHHlgKnSWASsbG+a+CvZJ72ImSFF32uTKWcZszOol5o18ETQIuQKYn7xCmMlt pU41vAaRXuUDTb0n31BjdW5eCA39PQF/bFifmlhWBgsDCNTDQR8zUtQ6p+MXDVgZRnpk vVkE7aMv42uJBfQrPZI44OtUoMJMhH+5iKxoP3lUatp7O2AwUpBBxubJqb25EP6w2kXA VDsw== X-Received: by 10.50.127.137 with SMTP id ng9mr2301055igb.32.1366142762891; Tue, 16 Apr 2013 13:06:02 -0700 (PDT) Received: from gloom.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPS id y5sm3367362igg.7.2013.04.16.13.06.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 13:06:02 -0700 (PDT) Date: Tue, 16 Apr 2013 16:05:47 -0400 From: Mark Johnston To: Ryan Stone Subject: Re: DTrace gone quiet? Message-ID: <20130416200547.GA17097@gloom.sandvine.com> References: <516DAD14.9020307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:06:03 -0000 On Tue, Apr 16, 2013 at 04:03:06PM -0400, Ryan Stone wrote: > On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar wrote: > > > I just upgraded my kernel and userspace to head (r249552) and I notice > > that DTrace doesn't output anything until I hit ctrl-c. All previous > > "hits" on the probe appear lost. For example: > > > > # dtrace -n 'fbt::ether_output:entry' > > dtrace: description 'fbt::ether_output:entry' matched 1 probe > > > > (No output here. I waited a long time before the ctrl-c and I know the > > system is actively transmitting and receiving Ethernet traffic). > > > > ^C > > CPU ID FUNCTION:NAME > > 9 29354 ether_output:entry > > 8 29354 ether_output:entry > > 8 29354 ether_output:entry > > 8 29354 ether_output:entry > > > > > > Can anyone confirm or contradict this on a recent HEAD (around r249552 > > in my case)? > > > > Regards, > > Navdeep > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > Hm, if you run with "-x bufpolicy=switch" does it work? It sounds as > through the ring buffer policy is being set by default for you. I'm not > sure how that could happen. I'm seeing it too as of r249508. Adding those arguments doesn't seem to have any effect. From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:14:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A07D6CA1 for ; Tue, 16 Apr 2013 20:14:12 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2BC151B for ; Tue, 16 Apr 2013 20:14:12 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id kx1so531490pab.0 for ; Tue, 16 Apr 2013 13:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bgjNr5/Vl0scF5HUs3imj6jTRKhUl/8gLD16lF0Z76g=; b=YrjKRcX7oEYUpzFvGSHawSavMDPEyMKwlpIdk7BztzBx87LY4lSs/BS1pDc4mAcAX8 s9Bu2W1dssln7937SHl1DsH+taFxYV5HKBPN07ZSwL5ETYEnACFkubqqaM2z7blKLNNv hMYZCfnSxZ9+QWjdhUk6kx0kOWur+VrEJuzZMb9FCI9XU9XoJ6/4KOWGQOx23rIti+mS ANVRiNPVz7LQYVb8JGrQPykj6o4P/rg028mHH5u8qfisTL2t6tuKrHY3posm5RREaKyp /95Wmp96K3VefHq8EUHFQ3XGoaNM9zwFIR2EfZ5zGaK5pCOnQmmjIHMWH15XUMi9+AGG 1SkA== X-Received: by 10.66.52.50 with SMTP id q18mr5037392pao.201.1366142770522; Tue, 16 Apr 2013 13:06:10 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id t1sm3891207pab.12.2013.04.16.13.06.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 13:06:09 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <516DAF2F.3010107@FreeBSD.org> Date: Tue, 16 Apr 2013 13:06:07 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ryan Stone Subject: Re: DTrace gone quiet? References: <516DAD14.9020307@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:14:12 -0000 On 04/16/13 13:03, Ryan Stone wrote: > On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar > wrote: > > I just upgraded my kernel and userspace to head (r249552) and I notice > that DTrace doesn't output anything until I hit ctrl-c. All previous > "hits" on the probe appear lost. For example: > > # dtrace -n 'fbt::ether_output:entry' > dtrace: description 'fbt::ether_output:entry' matched 1 probe > > (No output here. I waited a long time before the ctrl-c and I know the > system is actively transmitting and receiving Ethernet traffic). > > ^C > CPU ID FUNCTION:NAME > 9 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > > > Can anyone confirm or contradict this on a recent HEAD (around r249552 > in my case)? > > Regards, > Navdeep > > > Hm, if you run with "-x bufpolicy=switch" does it work? It sounds as > through the ring buffer policy is being set by default for you. I'm not > sure how that could happen. No luck. trantor:~# dtrace -x bufpolicy=switch -n 'fbt::ether_output:entry' dtrace: description 'fbt::ether_output:entry' matched 1 probe (long fruitless wait here) ^C CPU ID FUNCTION:NAME 4 29354 ether_output:entry 3 29354 ether_output:entry 9 29354 ether_output:entry 3 29354 ether_output:entry From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:36:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 257A2793 for ; Tue, 16 Apr 2013 20:36:18 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 04917162B for ; Tue, 16 Apr 2013 20:36:17 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r3GKaHsR018456 for ; Tue, 16 Apr 2013 13:36:17 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r3GKaHD7018455 for current@freebsd.org; Tue, 16 Apr 2013 13:36:17 -0700 (PDT) (envelope-from david) Date: Tue, 16 Apr 2013 13:36:17 -0700 From: David Wolfskill To: "current@freebsd.org" Subject: Re: Stack Overflow in GEOM Message-ID: <20130416203617.GT1404@albert.catwhisker.org> References: <201304161756.r3GHuVmu003474@slippy.cwsent.com> <20130416181348.GR1404@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OtP8TOIcu2/MSuWQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:36:18 -0000 --OtP8TOIcu2/MSuWQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 16, 2013 at 01:01:49PM -0700, Jim Harris wrote: > ... > > I had built head @r249538 this morning, and that's the build where > > my smoke-test failed. > > > > > This stack trace corruption was noted on svn-src-head@ as well, and appea= rs > to be fixed with r249564. > .... Cool; thanks -- I applied that & rebuilt/installed my kernel; the laptop now boots: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #872 r2495= 38M/249542:1000030: Tue Apr 16 13:16:46 PDT 2013 root@g1-227.catwhisker= =2Eorg:/usr/obj/usr/src/sys/CANARY i386 and runs X; I can login and stuff. :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --OtP8TOIcu2/MSuWQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFttkAACgkQmprOCmdXAD1zuACfcrYTt7jNikRiToj7ibWaYLEv DUMAnja2Rq4mLkq3UZtDigdG3YKoZCHg =c3nx -----END PGP SIGNATURE----- --OtP8TOIcu2/MSuWQ-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:54:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D2359FA5; Tue, 16 Apr 2013 20:54:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 95C4016E6; Tue, 16 Apr 2013 20:54:39 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so1093858ieb.6 for ; Tue, 16 Apr 2013 13:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=pnzbqyOxraz7QqQybHlCkyrrN0D9hR8siJmenE4XAwE=; b=IFuBM5x2STgXQJpLEKoJOrW6gTIm5TeCVO4GqgBhicMji1J0ujENX4Kya4eVyOESwf ufn9aktmcQ/HTWBsPjYRc4C3E8zvNI/oJYBROF8BayIR/4RIJd8L+naEoDdGjVrxbKoM Sk2Ga0gHJ4mmUPqAcTVxZwfbnHQkp7YKrL+2u1JlKXOVXxrP7l27jIPTbO84nS54h1Z6 TGU29rXJCyM3z5U0xKmwtlOvCVYnGlwLiqI4pSytLC8ft3c/hkp4IKJWhQe6tJoI20Fi 4h4u/eC8PJzpWzsfKo+b6RGDiTmbqHZsrIdRQ7wv4ygGY4DeRhr7wUYN2tJ1Z5pC412X ObwQ== X-Received: by 10.50.154.72 with SMTP id vm8mr2568250igb.1.1366145679177; Tue, 16 Apr 2013 13:54:39 -0700 (PDT) Received: from gloom.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPS id w7sm1878904igl.4.2013.04.16.13.54.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 13:54:37 -0700 (PDT) Date: Tue, 16 Apr 2013 16:54:29 -0400 From: Mark Johnston To: Navdeep Parhar Subject: Re: DTrace gone quiet? Message-ID: <20130416205403.GA1409@gloom.sandvine.com> References: <516DAD14.9020307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516DAD14.9020307@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , pfg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:54:39 -0000 On Tue, Apr 16, 2013 at 12:57:08PM -0700, Navdeep Parhar wrote: > I just upgraded my kernel and userspace to head (r249552) and I notice > that DTrace doesn't output anything until I hit ctrl-c. All previous > "hits" on the probe appear lost. For example: > > # dtrace -n 'fbt::ether_output:entry' > dtrace: description 'fbt::ether_output:entry' matched 1 probe > > (No output here. I waited a long time before the ctrl-c and I know the > system is actively transmitting and receiving Ethernet traffic). > > ^C > CPU ID FUNCTION:NAME > 9 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > > > Can anyone confirm or contradict this on a recent HEAD (around r249552 > in my case)? Reverting r249367 and rebuilding libdtrace+the kernel fixes the problem for me. -Mark From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 20:55:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 704A4146; Tue, 16 Apr 2013 20:55:22 +0000 (UTC) (envelope-from ohauer@FreeBSD.org) Received: from p578be941.dip0.t-ipconnect.de (p578be941.dip0.t-ipconnect.de [87.139.233.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3008716FB; Tue, 16 Apr 2013 20:55:22 +0000 (UTC) Received: from [192.168.0.100] (cde1100.uni.vrs [192.168.0.100]) (Authenticated sender: ohauer) by p578be941.dip0.t-ipconnect.de (Postfix) with ESMTPSA id A53232092F; Tue, 16 Apr 2013 22:55:19 +0200 (CEST) Message-ID: <516DBAB6.3040602@FreeBSD.org> Date: Tue, 16 Apr 2013 22:55:18 +0200 From: Olli Hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: FreeBSD Current Subject: Please test upcoming DTrace port mod_usdt for apache22 X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Pedro Giffuni X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 20:55:22 -0000 Hi, I've created together with Pedro Giffuni (pfg@) a new DTrace apache port (www/mod_usdt). We are interested in getting some more test results from DTrace and apache users. A complete description is here: http://dtrace.org/blogs/dap/2011/12/13/usdt-providers-redux/ shar file for mod_usdt can be found here: http://people.freebsd.org/~ohauer/shar/mod_usdt_2013051601.shar Thanks, olli From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 21:02:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CB6F4BC for ; Tue, 16 Apr 2013 21:02:35 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) by mx1.freebsd.org (Postfix) with SMTP id 9CB6F1745 for ; Tue, 16 Apr 2013 21:02:34 +0000 (UTC) Received: from [98.139.214.32] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2013 21:02:33 -0000 Received: from [98.139.212.196] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 16 Apr 2013 21:02:33 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 16 Apr 2013 21:02:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 637779.89680.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 71912 invoked by uid 60001); 16 Apr 2013 21:02:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366146153; bh=K+N8uMEWsihPJz8CnjlQgK+ZWO9G7LNjM46BtO5AiDo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SiKA8+JUgB/ha2FYoRCfOzit2YqxQCjeA0IIez94JmdEC7rFp2McxB4EdcG0cdsugCiPhLhiVwZisKdpDCwkci0hT/Sib1XT7VLNdsUe7xhTflwQG38DF/tr9DJZx5r4fY/zqfPZRvcUcr8LGJOP9ms4V24O9pY9WI9g5I/gPoo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r3Qd65VMfE543Za/ndfmNBrGS/tSabIcmrJAO258XDr6RRXVeRPnhNE0g5keGNxLBwsB9PergiZwDvZ6alafypa3tXbCj19jI8ntnkln7iUhI+9jVKJPtTYPX+3wLTFj3PxQmLgyGluCNowlxFO8KhXD41srknrKZ7HLV+ZI4i4=; X-YMail-OSG: 98wp1OoVM1lPN0IYkRXLWZgWbglbhXNe_FRHbRHtbB31J6I jTc_YTA7G7Rqh0_qEQeWNksP0QssZEd_qUXooUnhCN6IapnQA4XaUTkrPXBC yI9wrTVez.Fs7waV0L4UN1GXMPLgeJjq6x6kgJST4IdykSVC3t0aRFi9F_68 w42mn6Z5OfflXoDTzS4X4Sm7wiHDqVaJNlP_VtGQqYjbp38dOoMTv0AAbKST y.mK_j2ATLNrmcOxvx7.pzAcSxqh6Nz93Mja4dtY5ISGOyHj6trAeBE7cDSX eGfgvS7Z7h6ww87IgV94OUJ1Qo.1nAfDNsXzs8.BK8pXysLp78OeNPkzjXnP w962DQcHn1ym5y.k1EXjd9GHSFPbnSM_wZFOK.VJleq.Tx8HoXThFu3jW4pZ ZI.NXukcYMpGPYfJOSArJW3fTm81zqmu_.V_IUOu4ck6lNM2Kj1YxftqSC0Q 4_4ySJ.bgPbsXVH_fzo1Ulo7Srd24gcL45gC1Vm0PMcr92bZJ2OB2mwWuM5i tYbcMCh6dp_qVkH5OHo4N Received: from [190.157.126.109] by web162106.mail.bf1.yahoo.com via HTTP; Tue, 16 Apr 2013 14:02:33 PDT X-Rocket-MIMEInfo: 002.001, SGVsbG87CgpZZXMsIEkgd2FzIGluZGVlZCBnb2luZyB0byBwb3N0IHRoYXQgdGhlIGN1bHByaXQgaXMgdGhpcyBjaGFuZ2UgZnJvbSBJbGx1bW9zOgoKMzAyNiBsaWJkdHJhY2Ugc2hvdWxkIHNldCBMRF9OT0xBWllMT0FEPTEgdG8gaGVscCB0aGUgcGlkIHByb3ZpZGVyCgoKSXQgaXMgYW4gdXBzdHJlYW0gaGFjayBmb3IgdGhlIFNvbGFyaXMgbGQgdGhhdCB0aGV5IGJ1bmRsZWQgYW1vbmcKbWFueSBjaGFuZ2VzLgoKSSB3aWxsIHNlZSBob3cgdG8gcmV2ZXJ0IG9ubHkgdGhlIHBhcnQgdGhhdCBnaXZlcyBwcm8BMAEBAQE- X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.140.532 References: <516DAD14.9020307@FreeBSD.org> <20130416205403.GA1409@gloom.sandvine.com> Message-ID: <1366146153.65175.YahooMailNeo@web162106.mail.bf1.yahoo.com> Date: Tue, 16 Apr 2013 14:02:33 -0700 (PDT) From: Pedro Giffuni Subject: Re: DTrace gone quiet? To: Mark Johnston , Navdeep Parhar In-Reply-To: <20130416205403.GA1409@gloom.sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Pedro Giffuni List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 21:02:35 -0000 Hello;=0A=0AYes, I was indeed going to post that the culprit is this change= from Illumos:=0A=0A3026 libdtrace should set LD_NOLAZYLOAD=3D1 to help the= pid provider=0A=0A=0AIt is an upstream hack for the Solaris ld that they b= undled among=0Amany changes.=0A=0AI will see how to revert only the part th= at gives problems.=0A=0ASorry for the inconvenience,=0A=0APedro.=0A=0A=0A= =0A>________________________________=0A> Da: Mark Johnston=A0=0A>...=0A>=0A= >Reverting r249367 and rebuilding libdtrace+the kernel fixes the problem=0A= >for me.=0A>=0A>-Mark=0A>=0A>=0A> From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 22:44:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87ADB81D; Tue, 16 Apr 2013 22:44:49 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id 497851CB7; Tue, 16 Apr 2013 22:44:49 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=3f4U5fHrZLLPCzJ96ldNbjtja1zQ0ih230F6vdsLr5s= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=vaJtXVxTAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=sq_fSE3xARbxezGG6UEA:9 a=wPNLvfGTeEIA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 16 Apr 2013 16:45:46 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id A0D3580; Tue, 16 Apr 2013 15:44:46 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3GMiiNc004099; Tue, 16 Apr 2013 15:44:45 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304162244.r3GMiiNc004099@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "Ilya A. Arkhipov" Subject: Re: Stack Overflow in GEOM In-Reply-To: Message from "Ilya A. Arkhipov" of "Tue, 16 Apr 2013 22:01:16 +0400." <1257671366135276@web6f.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Apr 2013 15:44:44 -0700 Cc: geom@freebsd.org, current@freebsd.org, ivoras@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 22:44:49 -0000 In message <1257671366135276=40web6f.yandex.ru>, =22Ilya A. Arkhipov=22 w= rites: > 16.04.2013, 21:56, =22Cy Schubert=22 : > > Has anyone see this before? Just updated my CURRENT partitions on my > > testbed and laptop. The laptop just boots but I've managed to capture= this > > on my testbed (attached to a serial port on another system). > > > > This is HEAD from yesterday (Apr 15) morning (PDT). The partition bei= ng > > booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is t= here a > > way to quickly display that kern.kstack_pages from DDB? > > > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-7 device > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad0 > > ada1 at ata0 bus 0 scbus0 target 1 lun 0 > > ada1: ATA-7 device > > ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) > > ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) > > ada1: Previously was known as ad1 > > ada2 at ata2 bus 0 scbus2 target 0 lun 0 > > ada2: ATA-8 SATA 2.x device > > ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > > ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada2: Previously was known as ad4 > > ada3 at ata3 bus 0 scbus3 target 0 lun 0 > > ada3: ATA-7 SATA 2.x device > > ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > > ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > > ada3: Previously was known as ad6 > > SMP: AP CPU =231 Launched=21 > > panic: stack overflow detected; backtrace may be corrupted > > cpuid =3D 1 > > KDB: enter: panic > > =5B thread pid 13 tid 100009 =5D > > Stopped at =9A=9A=9A=9A=9Akdb_enter+0x3d: movl =9A=9A=9A=240,kdb_why > > db> bt > > Tracing pid 13 tid 100009 td 0x872d6000 > > kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at > > kdb_enter+0x3d/frame 0x86edca98 > > panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at > > panic+0x141/frame 0x86edcad4 > > __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at > > __stack_chk_init/frame 0x86edcae0 > > g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at > > g_label_disk_ident_taste+0x102/frame 0x86edcb70 > > g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at > > g_label_taste+0x3ca/frame 0x86edcc6c > > g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at > > g_new_provider_event+0xb1/frame 0x86edcc88 > > g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at > > g_run_events+0x19f/frame 0x86edccc4 > > fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 > > fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 > > --- trap 0, eip =3D 0, esp =3D 0x86edcd40, ebp =3D 0 --- > > db> > > > > I've been poking at this off and on last night. Any ideas? > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: =9A =9A=9AWeb: =9Ahttp://www.FreeBSD.= org > > > > _______________________________________________ > > freebsd-current=40freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to =22freebsd-current-unsubscribe=40fre= ebsd.org=22 >=20 > Hi, >=20 > It should be related with: http://docs.freebsd.org/cgi/getmsg.cgi?fetch= =3D30160 > 3+0+current/svn-src-head >=20 > Author: ivoras > Date: Mon Apr 15 16:09:24 2013 > New Revision: 249508 > URL: http://svnweb.freebsd.org/changeset/base/249508 >=20 > Log: > Introduce glabel labels based on GEOM ident attributes. In this initi= al > implementation, error on the side of conservatism and only create lab= els > for GEOMs of classes DISK and MULTIPATH. >=20 > Discussed with: trasz > Approved by: silence from freebsd-geom=40 You were correct. Backing out r249508 in my tree resolves the panic on bo= th=20 hosts. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 23:02:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0CC0C1B; Tue, 16 Apr 2013 23:02:41 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by mx1.freebsd.org (Postfix) with ESMTP id 914E11D53; Tue, 16 Apr 2013 23:02:41 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id oz10so950176veb.10 for ; Tue, 16 Apr 2013 16:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8HaVuAmCmwXbwfbZyGW8e1cP4dCdthnwrStxm65jDsA=; b=X4c2/v+Ko1+3O98ea0VUmfad+rw/+v8Rl6I5Fbix0OUg2T3AlGKdkzVL6IW3jnqfNk HIAZpm+fK/iljvBEkxJO7/zvp6s3EkaiNCSypcJfOdfM+i4deWzW7TJOXka0Qoe179od Clg8CklEyDmcLwXzvw9nR6GimSd3Y2GTdxOF3ewyeI22ANdUgERWvdSTY7tuVCs+FaOu 6Hgrv1LfQLffezQ5dEL26P76yunOiHT6UBj8QFy343A4EwiwRBW+rhgi+vs90tx/2c24 Uyi0qcLk90Jgm46RJOX6XkSo+ehnShrSScgIKnYDiMkF4F8J3vjYs2NfWVg9GBBmB0ru WneQ== X-Received: by 10.52.99.67 with SMTP id eo3mr2709367vdb.21.1366153355385; Tue, 16 Apr 2013 16:02:35 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.58.34.162 with HTTP; Tue, 16 Apr 2013 16:01:55 -0700 (PDT) In-Reply-To: <201304162244.r3GMiiNc004099@slippy.cwsent.com> References: <1257671366135276@web6f.yandex.ru> <201304162244.r3GMiiNc004099@slippy.cwsent.com> From: Ivan Voras Date: Wed, 17 Apr 2013 01:01:55 +0200 X-Google-Sender-Auth: swoaGJ_yorVsAmQ0TLeQf1EYCY4 Message-ID: Subject: Re: Stack Overflow in GEOM To: Cy Schubert Content-Type: text/plain; charset=UTF-8 Cc: geom@freebsd.org, "Ilya A. Arkhipov" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 23:02:41 -0000 On 17 April 2013 00:44, Cy Schubert wrote: > You were correct. Backing out r249508 in my tree resolves the panic on both > hosts. Hi, Sorry about that - should be fixed by http://svnweb.freebsd.org/base?view=revision&revision=249564 . From owner-freebsd-current@FreeBSD.ORG Tue Apr 16 23:20:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9981F10E; Tue, 16 Apr 2013 23:20:15 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id F15341DEA; Tue, 16 Apr 2013 23:20:14 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id w20so1072966lbh.32 for ; Tue, 16 Apr 2013 16:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7wFtLO897IHsYH8Fxy1LxwrVRuH+Wm9/97227l0n6W4=; b=NXgApaMmH2yds2Db0lRGMNM6Q1drm5V+IlYqzi9yAhfD2SHIW/10Uui8e2WSyo0ik5 RKUmA4vL4wEFEWm9w0ARjCLPXO7RnO9TS0B4EPF2z0w38N1p0HfzJFZR9+hiPwYjUSxO i12OoGQ8TR1uC7z+2t0I7OJMwxwfh1ZdtELybGwZNoG7eYkvTK/w1RDWrShaWLcATvdd +t0Tt+/qtdbiAXOhUTLKPwh4kscL40UoJtOz2lNSqFs+yi6n0Nh8CU9Cz/RsEvlvBeVm VKCA2FBQnHKnGX8prAqxMHPv5/T17tlPtPJogwZeBTqNAB0IwQp5oEVaYdCbt2ayQtN0 2wzA== MIME-Version: 1.0 X-Received: by 10.112.133.137 with SMTP id pc9mr2341590lbb.74.1366154407758; Tue, 16 Apr 2013 16:20:07 -0700 (PDT) Received: by 10.114.12.232 with HTTP; Tue, 16 Apr 2013 16:20:07 -0700 (PDT) In-Reply-To: <516D8531.1090006@coosemans.org> References: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> <516D8531.1090006@coosemans.org> Date: Tue, 16 Apr 2013 16:20:07 -0700 Message-ID: Subject: Re: My incremental buildworlds started failing From: Navdeep Parhar To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Bjoern A. Zeeb" , Current , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 23:20:15 -0000 On Tue, Apr 16, 2013 at 10:06 AM, Tijl Coosemans wrote: > On 2013-04-16 18:39, Dimitry Andric wrote: > > On Apr 16, 2013, at 18:08, Bjoern A. Zeeb wrote: > >> I have been seeing this on incremental buildworlds for a day or two now? > >> ANyone can throw the cluebat at me? > > If that means building with NO_CLEAN=yes then the problem is r249484. > It creates a symlink: ln -fs ../include ${DESTDIR}/usr/lib/include > But if ${DESTDIR}/usr/lib/include already exists it creates > ${DESTDIR}/usr/include/include -> ../include. > > I'm thinking of reverting that commit. > Has this been sorted out? Not being able to buildworld with NO_CLEAN is a bit of a pain. Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 00:01:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E922A649 for ; Wed, 17 Apr 2013 00:01:07 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id A6C501F0C for ; Wed, 17 Apr 2013 00:01:07 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r3H011Xc024891; Tue, 16 Apr 2013 20:01:06 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <516DE63D.8070409@m5p.com> Date: Tue, 16 Apr 2013 20:01:01 -0400 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mark Johnston Subject: Re: After a source upgrade from 8.3-RELEASE to r249432 (HEAD) References: <516C5BE2.50005@m5p.com> <20130416005702.GA5006@gloom.uwaterloo.ca> In-Reply-To: <20130416005702.GA5006@gloom.uwaterloo.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 16 Apr 2013 20:01:06 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 00:01:08 -0000 On 04/15/13 20:57, Mark Johnston wrote: > On Mon, Apr 15, 2013 at 03:58:26PM -0400, George Mitchell wrote: >> >> It was pretty successful. All my 8.3 packages are still running very >> happily, though at some point I imagine I will have to update and >> recompile them. >> >> But ... >> >> When I press ENTER in the boot0 screen, I get the hyphen that will start >> spinning after a timeout and begin loading boot1 (which, as far as I >> know, I have not updated). boot1 (I think) presents me with a prompt >> that does not respond to key presses on the keyboard. It times out and >> continues loading anyway. At this stage, I am always presented with a >> manual mountroot: prompt, and I have to type "ufs:/dev/ada0s1a" to get >> any further. > > I ran into this too. It was caused by a problem in r249408 and is fixed > as of r249436. Updating your kernel to something beyond r249435 should > make this go away. > > -Mark > Yes, r249436 fixes the mountroot problem. -- George From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 00:16:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 107FD8C1; Wed, 17 Apr 2013 00:16:10 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-05.shaw.ca (smtp-out-05.shaw.ca [64.59.134.13]) by mx1.freebsd.org (Postfix) with ESMTP id BD6071F7F; Wed, 17 Apr 2013 00:16:09 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=7/EMZfWbaVtDMdTqnk9efwidrOfQb3DZMdpNhNw5Oc4= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=i5LUQIlrN4e3-3zU_18A:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-05.shaw.ca with ESMTP; 16 Apr 2013 18:16:53 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 99CD480; Tue, 16 Apr 2013 17:16:02 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3H0G2PN002625; Tue, 16 Apr 2013 17:16:02 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304170016.r3H0G2PN002625@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ivan Voras Subject: Re: Stack Overflow in GEOM In-Reply-To: Message from Ivan Voras of "Wed, 17 Apr 2013 01:01:55 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2013 17:16:02 -0700 Cc: geom@freebsd.org, "Ilya A. Arkhipov" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:16:10 -0000 In message , Ivan Voras writes: > On 17 April 2013 00:44, Cy Schubert wrote: > > > You were correct. Backing out r249508 in my tree resolves the panic on both > > hosts. > > Hi, > > Sorry about that - should be fixed by > http://svnweb.freebsd.org/base?view=revision&revision=249564 . > hey, no prob. Fetching it now. Thanks. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 02:28:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AA75C70 for ; Wed, 17 Apr 2013 02:28:16 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by mx1.freebsd.org (Postfix) with SMTP id C2C6B37D for ; Wed, 17 Apr 2013 02:28:15 +0000 (UTC) Received: from [98.139.212.146] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 02:28:09 -0000 Received: from [98.139.213.13] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 02:28:09 -0000 Received: from [127.0.0.1] by smtp113.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 02:28:09 -0000 X-Yahoo-Newman-Id: 311096.54644.bm@smtp113.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: wRuYFW8VM1nVDbLvYFU0Jn.MPZ7V_CxqTokBPp6NCIXKR21 IUhvGyIufVNxX2novMdnq6E4Gcg8UcDeoUkD6PGgyccVBxmK3Fb54l.A_urg ik_uAzrJNgt67wa7hit5f8UGxCbJWhUAwWUGN0O5Svf7qP23puDQOSkqNMbt BvCd7P9fm3kksQS2ffoKk2EOLsYEPxttiwuRstGN8AKK3CEmuM5UpSHzuaEu AREJCwRGqjkQ5aGIxvri5m2M7sokV9pllLR_CdvjklsLNWtXRrQyRu11IV56 DJs3LkFrAWJY4xaanCco5QqHz3cFHc4iICFhkm_KFxhiZeJ6fcHIzbN5XGyw JzdIUJl2M2pByt_GosF2JY55JqYRRDqHa58Sqp4XPIFM2FW7l0SCPfV7GkRI hELSy_DqCjGhMAneU3XJIr36AotYN6SHpnoiV4FZXw68syfv9_szieT3ISPb MpVJkoPRkeayv X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain) by smtp113.mail.bf1.yahoo.com with SMTP; 16 Apr 2013 19:28:09 -0700 PDT Message-ID: <516E08B7.7030807@FreeBSD.org> Date: Tue, 16 Apr 2013 21:28:07 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130324 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Johnston Subject: Re: DTrace gone quiet? References: <516DAD14.9020307@FreeBSD.org> <20130416205403.GA1409@gloom.sandvine.com> In-Reply-To: <20130416205403.GA1409@gloom.sandvine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 02:28:16 -0000 On 04/16/13 15:54, Mark Johnston wrote: > On Tue, Apr 16, 2013 at 12:57:08PM -0700, Navdeep Parhar wrote: >> I just upgraded my kernel and userspace to head (r249552) and I notice >> that DTrace doesn't output anything until I hit ctrl-c. All previous >> "hits" on the probe appear lost. For example: >> >> # dtrace -n 'fbt::ether_output:entry' >> dtrace: description 'fbt::ether_output:entry' matched 1 probe >> >> (No output here. I waited a long time before the ctrl-c and I know the >> system is actively transmitting and receiving Ethernet traffic). >> >> ^C >> CPU ID FUNCTION:NAME >> 9 29354 ether_output:entry >> 8 29354 ether_output:entry >> 8 29354 ether_output:entry >> 8 29354 ether_output:entry >> >> >> Can anyone confirm or contradict this on a recent HEAD (around r249552 >> in my case)? > Reverting r249367 and rebuilding libdtrace+the kernel fixes the problem > for me. > > -Mark Thanks for pointing culprit ! Unfortunately upstream merged many changes in the same commit so it's difficult to separate the specific change that is causing this. I reverted all the change in r249573. Regards, Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 03:04:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6D8B6CF for ; Wed, 17 Apr 2013 03:04:06 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm36-vm2.bullet.mail.bf1.yahoo.com (nm36-vm2.bullet.mail.bf1.yahoo.com [72.30.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5617A0 for ; Wed, 17 Apr 2013 03:04:06 +0000 (UTC) Received: from [98.139.212.153] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 03:04:00 -0000 Received: from [98.139.213.4] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 03:04:00 -0000 Received: from [127.0.0.1] by smtp104.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 03:04:00 -0000 X-Yahoo-Newman-Id: 822953.67861.bm@smtp104.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3V32jRQVM1mjKMuSh0h2WiMu3tFrY2TmEWPnQjo1Q1YoORK sjcYpjp1uH0SSDHLg3xiC_mUOocDy0yHUKr5TwPHWtvjTs6oEjmNbtqAes0g IOMWQcp7DPLZSQy.Zzh8oT.p5y8fbFWL8R16_qKca671PUhQxOERFEPGyCTB tFb82zFAD2sXbJW1R9Y7qoOvn8l.zB54p93noMmqNcG3brUOvBzCbnv7kH0v H8GdS9S_G8YvAdIkCLpIa4tELscwKfO_uEnNH68X3chLH4EuGZ3b1X5iIpKW g8dA4vPU40Uh07XhYm0jwdO5ONIX4AW.spFKzRs9CDV9km2JUPTdJ4LvXDFu Am9uiBL_ZOuQdbGX.7FcQK4jwdAyx1.e3JPa3XN.Q8bUXXdsDNeaOrprrMxJ .gkFDdqiFDMKo.eKQ7LAF4LTHuGtIybUJVmFRfN_pWrm26z1XpGJ5LmVWKtw 1JId5biInPHs8ztaRIWnvbJF0Z22VvASqDW8Eyi7nKkZntGxKFA1L6.SO5F9 5z.4a8B42QS7jz2yN7EhYmGiQUdN7hbrcWbgJ3hxrpkI_L8rzdCG6swmO8Fc dv14hU3C3OGUe76Q3GF_.gSS1ercEu7psI4uzevevdwRNfDVMr1snMboD2h_ FgD0.QA_aNOuZvq.vppHWgA6YLuOfJ2a6C2xqu6bI6SU- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp104.mail.bf1.yahoo.com with SMTP; 16 Apr 2013 20:04:00 -0700 PDT Message-ID: <516E111E.9040703@FreeBSD.org> Date: Tue, 16 Apr 2013 22:03:58 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130324 Thunderbird/17.0.4 MIME-Version: 1.0 To: Olli Hauer Subject: Re: Please test upcoming DTrace port mod_usdt for apache22 References: <516DBAB6.3040602@FreeBSD.org> In-Reply-To: <516DBAB6.3040602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 03:04:06 -0000 On 04/16/13 15:55, Olli Hauer wrote: > Hi, > > I've created together with Pedro Giffuni (pfg@) a new > DTrace apache port (www/mod_usdt). > We are interested in getting some more test results from > DTrace and apache users. > > A complete description is here: > http://dtrace.org/blogs/dap/2011/12/13/usdt-providers-redux/ > > shar file for mod_usdt can be found here: > http://people.freebsd.org/~ohauer/shar/mod_usdt_2013051601.shar > > Thanks, > olli Most of the work was done by Olli, I only added a -lelf to linking stage. We did find out that we still lack some important providers in FreeBSD so some of the examples won't work but it should still be useful. BTW, stuff like the NFS provider should not be difficult to finish but given that our implementation is not related to the Solaris one it does require at least adding probes to our code. Just something to investigate in the future ;). Cheers, Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 05:34:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5CC8364E; Wed, 17 Apr 2013 05:34:22 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1B98DB44; Wed, 17 Apr 2013 05:34:21 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1USL0d-0005yd-Cc; Wed, 17 Apr 2013 09:34:19 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=wS62jRt1HduYuzj4bJZYyfrsnQkNMRDP9JwZCM3ftHw=; b=pq0My69ibiQZFAQMgsiwinnOh0CC8Xc0Z8Vn6/TRHWDhVH8fjhQf+UjlXaMdS6Iv9x85CLbAOk8IfDKLbu4cCfiu4uYD4a3SlZ20rqH4sWGVaUKctNWwU0ru3yCoz/ESsEhtUw8eeKaR/o1gnpHmCpfdVepRCDY2peVxrXQBwxg=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1USKxR-00025i-Tt; Wed, 17 Apr 2013 05:31:03 +0000 From: Jan Beich To: Dimitry Andric Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ Date: Tue, 16 Apr 2013 22:31:36 -0700 References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1USKxR-00025i-Tt@internal.tormail.org> Cc: FreeBSD Current , "O. Hartmann" , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 05:34:22 -0000 Dimitry Andric writes: > On Apr 16, 2013, at 00:42, Jan Beich wrote: > >> "O. Hartmann" writes: >>> ./unistd.h:694:5: error: invalid token at start of a preprocessor >>> expression >>> #if @GNULIB_EUIDACCESS@ >>> ^ >>> 1 error generated. >> >> Maybe -O3 overoptimizes regex in libc e.g., >> >> $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' >> #if @GNULIB_EUIDACCESS@ >> >> $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' >> aaaaaaaaaaaaaaaaxxxaaaa > > How did you arrive at this result? 1/ chroot into poudriere jail for /head amd64 2/ echo CFLAGS+=-O3 >> /etc/make.conf 3/ make -j2 (in /usr/src/lib/libc) 4/ prepend LD_LIBRARY_PATH=. before sed(1) 5/ rebuild regcomp.o, regcomp.So with -O2 to confirm > I have recompiled both libc and sed > with -O3, but it works just fine here. > Maybe -march=native is the clue, so which kind of CPU do you have? sse2 is available on amd64 even without -march=. But I can't reproduce the issue on i386 even with -march=native. > To see what CPU llvm detects, try: > > tblgen -version | grep CPU Host CPU: penryn > > Note that -O3 turns on clang's vectorizer, so you might have run into an > optimizer bug, or some kind of undefined behavior which now falls over. My luck is poor even with -O2 e.g., firefox20 crash on stackoverflow.com [New LWP 101222] [New Thread 801b02400 (LWP 101222)] [New Thread 81060e800 (LWP 101372 StreamTrans #1)] [New Thread 810ee8800 (LWP 101373 DOM Worker)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 801b02400 (LWP 101222)] PodCopy (dst=, nelem=, src=, dst=, src=, nelem=) at ../../../js/src/jsutil.h:238 238 PodAssign(dst, src); (gdb) bt #0 PodCopy (dst=, nelem=, src=, dst=, src=, nelem=) at ../../../js/src/jsutil.h:238 #1 getCallFrame (cx=, flags=, fun=, report=(unknown: 2266652928), this=, args=..., script=...) at ../../../js/src/vm/Stack-inl.h:454 #2 getFixupFrame (cx=, initial=, fun=, ncode=, dummy=0, report=, this=, cx=, report=, args=..., fun=, script=..., ncode=, initial=, stackLimit=) at ../../../js/src/vm/Stack-inl.h:513 #3 js::mjit::stubs::FixupArity (f=..., nactual=4294945312) at /wrkdirs/usr/ports/www/firefox/work/mozilla-release/js/src/methodjit/InvokeHelpers.cpp:213 #4 0x00000008019c48c2 in ?? () #5 0x00000008019b56b8 in ?? () #6 0x0000000000000001 in ?? () #7 0x0000000000000000 in ?? () > > -Dimitry From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 09:15:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 080B0EDD; Wed, 17 Apr 2013 09:15:22 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8D175E; Wed, 17 Apr 2013 09:15:20 +0000 (UTC) Received: from cpsps-ews08.kpnxchange.com ([10.94.84.175]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 17 Apr 2013 11:14:10 +0200 Received: from CPSMTPM-CMT101.kpnxchange.com ([195.121.3.17]) by cpsps-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 17 Apr 2013 11:14:10 +0200 Received: from sun.offermans.rompen.nl ([77.170.60.162]) by CPSMTPM-CMT101.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Wed, 17 Apr 2013 11:14:09 +0200 Received: from squid (squid.vpn.offrom.nl [10.168.0.72]) by sun.offermans.rompen.nl (8.14.5/8.14.4) with ESMTP id r3H9E8n1032889; Wed, 17 Apr 2013 11:14:09 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid with local (Exim 4.72) (envelope-from ) id 1USORM-00062i-Bh; Wed, 17 Apr 2013 11:14:08 +0200 Date: Wed, 17 Apr 2013 11:14:08 +0200 From: Willy Offermans To: Brooks Davis Subject: Re: control of order of inet devices Message-ID: <20130417091408.GG3480@vpn.offrom.nl> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130416154423.GD98205@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 17 Apr 2013 09:14:09.0957 (UTC) FILETIME=[EB7A4D50:01CE3B4B] X-RcptDomain: freebsd.org Cc: Willy Offermans , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 09:15:22 -0000 Hello Brooks, On Tue, Apr 16, 2013 at 10:44:23AM -0500, Brooks Davis wrote: > On Tue, Apr 16, 2013 at 03:56:21PM +0200, Willy Offermans wrote: > > Dear FreeBSD friends, > > > > How can I control the order of the network devices in FreeBSD. > > > > For example, the command ifconfig lists the network devices: > > > > pcn0: flags=8802 metric 0 mtu 1500 > > options=80000 > > ether 00:0c:46:ea:2b:32 > > nd6 options=29 > > media: Ethernet 100baseFX > > status: no carrier > > rl0: flags=8843 metric 0 mtu 1500 > > options=2008 > > ether 00:11:6b:99:7c:5a > > inet XXX.XXX.24.4 netmask 0xffffff80 broadcast 137.226.24.127 > > inet6 fe80::211:6bff:fe99:7c5a%rl0 prefixlen 64 scopeid 0x4 > > nd6 options=29 > > media: Ethernet autoselect (100baseTX ) > > status: active > > nfe0: flags=8802 metric 0 mtu 1500 > > options=82008 > > ether 00:1b:fc:df:a1:33 > > nd6 options=29 > > media: Ethernet autoselect (none) > > status: no carrier > > plip0: flags=8810 metric 0 mtu 1500 > > nd6 options=29 > > lo0: flags=8049 metric 0 mtu 16384 > > options=600003 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 > > inet 127.0.0.1 netmask 0xff000000 > > nd6 options=21 > > tap0: flags=8843 metric 0 mtu 1500 > > options=80000 > > ether 00:22:19:10:8d:bb > > inet XXX.XXX.24.19 netmask 0xffffffff broadcast 137.226.24.19 > > inet6 fe80::2bd:83ff:fe68:7200%tap0 prefixlen 64 scopeid 0x8 > > nd6 options=21 > > media: Ethernet autoselect > > status: no carrier > > > > pcn0 being first. However, I would like tap0 being first and of course > > without any output ordering trick. > > The order is dictated by the order the drivers are probed by the kernel. > When the devices are created they are added to a linked list. There is > no practical way to control the order and it has little or no effect. > > -- Brooks This is what I read in some of the articles or handbook as well. Can I reorder this linked list? Can I control the order by creating the kernel and reordering the inclusion of the device drivers? I am aware that the request sounds silly, but I have a third party program which checks its licence against the first inet device. Since I have added a new inet controller, the sequence has changed. Of course I ask for a new licence, but they want to charge me for that and I do not see any reason for that. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy ************************************* W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 09:27:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 124894D2 for ; Wed, 17 Apr 2013 09:27:53 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id DC0037E4 for ; Wed, 17 Apr 2013 09:27:52 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id f27so1241482iae.30 for ; Wed, 17 Apr 2013 02:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4Y5s+sZ0GDr1H0p1YzOmKXNmHZ8Ggda7yKj/GE2WmrE=; b=UKtovfGJeVdFiVhTHsbduQ7ZVvLXigMU1DBYo1C2sSRv38x1hJudSEr7iVCOUy3KkS /PONPGyLHaFLZgEvoRPSl77cmqeDKfkQoOmJwLCobFtkoiKEEW7PrHxAyWlC24f+QB8/ foaVsZdhvC2mLVeO0Q6sUpshcPsgiwgnwG4Np+2Z+jBGW3+4UIzjAHBpZnZRZtN31kyM se7PHniL3b1TKsDwuHuMiiyNjaq2A4YYEmAGywz+45icuexodhG6IkNWdtpHrlB4Mlyi 5G2eMu2LOsI/D9MXSv8UDFvuHvUfapv6XgxkCtK9LUtwEX9m2vd1XdG1Oa3OIHSJMK8v QVqg== X-Received: by 10.42.40.11 with SMTP id j11mr3149446ice.50.1366190872559; Wed, 17 Apr 2013 02:27:52 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id c14sm6311627ign.2.2013.04.17.02.27.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 02:27:51 -0700 (PDT) Message-ID: <516E6B10.2080000@gmail.com> Date: Wed, 17 Apr 2013 04:27:44 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: control of order of inet devices References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130417091408.GG3480@vpn.offrom.nl> In-Reply-To: <20130417091408.GG3480@vpn.offrom.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 09:27:53 -0000 On 4/17/2013 4:14 AM, Willy Offermans wrote: > This is what I read in some of the articles or handbook as well. Can I > reorder this linked list? Can I control the order by creating the kernel > and reordering the inclusion of the device drivers? > > I am aware that the request sounds silly, but I have a third party program > which checks its licence against the first inet device. Since I have added > a new inet controller, the sequence has changed. Of course I ask for a new > licence, but they want to charge me for that and I do not see any reason > for that. Load old inet devices like normal, in loader.conf. Then load the new device driver before networking, after rc's started. If it'd because of probe order, then you might just have to control the probe order the hard way. If the program's calling ifconfig itself, you could write a wrapper to resort the output. And call a lawyer, getting a new ethernet card shouldn't void a license. From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 10:07:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79D3DFE3; Wed, 17 Apr 2013 10:07:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 24BBD9F6; Wed, 17 Apr 2013 10:07:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::dc79:2881:589:7d77] (unknown [IPv6:2001:7b8:3a7:0:dc79:2881:589:7d77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4646E5C45; Wed, 17 Apr 2013 12:07:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ From: Dimitry Andric In-Reply-To: <1USKxR-00025i-Tt@internal.tormail.org> Date: Wed, 17 Apr 2013 12:07:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> <1USKxR-00025i-Tt@internal.tormail.org> To: Jan Beich X-Mailer: Apple Mail (2.1503) Cc: FreeBSD Current , "O. Hartmann" , FreeBSD ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 10:07:54 -0000 On Apr 17, 2013, at 07:31, Jan Beich wrote: > Dimitry Andric writes: > On Apr 16, 2013, at 00:42, Jan Beich wrote: ... >>> Maybe -O3 overoptimizes regex in libc e.g., >>>=20 >>> $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' >>> #if @GNULIB_EUIDACCESS@ >>>=20 >>> $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed 's/aaaaaaaaaaaaxxxaaaa//' >>> aaaaaaaaaaaaaaaaxxxaaaa >>=20 >> How did you arrive at this result? >=20 > 1/ chroot into poudriere jail for /head amd64 > 2/ echo CFLAGS+=3D-O3 >> /etc/make.conf > 3/ make -j2 (in /usr/src/lib/libc) > 4/ prepend LD_LIBRARY_PATH=3D. before sed(1) > 5/ rebuild regcomp.o, regcomp.So with -O2 to confirm I have been able to reproduce this on amd64, with -O3, but not on i386. It seems regcomp() is either miscompiled at -O3, or it contains some bug triggered only by the vectorizer. I am still investigating. > My luck is poor even with -O2 e.g., firefox20 crash on = stackoverflow.com >=20 > [New LWP 101222] > [New Thread 801b02400 (LWP 101222)] > [New Thread 81060e800 (LWP 101372 StreamTrans #1)] > [New Thread 810ee8800 (LWP 101373 DOM Worker)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 801b02400 (LWP 101222)] > PodCopy (dst=3D, nelem=3D, > src=3D, dst=3D, src=3D, > nelem=3D) at ../../../js/src/jsutil.h:238 > 238 PodAssign(dst, src); > (gdb) bt > #0 PodCopy (dst=3D, nelem=3D, > src=3D, dst=3D, src=3D, > nelem=3D) at ../../../js/src/jsutil.h:238 > #1 getCallFrame (cx=3D, flags=3D, = fun=3D, > report=3D(unknown: 2266652928), this=3D, args=3D..., = script=3D...) > at ../../../js/src/vm/Stack-inl.h:454 > #2 getFixupFrame (cx=3D, initial=3D, > fun=3D, ncode=3D, dummy=3D0, = report=3D, > this=3D, cx=3D, report=3D, args=3D..., > fun=3D, script=3D..., ncode=3D, > initial=3D, stackLimit=3D) > at ../../../js/src/vm/Stack-inl.h:513 > #3 js::mjit::stubs::FixupArity (f=3D..., nactual=3D4294945312) > at = /wrkdirs/usr/ports/www/firefox/work/mozilla-release/js/src/methodjit/Invok= eHelpers.cpp:213 > #4 0x00000008019c48c2 in ?? () > #5 0x00000008019b56b8 in ?? () > #6 0x0000000000000001 in ?? () > #7 0x0000000000000000 in ?? () This is a completely different issue. Is there any way you can reduce the test case? Or maybe upstream has already fixed it? From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 19:19:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2180744E; Wed, 17 Apr 2013 19:19:13 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 81794AC; Wed, 17 Apr 2013 19:19:12 +0000 (UTC) Message-ID: <516EF507.6040309@FreeBSD.org> Date: Wed, 17 Apr 2013 15:16:23 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130408 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@ References: <1365877246.2093.20.camel@thor.walstatt.dyndns.org> <1URs5b-000B9U-A2@internal.tormail.org> <1USKxR-00025i-Tt@internal.tormail.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "O. Hartmann" , FreeBSD ports , Jan Beich X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 19:19:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-04-17 06:07:47 -0400, Dimitry Andric wrote: > On Apr 17, 2013, at 07:31, Jan Beich wrote: >> Dimitry Andric writes: On Apr 16, 2013, at >> 00:42, Jan Beich wrote: > ... >>>> Maybe -O3 overoptimizes regex in libc e.g., >>>> >>>> $ echo '#if @GNULIB_EUIDACCESS@' | sed >>>> 's/@GNULIB_EUIDACCESS@/0/' #if @GNULIB_EUIDACCESS@ >>>> >>>> $ echo 'aaaaaaaaaaaaaaaaxxxaaaa' | sed >>>> 's/aaaaaaaaaaaaxxxaaaa//' aaaaaaaaaaaaaaaaxxxaaaa >>> >>> How did you arrive at this result? >> >> 1/ chroot into poudriere jail for /head amd64 2/ echo CFLAGS+=-O3 >> >> /etc/make.conf 3/ make -j2 (in /usr/src/lib/libc) 4/ prepend >> LD_LIBRARY_PATH=. before sed(1) 5/ rebuild regcomp.o, regcomp.So >> with -O2 to confirm > > I have been able to reproduce this on amd64, with -O3, but not on > i386. It seems regcomp() is either miscompiled at -O3, or it > contains some bug triggered only by the vectorizer. I am still > investigating. ... With "-fno-vectorize", this problem doesn't seem to happen. FYI, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbvUHAAoJECXpabHZMqHOekEIAIml2te9436LzTFsr794y82E Vmytl95H+vW9Nj0qK5X/DkB/0MSepL5FZqKF5CSNTXFoNJoVFewYRIH/H5oICSpZ jfS4evF9i2mEDOScTyC/XaucvcVWupLE9Kf7FHEk5YIhDMs4r4nzwMFGkzffEqPK yLkV/Cpc8xjvi28OuXd1KaPIcX3S8Z9vEmWPyljtseRv9WlC5gT44fSz18hmqYmv fWSiML4YKKkDRAPOCy/Shpf5QUcygOul7Jz8RiDBx3O4R5goGW8Ee8Napn7UulSL nAXTHy8dcSbiAqqPKeXhmZGPCotj++P9s3jEvunOxL7lvrdjfy3WtGedcp02ia8= =jwYS -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Apr 17 20:01:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5822B30A for ; Wed, 17 Apr 2013 20:01:23 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0E9287 for ; Wed, 17 Apr 2013 20:01:22 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3HK1Rps030752; Wed, 17 Apr 2013 15:01:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3HK1Rh2030751; Wed, 17 Apr 2013 15:01:27 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Apr 2013 15:01:27 -0500 From: Brooks Davis To: Joshua Isom Subject: Re: control of order of inet devices Message-ID: <20130417200127.GB30583@lor.one-eyed-alien.net> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130417091408.GG3480@vpn.offrom.nl> <516E6B10.2080000@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <516E6B10.2080000@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 20:01:23 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2013 at 04:27:44AM -0500, Joshua Isom wrote: > On 4/17/2013 4:14 AM, Willy Offermans wrote: > > This is what I read in some of the articles or handbook as well. Can I > > reorder this linked list? Can I control the order by creating the kernel > > and reordering the inclusion of the device drivers? > > > > I am aware that the request sounds silly, but I have a third party prog= ram > > which checks its licence against the first inet device. Since I have ad= ded > > a new inet controller, the sequence has changed. Of course I ask for a = new > > licence, but they want to charge me for that and I do not see any reason > > for that. >=20 > Load old inet devices like normal, in loader.conf. Then load the new=20 > device driver before networking, after rc's started. If it'd because of= =20 > probe order, then you might just have to control the probe order the=20 > hard way. If the program's calling ifconfig itself, you could write a=20 > wrapper to resort the output. And call a lawyer, getting a new ethernet= =20 > card shouldn't void a license. It wouldn't be particularly hard to influence the sorting of the list if you're willing to modify the if_attach_internal() function and always insert devices with that name at the beginning. It just doesn't seem very general purpose so I'd have a hard time considering including it. -- Brooks --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRbv+WXY6L6fI4GtQRAosYAKCtBpxq6brNhJv24VJtxOQN1haZ/wCgoBPG N3JUS3PY3pDTc9qHFRT7LAc= =zx/1 -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 03:49:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8EB249E0 for ; Thu, 18 Apr 2013 03:49:36 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 677F5874 for ; Thu, 18 Apr 2013 03:49:36 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id w21so2144835iac.9 for ; Wed, 17 Apr 2013 20:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=GVIFR4+erPzdAaKrw3fHUuBOIaphdFwVzrw4vzwQges=; b=E2XcZVI9BcZs7kijJ9yPYkdEzcFJE1UowyDuoj5+CAEJN+m+LanZJZ0EjgyKjXaDgc 8y1PJpLxBKPIj2YfMji2xirAQDbwmJuPHl+lfSeXesStB4bLBWwHZIx/fq1EI1UvKYDh 958nywaIePN2y2SBMOexjXJiSRz2ZF9gu0Etyz/F1ies3bPH2uGTmLWrV822VebogPGp 8KEazUlYtqmm0PVdwISzBSzxcDgDPG6lqxV40qKOi3dZtA80f3kTvNoFrJAC7PA/ddFm b6WcHjCWyADZViP068G+KXWc3/ghu/yWxohMDTDRBoIvldnombvIXBVFVkObA2NEccTq DFGA== MIME-Version: 1.0 X-Received: by 10.50.100.167 with SMTP id ez7mr12160844igb.3.1366256976105; Wed, 17 Apr 2013 20:49:36 -0700 (PDT) Received: by 10.43.9.138 with HTTP; Wed, 17 Apr 2013 20:49:36 -0700 (PDT) Date: Wed, 17 Apr 2013 20:49:36 -0700 Message-ID: Subject: pkg_add not working From: Neel Natu To: "current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 03:49:36 -0000 Hi, I am running HEAD and recently started getting errors on pkg_add. uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:25:06 PDT 2013 > pkg_add -r sudo Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch ' ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz' by URL This used to work pretty well until a few days ago. Any clues? best Neel From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 03:59:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8FFFC65 for ; Thu, 18 Apr 2013 03:59:26 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9E28E0 for ; Thu, 18 Apr 2013 03:59:26 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ib11so1978792vcb.20 for ; Wed, 17 Apr 2013 20:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wnmoQ2v2nI6UDnLD/ug6w3Crd7935lsOtQwTcpE1VCA=; b=mbm0KvNGgAnRIQTsV7VVIpkB0JBQmdhMOBgNqCmVAdMQSVpaTp8+yjhAaS2YLzQSEE 0mQE0V3jpoY0bILpmgSrnGjVAAl5+Ugg3YNaHB6YzGsDiBsWTnTQki+Y6Oah8A0gRmxO Ir73+0sLQVC1ciuqieVszn/sot7LtD29Zax78v9yh68/rXvOJNs9zc+KStfeNhf2vbQk qdC5hRof4bL7iw+QSganWsGDHcJTR5regdOrYn0Qued1zDpd277RO+J4xCWqeVr6A5vL yRfklNBya1owlA60Eon93ZSkEikrY++4sBR8MIVCKHp0A4uNb049ucrnoAJ6QZQbOfKk IN3g== MIME-Version: 1.0 X-Received: by 10.220.242.73 with SMTP id lh9mr6924409vcb.49.1366257565771; Wed, 17 Apr 2013 20:59:25 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Wed, 17 Apr 2013 20:59:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Apr 2013 20:59:25 -0700 Message-ID: Subject: Re: pkg_add not working From: Mehmet Erol Sanliturk To: Neel Natu Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 03:59:26 -0000 On Wed, Apr 17, 2013 at 8:49 PM, Neel Natu wrote: > Hi, > > I am running HEAD and recently started getting errors on pkg_add. > > uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:25:06 > PDT 2013 > > > pkg_add -r sudo > Error: Unable to get > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz > : > File unavailable (e.g., file not found, no access) > pkg_add: unable to fetch ' > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz > ' > by URL > > This used to work pretty well until a few days ago. Any clues? > > best > Neel > The "packages-10-current" is deleted from ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/ It seems that , it will be reconstructed from scratch . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 04:55:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AACBF3EE; Thu, 18 Apr 2013 04:55:08 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 7785EA68; Thu, 18 Apr 2013 04:55:08 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k5so2820856iea.18 for ; Wed, 17 Apr 2013 21:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=76FX2L3sai35IuqA6aXzIvIij1D6A2Qoud/nICSaSeE=; b=f53SX2tkMQhqAGx9OkzYZJLaycOphg7kBD/DeSMM6OfWTu9bQexTjpFDjhEAJeWgMq LXOkhduVWh4j+m9CmzCbNPV4uasTSTRYDWOxwrlMfquql5lTC8SZu+MkL8z4DKOa4pa0 iTICVUCFIRdhgNhpw458AECiRe0D6bxFqiOIoXQROb7dqN6HrkzIogwEch8PTG1LT9Xd coPfuN99ooejsckOPHdtOKg3yyfPL/fDL0FLpFVZWnHvMMwekrqGSDLNm9LyLEu0+M1a MfTn7xa4KADF8weoL4xQaJz8KhdOO7mUQbTKhZ/YZhczScpXboSonCAGtR1k0mzca/sb FlYQ== MIME-Version: 1.0 X-Received: by 10.50.20.69 with SMTP id l5mr6029435ige.106.1366260908125; Wed, 17 Apr 2013 21:55:08 -0700 (PDT) Received: by 10.50.57.84 with HTTP; Wed, 17 Apr 2013 21:55:07 -0700 (PDT) In-Reply-To: <20130417091408.GG3480@vpn.offrom.nl> References: <20130416135621.GE3286@vpn.offrom.nl> <20130416154423.GD98205@lor.one-eyed-alien.net> <20130417091408.GG3480@vpn.offrom.nl> Date: Wed, 17 Apr 2013 23:55:07 -0500 Message-ID: Subject: Re: control of order of inet devices From: Scot Hetzel To: Willy@offermans.rompen.nl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , freebsd-hardware@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 04:55:08 -0000 On Wed, Apr 17, 2013 at 4:14 AM, Willy Offermans wrote: > Hello Brooks, > > On Tue, Apr 16, 2013 at 10:44:23AM -0500, Brooks Davis wrote: > > On Tue, Apr 16, 2013 at 03:56:21PM +0200, Willy Offermans wrote: > > > Dear FreeBSD friends, > > > > > > How can I control the order of the network devices in FreeBSD. > > > > > > For example, the command ifconfig lists the network devices: > > > > > > pcn0: flags=8802 metric 0 mtu 1500 > > > options=80000 > > > ether 00:0c:46:ea:2b:32 > > > nd6 options=29 > > > media: Ethernet 100baseFX > > > status: no carrier > > > rl0: flags=8843 metric 0 mtu > 1500 > > > options=2008 > > > ether 00:11:6b:99:7c:5a > > > inet XXX.XXX.24.4 netmask 0xffffff80 broadcast 137.226.24.127 > > > inet6 fe80::211:6bff:fe99:7c5a%rl0 prefixlen 64 scopeid 0x4 > > > nd6 options=29 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > nfe0: flags=8802 metric 0 mtu 1500 > > > options=82008 > > > ether 00:1b:fc:df:a1:33 > > > nd6 options=29 > > > media: Ethernet autoselect (none) > > > status: no carrier > > > plip0: flags=8810 metric 0 mtu 1500 > > > nd6 options=29 > > > lo0: flags=8049 metric 0 mtu 16384 > > > options=600003 > > > inet6 ::1 prefixlen 128 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 > > > inet 127.0.0.1 netmask 0xff000000 > > > nd6 options=21 > > > tap0: flags=8843 metric 0 mtu > 1500 > > > options=80000 > > > ether 00:22:19:10:8d:bb > > > inet XXX.XXX.24.19 netmask 0xffffffff broadcast 137.226.24.19 > > > inet6 fe80::2bd:83ff:fe68:7200%tap0 prefixlen 64 scopeid 0x8 > > > nd6 options=21 > > > media: Ethernet autoselect > > > status: no carrier > > > > > > pcn0 being first. However, I would like tap0 being first and of course > > > without any output ordering trick. > > > > The order is dictated by the order the drivers are probed by the kernel. > > When the devices are created they are added to a linked list. There is > > no practical way to control the order and it has little or no effect. > > > > -- Brooks > > This is what I read in some of the articles or handbook as well. Can I > reorder this linked list? Can I control the order by creating the kernel > and reordering the inclusion of the device drivers? > > I am aware that the request sounds silly, but I have a third party program > which checks its licence against the first inet device. Since I have added > a new inet controller, the sequence has changed. Of course I ask for a new > licence, but they want to charge me for that and I do not see any reason > for that. > What information did you give them when you registered that software? Was it just the MAC address of tap0? If it was just the MAC address of tap0, you could try changing the MAC address of pcn0 to the MAC address of tap0: echo 'ifconfig pcn0 ether 00:22:19:10:8d:bb' >/etc/start_if.pcn0 echo 'ifconfig tap0 ether 00:22:19:10:8d:bc' >/etc/start_if.tap0 From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 06:38:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9A25D09 for ; Thu, 18 Apr 2013 06:38:13 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 82DD9E45 for ; Thu, 18 Apr 2013 06:38:13 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t57so1886238wey.32 for ; Wed, 17 Apr 2013 23:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=KDYq1Y0f2VxdGr7kUgOBY0aTGlwdIMCsAQFO+kLRFbU=; b=ISBovrtmJ1yvdT+yuNyAWCFd4lRzz0Ej+KKHfqAUczcPV8CnoFFl5t85lv9G/VYxDT 8aTRW/KAQKc+PLBsFr+6tfxVfxlLSi8VILfqUX1hje9IiazX9Gy1VQ1265nc21K/Wwk/ ddI8o/eFaZPxjgqUTjK91GhnK8gdJA0IF8y7OSeQw2wGcbylB6jq+TXvXGqsfuBISFXL +F1NXsvz/nVSxpYN/78aVVexsoR2Nio34JyuXEDrYcV/Fq52TuzWazbWJo3/jw7YTRmI 2h4jjx5xRPgioOHjxkZJD3pY2U8iOZuc5cEnYWY1yAQQImjifRf+tbfyLYbuuz0eSjoz WVcQ== X-Received: by 10.194.104.168 with SMTP id gf8mr16081166wjb.58.1366267092780; Wed, 17 Apr 2013 23:38:12 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id t7sm29446063wij.2.2013.04.17.23.38.11 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Apr 2013 23:38:11 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 18 Apr 2013 08:38:09 +0200 From: Baptiste Daroussin To: Mehmet Erol Sanliturk Subject: Re: pkg_add not working Message-ID: <20130418063809.GF90159@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vA66WO2vHvL/CRSR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "current@freebsd.org" , Neel Natu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 06:38:14 -0000 --vA66WO2vHvL/CRSR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2013 at 08:59:25PM -0700, Mehmet Erol Sanliturk wrote: > On Wed, Apr 17, 2013 at 8:49 PM, Neel Natu wrote: >=20 > > Hi, > > > > I am running HEAD and recently started getting errors on pkg_add. > > > > uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:2= 5:06 > > PDT 2013 > > > > > pkg_add -r sudo > > Error: Unable to get > > > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Lates= t/sudo.tbz > > : > > File unavailable (e.g., file not found, no access) > > pkg_add: unable to fetch ' > > > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Lates= t/sudo.tbz > > ' > > by URL > > > > This used to work pretty well until a few days ago. Any clues? > > > > best > > Neel > > >=20 >=20 > The "packages-10-current" > is deleted from >=20 > ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/ >=20 >=20 > It seems that , it will be reconstructed from scratch . >=20 >=20 There is high probabilty that it won't, pkg_add is deprecated, and current = has switch to pkgng by default for a while now. given we have to rebuild all the packages from scratch, there is a very high level of chance only the one respecting the default will be built now (meaning pkgng) regards, Bapt --vA66WO2vHvL/CRSR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFvlNEACgkQ8kTtMUmk6Ezo7ACgvFt14dLTLLYdDdj2qAmcSUi7 im8AoLDPM+lR6pkjN/p6yDGFDcoEeBd0 =6vkB -----END PGP SIGNATURE----- --vA66WO2vHvL/CRSR-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 07:49:47 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9299DCA1 for ; Thu, 18 Apr 2013 07:49:47 +0000 (UTC) (envelope-from davidxu@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 84C2610D; Thu, 18 Apr 2013 07:49:47 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3I7nkKQ078386; Thu, 18 Apr 2013 07:49:47 GMT (envelope-from davidxu@freebsd.org) Message-ID: <516FA5B1.2040202@freebsd.org> Date: Thu, 18 Apr 2013 15:50:09 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130416 Thunderbird/17.0.5 MIME-Version: 1.0 To: Oliver Pinter Subject: Re: swapcontext rewrite broke some software References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 07:49:47 -0000 On 2013/04/16 21:24, Oliver Pinter wrote: > Hi! > > After this commit: > > commit ac0cfc7fcb1b51ee6aeacfd676fa6dfbe11eefb5 > Author: davidxu > Date: Wed Apr 10 02:40:03 2013 +0000 > > swapcontext wrapper can not be implemented in C, the stack pointer saved in > the context becomes invalid when the function returns, same as setjmp, > it must be implemented in assemble language, see discussions in PR > misc/177624. > > Some* software not found the swapcontext functions after this commit. > Please add a sentence to UPDATING file and/or bump the > __FreeBSD_version to reflect this change. > > > * qemu > Hi, The change is reverted. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 11:59:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E047104 for ; Thu, 18 Apr 2013 11:59:50 +0000 (UTC) (envelope-from shonnur@chelsio.com) Received: from stargate.chelsio.com (stargate.chelsio.com [67.207.112.58]) by mx1.freebsd.org (Postfix) with ESMTP id 15E60805 for ; Thu, 18 Apr 2013 11:59:49 +0000 (UTC) Received: from maui.asicdesigners.com (maui.asicdesigners.com [10.192.180.15]) by stargate.chelsio.com (8.13.1/8.13.1) with SMTP id r3IBxnNv026185 for ; Thu, 18 Apr 2013 04:59:49 -0700 Received: from corona.asicdesigners.com ([10.192.160.6]) by maui.asicdesigners.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Apr 2013 04:59:49 -0700 Received: from NICE.asicdesigners.com (10.192.160.7) by corona.asicdesigners.com (10.192.160.6) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 18 Apr 2013 04:59:49 -0700 Received: from NICE.asicdesigners.com ([fe80::51b2:ba95:9d72:babc]) by nice.asicdesigners.com ([fe80::51b2:ba95:9d72:babc%15]) with mapi id 14.02.0247.003; Thu, 18 Apr 2013 04:59:49 -0700 From: Sreenivasa Honnur To: current Subject: IPv6 bind fails with 49 (#define EADDRNOTAVAIL 49 /* Can't assign requested address */) Thread-Topic: IPv6 bind fails with 49 (#define EADDRNOTAVAIL 49 /* Can't assign requested address */) Thread-Index: AQHOPCw5ojEwBJmsCkWYZBpofKkENQ== Date: Thu, 18 Apr 2013 11:59:48 +0000 Message-ID: References: <516FA5B1.2040202@freebsd.org> In-Reply-To: <516FA5B1.2040202@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.190.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 18 Apr 2013 11:59:49.0505 (UTC) FILETIME=[3A52B710:01CE3C2C] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 11:59:50 -0000 SSBoYXZlIGEgaXB2NiBpbnRlcmZhY2UocGluZzYgdG8gYSByZW1vdmUgaXB2NiB3b3Jrcykgd2hl biBJIHRyeSB0byBiaW5kIHRvIHRoaXMgYWRkcmVzcyB0aHJvdWdoIGEgc29ja2V0IHByb2dyYW0g InNvYmluZCIgZmFpbHMgd2l0aCAiNDkiIGFzIHJldHVybiB2YWx1ZS4gSWYgSSBnaXZlICJzYWRk cjYuc2luNl9hZGRyID0gIGluNmFkZHJfYW55OyIgc29iaW5kIHdvcmtzLg0KDQpBbnkgaWRlYSB3 aGF0IGNvdWxkIGJlIGdvaW5nIHdyb25nIGhlcmU/IA0KDQpyb3VuZGhheSMgaWZjb25maWcgY3hn YmUxDQpjeGdiZTE6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxU SUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwDQogICAgICAgIG9wdGlvbnM9NmMwN2JiPFJYQ1NVTSxU WENTVU0sVkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsSlVNQk9fTVRVLFZMQU5fSFdDU1VNLFRTTzQs VFNPNixMUk8sVkxBTl9IV1RTTyxMSU5LU1RBVEUsUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+DQog ICAgICAgIGV0aGVyIDAwOjA3OjQzOjExOjg5Ojg4DQogICAgICAgIGluZXQ2IDIwMTA6OjEwMiBw cmVmaXhsZW4gNjQNCiAgICAgICAgaW5ldDYgZmU4MDo6MjA3OjQzZmY6ZmUxMTo4OTg4JWN4Z2Jl MSBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweGQNCiAgICAgICAgbmQ2IG9wdGlvbnM9MjE8UEVSRk9S TU5VRCxBVVRPX0xJTktMT0NBTD4NCiAgICAgICAgbWVkaWE6IEV0aGVybmV0IDEwR2Jhc2UtU1Ig PGZ1bGwtZHVwbGV4Pg0KICAgICAgICBzdGF0dXM6IGFjdGl2ZQ0Kcm91bmRoYXkjIHBpbmc2IDIw MTA6OjEwMQ0KUElORzYoNTY9NDArOCs4IGJ5dGVzKSAyMDEwOjoxMDIgLS0+IDIwMTA6OjEwMQ0K MTYgYnl0ZXMgZnJvbSAyMDEwOjoxMDEsIGljbXBfc2VxPTAgaGxpbT02NCB0aW1lPTAuOTUwIG1z DQoxNiBieXRlcyBmcm9tIDIwMTA6OjEwMSwgaWNtcF9zZXE9MSBobGltPTY0IHRpbWU9MC4xNTgg bXMNCl5DDQotLS0gMjAxMDo6MTAxIHBpbmc2IHN0YXRpc3RpY3MgLS0tDQoyIHBhY2tldHMgdHJh bnNtaXR0ZWQsIDIgcGFja2V0cyByZWNlaXZlZCwgMC4wJSBwYWNrZXQgbG9zcw0Kcm91bmQtdHJp cCBtaW4vYXZnL21heC9zdGQtZGV2ID0gMC4xNTgvMC41NTQvMC45NTAvMC4zOTYgbXMNCg0KDQoN CkNvZGU6DQo9PT09PQ0Kew0KICAgICAgICAgICAgcnYgPSBzb2NyZWF0ZShBRl9JTkVUNiwgJnNv Y2ssIFNPQ0tfU1RSRUFNLCBJUFBST1RPX1RDUCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGQtPnRkX3VjcmVkLCB0ZCk7DQoNCiAgICAgICAgICAgICAgICBpZiAocnYgIT0gMCkg ew0KICAgICAgICAgICAgICAgICAgICAgICAgb3NfbG9nX2Vycm9yKCJzb2NrIGNyZWF0ZSBpcHY2 ICVzIGZhaWxlZCAlZC5cbiIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdGJ1ZiwgcnYpOw0KICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQogICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgZmFtaWx5ID0gc2FkZHI2LnNpbjZfZmFt aWx5ID0gQUZfSU5FVDY7DQogICAgaW5ldF9wdG9uKEFGX0lORVQ2LCAiMjAxMDo6MTAyIiwgJnNh ZGRyNi5zaW42X2FkZHIpOw0KICAgICAgICAgICAgICAgIHNhZGRyNi5zaW42X3BvcnQgPSBodG9u cyhlcC0+cG9ydCk7DQogICAgICAgICAgICAgICAgc2FkZHI2LnNpbjZfbGVuID0gc2l6ZW9mKHN0 cnVjdCBzb2NrYWRkcl9pbjYpOw0KDQogICAgICAgICAgICAgICAgcnYgPSBzb2JpbmQoc29jaywg KHN0cnVjdCBzb2NrYWRkciAqKSZzYWRkcjYsIHRkKTsNCn0NCg0KDQpIZXJlIGlzIHRoZSBjb2Rl IHNuaXBwZXQgZnJvbSB3aGVyZSBFQUREUk5PVEFWQUlMICBpcyByZXR1cm5lZC4NCg0KRmlsZSA6 IG5ldGluZXQ2L2luNl9wY2IuYw0KDQppbjZfcGNiYmluZChyZWdpc3RlciBzdHJ1Y3QgaW5wY2Ig KmlucCwgc3RydWN0IHNvY2thZGRyICpuYW0sDQogICAgc3RydWN0IHVjcmVkICpjcmVkKQ0Kew0K 4oCm4oCmLi4NCuKApuKApi4uDQoNCn0gZWxzZSBpZiAoIUlONl9JU19BRERSX1VOU1BFQ0lGSUVE KCZzaW42LT5zaW42X2FkZHIpKSB7DQogICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgaWZh ZGRyICppZmE7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHNpbjYtPnNpbjZfcG9ydCA9IDA7 ICAgICAgICAgICAgLyogeWVjaC4uLiAqLw0KICAgICAgICAgICAgICAgICAgICAgICAgaWYgKChp ZmEgPSBpZmFfaWZ3aXRoYWRkcigoc3RydWN0IHNvY2thZGRyICopc2luNikpID09DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgTlVMTCAmJg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IChpbnAtPmlucF9mbGFncyAmIElOUF9CSU5EQU5ZKSA9PSAwKSB7DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHJldHVybiAoRUFERFJOT1RBVkFJTCk7IO+DqCBpdCBmYWlscyBoZXJl IHNpbmNlIGlmYV9pZndpdGhhZGRyKCkgcmV0dXJucyBOVUxMDQogICAgICAgICAgICAgICAgICAg ICAgICB9DQrigKbigKYuLg0K4oCm4oCmLi4NCg0KfQ0KDQpGaWxlOiBuZXQvaWYuYw0Kc3RydWN0 IGlmYWRkciAqDQppZmFfaWZ3aXRoYWRkcihzdHJ1Y3Qgc29ja2FkZHIgKmFkZHIpDQp7DQoNCiAg ICAgICAgcmV0dXJuIChpZmFfaWZ3aXRoYWRkcl9pbnRlcm5hbChhZGRyLCAxKSk7DQp9DQoNCmlm YV9pZndpdGhhZGRyX2ludGVybmFsKHN0cnVjdCBzb2NrYWRkciAqYWRkciwgaW50IGdldHJlZikN CnsNCuKApuKApi4uDQrigKbigKYuLg0KDQpUQUlMUV9GT1JFQUNIKGlmcCwgJlZfaWZuZXQsIGlm X2xpbmspIHsNCiAgICAgICAgICAgICAgICBJRl9BRERSX1JMT0NLKGlmcCk7DQogICAgICAgICAg ICAgICAgcHJpbnRmKCJpZnAtPnhuYW1lOiVzIGlmcC0+ZG5hbWU6JXNcbiIsaWZwLT5pZl94bmFt ZSwgaWZwLT5pZl9kbmFtZSk7DQogICAgICAgICAgICAgICAgVEFJTFFfRk9SRUFDSChpZmEsICZp ZnAtPmlmX2FkZHJoZWFkLCBpZmFfbGluaykgew0KICAgICAgICAgICAgICAgICAgICAgICAgaWYg KGlmYS0+aWZhX2FkZHItPnNhX2ZhbWlseSAhPSBhZGRyLT5zYV9mYW1pbHkpIO+DqCAgaWZhLT5p ZmFfYWRkci0+c2FfZmFtaWx5PTE4ICYgYWRkci0+c2FfZmFtaWx5PTI4LiBFdmVuIHRob3VnaCB0 aGUgaW50ZXJmYWNlIGlzIGluIElQVjYgbW9kZSBpdHMgc2FfZmFtaWx5IGlzIG5vdCAgc2V0IHBy b3Blcmx5LCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udGludWU7DQp9DQpJZmEgPSBOVUxMOw0K4oCm4oCmLi4NCuKApuKApi4uDQoN Cn0NCg0K From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 13:02:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D2B3526 for ; Thu, 18 Apr 2013 13:02:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 0C960B79 for ; Thu, 18 Apr 2013 13:02:40 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k3so31707oag.19 for ; Thu, 18 Apr 2013 06:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lM5T+S9YvKybUUNGgqxqXA2Z4Ei9FQcqTpuVg8PoxII=; b=yrzICRp/4ustuqeVBr2RF7fvImv2fnHdVlD632ZV3RMfhM0smWb463SqnzhYSG5S3l HX0hejiidYintB8Ss8NP//mzVrtvhSdye0o/O/spAdrU+wQCwhJclgi2sZnkBjGQhssn PM++GOFvX1y06lZCRSe4N2222KmC/zGW9Ss5EA4UlkNkyGhiGEY2QZeO1fWeTjjeXuut 7WsJd3CbwxRgsmpHjvTTyVvClFa/Pb1Nfq6BJ+wBPSnDGNoDzjcVAzrSf72HwMawtz4j ax/1eLZehBMv6qdsHyWIxdUAdkD8Ja6gnRn7vPWdQKlBneVMfQ7GpWGI9IFiGq1hdJ0N jRQA== MIME-Version: 1.0 X-Received: by 10.60.55.97 with SMTP id r1mr294558oep.85.1366290160364; Thu, 18 Apr 2013 06:02:40 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.60.7.5 with HTTP; Thu, 18 Apr 2013 06:02:40 -0700 (PDT) In-Reply-To: <201304152012.r3FKCdI3085567@slippy.cwsent.com> References: <20130415195544.GY76816@FreeBSD.org> <201304152012.r3FKCdI3085567@slippy.cwsent.com> Date: Thu, 18 Apr 2013 09:02:40 -0400 X-Google-Sender-Auth: tLEX_iVn4WyQgYZ45Dmzn-4hzIo Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Ed Maste To: Cy Schubert Content-Type: text/plain; charset=ISO-8859-1 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 13:02:41 -0000 On 15 April 2013 16:12, Cy Schubert wrote: > The existing license isn't that BSD-friendly either, which is why it lives > in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as > Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. > A person can always load it anyway. There's a plan[1] to remove the remaining GPL components from base over time. Updating to the last ipfilter that's under the current license is probably the path forward, unless it moves out to ports. [1] https://wiki.freebsd.org/GPLinBase -Ed From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 13:55:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7DC598AE; Thu, 18 Apr 2013 13:55:01 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-04.shaw.ca (smtp-out-04.shaw.ca [64.59.134.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4B708FCC; Thu, 18 Apr 2013 13:55:01 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=HUoWN8sqH4wajA0WKpKyUV7G7o/UpN4YSPso/+twBIs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=y0hQBMVAJT5ZhVpp6mQA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-04.shaw.ca with ESMTP; 18 Apr 2013 07:55:48 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id DDD52FF; Thu, 18 Apr 2013 06:54:54 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3IDssVp005515; Thu, 18 Apr 2013 06:54:54 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304181354.r3IDssVp005515@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ed Maste Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Ed Maste of "Thu, 18 Apr 2013 09:02:40 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Apr 2013 06:54:54 -0700 Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 13:55:01 -0000 In message , Ed Maste writes: > On 15 April 2013 16:12, Cy Schubert wrote: > > The existing license isn't that BSD-friendly either, which is why it lives > > in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as > > Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. > > A person can always load it anyway. > > There's a plan[1] to remove the remaining GPL components from base > over time. Updating to the last ipfilter that's under the current > license is probably the path forward, unless it moves out to ports. > > [1] https://wiki.freebsd.org/GPLinBase That's been pointed out to me. IPF's build/install scripts place header files in /usr/include, IMO unacceptable for a port. Going forward we go to 4.1.34 (still under the old license) then look at options. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 14:15:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93FE4DE6; Thu, 18 Apr 2013 14:15:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8C0179; Thu, 18 Apr 2013 14:15:12 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id o7so2341004wea.22 for ; Thu, 18 Apr 2013 07:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UsUrkZV9sNaFcGMcSucdjuBOgxSquaegUTlJD46Ud8E=; b=d6fLKuYoWCruHK6dFW0Z5l/5iluFqdgjDYQdp7YHnqX8JUpjg5b5e4jyRQJKJ9O4Qy tNl7R+pgMSVgWAoUFUj8b36+TuIecE4EWdiZhFjJnU67bPNVZOxTgYzv4ouZyBuw7KJD Mq4oHjvyTc4tvJqCKhfF1AudhpyKigkip+/Sw0ezi7tlYJ6TvZP3DDmad/j88Dfk4FT1 80OZUkrjZ07SsJgqPlU7KrueqEvwDgekJHg8HHluX0Yt9Rg8OZuTBMOV+mCjvrpKDW5e OYuJ361WyRIhoG/tX4et9HcrOI3TnWtZPe7JuGz1ziY8Hcx+B2l+fUvG6p1yxllND//7 qwdg== MIME-Version: 1.0 X-Received: by 10.194.142.236 with SMTP id rz12mr19219614wjb.12.1366294512204; Thu, 18 Apr 2013 07:15:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 07:15:12 -0700 (PDT) In-Reply-To: <1789865.JtNRVqvDCl@home.alkar.net> References: <1645676.6Cz3TLlJG5@home.alkar.net> <1789865.JtNRVqvDCl@home.alkar.net> Date: Thu, 18 Apr 2013 07:15:12 -0700 X-Google-Sender-Auth: -GfUSejUMnQygXO-cEhVt34zFNk Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 14:15:13 -0000 Sigh. Someone's broken the bus or interrupt handling code between -9 and -head. Or ACPI, for all I know. It may even be something to do with RFKILL. Can you please boot verbosely, both on -9 and -head? you don't have to do anything - just capture the logfile /var/run/dmesg.boot and attach them here. Hopefully something glaringly different will stand out. Thanks, adrian On 18 April 2013 07:05, Artyom Mirgorodskiy wrote: > No interrupts at all: > > > > interrupt total rate > > irq1: atkbd0 474 1 > > irq9: acpi0 95 0 > > irq22: ehci1 504 1 > > irq23: ehci0 1037 3 > > irq256: hpet0:t0 8426 30 > > irq257: hpet0:t1 1823 6 > > irq258: hpet0:t2 1992 7 > > irq259: hpet0:t3 2112 7 > > irq264: hdac0 118 0 > > irq265: ahci0 4026 14 > > Total 20607 75 > > > > > > On Thursday 18 April 2013 06:56:14 Adrian Chadd wrote: > >> I've just tested -HEAD on a WB197 (AR9287 + bluetooth.) It works fine. > >> > >> I think it's very likely something to do with the bus enumeration. Can > >> you do a vmstat -i, see if you've seen any ath interrupts? > >> > >> > >> > >> adrian > > -- > > Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 15:13:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16EA4F30; Thu, 18 Apr 2013 15:13:40 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id CE61E6D9; Thu, 18 Apr 2013 15:13:38 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id q15so1295414ead.27 for ; Thu, 18 Apr 2013 08:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=nSF6Z6kqtsLT8XdjsMwWngTy0H0sTuKWaEm1hkzCMJ8=; b=TnZdIKV+UprJUIn9XMh/Yv9eJVi3TMpMDh3h6VA1lXZKDWomwni0OZyVh/ZqpbkYEs c8hacba2aXuJcbdNimzvRa9Qkm4Fr3YJhHfTJXxIkgIbU5uX7y8U8E603Vwgu9AHDjom /Q2NLhhIfQ3hO7tZ9vQjGDXqDSWKscFbewwsbnoPxlKbi01e9ggdN6+G4wNse5jHO2fb ObxIE3HWQLlxUex3v367wWnatLxnAhbxgBvqqwRM5etiwT6rzCn/dtKB3X1Itf6uqRfz 99iAEvQw9KAnKKRRY5pzyPI6VQ0mDlcU94g03drxi9pvW4k+lRHLrpaZF9V/QO0I02Gp glzQ== X-Received: by 10.15.43.73 with SMTP id w49mr31335943eev.12.1366298018004; Thu, 18 Apr 2013 08:13:38 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id f9sm1326606eeu.11.2013.04.18.08.13.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:13:37 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 18:12:55 +0300 Message-ID: <3905231.GikR8SZEYk@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <1645676.6Cz3TLlJG5@home.alkar.net> <1789865.JtNRVqvDCl@home.alkar.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart3674367.YiUq4v0LF4" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 15:13:40 -0000 This is a multi-part message in MIME format. --nextPart3674367.YiUq4v0LF4 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" See attached On Thursday 18 April 2013 07:15:12 Adrian Chadd wrote: > Sigh. > > Someone's broken the bus or interrupt handling code between -9 and > -head. Or ACPI, for all I know. It may even be something to do with > RFKILL. > > Can you please boot verbosely, both on -9 and -head? you don't have to > do anything - just capture the logfile /var/run/dmesg.boot and attach > them here. > > Hopefully something glaringly different will stand out. > > Thanks, > > > > adrian > > On 18 April 2013 07:05, Artyom Mirgorodskiy > wrote: > > No interrupts at all: > > > > > > > > interrupt total rate > > > > irq1: atkbd0 474 1 > > > > irq9: acpi0 95 0 > > > > irq22: ehci1 504 1 > > > > irq23: ehci0 1037 3 > > > > irq256: hpet0:t0 8426 30 > > > > irq257: hpet0:t1 1823 6 > > > > irq258: hpet0:t2 1992 7 > > > > irq259: hpet0:t3 2112 7 > > > > irq264: hdac0 118 0 > > > > irq265: ahci0 4026 14 > > > > Total 20607 75 > > > > > > > > > > > > On Thursday 18 April 2013 06:56:14 Adrian Chadd wrote: > > > >> I've just tested -HEAD on a WB197 (AR9287 + bluetooth.) It works fine. > > > >> > > > >> I think it's very likely something to do with the bus enumeration. Can > > > >> you do a vmstat -i, see if you've seen any ath interrupts? > > > >> > > > >> > > > >> > > > >> adrian > > > > -- > > > > Artyom Mirgorodskiy -- Artyom Mirgorodskiy --nextPart3674367.YiUq4v0LF4 Content-Disposition: attachment; filename="dmesg.boot-9" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="dmesg.boot-9" FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000224000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) acpi0: Power Button (fixed) hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2625000, size 4, enabled pcib0: allocated type 3 (0xe2625000-0xe262500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1503, revid=0x04 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe2600000, size 17, enabled pcib0: allocated type 3 (0xe2600000-0xe261ffff) for rid 10 of pci0:0:25:0 map[14]: type Memory, range 32, base 0xe262b000, size 12, enabled pcib0: allocated type 3 (0xe262b000-0xe262bfff) for rid 14 of pci0:0:25:0 map[18]: type I/O Port, range 32, base 0x3080, size 5, enabled pcib0: allocated type 4 (0x3080-0x309f) for rid 18 of pci0:0:25:0 pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe262a000, size 10, enabled pcib0: allocated type 3 (0xe262a000-0xe262a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2620000, size 14, enabled pcib0: allocated type 3 (0xe2620000-0xe2623fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c1e, revid=0xb4 domain=0, bus=0, slot=28, func=7 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2629000, size 10, enabled pcib0: allocated type 3 (0xe2629000-0xe26293ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x30a8, size 3, enabled pcib0: allocated type 4 (0x30a8-0x30af) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x30b4, size 2, enabled pcib0: allocated type 4 (0x30b4-0x30b7) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x30a0, size 3, enabled pcib0: allocated type 4 (0x30a0-0x30a7) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x30b0, size 2, enabled pcib0: allocated type 4 (0x30b0-0x30b3) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2628000, size 11, enabled pcib0: allocated type 3 (0xe2628000-0xe26287ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 64, base 0xe2624000, size 8, enabled pcib0: allocated type 3 (0xe2624000-0xe26240ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0: at device 25.0 (no driver attached) ehci0: mem 0xe262a000-0xe262a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 usbus0: bpf attached ehci0: usbpf: Attached hdac0: mem 0xe2620000-0xe2623fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search pcib3: irq 17 at device 28.7 on pci0 pcib0: allocated type 3 (0xe0400000-0xe04fffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 11 pcib3: subordinate bus 11 pcib3: memory decode 0xe0400000-0xe04fffff pcib3: no prefetched decode pci11: on pcib3 pci11: domain=0, physical bus=11 found-> vendor=0x10ec, dev=0x5209, revid=0x01 domain=0, bus=11, slot=0, func=0 class=ff-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0401000, size 12, enabled pcib3: allocated memory range (0xe0401000-0xe0401fff) for rid 10 of pci0:11:0:0 pcib3: matched entry for 11.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x5209, revid=0x01 domain=0, bus=11, slot=0, func=1 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0400000, size 8, enabled pcib3: allocated memory range (0xe0400000-0xe04000ff) for rid 10 of pci0:11:0:1 pcib3: matched entry for 11.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 pci11: at device 0.0 (no driver attached) pci11: at device 0.1 (no driver attached) ehci1: mem 0xe2629000-0xe26293ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 usbus1: bpf attached ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x30a8-0x30af,0x30b4-0x30b7,0x30a0-0x30a7,0x30b0-0x30b3,0x3060-0x307f mem 0xe2628000-0xe26287ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ichsmb0: port 0xefa0-0xefbf mem 0xe2624000-0xe26240ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi0: wakeup code va 0xffffff8111954000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices ctl: CAM Target Layer loaded est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdaa0: hdaa0: +-------------------+ hdaa0: | DUMPING HDA NODES | hdaa0: +-------------------+ hdaa0: hdaa0: Default Parameter hdaa0: ----------------- hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e0560 hdaa0: 16 20 24 bits, 44 48 96 192 KHz hdaa0: IN amp: 0x00000000 hdaa0: OUT amp: 0x00000000 hdaa0: hdaa0: nid: 2 hdaa0: Name: audio output hdaa0: Widget cap: 0x0000001d hdaa0: STEREO hdaa0: Association: 0 (0x00008001) hdaa0: OSS: pcm (pcm) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e0560 hdaa0: 16 20 24 bits, 44 48 96 192 KHz hdaa0: Output amp: 0x00025757 hdaa0: mute=0 step=87 size=2 offset=87 hdaa0: hdaa0: nid: 3 hdaa0: Name: audio output hdaa0: Widget cap: 0x0000001d hdaa0: STEREO hdaa0: Association: 1 (0x00000001) hdaa0: OSS: pcm (pcm) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e0560 hdaa0: 16 20 24 bits, 44 48 96 192 KHz hdaa0: Output amp: 0x00025757 hdaa0: mute=0 step=87 size=2 offset=87 hdaa0: hdaa0: nid: 4 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 5 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 6 [DISABLED] hdaa0: Name: audio output hdaa0: Widget cap: 0x00000211 hdaa0: DIGITAL STEREO hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e05e0 hdaa0: 16 20 24 bits, 44 48 88 96 192 KHz hdaa0: hdaa0: nid: 7 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 8 hdaa0: Name: audio input hdaa0: Widget cap: 0x0010011b hdaa0: STEREO hdaa0: Association: 2 (0x00000001) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e0560 hdaa0: 16 20 24 bits, 44 48 96 192 KHz hdaa0: Input amp: 0x80051f0b hdaa0: mute=1 step=31 size=5 offset=11 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=35 [audio mixer] hdaa0: hdaa0: nid: 9 hdaa0: Name: audio input hdaa0: Widget cap: 0x0010011b hdaa0: STEREO hdaa0: Association: 3 (0x00000001) hdaa0: Stream cap: 0x00000001 hdaa0: PCM hdaa0: PCM cap: 0x000e0560 hdaa0: 16 20 24 bits, 44 48 96 192 KHz hdaa0: Input amp: 0x80051f0b hdaa0: mute=1 step=31 size=5 offset=11 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=34 [audio selector] hdaa0: hdaa0: nid: 10 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 11 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x0020010b hdaa0: STEREO hdaa0: Association: 2 (0x00000001) hdaa0: OSS: mix (mix) hdaa0: Input amp: 0x80051f17 hdaa0: mute=1 step=31 size=5 offset=23 hdaa0: connections: 5 hdaa0: | hdaa0: + [DISABLED] <- nid=24 [pin: Mic (Black Jack)] hdaa0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdaa0: + [DISABLED] <- nid=26 [pin: Headphones (Black Jack)] hdaa0: + <- nid=27 [pin: Mic (Black Jack)] hdaa0: + <- nid=29 [beep widget] hdaa0: hdaa0: nid: 12 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x0020010b hdaa0: STEREO hdaa0: Association: 0 (0x00008001) hdaa0: OSS: pcm, mix hdaa0: Input amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=2 [audio output] hdaa0: + <- nid=11 [audio mixer] hdaa0: hdaa0: nid: 13 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x0020010b hdaa0: STEREO hdaa0: Association: 1 (0x00000001) hdaa0: OSS: pcm, mix hdaa0: Input amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=3 [audio output] hdaa0: + <- nid=11 [audio mixer] hdaa0: hdaa0: nid: 14 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 15 [DISABLED] hdaa0: Name: audio mixer hdaa0: Widget cap: 0x0020010a hdaa0: Input amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=2 [audio output] hdaa0: + [DISABLED] <- nid=11 [audio mixer] hdaa0: hdaa0: nid: 16 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 17 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 18 [DISABLED] hdaa0: Name: pin: Mic (Fixed) hdaa0: Widget cap: 0x0040000b hdaa0: STEREO hdaa0: Pin cap: 0x00000020 hdaa0: IN hdaa0: Pin config: 0x90a60150 hdaa0: Pin control: 0x00000000 hdaa0: Input amp: 0x002f0300 hdaa0: mute=0 step=3 size=47 offset=0 hdaa0: hdaa0: nid: 19 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 20 hdaa0: Name: pin: Speaker (Fixed) hdaa0: Widget cap: 0x0040018d hdaa0: UNSOL STEREO hdaa0: Association: 0 (0x00000001) hdaa0: Pin cap: 0x00010014 hdaa0: PDC OUT EAPD hdaa0: Pin config: 0x90170110 hdaa0: Pin control: 0x00000040 OUT hdaa0: EAPD: 0x00000002 hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=12 [audio mixer] (selected) hdaa0: + [DISABLED] <- nid=13 [audio mixer] hdaa0: hdaa0: nid: 21 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 22 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 23 [DISABLED] hdaa0: Name: pin: Speaker (None) hdaa0: Widget cap: 0x0040010c hdaa0: Pin cap: 0x00000010 hdaa0: OUT hdaa0: Pin config: 0x411111f0 hdaa0: Pin control: 0x00000000 hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 1 hdaa0: | hdaa0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdaa0: hdaa0: nid: 24 hdaa0: Name: pin: Mic (Black Jack) hdaa0: Widget cap: 0x0040018f hdaa0: UNSOL STEREO hdaa0: Association: 3 (0x00000001) hdaa0: OSS: mic (mic) hdaa0: Pin cap: 0x00001734 hdaa0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdaa0: Pin config: 0x02a11040 hdaa0: Pin control: 0x00000024 IN VREFs hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: Input amp: 0x002f0300 hdaa0: mute=0 step=3 size=47 offset=0 hdaa0: connections: 1 hdaa0: | hdaa0: + [DISABLED] <- nid=13 [audio mixer] hdaa0: hdaa0: nid: 25 [DISABLED] hdaa0: Name: pin: Speaker (None) hdaa0: Widget cap: 0x0040008b hdaa0: UNSOL STEREO hdaa0: Pin cap: 0x00001724 hdaa0: PDC IN VREF[ 50 80 GROUND HIZ ] hdaa0: Pin config: 0x411111f0 hdaa0: Pin control: 0x00000000 hdaa0: Input amp: 0x002f0300 hdaa0: mute=0 step=3 size=47 offset=0 hdaa0: hdaa0: nid: 26 hdaa0: Name: pin: Headphones (Black Jack) hdaa0: Widget cap: 0x0040018f hdaa0: UNSOL STEREO hdaa0: Association: 0 (0x00008000) hdaa0: Pin cap: 0x0000003c hdaa0: PDC HP OUT IN hdaa0: Pin config: 0x2121101f hdaa0: Pin control: 0x000000c0 HP OUT hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: Input amp: 0x002f0300 hdaa0: mute=0 step=3 size=47 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + <- nid=12 [audio mixer] (selected) hdaa0: + [DISABLED] <- nid=13 [audio mixer] hdaa0: hdaa0: nid: 27 hdaa0: Name: pin: Mic (Black Jack) hdaa0: Widget cap: 0x0040018f hdaa0: UNSOL STEREO hdaa0: Association: 2 (0x00000001) hdaa0: OSS: monitor (monitor) hdaa0: Pin cap: 0x00000034 hdaa0: PDC OUT IN hdaa0: Pin config: 0x21a11030 hdaa0: Pin control: 0x00000020 IN hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: Input amp: 0x002f0300 hdaa0: mute=0 step=3 size=47 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdaa0: + [DISABLED] <- nid=13 [audio mixer] hdaa0: hdaa0: nid: 28 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 29 hdaa0: Name: beep widget hdaa0: Widget cap: 0x00700000 hdaa0: Association: -2 (0x00000000) hdaa0: OSS: speaker (speaker) hdaa0: Pin cap: 0x00000020 hdaa0: IN hdaa0: Pin config: 0x909701f0 hdaa0: Pin control: 0x00000020 IN hdaa0: hdaa0: nid: 30 [DISABLED] hdaa0: Name: pin: Speaker (None) hdaa0: Widget cap: 0x00400381 hdaa0: DIGITAL UNSOL STEREO hdaa0: Pin cap: 0x00000014 hdaa0: PDC OUT hdaa0: Pin config: 0x411111f0 hdaa0: Pin control: 0x00000000 hdaa0: connections: 1 hdaa0: | hdaa0: + <- nid=6 [audio output] [DISABLED] hdaa0: hdaa0: nid: 31 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00000 hdaa0: hdaa0: nid: 32 [DISABLED] hdaa0: Name: vendor widget hdaa0: Widget cap: 0x00f00040 hdaa0: PROC hdaa0: hdaa0: nid: 33 hdaa0: Name: pin: Headphones (Black Jack) hdaa0: Widget cap: 0x0040018d hdaa0: UNSOL STEREO hdaa0: Association: 1 (0x00000001) hdaa0: Pin cap: 0x0000001c hdaa0: PDC HP OUT hdaa0: Pin config: 0x02211020 hdaa0: Pin control: 0x000000c0 HP OUT hdaa0: Output amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 2 hdaa0: | hdaa0: + [DISABLED] <- nid=12 [audio mixer] hdaa0: + <- nid=13 [audio mixer] (selected) hdaa0: hdaa0: nid: 34 hdaa0: Name: audio selector hdaa0: Widget cap: 0x0030010b hdaa0: STEREO hdaa0: Association: 3 (0x00000001) hdaa0: OSS: speaker, mic hdaa0: connections: 7 hdaa0: | hdaa0: + <- nid=24 [pin: Mic (Black Jack)] (selected) hdaa0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdaa0: + [DISABLED] <- nid=26 [pin: Headphones (Black Jack)] hdaa0: + [DISABLED] <- nid=27 [pin: Mic (Black Jack)] hdaa0: + <- nid=29 [beep widget] hdaa0: + [DISABLED] <- nid=11 [audio mixer] hdaa0: + [DISABLED] <- nid=18 [pin: Mic (Fixed)] [DISABLED] hdaa0: hdaa0: nid: 35 hdaa0: Name: audio mixer hdaa0: Widget cap: 0x0020010b hdaa0: STEREO hdaa0: Association: 2 (0x00000001) hdaa0: OSS: speaker, mix, monitor hdaa0: Input amp: 0x80000000 hdaa0: mute=1 step=0 size=0 offset=0 hdaa0: connections: 6 hdaa0: | hdaa0: + [DISABLED] <- nid=24 [pin: Mic (Black Jack)] hdaa0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdaa0: + [DISABLED] <- nid=26 [pin: Headphones (Black Jack)] hdaa0: + <- nid=27 [pin: Mic (Black Jack)] hdaa0: + <- nid=29 [beep widget] hdaa0: + <- nid=11 [audio mixer] hdaa0: pcm0: at nid 20,26 and 27 on hdaa0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: | pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: | pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: | pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: | pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: | pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: | pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: | pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: | pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 12fd00000, 10000; 0xffffff811196d000 -> 12fd00000 pcm0: sndbuf_setmap 12fd40000, 10000; 0xffffff81119ad000 -> 12fd40000 pcm1: at nid 33 and 24 on hdaa0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 9 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: | pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: | pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: | pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: | pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: | pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: | pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: | pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: | pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: | pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: | pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 4d00000, 10000; 0xffffff81119ed000 -> 4d00000 pcm1: sndbuf_setmap 4d40000, 10000; 0xffffff8111a2d000 -> 4d40000 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdaa1: hdaa1: +-------------------+ hdaa1: | DUMPING HDA NODES | hdaa1: +-------------------+ hdaa1: hdaa1: Default Parameter hdaa1: ----------------- hdaa1: IN amp: 0x00000000 hdaa1: OUT amp: 0x00000000 hdaa1: hdaa1: nid: 2 hdaa1: Name: audio output hdaa1: Widget cap: 0x00006611 hdaa1: PWR DIGITAL 8CH hdaa1: Association: 0 (0x00000001) hdaa1: OSS: pcm (pcm) hdaa1: Stream cap: 0x00000005 hdaa1: AC3 PCM hdaa1: PCM cap: 0x001e07f0 hdaa1: 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz hdaa1: hdaa1: nid: 3 hdaa1: Name: audio output hdaa1: Widget cap: 0x00006611 hdaa1: PWR DIGITAL 8CH hdaa1: Association: 1 (0x00000001) hdaa1: OSS: pcm (pcm) hdaa1: Stream cap: 0x00000005 hdaa1: AC3 PCM hdaa1: PCM cap: 0x001e07f0 hdaa1: 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz hdaa1: hdaa1: nid: 4 [DISABLED] hdaa1: Name: audio output hdaa1: Widget cap: 0x00006611 hdaa1: PWR DIGITAL 8CH hdaa1: Stream cap: 0x00000005 hdaa1: AC3 PCM hdaa1: PCM cap: 0x001e07f0 hdaa1: 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz hdaa1: hdaa1: nid: 5 hdaa1: Name: pin: Digital-out (Jack) hdaa1: Widget cap: 0x0040778d hdaa1: PWR DIGITAL UNSOL 8CH hdaa1: Association: 0 (0x00000001) hdaa1: Pin cap: 0x09000094 hdaa1: PDC OUT HDMI DP HBR hdaa1: Pin config: 0x18560010 hdaa1: Pin control: 0x00000040 OUT hdaa1: Output amp: 0x80000000 hdaa1: mute=1 step=0 size=0 offset=0 hdaa1: connections: 1 hdaa1: | hdaa1: + <- nid=2 [audio output] hdaa1: hdaa1: nid: 6 hdaa1: Name: pin: Digital-out (Jack) hdaa1: Widget cap: 0x0040778d hdaa1: PWR DIGITAL UNSOL 8CH hdaa1: Association: 1 (0x00000001) hdaa1: Pin cap: 0x09000094 hdaa1: PDC OUT HDMI DP HBR hdaa1: Pin config: 0x18560020 hdaa1: Pin control: 0x00000040 OUT hdaa1: Output amp: 0x80000000 hdaa1: mute=1 step=0 size=0 offset=0 hdaa1: connections: 1 hdaa1: | hdaa1: + <- nid=3 [audio output] hdaa1: hdaa1: nid: 7 [DISABLED] hdaa1: Name: pin: Digital-out (None) hdaa1: Widget cap: 0x0040778d hdaa1: PWR DIGITAL UNSOL 8CH hdaa1: Pin cap: 0x09000094 hdaa1: PDC OUT HDMI DP HBR hdaa1: Pin config: 0x58560010 hdaa1: Pin control: 0x00000000 hdaa1: Output amp: 0x80000000 hdaa1: mute=1 step=0 size=0 offset=0 hdaa1: connections: 1 hdaa1: | hdaa1: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdaa1: hdaa1: nid: 8 [DISABLED] hdaa1: Name: vendor widget hdaa1: Widget cap: 0x00f00000 hdaa1: pcm2: at nid 5 on hdaa1 pcm2: +--------------------------------------+ pcm2: | DUMPING PCM Playback/Record Channels | pcm2: +--------------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: Stream cap: 0x00000005 pcm2: AC3 PCM pcm2: PCM cap: 0x001e07f0 pcm2: 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: +-------------------------------+ pcm2: | DUMPING Playback/Record Paths | pcm2: +-------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: | pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: +-------------------------+ pcm2: | DUMPING Volume Controls | pcm2: +-------------------------+ pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: | pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: | pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: clone manager: deadline=750ms flags=0x8000001e pcm2: sndbuf_setmap 4d80000, 10000; 0xffffff8111a6d000 -> 4d80000 pcm3: at nid 6 on hdaa1 pcm3: +--------------------------------------+ pcm3: | DUMPING PCM Playback/Record Channels | pcm3: +--------------------------------------+ pcm3: pcm3: Playback: pcm3: pcm3: Stream cap: 0x00000005 pcm3: AC3 PCM pcm3: PCM cap: 0x001e07f0 pcm3: 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: +-------------------------------+ pcm3: | DUMPING Playback/Record Paths | pcm3: +-------------------------------+ pcm3: pcm3: Playback: pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: | pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: +-------------------------+ pcm3: | DUMPING Volume Controls | pcm3: +-------------------------+ pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: | pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: | pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: clone manager: deadline=750ms flags=0x8000001e pcm3: sndbuf_setmap 4dc0000, 10000; 0xffffff8111aad000 -> 4dc0000 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 lapic3: CMCI unmasked lapic2: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (GEOM: new disk ada0 ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097534906 Hz quality 1000 Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen1.2: at usbus1 uhub2: on usbus1 ugen0.2: at usbus0 uhub3: on usbus0 Root mount waiting for: usbus1 usbus0 uhub3: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered ugen1.3: at usbus1 Root mount waiting for: usbus0 ugen0.3: at usbus0 ugen0.4: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e umass0: on usbus0 umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? GEOM: new disk da0 pass1 at umass-sim0 bus 0 scbus2 target 0 lun 0 pass1: Removable Direct Access SCSI-0 device pass1: Serial Number 123456790130 pass1: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 123456790130 da0: 40.000MB/s transfers da0: 483MB (990976 512 byte sectors: 64H 32S/T 483C) ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled ipfw0: bpf attached nfslock: pseudo-device --nextPart3674367.YiUq4v0LF4 Content-Disposition: attachment; filename="dmesg.boot-head" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="dmesg.boot-head" Table 'FACP' at 0xcafef000 Table 'SSDT' at 0xcaffd000 Table 'SSDT' at 0xcaffc000 Table 'SSDT' at 0xcaffb000 Table 'ASF!' at 0xcaff1000 Table 'HPET' at 0xcafee000 Table 'APIC' at 0xcafed000 APIC: Found table at 0xcafed000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 0 ACPI ID 5: disabled MADT: Found CPU APIC ID 0 ACPI ID 6: disabled MADT: Found CPU APIC ID 0 ACPI ID 7: disabled MADT: Found CPU APIC ID 0 ACPI ID 8: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r249620: Thu Apr 18 15:17:57 EEST 2013 root@home.alkar.net:/usr/obj/usr/src/sys/Work amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80d2a000. Preloaded elf obj module "/boot/kernel/msdosfs.ko" at 0xffffffff80d2a950. Preloaded elf obj module "/boot/kernel/if_ath.ko" at 0xffffffff80d2aef8. Preloaded elf obj module "/boot/kernel/wlan.ko" at 0xffffffff80d2b6a0. Preloaded elf obj module "/boot/kernel/if_re.ko" at 0xffffffff80d2bf08. Preloaded elf obj module "/boot/kernel/miibus.ko" at 0xffffffff80d2c430. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff80d2c998. Preloaded elf obj module "/boot/kernel/uhid.ko" at 0xffffffff80d2cf40. Preloaded elf obj module "/boot/kernel/usb.ko" at 0xffffffff80d2d4a8. Preloaded elf obj module "/boot/kernel/if_ath_pci.ko" at 0xffffffff80d2db10. Preloaded elf obj module "/boot/kernel/uhci.ko" at 0xffffffff80d2e040. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0xffffffff80d2e568. Preloaded elf obj module "/boot/kernel/msdosfs_iconv.ko" at 0xffffffff80d2ea90. Preloaded elf obj module "/boot/kernel/libiconv.ko" at 0xffffffff80d2ef40. Preloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff80d2f570. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80d2fb20. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80d30048. Calibrating TSC clock ... TSC clock: 2195067972 Hz CPU: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz (2195.07-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000d50000 - 0x00000000bfa37fff, 3201204224 bytes (781544 pages) 0x0000000100000000 - 0x000000012fde7fff, 803110912 bytes (196072 pages) avail memory = 3829268480 (3651 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000244000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse4BSD v0.1.27 @ /dev/cuse wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7e63c0), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2625000, size 4, enabled pcib0: allocated type 3 (0xe2625000-0xe262500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1503, revid=0x04 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe2600000, size 17, enabled pcib0: allocated type 3 (0xe2600000-0xe261ffff) for rid 10 of pci0:0:25:0 map[14]: type Memory, range 32, base 0xe262b000, size 12, enabled pcib0: allocated type 3 (0xe262b000-0xe262bfff) for rid 14 of pci0:0:25:0 map[18]: type I/O Port, range 32, base 0x3080, size 5, enabled pcib0: allocated type 4 (0x3080-0x309f) for rid 18 of pci0:0:25:0 pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe262a000, size 10, enabled pcib0: allocated type 3 (0xe262a000-0xe262a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2620000, size 14, enabled pcib0: allocated type 3 (0xe2620000-0xe2623fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c1e, revid=0xb4 domain=0, bus=0, slot=28, func=7 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2629000, size 10, enabled pcib0: allocated type 3 (0xe2629000-0xe26293ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x30a8, size 3, enabled pcib0: allocated type 4 (0x30a8-0x30af) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x30b4, size 2, enabled pcib0: allocated type 4 (0x30b4-0x30b7) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x30a0, size 3, enabled pcib0: allocated type 4 (0x30a0-0x30a7) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x30b0, size 2, enabled pcib0: allocated type 4 (0x30b0-0x30b3) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2628000, size 11, enabled pcib0: allocated type 3 (0xe2628000-0xe26287ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 64, base 0xe2624000, size 8, enabled pcib0: allocated type 3 (0xe2624000-0xe26240ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0: at device 25.0 (no driver attached) ehci0: mem 0xe262a000-0xe262a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2620000-0xe2623fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search pcib3: irq 17 at device 28.7 on pci0 pcib0: allocated type 3 (0xe0400000-0xe04fffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 11 pcib3: subordinate bus 11 pcib3: memory decode 0xe0400000-0xe04fffff pcib3: no prefetched decode pci11: on pcib3 pci11: domain=0, physical bus=11 found-> vendor=0x10ec, dev=0x5209, revid=0x01 domain=0, bus=11, slot=0, func=0 class=ff-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0401000, size 12, enabled pcib3: allocated memory range (0xe0401000-0xe0401fff) for rid 10 of pci0:11:0:0 pcib3: matched entry for 11.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x10ec, dev=0x5209, revid=0x01 domain=0, bus=11, slot=0, func=1 class=08-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0400000, size 8, enabled pcib3: allocated memory range (0xe0400000-0xe04000ff) for rid 10 of pci0:11:0:1 pcib3: matched entry for 11.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 pci11: at device 0.0 (no driver attached) pci11: at device 0.1 (no driver attached) ehci1: mem 0xe2629000-0xe26293ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x30a8-0x30af,0x30b4-0x30b7,0x30a0-0x30a7,0x30b0-0x30b3,0x3060-0x307f mem 0xe2628000-0xe26287ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2624000-0xe26240ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff81198bf000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices ctl: CAM Target Layer loaded est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: new disk ada0 ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097533986 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen1.3: at usbus1 ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled nfslock: pseudo-device --nextPart3674367.YiUq4v0LF4-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 15:22:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57C1D1EF; Thu, 18 Apr 2013 15:22:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id A22547A2; Thu, 18 Apr 2013 15:22:39 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id l13so2663571wie.12 for ; Thu, 18 Apr 2013 08:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=i9vEktrYvslQ6AyVVExEgpR43odQnrYptlNIIhHFQ8U=; b=ZNm2rRspjuFblAZonrBQUely4OKkmYHY6oVgFmogVbN2fPpjstuB+pE+O5NU8XYo0W ZdQlRhYi3TE+NR4tEASxwixCAOXMNRUHgVYxETIHieQno534Lz71NrGpadU1Co0OkDkB 9KkvBzgh26trJN8ov7DoT9NtXfFzg+qo3+ol0rAr7A8GdcKqOKwi1cbmL2g9Ng8P4UaX qSBcpq7PCQOQESvhoDFrO0NDsXoKdda9Hvng4gFgB94a0JUt0CUMo4/u1uAHasqcNSQa krxcj+GfPJwxVI/avjCbelvvqrhVpXSBwBXCez9m+B3Lh79473Q0lb1jM7s0i/F6+EWs nhOQ== MIME-Version: 1.0 X-Received: by 10.194.142.236 with SMTP id rz12mr19739339wjb.12.1366298558889; Thu, 18 Apr 2013 08:22:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 08:22:38 -0700 (PDT) In-Reply-To: <3905231.GikR8SZEYk@home.alkar.net> References: <1645676.6Cz3TLlJG5@home.alkar.net> <1789865.JtNRVqvDCl@home.alkar.net> <3905231.GikR8SZEYk@home.alkar.net> Date: Thu, 18 Apr 2013 08:22:38 -0700 X-Google-Sender-Auth: l2-aXHuKHi7A4_1jrAkb4ALfr8A Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 15:22:40 -0000 Ok, the relevant / interesting bit:s. John, any ideas? HEAD: pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 ^---------- notice how this is irq 10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search versus pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 ^------ notice this is irq 7 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 15:40:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F318B4EC; Thu, 18 Apr 2013 15:40:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D0C32854; Thu, 18 Apr 2013 15:40:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A582B926; Thu, 18 Apr 2013 11:40:01 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 11:37:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1645676.6Cz3TLlJG5@home.alkar.net> <3905231.GikR8SZEYk@home.alkar.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304181137.17627.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Apr 2013 11:40:01 -0400 (EDT) Cc: Artyom Mirgorodskiy , freebsd-wireless@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 15:40:02 -0000 On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > Ok, the relevant / interesting bit:s. John, any ideas? Only that this means absolutely nothing? These are the values the BIOS wrote into the registers which we use as hints about whether or not ACPI lies about which interrupts are used when APIC is disabled. The actually useful message shows the same interrupts used in both cases: > HEAD: > > pcib2: slot 0 INTA hardwired to IRQ 18 > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > versus > > pcib2: slot 0 INTA hardwired to IRQ 18 > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 16:42:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7CA42A9; Thu, 18 Apr 2013 16:42:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7133BB33; Thu, 18 Apr 2013 16:42:07 +0000 (UTC) Received: by mail-da0-f49.google.com with SMTP id t11so1477098daj.36 for ; Thu, 18 Apr 2013 09:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:to:cc:reply-to:subject:in-reply-to :x-mailer:mime-version:content-type; bh=bXjxbkamLhaG+vEXVaKEvGisqxVR9XjsBU0u3wm4Xpg=; b=U5mf5IJVcqoh7RUTUS/wYYKAatodXK1e1TsrQ0DziA2AkthMpUBenMfN1uHLSBntj+ gMN+W/UUN/s0fj+MswXd3jblxKudbZltESeLhHqNkOAbIdUcLZG0pG/MhobTuugHrn/7 nRNXQMNZQibgcFthNIMbUnCxaL5KgS9U1V552+xbayAlFdi1FGaGlU+bKmMXBSiAtaUC tZ5BAZW6HKWLGdXJcSf5sTDoCWJWxsad1gYWizM9iaXzH2swoGdwzxhyap1tj2F+ushk YtGcro3HZYaY5kGPffkWvuiXeYjxuFkFyMBROAL4u6yhHkPuGtb3K4PGqZpouCmz5v3f LVlA== X-Received: by 10.68.172.5 with SMTP id ay5mr14600491pbc.73.1366303327260; Thu, 18 Apr 2013 09:42:07 -0700 (PDT) Received: from www.palm.com ([32.158.149.109]) by mx.google.com with ESMTPS id ew5sm10450471pbc.9.2013.04.18.09.42.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 09:42:06 -0700 (PDT) Message-ID: <5170225e.c5b8440a.548f.3e8b@mx.google.com> Date: Thu, 18 Apr 2013 09:41:53 -0700 From: "Adrian Chadd" To: "John Baldwin" , "Adrian Chadd" Subject: Re: Atheros 9287 - no carrier . revision 249623. In-Reply-To: <201304181137.17627.jhb@freebsd.org> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Artyom Mirgorodskiy , "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:42:07 -0000 =2E.. Why would it differ for the same machine, different kernel? Adrian Sent from my Palm Pre on AT&T On Apr 18, 2013 8:40 AM, John Baldwin <jhb@freebsd.org> wrote:=20 On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > Ok, the relevant / interesting bit:s. John, any ideas? Only that this means absolutely nothing? These are the values the BIOS wro= te=20 into the registers which we use as hints about whether or not ACPI lies abo= ut=20 which interrupts are used when APIC is disabled. The actually useful messa= ge shows the same interrupts used in both cases: > HEAD: >=20 > pcib2: slot 0 INTA hardwired to IRQ 18 > ath0: <Atheros 9287> mem 0xe0500000-0xe050ffff irq 18 at device= 0.0 on pci10 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 >=20 > versus >=20 > pcib2: slot 0 INTA hardwired to IRQ 18 > ath0: <Atheros 9287> mem 0xe0500000-0xe050ffff irq 18 at device= 0.0 on pci10 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 17:06:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 345CDCDE; Thu, 18 Apr 2013 17:06:44 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 543C9D1C; Thu, 18 Apr 2013 17:06:43 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id d10so1346394eaj.11 for ; Thu, 18 Apr 2013 10:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=DqdgZsiDwNTzHrvAqeB4dRGwvrs9KQARb6ux14emh18=; b=BIPYU+sUoW5+aFWN7XoEsV929LY4y7t6MQE1Wq0jsrPsk7k9kd8q7ySilxlo21XJ/4 t9hj6npMrAeLjCiYgSarVETnVwm0QMCfMV0yK7T1xf7BBrG6xLIvCc+HAUIEq8raiKBl M+RTgVLo7aNl6kYEgRTSXcZIv78ymqlx63IPErOb2WSE5hTH/lMt0hebErZsOki/jQZ8 o+h3lPlwCPwSILodoefrZeaujrbm5zv0pcEpjx5kheCuTXU/kg/pvBVMK196F215jgiA O4Afr9RZmT76HJvDUGZO4qqOfWesO9EsyBs3O5cDrejmgTyQUlXdiFsKWC400edWqWX2 2JWw== X-Received: by 10.14.104.6 with SMTP id h6mr32054983eeg.5.1366304801934; Thu, 18 Apr 2013 10:06:41 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id x42sm17242075eee.0.2013.04.18.10.06.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 10:06:41 -0700 (PDT) From: Artyom Mirgorodskiy To: John Baldwin Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 20:05:59 +0300 Message-ID: <3591293.X8VkCk8bg8@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: <201304181137.17627.jhb@freebsd.org> References: <1645676.6Cz3TLlJG5@home.alkar.net> <201304181137.17627.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , freebsd-wireless@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 17:06:44 -0000 I tried to check out revision 245031 (only sys/dev/ath) and got a working WiFi. I'll try to find a broken revision. On Thursday 18 April 2013 11:37:17 John Baldwin wrote: > On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > > Ok, the relevant / interesting bit:s. John, any ideas? > > Only that this means absolutely nothing? These are the values the BIOS wrote > into the registers which we use as hints about whether or not ACPI lies about > which interrupts are used when APIC is disabled. The actually useful message > shows the same interrupts used in both cases: > > > HEAD: > > > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > > > versus > > > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 17:30:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75F244A1; Thu, 18 Apr 2013 17:30:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by mx1.freebsd.org (Postfix) with ESMTP id 41BE4E06; Thu, 18 Apr 2013 17:30:53 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id z10so1708043pdj.30 for ; Thu, 18 Apr 2013 10:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:to:cc:reply-to:subject:in-reply-to :x-mailer:mime-version:content-type; bh=6q5nKwM1zV+V1QA051G8taaLszHX3/0GMzCovkHV2nU=; b=jRC+pvrCcYqorRjzz/iyBH3jKbwNfb99SHtWF+F9zzqhQBewJH7lmqrpw6/PnHpWOE AhPXfYaZTaY/I++gs+J8srDEaKrHnjEwLSi0PD0aQfl9XITpOgC+u3Y81rImLvOhHk04 x2Dh3Jo/GWbdWL3VfQagq6WbIIPdvR3MRO0MAajEqQPQyHX//wg8xIyr5qFfL2OZ5PE7 xXUoKFM8hIaeiNTL5xvXs4fOgNMjkHv0HHxu4+43h83ilbpPoIcLYIp3ydi58pLcGkeZ XhlibV2QkMSETzZkDemtktov8cef/fjlH6KQUedhZO888BnXX6zX59Pd3FJqwddG/NfJ 5lvw== X-Received: by 10.68.88.129 with SMTP id bg1mr14561359pbb.10.1366306247598; Thu, 18 Apr 2013 10:30:47 -0700 (PDT) Received: from www.palm.com ([32.158.149.109]) by mx.google.com with ESMTPS id vk7sm10505223pbc.41.2013.04.18.10.30.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 10:30:46 -0700 (PDT) Message-ID: <51702dc6.87ee440a.57aa.327e@mx.google.com> Date: Thu, 18 Apr 2013 10:30:33 -0700 From: "Adrian Chadd" To: "Artyom Mirgorodskiy" , "John Baldwin" Subject: Re: Atheros 9287 - no carrier . revision 249623. In-Reply-To: <3591293.X8VkCk8bg8@home.alkar.net> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 17:30:53 -0000 On head? Adrian Sent from my Palm Pre on AT&T On Apr 18, 2013 10:06 AM, Artyom Mirgorodskiy <artyom.mirgorodsky@gmail.= com> wrote:=20 I tried to check out revision 245031 (only sys/dev/ath) and got a working= WiFi. I'll try to find a broken revision.   On Thursday 18 April 2013 11:37:17 John Baldwin wrote: > On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > > Ok, the relevant / interesting bit:s. John, any ideas? >=20 > Only that this means absolutely nothing? These are the values the BIO= S wrote=20 > into the registers which we use as hints about whether or not ACPI lie= s about=20 > which interrupts are used when APIC is disabled. The actually useful= message > shows the same interrupts used in both cases: >=20 > > HEAD: > >=20 > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: <Atheros 9287> mem 0xe0500000-0xe050ffff irq 18 at de= vice 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > >=20 > > versus > >=20 > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: <Atheros 9287> mem 0xe0500000-0xe050ffff irq 18 at de= vice 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 >=20 >=20 --=20 Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 17:37:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 361A68B9; Thu, 18 Apr 2013 17:37:28 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 48FB3E52; Thu, 18 Apr 2013 17:37:27 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id f15so390720eak.6 for ; Thu, 18 Apr 2013 10:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=RFpThFEOd2bnoaSsHe6LJb+D3UhBGAZ5gDpIzgMBBnE=; b=N+z9D3giKqhji61B9xUlWAI23pQ5sCQIetsuezLveNwKk3gkZemqHCejGgVwvmAjYV peQ0C2887Gp1y7f57yteIV1xW5/i3T/G2vnuSVoGsiNZG3ioHMSdvBBzDqBbFP2f1Oya otLkOQAFrLwwcjoR6oXI7Rz2Z/Ld7485lRgDYehHgVIp/pgZ33XDmkAWKbHDN+Qcfwg5 q0T4bYAtpRUu6DwjXVe7RaglcFQfopm4i/ZGVrs8CfgDAN0q98hPt4emykbk4sbV4gRO zDoa6ZLkGAGMwLXMvp7ZqgNsjlX9eI/Lc05DRyC48r3IOVIzMJ5AmdrZ55jw2JPkgnxo YkCQ== X-Received: by 10.14.174.5 with SMTP id w5mr32721598eel.1.1366306645859; Thu, 18 Apr 2013 10:37:25 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id i53sm17395136eeu.5.2013.04.18.10.37.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 10:37:25 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 20:36:43 +0300 Message-ID: <2271040.usaorIa3D6@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: <51702dc6.87ee440a.57aa.327e@mx.google.com> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 17:37:28 -0000 Yes On Thursday 18 April 2013 10:30:33 Adrian Chadd wrote: On head? Adrian Sent from my Palm Pre on AT&T -------------------- Artyom MirgorodskiyOn Apr 18, 2013 10:06 AM, wrote: I tried to check out revision 245031 (only sys/dev/ath) and got a working WiFi. I'll try to find a broken revision. On Thursday 18 April 2013 11:37:17 John Baldwin wrote: > On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > > Ok, the relevant / interesting bit:s. John, any ideas? > > Only that this means absolutely nothing? These are the values the BIOS wrote > into the registers which we use as hints about whether or not ACPI lies about > which interrupts are used when APIC is disabled. The actually useful message > shows the same interrupts used in both cases: > > > HEAD: > > > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > > > versus > > > > pcib2: slot 0 INTA hardwired to IRQ 18 > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > -- Artyom Mirgorodskiy -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 17:42:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8BB8DFD; Thu, 18 Apr 2013 17:42:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id 2617AE94; Thu, 18 Apr 2013 17:42:16 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hq17so3377391wib.5 for ; Thu, 18 Apr 2013 10:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u2Rn7KoqYdq7XuYyezgbHJxjYlgYn4pQAp4O4ilSLCo=; b=wE05ALEZJv626Zb/LGz6wC1DBKOpnix8jsLPWKubkcBsPEVEawPAq4y+4xWyID5hdQ sKgFRcJTA4WZ+0JHjL45F33A2d7O1lDByAYgirbSTQVwTwFGmwhtt+DrugLdYMXe7WPy eJwMCh/MxFmDvJUl7Lz/aZ4uJ7MIZEq/0JZoHsHk0ooK50aiqwZEKySfvVgqEV3Exxz9 dlTReAkKhrGhPBCVKsPHdnna8Bp4FZqz2sV7OWDC50j7aDi4QfppRyU8+G8EbGtnQwmv 1tEN/1yrpv0rW0CL2ppc/HagzImPcr2RlxKYDKsG/UjLGruE9SFEdLV1p4WC4OHgMPxr 2DUw== MIME-Version: 1.0 X-Received: by 10.180.211.50 with SMTP id mz18mr35063394wic.24.1366306935291; Thu, 18 Apr 2013 10:42:15 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 10:42:15 -0700 (PDT) In-Reply-To: <2271040.usaorIa3D6@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <2271040.usaorIa3D6@home.alkar.net> Date: Thu, 18 Apr 2013 10:42:15 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 17:42:16 -0000 Hm, so -HEAD everything else except the wifi code? That's really odd. I updated to -HEAD this morning just to test the AR9287 for you and it was peachy! Adrian On 18 April 2013 10:36, Artyom Mirgorodskiy wrote: > Yes > > > > On Thursday 18 April 2013 10:30:33 Adrian Chadd wrote: > > On head? > > > > Adrian > > > > Sent from my Palm Pre on AT&T > > ________________________________ > > Artyom MirgorodskiyOn Apr 18, 2013 10:06 AM, > wrote: > > I tried to check out revision 245031 (only sys/dev/ath) and got a working > WiFi. I'll try to find a broken revision. > > > > On Thursday 18 April 2013 11:37:17 John Baldwin wrote: > >> On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > >> > Ok, the relevant / interesting bit:s. John, any ideas? > >> > >> Only that this means absolutely nothing? These are the values the BIOS >> wrote > >> into the registers which we use as hints about whether or not ACPI lies >> about > >> which interrupts are used when APIC is disabled. The actually useful >> message > >> shows the same interrupts used in both cases: > >> > >> > HEAD: > >> > > >> > pcib2: slot 0 INTA hardwired to IRQ 18 > >> > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on >> > pci10 > >> > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > >> > > >> > versus > >> > > >> > pcib2: slot 0 INTA hardwired to IRQ 18 > >> > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on >> > pci10 > >> > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > >> > >> > > -- > > Artyom Mirgorodskiy > > > -- > > Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 18:59:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7EF42D66; Thu, 18 Apr 2013 18:59:22 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id DAFA514C7; Thu, 18 Apr 2013 18:59:21 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so1388350eaj.36 for ; Thu, 18 Apr 2013 11:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=kRUAIGiZHkbH565jx0cRJZTnddWGMAiHfxV13WuijXc=; b=nNHAA1Z8KoeIsEPOeFN12HfC2RhLUvi/Y+qs0OFMr+LBgIzVvVkhRfrS14qF7J/mDK slzWuMj/cCHwo4WRHI0NU+fQNrNoomj4zcBImNUEYYJwDi3kpWVoCZDinU/5Dd12KC+8 rfCAoyFyeQl3WwsxDJycXcs0WWZdy5nHpm5glTiTV7qm/KIRHkHEuDVl2G+c2oi4VSIx Hq4tSQmGtBVqb003Y2ATy0HjioNOUDytAvOelrV7W40EUYWx3s1K+6i5ymYsfvt+EvIV rdt1Daq2bb0ntmkEWtmXyV+82NZczOBaK4azLJgpigS1ZYAj4KTZNNVIeGfJtXuuIlMe ihUQ== X-Received: by 10.14.177.197 with SMTP id d45mr12020381eem.9.1366311560950; Thu, 18 Apr 2013 11:59:20 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id x42sm17881432eee.0.2013.04.18.11.59.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 11:59:20 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 21:58:38 +0300 Message-ID: <4973597.pFY2WkjzUY@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <2271040.usaorIa3D6@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 18:59:22 -0000 Yes, HEAD everything else except the wifi code (ath). Last working revision is 247286. So problem in revision 247287. On Thursday 18 April 2013 10:42:15 Adrian Chadd wrote: > Hm, so -HEAD everything else except the wifi code? > > That's really odd. I updated to -HEAD this morning just to test the > AR9287 for you and it was peachy! > > > Adrian > > On 18 April 2013 10:36, Artyom Mirgorodskiy > wrote: > > Yes > > > > > > > > On Thursday 18 April 2013 10:30:33 Adrian Chadd wrote: > > > > On head? > > > > > > > > Adrian > > > > > > > > Sent from my Palm Pre on AT&T > > > > ________________________________ > > > > Artyom MirgorodskiyOn Apr 18, 2013 10:06 AM, > > wrote: > > > > I tried to check out revision 245031 (only sys/dev/ath) and got a working > > WiFi. I'll try to find a broken revision. > > > > > > > > On Thursday 18 April 2013 11:37:17 John Baldwin wrote: > > > >> On Thursday, April 18, 2013 11:22:38 am Adrian Chadd wrote: > > > >> > Ok, the relevant / interesting bit:s. John, any ideas? > > > >> > > > >> Only that this means absolutely nothing? These are the values the BIOS > >> wrote > > > >> into the registers which we use as hints about whether or not ACPI lies > >> about > > > >> which interrupts are used when APIC is disabled. The actually useful > >> message > > > >> shows the same interrupts used in both cases: > > > >> > > > >> > HEAD: > > > >> > > > > >> > pcib2: slot 0 INTA hardwired to IRQ 18 > > > >> > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on > >> > pci10 > > > >> > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > > >> > > > > >> > versus > > > >> > > > > >> > pcib2: slot 0 INTA hardwired to IRQ 18 > > > >> > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on > >> > pci10 > > > >> > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 > > > >> > > > >> > > > > -- > > > > Artyom Mirgorodskiy > > > > > > -- > > > > Artyom Mirgorodskiy -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 20:23:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F815AC8; Thu, 18 Apr 2013 20:23:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0741C09; Thu, 18 Apr 2013 20:23:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9E560B94F; Thu, 18 Apr 2013 16:23:06 -0400 (EDT) From: John Baldwin To: "Adrian Chadd" Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 16:06:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5170225e.c5b8440a.548f.3e8b@mx.google.com> In-Reply-To: <5170225e.c5b8440a.548f.3e8b@mx.google.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304181606.03110.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Apr 2013 16:23:06 -0400 (EDT) Cc: Artyom Mirgorodskiy , Adrian Chadd , "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 20:23:07 -0000 On Thursday, April 18, 2013 12:41:53 pm Adrian Chadd wrote: > > ... Why would it differ for the same machine, different kernel? I can't tell you why, but if you compare the full dmesg's you will see that several devices all changed their BIOS-assigned IRQs because the BIOS decided to shuffle the IRQs assigned to the PCI links around. That should all be moot since you are using the APIC anyway. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 20:31:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0F227F84; Thu, 18 Apr 2013 20:31:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 77D771DAD; Thu, 18 Apr 2013 20:31:30 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id h11so2646307wiv.4 for ; Thu, 18 Apr 2013 13:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9Vbo3M2DW2b0iRNaiOHqy6f2TwsnMAEV12r1Dmi6Sy8=; b=UvE9Y+S0Ffuy8+DeeSSo98TPibUmjx/5cjfxyQvAMlBuzAP06N7g0/lN8RHaxf7mVT bUL5DeKXFUlX3KSxozubmUzcTp0rY3z+e25Sz+/IEWhooi36eLCcMVvzNq2fj6Xjg76g rgQSoIpjR58lTVah9p+a/xGmYTVZjZ2OSIvOEBvTyXa59DKENxlMaXjA1cysGAQt+piC wxKHnw59+pze43XiOnWCItN5YxcamPMhDvhxKr3zFrU0Vm1By/C3DKEbbbG5etyBchFr +RmSiLn0YGMuTCseKaqRStU/kLfFr7BD9UVTumu/kJBXzBjdzboCP70xBRYMDM+CqG24 ii1A== MIME-Version: 1.0 X-Received: by 10.181.12.5 with SMTP id em5mr20807950wid.24.1366317089678; Thu, 18 Apr 2013 13:31:29 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 13:31:29 -0700 (PDT) In-Reply-To: <4973597.pFY2WkjzUY@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <2271040.usaorIa3D6@home.alkar.net> <4973597.pFY2WkjzUY@home.alkar.net> Date: Thu, 18 Apr 2013 13:31:29 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 20:31:31 -0000 On 18 April 2013 11:58, Artyom Mirgorodskiy wrote: > Yes, HEAD everything else except the wifi code (ath). > > Last working revision is 247286. So problem in revision 247287. That's really odd. It behaves perfectly fine on my system. You've tested 247287 and it breaks? Adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 20:34:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F4D616A; Thu, 18 Apr 2013 20:34:00 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id E5D0C1DDC; Thu, 18 Apr 2013 20:33:59 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id b47so472687eek.36 for ; Thu, 18 Apr 2013 13:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=B3QrN9EXzqv8/eBKjFGpAM3B4+LP8XZtktEbO2fSOWc=; b=Am81OopXQezfldE0BtzvbGcdapM6EKnnMLeR57g2nY7ejKcxnDHpMOwi79Ay7enO4J bmPNZwLTXil8GgITshWjFT2rinExMWhPqZzevHP0aWnsc1AlQB4NLiImaxuXw9mF0HVd /qG9f22q9Ewh2txre941rDW8tmA/lZNmKSNLtKGC1f37Q9rvvoS5ClIyefDEoD4JLAd8 rH2QXqDFyh5bBGfSkg/PFPzmQfpw5TYPoifg6eVjvrBpHQku5xmD2LeNbV48NL7t0LlM iQzbjas8uZ6vN03H2YVkk8Qe0mW2aR+z8s+Tf0Nbg4d/3zwhnA5I8GIFgeHHa5UMtiFT yVeg== X-Received: by 10.15.35.200 with SMTP id g48mr19754615eev.33.1366317238801; Thu, 18 Apr 2013 13:33:58 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id w51sm18327819eev.13.2013.04.18.13.33.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 13:33:58 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Thu, 18 Apr 2013 23:33:16 +0300 Message-ID: <1960650.d0sTaO7Dhi@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <4973597.pFY2WkjzUY@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 20:34:00 -0000 Yes. I tested 247287 and it breaks. On Thursday 18 April 2013 13:31:29 Adrian Chadd wrote: > On 18 April 2013 11:58, Artyom Mirgorodskiy > wrote: > > Yes, HEAD everything else except the wifi code (ath). > > > > Last working revision is 247286. So problem in revision 247287. > > That's really odd. It behaves perfectly fine on my system. > > You've tested 247287 and it breaks? > > > Adrian -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 20:58:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F2E782C; Thu, 18 Apr 2013 20:58:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D87148A; Thu, 18 Apr 2013 20:58:24 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so2727291wey.25 for ; Thu, 18 Apr 2013 13:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OJ3DEmPx9LioJTEdSwweBzlshkSGxOWqNqsD0OonYEY=; b=aCwz3++lZq+Ewn3DEglC4iHStaGlKontF+M1Q1CITYG0FwD5zeKpaqpbhdOp2y0hFy uYgPEkkbomk836pCoFE8OolWF39e5PTzRPNgFDvZpm/0UsN0ILzd8tN4+bibqhYNXz4T sapSbw8iTx/9v52UikoFbOCOK4GM/7ba/3aTNFvD799PVyb5cYy2MXRfXTVvjMoLbFb6 9RvBut4kKkyfXsEEWGzc2rjVA1J/Eowl2fqrlD6MLO1fKhnToMxHKIZOwuUHibevFCNW yMT72r1+0+HLRV5jOVkeU5BXnfhIm7v4XJkynY8pnYA7jv//majVRsWoUUfyFR0IsRRS 2bAg== MIME-Version: 1.0 X-Received: by 10.180.37.101 with SMTP id x5mr831867wij.0.1366318704088; Thu, 18 Apr 2013 13:58:24 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 13:58:23 -0700 (PDT) In-Reply-To: <1960650.d0sTaO7Dhi@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <4973597.pFY2WkjzUY@home.alkar.net> <1960650.d0sTaO7Dhi@home.alkar.net> Date: Thu, 18 Apr 2013 13:58:23 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 20:58:25 -0000 On 18 April 2013 13:33, Artyom Mirgorodskiy wrote: > Yes. I tested 247287 and it breaks. Hm. Well, not much changed there. Try going to 247287 (ie, the broken revision), but revert head/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c to 247286. See if that fixes it. Adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 21:50:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21FACA9C; Thu, 18 Apr 2013 21:50:29 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5763EE; Thu, 18 Apr 2013 21:50:28 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id m14so1455823eaj.19 for ; Thu, 18 Apr 2013 14:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=G7kKSv6sZOQhmx4r6yfgubknHQM7uhNLaqkcX7jHcak=; b=eCz5fSWhiqrE6UEhX7hjHJzcWTv6EvRWKl2VkAff94Du8AfC3Wzy2x+RBlXUL599XG KJjm3q0ECVjhyCYxMQzuC5LCqRZtJF6I9Kq4rvIMIiAxZEwBqw91aLCklMNesYUlTT7H jeVU/7spvZKSA8Fvwy94xBjxm/fkq/87EjrJChPzVYfEOnN2HSugwCzpswU+mF9RuBwp zkXYFYZNupFNHzrAopheCRaPB6ZM+jkNZF7qvMKU8GVswr65ciBeqwRsKwl64Gi/YgxA i5NJP2xx9YvyuWixNktuldy/UVVvcRGoHoy1C36Z0IKrCYK1HLZmwKWaIKXvAX5HoeJX Rxlw== X-Received: by 10.15.98.66 with SMTP id bi42mr34183990eeb.39.1366321458042; Thu, 18 Apr 2013 14:44:18 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id a41sm18690400eei.4.2013.04.18.14.44.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 14:44:17 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 00:43:35 +0300 Message-ID: <3111674.jLbKQKCHzF@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <1960650.d0sTaO7Dhi@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 21:50:29 -0000 Did not work. On Thursday 18 April 2013 13:58:23 Adrian Chadd wrote: > On 18 April 2013 13:33, Artyom Mirgorodskiy > wrote: > > Yes. I tested 247287 and it breaks. > > Hm. > > Well, not much changed there. > > Try going to 247287 (ie, the broken revision), but revert > head/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c to 247286. > > See if that fixes it. > > > > Adrian -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 21:51:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 108C7BBB; Thu, 18 Apr 2013 21:51:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2EC3F3; Thu, 18 Apr 2013 21:51:06 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id r6so2799732wey.12 for ; Thu, 18 Apr 2013 14:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mwhu8F67y27dn7BtWNc6SnvnH36uI1xMpGctknNQIn4=; b=Ar05ZQzKciUlWMylmgVN2vlJuMPKbTjqjeeCOaSef9/r4QPTJx+NUyHakYQxjEH0oc YcVDgN6lLyNOY3NTIAxJxF6ha1Ov9A2pgc4Inv+c2mHI7E8wghAoeiV0mNrJrjMJef4F 9nkGzzEC5jWtc8MkZjJk/CRy4OXvzUnHdJsikbTpVoq6uqeE8XpAQ7uZ0hWLNNm/xwSr CxiUMTSnW7gJDhw6HIPRHrrHrHWYGvhc4dy0AEe39OHxpKnmZ1aKqkrjUMbp2qNChToL 8YeLvbcqv0h88aAAzUrJRHvlvITL1Gp/yFyMRSimMuQwauKDUBfKelkylvfzi8SXvq9B ZJJQ== MIME-Version: 1.0 X-Received: by 10.194.158.42 with SMTP id wr10mr21638972wjb.23.1366321865583; Thu, 18 Apr 2013 14:51:05 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 14:51:05 -0700 (PDT) In-Reply-To: <3111674.jLbKQKCHzF@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <1960650.d0sTaO7Dhi@home.alkar.net> <3111674.jLbKQKCHzF@home.alkar.net> Date: Thu, 18 Apr 2013 14:51:05 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 21:51:07 -0000 On 18 April 2013 14:43, Artyom Mirgorodskiy wrote: > Did not work. > Hm. Ok. Let's add some debugging: inside of ar5416SetChainMasks(), let's add a printf() at the -end- of the function: ath_hal_printf(ah, "%s: txchainmask=0x%x, rxchainmask=0x%x\n", __func__, AH5416(ah)->ah_tx_chainmask, AH5416(ah)->ah_rx_chainmask); Then recompile, reboot, and show me the output of 'dmesg' From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 22:08:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF501D9; Thu, 18 Apr 2013 22:08:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 240B2680; Thu, 18 Apr 2013 22:08:36 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so2876474wey.11 for ; Thu, 18 Apr 2013 15:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C3/MZJRJnL8BFXM7PnIAvnHcbQ1/jpke2AY8CPU+Eig=; b=KoTT0NcyxpsvP99liD6pLKAQUqhLtTmxEVfIEB9vPlIfqL/vGwEjKQeutd44QeQbbA IgnkzcgTjgpqJM+J4g8SpHM4D/XUAeWoKMc6w518ksTMSCBFGZSkq9lim8AUi5kMGlk7 pyEfWNrIRYpaAC5zDQhBrn/wxXKR8ijInnDZ1w5bchvjGC/ZtPDJTM4WDdfDizkb5nMN Qdwqp23qZseb/gaUTM6mRPiTNBsQBL1Dm9uFJ/VXRrH8x0kRAeIJKD7MWPxTKUQWFfjS WAf6rCJSgxzq2PuIzmJzvAv0jYgffSWp24mR5am4Q0iteEX4+ix/i63TM3yLtXoDypHR Vp5g== MIME-Version: 1.0 X-Received: by 10.194.142.236 with SMTP id rz12mr21915556wjb.12.1366322916219; Thu, 18 Apr 2013 15:08:36 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 15:08:36 -0700 (PDT) In-Reply-To: <2163177.OYO9r9Iusv@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <3111674.jLbKQKCHzF@home.alkar.net> <2163177.OYO9r9Iusv@home.alkar.net> Date: Thu, 18 Apr 2013 15:08:36 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 22:08:37 -0000 On 18 April 2013 15:07, Artyom Mirgorodskiy wrote: > See attached > What the hell? Those masks are really wrong. Try adding this line after it: ath_hal_printf(ah, "%s: pcap rx=0x%x, tx=0x%x; configured rx=0x%x, tx=0x%x\n", __func__, pCap->halRxChainMask, pCap->halTxChainMask, rx_chainmask, tx_chainmask); From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 22:22:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E841C505; Thu, 18 Apr 2013 22:22:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDAA75A; Thu, 18 Apr 2013 22:22:50 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hq17so5172478wib.17 for ; Thu, 18 Apr 2013 15:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hZn28ely03Wtj3XpU1j1IwiEAsUYWs89rX5TZY+6QK4=; b=FUzwxUePPIurdRjxfsBdI/lm6oAGOxFNE1qgdI6s9NRQNUKYAb3hWuGKkdakhOrh7Q RDJN/DDn6xixqSlhWuCsvoo76z5+Os1FpE0HuMPRDdpCUuppZoT13Xq75mxUnc6hIEIS vRMwPxJeRjjOMddqog9AYxnmr6eAcEyRG1uQMyrRvB83yhbfiWSfPDZfGUbdXXdwkJV/ pl5K0zopxzlZHyo4iwYD3jLA7DF+8+KRCfoYpjpom6nHLKTz8cJ2ZPjggj2nggba2JVU D8Zqh9y9vKvKo3UdFGwZjp+vZsFdgVIButbe8OniYm+tPDUvdFTFiToAzdgffFuwY/+j 9GdA== MIME-Version: 1.0 X-Received: by 10.194.158.42 with SMTP id wr10mr21746327wjb.23.1366323769482; Thu, 18 Apr 2013 15:22:49 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 15:22:49 -0700 (PDT) In-Reply-To: <1436485.TxcZPeTyQ4@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <2163177.OYO9r9Iusv@home.alkar.net> <1436485.TxcZPeTyQ4@home.alkar.net> Date: Thu, 18 Apr 2013 15:22:49 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 22:22:51 -0000 Hm! I wonder.. Edit if_athvar.h - change sc_rxchainmask and sc_txchainmask in ath_softc to be uint32_t, rather than int. See if that helps. Adrian On 18 April 2013 15:20, Artyom Mirgorodskiy wrote: > See attached > > > > On Thursday 18 April 2013 15:08:36 Adrian Chadd wrote: > >> On 18 April 2013 15:07, Artyom Mirgorodskiy > >> wrote: > >> > See attached > >> > > >> > >> What the hell? Those masks are really wrong. > >> > >> Try adding this line after it: > >> > >> ath_hal_printf(ah, "%s: pcap rx=0x%x, tx=0x%x; configured rx=0x%x, > >> tx=0x%x\n", __func__, pCap->halRxChainMask, pCap->halTxChainMask, > >> rx_chainmask, tx_chainmask); > > -- > > Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 22:26:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 356C8659; Thu, 18 Apr 2013 22:26:05 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 33F28773; Thu, 18 Apr 2013 22:26:04 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id z10so1465309ead.12 for ; Thu, 18 Apr 2013 15:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=tGgCnRfR6mdyorIiIFVPjxJqAFPTgFdFj2cer4cA6yw=; b=KEiiqot7x66Om5Nsm27RwXkysSn6ivmeCzypoRIC/GEPrP8d51XtqMzjmQleE2ig4f 8XwuLtPasM7ejkZi6EZo/iquP6SG9s/x4NjMAN327x27Z8ZNsK8SuRiX4RP6Ud8ZOiv3 wT28Z77nHhWENZ4PCfdOAxcJFWx55LFPSyBfDjHMF0LpIRdD3FKLwmVBhxhtw/xU2vIh 7rTqd9xYF3bqAsZdatNQWknrWSRhZlU7P3DlIv+KH7NkRo+M9bdpsOOoS2/gcNwITDeD gbdXIHrwrVfCi3wb0Yae2tmPd3Ftsw0O712GpuZndA+aOLTYeCWMuFTbJUUm622QKmtI sgmQ== X-Received: by 10.14.177.197 with SMTP id d45mr13681680eem.9.1366323509331; Thu, 18 Apr 2013 15:18:29 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id a41sm18826519eei.4.2013.04.18.15.18.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 15:18:28 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 01:20:10 +0300 Message-ID: <1436485.TxcZPeTyQ4@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <2163177.OYO9r9Iusv@home.alkar.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1571758.2dmMsHNfry" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 22:26:05 -0000 This is a multi-part message in MIME format. --nextPart1571758.2dmMsHNfry Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" See attached On Thursday 18 April 2013 15:08:36 Adrian Chadd wrote: > On 18 April 2013 15:07, Artyom Mirgorodskiy > wrote: > > See attached > > > > What the hell? Those masks are really wrong. > > Try adding this line after it: > > ath_hal_printf(ah, "%s: pcap rx=0x%x, tx=0x%x; configured rx=0x%x, > tx=0x%x\n", __func__, pCap->halRxChainMask, pCap->halTxChainMask, > rx_chainmask, tx_chainmask); -- Artyom Mirgorodskiy --nextPart1571758.2dmMsHNfry Content-Disposition: attachment; filename="dmesg" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="dmesg" Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff811991d000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: GEOM: new disk ada0 lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097536930 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled nfslock: pseudo-device wlan0: link state changed to UP agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, vnodes remaining...15 15 3 4 3 2 1 0 1 0 0 0 done All buffers synced. Table 'FACP' at 0xcafef000 Table 'SSDT' at 0xcaffd000 Table 'SSDT' at 0xcaffc000 Table 'SSDT' at 0xcaffb000 Table 'ASF!' at 0xcaff1000 Table 'HPET' at 0xcafee000 Table 'APIC' at 0xcafed000 APIC: Found table at 0xcafed000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 0 ACPI ID 5: disabled MADT: Found CPU APIC ID 0 ACPI ID 6: disabled MADT: Found CPU APIC ID 0 ACPI ID 7: disabled MADT: Found CPU APIC ID 0 ACPI ID 8: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r249620: Thu Apr 18 15:17:57 EEST 2013 root@home.alkar.net:/usr/obj/usr/src/sys/Work amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cdd000. Preloaded elf obj module "/boot/kernel/msdosfs.ko" at 0xffffffff80cdd950. Preloaded elf obj module "/boot/kernel/if_ath.ko" at 0xffffffff80cddef8. Preloaded elf obj module "/boot/kernel/wlan.ko" at 0xffffffff80cde6a0. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff80cdef08. Preloaded elf obj module "/boot/kernel/uhid.ko" at 0xffffffff80cdf4b0. Preloaded elf obj module "/boot/kernel/usb.ko" at 0xffffffff80cdfa18. Preloaded elf obj module "/boot/kernel/if_ath_pci.ko" at 0xffffffff80ce0080. Preloaded elf obj module "/boot/kernel/uhci.ko" at 0xffffffff80ce05b0. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0xffffffff80ce0ad8. Preloaded elf obj module "/boot/kernel/msdosfs_iconv.ko" at 0xffffffff80ce1000. Preloaded elf obj module "/boot/kernel/libiconv.ko" at 0xffffffff80ce14b0. Preloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff80ce1ae0. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80ce2090. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80ce25b8. Calibrating TSC clock ... TSC clock: 2195063264 Hz CPU: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz (2195.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000d02000 - 0x00000000bfa37fff, 3201523712 bytes (781622 pages) 0x0000000100000000 - 0x000000012fde7fff, 803110912 bytes (196072 pages) avail memory = 3829579776 (3652 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000244000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse4BSD v0.1.27 @ /dev/cuse wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: ctl: CAM Target Layer loaded acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/2 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff811991c000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (GEOM: new disk ada0 ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097531632 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 nfslock: pseudo-device ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: pcap rx=0x3, tx=0x3; configured rx=0x0, tx=0x1 --nextPart1571758.2dmMsHNfry-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 22:34:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0516A898; Thu, 18 Apr 2013 22:34:43 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 088357CB; Thu, 18 Apr 2013 22:34:41 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id f15so498630eak.20 for ; Thu, 18 Apr 2013 15:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=3GLRkXGC5qL3wgrCVASq/89nJkemZ1DGVBjkjukiP20=; b=UPI9tXC6WkFCCCbbzTYFx/qZu4bTPy5t4Mc5vmELEPkQqEtaRGLgDCDnT+bHAaUUyp 0XyiTZhm/doJDbtVpEzWlI0TeTU7Z0Y8WozKvbOiV2BxZaViUJ+4JJfVhxwbk3ZR/IGo NaA7VjJgZvYyaZ/6wwBG/b310p1jWSqsJFbS0mCWa0PV2QOnF5aPcZ4Zgpy5yjWRbU3C DJxySez/fQTbAwTgYgfdvgg85/ic6seQwDOJsPjstP59HLomK7vWB5aZBjD8j/Ql4qbg uJUPJVyUUDqh4vSY5rW0aNE8/65MqMkGCfU7FL+ontyGyR3JybMN4s0F26xqD0wTeNCv HXEA== X-Received: by 10.14.214.65 with SMTP id b41mr34744435eep.37.1366322724389; Thu, 18 Apr 2013 15:05:24 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id b5sm18734273eew.16.2013.04.18.15.05.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 15:05:23 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 01:07:05 +0300 Message-ID: <2163177.OYO9r9Iusv@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <3111674.jLbKQKCHzF@home.alkar.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1870388.Wo2bHCjrVt" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 22:34:43 -0000 This is a multi-part message in MIME format. --nextPart1870388.Wo2bHCjrVt Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" See attached On Thursday 18 April 2013 14:51:05 Adrian Chadd wrote: > On 18 April 2013 14:43, Artyom Mirgorodskiy > wrote: > > Did not work. > > > > Hm. Ok. > > Let's add some debugging: > > inside of ar5416SetChainMasks(), let's add a printf() at the -end- of > the function: > > ath_hal_printf(ah, "%s: txchainmask=0x%x, rxchainmask=0x%x\n", > __func__, AH5416(ah)->ah_tx_chainmask, AH5416(ah)->ah_rx_chainmask); > > Then recompile, reboot, and show me the output of 'dmesg' -- Artyom Mirgorodskiy --nextPart1870388.Wo2bHCjrVt Content-Disposition: attachment; filename="dmesg" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="dmesg" ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/2 1/3 1/2 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff811991d000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (GEOM: new disk ada0 ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097533302 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled nfslock: pseudo-device wlan0: link state changed to UP agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...13 4 4 0 2 0 1 0 0 done All buffers synced. Table 'FACP' at 0xcafef000 Table 'SSDT' at 0xcaffd000 Table 'SSDT' at 0xcaffc000 Table 'SSDT' at 0xcaffb000 Table 'ASF!' at 0xcaff1000 Table 'HPET' at 0xcafee000 Table 'APIC' at 0xcafed000 APIC: Found table at 0xcafed000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 0 ACPI ID 5: disabled MADT: Found CPU APIC ID 0 ACPI ID 6: disabled MADT: Found CPU APIC ID 0 ACPI ID 7: disabled MADT: Found CPU APIC ID 0 ACPI ID 8: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r249620: Thu Apr 18 15:17:57 EEST 2013 root@home.alkar.net:/usr/obj/usr/src/sys/Work amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cdd000. Preloaded elf obj module "/boot/kernel/msdosfs.ko" at 0xffffffff80cdd950. Preloaded elf obj module "/boot/kernel/if_ath.ko" at 0xffffffff80cddef8. Preloaded elf obj module "/boot/kernel/wlan.ko" at 0xffffffff80cde6a0. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff80cdef08. Preloaded elf obj module "/boot/kernel/uhid.ko" at 0xffffffff80cdf4b0. Preloaded elf obj module "/boot/kernel/usb.ko" at 0xffffffff80cdfa18. Preloaded elf obj module "/boot/kernel/if_ath_pci.ko" at 0xffffffff80ce0080. Preloaded elf obj module "/boot/kernel/uhci.ko" at 0xffffffff80ce05b0. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0xffffffff80ce0ad8. Preloaded elf obj module "/boot/kernel/msdosfs_iconv.ko" at 0xffffffff80ce1000. Preloaded elf obj module "/boot/kernel/libiconv.ko" at 0xffffffff80ce14b0. Preloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff80ce1ae0. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80ce2090. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80ce25b8. Calibrating TSC clock ... TSC clock: 2195072612 Hz CPU: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz (2195.07-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000d02000 - 0x00000000bfa37fff, 3201523712 bytes (781622 pages) 0x0000000100000000 - 0x000000012fde7fff, 803110912 bytes (196072 pages) avail memory = 3829579776 (3652 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000244000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse4BSD v0.1.27 @ /dev/cuse wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: ctl: CAM Target Layer loaded acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/2 1/3 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff811991c000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (GEOM: new disk ada0 ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097536306 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen1.2: at usbus1 uhub2: on usbus1 ugen0.2: at usbus0 uhub3: on usbus0 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 nfslock: pseudo-device ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 ar5416SetChainMasks: txchainmask=0x1, rxchainmask=0x0 --nextPart1870388.Wo2bHCjrVt-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 23:05:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D4F8135; Thu, 18 Apr 2013 23:05:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 11D2F90A; Thu, 18 Apr 2013 23:05:25 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t57so2914433wey.18 for ; Thu, 18 Apr 2013 16:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7xeM830R16i/T8nFUHhI+w4MrKn2NzHHFKTB0X9nb6M=; b=QoGIVKen4eRY0fCk7/PBUy3mPV//1r+EYC9FHlgmPG1+k19HblabxRI3lP0u9sLAvS jIloUHf+i6B9qmZC0KMk+9iWGLUfSrJEegzKoelgRASakBRG+lUKD8qyFCnsZlhwi1e4 jtlU4vqaTujS3clt+vSqoud2SnP3CXNOvqqsMb0g3uBD/XaFgUH+18JtZY+l3xtRysq5 2wWzAMHUKvZpL/A1G34izKg1u1M2unrPbEYZ2PepXUcA0imjCvAK5/pBCT+zh2hnx+jj tXWmN62tjrYgZgCouO1ZCpkOinEmc/89YVG8lyy5UzgExSQAsgrdB/MlvgqKpg7slSPj nZwQ== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr21323640wiv.27.1366326325120; Thu, 18 Apr 2013 16:05:25 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Thu, 18 Apr 2013 16:05:24 -0700 (PDT) In-Reply-To: <1825476.qO1YuZaJ09@home.alkar.net> References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <1436485.TxcZPeTyQ4@home.alkar.net> <1825476.qO1YuZaJ09@home.alkar.net> Date: Thu, 18 Apr 2013 16:05:24 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 23:05:26 -0000 On 18 April 2013 15:54, Artyom Mirgorodskiy wrote: > Nothing :( Ok, so I wonder now whether we're actually getting the right chainmask at startup. edit if_ath.c, look for 'ath_hal_getrxchainmask()' After the rx/tx chainmask is fetched,a dd this: device_printf(sc->sc_dev, "%s: RX chainmask=0x%x, TX chainmask=0x%x\n", sc->sc_rxchainmask, sc->sc_txchainmask); Adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 18 23:23:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18DEE642; Thu, 18 Apr 2013 23:23:29 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0BD9B0; Thu, 18 Apr 2013 23:23:28 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id z10so1477553ead.12 for ; Thu, 18 Apr 2013 16:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=5VFm90aSZQcDXsOB+Zfuw4sv1AuTx76ZlFOdGhCKpgE=; b=gKk68Fdt/rudo+EKujyGxyx+6tFHwxBWT9FsWI2ga64UYrANV/9zzpj4BuzCiZyocZ w4MGfPA/ZEHmucdttJmw12QkzyApPbv68XxwV1dQ62R9Uh+61LauwcnIMIXGlnTYx5zG 5m5UOLpE739WkQzNiBxIaGD5jenPEH0agbGIN7wLt5Wp2QchIVStHupVCKPKUC2sZAX8 b7/UOaIgtenDrYVWAKADweijF+9iVE/6B3zfmrLcLXvJRuDPPCf4TFRJA3SZIaNHQU2P ly8IedY/Trd5jzGQ3IHfV1kO2QxOgH+wnLSVC+s2OsxQ0LGVYwre/4bOnciM45VG/Sri u5mw== X-Received: by 10.15.95.74 with SMTP id bc50mr10013513eeb.36.1366325559901; Thu, 18 Apr 2013 15:52:39 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id d47sm18926590eem.9.2013.04.18.15.52.38 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 15:52:39 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 01:54:21 +0300 Message-ID: <1825476.qO1YuZaJ09@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <51702dc6.87ee440a.57aa.327e@mx.google.com> <1436485.TxcZPeTyQ4@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 23:23:29 -0000 Nothing :( On Thursday 18 April 2013 15:22:49 Adrian Chadd wrote: > Hm! I wonder.. > > Edit if_athvar.h - change sc_rxchainmask and sc_txchainmask in > ath_softc to be uint32_t, rather than int. > > See if that helps. > > > > Adrian > > On 18 April 2013 15:20, Artyom Mirgorodskiy > wrote: > > See attached > > > > > > > > On Thursday 18 April 2013 15:08:36 Adrian Chadd wrote: > > > >> On 18 April 2013 15:07, Artyom Mirgorodskiy > > > >> wrote: > > > >> > See attached > > > >> > > > > >> > > > >> What the hell? Those masks are really wrong. > > > >> > > > >> Try adding this line after it: > > > >> > > > >> ath_hal_printf(ah, "%s: pcap rx=0x%x, tx=0x%x; configured rx=0x%x, > > > >> tx=0x%x\n", __func__, pCap->halRxChainMask, pCap->halTxChainMask, > > > >> rx_chainmask, tx_chainmask); > > > > -- > > > > Artyom Mirgorodskiy -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 02:04:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 831BEFB4 for ; Fri, 19 Apr 2013 02:04:44 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id E59A1FD for ; Fri, 19 Apr 2013 02:04:43 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id er20so3152700lab.0 for ; Thu, 18 Apr 2013 19:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=KhgoaEjNrFcfUJzq4semQ3/zVvb0Hoj2Gh1mLKZsz8U=; b=SMvf6Ild4t99O5w56B2yPpd0KP7ICL9/y5bMvBmJF4h6mHdNtOEzaVuahxCl3yHjPM ZPmZri/NmEw21KByyu/klCDvk2d5FjFxGkIoGstgkVS2jfr82aZlQuc9+wT4t0XnUHoi 8+Wn3vdQjjZeYL1+/MbuXBzTHk4lVgV09q2+OVB7NVc1JgT6X0OomCGrfS8n7ri5IP6U Z7aLgfhblL0/IFCifkkP74PmoeaMk80hHMkvT+LP7JAcgpXqXjM5ny5F9OMh7vy3ND/n b2fVW94cDWyxF6fgftbgyv3UQupo9pA4CKsTxzhWeouE2U6XXJ+BpE+twSdBotRQvZHE q21w== MIME-Version: 1.0 X-Received: by 10.152.21.229 with SMTP id y5mr6801528lae.44.1366327628126; Thu, 18 Apr 2013 16:27:08 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Thu, 18 Apr 2013 16:27:07 -0700 (PDT) Date: Thu, 18 Apr 2013 16:27:07 -0700 X-Google-Sender-Auth: 9xxbky5LgmmDL7gBobald4vqoEU Message-ID: Subject: Cannot unmount nullfs in current From: Craig Rodrigues To: freebsd-current Current Content-Type: multipart/mixed; boundary=089e0158b374ebe3fa04daaaf0d5 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 02:04:44 -0000 --089e0158b374ebe3fa04daaaf0d5 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am trying to build some software which uses nanobsd, and mounts/unmounts many nullfs mounts while it runs. I am hitting failures where I cannot unmount nullfs file systems. I cannot figure out why. Here is more info. SYSTEM ====== I am running amd64, current build at this revision: 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r249181: Sat Apr 6 03:07:32 UTC 2013 amd64 STEPS TO REPRODUCE =============== (1) Create a directory, /opt2/branches. Make sure that /opt2/branches is on ZFS (2) mkdir -p /opt2/branches/freenas mkdir -p /opt2/branches/freenas-cache (3) git clone git://github.com/freenas/freenas.git /opt2/branches/freenas git clone git://github.com/freenas/ports.git/opt2/branches/freenas-cache/ports git clone git://github.com/trueos/trueos.git/opt2/branches/freenas-cache/trueos (4) sudo to root (5) cd /opt2/branches/freenas (6) script build.log env GIT_REPO=/opt2/branches/freenas-cache/trueos \ GIT_PORTS_REPO=/opt2/branches/freenas-cache/ports \ sh build/do_build.sh The build cranks for a while, and then I get this error: 00:02:37 ### log: /opt2/branches/freenas/os-base/amd64/_.cust.add_pkg_archivers_lzo2 do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build FAILED; please check above log for more details If I look in .cust.add_pkg_archivers_lzo2, I see this error: + umount /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles umount: unmount of /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles failed: Device busy If I try to do this manually: # umount /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles umount: unmount of /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles failed: Device busy I can't figure out why this mount is busy. If I do: umount -f /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles it unmounts, but I don't like using the '-f' flag to force the unmount. Any ideas? I am attaching some of my logs. -- Craig --089e0158b374ebe3fa04daaaf0d5 Content-Type: text/plain; charset=US-ASCII; name="build.log.txt" Content-Disposition: attachment; filename="build.log.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hfok4nl50 U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IEFwciAxOCAxNDoyOTowMCAyMDEzCmNvbW1hbmQ6IGVudiBH SVRfUkVQTz0vb3B0Mi9icmFuY2hlcy9mcmVlbmFzLWNhY2hlL3RydWVvcyBHSVRfUE9SVFNfUkVQ Tz0vb3B0Mi9icmFuY2hlcy9mcmVlbmFzLWNhY2hlL3BvcnRzIHNoIGJ1aWxkL2RvX2J1aWxkLnNo ClVzaW5nIGxvY2FsIG1pcnJvciBpbiAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzLWNhY2hlL3RydWVv cy4NClVzaW5nIGxvY2FsIGdpdCBwb3J0cyBtaXJyb3IgaW4gL29wdDIvYnJhbmNoZXMvZnJlZW5h cy1jYWNoZS9wb3J0cw0KU291cmNpbmcgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9uYW5vYnNkL29z LWJhc2UNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDogZnRwX3dnZXQNClBhY2thZ2UgaXMgbm90 IHlldCBidWlsdDogYmVuY2htYXJrc19pb3pvbmUNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDog YmVuY2htYXJrc19pcGVyZg0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBiZW5jaG1hcmtzX25l dHBlcmYNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDogYmVuY2htYXJrc194ZGQNClBhY2thZ2Ug aXMgbm90IHlldCBidWlsdDogc2VjdXJpdHlfc3Vkbw0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0 OiBzeXN1dGlsc19pcG1pdG9vbA0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiB3d3dfcHktZGph bmdvLWpzb24tcnBjDQpQYWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IGRldmVsX3B5LW1pbWVwYXJz ZQ0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBkZXZlbF9weS1zaXgNClBhY2thZ2UgaXMgbm90 IHlldCBidWlsdDogZGV2ZWxfcHktZGF0ZXV0aWwNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDog ZGV2ZWxfcHktcm9zZQ0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiB3d3dfcHktZGphbmdvLXRh c3R5cGllDQpQYWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IGRldmVsX3B5LWRhZW1vbg0KUGFja2Fn ZSBpcyBub3QgeWV0IGJ1aWx0OiBkZXZlbF9weS1wb2xpYg0KUGFja2FnZSBpcyBub3QgeWV0IGJ1 aWx0OiBkZXZlbF9weS11anNvbg0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBkZXZlbF9weS1z aW1wbGVqc29uDQpQYWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IHN5c3V0aWxzX2JzZHN0YXRzDQpQ YWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IHd3d193Z2V0cGFzdGUNClBhY2thZ2UgaXMgbm90IHll dCBidWlsdDogZGV2ZWxfcHktZ3JlZW5sZXQNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDogbmV0 X3B5LWV2ZW50bGV0DQpQYWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IGdyYXBoaWNzX2pwZWcNClBh Y2thZ2UgaXMgbm90IHlldCBidWlsdDogc2VjdXJpdHlfY2Ffcm9vdF9uc3MNClBhY2thZ2UgaXMg bm90IHlldCBidWlsdDogZnRwX2N1cmwNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDogZGV2ZWxf YXByMQ0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiB3d3dfbmVvbjI5DQpQYWNrYWdlIGlzIG5v dCB5ZXQgYnVpbHQ6IGRldmVsX3N1YnZlcnNpb24NClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDog ZWRpdG9yc192aW0tbGl0ZQ0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBtaXNjX3B5LXBleHBl Y3QNClBhY2thZ2UgaXMgbm90IHlldCBidWlsdDogZGV2ZWxfaXB5dGhvbg0KUGFja2FnZSBpcyBu b3QgeWV0IGJ1aWx0OiBkZXZlbF9wNS1UZXJtLVJlYWRLZXkNClBhY2thZ2UgaXMgbm90IHlldCBi dWlsdDogZGV2ZWxfcDUtc3VidmVyc2lvbg0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBtYWls X3A1LU5ldC1TTVRQLVNTTA0KUGFja2FnZSBpcyBub3QgeWV0IGJ1aWx0OiBsYW5nX3A1LUVycm9y DQpQYWNrYWdlIGlzIG5vdCB5ZXQgYnVpbHQ6IGRldmVsX2dpdA0KUGFja2FnZSBpcyBub3QgeWV0 IGJ1aWx0OiBkZXZlbF9jdGFncw0KQXV0b21hdGljYWxseSBidWlsZGluZyBhICogKiBGIEEgVCAq ICogaW1hZ2Ugc28gd2UgY2FuIGJ1aWxkIHBvcnRzDQowMDowMDowMCAjIE5hbm9CU0QgaW1hZ2Ug RnJlZU5BUy05LjEuMC1BTFBIQS00ZGQ0MWQ5X2RpcnR5LXg2NCBidWlsZCBzdGFydGluZw0KMDA6 MDA6MDAgIyMgU2tpcHBpbmcgYnVpbGR3b3JsZCAoYXMgaW5zdHJ1Y3RlZCkNCjAwOjAwOjAwICMj IFNraXBwaW5nIGJ1aWxka2VybmVsIChhcyBpbnN0cnVjdGVkKQ0KMDA6MDA6MDAgIyMgQ2xlYW4g YW5kIGNyZWF0ZSB3b3JsZCBkaXJlY3RvcnkgKC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFz ZS9hbWQ2NC9fLncpDQowMDowMDoyNSAjIyBDb25zdHJ1Y3QgaW5zdGFsbCBtYWtlLmNvbmYgKC9v cHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2NC9tYWtlLmNvbmYuaW5zdGFsbCkNCjAw OjAwOjI1ICMjIGluc3RhbGx3b3JsZA0KMDA6MDA6MjUgIyMjIGxvZzogL29wdDIvYnJhbmNoZXMv ZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18uaXcNCjAwOjAyOjI5ICMjIGluc3RhbGwgL2V0Yw0KMDA6 MDI6MjkgIyMjIGxvZzogL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18uZXRj DQowMDowMjozMCAjIyBjb25maWd1cmUgbmFub2JzZCAvZXRjDQowMDowMjozMCAjIyBpbnN0YWxs IGtlcm5lbCAoL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9uYW5vYnNkL0ZSRUVOQVMuYW1kNjQpDQow MDowMjozMCAjIyMgbG9nOiAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy5p aw0KMDA6MDI6MzcgIyMgcnVuIGN1c3RvbWl6ZSBzY3JpcHRzDQowMDowMjozNyAjIyBbMS8xODRd IGN1c3RvbWl6ZSAiY2xlYW5fcGFja2FnZXMiDQowMDowMjozNyAjIyMgbG9nOiAvb3B0Mi9icmFu Y2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy5jdXN0LmNsZWFuX3BhY2thZ2VzDQowMDowMjoz NyAjIyBDbGVhbiBhbmQgY3JlYXRlIHdvcmxkIGRpcmVjdG9yeSAoL29wdDIvYnJhbmNoZXMvZnJl ZW5hcy9vcy1iYXNlL2FtZDY0L18udy91c3IvbG9jYWwpDQowMDowMjozNyAjIyBbMi8xODRdIGN1 c3RvbWl6ZSAiY3VzdF9pbnN0YWxsX2ZpbGVzIg0KMDA6MDI6MzcgIyMjIGxvZzogL29wdDIvYnJh bmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18uY3VzdC5jdXN0X2luc3RhbGxfZmlsZXMNCjAw OjAyOjM3ICMjIFszLzE4NF0gY3VzdG9taXplICJjdXN0X2luc3RhbGxfbWFjaGluZV9maWxlcyIN CjAwOjAyOjM3ICMjIyBsb2c6IC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2NC9f LmN1c3QuY3VzdF9pbnN0YWxsX21hY2hpbmVfZmlsZXMNCjAwOjAyOjM3ICMjIFs0LzE4NF0gY3Vz dG9taXplICJmZXRjaF9iYWNrZ3JvdW5kIg0KMDA6MDI6MzcgIyMjIGxvZzogL29wdDIvYnJhbmNo ZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18uY3VzdC5mZXRjaF9iYWNrZ3JvdW5kDQowMDowMjoz NyAjIyBmZXRjaCBwb3J0cyBpbiBiYWNrZ3JvdW5kDQowMDowMjozNyAjIyBbNS8xODRdIGN1c3Rv bWl6ZSAiZ2VuZXJhdGVfYXZhdGFyX2NvbmYiDQowMDowMjozNyAjIyMgbG9nOiAvb3B0Mi9icmFu Y2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy5jdXN0LmdlbmVyYXRlX2F2YXRhcl9jb25mDQow MDowMjozNyAjIyBbNi8xODRdIGN1c3RvbWl6ZSAiYWRkX3BrZ19hcmNoaXZlcnNfbHpvMiINCjAw OjAyOjM3ICMjIyBsb2c6IC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2NC9fLmN1 c3QuYWRkX3BrZ19hcmNoaXZlcnNfbHpvMg0KZG9fYnVpbGQuc2g6IEVSUk9SOiBGcmVlTkFTIC9v cHQyL2JyYW5jaGVzL2ZyZWVuYXMvbmFub2JzZC9vcy1iYXNlIGJ1aWxkIEZBSUxFRDsgcGxlYXNl IGNoZWNrIGFib3ZlIGxvZyBmb3IgbW9yZSBkZXRhaWxzDQoKU2NyaXB0IGRvbmUgb24gVGh1IEFw ciAxOCAxNDozMjoyMSAyMDEzCg== --089e0158b374ebe3fa04daaaf0d5 Content-Type: text/plain; charset=US-ASCII; name="cust.add_pkg_archivers_lzo2.txt" Content-Disposition: attachment; filename="cust.add_pkg_archivers_lzo2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hfok63od1 KyBhZGRfcGtnX2FyY2hpdmVyc19sem8yCisgZG9fYWRkX3BrZyBsem8yLTIuMDYKKyBta2RpciAt cCAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvcG9ydHMvZGlzdGZpbGVzCisg bWtkaXIgLXAgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L3BvcnRzL3BhY2th Z2VzCisgbWtkaXIgLXAgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18udy91 c3IvcG9ydHMvcGFja2FnZXMvQWxsCisgbWtkaXIgLXAgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9v cy1iYXNlL2FtZDY0L18udy91c3IvcG9ydHMvZGlzdGZpbGVzCisgbW91bnQgLXQgbnVsbGZzIC1v IG5vYXRpbWUgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L3BvcnRzL3BhY2th Z2VzIC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2NC9fLncvdXNyL3BvcnRzL3Bh Y2thZ2VzCisgbW91bnQgLXQgbnVsbGZzIC1vIG5vYXRpbWUgL29wdDIvYnJhbmNoZXMvZnJlZW5h cy9vcy1iYXNlL2FtZDY0L3BvcnRzL2Rpc3RmaWxlcyAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29z LWJhc2UvYW1kNjQvXy53L3Vzci9wb3J0cy9kaXN0ZmlsZXMKKyBDUiAnY2QgL3Vzci9wb3J0cy9w YWNrYWdlcy9BbGw7cGtnX2FkZCAtRiBsem8yLTIuMDYudGJ6JworIG1vdW50IC10IGRldmZzIG5v bmUgL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18udy9kZXYKKyBmYWtlX3Rh cmdldF9ob3N0IGNocm9vdCAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy53 IC9iaW4vc2ggLWV4YyAnY2QgL3Vzci9wb3J0cy9wYWNrYWdlcy9BbGw7cGtnX2FkZCAtRiBsem8y LTIuMDYudGJ6JworIGxvY2FsIG5ld3ZlcnMgcmV2aXNpb24gYnJhbmNoCisgbmV3dmVycz0vb3B0 Mi9icmFuY2hlcy9mcmVlbmFzL0ZyZWVCU0Qvc3JjL3N5cy9jb25mL25ld3ZlcnMuc2gKKyBncmVw IC1tIDEgUkVWSVNJT049IC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvRnJlZUJTRC9zcmMvc3lzL2Nv bmYvbmV3dmVycy5zaAorIGN1dCAtZjIgLWQgJyInCisgcmV2aXNpb249OS4xCisgZ3JlcCAtbSAx IEJSQU5DSD0gL29wdDIvYnJhbmNoZXMvZnJlZW5hcy9GcmVlQlNEL3NyYy9zeXMvY29uZi9uZXd2 ZXJzLnNoCisgY3V0IC1mMiAtZCAnIicKKyBicmFuY2g9U1RBQkxFCisgc2V0IC1lCisgZW52ClNV RE9fQ09NTUFORD0vdXNyL2xvY2FsL2Jpbi9iYXNoCk5BTk9fU1JDPS9vcHQyL2JyYW5jaGVzL2Zy ZWVuYXMvRnJlZUJTRC9zcmMKTkFOT19NT0RVTEVTPWN4Z2IgZXh0MmZzIGdlb20gaXBtaSBpc2Nz aSBwZiBwZmxvZyBzbWJmcyBsaWJpY29udiBsaWJtY2hhaW4gc3lzY29ucyB1ZGYgemZzIG9wZW5z b2xhcmlzIHVzYi94aGNpCk5BTk9fTEFCRUw9RnJlZU5BUwpGT1JDRV9GQlNEX09OTFk9MQpOQU5P X01FRElBU0laRT0zOTA2MjUwCk5BTk9fTkVXRlM9LWIgNDA5NiAtZiA1MTIgLWkgODE5MiAtTzEg LVUKTE9HTkFNRT1yb290Ck5BTk9fVE9PTFM9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9idWlsZC9u YW5vYnNkCk5BTk9fTUFLRV9DT05GX0JVSUxEPS9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFz ZS9hbWQ2NC9tYWtlLmNvbmYuYnVpbGQKTkFOT19CT09UTE9BREVSPWJvb3QvYm9vdDAKTkFOT19D VVNUT01JWkU9IGNsZWFuX3BhY2thZ2VzIGN1c3RfaW5zdGFsbF9maWxlcyBjdXN0X2luc3RhbGxf bWFjaGluZV9maWxlcyBmZXRjaF9iYWNrZ3JvdW5kIGdlbmVyYXRlX2F2YXRhcl9jb25mIGFkZF9w a2dfYXJjaGl2ZXJzX2x6bzIgYWRkX3BrZ19zZWN1cml0eV9lYXN5LXJzYSBhZGRfcGtnX3NlY3Vy aXR5X29wZW52cG4gYWRkX3BrZ19jb252ZXJ0ZXJzX2xpYmljb252IGFkZF9wa2dfbGFuZ19wZXJs NS4xNCBhZGRfcGtnX2NvbnZlcnRlcnNfaWNvbnYgYWRkX3BrZ19kZXZlbF9nZXR0ZXh0IGFkZF9w a2dfZGV2ZWxfcGtnY29uZiBhZGRfcGtnX2RldmVsX2xpYnB0aHJlYWQtc3R1YnMgYWRkX3BrZ19k ZXZlbF9jZGlhbG9nIGFkZF9wa2dfZG5zX2luYWR5bi1tdCBhZGRfcGtnX2RldmVsX3BjcmUgYWRk X3BrZ19lZGl0b3JzX25hbm8gYWRkX3BrZ19mdHBfcHJvZnRwZCBhZGRfcGtnX25ldC1tZ210X2Jz bm1wLXVjZCBhZGRfcGtnX25ldC1tZ210X2Jzbm1wdG9vbHMgYWRkX3BrZ19uZXQtbWdtdF9jbG9n IGFkZF9wa2dfbmV0LW1nbXRfc2lwY2FsYyBhZGRfcGtnX25ldF9pc3RndCBhZGRfcGtnX25ldF92 YmxhZGUgYWRkX3BrZ19zZWN1cml0eV9saWJncGctZXJyb3IgYWRkX3BrZ19zZWN1cml0eV9saWJn Y3J5cHQgYWRkX3BrZ19kYXRhYmFzZXNfZGI0NiBhZGRfcGtnX3NlY3VyaXR5X2N5cnVzLXNhc2wy IGFkZF9wa2dfbmV0X29wZW5sZGFwMjQtc2FzbC1jbGllbnQgYWRkX3BrZ19uZXRfbnNzX2xkYXAg YWRkX3BrZ19uZXRfcnN5bmMgYWRkX3BrZ19sYW5nX3B5dGhvbjI3IGFkZF9wa2dfZG5zX3B5LWRu c3B5dGhvbiBhZGRfcGtnX2RldmVsX3RhbGxvYyBhZGRfcGtnX2RldmVsX2xpYmV4ZWNpbmZvIGFk ZF9wa2dfZGV2ZWxfcG9wdCBhZGRfcGtnX2RhdGFiYXNlc190ZGIgYWRkX3BrZ19zeXN1dGlsc19s aWJzdW5hY2wgYWRkX3BrZ19uZXRfc2FtYmEzNiBhZGRfcGtnX3NlY3VyaXR5X3BhbV9sZGFwIGFk ZF9wa2dfc2VjdXJpdHlfcGFtX21raG9tZWRpciBhZGRfcGtnX3NoZWxsc19iYXNoIGFkZF9wa2df c2hlbGxzX3NjcG9ubHkgYWRkX3BrZ19zeXN1dGlsc19lMmZzcHJvZ3MgYWRkX3BrZ19zeXN1dGls c19mdXNlZnMta21vZCBhZGRfcGtnX3N5c3V0aWxzX2Z1c2Vmcy1saWJzIGFkZF9wa2dfZGV2ZWxf bGlidWJsaW8gYWRkX3BrZ19zeXN1dGlsc19mdXNlZnMtbnRmcyBhZGRfcGtnX3N5c3V0aWxzX3Nt YXJ0bW9udG9vbHMgYWRkX3BrZ19kZXZlbF9nbGliMjAgYWRkX3BrZ19uZXRfbGliZG5ldCBhZGRf cGtnX2VtdWxhdG9yc19vcGVuLXZtLXRvb2xzLW5veDExIGFkZF9wa2dfZGF0YWJhc2VzX3NxbGl0 ZTMgYWRkX3BrZ19kYXRhYmFzZXNfcHktc3FsaXRlMyBhZGRfcGtnX2RhdGFiYXNlc19weS1ic2Rk YjMgYWRkX3BrZ19kZXZlbF9weS1kaXN0cmlidXRlIGFkZF9wa2dfd3d3X3B5LWZsdXAgYWRkX3Br Z193d3dfcHktZGphbmdvIGFkZF9wa2dfd3d3X3B5LWRvamFuZ28gYWRkX3BrZ193d3dfZG9qbyBh ZGRfcGtnX2RhdGFiYXNlc19weS1zb3V0aCBhZGRfcGtnX2RldmVsX3B5LWFzbjEgYWRkX3BrZ19k ZXZlbF9weS1hc24xLW1vZHVsZXMgYWRkX3BrZ193d3dfbmdpbnggYWRkX3BrZ19uZXQtbWdtdF9u ZXQtc25tcCBhZGRfcGtnX3N5c3V0aWxzX251dCBhZGRfcGtnX3RleHRwcm9jX2xpYnhtbDIgYWRk X3BrZ190ZXh0cHJvY19weS1saWJ4bWwyIGFkZF9wa2dfdGV4dHByb2NfZXhwYXQyIGFkZF9wa2df ZGV2ZWxfZ2FtaW4gYWRkX3BrZ19kZXZlbF9naW8tZmFtLWJhY2tlbmQgYWRkX3BrZ19kZXZlbF9t NCBhZGRfcGtnX2RldmVsX2Jpc29uIGFkZF9wa2dfZGV2ZWxfbGliZmZpIGFkZF9wa2dfbWlzY19n bm9tZWhpZXIgYWRkX3BrZ19kZXZlbF9nb2JqZWN0LWludHJvc3BlY3Rpb24gYWRkX3BrZ193d3df cHktaHR0cGxpYjIgYWRkX3BrZ19uZXRfcHktb2F1dGgyIGFkZF9wa2dfc3lzdXRpbHNfamFpbG1l IGFkZF9wa2dfZ3JhcGhpY3NfcG5nIGFkZF9wa2dfZGV2ZWxfbGlic3RhdGdyYWIgYWRkX3BrZ19k ZXZlbF9saWJsdGRsIGFkZF9wa2dfcHJpbnRfZnJlZXR5cGUyIGFkZF9wa2dfeDExX3hwcm90byBh ZGRfcGtnX3gxMS1mb250c19mb250Y29uZmlnIGFkZF9wa2dfeDExLWZvbnRzX2xpYmZvbnRlbmMg YWRkX3BrZ194MTEtZm9udHNfbWtmb250c2NhbGUgYWRkX3BrZ194MTEtZm9udHNfbWtmb250ZGly IGFkZF9wa2dfeDExLWZvbnRzX2ZvbnQtYmgtdHRmIGFkZF9wa2dfeDExLWZvbnRzX2ZvbnQtbWlz Yy1tZWx0aG8gYWRkX3BrZ194MTEtZm9udHNfZm9udC1taXNjLWV0aGlvcGljIGFkZF9wa2dfeDEx LWZvbnRzX2JpdHN0cmVhbS12ZXJhIGFkZF9wa2dfeDExLWZvbnRzX2ZvbnQtdXRpbCBhZGRfcGtn X3gxMS1mb250c19lbmNvZGluZ3MgYWRkX3BrZ194MTEtZm9udHNfeG9yZy1mb250cy10cnVldHlw ZSBhZGRfcGtnX3gxMV9waXhtYW4gYWRkX3BrZ19ncmFwaGljc19jYWlybyBhZGRfcGtnX3gxMS10 b29sa2l0c19wYW5nbyBhZGRfcGtnX2RhdGFiYXNlc19ycmR0b29sIGFkZF9wa2dfbmV0X2xpYm9w aW5nIGFkZF9wa2dfbmV0LW1nbXRfY29sbGVjdGQ1IGFkZF9wa2dfZGV2ZWxfcHktaXBhZGRyIGFk ZF9wa2dfY29udmVydGVyc19iYXNlNjQgYWRkX3BrZ19lbXVsYXRvcnNfbXRvb2xzIGFkZF9wa2df c3lzdXRpbHNfYXJjY29uZiBhZGRfcGtnX3N5c3V0aWxzX3R3X2NsaSBhZGRfcGtnX3N5c3V0aWxz X21lZ2FjbGkgYWRkX3BrZ19zeXN1dGlsc19hcmVjYS1jbGkgYWRkX3BrZ19uZXRfcHktbGRhcDIg YWRkX3BrZ19zeXN1dGlsc19hdGFpZGxlIGFkZF9wa2dfc3lzdXRpbHNfZ25vbWVfc3ViciBhZGRf cGtnX2RldmVsX2RidXMgYWRkX3BrZ19kZXZlbF9kYnVzLWdsaWIgYWRkX3BrZ19kZXZlbF9saWJk YWVtb24gYWRkX3BrZ19kYXRhYmFzZXNfZ2RibSBhZGRfcGtnX25ldF9hdmFoaS1hcHAgYWRkX3Br Z19uZXRfYXZhaGktbGliZG5zIGFkZF9wa2dfdGV4dHByb2NfcHkteG1sIGFkZF9wa2dfc3lzdXRp bHNfdGhyb3R0bGUgYWRkX3BrZ19zeXN1dGlsc19kbWlkZWNvZGUgYWRkX3BrZ19zeXN1dGlsc19n cmFpZDUgYWRkX3BrZ19kZXZlbF9saWJldmVudCBhZGRfcGtnX3N5c3V0aWxzX3RtdXggYWRkX3Br Z19uZXRfbmV0YXRhbGsgYWRkX3BrZ19kbnNfbGliaWRuIGFkZF9wb3J0X2Z0cF93Z2V0IGFkZF9w b3J0X2JlbmNobWFya3NfaW96b25lIGFkZF9wb3J0X2JlbmNobWFya3NfaXBlcmYgYWRkX3BvcnRf YmVuY2htYXJrc19uZXRwZXJmIGFkZF9wb3J0X2JlbmNobWFya3NfeGRkIGFkZF9wb3J0X3NlY3Vy aXR5X3N1ZG8gYWRkX3BvcnRfc3lzdXRpbHNfaXBtaXRvb2wgYWRkX3BvcnRfd3d3X3B5LWRqYW5n by1qc29uLXJwYyBhZGRfcG9ydF9kZXZlbF9weS1taW1lcGFyc2UgYWRkX3BvcnRfZGV2ZWxfcHkt c2l4IGFkZF9wb3J0X2RldmVsX3B5LWRhdGV1dGlsIGFkZF9wb3J0X2RldmVsX3B5LXJvc2UgYWRk X3BvcnRfd3d3X3B5LWRqYW5nby10YXN0eXBpZSBhZGRfcG9ydF9kZXZlbF9weS1kYWVtb24gYWRk X3BvcnRfZGV2ZWxfcHktcG9saWIgYWRkX3BvcnRfZGV2ZWxfcHktdWpzb24gYWRkX3BvcnRfZGV2 ZWxfcHktc2ltcGxlanNvbiBhZGRfcG9ydF9zeXN1dGlsc19ic2RzdGF0cyBhZGRfcG9ydF93d3df d2dldHBhc3RlIGFkZF9wb3J0X2RldmVsX3B5LWdyZWVubGV0IGFkZF9wb3J0X25ldF9weS1ldmVu dGxldCBhZGRfcG9ydF9ncmFwaGljc19qcGVnIGFkZF9wb3J0X3NlY3VyaXR5X2NhX3Jvb3RfbnNz IGFkZF9wb3J0X2Z0cF9jdXJsIGFkZF9wb3J0X2RldmVsX2FwcjEgYWRkX3BvcnRfd3d3X25lb24y OSBhZGRfcG9ydF9kZXZlbF9zdWJ2ZXJzaW9uIGFkZF9wb3J0X2VkaXRvcnNfdmltLWxpdGUgYWRk X3BvcnRfbWlzY19weS1wZXhwZWN0IGFkZF9wb3J0X2RldmVsX2lweXRob24gYWRkX3BvcnRfZGV2 ZWxfcDUtVGVybS1SZWFkS2V5IGFkZF9wb3J0X2RldmVsX3A1LXN1YnZlcnNpb24gYWRkX3BvcnRf bWFpbF9wNS1OZXQtU01UUC1TU0wgYWRkX3BvcnRfbGFuZ19wNS1FcnJvciBhZGRfcG9ydF9kZXZl bF9naXQgYWRkX3BvcnRfZGV2ZWxfY3RhZ3MgaGFja19uc3N3aXRjaF9jb25mIGFkZF9ndWkgYWRk X2F1dG90dW5lIGFyY2hfc3BlY2lmaWNfa28gYWRkX3BiaV9tYW5hZ2VyIGFkZF93YXJkZW4gYWRk X3BjYnNkX2xpYnNoIGFkZF9wYmlfd3JhcHBlciBtb3ZlX2RhdGEgYWRkX2RhdGFfdG9fZnN0YWIg YWZwZF9jb25mX3N5bWxpbmsgc2VsZWN0X2h0dHBkIHN0YXRpY19kaWFsb2cgcmVtb3ZlX3BhdGNo X2Rpdm90cyBjb25maWd1cmVfbW50X21kIHNocmlua19tZF9mYnNpemUgc2F2ZV9idWlsZCB1bm11 dGVfY29uc29sZV9sb2dnaW5nIHJlbW92ZV92YXJfZGJfcGtnIGZpeF9mdXNlX21vZHVsZV9sb2Nh dGlvbiBmaXhfZWFzeV9pbnN0YWxsX3B0aCBjcmVhdGVfdmFyX2hvbWVfc3ltbGluawpBVkFUQVJf Uk9PVD0vb3B0Mi9icmFuY2hlcy9mcmVlbmFzCk5BTk9fWFo9eHoKUEJJX0RFTEVURV9CVUlMRD0w Ck1BS0VPQkpESVJQUkVGSVg9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0Ck5B Tk9fUE1BS0U9bWFrZSAtaiA1ClNDUklQVD1idWlsZC5sb2cKTkFOT19BUkNIPWFtZDY0Ck1BSUw9 L3Zhci9tYWlsL3Jvb3QKTkFOT19MT0NBTF9ESVJTPXBiaS13cmFwcGVyCk5BTk9fQ09ORlNJWkU9 MjA0OApOQU5PX0hFQURTPTE2Ck1BS0VfSk9CUz01ClBBVEg9L29wdDIvYnJhbmNoZXMvZnJlZW5h cy9zYmluOi9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluOi91c3IvZ2FtZXM6L3Vzci9sb2Nh bC9zYmluOi91c3IvbG9jYWwvYmluOi9vcHQvaG9tZS9yb2RyaWdjL2JpbjovdXNyL2xvY2FsL0Fj cm9iYXQ1L2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW46L3ZvbHVtZS9idWlsZHRv b2xzL2Jpbjovdm9sdW1lL2xhYnRvb2xzL2Jpbjovdm9sdW1lL2N1cnJlbnQvc3ctcHJvamVjdHMv cmV2aWV3LXRyYWNrZXIvc2NyaXB0cwpQQklfREVMRVRFX0JVSUxEU1JDPTAKTkFOT19JTUFHRVM9 MgpOQU5PX0NGR19CQVNFPS9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvbmFub2JzZApOQU5PX01BS0Vf Q09ORl9JTlNUQUxMPS9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2NC9tYWtlLmNv bmYuaW5zdGFsbApTVURPX0dJRD0xMDAxCk9MRFBXRD0vb3B0Mi9icmFuY2hlcy9mcmVlbmFzL0Zy ZWVCU0QvcG9ydHMvZGV2ZWwvZ2l0ClBCSV9BUFBESVI9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9w YmkKTkFOT19EQVRBU0laRT00MDk2MApQV0Q9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9GcmVlQlNE L3BvcnRzL2RldmVsL2N0YWdzCl89L3Vzci9iaW4vc2NyaXB0ClJFVklTSU9OPTRkZDQxZDlfZGly dHkKTkFOT19XT1JMRERJUj0vb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy53 CkZSRUVOQVNfQVJDSD1hbWQ2NApQQklfQlVJTERTUkM9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9w Ymkvc3JjCk5BTk9fQVJDSF9IVU1BTklaRUQ9eDY0ClRFUk09eHRlcm0KTkFOT19OQU1FPUZyZWVO QVMtOS4xLjAtQUxQSEEtNGRkNDFkOV9kaXJ0eS14NjQKTkFOT19JTUdOQU1FPUZyZWVOQVMtOS4x LjAtQUxQSEEtNGRkNDFkOV9kaXJ0eS14NjQKTkFOT19NQUtFRlM9bWFrZWZzIC1CIGJpZyAJLW8g YnNpemU9NDA5Nixmc2l6ZT01MTIsZGVuc2l0eT04MTkyLG9wdGltaXphdGlvbj1zcGFjZQpOQU5P X0NPREVTSVpFPTAKVVNFUj1yb290CkhPTUU9L3Jvb3QKUEJJX0JVSUxEVEFSR0VUPS9vcHQyL2Jy YW5jaGVzL2ZyZWVuYXMvcGJpL2FtZDY0L3RhcmdldApOQU5PX0RSSVZFPXVmcy9GcmVlTkFTCk5B Tk9fQVJHUz0KTkFOT19LRVJORUw9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9uYW5vYnNkL0ZSRUVO QVMuYW1kNjQKTkFOT19CT09UMENGRz0tbyBwYWNrZXQgLXMgMSAtbSAzIC10IDE4ClBTMT1bXHVA XGggXFddJSAKR0lUX1JFUE89L29wdDIvYnJhbmNoZXMvZnJlZW5hcy1jYWNoZS90cnVlb3MKU0hF TEw9L3Vzci9sb2NhbC9iaW4vYmFzaApTVk5SRVZJU0lPTj00ZGQ0MWQ5X2RpcnR5Ck5BTk9fU0VD VFM9NjMKU1VET19VU0VSPXJvZHJpZ2MKUEJJX1BLR0RJUj0vb3B0Mi9icmFuY2hlcy9mcmVlbmFz L3BiaS9hbWQ2NC9wa2dzClNVRE9fVUlEPTEwMDEKVVNFUk5BTUU9cm9vdApQQklfT1NSRUw9OS4w LVJFTEVBU0UKR0lUX1BPUlRTX1JFUE89L29wdDIvYnJhbmNoZXMvZnJlZW5hcy1jYWNoZS9wb3J0 cwpQQklfQlVJTERESVI9L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9wYmkvYW1kNjQKUEJJX09TQVJD SD1hbWQ2NApBVkFUQVJfQ09NUE9ORU5UPW9zLWJhc2UKUEJJX0JJTkRJUj0vb3B0Mi9icmFuY2hl cy9mcmVlbmFzL3NiaW4KUFlUSE9OX0RFRkFVTFRfVkVSU0lPTj1weXRob24yLjcKTkFOT19PQko9 L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0ClBCSV9ERUxFVEVfQlVJTERUQVJH RVQ9MApTSExWTD0xCisgZXhwb3J0IFVOQU1FX209YW1kNjQKKyBleHBvcnQgVU5BTUVfcD1hbWQ2 NAorIGV4cG9ydCBVTkFNRV9yPTkuMS1TVEFCTEUKKyB1bmFtZSAtdgorIHVuYW1lIC1wCisgdW5h bWUgLXIKKyBzZWQgLWUgcy9hbWQ2NC9hbWQ2NC8gLWUgcy85LjEtU1RBQkxFLzkuMS1TVEFCTEUv ZworIGV4cG9ydCAnVU5BTUVfdj1GcmVlQlNEIDEwLjAtQ1VSUkVOVCAjMCByMjQ5MTgxOiBTYXQg QXByICA2IDAzOjA3OjMyIFVUQyAyMDEzICAgICByb2RyaWdjQGRpYmJsZXIuY3JvZHJpZ3Vlcy5v cmc6L3Vzci9vYmovb3B0Mi9icmFuY2hlcy9oZWFkL3N5cy9HRU5FUklDICcKKyBhd2sgJy9cI2Rl ZmluZS4qX19GcmVlQlNEX3ZlcnNpb24vIHsgcHJpbnQgJDMgfScgL29wdDIvYnJhbmNoZXMvZnJl ZW5hcy9GcmVlQlNEL3NyYy9zeXMvc3lzL3BhcmFtLmgKKyBleHBvcnQgT1NWRVJTSU9OPTkwMTUw NAorIGV4cG9ydCBQQVRIPS9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvc2Jpbjovc2JpbjovYmluOi91 c3Ivc2JpbjovdXNyL2JpbjovdXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW4KKyBjaHJvb3Qg L29wdDIvYnJhbmNoZXMvZnJlZW5hcy9vcy1iYXNlL2FtZDY0L18udyAvYmluL3NoIC1leGMgJ2Nk IC91c3IvcG9ydHMvcGFja2FnZXMvQWxsO3BrZ19hZGQgLUYgbHpvMi0yLjA2LnRieicKKyBjZCAv dXNyL3BvcnRzL3BhY2thZ2VzL0FsbAorIHBrZ19hZGQgLUYgbHpvMi0yLjA2LnRiegorIHVtb3Vu dCAvb3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy53L2RldgorIHVtb3VudCAv b3B0Mi9icmFuY2hlcy9mcmVlbmFzL29zLWJhc2UvYW1kNjQvXy53L3Vzci9wb3J0cy9kaXN0Zmls ZXMKdW1vdW50OiB1bm1vdW50IG9mIC9vcHQyL2JyYW5jaGVzL2ZyZWVuYXMvb3MtYmFzZS9hbWQ2 NC9fLncvdXNyL3BvcnRzL2Rpc3RmaWxlcyBmYWlsZWQ6IERldmljZSBidXN5Cg== --089e0158b374ebe3fa04daaaf0d5-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 03:13:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83CB9CDF; Fri, 19 Apr 2013 03:13:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id 5A596635; Fri, 19 Apr 2013 03:13:15 +0000 (UTC) Received: by mail-da0-f49.google.com with SMTP id t11so1716310daj.36 for ; Thu, 18 Apr 2013 20:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:to:cc:reply-to:subject:in-reply-to :x-mailer:mime-version:content-type; bh=/UEPTmMiSEdBDRE80ccOV7TNOwo+YZjMLrdcaciO3LA=; b=SaX3D6Vz+8n+pVDu2LdRnYhZMvSbMdnTCQsYRzuIjD7iVjj3Fj3CAw3cjBi1BPGwgg Shg38wMAodmOR0p5rq0EAIgsXRWnsoNZr/YDWRycz+IWmTzRlsPyCA5uemjWMPVrAAdz jkiJXRPW4isqGnaGFY6XOXkWA/Ums1uXXCjM2T/mp0D+IomHavQmLRUwJb8IzB4TCvXg ocYOHJh7OkWg90DNmrEPqZs3lY5T7ftkty9F8FRhCCGkdn35yLbJOiXQ+2ZQaYWR31pV 022Vh0iyOPTIRIeKyW9C8qOXcVGxRqRgJuYtQPmfW1wdige4eNW/JUkTg29oUCD0cntW YD3g== X-Received: by 10.68.196.1 with SMTP id ii1mr16464509pbc.200.1366340869473; Thu, 18 Apr 2013 20:07:49 -0700 (PDT) Received: from www.palm.com ([32.158.91.181]) by mx.google.com with ESMTPS id al2sm3546534pbc.25.2013.04.18.20.07.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Apr 2013 20:07:48 -0700 (PDT) Message-ID: <5170b504.62aa440a.562f.3be5@mx.google.com> Date: Thu, 18 Apr 2013 20:07:38 -0700 From: "Adrian Chadd" To: "Artyom Mirgorodskiy" Subject: Re: Atheros 9287 - no carrier . revision 249623. In-Reply-To: <1825476.qO1YuZaJ09@home.alkar.net> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 03:13:15 -0000 Ok. I'll add some tidyups to head tonight and then add some more verbose lo= gging. I don't have any 64 bit machines to test ar9287 on atm. Sent from my Palm Pre on AT&T On Apr 18, 2013 3:52 PM, Artyom Mirgorodskiy <artyom.mirgorodsky@gmail.c= om> wrote:=20 Nothing :(   On Thursday 18 April 2013 15:22:49 Adrian Chadd wrote: > Hm! I wonder.. >=20 > Edit if_athvar.h - change sc_rxchainmask and sc_txchainmask in > ath_softc to be uint32_t, rather than int. >=20 > See if that helps. >=20 >=20 >=20 > Adrian >=20 > On 18 April 2013 15:20, Artyom Mirgorodskiy > <artyom.mirgorodsky@gmail.com> wrote: > > See attached > > > > > > > > On Thursday 18 April 2013 15:08:36 Adrian Chadd wrote: > > > >> On 18 April 2013 15:07, Artyom Mirgorodskiy > > > >> <artyom.mirgorodsky@gmail.com> wrote: > > > >> > See attached > > > >> > > > > >> > > > >> What the hell? Those masks are really wrong. > > > >> > > > >> Try adding this line after it: > > > >> > > > >> ath_hal_printf(ah, "%s: pcap rx=3D0x%x, tx=3D0x%x; configured= rx=3D0x%x, > > > >> tx=3D0x%x\n", __func__, pCap->halRxChainMask, pCap->hal= TxChainMask, > > > >> rx_chainmask, tx_chainmask); > > > > -- > > > > Artyom Mirgorodskiy --=20 Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 07:57:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B96012A4; Fri, 19 Apr 2013 07:57:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBF1FA5; Fri, 19 Apr 2013 07:57:13 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hq17so381840wib.11 for ; Fri, 19 Apr 2013 00:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QTKwe6IFbIidFMYtQECoNcGKweV+ZfmPnOUiWIw14eE=; b=dSiBwk2RLZAGf2RGwN/yyv1osRXiWGY23uVd9qwBh2xtWYgBMYNTAKqx7UgZWXLtPq MyAVaTI3OXnDttiQ9Z6eC734qvKkPxA5vmMO4PTalnkwipfv6e0C6l34N92TFjbfcuST SQL8uUn7HzA8YZJ9/G7Nzvi6mWggsq4GJzk61EN/d7IjtGgBnBvIWaatwuRB+meja1IB Yw8WykxEYD2G8h6oZSojhPY5277EoT9jHMUjOA9t1x4bU5fkIK1HGxeMh8N+2BsGfcaJ 1ZYyAHDkTv5KzWk6GBKe8QX1PzD419Kc2u8lIQsa6VV7evQVhvM/Plvdvfp5TYrp8rit CPjQ== MIME-Version: 1.0 X-Received: by 10.180.73.173 with SMTP id m13mr23099468wiv.27.1366358232390; Fri, 19 Apr 2013 00:57:12 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Fri, 19 Apr 2013 00:57:12 -0700 (PDT) In-Reply-To: <5170b504.62aa440a.562f.3be5@mx.google.com> References: <1825476.qO1YuZaJ09@home.alkar.net> <5170b504.62aa440a.562f.3be5@mx.google.com> Date: Fri, 19 Apr 2013 00:57:12 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 07:57:13 -0000 Hi, I've just committed some changes to -HEAD. Please update to the latest -HEAD and paste me the ath0 dmesg output. It will include the chainmask information. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 08:12:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62E669BA for ; Fri, 19 Apr 2013 08:12:03 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id CE070F3 for ; Fri, 19 Apr 2013 08:12:02 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fk20so3058322lab.20 for ; Fri, 19 Apr 2013 01:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vALYfNGDrRnR6fna91Y2PyXebdxsTwQfsDrg4a2nMI4=; b=Qqv+haivy99GDzjaAuQorG/UEAZqnUxRNYhZg6YkuRFqAXSfUoPqxq5GVLW4rB9elT GVw0L4jYair7wLOHfJ9tjdeK8ssQKUBAqNPiS96DCyIu+tIACfmjtw26adBx/OKzJrHX YvmDXWlAeRPkwlYMtOhjU10w3NCyq2UXUK7w5Cnedqkom/m5M706ENeoxIKzjYxOWPss lThlYTZ99acVnYrmgyi4CKzHj3kO2DQ10q4WJIKLo6gVQPKUSR0IauKoTDnXP/9CA3Kl z9DLrR2H2/fNWQCDV+LZsalCWs32gfR1jxthLhexu2/ypIhLvNduxkRHGwH7jgOAj8sR 6tsQ== MIME-Version: 1.0 X-Received: by 10.112.133.4 with SMTP id oy4mr7613565lbb.22.1366359121612; Fri, 19 Apr 2013 01:12:01 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Fri, 19 Apr 2013 01:12:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 01:12:01 -0700 X-Google-Sender-Auth: s_9uaGdtjP-s42lJrYiXOwb5j5I Message-ID: Subject: Re: Cannot unmount nullfs in current From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 08:12:03 -0000 On Thu, Apr 18, 2013 at 4:27 PM, Craig Rodrigues wrote: > Hi, > > I am trying to build some software which uses > nanobsd, and mounts/unmounts many nullfs mounts > while it runs. I am hitting failures where > I cannot unmount nullfs file systems. I cannot figure out why. > I forgot to run fstat. :( fstat /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME rodrigc gam_server 2275 37 /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles 3194579 drwxr-xr-x 196 r /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles Since I run the GNOME desktop, gnome has a dependency on the gamin port. The gamin port contains gam_server. gamin monitors file system activity. It looks like gam_server gets triggered when things are mounted, and for some reason, sometimes fails to go away. I need to read http://people.gnome.org/~veillard/gamin/config.html and figure out how to disable gamin, or just remove gamin from my system. Annoying. :( -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 09:46:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94EE17E; Fri, 19 Apr 2013 09:46:48 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id AC0D78A6; Fri, 19 Apr 2013 09:46:47 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so523852wiv.2 for ; Fri, 19 Apr 2013 02:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n1uUd+/ZOPA38EiRjsijdbPjr5ajljfVvOcMS9FnZWI=; b=x7JMXfJjG0VaTKv9OOoxpTeiVe3OkKeoxsJLrtk9biY2IfJftWQGbIrvAH5RNbnBlZ Jbzf20LglH+lUHWQvGlqLkBRFpQqlB15LsH0kCW0ur/pXAbRJBh+AK4QcnsEG0JXfo70 n9jJM4PuydRZZoyx77G2ihjxe2s59Ndx44Y2DFDfsOIiSK5p4ipVo5TtUtCIXLiALJ8h 7xQNHHdj4uvuKGtbMN/u6AipVlPkwOHLcDKGT77NaedgAz5PTFQEV3u4Fv0XHkOBmYAL XauzlaRoQx516gaLQ1+/JFjvs+x60mQX6AFsXfiL7N3TkoKasNTHwt5/Ec29fySsM20j ohsw== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr347953wiy.19.1366364758021; Fri, 19 Apr 2013 02:45:58 -0700 (PDT) Received: by 10.194.76.147 with HTTP; Fri, 19 Apr 2013 02:45:57 -0700 (PDT) In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Fri, 19 Apr 2013 11:45:57 +0200 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: David Demelier To: Gary Palmer Content-Type: text/plain; charset=UTF-8 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 09:46:48 -0000 2013/4/14 Gary Palmer : > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: >> Is it possible to move ipfilter into a port? > > That may work short term, but the ENOMAINTAINER problem will quickly creep > up again as kernel APIs change. If the author has lost interest in > maintaining the FreeBSD port of ipfilter then unless someone steps forward > to carry on the work, I don't see much of a future for ipfilter in > FreeBSD > > Do we honestly need three packet filters? > No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits My $0.02, Regards -- Demelier David From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 10:25:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0541A9E1; Fri, 19 Apr 2013 10:25:41 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 09573A5C; Fri, 19 Apr 2013 10:25:39 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id h14so916976eaj.24 for ; Fri, 19 Apr 2013 03:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=LHqtoN3QOBON5WgWKjJMuBdDLE7hA4O/ty6Qu/6Lhyw=; b=AWoWW5iwOHcTdyiU7psH30JxxYXZ1GIQiuSOGTDgcdYGY88AO9Gv2erN9q7Cu5QAk9 8gB+lpgzClq1+9fj2+yZsBnhY8jZl1aHFGFhVz1/8q4o3WKKJ7hNZbW3YXS2bsJycUS+ h4cKPQbc69orpxxve9ytG6hPlHihOuu0wgLBSTPKjkJCEeDRH+jQEtTl5kOUzNLZgSe1 NVLLrN+UsH07EUwkJaQBkUBPgnsc0NaHbSnRiaANMzVj9C62CMGHwPWBkzNtA3+q8Nvw 3luvoprNT/3LXRIMt1DosR9TMQWN2Xu5BBgsPysiQJXmb3advbRV17U8D1yee5Zkjvyi +PTw== X-Received: by 10.14.179.201 with SMTP id h49mr40418774eem.26.1366367139136; Fri, 19 Apr 2013 03:25:39 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id 8sm21929594eeg.15.2013.04.19.03.25.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Apr 2013 03:25:38 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 13:27:21 +0300 Message-ID: <2381713.gpuUDy5DnR@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <1825476.qO1YuZaJ09@home.alkar.net> <5170b504.62aa440a.562f.3be5@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1595643.eQ8gZeXthg" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 10:25:41 -0000 This is a multi-part message in MIME format. --nextPart1595643.eQ8gZeXthg Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Updated. However I did not see chainmask information. See attached On Friday 19 April 2013 00:57:12 Adrian Chadd wrote: > Hi, > > I've just committed some changes to -HEAD. Please update to the latest > -HEAD and paste me the ath0 dmesg output. > It will include the chainmask information. > > Thanks, > > > Adrian -- Artyom Mirgorodskiy --nextPart1595643.eQ8gZeXthg Content-Disposition: attachment; filename="dmesg" Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; name="dmesg" x86bios: SSEG 0x098000-0x098fff at 0xffffff8000244000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse4BSD v0.1.27 @ /dev/cuse wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: ctl: CAM Target Layer loaded acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a995840), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff811991d000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (GEOM: new disk ada0 ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097532300 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled nfslock: pseudo-device wlan0: link state changed to UP agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 wlan0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...10 2 2 1 1 1 0 0 0 done All buffers synced. Table 'FACP' at 0xcafef000 Table 'SSDT' at 0xcaffd000 Table 'SSDT' at 0xcaffc000 Table 'SSDT' at 0xcaffb000 Table 'ASF!' at 0xcaff1000 Table 'HPET' at 0xcafee000 Table 'APIC' at 0xcafed000 APIC: Found table at 0xcafed000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 4: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 0 ACPI ID 5: disabled MADT: Found CPU APIC ID 0 ACPI ID 6: disabled MADT: Found CPU APIC ID 0 ACPI ID 7: disabled MADT: Found CPU APIC ID 0 ACPI ID 8: disabled Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r249643: Fri Apr 19 13:07:01 EEST 2013 MAN@home.alkar.net:/usr/obj/usr/src/sys/Work amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cdf000. Preloaded elf obj module "/boot/kernel/msdosfs.ko" at 0xffffffff80cdf950. Preloaded elf obj module "/boot/kernel/if_ath.ko" at 0xffffffff80cdfef8. Preloaded elf obj module "/boot/kernel/wlan.ko" at 0xffffffff80ce06a0. Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff80ce0f08. Preloaded elf obj module "/boot/kernel/uhid.ko" at 0xffffffff80ce14b0. Preloaded elf obj module "/boot/kernel/usb.ko" at 0xffffffff80ce1a18. Preloaded elf obj module "/boot/kernel/if_ath_pci.ko" at 0xffffffff80ce2080. Preloaded elf obj module "/boot/kernel/uhci.ko" at 0xffffffff80ce25b0. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0xffffffff80ce2ad8. Preloaded elf obj module "/boot/kernel/msdosfs_iconv.ko" at 0xffffffff80ce3000. Preloaded elf obj module "/boot/kernel/libiconv.ko" at 0xffffffff80ce34b0. Preloaded elf obj module "/boot/modules/cuse4bsd.ko" at 0xffffffff80ce3ae0. Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff80ce4090. Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff80ce45b8. Calibrating TSC clock ... TSC clock: 2195064664 Hz CPU: Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz (2195.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000d04000 - 0x00000000bfa37fff, 3201515520 bytes (781620 pages) 0x0000000100000000 - 0x000000012fde7fff, 803110912 bytes (196072 pages) avail memory = 3829571584 (3652 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff8000244000 x86bios: EBDA 0x09d000-0x09ffff at 0xfffffe000009d000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf00e0 00024 (v02 FUJ ) ACPI: XSDT 0xcaffe120 0008C (v01 FUJ PC 01120000 FUJ 00000001) ACPI: FACP 0xcafef000 000F4 (v03 FUJ PC 01120000 FUJ 00000001) ACPI: DSDT 0xcaff2000 08E91 (v02 FUJ FJNB223 01120000 INTL 20061109) ACPI: FACS 0xcaf42000 00040 ACPI: SSDT 0xcaffd000 00346 (v01 FUJ SataAhci 00000001 INTL 20061109) ACPI: SSDT 0xcaffc000 002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109) ACPI: SSDT 0xcaffb000 000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109) ACPI: ASF! 0xcaff1000 000A5 (v32 FUJ PC 00000001 PTL 00000001) ACPI: HPET 0xcafee000 00038 (v01 FUJ PC 00000001 PTL 00000001) ACPI: APIC 0xcafed000 00098 (v01 FUJ PC 00000001 PTL 00000001) ACPI: MCFG 0xcafec000 0003C (v01 FUJ PC 00000001 PTL 00000001) ACPI: SSDT 0xcafeb000 0090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xcafea000 009F5 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: UEFI 0xcafe9000 0003E (v01 FUJ PC 00000001 PTL 00000001) ACPI: UEFI 0xcafe8000 00042 (v01 PTL COMBUF 00000001 PTL 00000001) ACPI: UEFI 0xcafe7000 00256 (v01 FUJ PC 00000001 PTL 00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Ignoring local NMI routed to ACPI CPU 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 Cuse4BSD v0.1.27 @ /dev/cuse wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 io: kbd: new array size 4 kbd1 at kbdmux0 mem: null: random: acpi0: on motherboard ACPI: All ACPI Tables successfully acquired PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: SSDT 0xcae99618 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI: Marking method _INI as Serialized because of AE_ALREADY_EXISTS error ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node 0xfffffe000a7c1880), AE_ALREADY_EXISTS (20130328/psparse-560) acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 950 msi: routing MSI-X IRQ 256 to local APIC 0 vector 49 msi: routing MSI-X IRQ 257 to local APIC 0 vector 50 msi: routing MSI-X IRQ 258 to local APIC 0 vector 51 msi: routing MSI-X IRQ 259 to local APIC 0 vector 52 msi: routing MSI-X IRQ 260 to local APIC 0 vector 53 msi: routing MSI-X IRQ 261 to local APIC 0 vector 54 msi: routing MSI-X IRQ 262 to local APIC 0 vector 55 msi: routing MSI-X IRQ 263 to local APIC 0 vector 56 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 cpu0: Processor \134_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI: SSDT 0xcadc0818 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) cpu1: Processor \134_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 ACPI: SSDT 0xcadc1a98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xcae9dc18 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) cpu2: Processor \134_PR_.CPU2 (ACPI ID 3) -> APIC ID 2 cpu2: on acpi0 cpu3: Processor \134_PR_.CPU3 (ACPI ID 4) -> APIC ID 3 cpu3: on acpi0 ACPI: Processor \134_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \134_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \134_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \134_PR_.CPU7 (ACPI ID 8) ignored atrtc0: port 0x70-0x77 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 ACPI timer: 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 7 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xcfa00000-0xfeafffff pcib0: decoding 3 range 0xfed40000-0xfed44fff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0104, revid=0x09 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0116, revid=0x09 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0000000, size 22, enabled pcib0: allocated type 3 (0xe0000000-0xe03fffff) for rid 10 of pci0:0:2:0 map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 map[20]: type I/O Port, range 32, base 0x3000, size 6, enabled pcib0: allocated type 4 (0x3000-0x303f) for rid 20 of pci0:0:2:0 pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c3a, revid=0x04 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2605000, size 4, enabled pcib0: allocated type 3 (0xe2605000-0xe260500f) for rid 10 of pci0:0:22:0 pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c2d, revid=0x04 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe260a000, size 10, enabled pcib0: allocated type 3 (0xe260a000-0xe260a3ff) for rid 10 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x1c20, revid=0x04 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe2600000, size 14, enabled pcib0: allocated type 3 (0xe2600000-0xe2603fff) for rid 10 of pci0:0:27:0 pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x1c10, revid=0xb4 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x1c14, revid=0xb4 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1c26, revid=0x04 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe2609000, size 10, enabled pcib0: allocated type 3 (0xe2609000-0xe26093ff) for rid 10 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1c49, revid=0x04 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1c03, revid=0x04 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x3088, size 3, enabled pcib0: allocated type 4 (0x3088-0x308f) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x3094, size 2, enabled pcib0: allocated type 4 (0x3094-0x3097) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x3080, size 3, enabled pcib0: allocated type 4 (0x3080-0x3087) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x3090, size 2, enabled pcib0: allocated type 4 (0x3090-0x3093) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: allocated type 4 (0x3060-0x307f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xe2608000, size 11, enabled pcib0: allocated type 3 (0xe2608000-0xe26087ff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x1c22, revid=0x04 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xe2604000, size 8, enabled pcib0: allocated type 3 (0xe2604000-0xe26040ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0xefa0, size 5, enabled pcib0: allocated type 4 (0xefa0-0xefbf) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 19 vgapci0: port 0x3000-0x303f mem 0xe0000000-0xe03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) pci0:0:22:0: Transition from D0 to D3 ehci0: mem 0xe260a000-0xe260a3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 58 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached hdac0: mem 0xe2600000-0xe2603fff irq 21 at device 27.0 on pci0 hdac0: PCI card vendor: 0x10cf, device: 0x15dc hdac0: HDA Driver Revision: 20120126_0002 hdac0: Config options: on=0x00000000 off=0x00000000 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 264 to local APIC 0 vector 59 hdac0: using IRQ 264 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xe0600000-0xe25fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 9 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xe0600000-0xe25fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib0: allocated type 3 (0xe0500000-0xe05fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 10 pcib2: subordinate bus 10 pcib2: memory decode 0xe0500000-0xe05fffff pcib2: no prefetched decode pci10: on pcib2 pci10: domain=0, physical bus=10 found-> vendor=0x168c, dev=0x002e, revid=0x01 domain=0, bus=10, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xe0500000, size 16, enabled pcib2: allocated memory range (0xe0500000-0xe050ffff) for rid 10 of pci0:10:0:0 pcib2: matched entry for 10.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 60 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 2T2R ath0: 11ng MCS 20MHz ath0: MCS 0-7: 6.5Mbps - 65Mbps ath0: MCS 8-15: 13Mbps - 130Mbps ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons ath0: using multicast key search ehci1: mem 0xe2609000-0xe26093ff irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0xe2608000-0xe26087ff irq 20 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 265 to local APIC 0 vector 62 ahci0: using IRQ 265 for MSI ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: not probed (disabled) ahcich2: not probed (disabled) ahcich3: not probed (disabled) ahcich4: not probed (disabled) ahcich5: not probed (disabled) ahciem0: on ahci0 ahciem0: Caps: ALHD XMT SMB LED ichsmb0: port 0xefa0-0xefbf mem 0xe2604000-0xe26040ff irq 19 at device 31.3 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 63 smbus0: on ichsmb0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 64 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0067 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 65 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ACPI: Enabled 9 GPEs in block 00 to 3F acpi0: wakeup code va 0xffffff8119915000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices ctl: CAM Target Layer loaded est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 Device configuration finished. procfs registered Timecounters tick every 5.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 lo0: bpf attached hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 hdaa0: Subsystem ID: 0x10cf1100 hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: Original pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 29 909701f0 15 0 AUX Fixed Analog Internal Unknown 1 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: Patching widget caps nid=29 0x00400000 -> 0x00700000 hdaa0: Patched pins configuration: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60150 5 0 Mic Fixed Digital Internal Unknown 1 hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 24 02a11040 4 0 Mic Jack 1/8 Front Black 0 hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 26 2121101f 1 15 Headphones Jack 1/8 Ext-Rear Black 0 hdaa0: 27 21a11030 3 0 Mic Jack 1/8 Ext-Rear Black 0 hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: 33 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa0: 5 associations found: hdaa0: Association 0 (1) out: hdaa0: Pin nid=20 seq=0 hdaa0: Pin nid=26 seq=15 hdaa0: Association 1 (2) out: hdaa0: Pin nid=33 seq=0 hdaa0: Association 2 (3) in: hdaa0: Pin nid=27 seq=0 hdaa0: Association 3 (4) in: hdaa0: Pin nid=24 seq=0 hdaa0: Association 4 (5) in: hdaa0: Pin nid=18 seq=0 hdaa0: Tracing association 0 (1) hdaa0: Pin 20 traced to DAC 2 hdaa0: Pin 26 traced to DAC 2 and hpredir 0 hdaa0: Association 0 (1) trace succeeded hdaa0: Tracing association 1 (2) hdaa0: Pin 33 traced to DAC 3 hdaa0: Association 1 (2) trace succeeded hdaa0: Tracing association 2 (3) hdaa0: Pin 27 traced to ADC 8 hdaa0: Association 2 (3) trace succeeded hdaa0: Tracing association 3 (4) hdaa0: Pin 24 traced to ADC 9 hdaa0: Association 3 (4) trace succeeded hdaa0: Tracing association 4 (5) hdaa0: Association 4 (5) trace failed hdaa0: Looking for additional DAC for association 0 (1) hdaa0: Looking for additional DAC for association 1 (2) hdaa0: Looking for additional ADC for association 2 (3) hdaa0: Looking for additional ADC for association 3 (4) hdaa0: Tracing input monitor hdaa0: Tracing nid 11 to out hdaa0: nid 11 is input monitor hdaa0: Tracing nid 35 to out hdaa0: Tracing other input monitors hdaa0: Tracing nid 24 to out hdaa0: Tracing nid 27 to out hdaa0: Tracing beeper hdaa0: Headphones redirection for association 0 nid=26 using unsolicited responses. hdaa0: Redirect output to: main hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm0: at nid 20,26 and 27 on hdaa0 pcm0: Playback: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=26 [pin: Headphones (Black Jack)] pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: Stream cap: 0x00000001 PCM pcm0: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: nid=8 [audio input] pcm0: + <- nid=35 [audio mixer] [src: speaker, mix, monitor] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: + <- nid=27 [pin: Mic (Black Jack)] [src: monitor] pcm0: + <- nid=29 [beep widget] [src: speaker] pcm0: pcm0: Master Volume (OSS: vol): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 17 (nid 20 in ): mute pcm0: +- ctl 22 (nid 26 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm): -65/0dB pcm0: +- ctl 1 (nid 2 out): -65/0dB (88 steps) pcm0: +- ctl 10 (nid 12 in 0): mute pcm0: pcm0: Microphone2 Volume (OSS: monitor): 0/36dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 25 (nid 27 out): 0/36dB (4 steps) pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker): -16/12dB pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: pcm0: Recording Level (OSS: rec): -16/30dB pcm0: +- ctl 3 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 30 (nid 35 in 3): mute pcm0: +- ctl 31 (nid 35 in 4): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Mix Level (OSS: mix): -34/12dB pcm0: +- ctl 8 (nid 11 in 3): -34/12dB (32 steps) + mute pcm0: +- ctl 9 (nid 11 in 4): -34/12dB (32 steps) + mute pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: +- ctl 32 (nid 35 in 5): mute pcm0: pcm0: Input Monitoring Level (OSS: igain): 0/0dB pcm0: +- ctl 11 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "monitor": pcm0: Playback channel set is: Front Left, Front Right, pcm0: Playback channel matrix is: 2.0 (unknown) pcm0: Recording channel set is: Front Left, Front Right, pcm0: Recording channel matrix is: 2.0 (disconnected) pcm1: at nid 33 and 24 on hdaa0 pcm1: Playback: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 3 pcm1: pcm1: nid=33 [pin: Headphones (Black Jack)] pcm1: + <- nid=13 [audio mixer] [src: pcm, mix] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: + <- nid=11 [audio mixer] [src: mix] pcm1: pcm1: Record: pcm1: Stream cap: 0x00000001 PCM pcm1: PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: nid=9 [audio input] pcm1: + <- nid=34 [audio selector] [src: speaker, mic] pcm1: + <- nid=24 [pin: Mic (Black Jack)] [src: mic] pcm1: + <- nid=29 [beep widget] [src: speaker] pcm1: pcm1: Master Volume (OSS: vol): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: +- ctl 26 (nid 33 in ): mute pcm1: pcm1: PCM Volume (OSS: pcm): -65/0dB pcm1: +- ctl 2 (nid 3 out): -65/0dB (88 steps) pcm1: +- ctl 12 (nid 13 in 0): mute pcm1: pcm1: Microphone Volume (OSS: mic): 0/36dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec): -16/30dB pcm1: +- ctl 4 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 20 (nid 24 out): 0/36dB (4 steps) pcm1: pcm1: Input Mix Level (OSS: mix) pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Input Monitoring Level (OSS: igain): 0/0dB pcm1: +- ctl 13 (nid 13 in 1): mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "igain": pcm1: Playback channel set is: Front Left, Front Right, pcm1: Playback channel matrix is: 2.0 (disconnected) pcm1: Recording channel set is: Front Left, Front Right, pcm1: Recording channel matrix is: 2.0 (disconnected) hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 hdaa1: Subsystem ID: 0x80860101 hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdaa1: Original pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 hdaa1: Patched pins configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 5 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 6 18560020 2 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: 7 58560010 1 0 Digital-out None Digital 0x18 Unknown 0 DISA hdaa1: 2 associations found: hdaa1: Association 0 (1) out: hdaa1: Pin nid=5 seq=0 hdaa1: Association 1 (2) out: hdaa1: Pin nid=6 seq=0 hdaa1: Tracing association 0 (1) hdaa1: Pin 5 traced to DAC 2 hdaa1: Association 0 (1) trace succeeded hdaa1: Tracing association 1 (2) hdaa1: Pin 6 traced to DAC 3 hdaa1: Association 1 (2) trace succeeded hdaa1: Looking for additional DAC for association 0 (1) hdaa1: Looking for additional DAC for association 1 (2) hdaa1: Tracing input monitor hdaa1: Tracing other input monitors hdaa1: Tracing beeper hdaa1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref pcm2: at nid 5 on hdaa1 pcm2: Playback: pcm2: Stream cap: 0x00000005 AC3 PCM pcm2: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm2: DAC: 2 pcm2: pcm2: nid=5 [pin: Digital-out (Jack)] pcm2: + <- nid=2 [audio output] [src: pcm] pcm2: pcm2: Master Volume (OSS: vol): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 1 (nid 5 in ): mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel matrix is: unknown, assuming 7.1 (disconnected) pcm3: at nid 6 on hdaa1 pcm3: Playback: pcm3: Stream cap: 0x00000005 AC3 PCM pcm3: PCM cap: 0x001e07f0 16 20 24 32 bits, 32 44 48 88 96 176 192 KHz pcm3: DAC: 3 pcm3: pcm3: nid=6 [pin: Digital-out (Jack)] pcm3: + <- nid=3 [audio output] [src: pcm] pcm3: pcm3: Master Volume (OSS: vol): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: PCM Volume (OSS: pcm): 0/0dB pcm3: +- ctl 2 (nid 6 in ): mute pcm3: pcm3: Mixer "vol": pcm3: Mixer "pcm": pcm3: Soft PCM mixer ENABLED pcm3: Playback channel matrix is: unknown, assuming 7.1 (disconnected) usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=100us status=00000133 ahcich0: AHCI reset: device found acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery1: battery initialization start ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 battery0: battery initialization done, tried 1 times battery1: battery initialization done, tried 1 times ahcich0: AHCI reset: device ready after 100ms pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-9 SATA 3.x device pass0: Serial Number S12PNEACC28675T pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahciem0 bus 0 scbus1 target 0 lun 0 pass1: SEMB S-E-S 2.00 device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S12PNEACC28675T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: new disk ada0 ses0 at ahciem0 bus 0 scbus1 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ses0: Generation Code 0x0 has 1 SubEnclosures ses0: SubEnclosure ID 0, 1 Types With this ID, Descriptor Length 36, offset 8 ses0: WWN: 0 ses0: Type Desc[0]: Type 0x17, MaxElt 6, In Subenc 0, Text Length 0: lapic2: CMCI unmasked lapic3: CMCI unmasked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 3 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 2 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 3 vector 49 msi: Assigning MSI-X IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 2 vector 50 msi: Assigning MSI-X IRQ 259 to local APIC 3 vector 50 msi: Assigning MSI IRQ 265 to local APIC 1 vector 51 SMP: passed TSC synchronization test TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1097532332 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 Trying to mount root from ufs:/dev/ufs/ssdrootfs [ro,noatime]... start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered linsysfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: e0:ca:94:7e:d0:0e ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled nfslock: pseudo-device agp0: on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: 00000000 agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 266 to local APIC 2 vector 51 vgapci0: using IRQ 266 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] AGP at 0xd0000000 256MB iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iic1: on iicbus1 iicbus2: on iicbb1 addr 0xff iic2: on iicbus2 iic3: on iicbus3 iicbus4: on iicbb2 addr 0xff iic4: on iicbus4 iic5: on iicbus5 iicbus6: on iicbb3 addr 0xff iic6: on iicbus6 iic7: on iicbus7 iicbus8: on iicbb4 addr 0xff iic8: on iicbus8 iic9: on iicbus9 iicbus10: on iicbb5 addr 0xff iic10: on iicbus10 iic11: on iicbus11 iicbus12: on iicbb6 addr 0xff iic12: on iicbus12 iic13: on iicbus13 iicbus14: on iicbb7 addr 0xff iic14: on iicbus14 iic15: on iicbus15 info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on drmn0: taking over the fictitious range 0xd0000000-0xe0000000 info: [drm] GMBUS timed out, falling back to bit banging on pin 7 [gmbus bus dpd] info: [drm] Initialized i915 1.6.0 20080730 --nextPart1595643.eQ8gZeXthg-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 11:08:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5022C8BB; Fri, 19 Apr 2013 11:08:55 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id B1EACD9A; Fri, 19 Apr 2013 11:08:54 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so1745570eae.2 for ; Fri, 19 Apr 2013 04:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=rfnw1rE8fyRsEN0oHyvl3tygD8j/7RrgVNoqtlGEpOw=; b=vx2TR2o0HUOv9tpXLAiQUAtkHMFvJQY4KrUKn6r1q4qXkz2Vlk8RUEJyRv5yiEYkQa Pv3wh8C/KjWWMeuqQTLHLfTyZuMLchCWKO9ldq/jJODV2ow2iXRLDaPOwj0Z3/czk+CN d6nbB6Smqmju47xMxunzNrZMfBJ9sqS/9znAljd+ek/w4hsNNLw6Y2WMtnW04ZRVjyTg yyCJhX8Jywktk8XD4IbyO9kdfPuez/0CBTnYfdIiMsOMRvv27yWz2vhdeEhIekKBwWdu d6I3ldZvDxADaCILXEPgU8J/ebDeXMAoLorrWi5G/hRtaVfOaV1G120LHN4GaNqRUXoZ +Tqg== X-Received: by 10.14.174.5 with SMTP id w5mr41337827eel.1.1366369733874; Fri, 19 Apr 2013 04:08:53 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id d47sm22209753eem.9.2013.04.19.04.08.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 19 Apr 2013 04:08:53 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Fri, 19 Apr 2013 14:08:11 +0300 Message-ID: <2717891.HdW8GIoFa8@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: <2381713.gpuUDy5DnR@home.alkar.net> References: <1825476.qO1YuZaJ09@home.alkar.net> <2381713.gpuUDy5DnR@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 11:08:55 -0000 Adrian, I found the problem. I'm use ath as module, so ATH_ENABLE_11N is not defined. When I define ATH_ENABLE_11N - everything work. Artyom Mirgorodskiy On Friday 19 April 2013 13:27:21 wrote: Updated. However I did not see chainmask information. See attached On Friday 19 April 2013 00:57:12 Adrian Chadd wrote: > Hi, > > I've just committed some changes to -HEAD. Please update to the latest > -HEAD and paste me the ath0 dmesg output. > It will include the chainmask information. > > Thanks, > > > Adrian -- Artyom Mirgorodskiy -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 13:26:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 775AB42D; Fri, 19 Apr 2013 13:26:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id E00842D9; Fri, 19 Apr 2013 13:26:46 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id r6so3494119wey.40 for ; Fri, 19 Apr 2013 06:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8qwZlAOF4qjGsDw7BNXmQrTto51vQDpjxHIsdluPBDY=; b=k5xuc/3qLgtMDn4WXHTntL7kCAwUxt8C4+I3q3NXl/EZ9AZ0yDXkj9Exng0meYlFjS zk7Db8CEyzmb9y2OCZ6wBKqW2OQjm+8ZuIQtH6tOeLBi8Nfu8eM8HdyY4ylHhr0RkEeJ vxZOxmRZsarA6yz+np76q0m1BlQT0EqGKOAd6LktBqpvhI+IKlKUinDWHiqQlv6g3nsZ d6Z2SnLdbZ1XZQbMuJAWEZ9OJYvxHljELaHqgzMDpiauRGNQsdFOsPM/5djGWyk/bbUX sTlU323GkBH67nwvXDMA6cF+VCwO02MjVGnKp4Am12zPjmgoeJaT9kEa4O/Jxa81pUmS lZSw== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr25280864wib.23.1366378005934; Fri, 19 Apr 2013 06:26:45 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Fri, 19 Apr 2013 06:26:45 -0700 (PDT) In-Reply-To: <2717891.HdW8GIoFa8@home.alkar.net> References: <1825476.qO1YuZaJ09@home.alkar.net> <2381713.gpuUDy5DnR@home.alkar.net> <2717891.HdW8GIoFa8@home.alkar.net> Date: Fri, 19 Apr 2013 06:26:45 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 13:26:47 -0000 oooooo good to know! let me setup the chainmask info whether or not the 11n option is set. thanks! adrian On 19 April 2013 04:08, Artyom Mirgorodskiy wrote: > Adrian, I found the problem. > > I'm use ath as module, so ATH_ENABLE_11N is not defined. When I define > ATH_ENABLE_11N - everything work. > > > > > > Artyom Mirgorodskiy > > > > On Friday 19 April 2013 13:27:21 wrote: > > Updated. However I did not see chainmask information. > > See attached > > > > On Friday 19 April 2013 00:57:12 Adrian Chadd wrote: > >> Hi, > >> > >> I've just committed some changes to -HEAD. Please update to the latest > >> -HEAD and paste me the ath0 dmesg output. > >> It will include the chainmask information. > >> > >> Thanks, > >> > >> > >> Adrian > > -- > > Artyom Mirgorodskiy > > > -- > > Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 14:57:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 74DD2567; Fri, 19 Apr 2013 14:57:41 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id D991669F; Fri, 19 Apr 2013 14:57:40 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h14so1191061eak.35 for ; Fri, 19 Apr 2013 07:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DaZXHyhzBqvKiQE/H+RKkvQKCzOaKsSfpgzzqoqPNZw=; b=ituMZG6yVXawasNtvzLNpn84hd3pzgnMqB2mZjKNc5jgOeIgGSPGW19/hnaGPRH+mF thOFlHmX4FjX1upBWxrpdbAfQI/ghHqH38AIvtDR5TmbbXhgCya5vnAWgtOAbnxKkE0J 3I08sLykBr9fsxFmsuhXdu84ywt3+rJ/O54hKdSPR0mv+zMyLMEOX97fOnIw/IMJ6kAM kXrBqLl7hF3JaEnWWC+YEzX37cyFy2CPhdxxXrh/QyiXNS+z7BiKN8K91e3ii6R69ZDJ FEeGhdr25/QIQZpBFZCL2m0J2NDJqWDpAkLI+mjj6fWjYrAFDCtjZ+7ajaiOsyqsroPW /+0w== MIME-Version: 1.0 X-Received: by 10.15.76.132 with SMTP id n4mr11083851eey.16.1366381810700; Fri, 19 Apr 2013 07:30:10 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.15.91.72 with HTTP; Fri, 19 Apr 2013 07:30:09 -0700 (PDT) Received: by 10.15.91.72 with HTTP; Fri, 19 Apr 2013 07:30:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 07:30:09 -0700 X-Google-Sender-Auth: LsXakADcAMEoVNg_hXnX9Vww1ZA Message-ID: Subject: Re: Cannot unmount nullfs in current From: hiren panchasara To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 14:57:41 -0000 On Apr 18, 2013 7:04 PM, "Craig Rodrigues" wrote: > > Hi, > > I am trying to build some software which uses > nanobsd, and mounts/unmounts many nullfs mounts > while it runs. I am hitting failures where > I cannot unmount nullfs file systems. I cannot figure out why. I am also getting similar failures while trying to build freenas. > > Here is more info. > > SYSTEM > ====== > I am running amd64, current build at this revision: > > 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r249181: Sat Apr 6 03:07:32 UTC 2013 > amd64 > > STEPS TO REPRODUCE > =============== > > (1) Create a directory, /opt2/branches. Make sure that /opt2/branches > is on ZFS > > (2) > mkdir -p /opt2/branches/freenas > mkdir -p /opt2/branches/freenas-cache > > (3) > > git clone git://github.com/freenas/freenas.git /opt2/branches/freenas > git clone git:// github.com/freenas/ports.git/opt2/branches/freenas-cache/ports > git clone git:// github.com/trueos/trueos.git/opt2/branches/freenas-cache/trueos > > (4) sudo to root > > (5) cd /opt2/branches/freenas > > (6) > script build.log env GIT_REPO=/opt2/branches/freenas-cache/trueos \ > GIT_PORTS_REPO=/opt2/branches/freenas-cache/ports \ > sh build/do_build.sh > > > The build cranks for a while, and then I get this error: > > 00:02:37 ### log: > /opt2/branches/freenas/os-base/amd64/_.cust.add_pkg_archivers_lzo2 I do not get this. > do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build > FAILED; please check above log for more details I get this which looks like a generic build failure message. I do not have gnome or any X related things. > > > > If I look in .cust.add_pkg_archivers_lzo2, I see this error: > > + umount /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > umount: unmount of > /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles failed: Device > busy Where do you find/see logs for the build? Another weird thing. Somehow my /sbin was wiped out and only had some pbi-* files in it. This happened to me on 2 different machines while trying to build freenas. I will try to take a closer look today when time permits. Thanks, Hiren > > > If I try to do this manually: > > # umount /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > umount: unmount of > /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles failed: Device > busy > > > I can't figure out why this mount is busy. > If I do: > > umount -f /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > > it unmounts, but I don't like using the '-f' flag to force the unmount. > > Any ideas? I am attaching some of my logs. > > -- > Craig > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 15:39:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 323C0E9D; Fri, 19 Apr 2013 15:39:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2A10B8D2; Fri, 19 Apr 2013 15:39:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA25077; Fri, 19 Apr 2013 08:19:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UT3iv-000K0d-CH; Fri, 19 Apr 2013 08:19:01 +0300 Message-ID: <5170D3C5.1080705@FreeBSD.org> Date: Fri, 19 Apr 2013 08:19:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: Cannot unmount nullfs in current References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 15:39:24 -0000 on 19/04/2013 02:27 Craig Rodrigues said the following: > I can't figure out why this mount is busy. > If I do: > > umount -f /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > > it unmounts, but I don't like using the '-f' flag to force the unmount. > > Any ideas? fstat? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 15:40:57 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BD0735F; Fri, 19 Apr 2013 15:40:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E77CA29; Fri, 19 Apr 2013 15:40:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3JDJFi8035934; Fri, 19 Apr 2013 09:19:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3JDJFn5035913; Fri, 19 Apr 2013 13:19:15 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 19 Apr 2013 13:19:15 GMT Message-Id: <201304191319.r3JDJFn5035913@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:40:57 -0000 TB --- 2013-04-19 09:39:55 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-19 09:39:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-19 09:39:55 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-19 09:39:55 - cleaning the object tree TB --- 2013-04-19 09:39:55 - /usr/local/bin/svn stat /src TB --- 2013-04-19 09:40:04 - At svn revision 249637 TB --- 2013-04-19 09:40:05 - building world TB --- 2013-04-19 09:40:05 - CROSS_BUILD_TESTING=YES TB --- 2013-04-19 09:40:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-19 09:40:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-19 09:40:05 - SRCCONF=/dev/null TB --- 2013-04-19 09:40:05 - TARGET=pc98 TB --- 2013-04-19 09:40:05 - TARGET_ARCH=i386 TB --- 2013-04-19 09:40:05 - TZ=UTC TB --- 2013-04-19 09:40:05 - __MAKE_CONF=/dev/null TB --- 2013-04-19 09:40:05 - cd /src TB --- 2013-04-19 09:40:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Apr 19 09:40:10 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 19 12:54:48 UTC 2013 TB --- 2013-04-19 12:54:48 - generating LINT kernel config TB --- 2013-04-19 12:54:48 - cd /src/sys/pc98/conf TB --- 2013-04-19 12:54:48 - /usr/bin/make -B LINT TB --- 2013-04-19 12:54:48 - cd /src/sys/pc98/conf TB --- 2013-04-19 12:54:48 - /usr/sbin/config -m LINT TB --- 2013-04-19 12:54:48 - building LINT kernel TB --- 2013-04-19 12:54:48 - CROSS_BUILD_TESTING=YES TB --- 2013-04-19 12:54:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-19 12:54:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-19 12:54:48 - SRCCONF=/dev/null TB --- 2013-04-19 12:54:48 - TARGET=pc98 TB --- 2013-04-19 12:54:48 - TARGET_ARCH=i386 TB --- 2013-04-19 12:54:48 - TZ=UTC TB --- 2013-04-19 12:54:48 - __MAKE_CONF=/dev/null TB --- 2013-04-19 12:54:48 - cd /src TB --- 2013-04-19 12:54:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 19 12:54:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-19 13:19:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-19 13:19:15 - ERROR: failed to build LINT kernel TB --- 2013-04-19 13:19:15 - 10573.87 user 1488.54 system 13160.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 15:45:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7202CAE2 for ; Fri, 19 Apr 2013 15:45:51 +0000 (UTC) (envelope-from opera23@operamail.com) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 499D3CC3 for ; Fri, 19 Apr 2013 15:45:51 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BFC8A20EA9 for ; Fri, 19 Apr 2013 04:37:35 -0400 (EDT) Received: from web5.nyi.mail.srv.osa ([10.202.2.215]) by compute5.internal (MEProxy); Fri, 19 Apr 2013 04:37:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=operamail.com; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=mesmtp; bh=ukP2eLxnlogqspcUIWSodqh bYyo=; b=UavcqpXX8lroeYH027PfswHrJOLWWiVe4bADb89kJ54AV4ZsvrDCKut XIuXzDnSUjgvYDfxeUbrUBLdqEmnp969uT4QeRVpfv6jwz+buMIrPjaGOxlVIetM ht2GGvBTpSwo+mYqr4Su+emjr8dthdGwq66Y9m8EJKAlWWnJ//Q4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=ukP2eLxnlogqspcUIWSodqhbYyo=; b=X3FAyvw1cMWAqF78afh75L+e0A6I phAklcx6mvXoM8JH0blNy0dRkTWI8qlDtCkF2jlXcUYC4+a2/K759uypMoe6cpxg 1xCVNGpAeAdryBr4wz+c19TEsmu4obiL14N3RUmpUGj4bWp7ctYYR4HOitmMXwYG BsO0tQOiYvBqReA= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id C78DA5FEBDF; Fri, 19 Apr 2013 04:37:34 -0400 (EDT) Message-Id: <1366360654.23150.140661219897674.1011A23C@webmail.messagingengine.com> X-Sasl-Enc: SuVpIdyBFqxgF8qf9nZyvpZEE7xcsssDfFcpWOj0m0Og 1366360654 From: fname lname To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-3ef74f37 Subject: no boot 91stable-last april13(486no acpi Date: Fri, 19 Apr 2013 01:37:34 -0700 X-Mailman-Approved-At: Fri, 19 Apr 2013 15:53:43 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 15:45:51 -0000 486! system.stop after init. boot safe mode (only kernel enable?(no acpi -- fname lname opera23@operamail.com -- http://www.fastmail.fm - A fast, anti-spam email service. From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 15:46:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3AF8B13; Fri, 19 Apr 2013 15:46:06 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 2498CCDF; Fri, 19 Apr 2013 15:46:05 +0000 (UTC) Received: from cicuta.babolo.ru (cicuta.babolo.ru [194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id r3J9uDdu051446; Fri, 19 Apr 2013 13:56:13 +0400 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 94223 invoked by uid 136); Fri, 19 Apr 2013 10:06:20 -0000 Date: Fri, 19 Apr 2013 14:06:20 +0400 From: Aleksandr A Babaylov <.@babolo.ru> To: David Demelier Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130419100620.GA94200@babolo.ru> References: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Fri, 19 Apr 2013 15:53:58 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Gary Palmer , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 15:46:06 -0000 On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote: > 2013/4/14 Gary Palmer : > > Do we honestly need three packet filters? > > No, for me only one should be present. I completely understand that > some users still use IPFilter and IPFW but why providing three packet > filters? > > The answer should be: use one and document only one. If at the > beginning we started documenting only one all users should have used > the only one present. Now we really need to remove the ancestral > ipfilter and tell people switching to pf(4). IPFW. It is more logical and easy to use in complex context. > Everything in life change, if we need to maintain all code from the > past we will have a lot of compat code that pollute the full source > tree and we will never improve the code just because of old bits From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 17:43:52 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 28105DEA; Fri, 19 Apr 2013 17:43:52 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 02FB63CA; Fri, 19 Apr 2013 15:55:55 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UTBTi-000CLU-7K; Fri, 19 Apr 2013 13:35:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r3JDZkhf014123; Fri, 19 Apr 2013 07:35:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19HSUEGetv7tazuvpf4XMDu Subject: Re: Cannot unmount nullfs in current From: Ian Lepore To: Craig Rodrigues In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Apr 2013 07:35:46 -0600 Message-ID: <1366378546.1231.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 17:43:52 -0000 On Fri, 2013-04-19 at 01:12 -0700, Craig Rodrigues wrote: > On Thu, Apr 18, 2013 at 4:27 PM, Craig Rodrigues wrote: > > > Hi, > > > > I am trying to build some software which uses > > nanobsd, and mounts/unmounts many nullfs mounts > > while it runs. I am hitting failures where > > I cannot unmount nullfs file systems. I cannot figure out why. > > > > > I forgot to run fstat. :( > > fstat /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME > rodrigc gam_server 2275 37 > /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles 3194579 > drwxr-xr-x 196 r > /opt2/branches/freenas/os-base/amd64/_.w/usr/ports/distfiles > > > Since I run the GNOME desktop, gnome has a dependency on the gamin port. > The gamin port contains gam_server. > gamin monitors file system activity. It looks like gam_server gets > triggered > when things are mounted, and for some reason, sometimes fails to go away. > > I need to read http://people.gnome.org/~veillard/gamin/config.html and > figure out how to disable gamin, > or just remove gamin from my system. Annoying. :( > I worked around this kind of problem by putting a single entry in /usr/local/etc/gamin/gaminrc: poll /* It might be slightly less efficient to have gamin polling all mounts instead of getting change notices from the kernel, but I've never really noticed any performance hit, even with dozens of nullfs and devfs mounts in various chroots. -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 17:48:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FB0271E; Fri, 19 Apr 2013 17:48:52 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id E5B9D889; Fri, 19 Apr 2013 17:48:51 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id ar20so5015255iec.14 for ; Fri, 19 Apr 2013 10:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B2PVB8cMSMjH86q4mCsr0c1/Pu6/ba/kyJtm9aD+ScI=; b=SiXpdu7naWvwD6CGtzusMIYQRjmFINV7XLKCDiFbLR4SZQxO6fK0p4HhQ5/UPf0Gfp ukB2R6r8iIgzcXm3bz6PleE1UF2I3K+iaj+Rpupgzf9O1WSBAtqmrViSKxwkyHZ3dK// c9YnJOf7ltaIPKZ5jBzpNwVdZKgssQBNmFTIMaGOWlpMkIIgbBiDUaAzJPAC17/87xou xih6Duidrb+JfY+IIs+O7UwmFdz3jdHMDvtgebw7zHH6bAL52x/rc3T5NjreVrOgHHTF iunFlVTIp0AKBd9nXAt8CE7H8Po9tnz7kFC7WvNa2//qtq+FOmFoO4aZ7b8LuHdwJTpl tpGA== MIME-Version: 1.0 X-Received: by 10.50.42.165 with SMTP id p5mr16329322igl.75.1366392355057; Fri, 19 Apr 2013 10:25:55 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Fri, 19 Apr 2013 10:25:54 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Fri, 19 Apr 2013 10:25:54 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Fri, 19 Apr 2013 18:25:54 +0100 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Chris Rees To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Gary Palmer , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 17:48:52 -0000 On 19 Apr 2013 10:46, "David Demelier" wrote: > > 2013/4/14 Gary Palmer : > > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: > >> Is it possible to move ipfilter into a port? > > > > That may work short term, but the ENOMAINTAINER problem will quickly creep > > up again as kernel APIs change. If the author has lost interest in > > maintaining the FreeBSD port of ipfilter then unless someone steps forward > > to carry on the work, I don't see much of a future for ipfilter in > > FreeBSD > > > > Do we honestly need three packet filters? > > > > No, for me only one should be present. I completely understand that > some users still use IPFilter and IPFW but why providing three packet > filters? > > The answer should be: use one and document only one. If at the > beginning we started documenting only one all users should have used > the only one present. Now we really need to remove the ancestral > ipfilter and tell people switching to pf(4). > > Everything in life change, if we need to maintain all code from the > past we will have a lot of compat code that pollute the full source > tree and we will never improve the code just because of old bits These so called "old bits" are both maintained, and have different strengths. Removing dead unmaintained code yes, but having choice makes transition easier from other OSes; the fewer parts to change at a time, the better. Chris From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 17:55:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 88786821 for ; Fri, 19 Apr 2013 17:55:09 +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]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFEDAE0 for ; Fri, 19 Apr 2013 17:55:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UTA0P-000pKX-SK>; Fri, 19 Apr 2013 14:01:29 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UTA0P-000EBu-PW>; Fri, 19 Apr 2013 14:01:29 +0200 Subject: sysctl -a: Crashes CURRENT From: "O. Hartmann" To: freebsd-current Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Apr 2013 14:01:29 +0200 Message-ID: <1366372889.1828.7.camel@telesto> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 17:55:09 -0000 trying to read the temperature on an Intel Core-i7 3930K box (10.0-CURRENT #2 r249647: Fri Apr 19 13:22:41 CEST 2013 amd64) via sysctl -a|grep tempe crashes sporadically the system due to panic/page fault and dumps core. I'm not able to reproduces this behaviour by intention, as I stated at the beginning, the crash occurs sporadically. That also happened once on a Core2Duo based box (Intel E8400), but also not being reproducable. First occurence was over Easter. Since all the boxes in question use the Intel temperature sensor driver in-core, the question is whether there is a known issue and I better do not use the driver (device coretemp). Since I'm also incapable of triggering this error by will, I'm sorry not providing more informations. the last incident was during kernel compilation, but at this very moment, I recompile also a kernel and try trigering the crash - but it doesn't work. Oliver From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 17:58:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED0BCDA0; Fri, 19 Apr 2013 17:58:47 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by mx1.freebsd.org (Postfix) with ESMTP id C2174B8B; Fri, 19 Apr 2013 17:58:47 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id kl13so2409570pab.32 for ; Fri, 19 Apr 2013 10:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L5MGv5O4pZ2j2f/MYhlBaZpNlfr/nP1SZTUMuRo4oHs=; b=N3/6hYpU9zAiwN/akrZskWoJCDBdXVXub6/oyf9KA6k5EPpygfTEUVEwZW9urY6r+m TbbjPGfGNKtLiVIOdlFY7t43cXKfGUIBgVB4Aau6UrxpwVmPAIYvYTidjNN9BSAvL3fO YLW8lYAKXi1amq8QFlsiSwU4fK0oulkdfZzJZ7B739bHdA2c1YtsYbXFXhP6y0RBL/QC aPqeyB6Ciht805BAIpAglOEnnxeyN8i+UO13CIawOdDJHV3PW2o4VLbiUqc4oX8tstD/ a474ICgk1cGhxRewIoyQZixIxkq6WgwmTuDfoS9mskU5Bv+bV9OGNZjLIKacn0ei9dh0 lOQw== MIME-Version: 1.0 X-Received: by 10.68.184.100 with SMTP id et4mr14824314pbc.48.1366390768074; Fri, 19 Apr 2013 09:59:28 -0700 (PDT) Received: by 10.68.230.233 with HTTP; Fri, 19 Apr 2013 09:59:27 -0700 (PDT) Received: by 10.68.230.233 with HTTP; Fri, 19 Apr 2013 09:59:27 -0700 (PDT) In-Reply-To: <5170D3C5.1080705@FreeBSD.org> References: <5170D3C5.1080705@FreeBSD.org> Date: Fri, 19 Apr 2013 19:59:27 +0300 Message-ID: Subject: Re: Cannot unmount nullfs in current From: Alexander Yerenkow To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Craig Rodrigues , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 17:58:48 -0000 Can we pretend an user-friendly-os and spam to syslog corresponding blocking file and process whenever umount going to fail ? :) Like, make this to be default ( or with some key at least ) behavior of umount. Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 17:59:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 40130F9B for ; Fri, 19 Apr 2013 17:59:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 16455C36 for ; Fri, 19 Apr 2013 17:59:52 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id bn7so2861381ieb.13 for ; Fri, 19 Apr 2013 10:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=6T/V1K2k2KI3wekWLOtb8snj1csp+AwQ7FyOeU8iIrM=; b=Ck5vSPCdb0z3SCxqj9q2DxL1WXNXnBSQH2TmlKNNZ0urV4mYwyDVDA4GQ0ABSGKiXY NcWF/v9IRs5blr25IqbrK30Xdjsmmpu43pMG30SIowlhm9vppZBMWPG0B2ygXnjc2G1/ u7oFPSvIEV3HMXh2Xqz5qGB/te4YQILJyGuI3J8SqdtYSmIyeS6/2+Anye0Qo4m10JEg EMkkvBVf11J70uVOfcO2YUl0NuJzKbZELkkVUcgj8982MWyJYEaA0lxneScpVQJkl6s7 xQCZ2ZzeVlaUO0AjJBtuy2szNDjxzEZn0yjOal4u2rRyLRfIJ+yfFGzbSK8KuvcwNYEj YuoA== X-Received: by 10.50.57.78 with SMTP id g14mr3954305igq.87.1366394391641; Fri, 19 Apr 2013 10:59:51 -0700 (PDT) Received: from gloom.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPSA id xf4sm3752691igb.8.2013.04.19.10.59.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 10:59:50 -0700 (PDT) Date: Fri, 19 Apr 2013 13:59:36 -0400 From: Mark Johnston To: "O. Hartmann" Subject: Re: sysctl -a: Crashes CURRENT Message-ID: <20130419175936.GA4466@gloom.sandvine.com> References: <1366372889.1828.7.camel@telesto> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1366372889.1828.7.camel@telesto> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 17:59:52 -0000 On Fri, Apr 19, 2013 at 02:01:29PM +0200, O. Hartmann wrote: > trying to read the temperature on an Intel Core-i7 3930K box > (10.0-CURRENT #2 r249647: Fri Apr 19 13:22:41 CEST 2013 amd64) via > > sysctl -a|grep tempe > > crashes sporadically the system due to panic/page fault and dumps core. > > I'm not able to reproduces this behaviour by intention, as I stated at > the beginning, the crash occurs sporadically. > > That also happened once on a Core2Duo based box (Intel E8400), but also > not being reproducable. > > First occurence was over Easter. > > Since all the boxes in question use the Intel temperature sensor driver > in-core, the question is whether there is a known issue and I better do > not use the driver (device coretemp). Why do you think this has anything to do with coretemp? What backtraces are you getting? > > Since I'm also incapable of triggering this error by will, I'm sorry not > providing more informations. the last incident was during kernel > compilation, but at this very moment, I recompile also a kernel and try > trigering the crash - but it doesn't work. > > Oliver > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 18:17:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF3D4D20; Fri, 19 Apr 2013 18:17:41 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 497A1104F; Fri, 19 Apr 2013 18:17:41 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id er20so3855162lab.0 for ; Fri, 19 Apr 2013 11:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lIAJQGzBDlqx2TFZh+Ft8ATAb3uYX2wdpAAzeV9xxv8=; b=AzxeMfsbQi/KiDBngRn4/6tTvWlbVlI0z8y72Gg7nrkA041ZpqcItSAcyo0I6TtyuP l1C+bdu18rjDokiXy0NKWfk7GmtKuUi22YRvBvUhhb5RydbK7HpaZf6+MwqnXeyA0RNv o+xC9YfVGYPJxSc7vd4ovpkA33MVjZ11/rKzmINtbVaP+e3BDmoMvYX/5s+wPOFieiPU TUPPDzCLiuqITF5a1BQdohKEHtPmer4Pem6DH9uVnBP6Hbw9EkQylssV8olbEGOTpOog PABiixFKIJtDKfSRDMznYsWx31rF3t117Yt+MA+5/3rO84rJE8OUXNV1LRFK4pp355KC Sddw== MIME-Version: 1.0 X-Received: by 10.112.133.4 with SMTP id oy4mr8681158lbb.22.1366395460254; Fri, 19 Apr 2013 11:17:40 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Fri, 19 Apr 2013 11:17:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 11:17:40 -0700 X-Google-Sender-Auth: jRw9Apv7B48dIp-rpU8xJs-BqUU Message-ID: Subject: Re: Cannot unmount nullfs in current From: Craig Rodrigues To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 18:17:42 -0000 On Fri, Apr 19, 2013 at 7:30 AM, hiren panchasara wrote: > > > > > 00:02:37 ### log: > > /opt2/branches/freenas/os-base/amd64/_.cust.add_pkg_archivers_lzo2 > > I do not get this. > > do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build > > FAILED; please check above log for more details > > I get this which looks like a generic build failure message. > > I do not have gnome or any X related things. > Where do you find/see logs for the build? > > > When building freenas, instead of doing: sh build/do_build.sh if you do: sh build/do_build.sh -x This enables a lot of tracing output. Also, when you see an error message such as: do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build FAILED; please check above log for more details Then you need to scroll up a bit to see which log file it is referring to. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 18:36:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F6C5886; Fri, 19 Apr 2013 18:36:30 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id C7C5E1306; Fri, 19 Apr 2013 18:36:29 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hq17so1249277wib.17 for ; Fri, 19 Apr 2013 11:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=raTpIl7JUyukIdoRNd0HASYcOOXAAeC6aMwB1Xdgnts=; b=Ga1f0jjpccY5F4LoG55RTHZRDdtmYKfNgc3V/uEN/Ws9DRnbgZupQZvyJR9p7Iicy6 Ozf2P8wS5YkVfqwakJzAIQflkbHlbneYmJeVimoezFoAJ+0BvrUAbjm/h6WK71bW/VNg w7XpS/2QhTtk97GJhNmBggzCnn+qcBsGgmOmST8wGYZYSOggmvkHvIxw0VcFQRGj+spd LhWs617Awn0QjjCi3xdbmVWsKjkmq98W6nhogHfKsJG79gxiqYo+lmLff1IHA9fWm+Rq I6k2v0UEb8wpmPccvRMwZ+QKhxfOpWA1a7Y6B7s9VYXdy406f3NDrhGf2OgQOKmX+fGm iRjQ== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr27913522wjb.24.1366396589004; Fri, 19 Apr 2013 11:36:29 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.15.91.72 with HTTP; Fri, 19 Apr 2013 11:36:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 11:36:28 -0700 X-Google-Sender-Auth: Mf4D2IS4HzvqXNP150Y9hz7raNo Message-ID: Subject: Re: Cannot unmount nullfs in current From: hiren panchasara To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 18:36:30 -0000 On Fri, Apr 19, 2013 at 11:17 AM, Craig Rodrigues wrote: > On Fri, Apr 19, 2013 at 7:30 AM, hiren panchasara wrote: >> >> > >> >> > 00:02:37 ### log: >> > /opt2/branches/freenas/os-base/amd64/_.cust.add_pkg_archivers_lzo2 >> >> I do not get this. >> >> > do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build >> > FAILED; please check above log for more details >> >> I get this which looks like a generic build failure message. >> >> I do not have gnome or any X related things. >> >> Where do you find/see logs for the build? >> >> > > > When building freenas, instead of doing: > > sh build/do_build.sh > > if you do: > > sh build/do_build.sh -x > > This enables a lot of tracing output. > > Also, when you see an error message such as: > > do_build.sh: ERROR: FreeNAS /opt2/branches/freenas/nanobsd/os-base build > FAILED; please check above log for more details > > Then you need to scroll up a bit to see which log file it is referring to. I had tried that without success. I did not get any pointer to where the error might be. I may have failed well before starting any building. One of the reasons might be that I had git port without svn support. Some of the buildscripts magic for git-svn interaction may have failed because of that. I am trying to fix that right now and give this another try. cheers, Hiren > > -- > Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 19:07:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 350E6BE0; Fri, 19 Apr 2013 19:07:32 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 822671798; Fri, 19 Apr 2013 19:07:31 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id q13so3973568lbi.23 for ; Fri, 19 Apr 2013 12:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YPDiZDZmx2WGHIAZk98sEO7oddbBxF3JdgaxDkJixoY=; b=smdqlRk9GWAf7JYOvOTBrCe7d7kxnoXkOTq4AyK8VuSlxG4LJU3qJWgy7TGam3/117 h+WVM7+rbGeyqNwgtBYdnOXbblizvp3piIgcdUjw+KiXIE3ISRJYHJnwkW46PgO27BQK +FEIajrFcArKd+JcQea+xceXj3skSyrhxSkA3KQxoaxwaTDCaUpUx27a/qK+HwUsqLxw wKO9Tv1HdLgwcz8YyQVdwn8kTWxqV6jTuxxs1rIjzhSfYQLJxcJ2/u2jnPAKUxmYlQcp jZD8X7EnawzKlGl6jbyVdkQHCmsM7hHGaPVg64z0/xVKHBzcITgPx/hBq2YlPjy3T6t2 L03w== MIME-Version: 1.0 X-Received: by 10.112.198.227 with SMTP id jf3mr8664951lbc.69.1366398450074; Fri, 19 Apr 2013 12:07:30 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Fri, 19 Apr 2013 12:07:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 12:07:29 -0700 X-Google-Sender-Auth: iWWxqLmcY8Kh0RaG8O1g02Lwdfw Message-ID: Subject: Re: Cannot unmount nullfs in current From: Craig Rodrigues To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 19:07:32 -0000 On Fri, Apr 19, 2013 at 11:36 AM, hiren panchasara wrote: > > I had tried that without success. I did not get any pointer to where > the error might be. I may have failed well before starting any > building. One of the reasons might be that I had git port without svn > support. Some of the buildscripts magic for git-svn interaction may > have failed because of that. > > I am trying to fix that right now and give this another try. > > Yes, you are right. I found that to the hard way. You need devel/git-subversion and not devel/git port installed. Somewhere in the build "git svn" is invoked, and will fail if you don't have devel/git-subversion installed. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 19:11:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3765BD23; Fri, 19 Apr 2013 19:11:04 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 8700417C6; Fri, 19 Apr 2013 19:11:03 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id el20so3873033lab.37 for ; Fri, 19 Apr 2013 12:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pz/NfVkcOt+ZmgR56lxvkB2bkfr0HGgaRTAoCgZ4LiY=; b=scF5kVC/wsEAgoRJfjo01OJHN3xV8xqmEuiFznH6pY7p1uW4oG76dib3AtedWR0bnb 4U/xrd7ekyBx64CA9y73H6TssQ20gwu+X3Vij157ST8gLyvAov5K6B8qlFJO5mb7eSxI 5o055O1t+Hf+hlQmTy6I/fONmhVpvW0S8Ul26K4qpOdEmdlaPonqaOYWie6xUbQtqlj+ aC82yXM1ZNkDKjWS8Q076gllMPzVu79lrZhJfV272O5yytqfZkA/2VROSqNpOBl71Fnr gpNzw247KL1v9MWmVq25dg1vpI+5437qe8OQwOWsT0+5W7Gl489HX65KmzR3nCqCgQvp 4ilA== MIME-Version: 1.0 X-Received: by 10.152.30.106 with SMTP id r10mr8779952lah.28.1366398662385; Fri, 19 Apr 2013 12:11:02 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Fri, 19 Apr 2013 12:11:02 -0700 (PDT) In-Reply-To: <1366378546.1231.4.camel@revolution.hippie.lan> References: <1366378546.1231.4.camel@revolution.hippie.lan> Date: Fri, 19 Apr 2013 12:11:02 -0700 X-Google-Sender-Auth: xyYmymhHSAxNYA6cgX_NRAmKDsk Message-ID: Subject: Re: Cannot unmount nullfs in current From: Craig Rodrigues To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 19:11:04 -0000 On Fri, Apr 19, 2013 at 6:35 AM, Ian Lepore wrote: > > I worked around this kind of problem by putting a single entry > in /usr/local/etc/gamin/gaminrc: > > poll /* > > That's one option. I used a "hammer" approach, and after reading http://people.gnome.org/~veillard/gamin/config.html, I put this in my /usr/local/etc/gamin/gaminrc: fsset nullfs none fsset ufs none fsset zfs none I think that is supposed to turn off gamin for any nullfs, ufs, or zfs file system. :) It seems to work for me. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 20:55:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D9060730; Fri, 19 Apr 2013 20:55:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AFD521DED; Fri, 19 Apr 2013 20:55:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3JKtVjq097577; Fri, 19 Apr 2013 16:55:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3JKtViO097573; Fri, 19 Apr 2013 20:55:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 19 Apr 2013 20:55:31 GMT Message-Id: <201304192055.r3JKtViO097573@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:55:33 -0000 TB --- 2013-04-19 20:40:33 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-19 20:40:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-19 20:40:33 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-19 20:40:33 - cleaning the object tree TB --- 2013-04-19 20:42:18 - /usr/local/bin/svn stat /src TB --- 2013-04-19 20:42:32 - At svn revision 249650 TB --- 2013-04-19 20:42:33 - building world TB --- 2013-04-19 20:42:33 - CROSS_BUILD_TESTING=YES TB --- 2013-04-19 20:42:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-19 20:42:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-19 20:42:33 - SRCCONF=/dev/null TB --- 2013-04-19 20:42:33 - TARGET=pc98 TB --- 2013-04-19 20:42:33 - TARGET_ARCH=i386 TB --- 2013-04-19 20:42:33 - TZ=UTC TB --- 2013-04-19 20:42:33 - __MAKE_CONF=/dev/null TB --- 2013-04-19 20:42:33 - cd /src TB --- 2013-04-19 20:42:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Apr 19 20:42:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTDiagnostic.cpp -o ASTDiagnostic.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTDumper.cpp -o ASTDumper.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTImporter.cpp -o ASTImporter.o /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTImporter.cpp: In destructor 'virtual clang::ASTImporter::~ASTImporter()': /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTImporter.cpp:4333: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [ASTImporter.o] Error code 1 Stop in /src/lib/clang/libclangast. *** [all] Error code 1 Stop in /src/lib/clang. *** [cross-tools] Error code 1 Stop in /src. *** [_cross-tools] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-19 20:55:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-19 20:55:31 - ERROR: failed to build world TB --- 2013-04-19 20:55:31 - 559.82 user 146.30 system 897.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 21:36:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F1D54FC; Fri, 19 Apr 2013 21:36:06 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id B6D3161; Fri, 19 Apr 2013 21:36:05 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hj19so1478758wib.15 for ; Fri, 19 Apr 2013 14:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6l3JCggpIEA+nSGm/x5gXhyw2WgKPsR44gL/+lwZ1Ec=; b=EZOwz/zHx3igw4Qd4vz9fT7a/iIseLTYGvFksUvLgX1MStm2Khc1+tqnuEpGotzVDA BT8mrSnTN8LcAzMlyrsm6BLLXkldyTvZ4/MW3UTdvPRruJLsydTfYm4jwyYf7OIXtdCI u0bZH7edSjPK9TKfPPw3zA+dgW/drbrUfs9nkUCiR7UH7RIwMY+XJfATe9SMO/xdjBD9 lUEbIA0oROChmnuVDwT3WDkqeWDjuEp8p6gvFN4S6SZshB6Q6+J6RTvmmJ/GD3ZsUSx4 iicLlli6OGpWpe4ckp3c3skJV+MNZ0d752qnrkZba8fK0hU29Q/2GYcMOyzUEvCiZRO3 agYA== MIME-Version: 1.0 X-Received: by 10.180.205.135 with SMTP id lg7mr14670263wic.11.1366407364895; Fri, 19 Apr 2013 14:36:04 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.15.91.72 with HTTP; Fri, 19 Apr 2013 14:36:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 14:36:04 -0700 X-Google-Sender-Auth: rb3pgq5kCNpGScUUWOmI56k3MWo Message-ID: Subject: Re: Cannot unmount nullfs in current From: hiren panchasara To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 21:36:06 -0000 On Fri, Apr 19, 2013 at 12:07 PM, Craig Rodrigues wrote: > > > > On Fri, Apr 19, 2013 at 11:36 AM, hiren panchasara > wrote: >> >> >> I had tried that without success. I did not get any pointer to where >> the error might be. I may have failed well before starting any >> building. One of the reasons might be that I had git port without svn >> support. Some of the buildscripts magic for git-svn interaction may >> have failed because of that. >> >> I am trying to fix that right now and give this another try. >> > > Yes, you are right. > I found that to the hard way. You need devel/git-subversion > and not devel/git port installed. Somewhere in the build "git svn" is > invoked, > and will fail if you don't have devel/git-subversion installed. I believe that was the problem. Installing devel/git-subversion fixed it for me. I will poke freenas folks to add this instruction on their git page for not-so-smart souls like myself. :-) Thanks, Hiren > > -- > Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 21:56:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0E8A994; Fri, 19 Apr 2013 21:56:13 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEB06123; Fri, 19 Apr 2013 21:56:12 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z13so4169227lbh.27 for ; Fri, 19 Apr 2013 14:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fqcYLopqkmnDLDnVhg/eC3HOLhfoUTE0/g94NwsqMnc=; b=l70vMlkzHknC6JAf69Q8JrnVJOXqv6mXkeurIelbF+29cLtSRG+2mcPTHnRPQJMbyN zMXfVRBXz+AVXYI+ECIsSySSGzo5IYf+6j+gA04JU093qVv4AUrfyiTpBsAO0C2L28KH suu3+VK8i0P4gTdWtuTtUq51HFIlYfOAlhbU5CY5RqjcGUuiQHbfy0gvZ+1+AkIYqoe5 lCEcnMsH3j7RT3SCmZwnGQoUgPqdmMyquMSK3+iRBN1zCUGc1WW+OI7DPyoO5VWOUaP2 wuCDzV9xEHBqFFsp0CtUMOdVS+UiEFDmIwMXnF41VF0QxPuxMiPFosZYYKuZIwiC8PiB UgrA== MIME-Version: 1.0 X-Received: by 10.112.136.10 with SMTP id pw10mr8842432lbb.61.1366408565923; Fri, 19 Apr 2013 14:56:05 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.146.135 with HTTP; Fri, 19 Apr 2013 14:56:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 14:56:05 -0700 X-Google-Sender-Auth: 1LdovM9C9d6-QMhtqQy5nLwJlZU Message-ID: Subject: Re: Cannot unmount nullfs in current From: Craig Rodrigues To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 21:56:13 -0000 On Fri, Apr 19, 2013 at 2:36 PM, hiren panchasara wrote: > > I believe that was the problem. Installing devel/git-subversion fixed > it for me. I will poke freenas folks to add this instruction on their > git page for not-so-smart souls like myself. :-) > > Thanks, > Hiren > See: https://github.com/freenas/freenas/pull/11 -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 21:57:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9506AD4; Fri, 19 Apr 2013 21:57:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDBD140; Fri, 19 Apr 2013 21:57:13 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so1499159wiv.14 for ; Fri, 19 Apr 2013 14:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=43ku+9B+KSrdof2w8sNOc+6RWDlHjmcFZRjd7R8ycIc=; b=ZxUnygLUJTVPtCPcPVH8PvS6EBi7DJ/0DJ+VzGu0xp22u8/ZFGLT5z55wR9lJ4fBus jyGgiR7gPnnOJzDh516M+Am+/LGpIe8//jDX0EhLTIS/YQw0a2Z/c+wnPKuGWF+PT3sR 9xS7nYjdI99YW8kwDahLyi4s+Kd23JUv25ETJZLCte+P0MkrvGX35HXTRhOR3Zf7RIrI O6iXJ1PgyF8oILELOtqPi6O1rOoPRNPSb04LafgYtQpnAjR4KBovWdMkJDAEM6GQg7HM gwbNgyojV2pQj3NVdR3a66ZbtasqeFsygHSrwzBoipMLCkY/yzFTzqwxnlt27exquRnC vmoA== MIME-Version: 1.0 X-Received: by 10.194.142.236 with SMTP id rz12mr29483023wjb.12.1366408632440; Fri, 19 Apr 2013 14:57:12 -0700 (PDT) Received: by 10.217.88.129 with HTTP; Fri, 19 Apr 2013 14:57:12 -0700 (PDT) In-Reply-To: References: <1825476.qO1YuZaJ09@home.alkar.net> <2381713.gpuUDy5DnR@home.alkar.net> <2717891.HdW8GIoFa8@home.alkar.net> Date: Fri, 19 Apr 2013 14:57:12 -0700 Message-ID: Subject: Re: Atheros 9287 - no carrier . revision 249623. From: Adrian Chadd To: Artyom Mirgorodskiy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 21:57:14 -0000 Hi! Ok, please update to -HEAD and retest! adrian On 19 April 2013 06:26, Adrian Chadd wrote: > oooooo good to know! let me setup the chainmask info whether or not > the 11n option is set. > > thanks! > > > adrian > > On 19 April 2013 04:08, Artyom Mirgorodskiy > wrote: >> Adrian, I found the problem. >> >> I'm use ath as module, so ATH_ENABLE_11N is not defined. When I define >> ATH_ENABLE_11N - everything work. >> >> >> >> >> >> Artyom Mirgorodskiy >> >> >> >> On Friday 19 April 2013 13:27:21 wrote: >> >> Updated. However I did not see chainmask information. >> >> See attached >> >> >> >> On Friday 19 April 2013 00:57:12 Adrian Chadd wrote: >> >>> Hi, >> >>> >> >>> I've just committed some changes to -HEAD. Please update to the latest >> >>> -HEAD and paste me the ath0 dmesg output. >> >>> It will include the chainmask information. >> >>> >> >>> Thanks, >> >>> >> >>> >> >>> Adrian >> >> -- >> >> Artyom Mirgorodskiy >> >> >> -- >> >> Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Fri Apr 19 22:09:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E267E67; Fri, 19 Apr 2013 22:09:17 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id A46BB1AF; Fri, 19 Apr 2013 22:09:16 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id l13so1719185wie.1 for ; Fri, 19 Apr 2013 15:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uaIf6/kPz05fqPuI61erAH8juZUGEwagcLenVYYZA+g=; b=ehcPD1IdKeI/3pYtBWKZc5A1aiJfezHM4aXoCrvsb3Mpd6MhIcwW1TdIGD2eBO2QKc 96p7imk1zPnXa7OcbSL/sAw26lu0ro25cT//uaOkD5DnBSAxz/DgYtoThviFmtaSYtVB 8YYo4HhZlW8s4hZMmzkYx1EAJgMs2zKlk1E/auTbQEpEWv/codp1OXA63jSI/78Q40Nz Do3wRDOnREMlTLhQNr1JEFkre9esZ8w/EahCXpDH5nXel70Q1GJk84S7y2zAqKWG3o8o Yoe+gW5Hb8ixLymNsconAqnEF623+g8bqzJ726L6SNX3a+sQ3Fpr3ZD9CSQpQt6oq1FM 6XyA== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr29431418wjb.24.1366409355880; Fri, 19 Apr 2013 15:09:15 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.15.91.72 with HTTP; Fri, 19 Apr 2013 15:09:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 15:09:15 -0700 X-Google-Sender-Auth: finM8CWS036CW1l2NdYnuW0226Y Message-ID: Subject: Re: Cannot unmount nullfs in current From: hiren panchasara To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 22:09:17 -0000 On Fri, Apr 19, 2013 at 2:56 PM, Craig Rodrigues wrote: > > > > On Fri, Apr 19, 2013 at 2:36 PM, hiren panchasara wrote: >> >> >> I believe that was the problem. Installing devel/git-subversion fixed >> it for me. I will poke freenas folks to add this instruction on their >> git page for not-so-smart souls like myself. :-) >> >> Thanks, >> Hiren > > > See: > > https://github.com/freenas/freenas/pull/11 Awesome! Thanks, Hiren > > -- > Craig From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 02:47:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92196F91 for ; Sat, 20 Apr 2013 02:47:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id F2E54A30 for ; Sat, 20 Apr 2013 02:47:52 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5730925D3894; Sat, 20 Apr 2013 02:47:51 +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 4B2A1BE846B; Sat, 20 Apr 2013 02:47:50 +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 ypiZesEOc9w4; Sat, 20 Apr 2013 02:47:48 +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 1593DBE8465; Sat, 20 Apr 2013 02:47:47 +0000 (UTC) Date: Sat, 20 Apr 2013 02:47:47 +0000 (UTC) From: "Bjoern A. Zeeb" To: Tijl Coosemans Subject: Re: My incremental buildworlds started failing In-Reply-To: <516D8531.1090006@coosemans.org> Message-ID: References: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> <516D8531.1090006@coosemans.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 02:47:53 -0000 On Tue, 16 Apr 2013, Tijl Coosemans wrote: > On 2013-04-16 18:39, Dimitry Andric wrote: >> On Apr 16, 2013, at 18:08, Bjoern A. Zeeb wrote: >>> I have been seeing this on incremental buildworlds for a day or two now? >>> ANyone can throw the cluebat at me? > > If that means building with NO_CLEAN=yes then the problem is r249484. > It creates a symlink: ln -fs ../include ${DESTDIR}/usr/lib/include > But if ${DESTDIR}/usr/lib/include already exists it creates > ${DESTDIR}/usr/include/include -> ../include. > > I'm thinking of reverting that commit. > >>> ===> rescue/rescue/routed/rtquery (depend) >>> {standard input}: Assembler messages: >>> {standard input}:2: Warning: unterminated string; newline inserted >>> {standard input}:3: Warning: unterminated string; newline inserted >>> ===> kerberos5/usr.bin/kcc (all) >>> In file included from /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.sbin/rtsold/rtsol.c:51: >>> /storage/head/obj//sparc64.sparc64/scratch/tmp/bz/head.svn/tmp/usr/include/netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (not in a function) >>> *** [rtsol.o] Error code 1 >>> 1 error >>> *** [rtsol_make] Error code 2 >>> 1 error >> >> >> Probably http://svnweb.freebsd.org/changeset/base/249543 > > This has been fixed in r249552 now. But if the problem is there once and you never remove your obj directory it's not really gone even with a full (no NOCLEAN) rebuild, right? SO time to kill the obj directory... -- Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 08:52:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 605DC3AD for ; Sat, 20 Apr 2013 08:52:19 +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]) by mx1.freebsd.org (Postfix) with ESMTP id 25BF61360 for ; Sat, 20 Apr 2013 08:52:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1UTTWr-0042ps-Lk>; Sat, 20 Apr 2013 10:52:17 +0200 Received: from g231086065.adsl.alicedsl.de ([92.231.86.65] helo=[192.168.0.128]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1UTTWr-001G93-Ii>; Sat, 20 Apr 2013 10:52:17 +0200 Subject: CURRENT: extremely unresponsive disk I/O From: "O. Hartmann" To: FreeBSD Current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-jpBtBQEDf5w6Q+v10Dqu" Date: Sat, 20 Apr 2013 10:52:17 +0200 Message-ID: <1366447937.1475.35.camel@thor.walstatt.dyndns.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Originating-IP: 92.231.86.65 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 08:52:19 -0000 --=-jpBtBQEDf5w6Q+v10Dqu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since a couple of weeks now, FreeBSD 10.0-CURRENT is really unresponsive when managing high disk I/O. This is most noticeable when starting the buildworld process, hwen clang 3.3 starts to build the llvm backend libraries and doing some sort of portmaster/portupgrade in parallel: even a "make rmconfig config" takes aprox. a minute to show up. Is there a known issue at this moment? I can not see such a behaviour on FreeBSD 9.1-STABLE (similar hardware). Oliver --=-jpBtBQEDf5w6Q+v10Dqu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJRcldBAAoJEOgBcD7A/5N8zrAIAKSqxbatqLLyiwp/258qD0hi DVfp9P4V5Kz/BmzY+2JDdn4V8pVI9IfyMDxXH0YM9XCYGF8Uir+10O7J4O1mLKCX log7nb6lpM4d3ZqinQ9JTAQ15Ud3iGX5Lk+11xFBU7KOD5Tio+ax4pa8tkQlouCQ /hYw4o+oFWESd0K1ZW18zQTv3ZdF3lMdheWgq8keylHjeqm2b4ycTA+u9gyIMPdx afUIaym35fq/eisni5axhqLrpVAayNTviQmg4KwkS5XZdQGQXq4JxCGJdKs3ngUh RSeT9eYz2on+L1erQ1SS6epL8pIFAcLejzGbDLRlJ8g0AJveY75zUOgBP8PLHUw= =JI6o -----END PGP SIGNATURE----- --=-jpBtBQEDf5w6Q+v10Dqu-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 09:47:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02629B42 for ; Sat, 20 Apr 2013 09:47:14 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA6A1504 for ; Sat, 20 Apr 2013 09:47:14 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwGALNjclFR8npE/2dsb2JhbABQgwY2wQWBARd0gh8BAQUnLyIBEAsYCRYPCQMCAQIBJx4GDQEHAQGIFAi8eI15gSwHg0cDj16BKYctj3GDDjqBLw Received: from 68.122-242-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.242.122.68]) by relay.skynet.be with ESMTP; 20 Apr 2013 11:46:56 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.6/8.14.6) with ESMTP id r3K9ktrR000985; Sat, 20 Apr 2013 11:46:56 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <5172640A.5020801@coosemans.org> Date: Sat, 20 Apr 2013 11:46:50 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130408 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: My incremental buildworlds started failing References: <90666BA3-A148-426E-83BC-D85A918C2B45@FreeBSD.org> <516D8531.1090006@coosemans.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2RPWUVPJLQAARFLUTPLIU" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 09:47:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RPWUVPJLQAARFLUTPLIU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-04-20 04:47, Bjoern A. Zeeb wrote: > On Tue, 16 Apr 2013, Tijl Coosemans wrote: >=20 >> On 2013-04-16 18:39, Dimitry Andric wrote: >>> On Apr 16, 2013, at 18:08, Bjoern A. Zeeb wrote: >>>> I have been seeing this on incremental buildworlds for a day or two = now? >>>> ANyone can throw the cluebat at me? >> >> If that means building with NO_CLEAN=3Dyes then the problem is r249484= =2E >> It creates a symlink: ln -fs ../include ${DESTDIR}/usr/lib/include >> But if ${DESTDIR}/usr/lib/include already exists it creates >> ${DESTDIR}/usr/include/include -> ../include. >> >> I'm thinking of reverting that commit. >> >>>> =3D=3D=3D> rescue/rescue/routed/rtquery (depend) >>>> {standard input}: Assembler messages: >>>> {standard input}:2: Warning: unterminated string; newline inserted >>>> {standard input}:3: Warning: unterminated string; newline inserted >>>> =3D=3D=3D> kerberos5/usr.bin/kcc (all) >>>> In file included from /scratch/tmp/bz/head.svn/sbin/rtsol/../../usr.= sbin/rtsold/rtsol.c:51: >>>> /storage/head/obj//sparc64.sparc64/scratch/tmp/bz/head.svn/tmp/usr/i= nclude/netinet6/ip6_var.h:245: error: 'IP6S_MAXRULES' undeclared here (no= t in a function) >>>> *** [rtsol.o] Error code 1 >>>> 1 error >>>> *** [rtsol_make] Error code 2 >>>> 1 error >>> >>> >>> Probably http://svnweb.freebsd.org/changeset/base/249543 >> >> This has been fixed in r249552 now. >=20 >=20 > But if the problem is there once and you never remove your obj > directory it's not really gone even with a full (no NOCLEAN) rebuild, > right? SO time to kill the obj directory... You should be ok if you delete tmp/usr/include/include in obj directory. ------enig2RPWUVPJLQAARFLUTPLIU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iF4EAREIAAYFAlFyZA8ACgkQfoCS2CCgtisQjwD/X9xtL1Vu+toVmIepYP9Kwe8B ht1CE6ET8u8tq7+9yWsA/3kyPkoGIogSNaiIBBxfBEHtCS27aorzKJg6b7VDWcU4 =QY2D -----END PGP SIGNATURE----- ------enig2RPWUVPJLQAARFLUTPLIU-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 09:55:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94D4AE84; Sat, 20 Apr 2013 09:55:28 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 0CFC41563; Sat, 20 Apr 2013 09:55:27 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id c10so1962176wiw.6 for ; Sat, 20 Apr 2013 02:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=c21KDMvgMopz2Lnv5Z8ImTr/Q3dk7PEu/hrlHfFObbg=; b=Snt5WevnCvbqPhiDM7JKk+CcOd74h/Rc0bnDraJM6lO1wfskRdz+p/hRx74LSkMEOH 3r5NKYSTqBtW2wfOhfyQz3fQA7gsgLRY/RRgFa3/yW/StgGMHeBaS2YiJzqDtq7K5sid yfezw98Z2zFFZhJHfln3w8W/ZNZNnLjW8lU3nyBK9NGGGUFSlMYEX7LSdKrLO/8pcAyD xs0mBC0kOPnbHy0xIzCl9D8ISM5+hR1V3T5zqWQHMupD59YfW8Ed08n1i3nMYfGfUSVe GxiUB3/ZQDadG///dRq13cJ8V18gsAehdi1f1NLFiLayBkHgwZNrlTuDC7tj9E7sXo22 79sQ== MIME-Version: 1.0 X-Received: by 10.194.103.72 with SMTP id fu8mr33296880wjb.42.1366451727082; Sat, 20 Apr 2013 02:55:27 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sat, 20 Apr 2013 02:55:26 -0700 (PDT) Date: Sat, 20 Apr 2013 12:55:26 +0300 Message-ID: Subject: WORLDTMP on a ram disk From: Kimmo Paasiala To: freebsd-hackers@freebsd.org, FreeBSD current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 09:55:28 -0000 Poking around the /usr/src/Makefile.inc1 I see that there's a variable called "WORLDTMP" that seems to set the location for temporary files during the world build. My question is now: Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)? Looking at the build process it seems to me that the temporary files are no longer needed after make buildworld has finished? -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 10:28:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86EA146C; Sat, 20 Apr 2013 10:28:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 515A31656; Sat, 20 Apr 2013 10:28:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KASNVV018530; Sat, 20 Apr 2013 06:28:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KASM3t018519; Sat, 20 Apr 2013 10:28:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 10:28:22 GMT Message-Id: <201304201028.r3KASM3t018519@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:28:24 -0000 TB --- 2013-04-20 08:49:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 08:49:25 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 08:49:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-04-20 08:49:25 - cleaning the object tree TB --- 2013-04-20 08:49:25 - /usr/local/bin/svn stat /src TB --- 2013-04-20 08:49:45 - At svn revision 249665 TB --- 2013-04-20 08:49:46 - building world TB --- 2013-04-20 08:49:46 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 08:49:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 08:49:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 08:49:46 - SRCCONF=/dev/null TB --- 2013-04-20 08:49:46 - TARGET=ia64 TB --- 2013-04-20 08:49:46 - TARGET_ARCH=ia64 TB --- 2013-04-20 08:49:46 - TZ=UTC TB --- 2013-04-20 08:49:46 - __MAKE_CONF=/dev/null TB --- 2013-04-20 08:49:46 - cd /src TB --- 2013-04-20 08:49:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 08:49:51 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 10:25:13 UTC 2013 TB --- 2013-04-20 10:25:13 - generating LINT kernel config TB --- 2013-04-20 10:25:13 - cd /src/sys/ia64/conf TB --- 2013-04-20 10:25:13 - /usr/bin/make -B LINT TB --- 2013-04-20 10:25:13 - cd /src/sys/ia64/conf TB --- 2013-04-20 10:25:13 - /usr/sbin/config -m LINT TB --- 2013-04-20 10:25:13 - building LINT kernel TB --- 2013-04-20 10:25:13 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 10:25:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 10:25:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 10:25:13 - SRCCONF=/dev/null TB --- 2013-04-20 10:25:13 - TARGET=ia64 TB --- 2013-04-20 10:25:13 - TARGET_ARCH=ia64 TB --- 2013-04-20 10:25:13 - TZ=UTC TB --- 2013-04-20 10:25:13 - __MAKE_CONF=/dev/null TB --- 2013-04-20 10:25:13 - cd /src TB --- 2013-04-20 10:25:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 10:25:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 10:28:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 10:28:22 - ERROR: failed to build LINT kernel TB --- 2013-04-20 10:28:22 - 4607.78 user 776.19 system 5937.56 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 11:08:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3AB07F3; Sat, 20 Apr 2013 11:08:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF45E1747; Sat, 20 Apr 2013 11:08:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KB8oR8072315; Sat, 20 Apr 2013 07:08:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KB8oTt072310; Sat, 20 Apr 2013 11:08:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 11:08:50 GMT Message-Id: <201304201108.r3KB8oTt072310@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 11:08:51 -0000 TB --- 2013-04-20 07:24:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 07:24:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 07:24:30 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-20 07:24:30 - cleaning the object tree TB --- 2013-04-20 07:24:47 - /usr/local/bin/svn stat /src TB --- 2013-04-20 07:25:14 - At svn revision 249665 TB --- 2013-04-20 07:25:15 - building world TB --- 2013-04-20 07:25:15 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 07:25:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 07:25:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 07:25:15 - SRCCONF=/dev/null TB --- 2013-04-20 07:25:15 - TARGET=pc98 TB --- 2013-04-20 07:25:15 - TARGET_ARCH=i386 TB --- 2013-04-20 07:25:15 - TZ=UTC TB --- 2013-04-20 07:25:15 - __MAKE_CONF=/dev/null TB --- 2013-04-20 07:25:15 - cd /src TB --- 2013-04-20 07:25:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 07:25:20 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 10:44:10 UTC 2013 TB --- 2013-04-20 10:44:10 - generating LINT kernel config TB --- 2013-04-20 10:44:10 - cd /src/sys/pc98/conf TB --- 2013-04-20 10:44:10 - /usr/bin/make -B LINT TB --- 2013-04-20 10:44:10 - cd /src/sys/pc98/conf TB --- 2013-04-20 10:44:10 - /usr/sbin/config -m LINT TB --- 2013-04-20 10:44:10 - building LINT kernel TB --- 2013-04-20 10:44:10 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 10:44:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 10:44:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 10:44:10 - SRCCONF=/dev/null TB --- 2013-04-20 10:44:10 - TARGET=pc98 TB --- 2013-04-20 10:44:10 - TARGET_ARCH=i386 TB --- 2013-04-20 10:44:10 - TZ=UTC TB --- 2013-04-20 10:44:10 - __MAKE_CONF=/dev/null TB --- 2013-04-20 10:44:10 - cd /src TB --- 2013-04-20 10:44:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 10:44:10 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 11:08:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 11:08:50 - ERROR: failed to build LINT kernel TB --- 2013-04-20 11:08:50 - 10620.86 user 1557.84 system 13459.55 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 11:38:06 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CB2A02A6; Sat, 20 Apr 2013 11:38:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 93E9A1814; Sat, 20 Apr 2013 11:38:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KBc5Jc000692; Sat, 20 Apr 2013 07:38:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KBc5qZ000691; Sat, 20 Apr 2013 11:38:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 11:38:05 GMT Message-Id: <201304201138.r3KBc5qZ000691@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 11:38:06 -0000 TB --- 2013-04-20 10:28:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 10:28:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 10:28:23 - starting HEAD tinderbox run for mips/mips TB --- 2013-04-20 10:28:23 - cleaning the object tree TB --- 2013-04-20 10:28:23 - /usr/local/bin/svn stat /src TB --- 2013-04-20 10:28:40 - At svn revision 249665 TB --- 2013-04-20 10:28:41 - building world TB --- 2013-04-20 10:28:41 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 10:28:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 10:28:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 10:28:41 - SRCCONF=/dev/null TB --- 2013-04-20 10:28:41 - TARGET=mips TB --- 2013-04-20 10:28:41 - TARGET_ARCH=mips TB --- 2013-04-20 10:28:41 - TZ=UTC TB --- 2013-04-20 10:28:41 - __MAKE_CONF=/dev/null TB --- 2013-04-20 10:28:41 - cd /src TB --- 2013-04-20 10:28:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 10:28:45 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 11:31:39 UTC 2013 TB --- 2013-04-20 11:31:39 - cd /src/sys/mips/conf TB --- 2013-04-20 11:31:39 - /usr/sbin/config -m ADM5120 TB --- 2013-04-20 11:31:39 - skipping ADM5120 kernel TB --- 2013-04-20 11:31:39 - cd /src/sys/mips/conf TB --- 2013-04-20 11:31:39 - /usr/sbin/config -m ALCHEMY TB --- 2013-04-20 11:31:39 - skipping ALCHEMY kernel TB --- 2013-04-20 11:31:39 - cd /src/sys/mips/conf TB --- 2013-04-20 11:31:39 - /usr/sbin/config -m AP121 TB --- 2013-04-20 11:31:39 - building AP121 kernel TB --- 2013-04-20 11:31:39 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:31:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:31:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:31:39 - SRCCONF=/dev/null TB --- 2013-04-20 11:31:39 - TARGET=mips TB --- 2013-04-20 11:31:39 - TARGET_ARCH=mips TB --- 2013-04-20 11:31:39 - TZ=UTC TB --- 2013-04-20 11:31:39 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:31:39 - cd /src TB --- 2013-04-20 11:31:39 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Sat Apr 20 11:31:39 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP121 completed on Sat Apr 20 11:34:12 UTC 2013 TB --- 2013-04-20 11:34:12 - cd /src/sys/mips/conf TB --- 2013-04-20 11:34:12 - /usr/sbin/config -m AP91 TB --- 2013-04-20 11:34:12 - building AP91 kernel TB --- 2013-04-20 11:34:12 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:34:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:34:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:34:12 - SRCCONF=/dev/null TB --- 2013-04-20 11:34:12 - TARGET=mips TB --- 2013-04-20 11:34:12 - TARGET_ARCH=mips TB --- 2013-04-20 11:34:12 - TZ=UTC TB --- 2013-04-20 11:34:12 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:34:12 - cd /src TB --- 2013-04-20 11:34:12 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Sat Apr 20 11:34:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_sim.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_xpt.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_all.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_cd.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/modules/cam/../../cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/modules/cam/../../cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /src/sys/modules/cam. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 11:38:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 11:38:05 - ERROR: failed to build AP91 kernel TB --- 2013-04-20 11:38:05 - 2979.31 user 644.79 system 4182.27 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 12:11:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AA4935B; Sat, 20 Apr 2013 12:11:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC671AB0; Sat, 20 Apr 2013 12:11:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KCBVTd045441; Sat, 20 Apr 2013 08:11:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KCBVfb045430; Sat, 20 Apr 2013 12:11:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 12:11:31 GMT Message-Id: <201304201211.r3KCBVfb045430@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:11:35 -0000 TB --- 2013-04-20 10:58:57 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 10:58:57 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 10:58:57 - starting HEAD tinderbox run for mips64/mips TB --- 2013-04-20 10:58:57 - cleaning the object tree TB --- 2013-04-20 10:58:57 - /usr/local/bin/svn stat /src TB --- 2013-04-20 10:59:00 - At svn revision 249665 TB --- 2013-04-20 10:59:01 - building world TB --- 2013-04-20 10:59:01 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 10:59:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 10:59:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 10:59:01 - SRCCONF=/dev/null TB --- 2013-04-20 10:59:01 - TARGET=mips TB --- 2013-04-20 10:59:01 - TARGET_ARCH=mips64 TB --- 2013-04-20 10:59:01 - TZ=UTC TB --- 2013-04-20 10:59:01 - __MAKE_CONF=/dev/null TB --- 2013-04-20 10:59:01 - cd /src TB --- 2013-04-20 10:59:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 10:59:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 11:59:24 UTC 2013 TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m ADM5120 TB --- 2013-04-20 11:59:24 - skipping ADM5120 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m ALCHEMY TB --- 2013-04-20 11:59:24 - skipping ALCHEMY kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AP121 TB --- 2013-04-20 11:59:24 - skipping AP121 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AP91 TB --- 2013-04-20 11:59:24 - skipping AP91 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AP93 TB --- 2013-04-20 11:59:24 - skipping AP93 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AP94 TB --- 2013-04-20 11:59:24 - skipping AP94 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AP96 TB --- 2013-04-20 11:59:24 - skipping AP96 kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-04-20 11:59:24 - skipping AR71XX_BASE kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AR724X_BASE TB --- 2013-04-20 11:59:24 - skipping AR724X_BASE kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-04-20 11:59:24 - skipping AR91XX_BASE kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m AR933X_BASE TB --- 2013-04-20 11:59:24 - skipping AR933X_BASE kernel TB --- 2013-04-20 11:59:24 - cd /src/sys/mips/conf TB --- 2013-04-20 11:59:24 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-04-20 11:59:24 - building BERI_DE4_MDROOT kernel TB --- 2013-04-20 11:59:24 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:59:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:59:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:59:24 - SRCCONF=/dev/null TB --- 2013-04-20 11:59:24 - TARGET=mips TB --- 2013-04-20 11:59:24 - TARGET_ARCH=mips64 TB --- 2013-04-20 11:59:24 - TZ=UTC TB --- 2013-04-20 11:59:24 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:59:24 - cd /src TB --- 2013-04-20 11:59:24 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Apr 20 11:59:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Sat Apr 20 12:01:47 UTC 2013 TB --- 2013-04-20 12:01:47 - cd /src/sys/mips/conf TB --- 2013-04-20 12:01:47 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-04-20 12:01:47 - building BERI_DE4_SDROOT kernel TB --- 2013-04-20 12:01:47 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:01:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:01:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:01:47 - SRCCONF=/dev/null TB --- 2013-04-20 12:01:47 - TARGET=mips TB --- 2013-04-20 12:01:47 - TARGET_ARCH=mips64 TB --- 2013-04-20 12:01:47 - TZ=UTC TB --- 2013-04-20 12:01:47 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:01:47 - cd /src TB --- 2013-04-20 12:01:47 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Sat Apr 20 12:01:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Sat Apr 20 12:04:08 UTC 2013 TB --- 2013-04-20 12:04:08 - cd /src/sys/mips/conf TB --- 2013-04-20 12:04:08 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-04-20 12:04:08 - building BERI_SIM_MDROOT kernel TB --- 2013-04-20 12:04:08 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:04:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:04:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:04:08 - SRCCONF=/dev/null TB --- 2013-04-20 12:04:08 - TARGET=mips TB --- 2013-04-20 12:04:08 - TARGET_ARCH=mips64 TB --- 2013-04-20 12:04:08 - TZ=UTC TB --- 2013-04-20 12:04:08 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:04:08 - cd /src TB --- 2013-04-20 12:04:08 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Sat Apr 20 12:04:08 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Sat Apr 20 12:06:24 UTC 2013 TB --- 2013-04-20 12:06:24 - cd /src/sys/mips/conf TB --- 2013-04-20 12:06:24 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-04-20 12:06:24 - building BERI_TEMPLATE kernel TB --- 2013-04-20 12:06:24 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:06:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:06:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:06:24 - SRCCONF=/dev/null TB --- 2013-04-20 12:06:24 - TARGET=mips TB --- 2013-04-20 12:06:24 - TARGET_ARCH=mips64 TB --- 2013-04-20 12:06:24 - TZ=UTC TB --- 2013-04-20 12:06:24 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:06:24 - cd /src TB --- 2013-04-20 12:06:24 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Sat Apr 20 12:06:24 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Sat Apr 20 12:08:36 UTC 2013 TB --- 2013-04-20 12:08:36 - cd /src/sys/mips/conf TB --- 2013-04-20 12:08:36 - /usr/sbin/config -m DIR-825 TB --- 2013-04-20 12:08:36 - skipping DIR-825 kernel TB --- 2013-04-20 12:08:36 - cd /src/sys/mips/conf TB --- 2013-04-20 12:08:36 - /usr/sbin/config -m GXEMUL TB --- 2013-04-20 12:08:36 - building GXEMUL kernel TB --- 2013-04-20 12:08:36 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:08:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:08:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:08:36 - SRCCONF=/dev/null TB --- 2013-04-20 12:08:36 - TARGET=mips TB --- 2013-04-20 12:08:36 - TARGET_ARCH=mips64 TB --- 2013-04-20 12:08:36 - TZ=UTC TB --- 2013-04-20 12:08:36 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:08:36 - cd /src TB --- 2013-04-20 12:08:36 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Sat Apr 20 12:08:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Sat Apr 20 12:10:33 UTC 2013 TB --- 2013-04-20 12:10:33 - cd /src/sys/mips/conf TB --- 2013-04-20 12:10:33 - /usr/sbin/config -m IDT TB --- 2013-04-20 12:10:33 - skipping IDT kernel TB --- 2013-04-20 12:10:33 - cd /src/sys/mips/conf TB --- 2013-04-20 12:10:33 - /usr/sbin/config -m MALTA TB --- 2013-04-20 12:10:33 - skipping MALTA kernel TB --- 2013-04-20 12:10:33 - cd /src/sys/mips/conf TB --- 2013-04-20 12:10:33 - /usr/sbin/config -m MALTA64 TB --- 2013-04-20 12:10:33 - skipping MALTA64 kernel TB --- 2013-04-20 12:10:33 - cd /src/sys/mips/conf TB --- 2013-04-20 12:10:33 - /usr/sbin/config -m OCTEON1 TB --- 2013-04-20 12:10:33 - building OCTEON1 kernel TB --- 2013-04-20 12:10:33 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:10:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:10:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:10:33 - SRCCONF=/dev/null TB --- 2013-04-20 12:10:33 - TARGET=mips TB --- 2013-04-20 12:10:33 - TARGET_ARCH=mips64 TB --- 2013-04-20 12:10:33 - TZ=UTC TB --- 2013-04-20 12:10:33 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:10:33 - cd /src TB --- 2013-04-20 12:10:33 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Sat Apr 20 12:10:34 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/mips.mips64/src/sys/OCTEON1. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 12:11:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 12:11:31 - ERROR: failed to build OCTEON1 kernel TB --- 2013-04-20 12:11:31 - 3297.00 user 652.12 system 4353.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 12:16:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8AFE4A3; Sat, 20 Apr 2013 12:16:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 7120D1ADE; Sat, 20 Apr 2013 12:16:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::15fb:7073:6a12:b988] (unknown [IPv6:2001:7b8:3a7:0:15fb:7073:6a12:b988]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 438B75C44; Sat, 20 Apr 2013 14:16:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: WORLDTMP on a ram disk From: Dimitry Andric In-Reply-To: Date: Sat, 20 Apr 2013 14:16:45 +0200 Content-Transfer-Encoding: 7bit Message-Id: <60A8F6C1-2A06-4646-9A28-83608FF23443@FreeBSD.org> References: To: Kimmo Paasiala X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@freebsd.org, FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 12:16:39 -0000 On Apr 20, 2013, at 11:55, Kimmo Paasiala wrote: > Poking around the /usr/src/Makefile.inc1 I see that there's a variable > called "WORLDTMP" that seems to set the location for temporary files > during the world build. My question is now: > > Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)? > > Looking at the build process it seems to me that the temporary files > are no longer needed after make buildworld has finished? The problem is that you need those temporary files for installworld, and you must reboot with your new kernel before running that... From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 12:30:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE5E37FC; Sat, 20 Apr 2013 12:30:27 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id F216B1B7A; Sat, 20 Apr 2013 12:30:26 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id c10so2093165wiw.0 for ; Sat, 20 Apr 2013 05:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WetEaqd0L2smFm4B0R6yqhJWyrGjd/RwWz/3ruCDZMo=; b=o3VczXVIFbpuK88HVI9X0J1AFo+F+KhgHQFAxegzqMhbO6Ur6dvhwY33Hys6SI7qHS TmyaSx5chOogxiYVlyPhk2GRWahWUbPOLoSfoaIK0QchSkm+X7p7aHGzi3AS4y8hPE/q zZLEfVM7/Sxp/SEw4aC83gAdJNTGM3/jKtcsPNUwWjOWayOFYjrMTLHFxPP/BErbQPSL b+zWqPNhq9PhaWN9Cu17+FzkVdq4sGx9HIjDJ/314ROiH7KiJ6WXlnOHXicAj08WcJEo n0t5MXAEOklIiakC9kqZAnT4AcJkEaTpKoCFCHlTz5xWl51jOzrtYuqYykg4dPgFP/RB fa2w== MIME-Version: 1.0 X-Received: by 10.194.157.138 with SMTP id wm10mr34326957wjb.28.1366461026164; Sat, 20 Apr 2013 05:30:26 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sat, 20 Apr 2013 05:30:26 -0700 (PDT) In-Reply-To: <60A8F6C1-2A06-4646-9A28-83608FF23443@FreeBSD.org> References: <60A8F6C1-2A06-4646-9A28-83608FF23443@FreeBSD.org> Date: Sat, 20 Apr 2013 15:30:26 +0300 Message-ID: Subject: Re: WORLDTMP on a ram disk From: Kimmo Paasiala To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, FreeBSD current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 12:30:27 -0000 On Sat, Apr 20, 2013 at 3:16 PM, Dimitry Andric wrote: > On Apr 20, 2013, at 11:55, Kimmo Paasiala wrote: >> Poking around the /usr/src/Makefile.inc1 I see that there's a variable >> called "WORLDTMP" that seems to set the location for temporary files >> during the world build. My question is now: >> >> Is it safe to put WORLDTMP on a ram disk, for example tmpfs(5)? >> >> Looking at the build process it seems to me that the temporary files >> are no longer needed after make buildworld has finished? > > > The problem is that you need those temporary files for installworld, and > you must reboot with your new kernel before running that... > Well that was what I was after, I was somehow under the impression that the files in WORLDTMP would be moved to more permanent location under /usr/obj for installworld to find them. -Kimmo From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 12:42:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31745D83; Sat, 20 Apr 2013 12:42:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4D31BF6; Sat, 20 Apr 2013 12:42:29 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r3KCTkCP035122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Apr 2013 14:29:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r3KCTih5097139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r3KCTiR6004541; Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r3KCTiJi004540; Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso) Date: Sat, 20 Apr 2013 14:29:44 +0200 From: Bernd Walter To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130420122944.GD3401@cicely7.cicely.de> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CAA04.1050108@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Jeremy Chadwick , Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:42:31 -0000 On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote: > I have just sent more information to the PR at > http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 > > The short summary (more info in the PR) is: > > - limiting tags to 31 does not help > > - disabling NCQ appears to help in initial testing, but warrants more > testing > > - error happens during WRITE_FPDMA_QUEUED, > > - File system in question is SU+J UFS2 mounted on /usr, and I can for > instance "rm -rf /usr/obj" or just log into GNOME and try to open a > gnome-terminal to trigger stalls; > > - Linux uses 31 tags (for different reason) and has no drive quirks, but > a controller quirk; > > for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it > might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag > - it gets set by Linux on the SB700 that my computer is using, see > ahci_error_intr() in libahci.h - I am not going to interpret that for > lack of expertise, but it does affect error handling and appears to > ignore a certain condition. > > Why only my Samsung HDD drive triggers this but not the WD drive, I do > not know yet. I have had data corruption with Samsung drive and CAM connected to an onboard intel AHCI. The system was known good running with an older FreeBSD version and was brought back into service for another use case with a fresh installation. Regulary on major filesystem write activity we got random FS corruptions and panics. My assumption was broen NCQ firmware on the drive, but have nothing to proof this assumtion. We switched to old ata driver and lived with this until we replaced the whole machine. Don't know if the machine still exists somewhere. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 12:44:54 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2226FC5; Sat, 20 Apr 2013 12:44:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AAA931C38; Sat, 20 Apr 2013 12:44:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KCirTq021360; Sat, 20 Apr 2013 08:44:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KCirE9021359; Sat, 20 Apr 2013 12:44:53 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 12:44:53 GMT Message-Id: <201304201244.r3KCirE9021359@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:44:55 -0000 TB --- 2013-04-20 11:38:05 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 11:38:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 11:38:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-04-20 11:38:05 - cleaning the object tree TB --- 2013-04-20 11:38:05 - /usr/local/bin/svn stat /src TB --- 2013-04-20 11:38:10 - At svn revision 249665 TB --- 2013-04-20 11:38:11 - building world TB --- 2013-04-20 11:38:11 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:38:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:38:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:38:11 - SRCCONF=/dev/null TB --- 2013-04-20 11:38:11 - TARGET=sparc64 TB --- 2013-04-20 11:38:11 - TARGET_ARCH=sparc64 TB --- 2013-04-20 11:38:11 - TZ=UTC TB --- 2013-04-20 11:38:11 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:38:11 - cd /src TB --- 2013-04-20 11:38:11 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 11:38:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 12:42:21 UTC 2013 TB --- 2013-04-20 12:42:21 - generating LINT kernel config TB --- 2013-04-20 12:42:21 - cd /src/sys/sparc64/conf TB --- 2013-04-20 12:42:21 - /usr/bin/make -B LINT TB --- 2013-04-20 12:42:21 - cd /src/sys/sparc64/conf TB --- 2013-04-20 12:42:21 - /usr/sbin/config -m LINT TB --- 2013-04-20 12:42:21 - building LINT kernel TB --- 2013-04-20 12:42:21 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 12:42:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 12:42:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 12:42:21 - SRCCONF=/dev/null TB --- 2013-04-20 12:42:21 - TARGET=sparc64 TB --- 2013-04-20 12:42:21 - TARGET_ARCH=sparc64 TB --- 2013-04-20 12:42:21 - TZ=UTC TB --- 2013-04-20 12:42:21 - __MAKE_CONF=/dev/null TB --- 2013-04-20 12:42:21 - cd /src TB --- 2013-04-20 12:42:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 12:42:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 12:44:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 12:44:53 - ERROR: failed to build LINT kernel TB --- 2013-04-20 12:44:53 - 3229.00 user 551.60 system 4007.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 13:40:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02766565; Sat, 20 Apr 2013 13:40:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2772B1DB1; Sat, 20 Apr 2013 13:40:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KDeYkd058790; Sat, 20 Apr 2013 09:40:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KDeXAp058789; Sat, 20 Apr 2013 13:40:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 13:40:33 GMT Message-Id: <201304201340.r3KDeXAp058789@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 13:40:42 -0000 TB --- 2013-04-20 11:06:54 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 11:06:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 11:06:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-04-20 11:06:54 - cleaning the object tree TB --- 2013-04-20 11:06:54 - /usr/local/bin/svn stat /src TB --- 2013-04-20 11:06:57 - At svn revision 249665 TB --- 2013-04-20 11:06:58 - building world TB --- 2013-04-20 11:06:58 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:06:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:06:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:06:58 - SRCCONF=/dev/null TB --- 2013-04-20 11:06:58 - TARGET=powerpc TB --- 2013-04-20 11:06:58 - TARGET_ARCH=powerpc TB --- 2013-04-20 11:06:58 - TZ=UTC TB --- 2013-04-20 11:06:58 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:06:58 - cd /src TB --- 2013-04-20 11:06:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 11:07:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 13:38:14 UTC 2013 TB --- 2013-04-20 13:38:14 - generating LINT kernel config TB --- 2013-04-20 13:38:14 - cd /src/sys/powerpc/conf TB --- 2013-04-20 13:38:14 - /usr/bin/make -B LINT TB --- 2013-04-20 13:38:14 - cd /src/sys/powerpc/conf TB --- 2013-04-20 13:38:14 - /usr/sbin/config -m LINT TB --- 2013-04-20 13:38:14 - building LINT kernel TB --- 2013-04-20 13:38:14 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 13:38:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 13:38:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 13:38:14 - SRCCONF=/dev/null TB --- 2013-04-20 13:38:14 - TARGET=powerpc TB --- 2013-04-20 13:38:14 - TARGET_ARCH=powerpc TB --- 2013-04-20 13:38:14 - TZ=UTC TB --- 2013-04-20 13:38:14 - __MAKE_CONF=/dev/null TB --- 2013-04-20 13:38:14 - cd /src TB --- 2013-04-20 13:38:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 13:38:14 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 13:40:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 13:40:33 - ERROR: failed to build LINT kernel TB --- 2013-04-20 13:40:33 - 8028.38 user 950.31 system 9219.48 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 14:17:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62DE359C; Sat, 20 Apr 2013 14:17:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 146E61EF3; Sat, 20 Apr 2013 14:17:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KEHQJG037431; Sat, 20 Apr 2013 10:17:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KEHQ2A037430; Sat, 20 Apr 2013 14:17:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 14:17:26 GMT Message-Id: <201304201417.r3KEHQ2A037430@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 14:17:32 -0000 TB --- 2013-04-20 11:08:50 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 11:08:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 11:08:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-04-20 11:08:50 - cleaning the object tree TB --- 2013-04-20 11:08:50 - /usr/local/bin/svn stat /src TB --- 2013-04-20 11:08:53 - At svn revision 249665 TB --- 2013-04-20 11:08:54 - building world TB --- 2013-04-20 11:08:54 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 11:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 11:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 11:08:54 - SRCCONF=/dev/null TB --- 2013-04-20 11:08:54 - TARGET=powerpc TB --- 2013-04-20 11:08:54 - TARGET_ARCH=powerpc64 TB --- 2013-04-20 11:08:54 - TZ=UTC TB --- 2013-04-20 11:08:54 - __MAKE_CONF=/dev/null TB --- 2013-04-20 11:08:54 - cd /src TB --- 2013-04-20 11:08:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 11:08:58 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Apr 20 14:09:38 UTC 2013 TB --- 2013-04-20 14:09:38 - generating LINT kernel config TB --- 2013-04-20 14:09:38 - cd /src/sys/powerpc/conf TB --- 2013-04-20 14:09:38 - /usr/bin/make -B LINT TB --- 2013-04-20 14:09:38 - cd /src/sys/powerpc/conf TB --- 2013-04-20 14:09:38 - /usr/sbin/config -m LINT TB --- 2013-04-20 14:09:38 - skipping LINT kernel TB --- 2013-04-20 14:09:38 - cd /src/sys/powerpc/conf TB --- 2013-04-20 14:09:38 - /usr/sbin/config -m GENERIC TB --- 2013-04-20 14:09:38 - skipping GENERIC kernel TB --- 2013-04-20 14:09:38 - cd /src/sys/powerpc/conf TB --- 2013-04-20 14:09:38 - /usr/sbin/config -m GENERIC64 TB --- 2013-04-20 14:09:38 - building GENERIC64 kernel TB --- 2013-04-20 14:09:38 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 14:09:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 14:09:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 14:09:38 - SRCCONF=/dev/null TB --- 2013-04-20 14:09:38 - TARGET=powerpc TB --- 2013-04-20 14:09:38 - TARGET_ARCH=powerpc64 TB --- 2013-04-20 14:09:38 - TZ=UTC TB --- 2013-04-20 14:09:38 - __MAKE_CONF=/dev/null TB --- 2013-04-20 14:09:38 - cd /src TB --- 2013-04-20 14:09:38 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sat Apr 20 14:09:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_sim.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_xpt.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_all.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_cd.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/modules/cam/../../cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/modules/cam/../../cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /src/sys/modules/cam. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 14:17:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 14:17:26 - ERROR: failed to build GENERIC64 kernel TB --- 2013-04-20 14:17:26 - 9958.69 user 1229.59 system 11315.88 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 14:52:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3525268 for ; Sat, 20 Apr 2013 14:52:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by mx1.freebsd.org (Postfix) with ESMTP id D262F1FC7 for ; Sat, 20 Apr 2013 14:52:29 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id kl13so2795542pab.32 for ; Sat, 20 Apr 2013 07:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HrUa5ay76TylXeCwvW72jHiNkdvtxiEsRIGrWkaMMu0=; b=Fz4DpJsNTxvK3hDDnjE9FYBJ/Gfhb7pZEbC6y+/UxStri+xJMJMFFsIxmjrGHHQh77 Z6bt0Pho/qfOmjxFmHCCM932UQubLJcuL8/nlY//WxF6vdpP9M6dnfd/3vYriu2LJsEm ioIfjXDv1uQ0bp838nDypdw5q0nvJZ3fooT4ZZEcAylIBhVqdcuApkdmOaGiQE7ZlhfJ EFWEZjIzNzCFPiRr5xBAdojxeBBfj6oYj3tQf2nuDq9zFA2ejbvTV4K+TkqMLCXNr7ea Wz6zdZZNV2j//XBUVUZxWc2MhDoP+MUsaIM8vpNv90mVBE5W66xQvBqrEkpsmZzlTe1J yJtw== MIME-Version: 1.0 X-Received: by 10.68.248.8 with SMTP id yi8mr2164134pbc.54.1366469549250; Sat, 20 Apr 2013 07:52:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.27.99 with HTTP; Sat, 20 Apr 2013 07:52:29 -0700 (PDT) In-Reply-To: <1366447937.1475.35.camel@thor.walstatt.dyndns.org> References: <1366447937.1475.35.camel@thor.walstatt.dyndns.org> Date: Sat, 20 Apr 2013 07:52:29 -0700 X-Google-Sender-Auth: 2VNc2Gj08Da5lt6-2shmmVGBwDQ Message-ID: Subject: Re: CURRENT: extremely unresponsive disk I/O From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 14:52:30 -0000 Think you could trace down which kernel commit introduced the regression? It should be pretty easy if you know the window is only two weeks long. Thanks, Adrian On 20 April 2013 01:52, O. Hartmann wrote: > Since a couple of weeks now, FreeBSD 10.0-CURRENT is really unresponsive > when managing high disk I/O. > > This is most noticeable when starting the buildworld process, hwen clang > 3.3 starts to build the llvm backend libraries and doing some sort of > portmaster/portupgrade in parallel: even a "make rmconfig config" takes > aprox. a minute to show up. > > Is there a known issue at this moment? I can not see such a behaviour on > FreeBSD 9.1-STABLE (similar hardware). > > Oliver From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 14:52:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5CB336D for ; Sat, 20 Apr 2013 14:52:42 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by mx1.freebsd.org (Postfix) with ESMTP id 824191FD1 for ; Sat, 20 Apr 2013 14:52:42 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz1so278578pad.16 for ; Sat, 20 Apr 2013 07:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=GAP3dbmNd1tW3DEIThu1sC3M1kSbPb4SEl7TYUYeR4E=; b=t+CLkkCWkpkPUmzIeTudHeCKCQzpf/V/iw1tiGK99tUCrVUJWSp0P2MDs7wPqdxgWr jqHN2kztG/fYb0BXLrVnvo1+oigVmkWDmjDLHSwrU9DwOCST4aHkiU5aaQ0NFqJB2Wls V5oFUHW2G8lQIV8rClzEBs3Ai8ZROYvbngo+sE5kkcZg6VS3rionRaaQwOQe9QyumQYD q+k7LBlBL3SbzCIMuH4TqLhvWqYy3nsLq/GIkPxInaXQlgfXlLs058Tcf2qHDLcDNGvV sW7yuXa2RpqJFnhl0/RAUKSdveon9BMmanN4F9aQ1bTKKC6tGGSrhWRe+OIuwBPCHHjR TKjA== MIME-Version: 1.0 X-Received: by 10.68.204.169 with SMTP id kz9mr10879750pbc.188.1366469556006; Sat, 20 Apr 2013 07:52:36 -0700 (PDT) Received: by 10.68.5.231 with HTTP; Sat, 20 Apr 2013 07:52:35 -0700 (PDT) Date: Sat, 20 Apr 2013 22:52:35 +0800 Message-ID: Subject: panic when booting HEAD on i386 From: Ganbold Tsagaankhuu To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 14:52:42 -0000 Hi, I'm trying to boot HEAD after updating, but unfortunately it panics with following message: panic: kmem_suballoc: bad status return of 3. I was only able to get image of the panic. http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg Does anybody see same panic booting on i386 lately? Tried clang, and it panics also. thanks, Ganbold From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 15:01:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0159653 for ; Sat, 20 Apr 2013 15:01:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6423B88 for ; Sat, 20 Apr 2013 15:01:16 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r3KF1Ge1053270; Sat, 20 Apr 2013 08:01:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r3KF1GfU053269; Sat, 20 Apr 2013 08:01:16 -0700 (PDT) (envelope-from david) Date: Sat, 20 Apr 2013 08:01:16 -0700 From: David Wolfskill To: Ganbold Tsagaankhuu Subject: Re: panic when booting HEAD on i386 Message-ID: <20130420150116.GP1404@albert.catwhisker.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6LBV5rbcQI/FyIzH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 15:01:17 -0000 --6LBV5rbcQI/FyIzH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > Hi, >=20 > I'm trying to boot HEAD after updating, but unfortunately it panics with > following message: >=20 > panic: kmem_suballoc: bad status return of 3. >=20 > I was only able to get image of the panic. >=20 > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg >=20 > Does anybody see same panic booting on i386 lately? > Tried clang, and it panics also. > ... My (daily) updates/smoke tests on i386 were uneventful both yesterday & today -- both on my laptop & my build machine (the latter of which runs a GENERIC kernel). I use clang as the system compiler; here are some recent uname strings: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #874 r2496= 16M/249616:1000030: Thu Apr 18 07:40:02 PDT 2013 root@g1-227.catwhisker= =2Eorg:/usr/obj/usr/src/sys/CANARY i386 FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #875 r2496= 44M/249644:1000030: Fri Apr 19 05:42:45 PDT 2013 root@g1-227.catwhisker= =2Eorg:/usr/obj/usr/src/sys/CANARY i386 FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #876 r2496= 88M/249689:1000030: Sat Apr 20 05:12:39 PDT 2013 root@g1-227.catwhisker= =2Eorg:/usr/obj/usr/src/sys/CANARY i386 Looking at the image you provided, I see that you're at r249649; my builds bracketing that were at r249644 & r249688. You could try updating to r249688, perhaps -- it certainly worked for me. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6LBV5rbcQI/FyIzH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFyrbsACgkQmprOCmdXAD0LXQCggrCnxRDJqXOudIPhPYaes7T5 WOIAnRc6Zcm35Qu2pDWgdgPGrXW2ERYv =ufp/ -----END PGP SIGNATURE----- --6LBV5rbcQI/FyIzH-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 15:21:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EE527AC7 for ; Sat, 20 Apr 2013 15:21:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 653BD118 for ; Sat, 20 Apr 2013 15:21:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r3KFL2un083699; Sat, 20 Apr 2013 18:21:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r3KFL2un083699 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r3KFL2iX083698; Sat, 20 Apr 2013 18:21:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Apr 2013 18:21:02 +0300 From: Konstantin Belousov To: Ganbold Tsagaankhuu Subject: Re: panic when booting HEAD on i386 Message-ID: <20130420152102.GC67273@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JWEK1jqKZ6MHAcjA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 15:21:14 -0000 --JWEK1jqKZ6MHAcjA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > Hi, >=20 > I'm trying to boot HEAD after updating, but unfortunately it panics with > following message: >=20 > panic: kmem_suballoc: bad status return of 3. >=20 > I was only able to get image of the panic. >=20 > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg >=20 > Does anybody see same panic booting on i386 lately? > Tried clang, and it panics also. How much memory do you have ? Do you have any tunables in the loader.conf ? What was the previous version of the kernel which worked for you ? r249538 boots for me on i386 with memory sizes of 64M, 2G and 4G. --JWEK1jqKZ6MHAcjA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRcrJdAAoJEJDCuSvBvK1BfesP/jZY6VNfWBzXkQlplSl+YcnC xpPPmIkNBkYe6c3qJNb1p7NjMpKhIvf4kJUtI6RiVqNFs6hTWUbps/smZHbC1Qtw b5d+iYKaRenJ1qKfHyaTiIkmHH7YOplUnT649zGvDw89mV0PsjwmMz8HLkNGOlp+ eUS6m9PmPQrvTYBRyVKImGsXsHQlp93X1I+XLCcu66+ube/v9m8zozPN0wZxsnjL i/lRqoW4WgwzYrmJS0VZ+txQy9jPVgRBoDiIpnXlmXXzjUjvb9558gNTA+YLNbsH yv5L/SzYLBqRK1fc7fD4yQ5wiPh9aac/byeFG8lB+NpuyZ4rppE2C4yq/Nvn5P+c sISuLWltryCXi8ccvqeEchE2yrcOUehhaVFuBlZSgFDRlygq7vE7O6rWKLP9uxRR 2tkzQAEJfjYicaQycFZfU1OxkWgS4sFTZLrepELLgeCqPddU43PSiZuCoXiuqSD4 g+lVMMu91OafgZhev7remu9sGMjpzi56UmajxI7N5mbI7kdxx833PVuPHLFVJ0Q8 +UJv7zG4iRECAY30Pbzz5KgWRoJA3NU4AQrvdNzHnYp09aBNIZ+hZRSUNpfHBAn+ xMhPZWEoaZm1J7/5r1h29DXNyJ7qcGR75E7FHNR8PjjBynn4lrFlOmBwbcp0sP3A Be/JMCi3D7NvyZHaqhaE =j7Hy -----END PGP SIGNATURE----- --JWEK1jqKZ6MHAcjA-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 15:32:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85E0ADE9 for ; Sat, 20 Apr 2013 15:32:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by mx1.freebsd.org (Postfix) with ESMTP id 65531174 for ; Sat, 20 Apr 2013 15:32:32 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id kp14so2780508pab.22 for ; Sat, 20 Apr 2013 08:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dMrcJDhWWnJLsPmrlTyka1lu3wXa9ibnTS0prUh1PFc=; b=dfaqvoGS8DJSNkqFpz7G7Etfw8WPBzzHOhannHyruBSnzs3Rthvw8J43uGJIKK5kZp 5ao9QIn8j3R6T7SYEmhDzRY7n+npcSWfQOEyVdSlUsxGIu7UPoeNCw8yRJb4lEyBzj4H QcNeA+CRGMksbEBtnqcoqoaTmElRCWWG96Rznunwx0lapgT5xJExEPYYyz8LxRDzjkSn Z1tY8g6OLCNOhefxaGy0Xy4SkSryUwxaXsndmVFr+x4MhjGSM+FL5f7MpNoAbMOzDmlj M4EJhog/dDU7ZCzovIqphUYhsdOe9e9vSfuzcQP6XCvvlQ9Jl5OMby9pKJhrapqJMxSF OrqQ== MIME-Version: 1.0 X-Received: by 10.68.49.193 with SMTP id w1mr24133585pbn.146.1366471946757; Sat, 20 Apr 2013 08:32:26 -0700 (PDT) Received: by 10.68.5.231 with HTTP; Sat, 20 Apr 2013 08:32:26 -0700 (PDT) In-Reply-To: <20130420152102.GC67273@kib.kiev.ua> References: <20130420152102.GC67273@kib.kiev.ua> Date: Sat, 20 Apr 2013 23:32:26 +0800 Message-ID: Subject: Re: panic when booting HEAD on i386 From: Ganbold Tsagaankhuu To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 15:32:32 -0000 On Sat, Apr 20, 2013 at 11:21 PM, Konstantin Belousov wrote: > On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > > Hi, > > > > I'm trying to boot HEAD after updating, but unfortunately it panics with > > following message: > > > > panic: kmem_suballoc: bad status return of 3. > > > > I was only able to get image of the panic. > > > > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg > > > > Does anybody see same panic booting on i386 lately? > > Tried clang, and it panics also. > > How much memory do you have ? > 2GB. http://people.freebsd.org/~ganbold/dmesg.txt > Do you have any tunables in the loader.conf ? > Just checked, it seems old kqemu, atapicam etc. were there. This is what was on old kernel right after WITNESS line: link_elf: symbol _mtx_unlock_flags undefined KLD file kqemu.ko - could not finalize loading link_elf: symbol ata_controlcmd undefined KLD file atapicam.ko - could not finalize loading > What was the previous version of the kernel which worked for you ? > r244046. I will disable kqemu, atapicam etc and try again. thanks, Ganbold > > r249538 boots for me on i386 with memory sizes of 64M, 2G and 4G. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 16:26:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 64C67AF4 for ; Sat, 20 Apr 2013 16:26:14 +0000 (UTC) (envelope-from prvs=18229b97a1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 050B02F0 for ; Sat, 20 Apr 2013 16:26:13 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50003391000.msg for ; Sat, 20 Apr 2013 17:26:01 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 20 Apr 2013 17:26:01 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=18229b97a1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> From: "Steven Hartland" To: Subject: Booting an alternative kernel from loader prompt fails the first time only Date: Sat, 20 Apr 2013 17:05:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 16:26:14 -0000 When trying to boot an alternative kernel from the loader prompt it fails the first time the command is run but succeeds the second time. Type '?' for a list of commands, 'help' for more detailed help. OK boot kernel.generic Booting... don't know how to load module '/boot/kernel.generic/kernel' OK boot kernel.generic Booting... /boot/kernel.generic/kernel text=0xd21288 data=...... Both kernels where built from r249664 based source. As a side issue, shouldn't additional kernel module dependencies be noted in UPDATING so those that use MODULES_OVERRIDE don't get bitten by machines failing to boot due to known dependencies? Ideally it would be nice if there was some sort of warning when building / installing the kernel that dependencies where missing. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 16:47:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85890DD9 for ; Sat, 20 Apr 2013 16:47:27 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:4f8:162:1142::2]) by mx1.freebsd.org (Postfix) with ESMTP id 44D0B36A for ; Sat, 20 Apr 2013 16:47:27 +0000 (UTC) Received: from cpos1.nexxtmobile.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id C77FCD7BA; Sat, 20 Apr 2013 18:47:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at nexxtmobile.de Received: from mail.solomo.de ([127.0.0.1]) by cpos1.nexxtmobile.de (cpos1.nexxtmobile.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TDbKORTS0Ty4; Sat, 20 Apr 2013 18:47:24 +0200 (CEST) Received: from nibbler-osx.fritz.box (unknown [IPv6:2001:4dd0:ff00:8bb6:5d4d:3c4f:c7ec:ed1f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id DD9EFD7A6; Sat, 20 Apr 2013 18:47:23 +0200 (CEST) Message-ID: <5172C699.8020708@smeets.im> Date: Sat, 20 Apr 2013 18:47:21 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0a1 MIME-Version: 1.0 To: Steven Hartland , freebsd-current@freebsd.org Subject: Re: Booting an alternative kernel from loader prompt fails the first time only References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> In-Reply-To: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FUBCRHNMSLJMOQPVFUUK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 16:47:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FUBCRHNMSLJMOQPVFUUK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.04.13 18:05, Steven Hartland wrote: > When trying to boot an alternative kernel from the loader prompt > it fails the first time the command is run but succeeds the second > time. >=20 > Type '?' for a list of commands, 'help' for more detailed help. > OK boot kernel.generic > Booting... > don't know how to load module '/boot/kernel.generic/kernel' > OK boot kernel.generic > Booting... > /boot/kernel.generic/kernel text=3D0xd21288 data=3D...... >=20 Yes, I've been seeing the same thing for about 6-12 months maybe more. None of the people I asked were able to confirm, so I'm happy that I'm not imagining it :) I see this on serial as well as on the normal console in front of a PC. Florian ------enig2FUBCRHNMSLJMOQPVFUUK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlFyxpoACgkQapo8P8lCvwl1HQCfTF56z7Lk+g58FOLLC6u8MmTb qToAn0nnuJPuzzHOu14Kw7WRlBzL94RT =WEuX -----END PGP SIGNATURE----- ------enig2FUBCRHNMSLJMOQPVFUUK-- From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 17:24:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF44667F for ; Sat, 20 Apr 2013 17:24:34 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 891C86DB for ; Sat, 20 Apr 2013 17:24:34 +0000 (UTC) Received: from p5dc3fbd8.dip0.t-ipconnect.de ([93.195.251.216] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UTbWR-00084Z-VQ; Sat, 20 Apr 2013 19:24:24 +0200 Message-ID: <5172CF44.1050309@gwdg.de> Date: Sat, 20 Apr 2013 19:24:20 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Florian Smeets Subject: Re: Booting an alternative kernel from loader prompt fails the first time only References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> <5172C699.8020708@smeets.im> In-Reply-To: <5172C699.8020708@smeets.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org, Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 17:24:34 -0000 On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote: > On 20.04.13 18:05, Steven Hartland wrote: >> When trying to boot an alternative kernel from the loader prompt >> it fails the first time the command is run but succeeds the second >> time. >> >> Type '?' for a list of commands, 'help' for more detailed help. >> OK boot kernel.generic >> Booting... >> don't know how to load module '/boot/kernel.generic/kernel' >> OK boot kernel.generic >> Booting... >> /boot/kernel.generic/kernel text=0xd21288 data=...... >> > > Yes, I've been seeing the same thing for about 6-12 months maybe more. > None of the people I asked were able to confirm, so I'm happy that I'm > not imagining it :) I also can confirm this behaviour for month now (on 10.0-CURRENT amd64 with clang). Rainer > > I see this on serial as well as on the normal console in front of a PC. > > Florian > From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 18:06:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAC24497 for ; Sat, 20 Apr 2013 18:06:44 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0658A4 for ; Sat, 20 Apr 2013 18:06:44 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.6/8.14.6) with ESMTP id r3KHfrJe001805 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT); Sat, 20 Apr 2013 10:41:54 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201304201741.r3KHfrJe001805@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 20 Apr 2013 10:41:48 -0700 To: Rainer Hurling , Florian Smeets From: Manfred Antar Subject: Re: Booting an alternative kernel from loader prompt fails the first time only In-Reply-To: <5172CF44.1050309@gwdg.de> References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> <5172C699.8020708@smeets.im> <5172CF44.1050309@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: r3KHfrJe001805 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: freebsd-current@freebsd.org, Steven Hartland X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 18:06:44 -0000 At 10:24 AM 4/20/2013, Rainer Hurling wrote: >On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote: >> On 20.04.13 18:05, Steven Hartland wrote: >>> When trying to boot an alternative kernel from the loader prompt >>> it fails the first time the command is run but succeeds the second >>> time. >>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK boot kernel.generic >>> Booting... >>> don't know how to load module '/boot/kernel.generic/kernel' >>> OK boot kernel.generic >>> Booting... >>> /boot/kernel.generic/kernel text=0xd21288 data=...... >>> >> >> Yes, I've been seeing the same thing for about 6-12 months maybe more. >> None of the people I asked were able to confirm, so I'm happy that I'm >> not imagining it :) > >I also can confirm this behaviour for month now (on 10.0-CURRENT amd64 >with clang). > >Rainer > >> >> I see this on serial as well as on the normal console in front of a PC. >> >> Florian >> Have you tried: OK boot /boot/kernel.generic/kernel Use full path name always works for me Manfred ======================== || null@pozo.com || || || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 21:02:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36C60609; Sat, 20 Apr 2013 21:02:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F3B55EA2; Sat, 20 Apr 2013 21:02:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KL2ifw047148; Sat, 20 Apr 2013 17:02:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KL2i34047117; Sat, 20 Apr 2013 21:02:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 21:02:44 GMT Message-Id: <201304202102.r3KL2i34047117@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 21:02:46 -0000 TB --- 2013-04-20 19:23:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 19:23:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 19:23:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-04-20 19:23:26 - cleaning the object tree TB --- 2013-04-20 19:25:04 - /usr/local/bin/svn stat /src TB --- 2013-04-20 19:25:08 - At svn revision 249700 TB --- 2013-04-20 19:25:09 - building world TB --- 2013-04-20 19:25:09 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 19:25:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 19:25:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 19:25:09 - SRCCONF=/dev/null TB --- 2013-04-20 19:25:09 - TARGET=ia64 TB --- 2013-04-20 19:25:09 - TARGET_ARCH=ia64 TB --- 2013-04-20 19:25:09 - TZ=UTC TB --- 2013-04-20 19:25:09 - __MAKE_CONF=/dev/null TB --- 2013-04-20 19:25:09 - cd /src TB --- 2013-04-20 19:25:09 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 19:25:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 20:59:40 UTC 2013 TB --- 2013-04-20 20:59:40 - generating LINT kernel config TB --- 2013-04-20 20:59:40 - cd /src/sys/ia64/conf TB --- 2013-04-20 20:59:40 - /usr/bin/make -B LINT TB --- 2013-04-20 20:59:40 - cd /src/sys/ia64/conf TB --- 2013-04-20 20:59:40 - /usr/sbin/config -m LINT TB --- 2013-04-20 20:59:40 - building LINT kernel TB --- 2013-04-20 20:59:40 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 20:59:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 20:59:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 20:59:40 - SRCCONF=/dev/null TB --- 2013-04-20 20:59:40 - TARGET=ia64 TB --- 2013-04-20 20:59:40 - TARGET_ARCH=ia64 TB --- 2013-04-20 20:59:40 - TZ=UTC TB --- 2013-04-20 20:59:40 - __MAKE_CONF=/dev/null TB --- 2013-04-20 20:59:40 - cd /src TB --- 2013-04-20 20:59:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 20:59:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 21:02:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 21:02:44 - ERROR: failed to build LINT kernel TB --- 2013-04-20 21:02:44 - 4586.35 user 781.47 system 5958.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 21:46:13 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35C50F54; Sat, 20 Apr 2013 21:46:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F4117FC3; Sat, 20 Apr 2013 21:46:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KLkCB6009936; Sat, 20 Apr 2013 17:46:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KLkChC009930; Sat, 20 Apr 2013 21:46:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 21:46:12 GMT Message-Id: <201304202146.r3KLkChC009930@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 21:46:13 -0000 TB --- 2013-04-20 18:02:30 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 18:02:30 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 18:02:30 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-20 18:02:30 - cleaning the object tree TB --- 2013-04-20 18:04:26 - /usr/local/bin/svn stat /src TB --- 2013-04-20 18:04:40 - At svn revision 249700 TB --- 2013-04-20 18:04:41 - building world TB --- 2013-04-20 18:04:41 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 18:04:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 18:04:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 18:04:41 - SRCCONF=/dev/null TB --- 2013-04-20 18:04:41 - TARGET=pc98 TB --- 2013-04-20 18:04:41 - TARGET_ARCH=i386 TB --- 2013-04-20 18:04:41 - TZ=UTC TB --- 2013-04-20 18:04:41 - __MAKE_CONF=/dev/null TB --- 2013-04-20 18:04:41 - cd /src TB --- 2013-04-20 18:04:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 18:04:46 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 21:20:41 UTC 2013 TB --- 2013-04-20 21:20:41 - generating LINT kernel config TB --- 2013-04-20 21:20:41 - cd /src/sys/pc98/conf TB --- 2013-04-20 21:20:41 - /usr/bin/make -B LINT TB --- 2013-04-20 21:20:41 - cd /src/sys/pc98/conf TB --- 2013-04-20 21:20:41 - /usr/sbin/config -m LINT TB --- 2013-04-20 21:20:41 - building LINT kernel TB --- 2013-04-20 21:20:41 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 21:20:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 21:20:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 21:20:41 - SRCCONF=/dev/null TB --- 2013-04-20 21:20:41 - TARGET=pc98 TB --- 2013-04-20 21:20:41 - TARGET_ARCH=i386 TB --- 2013-04-20 21:20:41 - TZ=UTC TB --- 2013-04-20 21:20:41 - __MAKE_CONF=/dev/null TB --- 2013-04-20 21:20:41 - cd /src TB --- 2013-04-20 21:20:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 21:20:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~~~~~~~~~~~~~~~~~~~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 21:46:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 21:46:11 - ERROR: failed to build LINT kernel TB --- 2013-04-20 21:46:11 - 10593.60 user 1540.50 system 13421.32 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 21:56:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 136851BB; Sat, 20 Apr 2013 21:56:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C7E5E100F; Sat, 20 Apr 2013 21:56:01 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id F1547E66B9; Sat, 20 Apr 2013 23:03:28 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=myoFeo613IMy PAw4h8WuPp+Iyz0=; b=siGBW8JHM5SPwVjSmLA9yKJ/m+WQYJwbppNXq4gIKxU1 o73egMURhgiQ24O7FpoG2YHwv4CMK/UkQQuGxoTJ9tIX8ob7vHux2QzbUp0G/Uao M8ZOxqU3UYAOhfUFQT43RgfRjefwLfZ8iH7bUY+jRPsZ4ep1YOCFbdLzHHIne2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=BnbgfL g0uV8j7kYs6mCyW3bj9Z2NvlMUMD+KJO668I3NClnMB3CjhmttJl5sWkTBpFrPr/ 6SzKKVL4f+FI5hVYzd1sZ0CgKs8qzgQyvAzk9mepp2izzMeYSW2pJIK5fLxkCzXj iLTXWd26++3hETX6+8KAYQxwYdiIBpETLTY9g= Received: from mb.local (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 68765E66B3; Sat, 20 Apr 2013 23:03:28 +0100 (BST) Message-ID: <51730EE7.8060301@cran.org.uk> Date: Sat, 20 Apr 2013 22:55:51 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> <515D3312.3010109@FreeBSD.org> In-Reply-To: <515D3312.3010109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 21:56:02 -0000 On 04/04/2013 09:00, Matthias Andree wrote: > Any good "concurrent write" exercise tools for Unix that I could run > on the Linux ext4 partition that you would propose? benchmarks/fio is good for that. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 22:10:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F9C9449; Sat, 20 Apr 2013 22:10:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 478661070; Sat, 20 Apr 2013 22:10:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KMAaoo006730; Sat, 20 Apr 2013 18:10:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KMAaUb006726; Sat, 20 Apr 2013 22:10:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 22:10:36 GMT Message-Id: <201304202210.r3KMAaUb006726@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 22:10:42 -0000 TB --- 2013-04-20 21:02:44 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 21:02:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 21:02:44 - starting HEAD tinderbox run for mips/mips TB --- 2013-04-20 21:02:44 - cleaning the object tree TB --- 2013-04-20 21:04:06 - /usr/local/bin/svn stat /src TB --- 2013-04-20 21:04:15 - At svn revision 249700 TB --- 2013-04-20 21:04:16 - building world TB --- 2013-04-20 21:04:16 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 21:04:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 21:04:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 21:04:16 - SRCCONF=/dev/null TB --- 2013-04-20 21:04:16 - TARGET=mips TB --- 2013-04-20 21:04:16 - TARGET_ARCH=mips TB --- 2013-04-20 21:04:16 - TZ=UTC TB --- 2013-04-20 21:04:16 - __MAKE_CONF=/dev/null TB --- 2013-04-20 21:04:16 - cd /src TB --- 2013-04-20 21:04:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 21:04:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 22:04:47 UTC 2013 TB --- 2013-04-20 22:04:47 - cd /src/sys/mips/conf TB --- 2013-04-20 22:04:47 - /usr/sbin/config -m ADM5120 TB --- 2013-04-20 22:04:47 - skipping ADM5120 kernel TB --- 2013-04-20 22:04:47 - cd /src/sys/mips/conf TB --- 2013-04-20 22:04:47 - /usr/sbin/config -m ALCHEMY TB --- 2013-04-20 22:04:47 - skipping ALCHEMY kernel TB --- 2013-04-20 22:04:47 - cd /src/sys/mips/conf TB --- 2013-04-20 22:04:47 - /usr/sbin/config -m AP121 TB --- 2013-04-20 22:04:48 - building AP121 kernel TB --- 2013-04-20 22:04:48 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:04:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:04:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:04:48 - SRCCONF=/dev/null TB --- 2013-04-20 22:04:48 - TARGET=mips TB --- 2013-04-20 22:04:48 - TARGET_ARCH=mips TB --- 2013-04-20 22:04:48 - TZ=UTC TB --- 2013-04-20 22:04:48 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:04:48 - cd /src TB --- 2013-04-20 22:04:48 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Sat Apr 20 22:04:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AP121 completed on Sat Apr 20 22:07:01 UTC 2013 TB --- 2013-04-20 22:07:01 - cd /src/sys/mips/conf TB --- 2013-04-20 22:07:01 - /usr/sbin/config -m AP91 TB --- 2013-04-20 22:07:01 - building AP91 kernel TB --- 2013-04-20 22:07:01 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:07:01 - SRCCONF=/dev/null TB --- 2013-04-20 22:07:01 - TARGET=mips TB --- 2013-04-20 22:07:01 - TARGET_ARCH=mips TB --- 2013-04-20 22:07:01 - TZ=UTC TB --- 2013-04-20 22:07:01 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:07:01 - cd /src TB --- 2013-04-20 22:07:01 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Sat Apr 20 22:07:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_sim.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/cam_xpt.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_all.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_cd.c cc -O -pipe -G0 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/mips.mips/src/sys/AP91/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -G0 -fno-pic -mno-abicalls -mlong-calls -I/obj/mips.mips/src/sys/AP91 -msoft-float -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/cam/../../cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/modules/cam/../../cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/modules/cam/../../cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /src/sys/modules/cam. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/mips.mips/src/sys/AP91. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 22:10:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 22:10:36 - ERROR: failed to build AP91 kernel TB --- 2013-04-20 22:10:36 - 2959.97 user 633.39 system 4071.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 22:31:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66BFF9B5; Sat, 20 Apr 2013 22:31:55 +0000 (UTC) (envelope-from artyom.mirgorodsky@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id BB80510F4; Sat, 20 Apr 2013 22:31:54 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id m6so2516320wiv.1 for ; Sat, 20 Apr 2013 15:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=QLZt+QSFuGU6kmJSBGQ4PidVtqTowDI0Hou4D4bV0Qg=; b=iMeeFVgpz4HvPTcQNMZUSfaWG5uwKqSPzHIhiUCuPJdCkX6/+zTT5tDzFuUN0OoGyL KPZ/Sjy89/0cLmilomJi9G+ZzzfuTlYlaJSs9Z6vrOXsiSdR2WD8GDFde2vJeZfK3rU+ yySa0m9uqL+b90H2lm7BjfMY3jTGCEgxd/F96h2jrBipRqMupSrK63JQwxCT4SjOOVFh ttPcvzPfoyVYq3ZzeebhB0m4QmaLe8HYEoI5+3dmY6m6ss/niQGuUZVvwwWSkoLetP9V VC27OPEAPvQBxK2tX/9JwclyZahNkqiuLp+XrtLnmjkCto9Aw4t929qw47Ohw8ImV4J5 BpoA== X-Received: by 10.180.183.50 with SMTP id ej18mr4897886wic.4.1366497113968; Sat, 20 Apr 2013 15:31:53 -0700 (PDT) Received: from home.alkar.net ([178.215.171.22]) by mx.google.com with ESMTPS id bk42sm31584961eeb.3.2013.04.20.15.31.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 15:31:53 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: Atheros 9287 - no carrier . revision 249623. Date: Sun, 21 Apr 2013 01:33:39 +0300 Message-ID: <2301776.YtT55NUVoa@home.alkar.net> User-Agent: KMail/4.10.1 (FreeBSD/10.0-CURRENT; KDE/4.10.1; amd64; ; ) In-Reply-To: References: <1825476.qO1YuZaJ09@home.alkar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 22:31:55 -0000 Works fine. Thank you, Adrian On Friday 19 April 2013 14:57:12 Adrian Chadd wrote: > Hi! > > Ok, please update to -HEAD and retest! > > > > adrian > > On 19 April 2013 06:26, Adrian Chadd wrote: > > oooooo good to know! let me setup the chainmask info whether or not > > the 11n option is set. > > > > thanks! > > > > > > adrian > > > > On 19 April 2013 04:08, Artyom Mirgorodskiy > > wrote: > >> Adrian, I found the problem. > >> > >> I'm use ath as module, so ATH_ENABLE_11N is not defined. When I define > >> ATH_ENABLE_11N - everything work. > >> > >> > >> > >> > >> > >> Artyom Mirgorodskiy > >> > >> > >> > >> On Friday 19 April 2013 13:27:21 wrote: > >> > >> Updated. However I did not see chainmask information. > >> > >> See attached > >> > >> > >> > >> On Friday 19 April 2013 00:57:12 Adrian Chadd wrote: > >> > >>> Hi, > >> > >>> > >> > >>> I've just committed some changes to -HEAD. Please update to the latest > >> > >>> -HEAD and paste me the ath0 dmesg output. > >> > >>> It will include the chainmask information. > >> > >>> > >> > >>> Thanks, > >> > >>> > >> > >>> > >> > >>> Adrian > >> > >> -- > >> > >> Artyom Mirgorodskiy > >> > >> > >> -- > >> > >> Artyom Mirgorodskiy -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 22:48:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52D49EE3; Sat, 20 Apr 2013 22:48:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 035A11179; Sat, 20 Apr 2013 22:48:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KMmi7R089461; Sat, 20 Apr 2013 18:48:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KMmiZE089455; Sat, 20 Apr 2013 22:48:44 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 22:48:44 GMT Message-Id: <201304202248.r3KMmiZE089455@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 22:48:45 -0000 TB --- 2013-04-20 21:33:27 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 21:33:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 21:33:27 - starting HEAD tinderbox run for mips64/mips TB --- 2013-04-20 21:33:27 - cleaning the object tree TB --- 2013-04-20 21:34:53 - /usr/local/bin/svn stat /src TB --- 2013-04-20 21:34:56 - At svn revision 249700 TB --- 2013-04-20 21:34:57 - building world TB --- 2013-04-20 21:34:57 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 21:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 21:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 21:34:57 - SRCCONF=/dev/null TB --- 2013-04-20 21:34:57 - TARGET=mips TB --- 2013-04-20 21:34:57 - TARGET_ARCH=mips64 TB --- 2013-04-20 21:34:57 - TZ=UTC TB --- 2013-04-20 21:34:57 - __MAKE_CONF=/dev/null TB --- 2013-04-20 21:34:57 - cd /src TB --- 2013-04-20 21:34:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 21:35:02 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 22:36:30 UTC 2013 TB --- 2013-04-20 22:36:30 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:30 - /usr/sbin/config -m ADM5120 TB --- 2013-04-20 22:36:30 - skipping ADM5120 kernel TB --- 2013-04-20 22:36:30 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:30 - /usr/sbin/config -m ALCHEMY TB --- 2013-04-20 22:36:30 - skipping ALCHEMY kernel TB --- 2013-04-20 22:36:30 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:30 - /usr/sbin/config -m AP121 TB --- 2013-04-20 22:36:31 - skipping AP121 kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AP91 TB --- 2013-04-20 22:36:31 - skipping AP91 kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AP93 TB --- 2013-04-20 22:36:31 - skipping AP93 kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AP94 TB --- 2013-04-20 22:36:31 - skipping AP94 kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AP96 TB --- 2013-04-20 22:36:31 - skipping AP96 kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-04-20 22:36:31 - skipping AR71XX_BASE kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AR724X_BASE TB --- 2013-04-20 22:36:31 - skipping AR724X_BASE kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-04-20 22:36:31 - skipping AR91XX_BASE kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m AR933X_BASE TB --- 2013-04-20 22:36:31 - skipping AR933X_BASE kernel TB --- 2013-04-20 22:36:31 - cd /src/sys/mips/conf TB --- 2013-04-20 22:36:31 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-04-20 22:36:31 - building BERI_DE4_MDROOT kernel TB --- 2013-04-20 22:36:31 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:36:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:36:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:36:31 - SRCCONF=/dev/null TB --- 2013-04-20 22:36:31 - TARGET=mips TB --- 2013-04-20 22:36:31 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:36:31 - TZ=UTC TB --- 2013-04-20 22:36:31 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:36:31 - cd /src TB --- 2013-04-20 22:36:31 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Apr 20 22:36:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Sat Apr 20 22:39:00 UTC 2013 TB --- 2013-04-20 22:39:00 - cd /src/sys/mips/conf TB --- 2013-04-20 22:39:00 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-04-20 22:39:00 - building BERI_DE4_SDROOT kernel TB --- 2013-04-20 22:39:00 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:39:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:39:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:39:00 - SRCCONF=/dev/null TB --- 2013-04-20 22:39:00 - TARGET=mips TB --- 2013-04-20 22:39:00 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:39:00 - TZ=UTC TB --- 2013-04-20 22:39:00 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:39:00 - cd /src TB --- 2013-04-20 22:39:00 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Sat Apr 20 22:39:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Sat Apr 20 22:41:18 UTC 2013 TB --- 2013-04-20 22:41:18 - cd /src/sys/mips/conf TB --- 2013-04-20 22:41:18 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-04-20 22:41:18 - building BERI_SIM_MDROOT kernel TB --- 2013-04-20 22:41:18 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:41:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:41:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:41:18 - SRCCONF=/dev/null TB --- 2013-04-20 22:41:18 - TARGET=mips TB --- 2013-04-20 22:41:18 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:41:18 - TZ=UTC TB --- 2013-04-20 22:41:18 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:41:18 - cd /src TB --- 2013-04-20 22:41:18 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Sat Apr 20 22:41:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Sat Apr 20 22:43:33 UTC 2013 TB --- 2013-04-20 22:43:33 - cd /src/sys/mips/conf TB --- 2013-04-20 22:43:33 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-04-20 22:43:33 - building BERI_TEMPLATE kernel TB --- 2013-04-20 22:43:33 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:43:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:43:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:43:33 - SRCCONF=/dev/null TB --- 2013-04-20 22:43:33 - TARGET=mips TB --- 2013-04-20 22:43:33 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:43:33 - TZ=UTC TB --- 2013-04-20 22:43:33 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:43:33 - cd /src TB --- 2013-04-20 22:43:33 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Sat Apr 20 22:43:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Sat Apr 20 22:45:45 UTC 2013 TB --- 2013-04-20 22:45:45 - cd /src/sys/mips/conf TB --- 2013-04-20 22:45:45 - /usr/sbin/config -m DIR-825 TB --- 2013-04-20 22:45:45 - skipping DIR-825 kernel TB --- 2013-04-20 22:45:45 - cd /src/sys/mips/conf TB --- 2013-04-20 22:45:45 - /usr/sbin/config -m GXEMUL TB --- 2013-04-20 22:45:45 - building GXEMUL kernel TB --- 2013-04-20 22:45:45 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:45:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:45:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:45:45 - SRCCONF=/dev/null TB --- 2013-04-20 22:45:45 - TARGET=mips TB --- 2013-04-20 22:45:45 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:45:45 - TZ=UTC TB --- 2013-04-20 22:45:45 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:45:45 - cd /src TB --- 2013-04-20 22:45:45 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Sat Apr 20 22:45:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Sat Apr 20 22:47:40 UTC 2013 TB --- 2013-04-20 22:47:40 - cd /src/sys/mips/conf TB --- 2013-04-20 22:47:40 - /usr/sbin/config -m IDT TB --- 2013-04-20 22:47:40 - skipping IDT kernel TB --- 2013-04-20 22:47:40 - cd /src/sys/mips/conf TB --- 2013-04-20 22:47:40 - /usr/sbin/config -m MALTA TB --- 2013-04-20 22:47:40 - skipping MALTA kernel TB --- 2013-04-20 22:47:40 - cd /src/sys/mips/conf TB --- 2013-04-20 22:47:40 - /usr/sbin/config -m MALTA64 TB --- 2013-04-20 22:47:40 - skipping MALTA64 kernel TB --- 2013-04-20 22:47:40 - cd /src/sys/mips/conf TB --- 2013-04-20 22:47:40 - /usr/sbin/config -m OCTEON1 TB --- 2013-04-20 22:47:40 - building OCTEON1 kernel TB --- 2013-04-20 22:47:40 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:47:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:47:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:47:40 - SRCCONF=/dev/null TB --- 2013-04-20 22:47:40 - TARGET=mips TB --- 2013-04-20 22:47:40 - TARGET_ARCH=mips64 TB --- 2013-04-20 22:47:40 - TZ=UTC TB --- 2013-04-20 22:47:40 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:47:40 - cd /src TB --- 2013-04-20 22:47:40 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Sat Apr 20 22:47:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/mips.mips64/src/sys/OCTEON1. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 22:48:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 22:48:44 - ERROR: failed to build OCTEON1 kernel TB --- 2013-04-20 22:48:44 - 3285.40 user 652.04 system 4516.55 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 23:18:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD6D2495; Sat, 20 Apr 2013 23:18:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 973D11269; Sat, 20 Apr 2013 23:18:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r3KNIl4p048132; Sat, 20 Apr 2013 19:18:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r3KNIlAe048131; Sat, 20 Apr 2013 23:18:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 20 Apr 2013 23:18:47 GMT Message-Id: <201304202318.r3KNIlAe048131@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 23:18:48 -0000 TB --- 2013-04-20 22:10:36 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-20 22:10:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-04-20 22:10:36 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-04-20 22:10:36 - cleaning the object tree TB --- 2013-04-20 22:11:47 - /usr/local/bin/svn stat /src TB --- 2013-04-20 22:11:51 - At svn revision 249700 TB --- 2013-04-20 22:11:52 - building world TB --- 2013-04-20 22:11:52 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 22:11:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 22:11:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 22:11:52 - SRCCONF=/dev/null TB --- 2013-04-20 22:11:52 - TARGET=sparc64 TB --- 2013-04-20 22:11:52 - TARGET_ARCH=sparc64 TB --- 2013-04-20 22:11:52 - TZ=UTC TB --- 2013-04-20 22:11:52 - __MAKE_CONF=/dev/null TB --- 2013-04-20 22:11:52 - cd /src TB --- 2013-04-20 22:11:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Apr 20 22:11:56 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Apr 20 23:16:13 UTC 2013 TB --- 2013-04-20 23:16:13 - generating LINT kernel config TB --- 2013-04-20 23:16:13 - cd /src/sys/sparc64/conf TB --- 2013-04-20 23:16:13 - /usr/bin/make -B LINT TB --- 2013-04-20 23:16:13 - cd /src/sys/sparc64/conf TB --- 2013-04-20 23:16:13 - /usr/sbin/config -m LINT TB --- 2013-04-20 23:16:13 - building LINT kernel TB --- 2013-04-20 23:16:13 - CROSS_BUILD_TESTING=YES TB --- 2013-04-20 23:16:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-20 23:16:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-20 23:16:13 - SRCCONF=/dev/null TB --- 2013-04-20 23:16:13 - TARGET=sparc64 TB --- 2013-04-20 23:16:13 - TARGET_ARCH=sparc64 TB --- 2013-04-20 23:16:13 - TZ=UTC TB --- 2013-04-20 23:16:13 - __MAKE_CONF=/dev/null TB --- 2013-04-20 23:16:13 - cd /src TB --- 2013-04-20 23:16:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Apr 20 23:16:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/ata/ata_pmp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_xpt.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_all.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_cd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/scsi/scsi_ch.c cc1: warnings being treated as errors /src/sys/cam/scsi/scsi_ch.c: In function 'copy_element_status': /src/sys/cam/scsi/scsi_ch.c:1157: warning: comparison is always false due to limited range of data type *** [scsi_ch.o] Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-20 23:18:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-20 23:18:47 - ERROR: failed to build LINT kernel TB --- 2013-04-20 23:18:47 - 3227.40 user 564.23 system 4091.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 23:42:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8A8993A for ; Sat, 20 Apr 2013 23:42:04 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id BC85012FB for ; Sat, 20 Apr 2013 23:42:04 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c12so1933980ieb.17 for ; Sat, 20 Apr 2013 16:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FenOy4nP96lAkxCXoFfHDNBdxn8Sa+byQFlPshkhXHc=; b=oLOwyNCwRgNJr7RGbvsz8hNYKXwkDVbq6LqGJNonigOO1irYcDt32BrJCq7IqNTlAI nSbzrnPTZPZn2BM1vf7PAv5eWkJ/Flt5yzbWy9X9Pu4dxoe5xxdA3voOx6Ocl2QWI0B8 qtkXm5kbfzleYsWGI52wtIPBLKi1AA3Us+fEmKfAoEY6gqjgJQaNf8ysZbvWSU6+HtC6 kSZtBrJwMCMn3dDSQXj8lDjSuqfyv7jbTa8eKb/jNhoFY7FXG5u/al/nHWE6vj0nZ9qo oV+8rw2bTMu88XYtqkAGumd+Zazgf6fCzaMS6fl3nKSKzqnPYbDNfElXFwA5uU4d3ANU bipg== X-Received: by 10.50.100.201 with SMTP id fa9mr17712732igb.28.1366501324459; Sat, 20 Apr 2013 16:42:04 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPSA id qn10sm9317503igc.6.2013.04.20.16.42.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Apr 2013 16:42:03 -0700 (PDT) Message-ID: <517327C5.5050305@gmail.com> Date: Sat, 20 Apr 2013 18:41:57 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Booting an alternative kernel from loader prompt fails the first time only References: <625362A8116D4B43AF4912773F478CB9@multiplay.co.uk> <5172C699.8020708@smeets.im> <5172CF44.1050309@gwdg.de> <201304201741.r3KHfrJe001805@pozo.com> In-Reply-To: <201304201741.r3KHfrJe001805@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 23:42:05 -0000 On 4/20/2013 12:41 PM, Manfred Antar wrote: > At 10:24 AM 4/20/2013, Rainer Hurling wrote: >> On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote: >>> On 20.04.13 18:05, Steven Hartland wrote: >>>> When trying to boot an alternative kernel from the loader prompt >>>> it fails the first time the command is run but succeeds the second >>>> time. >>>> >>>> Type '?' for a list of commands, 'help' for more detailed help. >>>> OK boot kernel.generic >>>> Booting... >>>> don't know how to load module '/boot/kernel.generic/kernel' >>>> OK boot kernel.generic >>>> Booting... >>>> /boot/kernel.generic/kernel text=0xd21288 data=...... >>>> >>> >>> Yes, I've been seeing the same thing for about 6-12 months maybe more. >>> None of the people I asked were able to confirm, so I'm happy that I'm >>> not imagining it :) >> >> I also can confirm this behaviour for month now (on 10.0-CURRENT amd64 >> with clang). >> >> Rainer >> > > Have you tried: > OK boot /boot/kernel.generic/kernel > > Use full path name always works for me > Manfred > I couldn't get any other method to work. I can also confirm this. While working with Adrian testing ath changes, I frequently had to reboot into an old kernel(/boot/ATH/kernel, full path seemed required) to regain networking unless I physically moved the computer to add ethernet. Also, it's really annoying when I would have to manually kldload each module in order, especially opensolaris.ko and zfs.ko, and making sure I loaded /boot/ATH/if_ath.ko before /boot/ATH/if_ath_pci.ko or else the loader would load from /boot/kernel instead of /boot/ATH and I'd end up with broken networking even though the kernel was right. I'd really love it if there were a way for modules to be bundled with the kernel file and loaded from the kernel instead of the filesystem, especially since many modules can't be compiled in. As a side note, my /boot/loader is from -STABLE, mod time of January 24 this year. This could be an issue on -STABLE also. From owner-freebsd-current@FreeBSD.ORG Sat Apr 20 21:29:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88354C3D for ; Sat, 20 Apr 2013 21:29:59 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2DCF5E for ; Sat, 20 Apr 2013 21:29:59 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta13.emeryville.ca.mail.comcast.net with comcast id SLZi1l0011vN32cADMVzRu; Sat, 20 Apr 2013 21:29:59 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id SMVy1l00D1t3BNj8iMVyl1; Sat, 20 Apr 2013 21:29:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 04DF773A33; Sat, 20 Apr 2013 14:29:58 -0700 (PDT) Date: Sat, 20 Apr 2013 14:29:58 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130420212957.GA19158@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> <515D3312.3010109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515D3312.3010109@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366493399; bh=CwqtmSuUoQhEabOXV8j+PTjvQvi/2D3CiVf10Y9epcY=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=LcCh2YaATdkGrR3v+vO68Fc6OgwajtA/MLpgsIFQ5fnPOX9aBzviFUbwnAbA8SNr5 OR5cgQjej2iimp9QIkX40l+vIubbvEW9RrbkJFWmER6xgll3xcuz3Y2q/Z3PV0X8Tl X8Ll4tv1ypNeLSpFwJSMIgo2ZHec+WRhJxQSX+waC5HncfJNH/DAFvpIfvBFpouWBd PdluJbMp9pg2B/KePiOFabg2kFOTWsfPvEMfBi/a5y6Lpd/MD7aIFJNY6ZH91Uhknf 4qB7ZYxTKbMtkuf36bokEh7+YxOBVJAgXaGjcmHlBqq/LlqyqGkhRe/I+GS3Sn/ITD iRwibqhM0haIQ== X-Mailman-Approved-At: Sat, 20 Apr 2013 23:59:02 +0000 Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 21:29:59 -0000 On Thu, Apr 04, 2013 at 10:00:18AM +0200, Matthias Andree wrote: > Am 04.04.2013 03:05, schrieb Jeremy Chadwick: > > { snipping stuff I have no comment on. reference thread: } > { > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073036.html } > > > One piece of evidence that refutes my theory is that if Windows and/or > > Linux partition are something you boot into and use often, I would > > imagine NCQ would be used in both of those environments and would suffer > > from the same issue. Although Windows tends to hide all sorts of > > transient errors from the user (sigh), Linux tends to be like FreeBSD > > with regards to such issues (on the console anyway; you wouldn't see > > such messages normally inside of X). > > Now, the FreeBSD slice is the only partition on that disk that would > likely see concurrent write accesses (think "make -j8" on a quadcore > computer) which is more prone to ferret out such alignment contention. > > The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit > the problem anyways. > > The Linux partition is in ext4 format for mostly sequential access to > files usually in excess of 10 MB each. > > Linux's ext4 jumps through several hoops to end up with bulk writes, > like extents, delayed allocations (to avoid fragmentation), reordering > of data and metadata writes, serialized log writes and all that stuff, > and it would appear I am permitting it to cache writes -- Linux uses > write barriers to enforce proper ordering of journal/meta-data writes. > > It would be rather hard to hit ATA taskfile timeouts, the expected rate > with which the drive needs to do a partial write is orders of magnitude > lower. > > Any good "concurrent write" exercise tools for Unix that I could run on > the Linux ext4 partition that you would propose? The only tool I'm familiar with is bonnie++. But I don't think this (partition alignment) is what matters now. Your smartctl output has shed some light on your situation. > >> - I am running with kern.cam.ada.default_timeout=5 which makes the > >> computer recover faster > > > > I can definitely imagine cases where a drive using NCQ but doing writes > > to a non-aligned partition could take longer than 5 seconds to respond > > to an ATA CDB (this is different than a SATA or AHCI layer timeout). I am > > not telling you "change this back to 30", but it might not be helping > > your situation at all given my above theory. > > My feeling is that the stalls are mostly from the error handler and the > overall time the drive is "frozen" gets shorter. If it had not _felt_ > faster, I'd not have left that in sysctl.conf in the first place. Your understanding of what that sysctl does is wrong, or I'm misunderstanding what you're saying (very possible!). How I interpret what you're saying: that the sysctl somehow "decreases stall times" during I/O operations that fail. This is incorrect. What that sysctl does is define the number of seconds that transpire ***before*** the CAM layer says "Okay, I didn't get a response to the ATA CDB I sent the disk", and then re-submits the same CDB to the disk. Rephrased: in the case of a disk stalling on an I/O request, you will experience the effects of that stall no matter what that sysctl is set to. A lower value in that sysctl will result in CAM spitting out nasties on the console + hitting the CDB retry submission scenario sooner, which if the drive is awake/responsive by that time will go smoothly. That's all it does. Thus a value of 5 indicates a device/drive did not respond to a CDB within 5 seconds, and a value of 30 indicates a device/drive did not respond to a CDB within 30 seconds. Regardless, those lengths of time are VERY long for an I/O operation on a mechanical HDD. When you get to the bottom of my Email, you'll understand why I screamed at you about adjusting that sysctl. > > Finally: could you please provide output from "smartctl -x /dev/ada1"? > > I would like to rule out any possibility of your drive having some other > > kind of issue that might cause it to go catatonic. Thanks. > > I have fetched the data with Linux this time (should not make a > difference as it's all drive internal data, not host OS stuff). > > Looks sane to me, . > I'll be happy to refetch this data with a more current smartctl version > under FreeBSD if required. Oh look, it's the Samsung SpinPoint series, especially the EcoGreen ("EG") series. No joke: ~60% of the "problem reports" I deal with when it comes to "weird wonky problems" stem from this drive series. I have no idea why, but they're a common pain point for me. First, about the shown sector size: smartmontools 5.41 was the first release to show the sector sizes per ATA IDENTIFY. I assume they got this right from the get-go. So as of this moment I'm going to assume that this drive really is a 512-byte sector drive. Politely, your analysis of the drive ("looks sane to me") is an indicator of why SMART output needs to be interpreted by a person who is familiar with the information. That drive *does not* look sane to me. :-) The first thing that comes to my attention is attribute 199, indicating that the drive has experienced a total of 14 CRC errors during its lifetime (10779 hours as of that moment). Usually this attribute is zeroed at the factory (other attributes are often not). Just yesterday I wrote a very long/detailed analysis about what this attribute means, so I'll just link you to that post. Please focus on just the part about CRC errors: http://www.dslreports.com/forum/r28219261- The next thing I see are 14 errors in your SMART error log. It's worth noting that this number correlates with the CRC error count above (though depending on drive firmware they may not have a symbiotic relationship). Your SMART error log consists of entries indicating the drive itself sent back error conditions to the controller/OS (which FreeBSD or Linux would show on the console). The timestamps of these events are based on power-on hour count, so the most recent event was at 7747 hours, but there are others going back all the way to 6528 hours. Sadly, the SMART error log is very small (2 sectors / 1024 bytes), so only the last 8 errors can be shown. Key points about these errors: - The LBAs being accessed varies/is all over the board, indicating that it's very unlikely this anomaly is being caused by physical defects on the platters (the drive also shows no remapped LBAs or pending/suspect LBAs, which further supports that theory), - The ATA commands which lead up to the error also vary. Many are for write requests, and from some entries I can see that the OS was doing NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would do this (there's nothing optimal about it) unless there were conditions occurring where the OS/ATA driver said "this NCQ write isn't working (timeout, etc.), let me retry with a classic 28-bit LBA write". There is one entry (the last) which shows a similar situation happening but with NCQ reads. - These are conditions that short, long, select (LBA range scan), and conveyance SMART tests would probably not detect. Like I said: it seems to be all over the board. This is not the first time I have seen this behaviour with SpinPoint drives. Bernd Walter responded indicating that his experience indicated that the issue related to NCQ compatibility. This would not surprise me. NCQ incompatibilities have happened in the past; the most notable (to me) was between Maxtor drives and nVidia SATA controllers. Both companies blamed the other, yet both came out with "fixes" (Maxtor with a firmware update, nVidia with a driver update). Neither company stated anything concrete/useful publicly (oh America, so stock-focused you are). My personal opinion is that the bug was in Maxtor's firmware, and nVidia ceased use of NCQ requests to drives matching specific model numbers (similar to what we do in FreeBSD, re: 4KB quirks). What doesn't help is that SpinPoint drives have a history of pretty awful firmware bugs, such as this one, which still blows my mind to this day: http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks Your drive is using firmware version 1AG01118, but I can't easily find a newer firmware because of the whole Seagate/Samsung buyout (Seagate buying out Samsung's MHDD division). Because of the "random" nature of this issue, my opinion is that what you're experiencing is caused by one of the following: - The "EG" series are known to park their heads excessively, and much to my annoyance, do not track this behaviour in SMART (normally it's tracked in attribute 193, which the drive lacks (probably intentionally)). This head-parking nonsense is known to cause problems in certain situations, reported by the OS as timeouts and I/O errors as the drive is trying to wake up and respond to the CDB. There are many drives on the markets that do this now, and I generally boycott them all (it's only useful for laptops). I can talk at length about that some other time, or you can find/read my blog (I wrote an article about the WD30EFRX doing this -- at least on WD drives you can inhibit the behaviour, while on Seagate you can't). I noticed that SMART attribute 3 on your drive indicates it takes roughly 6.2 seconds to spin up. This may change over time as well (often getting worse as the drive gets older (spindle motors do wear down over time)). Now take into consideration the sysctl you changed, and what I said earlier about me knowing some conditions where a drive may take >5 seconds to handle certain I/O ops. - NCQ bugs in the drive's firmware. You can try to talk to Samsung about this, but you'll probably get no where due to how deep within companies actual engineers live. My suggestions to you at this point in time: - Remove the sysctl and leave it at its default (30 seconds). Or if you really must adjust it, set it to 15. YMMV with this. - Replace the drive and/or choose another drive vendor. My suggestions for FreeBSD at this time: - Regardless of what the root cause of the above is, we really do need a no-NCQ quirk, and we also need to print the quirks used (in a similar fashion to how CPU features are shown) during boot. I can try to write the code for this, but I am going to need help. Kernel land is not something I'm generally good at. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |